linux-kernel - Re: [PATCH 1/3] pipe: drop an always true check in anon_pipe

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: <CAGudoHG260oJkBPXwe13YqeC_si8RVUAHdMU1wMhNnXrZUFvPQ@mail.gmail.com>
Date: Tue, 4 Mar 2025 15:58:47 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: torvalds@...ux-foundation.org, brauner@...nel.org, mingo@...hat.com, 
	peterz@...radead.org, rostedt@...dmis.org, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 1/3] pipe: drop an always true check in anon_pipe_write()

On Tue, Mar 4, 2025 at 3:08 PM Oleg Nesterov <oleg@...hat.com> wrote:
>
> On 03/04, Mateusz Guzik wrote:
> >
> > @@ -529,10 +529,9 @@ anon_pipe_write(struct kiocb *iocb, struct iov_iter *from)
> >
> >                       if (!iov_iter_count(from))
> >                               break;
> > -             }
> >
> > -             if (!pipe_full(head, pipe->tail, pipe->max_usage))
> >                       continue;
> > +             }
>
> Reviewed-by: Oleg Nesterov <oleg@...hat.com>
>

thanks

> It seems that we can also remove the unnecessary signal_pending()
> check, but I need to recheck and we need to cleanup the poll_usage
> logic first.
>
> This will also remove the unnecessary wakeups when the writer is
> interrupted by signal/
>
[snip]

There are many touch ups to do here, I don't have an opinion about this diff.

I don't have compiled stats handy, but few months back I asked some
people to query pipe writes with dtrace on FreeBSD. Everything is very
heavily skewed towards < 128 bytes in total, including tons of 1 bytes
(and no, it's not just make). However, there is also quite a bit of
absolutely massive multipage ops as well -- north of  64K even. Doing
that kind of op in one go is way faster than restarting rep mov every
time interleaved with SMAP toggling, which is expensive in its own
right.

Thus I would argue someone(tm) should do it in Linux, but I don't have
immediate plans. Perhaps you would be happy to do it? :)

In the meantime, I would hope any refactoring in the area would make
the above easier (my patch does, I'm not claiming your does not :P)
-- 
Mateusz Guzik <mjguzik gmail.com>