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: <20150911214315.GA26995@redhat.com>
Date:	Fri, 11 Sep 2015 17:43:15 -0400
From:	Mike Snitzer <snitzer@...hat.com>
To:	Josh Boyer <jwboyer@...oraproject.org>
Cc:	ejt@...hat.com, Ming Lei <ming.lei@...onical.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Tejun Heo <tj@...nel.org>, Jens Axboe <axboe@...com>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	mlin@...nel.org, awilliam@...hat.com
Subject: 32-bit bio regression with 4.3 [was: Re: cgroup/loop Bad page state
 oops in Linux v4.2-rc3-136-g45b4b782e848]

Ming, Jens, others:

Please see this BZ comment that speaks to a 4.3 regression due to the
late bio splitting changes:
https://bugzilla.redhat.com/show_bug.cgi?id=1247382#c41

But inlined here so we can continue on list:
(In reply to Josh Boyer from comment #40)
> The function that was fixed in 4.2 doesn't exist any longer in
> 4.3.0-0.rc0.git6.1.fc24.  That kernel corresponds to Linux
> v4.2-6105-gdd5cdb48edfd which contains commit
> 8ae126660fddbeebb9251a174e6fa45b6ad8f932, which removed it completely.  So
> whatever fix was made in dm_merge_bvec doesn't seem to have made it to
> whatever replaced it.

The dm core fix to dm_merge_bvec was commit bd4aaf8f9b ("dm: fix
dm_merge_bvec regression on 32 bit systems").  But I'm not sure there is
a clear equivalent in the late bio splitting code that replaced block
core's merge_bvec logic.

merge_bvec was all about limiting bios (by asking "can/should this page
be added to this bio?") whereas the late bio splitting is more "build
the bios as large as possible and worry about splitting later".

Regardless, this regression needs to be reported to Ming Lin
<ming.l@....samsung.com>, Jens Axboe and the others involved in
maintaining the late bio splitting changes in block core.

Josh and/or Adam: it would _really_ help if the regression test you guys
are using could be handed-over and/or explained to us.  Is it as simple
as loading a 32bit with a particular config?  Can you share the guest
image if it is small enough?

Mike
--
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