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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170628185235.GA13126@lst.de>
Date:   Wed, 28 Jun 2017 20:52:35 +0200
From:   Christoph Hellwig <hch@....de>
To:     Jens Axboe <axboe@...com>
Cc:     Christoph Hellwig <hch@....de>,
        Keith Busch <keith.busch@...el.com>,
        wenxiong@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
        bjking@...ux.vnet.ibm.com
Subject: Re: [PATCH] fs: System memory leak when running HTX with T10 DIF
        enabled

On Wed, Jun 28, 2017 at 12:44:00PM -0600, Jens Axboe wrote:
> On 06/28/2017 12:38 PM, Christoph Hellwig wrote:
> > On Wed, Jun 28, 2017 at 12:34:15PM -0600, Jens Axboe wrote:
> >> That's what I sent out.
> > 
> > Where?  Didn't see that anywhere..
> 
> Looks like you weren't CC'ed on the original thread. About an hour ago.
> 
> >> Here it is again. We should get this into 4.12,
> >> so would be great with a review or two.
> > 
> > Can we rename __bio_free to bio_uninit and add a comment to bio_init
> > that it must be paried with bio_uninit?
> 
> Let's keep it small for 4.12. We can do a cleanup on top of this for
> 4.13.

The rename is two additional lines for the patch, it's not going to
make a difference..

> > Except for that this looks fine, although there are a lot more callers
> > that should get this treatment..
> 
> Should only be an issue for on-stack bio's, since we don't go through
> the put/free path. Did a quick grep, looks like this is one of 3. One
> is floppy, which probably neither has DIF or uses blk-throttle. Then
> there's one in dm-bufio, didn't look too closely at that. Last one is
> this one.

Well, it's really all callers but bio_alloc_bioset itself that
will need this handling, as only bios that come from bio_alloc_bioset
will be freed through bio_free.  Most of them probably don't
support DIF, but they'll also miss the bio_disassociate_task call
this way, and will leak I/O context and css references if block
cgroup support is enabled.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ