SCIENTIFIC-LINUX-DEVEL Archives

July 2013

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Akemi Yagi <[log in to unmask]>
Reply To:
Akemi Yagi <[log in to unmask]>
Date:
Sat, 27 Jul 2013 06:42:27 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (29 lines)
On Fri, Jul 26, 2013 at 3:36 AM, Anton Starikov <[log in to unmask]> wrote:
> Hey,
>
> I don't know how to proceed with this, as clearly thus must be patched upstream, but I don't use upstream so I submit here.
>
> 1) there is parameter in "nfs" module called "nfs4_disable_idmapping", to disable mapping on a client-side when AUTH_SYS. It was introduced, for support of NFS4-root. But NFS4-root can work smoothly only when on both sides, client and server, idmapping is disabled. It was fixed for "nfsd" in fresh kernels (commit http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e9541ce8efc22c233a045f091c2b969923709038 ).
>
> I attach here backported patch for current 2.6.32-358 kernels. I set default value of nfs4_disable_idmapping to FALSE in this patch, in order to mimic behaviour of unpatched kernel. (this differs from modern kernels, where it is TRUE by default).
>
>
> 2) with NFS4 mounted filesystems there is and issue with execution of files which has execute-only mode (111). (Typical example: sudo will not work on nfs4-root). This was also fixed relatively recently in fresh kernels. Here I attach patch, which fixes that (it affects both, "nfs" and "nfsd" modules). It is backported from 3.1.x.
>
>
> Without this patches, NFS4-root will never function as it really should. With this patches everything works like a charm.
>
> In my setups I have this patched modules in dkms, but having them in the upstream will be nice simplification of life :)

Do you think they can be built as kABI-tracking kmods? If so, would
you consider contributing to ELRepo?

As Pat mentioned, patches like this must be added to the upstream
(RHEL) kernel for rebuild projects like Scientific Linux to get them
in their distro kernels. This could take a long time depending on the
urgency (from the upstream's point of view). It will be beneficial if
the patches can be distributed as modules, which is why I'm wondering
if ELRepo can offer them as kmods.

Akemi

ATOM RSS1 RSS2