Re: [PATCH] proc: fix comm_write return value when truncated or error
From: Shengzhuo Wei
Date: Fri Apr 24 2026 - 14:04:54 EST
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.