Created attachment 567951 [details]
Patch vfs - fix LOOKUP_DIRECTORY not propagated to managed_dentry()

We can try this patch if someone wants to build a kernel with
it now, I'll do that tomorrow anyway if not.

Created attachment 567961 [details]
successful DFS access via a 131.12 kernel

Created attachment 567962 [details]
unsuccessful DFS access via a newer 220.4 kernel

unfortunately my first comment disappeared when i added the attachments, but the mount was made with:


sudo /sbin/mount.cifs //munin/data /mnt/users/petty -o uid=2022,gid=0,user=petty,domain=BIAC,rw,file_mode=0600,dir_mode=0700

131.21 shows the successful access, 220.4 was unsuccessful.

I accessed the same directory in the DFS both times.

command: ls /mnt/users/petty/Daemon/Salvage.01
220.4 result: ls: cannot access /mnt/users/petty/Daemon/Salvage.01: Not a directory

131.21 result was a listing of contents.

Chris, 

Thanks for that info. We did find a regression caused by the patch for an issue reported in kernel 2.6.32-191.el6
- [fs] CIFS: Use d_automount() rather than abusing follow_link() [ver #2] (Ian
Kent) [704941]
which prevents the submounts from from being mounted automatically by the client. This also affect NFS mounts in a similar manner.

Ian has provided a patch which in c#5 which can fix this particular problem. Can you please test that fix and let us know the results.

Sachin Prabhu

Chris,

Can you please open a case with the support group and point them to this bz so that we can provide you with a test kernel with the fix for the problem. The test kernel contains a fix for a regression introduced in -191 kernel which fixes the problem you see.

Sachin Prabhu

We had a crack at compiling the kernel with the patch, everything compiled and booted correctly, however after mounting the relevant server through CIFS we still had the same result:

ls: cannot access /mnt/users/petty/Daemon/Salvage.01: Not a directory


We're unsure if the patch was implemented correctly within the compiled kernel, so i'll open a case to be sure.

I was the one that compiled the kernel that Chris tested.  I used kernel sources 2.6.32-220.7.1.el6 and the patch (modified slightly to change the line numbers) applied successfully during the build, and the extracted source reflects the patch to fs/namei.c .  If we should be patching a different source version, we'd be happy to test with that.

(In reply to comment #8)
> unfortunately my first comment disappeared when i added the attachments, but
> the mount was made with:
> 
> 
> sudo /sbin/mount.cifs //munin/data /mnt/users/petty -o
> uid=2022,gid=0,user=petty,domain=BIAC,rw,file_mode=0600,dir_mode=0700
> 
> 131.21 shows the successful access, 220.4 was unsuccessful.
> 
> I accessed the same directory in the DFS both times.
> 
> command: ls /mnt/users/petty/Daemon/Salvage.01
> 220.4 result: ls: cannot access /mnt/users/petty/Daemon/Salvage.01: Not a
> directory

This isn't the same use case as that in comment #0 and is not
what the attached patch was meant to address.

What are the DFS mount points in the path above, Daemon, also
Salvage.01?

Daemon would be the DFS point, Salvage is subdirectory within that point.

Also, that is the same as comment #0, however this time i had mounted //munin/data directly to /mnt/users/petty, sorry for the confusion.

(In reply to comment #12)
> We had a crack at compiling the kernel with the patch, everything compiled and
> booted correctly, however after mounting the relevant server through CIFS we
> still had the same result:
> 
> ls: cannot access /mnt/users/petty/Daemon/Salvage.01: Not a directory

Lets have a look at an strace of running this command.

(In reply to comment #15)
> Daemon would be the DFS point, Salvage is subdirectory within that point.
> 
> Also, that is the same as comment #0, however this time i had mounted
> //munin/data directly to /mnt/users/petty, sorry for the confusion.

Sure, from your point of view, yes, but the issue that the
patch seeks to address is specifically the case where the
DFS path has a trailing "/".

(In reply to comment #15)
> Daemon would be the DFS point, Salvage is subdirectory within that point.

Does the DFS mount Daemon actually end up mounted after the
error return?

(In reply to comment #18)
> (In reply to comment #15)
> > Daemon would be the DFS point, Salvage is subdirectory within that point.
> 
> Does the DFS mount Daemon actually end up mounted after the
> error return?


I'm never able to access anything inside Daemon though the new kernel, it returns an error on every access. 

I'll provide the trace tomorrow, the newer kernel is only running on a virtual machine that i can't get to reliably from home.

(In reply to comment #19)
> (In reply to comment #18)
> > (In reply to comment #15)
> > > Daemon would be the DFS point, Salvage is subdirectory within that point.
> > 
> > Does the DFS mount Daemon actually end up mounted after the
> > error return?
> 
> 
> I'm never able to access anything inside Daemon though the new kernel, it
> returns an error on every access. 

That's actually good, it's what I wanted to hear.

> 
> I'll provide the trace tomorrow, the newer kernel is only running on a virtual
> machine that i can't get to reliably from home.

No problem.

Probably still worth doing although I might have spotted the
problem. But before producing a patch I need to consult Jeff.

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

Created attachment 568665 [details]
strace /mnt/users/petty/munin/data

Strace of listing data, which was mounted as the equivalent of comment #0.

Created attachment 568666 [details]
strace /mnt/users/petty/munin/data/Daemon/

Strace of listing a DFS share

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

Can we get a trace of the CIFS activity when attempting a
mount which fails please. I must know if the vfs automounting
code is being called or not.

I believe this should get what we want (after the cifs
module has been loaded):

echo 7 > /proc/fs/cifs/cifsFYI

(In reply to comment #32)
> Can we get a trace of the CIFS activity when attempting a
> mount which fails please. I must know if the vfs automounting
> code is being called or not.
> 
> I believe this should get what we want (after the cifs
> module has been loaded):
> 
> echo 7 > /proc/fs/cifs/cifsFYI

When doing this test ensure that a kernel with the patch from
comment #5 is used and that a trailing "/" is included in the
path used for the directory listing.

It might also be useful to include a trace of a mount attempt
without a trailing "/" also.

Thanks.  The virtual machine we were testing on is inaccessible at the moment, but should be available early next week.  We'll make sure to get the trace from the patched kernel (we have it built already and tested it, but never got a trace).  We'll do the test with and without the trailing "/".

Created attachment 577804 [details]
dmesg with cifsFYI = 7

dmesg from the patched kernel with cifsFYI = 7

There are several cases of listing DFS shares as well as the base
 mount point which shows all the various DFS shares.

Some were listed with and without the trailing "/"

ls /mnt/users/petty/Daemon/
ls: cannot access /mnt/users/petty/Daemon/: Not a directory

ls /mnt/users/petty/Daemon
ls: cannot open directory /mnt/users/petty/Daemon: Not a directory

Chris, thanks for the cifs trace.

Looking at it confirmed that in fact the VFS was not calling
the automounting functions.

Using the trace as a guide I found what appears to be a problem
where a prior directory read prevents the correct flags being
set and consequently automount for dfs mounts in that directory
don't trigger. At least that is what I see looking at the trace
and the cifs code. Hopefully this is the problem you are seeing.

I've built a test kernel with the changes I hope will fix the
problem so please test it and report back.

It can be found at:
http://people.redhat.com/~ikent/kernel-2.6.32-220.9.1.el6.bz786149.3

It turns out that the patch I'm using, but not the patch in
comment #5, is part of of the resolution for another bug and
is already included in RHEL-6.3.

Thanks Ian ... do you happen to have the kernel-firmware package associated with this patched kernel?

I rebuild the srpm from source hoping it would produce the firmware as well, but i just got these:

kernel-2.6.32-220.9.1.el6.bz786149.3.x86_64.rpm
kernel-debuginfo-2.6.32-220.9.1.el6.bz786149.3.x86_64.rpm
kernel-debug-2.6.32-220.9.1.el6.bz786149.3.x86_64.rpm
kernel-debuginfo-common-x86_64-2.6.32-220.9.1.el6.bz786149.3.x86_64.rpm
kernel-debug-debuginfo-2.6.32-220.9.1.el6.bz786149.3.x86_64.rpm  
kernel-devel-2.6.32-220.9.1.el6.bz786149.3.x86_64.rpm
kernel-debug-devel-2.6.32-220.9.1.el6.bz786149.3.x86_64.rpm
kernel-headers-2.6.32-220.9.1.el6.bz786149.3.x86_64.rpm

sorry, dis-regard that .. i'm building the noarch stuff now, will try the kernel when finished.

installed the new kernel/header/firmware and the DFS mounts work as expected again.

Thanks.

We need to go through the test process once again since
I believe there is a race with the patch used in the the
recent test kernel.

Please test the kernel found here:
http://people.redhat.com/~ikent/kernel-2.6.32-220.9.1.el6.bz786149.4

Created attachment 580327 [details]
Patch - check S_AUTOMOUNT in revalidate

Patch used in kernel-2.6.32-220.9.1.el6.bz786149.4.

Created attachment 580329 [details]
Patch - check S_AUTOMOUNT in revalidate (against current source)

This is a patch against the current RHEL-6 repository
for the recommended correction.

Mounts continue to work in this newer kernel as well.

-chris

Created attachment 581138 [details]
Patch vfs - fix LOOKUP_DIRECTORY not propagated to managed_dentry() (updated)

Patch(es) available on kernel-2.6.32-270.el6

This bug is reproduced on 2.6.32-220.el6, verified on 2.6.32-270.el6.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2012-0862.html