Re: [RFC PATCH 1/6] bsg: fix kernel panic resulting from missing allocation of a reply-buffer

2017-08-14 Thread Benjamin Block
On Sun, Aug 13, 2017 at 04:39:40PM +0200, Christoph Hellwig wrote: > On Fri, Aug 11, 2017 at 06:01:42PM +0200, Benjamin Block wrote: > > When the BSG interface is used with bsg-lib, and the user sends a > > Bidirectional command - so when he gives an input- and output-buffer > > (most users of our

Re: [RFC PATCH 1/6] bsg: fix kernel panic resulting from missing allocation of a reply-buffer

2017-08-14 Thread Benjamin Block
Hey Christoph, I looked over the patch in detail, see below. > From f5b03b82df0569c035022c1c2535696186907f1a Mon Sep 17 00:00:00 2001 > From: Christoph Hellwig > Date: Fri, 11 Aug 2017 11:03:29 +0200 > Subject: bsg-lib: allocate sense data for each request > > Since we split the

Re: [RFC PATCH 1/6] bsg: fix kernel panic resulting from missing allocation of a reply-buffer

2017-08-11 Thread Christoph Hellwig
On Fri, Aug 11, 2017 at 03:49:29PM +0200, Benjamin Block wrote: > On Fri, Aug 11, 2017 at 11:14:15AM +0200, Christoph Hellwig wrote: > > But patch 1 still creates an additional copy of the sense data for > > all bsg users. > > > > Huh? What additional copy? There is one reply-buffer and that is

Re: [RFC PATCH 1/6] bsg: fix kernel panic resulting from missing allocation of a reply-buffer

2017-08-11 Thread Benjamin Block
On Fri, Aug 11, 2017 at 11:14:15AM +0200, Christoph Hellwig wrote: > But patch 1 still creates an additional copy of the sense data for > all bsg users. > Huh? What additional copy? There is one reply-buffer and that is copied into the user-buffer should it contain valid data. Just like in your

Re: [RFC PATCH 1/6] bsg: fix kernel panic resulting from missing allocation of a reply-buffer

2017-08-11 Thread Christoph Hellwig
But patch 1 still creates an additional copy of the sense data for all bsg users. Can you test the patch below which implements my suggestion? Your other patches should still apply fine on top modulo minor context changes. --- >From 4cd32ee48e334b62b55bff0d380833b978454040 Mon Sep 17 00:00:00

Re: [RFC PATCH 1/6] bsg: fix kernel panic resulting from missing allocation of a reply-buffer

2017-08-11 Thread Christoph Hellwig
My point was that we now gurantee that that the sense data is not a stack pointer an a driver can DMA to it. Now for BSG the sense data is "just" abused as reply, but the point still stands - we don't want to pass a possible stack pointer to drivers in a data buffer because we want to allow DMA

Re: [RFC PATCH 1/6] bsg: fix kernel panic resulting from missing allocation of a reply-buffer

2017-08-10 Thread Benjamin Block
On Fri, Aug 11, 2017 at 12:10:38AM +0200, Benjamin Block wrote: > On Thu, Aug 10, 2017 at 11:32:17AM +0200, Christoph Hellwig wrote: > > We can't use an on-stack buffer for the sense data, as drivers will > > dma to it. So we should reuse the SCSI init_rq_fn() for the BSG > > queues and/or

Re: [RFC PATCH 1/6] bsg: fix kernel panic resulting from missing allocation of a reply-buffer

2017-08-10 Thread Christoph Hellwig
We can't use an on-stack buffer for the sense data, as drivers will dma to it. So we should reuse the SCSI init_rq_fn() for the BSG queues and/or implement the same scheme.

[RFC PATCH 1/6] bsg: fix kernel panic resulting from missing allocation of a reply-buffer

2017-08-09 Thread Benjamin Block
In contrast to the normal SCSI-lib, the BSG block-queue doesn't make use of any extra init_rq_fn() to make additional allocations during request-creation, and the request sense-pointer is not used to transport SCSI sense data, but is used as backing for the bsg_job->reply pointer; that in turn is