linux-kernel - Re: IO errors after "block: remove bio_get_nr

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: <524c6867be3fcf2e19d071599d4722cc@lycos.com>
Date:	Mon, 21 Dec 2015 04:49:46 +0500
From:	"Artem S. Tashkinov" <t.artem@...os.com>
To:	Kent Overstreet <kent.overstreet@...il.com>
Cc:	Christoph Hellwig <hch@....de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ming Lin <ming.l@....samsung.com>, Jens Axboe <axboe@...com>,
	"Artem S. Tashkinov" <t.artem@...lcity.com>,
	Steven Whitehouse <swhiteho@...hat.com>,
	Tejun Heo <tj@...nel.org>, IDE-ML <linux-ide@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: IO errors after "block: remove bio_get_nr_vecs()"

On 2015-12-21 04:42, Kent Overstreet wrote:
> On Mon, Dec 21, 2015 at 04:25:12AM +0500, Artem S. Tashkinov wrote:
>> On 2015-12-20 23:18, Christoph Hellwig wrote:
>> >On Sun, Dec 20, 2015 at 09:51:14AM -0800, Linus Torvalds wrote:
>> >>Kent, Jens, Christoph et al,
>> >> please see this bugzilla:
>> >>
>> >>  https://bugzilla.kernel.org/show_bug.cgi?id=109661
>> >>
>> >>where Artem Tashkinov bisected his problems with 4.3 down to commit
>> >>b54ffb73cadc ("block: remove bio_get_nr_vecs()") that you've all
>> >>signed off on.
>> >
>> >Artem,
>> >
>> >can you re-check the commits around this series again?  I would be
>> >extremtly surprised if it's really this particular commit and not
>> >one just before it causing the problem - it just allocates bios
>> >to the biggest possible instead of only allocating up to what
>> >bio_add_page would accept.
>> 
>> I'm positive about this particular commit. Of course, it might be 
>> another
>> GCC 4.7.4 miscompilation which causes the errors which shouldn't be 
>> there
>> but
>> I'm not an expert, so.
> 
> I believe you on the commit, and I doubt this has anything to do with 
> gcc - the
> errors you're getting are exactly what you normally get when you send 
> the device
> an sglist to dma to/from that it doesn't like.
> 
> The queue limits stuff is annoyingly fragile, you'd think we'd be able 
> to check
> directly in the driver that the stuff we're sending the device is sane 
> but we
> don't.
> 
> If I came up with a debug patch could you try it out? I don't have any 
> ideas for
> one yet, but if someone who knows the ATA code doesn't jump in I'll 
> call up
> Tejun and make him walk me through it.

No problem, I just hope that this particular access mode (and you debug 
patch) won't decrease the lifespan of my HDD. Seagate HDDs have been 
very fragile (read atrociously unreliable) for the past five years.
--
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/