Re: [PATCH] proc: fix comm_write return value when truncated or error

["Shengzhuo Wei" <me@cherr.cc>]

On 2026-04-24 16:28, Alexey Dobriyan wrote:
> > > Fixes: 4614a696bd1c ("procfs: allow threads to rename siblings via /proc/pid/tasks/tid/comm")
> > 
> > December 2009.
> > 
> > Hopefully no userspace is depending on the broken return value of a
> > write to /proc/pid/comm.
> > 
> > Arguably we should leave the code as-is and add an apologetic comment
> > explaining the situation.
> 

First, there's a plain bug regardless: assigning -EINVAL to a size_t count and
returning it as ssize_t produces a bogus positive value on the error path.
Introducing a dedicated ssize_t ret fixes this without changing any
success-path behavior, the change is on a permission failure path, so it's hard 
to imagine anyone depending on the broken behavior, but worth mentioning

> Yes, this issue must all over virtual filesystems.
> 
> Patch may break stuff in the other direction too:
> 
> if process is doing "full write" loop, and write hook gets string
> which is too long, then the last piece will be written, not truncated
> first part.

For the truncation case, I agree returning a short count breaks the
full-write idiom. But sliently truncating isnt't great either. Maybe we
should reject overlong writes and return -EINVAL instead? That's also an
ABI change and breaks the userspace, so it needs discussion, but at
least it fails loudly.

> 
> 	/proc/alexey

Very happy to hear from your opinions and sorry for my poor English.
Best regards.