linux-kernel - Re: [bug] block subsystem related crash with latest -git

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: <20071018122852.GA5063@kernel.dk>
Date:	Thu, 18 Oct 2007 14:28:52 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	David Miller <davem@...emloft.net>
Cc:	bhalevy@...asas.com, torvalds@...ux-foundation.org, mingo@...e.hu,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: [bug] block subsystem related crash with latest -git

On Thu, Oct 18 2007, David Miller wrote:
> From: Jens Axboe <jens.axboe@...cle.com>
> Date: Thu, 18 Oct 2007 12:55:17 +0200
> 
> > Things have progressed a lot since, see my recent posting based on
> > Davem's proposal. Will post another patch soonish, that is also
> > tested.
> 
> One core issue here is that we need to decide whether this thing to be
> iterated like an array or like a linked list.  It's trying to be both.
> 
> If we decide upon a looping construct for consumers and stick to it,
> we'll be in much better shape than we are now and bugs will be eaiser
> to spot.  It would be so much simpler to audit if all we saw in the
> consumers were things like:
> 
> 	while (sg) {
> 		do_stuff(sg);
> 		sg = sg_next(sg);
> 	}
> 
> I would suggest that we just get it over with and convert the whole
> tree now rather than trying to do this kind of thing in stages.
> Because then we can say that ever scatterlist creator has to set
> the "end" bit and therefore you use well established patterns
> for scatterlist iteration such as "traverse sg_next() until NULL"
> as shown above.

The above should work now, PROVIDED that the end has been marked
properly. I have added some helpers to init an sglist (or sg entry).
You can still use

        for_each_sg()

and pass in the number of entries, that'll work even with an end marker.
So, it does both.

> I also noticed that there is the issue of on-stack and embedded
> scatterlist users.  We'll need some sort of "DECLARE_SCATTERLIST"
> and a "scatterlist_init()" thing so that we can keep DEBUG_SG
> working even in those cases.  But for all I know Jens could be
> working on that already :-)

Heh, got some of it covered! The stack usage is generally just converted
to either use sg_init_one() if we can, or sg_init_table(). Adding some
soft of DECLARE_SCATTERLIST() sounds like a good idea, though. I'll take
patches :-)

> The only other real option if we don't convert the whole tree now to
> the "end" marker stuff, is to enforce that every scatterlist iterator
> only traverse the number of entries there were told are in the one
> given to them.

Driver that do all their own sg management typically still use a manual
loop over the number of entries they know are there. I didn't change
those, and the original sg chaining didn't convert those either. Some
manual labor is required in utilizing chained sg lists, unless you are
part of a subsystem (like SCSI) that allocates and inits themf or you.
So I still think that baby steps are a good idea - only convert things
that matter. Leave the rest to janitors or others willing to dive in.

-- 
Jens Axboe

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