Re: [PATCH 0/9] Various changes

[Pali Rohár]

On Tuesday 13 October 2026 14:25:34 Namjae Jeon wrote:
> On Mon, Oct 12, 2026 at 11:10 PM Pali Rohár <pali@xxxxxxxxxx> wrote:
> >
> Hi Pali,
> > Hello, now when is the -rc7 cycle, could you review these patches?
> > So if there are any issues, I would have a chance to address them for
> > the next merge window.
> Could you check sashiko's review comments from these patches ?
> 
> https://sashiko.dev/#/patchset/20260825230622.24617-1-pali%40kernel.org
> 
> Thanks!

Sure, I did not know that there is already review from machine. I have
not received any email about it.

I have checked those comments and here is what I think about it:

PATCH 1/9 is removal of dead code and sashiko found just pre-existing
issue which seems to be not related to this patch.

PATCH 2/9 comment 1 - here sashiko things that the code for serverino
disable should not be called. I think that this is wrong. If cifs.ko
detects that the inode number cannot retrieved then it must disable
serverino otherwise cifs.ko start reporting duplicate inode numbers to
userspace.  I think that in the current situation it must already happen
(from different code path), so I do not think this is valid point.

PATCH 2/9 comment 2 - this is preexisting issue

PATCH 4/9 - preexisting issue

PATCH 7/9 comment 1 - this is not a problem, non-WSL clients (therefore
also Linux one) do not need that EA for working correctly. Also
userspace application cannot see a special EA from userspace and even if
it is able to retrieve it (e.g. via separate own userspace smb client on
separate connection), this is basically a race condition in the smb
protocol itself like any other which requires multiple requests to
finish one filesystem call.

PATCH 7/9 comment 2 - this is preexisting issue

PATCH 8/9 comment 1 - unbound memory allocation based on symlink length
- this is valid, but unfortunately all the symlink parsing code would do
similar thing. And we have already more symlink types. Do we have some
limit how long could be symlink? Does it make sense to address only this
one issue and let all other untouched? I would rather propose to define
one common limit and fix this issue on all places.

PATCH 8/9 comment 2 - fid.netfid initialization - I'm not sure here.
I had an impression that this is a right pattern how to open and read
file. Can somebody else recheck this?

PATCH 9/9 - masking sync_write error by -EI - This looks to be valid.
The fix is simple, just adding "rc &&" before "bytes_written !=".