mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alexey Dobriyan <adobriyan@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, jstultz@google.com, me@cherr.cc,
	mm-commits@vger.kernel.org
Subject: Re: + proc-fix-comm_write-return-value-when-truncated-or-error.patch added to mm-nonmm-unstable branch
Date: Fri, 24 Apr 2026 16:40:02 +0300	[thread overview]
Message-ID: <ef2301c4-bbc5-496e-b9d2-9adcff8b8d42@p183> (raw)
In-Reply-To: <20260424105325.B0E0BC19425@smtp.kernel.org>

On Fri, Apr 24, 2026 at 03:53:25AM -0700, Andrew Morton wrote:
> From: "Shengzhuo Wei" <me@cherr.cc>
> Subject: proc: fix comm_write return value when truncated or error
> Date: Fri, 24 Apr 2026 04:06:21 +0800
> 
> When count exceeds TASK_COMM_LEN-1, comm_write() copies at most
> TASK_COMM_LEN-1 bytes but returns the original count.  This violates
> write(2) semantics, which require returning the number of bytes actually
> written.


This is sketchy for reasons:

1) not consuming whole buffer may (and will) break programs which write
   overlong string _and_ use "while (len > 0) { len -= write(); } "
   full write idiom.

2) adding filesystems semantics of writing into the middle of the file
   is counter productive here.

   If "comm" was regular API, there would be "read comm", "write comm"
   + some locking inside of the kernel. Partial update is kind of silly
   here because string is small.

   IIRC there was sysctl fixes banning partial update of modprobe path
   or something like that for security/predictability reasons.

> --- a/fs/proc/base.c~proc-fix-comm_write-return-value-when-truncated-or-error
> +++ a/fs/proc/base.c
> @@ -1727,8 +1727,10 @@ static ssize_t comm_write(struct file *f

> -	return count;
> +	return ret;

           reply	other threads:[~2026-04-24 13:37 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20260424105325.B0E0BC19425@smtp.kernel.org>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ef2301c4-bbc5-496e-b9d2-9adcff8b8d42@p183 \
    --to=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=jstultz@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=me@cherr.cc \
    --cc=mm-commits@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®