On Tue, Jun 7, 2016 at 3:18 PM, Larry Finger wrote:
> On 06/07/2016 04:39 AM, Catalin Marinas wrote:
>>
>> On Mon, Jun 06, 2016 at 12:09:49PM -0500, Shaun Tancheff wrote:
>>>
>>> I'm pretty sure it is missing a bio_put() after submit_bio_wait().
>>>
>>> Please excuse the hack-y patch but I think y
On 06/07/2016 04:39 AM, Catalin Marinas wrote:
On Mon, Jun 06, 2016 at 12:09:49PM -0500, Shaun Tancheff wrote:
I'm pretty sure it is missing a bio_put() after submit_bio_wait().
Please excuse the hack-y patch but I think you need to do something
like this ...
(Note tabs eaten by gmail).
diff -
On Mon, Jun 06, 2016 at 12:09:49PM -0500, Shaun Tancheff wrote:
> I'm pretty sure it is missing a bio_put() after submit_bio_wait().
>
> Please excuse the hack-y patch but I think you need to do something
> like this ...
> (Note tabs eaten by gmail).
>
> diff --git a/block/blk-lib.c b/block/blk-l
On Mon, Jun 06, 2016 at 11:06:05PM -0500, Larry Finger wrote:
> The leak is definitely not related to mkfs. At the moment, my system has
> been up about 26 hours, and has generated 162 of these leaks without ever
> doing a single mkfs. In addition, the box say idle for almost 12 of those
> hours
On 06/06/2016 11:12 AM, Catalin Marinas wrote:
On Mon, Jun 06, 2016 at 04:13:34PM +0200, Christoph Hellwig wrote:
I've got a few reports of this over the weekend, but it still doesn't
make much sense to me.
Could it be that kmemleak can't deal with the bio_batch logic? I've
tried to look at th
On 06/06/2016 11:27 AM, Christoph Hellwig wrote:
On Mon, Jun 06, 2016 at 12:09:49PM -0500, Shaun Tancheff wrote:
I'm pretty sure it is missing a bio_put() after submit_bio_wait().
Please excuse the hack-y patch but I think you need to do something
like this ...
(Note tabs eaten by gmail).
Yea
On Mon, Jun 06, 2016 at 07:27:18PM +0200, Christoph Hellwig wrote:
> On Mon, Jun 06, 2016 at 12:09:49PM -0500, Shaun Tancheff wrote:
> > I'm pretty sure it is missing a bio_put() after submit_bio_wait().
> >
> > Please excuse the hack-y patch but I think you need to do something
> > like this ...
On Mon, Jun 06, 2016 at 12:09:49PM -0500, Shaun Tancheff wrote:
> I'm pretty sure it is missing a bio_put() after submit_bio_wait().
>
> Please excuse the hack-y patch but I think you need to do something
> like this ...
> (Note tabs eaten by gmail).
Yeah, that makes sense - oddly enough submit_b
On Mon, Jun 6, 2016 at 11:12 AM, Catalin Marinas
wrote:
>
> On Mon, Jun 06, 2016 at 04:13:34PM +0200, Christoph Hellwig wrote:
> > I've got a few reports of this over the weekend, but it still doesn't
> > make much sense to me.
> >
> > Could it be that kmemleak can't deal with the bio_batch logic?
On Mon, Jun 06, 2016 at 04:13:34PM +0200, Christoph Hellwig wrote:
> I've got a few reports of this over the weekend, but it still doesn't
> make much sense to me.
>
> Could it be that kmemleak can't deal with the bio_batch logic? I've
> tried to look at the various bio and biovec number entries
Hi Catalin,
I've got a few reports of this over the weekend, but it still doesn't
make much sense to me.
Could it be that kmemleak can't deal with the bio_batch logic? I've
tried to look at the various bio and biovec number entries in
/proc/slabinfo, and while they keep changing a bit during the
Hi Christoph,
I tried enabling kmemleak on 4.7-rc2 on an x86 host (macbook pro running
Debian sid) and I get some kmemleak reports every few minutes coming
from the block layer. Reverting commit 9082e87bfbf8 ("block: remove
struct bio_batch") makes them go away:
unreferenced object 0x88007785
12 matches
Mail list logo
