| 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
| ||
|
Message-ID: <20241226160007.GA11118@redhat.com>
Date: Thu, 26 Dec 2024 17:00:07 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: WangYuli <wangyuli@...ontech.com>
Cc: viro@...iv.linux.org.uk, brauner@...nel.org, jack@...e.cz,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
yushengjin@...ontech.com, zhangdandan@...ontech.com,
guanwentao@...ontech.com, zhanjun@...ontech.com,
oliver.sang@...el.com, ebiederm@...ssion.com,
colin.king@...onical.com, josh@...htriplett.org,
penberg@...helsinki.fi, manfred@...orfullife.com, mingo@...e.hu,
jes@....com, hch@....de, aia21@...tab.net, arjan@...radead.org,
jgarzik@...ox.com, neukum@...hschaft.cup.uni-muenchen.de,
oliver@...kum.name, dada1@...mosbay.com, axboe@...nel.dk,
axboe@...e.de, nickpiggin@...oo.com.au, dhowells@...hat.com,
nathans@....com, rolandd@...co.com, tytso@....edu, bunk@...sta.de,
pbadari@...ibm.com, ak@...ux.intel.com, ak@...e.de,
davem@...emloft.net, jsipek@...sunysb.edu, jens.axboe@...cle.com,
ramsdell@...re.org, hch@...radead.org,
torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
randy.dunlap@...cle.com, efault@....de, rdunlap@...radead.org,
haveblue@...ibm.com, drepper@...hat.com, dm.n9107@...il.com,
jblunck@...e.de, davidel@...ilserver.org,
mtk.manpages@...glemail.com, linux-arch@...r.kernel.org,
vda.linux@...glemail.com, jmorris@...ei.org, serue@...ibm.com,
hca@...ux.ibm.com, rth@...ddle.net, lethal@...ux-sh.org,
tony.luck@...el.com, heiko.carstens@...ibm.com, andi@...stfloor.org,
corbet@....net, crquan@...il.com, mszeredi@...e.cz,
miklos@...redi.hu, peterz@...radead.org, a.p.zijlstra@...llo.nl,
earl_chew@...lent.com, npiggin@...il.com, npiggin@...e.de,
julia@...u.dk, jaxboe@...ionio.com, nikai@...ai.net,
dchinner@...hat.com, davej@...hat.com, npiggin@...nel.dk,
eric.dumazet@...il.com, tim.c.chen@...ux.intel.com,
xemul@...allels.com, tj@...nel.org, serge.hallyn@...onical.com,
gorcunov@...nvz.org, levinsasha928@...il.com, penberg@...nel.org,
amwang@...hat.com, bcrl@...ck.org, muthu.lkml@...il.com,
muthur@...il.com, mjt@....msk.ru, alan@...rguk.ukuu.org.uk,
raven@...maw.net, thomas@...3r.de, will.deacon@....com,
will@...nel.org, josef@...hat.com, anatol.pomozov@...il.com,
koverstreet@...gle.com, zab@...hat.com, balbi@...com,
gregkh@...uxfoundation.org, mfasheh@...e.com, jlbec@...lplan.org,
rusty@...tcorp.com.au, asamymuthupa@...ron.com, smani@...ron.com,
sbradshaw@...ron.com, jmoyer@...hat.com, sim@...tway.ca,
ia@...udflare.com, dmonakhov@...nvz.org, ebiggers3@...il.com,
socketpair@...il.com, penguin-kernel@...ove.SAKURA.ne.jp, w@....eu,
kirill.shutemov@...ux.intel.com, mhocko@...e.com,
vdavydov.dev@...il.com, vdavydov@...tuozzo.com, hannes@...xchg.org,
mhocko@...nel.org, minchan@...nel.org, deepa.kernel@...il.com,
arnd@...db.de, balbi@...nel.org, swhiteho@...hat.com,
konishi.ryusuke@....ntt.co.jp, dsterba@...e.com,
vegard.nossum@...cle.com, axboe@...com, pombredanne@...b.com,
tglx@...utronix.de, joe.lawrence@...hat.com, mpatocka@...hat.com,
mcgrof@...nel.org, keescook@...omium.org,
linux@...inikbrodowski.net, jannh@...gle.com, shakeelb@...gle.com,
guro@...com, willy@...radead.org, khlebnikov@...dex-team.ru,
kirr@...edi.com, stern@...land.harvard.edu, elver@...gle.com,
parri.andrea@...il.com, paulmck@...nel.org, rasibley@...hat.com,
jstancek@...hat.com, avagin@...il.com, cai@...hat.com,
josef@...icpanda.com, hare@...e.de, colyli@...e.de,
johannes@...solutions.net, sspatil@...roid.com, alex_y_xu@...oo.ca,
mgorman@...hsingularity.net, gor@...ux.ibm.com, jhubbard@...dia.com,
andriy.shevchenko@...ux.intel.com, crope@....fi, yzaikin@...gle.com,
bfields@...ldses.org, jlayton@...nel.org, kernel@...force.de,
steve@....org, nixiaoming@...wei.com, 0x7f454c46@...il.com,
kuniyu@...zon.co.jp, alexander.h.duyck@...el.com,
kuni1840@...il.com, soheil@...gle.com, sridhar.samudrala@...el.com,
Vincenzo.Frascino@....com, chuck.lever@...cle.com,
Kevin.Brodsky@....com, Szabolcs.Nagy@....com,
David.Laight@...LAB.com, Mark.Rutland@....com,
linux-morello@...lists.linaro.org, Luca.Vizzarro@....com,
max.kellermann@...os.com, adobriyan@...il.com, lukas@...auer.dev,
j.granados@...sung.com, djwong@...nel.org,
kent.overstreet@...ux.dev, linux@...ssschuh.net,
kstewart@...icios.com
Subject: Re: [RESEND PATCH] fs/pipe: Introduce a check to skip sleeping
processes during pipe read/write
Quite possibly I missed something, but I have some concerns after
a quick glance...
On 12/25, WangYuli wrote:
>
> +config PIPE_SKIP_SLEEPER
> + bool "Skip sleeping processes during pipe read/write"
> + default n
> + help
> + This option introduces a check whether the sleep queue will
> + be awakened during pipe read/write.
> +
> + It often leads to a performance improvement. However, in
> + low-load or single-task scenarios, it may introduce minor
> + performance overhead.
> +
> + If unsure, say N.
> +
Well, IMO the new config option should be avoided for this optimization.
> +static inline bool
> +pipe_check_wq_has_sleeper(struct wait_queue_head *wq_head)
> +{
> + if (IS_ENABLED(CONFIG_PIPE_SKIP_SLEEPER))
> + return wq_has_sleeper(wq_head);
> + else
> + return true;
> +}
I think that another helper makes more sense:
pipe_wake_xxx(wait_queue_head_t wait, flags)
{
if (wq_has_sleeper(wait))
wake_up_interruptible_sync_poll(wait, flags);
}
-------------------------------------------------------------------------------
But either way I am not sure this optimization is 100% correct, see below.
> @@ -377,7 +386,7 @@ pipe_read(struct kiocb *iocb, struct iov_iter *to)
> * _very_ unlikely case that the pipe was full, but we got
> * no data.
> */
> - if (unlikely(was_full))
> + if (unlikely(was_full) && pipe_check_wq_has_sleeper(&pipe->wr_wait))
> wake_up_interruptible_sync_poll(&pipe->wr_wait, EPOLLOUT | EPOLLWRNORM);
OK, at first glance this can't race with wait_event_xxx(wr_wait, pipe_writable),
wq_has_sleeper() and prepare_to_wait_event() have the necessary barriers.
But what about pipe_poll() ?
To oversimplify, pipe_poll(FMODE_WRITE) does
// poll_wait()
__pollwait() -> add_wait_queue(pipe->wr_wait) -> list_add()
check pipe_full()
and I don't see the (in theory) necessary barrier between list_add()
and LOAD(pipe->head/tail).
Oleg.
Powered by blists - more mailing lists