linux-kernel - Re: linux-next: Tree for July 16 (crash on quad core AMD)

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: <20080719004736.626ef169@mjolnir.drzeus.cx>
Date:	Sat, 19 Jul 2008 00:47:36 +0200
From:	Pierre Ossman <drzeus@...eus.cx>
To:	Tejun Heo <htejun@...il.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	scsi <linux-scsi@...r.kernel.org>,
	Jens Axboe <jens.axboe@...cle.com>,
	linux-ide <linux-ide@...r.kernel.org>,
	Jeff Garzik <jeff@...zik.org>, Takashi Iwai <tiwai@...e.de>,
	tino.keitel@....de
Subject: Re: linux-next: Tree for July 16 (crash on quad core AMD)

On Fri, 18 Jul 2008 21:38:56 +0900
Tejun Heo <htejun@...il.com> wrote:

> 
> The offending commit was 83e7d317cef3ee624886f128401a72e414c0a99d
> which implements sg iterator but it forgot to add offset to the
> kmapped address and copy goes out of bounds.  Takashi, this could also
> be the problem you were seeing if you don't have slab debugging turned
> on.
> 

Oops, sorry. This thing wasn't supposed to go out and mess with anyone
else's tree quite yet. I'll make sure to clean out my -next tree right
away.

> The implemented iterator didn't look too pretty and the usage was
> quite awkward involving a callback and end condition check distributed
> between the callback and the outer user who runs the loop.  For
> copying, end of buffer condition was tested by testing whether the
> callback returned 0 copied bytes for the iteration but AFAIK there's
> no restriction against zero length sg entry in the middle and it will
> terminate the copying prematurely.
> 
> So, I implemented slightly different version which follows below.
> 

I just have one objection to your version, and that is that it cannot
be used to nibble away at the sg list. The _next() call jumps an entire
page, whereas you sometimes need to consume that page in two different
sweeps. This could be handled by some external buffer that keeps the
remainder of the page, but the point of these functions was to keep
things simple for the callers.

Rgds
-- 
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)