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: <20071018.050327.59654383.davem@davemloft.net>
Date:	Thu, 18 Oct 2007 05:03:27 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jens.axboe@...cle.com
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

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.

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 :-)

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