Issue with kernel 6.8.0-40-generic?

Sat Apr 5 21:42:43 UTC 2025

Lightly updated version of Pali's patch description, merged into
cifs-2.6.git pending more review and testing.

Junwen,
Let me know if you see any problems.  I have tested it but the more
testing the better

On Sat, Apr 5, 2025 at 2:59 PM Pali Rohár <pali at kernel.org> wrote:
>
> Steve, thank you for testing. I will do some other my own tests too.
>
> For explanation, the function parse_reparse_point() is called by
> reparse_info_to_fattr() and then return value from
> reparse_info_to_fattr() is checked against -EOPNOTSUPP for handling name
> surrogate reparse points. This logic was added in the commit
> b587fd128660 ("cifs: Treat unhandled directory name surrogate reparse
> points as mount directory nodes").
>
> So this code in reparse_info_to_fattr() requires to know if the reparse
> point was handled by the parse_reparse_point() function or not. Hence
> reverting commit cad3fc0a4c8c ("cifs: Throw -EOPNOTSUPP error on
> unsupported reparse point type from parse_reparse_point()") would cause
> that the above logic stop working.
>
> To fix both problems, the one reported by Junwen about unsupported
> OneDrive reparse point, and the name surrogate reparse points, I'm
> proposing in my change to "mask" the -EOPNOTSUPP not in the called
> parse_reparse_point() function but instead in the caller
> reparse_info_to_fattr().
>
> During writing b587fd128660 and cad3fc0a4c8c I somehow forgot about the
> case which cause this issue.
>
> Linux SMB client should not filter out unknown/unhandled reparse points.
> Reparse points are processed by the SMB server (with few exceptions for
> UNIX special files).
>
> In the attachment I'm sending the patch, now with the commit message and
> Fixes lines.
>
> On Saturday 05 April 2025 14:30:22 Steve French wrote:
> > This was easy to reproduce on mainline for me as well (and presumably
> > the same on 6.12 and 6.13 since it has been picked up by stable, and
> > even looks it has been picked up in 6.6. stable) by simply mounting a
> > Windows share that was exporting a onedrive directory.
> >
> > Pali,
> > I did verify that your suggested fix worked for my experiment
> > (exporting onedrive dir as share).   Could you give more specific
> > examples of
> >
> >       'Reverting "cifs: Throw -EOPNOTSUPP error on unsupported reparse
> > point type from parse_reparse_point()" would
> >       break processing of the name-surrogate reparse points.
> >
> > ie some repro examples that Junwen etc. could try
> >
> > Welcome any other Tested-by/Reviewed-by/Acked-by for the two
> > alternatives - reverting the patch, vs. Pali's workaround
> >
> >
> > On Sat, Apr 5, 2025 at 12:20 PM Pali Rohár <pali at kernel.org> wrote:
> > >
> > > Hello Junwen,
> > >
> > > Could you please provide me more details about your issue? What exact
> > > kernel version is affected and what error message you see? Because in
> > > email subject is version 6.8 and in description is 6.12, so I quite
> > > confused.
> > >
> > > I will look at this issue, just I need all detailed information.
> > > It looks like that the error handling is missing some case there.
> > >
> > > Thanks
> > >
> > > Pali
> > >
> > > On Saturday 05 April 2025 12:16:27 Steve French wrote:
> > > > Good catch - it does look like a regression introduced by:
> > > >
> > > >         cad3fc0a4c8c ("cifs: Throw -EOPNOTSUPP error on unsupported
> > > > reparse point type from parse_reparse_point()")
> > > >
> > > > The "unhandled reparse tag: 0x9000701a" looks like (based on MS-FSCC
> > > > document) refers to
> > > >
> > > >     "IO_REPARSE_TAG_CLOUD_7   0x9000701A  Used by the Cloud Files
> > > > filter, for files managed by a sync engine such as OneDrive"
> > > >
> > > > Will need to revert that as it looks like there are multiple reparse
> > > > tags that it will break not just the onedrive one above
> > > >
> > > >
> > > > On Fri, Apr 4, 2025 at 10:24 PM Junwen Sun <sunjw8888 at gmail.com> wrote:
> > > > >
> > > > > Dear all,
> > > > >
> > > > > This is my first time submit an issue about kernel, if I am doing this
> > > > > wrong, please correct me.
> > > > >
> > > > > I'm using Debian testing amd64 as a home server. Recently, it updated
> > > > > to linux-image-6.12.20-amd64 and I found that it couldn't mount
> > > > > OneDrive shared folder using cifs. If I boot the system with 6.12.19,
> > > > > then there is no such problem.
> > > > >
> > > > > It just likes the issue Marc encountered in this thread. And the issue
> > > > > was fixed by commit 'ec686804117a0421cf31d54427768aaf93aa0069'. So,
> > > > > I've done some research and found that in 6.12.20, there is a new
> > > > > commit 'fef9d44b24be9b6e3350b1ac47ff266bd9808246' in cifs which almost
> > > > > revert the commit 'ec686804117a0421cf31d54427768aaf93aa0069'. I guess
> > > > > it brings the same issue back to 6.12.20.
> > > > >
> > > > > Thanks very much in advance if someone can have a look into this issue again.
> > > > >
> > > > > 孙峻文
> > > > > Sun Junwen
> > > >
> > > >
> > > >
> > > > --
> > > > Thanks,
> > > >
> > > > Steve
> >
> >
> >
> > --
> > Thanks,
> >
> > Steve

-- 
Thanks,

Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cifs-Ensure-that-all-non-client-specific-reparse-poi.patch
Type: text/x-patch
Size: 3336 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20250405/213607ad/0001-cifs-Ensure-that-all-non-client-specific-reparse-poi.bin>