linux-kernel - RE: [PATCH 02/10] zcache: fix refcount leak

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]

Message-ID: <db70ea46-7e43-4795-a399-c3220cda0a46@default>
Date:	Wed, 20 Jun 2012 15:25:52 -0700 (PDT)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	Xiao Guangrong <xiaoguangrong@...ux.vnet.ibm.com>
Cc:	Seth Jennings <sjenning@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
	Konrad Wilk <konrad.wilk@...cle.com>,
	Nitin Gupta <ngupta@...are.org>
Subject: RE: [PATCH 02/10] zcache: fix refcount leak

> From: Xiao Guangrong [mailto:xiaoguangrong@...ux.vnet.ibm.com]
> Subject: Re: [PATCH 02/10] zcache: fix refcount leak
> 
> On 06/20/2012 10:54 AM, Xiao Guangrong wrote:
> 
> > On 06/20/2012 04:06 AM, Seth Jennings wrote:
> >
> >> On 06/19/2012 02:49 PM, Dan Magenheimer wrote:
> >>
> >>> My preference would be to fix it the opposite way, by
> >>> checking and ignoring zcache_host in zcache_put_pool.
> >>> The ref-counting is to ensure that a client isn't
> >>> accidentally destroyed while in use (for multiple-client
> >>> users such as ramster and kvm) and since zcache_host is a static
> >>> struct, it should never be deleted so need not be ref-counted.
> >>
> >>
> >> If we do that, we'll need to comment it.  If we don't, it won't be
> >> obvious why we are refcounting every zcache client except one.  It'll
> >> look like a bug.
> >
> >
> > Okay, i will fix it like Dan's way and comment it.
> 
> Hmm...But i notice that zcache_host is the same as other clients, all
> of them are static struct:
> 
> | static struct zcache_client zcache_host;
> | static struct zcache_client zcache_clients[MAX_CLIENTS];
> 
> And all of them are not destroyed.

Yes, the code currently in zcache was a first step towards
supporting multiple clients.  Ramster goes one step further
and kvm will require even a tiny bit more work.

FYI, I'm working on a unification version of zcache that can support
all of these cleanly as well as better support for eviction
that will make standalone zcache more suitable for promotion from
staging and enterprise-ready.  Due to various summer commitments,
it will probably be a few weeks before it is ready for posting.

Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/