linux-kernel - Re: linux-next: build failure after merge of the driver-core tree

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:	Wed, 17 Mar 2010 08:51:49 -0700 (PDT)
From:	Sage Weil <sage@...dream.net>
To:	Neil Brown <neilb@...e.de>
cc:	Stephen Rothwell <sfr@...b.auug.org.au>, Greg KH <greg@...ah.com>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: linux-next: build failure after merge of the driver-core tree

On Wed, 17 Mar 2010, Neil Brown wrote:

> On Wed, 17 Mar 2010 15:41:45 +1100
> Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> 
> > Hi Greg,
> > 
> > After merging the driver-core tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > fs/ceph/msgpool.c: In function 'ceph_msgpool_put':
> > fs/ceph/msgpool.c:173: error: implicit declaration of function 'kref_set'
> > 
> > Caused by commit 10c5d9fdc9ba89606b34f01cbe6ea287abba7395 ("kref: remove
> > kref_set") from the driver-core tree interacting with commit
> > c2e552e76e2c6907ca50cd9a4b747a2e2e8c615e ("ceph: use kref for ceph_msg")
> > from the ceph tree.
> > 
> > I applied the following patch for today (which may not be correct):
> 
> I would say this is correct.

Yeah, the fix is good, thanks Stephen!  I'll add it to my tree shortly.

> It is a pity that this code cannot use mempool_t....
> What if mempool_t were changed to only re-alloc the vector of pointers when
> it grew, or when it shrank to less than 1/2 it's current size.  Would that
> reduce the frequency of allocations enough for you to be comfortable with it? 
> i.e. always make the vector a power-of-2 size (which is what is probably
> allocated anyway) while the pool size might be less.
> ??

That would improve the situation, but still mean potentially large 
allocations (the pools can grow pretty big) that aren't strictly 
necessary.  I can imagine a more modular mempool_t with an ops vector for 
adding/removing from the pool to cope with situations like this, but I'm 
not sure it's worth the effort?

sage
--
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/