Bug 786149
|
Description
chris.petty
2012-01-31 15:36:44 UTC
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 |