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, 6 Oct 2015 09:28:20 -0400 (EDT)
From:	Mikulas Patocka <mpatocka@...hat.com>
To:	Mike Snitzer <snitzer@...hat.com>
cc:	Jens Axboe <axboe@...nel.dk>, Kent Overstreet <kmo@...erainc.com>,
	"Alasdair G. Kergon" <agk@...hat.com>,
	linux-kernel@...r.kernel.org, dm-devel@...hat.com
Subject: Re: block: flush queued bios when the process blocks



On Mon, 5 Oct 2015, Mike Snitzer wrote:

> Mikulas,
> 
> Could it be that cond_resched() wasn't unplugging?  As was
> recently raised in this thread: https://lkml.org/lkml/2015/9/18/378
> Chris Mason's patch from that thread fixed this	issue... I _think_ Linus
> has since committed Chris' work but I haven't kept my finger on the
> pulse of that issue.

I think it doesn't matter (regarding correctness) if cond_reched unplugs 
on not. If it didn't unplug, the process will be scheduled later, and it 
will eventually reach the point where it unplugs.

> FYI, I've put rebased versions of your 2 patches in my wip branch, see:
> http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/log/?h=wip
> 
> I tweaked the 2nd patch that adds bio_list to plug so that
> generic_make_request's checks for in_generic_make_request isn't racey
> (your original patch could happen to have current-plug set but
> in_generic_make_request not yet set).

I don't recommend that second patch 
(http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/commit/?h=wip&id=5e740c2e45a767d8d6ef8ca36b0db705ef6259c4). 
The patch just complicates things without adding any value. It's also not 
correct because it plugs bios at places when bios aren't supposed to be 
plugged

> Anyway, I'm just dusting off your earlier work and seeing if I can make
> sense of a way forward that meets Jens' approval.  Jens, if adding a
> bio_list to struct blk_plug isn't what you were after either please be
> more specific on what you would like to see...
> 
> Thanks,
> Mike

Mikulas
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ