linux-kernel - Re: [PATCHv6 00/15] kill unnecessary bdi wakeups + cleanups

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]

Date:	Tue, 03 Aug 2010 17:11:21 +0300
From:	Artem Bityutskiy <dedekind1@...il.com>
To:	Jens Axboe <axboe@...nel.dk>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCHv6 00/15] kill unnecessary bdi wakeups + cleanups

On Tue, 2010-08-03 at 14:27 +0200, Jens Axboe wrote:
> On 2010-07-25 13:29, Artem Bityutskiy wrote:
> > Hi,
> > 
> > here is v6 of the patch series which clean-ups bdi threads and substantially
> > lessens amount of unnecessary kernel wake-ups, which is very important on
> > battery-powered devices.
> > 
> > This patch-set is also available at:
> > git://git.infradead.org/users/dedekind/misc-2.6.git flushers_v6
> 
> Thanks Artem, for sticking around long enough to get this into
> shape. I have finally merged it.
> 
> > 1. Use 'spin_lock_bh' for the 'bdi->wb_lock' (changed patch N12)
> 
> I'd rather not, question is how to avoid it. Either just wakeup the
> default thread, or punt the lock-and-check bdi->wb.task to a thread.

Jens, here are my quick thoughts, will come back to this tomorrow.

The spin_lock_bh(&bdi->wb_lock) in 'wakeup_timer_fn()' is needed:

a) to make sure the forker thread does not decide to kill the bdi
   thread at the same time, which could cause an oops on
   'wake_up_process(bdi->wb.task)'.
b) to make sure the forker thread does not decide to spawn a bdi thread
   at the same time, in which case we could lose a wake-up.

I without the "_bh" suffix lockdep complains with a warning. Cannot cite
the complained, but it is a fair warning about a possible deadlock if
the timer function interrupts the CPU while it is already holding the
spinlock, or something like that. The easiest way to address it was to
use "_bh".

The only way to avoid "_bh" I see right now is to not 'bdi->wb_lock' at
all in  'wakeup_timer_fn()'. In this case we cannot touch 'bdi->wb.task'
because it can become NULL at any point of time.

Your first suggestion ("just wakeup the default thread") will work only
if we add a new BDI_wakeup_thread or something like that. Not sure it is
worth it.

The second suggestion ("punt the lock-and-check bdi->wb.task to a
thread") is vague. "A thread" - this must be the forker thread, what
else could that be? So basically this is the same as the first
suggestion - we set a flag in 'bdi->wb.state' and wake up the forker,
which should wake up the bdi thread?

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/