I usually start with their bug tracker at:

http://elrepo.org/bugs/main_page.php


Pat

On 07/27/2013 09:07 AM, Anton Starikov wrote:
>
> So, point me to the instruction how to contribute to elrepo and I will do it.
>
> On 27 Jul 2013 15:42, "Akemi Yagi" <[log in to unmask] 
> <mailto:[log in to unmask]>> wrote:
>
>     On Fri, Jul 26, 2013 at 3:36 AM, Anton Starikov <[log in to unmask]
>     <mailto:[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
>


-- 
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/