lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250304234908.GH5756@redhat.com>
Date: Wed, 5 Mar 2025 00:49:09 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Hillf Danton <hdanton@...a.com>
Cc: K Prateek Nayak <kprateek.nayak@....com>,
	Mateusz Guzik <mjguzik@...il.com>,
	"Sapkal, Swapnil" <swapnil.sapkal@....com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] pipe_read: don't wake up the writer if the pipe is still
 full

On 03/05, Hillf Danton wrote:
>
> On Tue, 4 Mar 2025 13:34:57 +0100 Oleg Nesterov <oleg@...hat.com>
> > > >
> > > Note wakeup can occur even if pipe is full,
> >
> > Perhaps I misunderstood you, but I don't think pipe_read() can ever do
> > wake_up(pipe->wr_wait) if pipe is full...
> >
> > > 		 * So we still need to wake up any pending writers in the
> > > 		 * _very_ unlikely case that the pipe was full, but we got
> > > 		 * no data.
> > > 		 */
> >
> > Only if wake_writer is true,
> >
> > 		if (unlikely(wake_writer))
> > 			wake_up_interruptible_sync_poll(...);
> >
> > and in this case the pipe is no longer full. A zero-sized buffer was
> > removed.
> >
> > Of course this pipe can be full again when the woken writer checks the
> > condition, but this is another story. And in this case, with your
> > proposed change, the woken writer will take pipe->mutex for no reason.
> >
> See the following sequence,
>
> 	1) waker makes full false
> 	2) waker makes full true
> 	3) waiter checks full
> 	4) waker makes full false

I don't really understand this sequence, but

> waiter has no real idea of full without lock held, perhaps regardless
> the code cut below.

Of course! Again, whatever the woken writer checks in pipe_writable()
lockless, another writer can make pipe_full() true again.

But why do we care? Why do you think that the change you propose makes
more sense than the fix from Prateek or the (already merged) Linus's fix?

Oleg.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ