linux-kernel - Re: Recent removal of bsg read/write support

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]

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