[LU-7845] Support namespace in credentials retrieval

• Type: New Feature
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.10.0
• Labels: patch
• Assignee: John Hammond
• Reporter: Sebastien Buisson (Inactive)

Description

We are running Lustre clients from Docker containers, and we try to have Kerberos authentication for them.
We hit an issue when Lustre code (kernel space, so running on the host) calls request_key to get Kerberos credentials. The problem is that the request_key function will call the userland helper function that is on the host, not in the container, because it has no idea that it all started from a container. The consequence is that Lustre cannot get the Kerberos credentials associated with the client in the container.

There are some ongoing discussions in the kernel to find the best way, if any, to address this problem of namespace between request_key and userland helper.
However, I think we cannot afford having a patched kernel on client side. So I started thinking about a way to be able to retrieve credentials stored inside a Docker container when Lustre is mounted from this container.
I will post a patch with my proposal.

Thanks,
Sebastien.

Issue Links

• is related to: LU-16557 don't skip add_conn with -o network mount option
• is related to: LU-8392 sanity test_27z: soft lockup - CPU#0 stuck for 22s! [ptlrpcd_rcv:6145]

Comments

[Peter Jones]

Landed for 2.10

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/19792/
Subject: LU-7845 obd: add 'network' client mount option
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 1cf11e1cf9a55fa71c873a5f485be4b63e3a5e39

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/18781/
Subject: LU-7845 gss: support namespace in lgss_keyring
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 94c44c62dea2cf1f2174569524721ded1bbd1ce7

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/21884/
Subject: LU-7845 lnet: check if ni is in current net namespace
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 9a7c0e1207becd10fb70672193ca39cbfabdcf84

[Gerrit Updater]

Sebastien Buisson ([e-mail]) uploaded a new patch: http://review.whamcloud.com/21884
Subject: LU-7845 lnet: check if ni is in current net namespace
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 17aecba54686ec1ed45fd62944d3d61b48b547b6

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/21631/
Subject: Revert "LU-7845 lnet: check if address is visible"
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 0f9fa5180fb015af656b8eea06f04b02abc02232

[Sebastien Buisson (Inactive)]

Hi,

Confirmed that http://review.whamcloud.com/21437 passes sanity tests consistently.

[Sebastien Buisson (Inactive)]

FYI, patch http://review.whamcloud.com/21437 successfully passed Maloo tests.
I have just retriggered them with:
Test-Parameters: fortestonly testlist=sanity,sanity,sanity,sanity
to see if it passes sanity consistently.

[Sebastien Buisson (Inactive)]

I pushed a new version of the patch at http://review.whamcloud.com/21437, that avoids calling LIBCFS_ALLOC() while holding the lock.

[John Hammond]

> But as the issue was still hit with patch http://review.whamcloud.com/21437 (patch that avoids calling lnet_ipif_query() while holding the lnet_net_lock), there is no clue that this patch is responsible for this soft lockup.

This patch calls LIBCFS_ALLOC() while holding the lock so it's also subject to soft lockup.