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  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:   Sun, 13 Aug 2017 16:39:40 +0200
From:   Christoph Hellwig <>
To:     Benjamin Block <>
Cc:     Christoph Hellwig <>,
        "James E . J . Bottomley" <>,
        "Martin K . Petersen" <>,
        Jens Axboe <>,,,,
        Johannes Thumshirn <>,
        Steffen Maier <>,
Subject: Re: [RFC PATCH 1/6] bsg: fix kernel panic resulting from missing
        allocation of a reply-buffer

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 interface will likely do that, if they wanna get the
> transport-level response data) - bsg will allocate two requests from the
> queue. The first request's bio is used to map the input and the second
> request's bio for the output (see bsg_map_hdr() in the if-statement with
> (op == REQ_OP_SCSI_OUT && hdr->din_xfer_len)).
> When we now allocate the full space of bsg_job, sense, dd_data for each
> request, these will be wasted on the (linked) second request. They will
> go unused all the time, as only the first request's bsg_job, sense and
> dd_data is used by the LLDs and BSG itself.
> Right now, because we don't allocate this on each request, those spaces
> are only allocated for the first request in bsg-lib.
> Maybe we can ignore this, if it gets to complicated, I don't wanne
> prolong this unnecessary.

We have the same 'issue' with bidirection scsi commands - it's a side
effect of having two request structures for these commands, and the
only real fix would be to have a single request structure, which would
be nice especially if we can't do it without growing struct request.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux - Powered by OpenVZ