netdev - Re: [PATCH 8/8] dm-verity: Convert from tasklet to BH workqueue

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: <Zbq8cE3Y2ZL6dl8r@slm.duckdns.org>
Date: Wed, 31 Jan 2024 11:32:32 -1000
From: Tejun Heo <tj@...nel.org>
To: Mikulas Patocka <mpatocka@...hat.com>
Cc: torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	dm-devel@...ts.linux.dev, msnitzer@...hat.com, ignat@...udflare.com,
	damien.lemoal@....com, bob.liu@...cle.com, houtao1@...wei.com,
	peterz@...radead.org, mingo@...nel.org, netdev@...r.kernel.org,
	allen.lkml@...il.com, kernel-team@...a.com,
	Alasdair Kergon <agk@...hat.com>, Mike Snitzer <snitzer@...nel.org>
Subject: Re: [PATCH 8/8] dm-verity: Convert from tasklet to BH workqueue

Hello,

On Wed, Jan 31, 2024 at 10:19:07PM +0100, Mikulas Patocka wrote:
> > @@ -83,7 +83,7 @@ struct dm_verity_io {
> >  	struct bvec_iter iter;
> >  
> >  	struct work_struct work;
> > -	struct tasklet_struct tasklet;
> > +	struct work_struct bh_work;
> >  
> >  	/*
> >  	 * Three variably-size fields follow this struct:
> 
> Do we really need two separate work_structs here? They are never submitted 
> concurrently, so I think that one would be enough. Or, am I missing 
> something?

I don't know, so just did the dumb thing. If the caller always guarantees
that the work items are never queued at the same time, reusing is fine.
However, the followings might be useful to keep on mind:

- work_struct is pretty small - 4 pointers.

- INIT_WORK() on a queued work item isn't gonna be pretty.

- Flushing and no-concurrent-execution guarantee are broken on INIT_WORK().
  e.g. If you queue_work(), INIT_WORK(), flush_work(), the flush isn't
  actually going to wait for the work item to finish. Also, if you do
  queue_work(), INIT_WORK(), queue_work(), the two queued work item
  instances may end up running concurrently.

Muxing a single work item carries more risks of subtle bugs, but in some
cases, the way it's used is clear (e.g. sequential chaining) and that's
fine.

Thanks.

-- 
tejun