[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181005223526.GF13613@kroah.com>
Date: Fri, 5 Oct 2018 15:35:26 -0700
From: Greg KH <gregkh@...uxfoundation.org>
To: Dror Levin <drorl@...inidat.com>
Cc: torvalds@...ux-foundation.org,
Richard Weinberger <richard.weinberger@...il.com>,
linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
linux-scsi@...r.kernel.org, hch@...radead.org, axboe@...nel.dk
Subject: Re: Recent removal of bsg read/write support
On Thu, Oct 04, 2018 at 09:58:37AM +0300, Dror Levin wrote:
> CC'ing Greg.
>
> On Mon, Sep 3, 2018 at 11:34 AM Dror Levin <drorl@...inidat.com> wrote:
> >
> > On Sun, Sep 2, 2018 at 8:55 PM Linus Torvalds
> > <torvalds@...ux-foundation.org> wrote:
> > >
> > > On Sun, Sep 2, 2018 at 4:44 AM Richard Weinberger
> > > <richard.weinberger@...il.com> wrote:
> > > >
> > > > CC'ing relevant people. Otherwise your mail might get lost.
> > >
> > > Indeed.
> >
> > Sorry for that.
> >
> > > > On Sun, Sep 2, 2018 at 1:37 PM Dror Levin <drorl@...inidat.com> wrote:
> > > > >
> > > > > We have an internal tool that uses the bsg read/write interface to
> > > > > issue SCSI commands as part of a test suite for a storage device.
> > > > >
> > > > > After recently reading on LWN that this interface is to be removed we
> > > > > tried porting our code to use sg instead. However, that raises new
> > > > > issues - mainly getting ENOMEM over iSCSI for unknown reasons.
> > >
> > > Is there any chance that you can make more data available?
> >
> > Sure, I can try.
> >
> > We use writev() to send up to SG_MAX_QUEUE tasks at a time. Occasionally not
> > all tasks are written at which point we wait for tasks to return before
> > sending more, but then writev() fails with ENOMEM and we see this in the syslog:
> >
> > Sep 1 20:58:14 gdc-qa-io-017 kernel: sd 441:0:0:5: [sg73]
> > sg_common_write: start_req err=-12
> >
> > Failing tasks are reads of 128KiB.
> >
> > > I'd rather fix the sg interface (which while also broken garbage, we
> > > can't get rid of) than re-surrect the bsg interface.
>
> Discussion seems to have died down but release of 4.19 is drawing near.
>
> Is there still any chance removal of bsg can be reconsidered? Maybe
> postponed to the
> next version to allow more time to adjust?
>
> I'm especially concerned about the possibility of this being
> backported to stable kernels
> which might leave us very little time to fix our code.
What is being backported to what stable kernels and why?
Is there sg patches?
totally confused,
greg k-h
Powered by blists - more mailing lists