[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <PSAP153MB04220682838AC9D025414B6094769@PSAP153MB0422.APCP153.PROD.OUTLOOK.COM>
Date: Tue, 6 Apr 2021 14:00:48 +0000
From: Shyam Prasad <Shyam.Prasad@...rosoft.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Salvatore Bonaccorso <carnil@...ian.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
Aurelien Aptel <aaptel@...e.com>,
Steven French <Steven.French@...rosoft.com>,
Sasha Levin <sashal@...nel.org>
Subject: RE: [EXTERNAL] Re: [PATCH 4.19 013/247] cifs: Set
CIFS_MOUNT_USE_PREFIX_PATH flag on setting cifs_sb->prepath.
Hi Greg,
We'll need to debug this further to understand what's going on.
Hi Salvatore,
Any chance that you'll be able to provide us the cifsFYI logs from the time of mount failure?
https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Enabling_Debugging
Regards,
Shyam
-----Original Message-----
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Sent: Tuesday, April 6, 2021 7:12 PM
To: Salvatore Bonaccorso <carnil@...ian.org>
Cc: linux-kernel@...r.kernel.org; stable@...r.kernel.org; Shyam Prasad <Shyam.Prasad@...rosoft.com>; Aurelien Aptel <aaptel@...e.com>; Steven French <Steven.French@...rosoft.com>; Sasha Levin <sashal@...nel.org>
Subject: [EXTERNAL] Re: [PATCH 4.19 013/247] cifs: Set CIFS_MOUNT_USE_PREFIX_PATH flag on setting cifs_sb->prepath.
On Tue, Apr 06, 2021 at 01:38:24PM +0200, Salvatore Bonaccorso wrote:
> Hi,
>
> On Mon, Mar 01, 2021 at 05:10:33PM +0100, Greg Kroah-Hartman wrote:
> > From: Shyam Prasad N <sprasad@...rosoft.com>
> >
> > [ Upstream commit a738c93fb1c17e386a09304b517b1c6b2a6a5a8b ]
> >
> > While debugging another issue today, Steve and I noticed that if a
> > subdir for a file share is already mounted on the client, any new
> > mount of any other subdir (or the file share root) of the same share
> > results in sharing the cifs superblock, which e.g. can result in
> > incorrect device name.
> >
> > While setting prefix path for the root of a cifs_sb,
> > CIFS_MOUNT_USE_PREFIX_PATH flag should also be set.
> > Without it, prepath is not even considered in some places, and
> > output of "mount" and various /proc/<>/*mount* related options can
> > be missing part of the device name.
> >
> > Signed-off-by: Shyam Prasad N <sprasad@...rosoft.com>
> > Reviewed-by: Aurelien Aptel <aaptel@...e.com>
> > Signed-off-by: Steve French <stfrench@...rosoft.com>
> > Signed-off-by: Sasha Levin <sashal@...nel.org>
> > ---
> > fs/cifs/connect.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c index
> > 6285085195c15..632249ce61eba 100644
> > --- a/fs/cifs/connect.c
> > +++ b/fs/cifs/connect.c
> > @@ -3882,6 +3882,7 @@ int cifs_setup_cifs_sb(struct smb_vol *pvolume_info,
> > cifs_sb->prepath = kstrdup(pvolume_info->prepath, GFP_KERNEL);
> > if (cifs_sb->prepath == NULL)
> > return -ENOMEM;
> > + cifs_sb->mnt_cifs_flags |= CIFS_MOUNT_USE_PREFIX_PATH;
> > }
> >
> > return 0;
>
> A user in Debian reported an issue with mounts of DFS shares after an
> update in Debian from 4.19.177 to 4.181:
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.debian.org%2Fdebian-user%2F2021%2F04%2Fmsg00062.html&data=04%7C0
> 1%7CShyam.Prasad%40microsoft.com%7C0acbccd2643f4d55c6d008d8f901c180%7C
> 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637533133251645484%7CUnknow
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> JXVCI6Mn0%3D%7C1000&sdata=9xz2q%2FC1ur%2F3y70L5CJ5YoL%2FLhSci5hJ3U
> pttjbZJas%3D&reserved=0
>
> In a test setup i was able to reproduce the issue with 4.19.184 itself
> (but interestingly not withing the 5.10.y series, checked 5.10.26)
> which both contain the above commit.
>
> 4.19.184 with a738c93fb1c1 ("cifs: Set CIFS_MOUNT_USE_PREFIX_PATH flag
> on setting cifs_sb->prepath.") reverted fixes the issue.
>
> Is there probably some missing prerequisites missing in the 4.19.y
> brach? I could not test othr versions, but maybe other versions are
> affected as well as before 4.19.y, as the commit was backported to
> 4.14.223 as well.
If there is a missing patch, we will be glad to take it, does 5.4 also have this problem?
thanks,
greg k-h
Powered by blists - more mailing lists