Re: [PATCH] st: don't doublefree pages from scatterlist

[Hugh Dickins <hugh@veritas.com>]

On Fri, 3 Feb 2006, Mike Christie wrote:
> Hugh Dickins wrote:
> > On some architectures, mapping the scatterlist may coalesce entries:
> > if that coalesced list is then used for freeing the pages afterwards,
> > there's a danger that pages may be doubly freed (and others leaked).
> > 
> > Fix SCSI Tape's sgl_unmap_user_pages by freeing from the pagelist used
> > in sgl_map_user_pages.  Fixes Ryan Richter's crash on x86_64, with Bad
> > page state mapcount 2 from sgl_unmap_user_pages, and consequent mayhem.
> 
> Is this crash occuring with 2.6.16-rc1?

I do believe 2.6.15 is the latest release that Ryan has tried (and,
strangely, nobody else has ever reported it - identifiably, anyway).
Interested in trying unpatched 2.6.16-rc2, Ryan?

> I ask becuase in that kernel the scatterlist passed into scsi_execute_async
> 
> if (scsi_execute_async(STp->device, cmd, direction,
> &((STp->buffer)->sg[0]), bytes,
> 
> is not the same one that gets send down to the device/HBA.

Wow, great info, thanks.

> scsi_execute_async takes the scatterlist passed to it from st or sg, uses it
> as a hint to build a request + bios, then later when the request is sent to
> the device a new scatterlist is sent to the device and the device does the
> pci/dma operation on that scatterlist from the block/scsi layer.

Very interesting.  James can confirm, but I think that means everybody
can ignore my drivers/scsi/st.c patch for 2.6.16-rc, and the unposted
sg.c patches for the same issue that I was going to send Doug.

But the Infiniband, ipr and osst patches still look to be necessary -
unless maintainers can point to a similar intervening layer.

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/