linux-kernel - Re: [PATCH] reiserfs: don't use congestion

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: <20211213135930.GC14044@quack2.suse.cz>
Date:   Mon, 13 Dec 2021 14:59:30 +0100
From:   Jan Kara <jack@...e.cz>
To:     NeilBrown <neilb@...e.de>
Cc:     Jan Kara <jack@...e.cz>, Jens Axboe <axboe@...nel.dk>,
        reiserfs-devel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] reiserfs: don't use congestion_wait()

On Fri 10-12-21 15:27:44, NeilBrown wrote:
> On Thu, 18 Nov 2021, Jan Kara wrote:
> > On Wed 17-11-21 15:34:42, NeilBrown wrote:
> > > 
> > > Block devices do not, in general, report congestion any more, so this
> > > congestion_wait() is effectively just a sleep.
> > > 
> > > It isn't entirely clear what is being waited for, but as we only wait
> > > when j_async_throttle is elevated, it seems reasonable to stop waiting
> > > when j_async_throttle becomes zero - or after the same timeout.
> > > 
> > > So change to use wait_event_event_timeout() for waiting, and
> > > wake_up_var() to signal an end to waiting.
> > > 
> > > Signed-off-by: NeilBrown <neilb@...e.de>
> > > ---
> > > 
> > > I have no idea who might take this.... Jens and Jan have both landed
> > > reiserfs patches recently...
> > 
> > Yeah, I guess I can take this one. Honestly the whole code around
> > j_async_throttle looks a bit suspicious but your patch does not make it
> > worse so it looks safe to me :).
> 
> Hi,
>  I don't see this in linux-next.  Should I ??

No, my fault. I'm sorry. I didn't push out the resulting branch. Fixed now.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR