Hi Jens,
Today's linux-next build (x86_64 allmodconfig) failed like this:
block/built-in.o: In function `blkiocg_destroy':
blk-cgroup.c:(.text+0x1bd48): undefined reference to `cfq_unlink_blkio_group'
block/built-in.o: In function `blkiocg_weight_write':
blk-cgroup.c:(.text+0x1c0d2): undefined reference to `cfq_update_blkio_group_weight'
Caused by commits b1c3576961847da26c91b1e97f226bb66be5fa3f ("blkio: Take
care of cgroup deletion and cfq group reference counting") and
f8d461d692c341add957fb973fb5ee1f62039dc7 ("blkio: Propagate cgroup weight
updation to cfq groups").
When adding code that is CONFIG dependent, please build test it with and
without the relevant CONFIG setting (in this case
CONFIG_CFQ_GROUP_IOSCHED). Also put the extern declarations of global
functions into a header file.
I have used the version of the block tree from next-20091203 for today.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Fri, Dec 04 2009, Stephen Rothwell wrote:
> Hi Jens,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> block/built-in.o: In function `blkiocg_destroy':
> blk-cgroup.c:(.text+0x1bd48): undefined reference to `cfq_unlink_blkio_group'
> block/built-in.o: In function `blkiocg_weight_write':
> blk-cgroup.c:(.text+0x1c0d2): undefined reference to `cfq_update_blkio_group_weight'
>
> Caused by commits b1c3576961847da26c91b1e97f226bb66be5fa3f ("blkio: Take
> care of cgroup deletion and cfq group reference counting") and
> f8d461d692c341add957fb973fb5ee1f62039dc7 ("blkio: Propagate cgroup weight
> updation to cfq groups").
>
> When adding code that is CONFIG dependent, please build test it with and
> without the relevant CONFIG setting (in this case
> CONFIG_CFQ_GROUP_IOSCHED). Also put the extern declarations of global
> functions into a header file.
The problem looks like a circular dependency betwen BLK_CGROUP and CFQ.
The Kconfig dependencies doesn't express that blk-cgroup also calls into
cfq, so you can't have cfq=m (cfq doesn't even export those functions).
It looks pretty messy, to be honest. I'll see if I can fix it up.
> I have used the version of the block tree from next-20091203 for today.
Thanks.
--
Jens Axboe
On Fri, Dec 04 2009, Jens Axboe wrote:
> On Fri, Dec 04 2009, Stephen Rothwell wrote:
> > Hi Jens,
> >
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> >
> > block/built-in.o: In function `blkiocg_destroy':
> > blk-cgroup.c:(.text+0x1bd48): undefined reference to `cfq_unlink_blkio_group'
> > block/built-in.o: In function `blkiocg_weight_write':
> > blk-cgroup.c:(.text+0x1c0d2): undefined reference to `cfq_update_blkio_group_weight'
> >
> > Caused by commits b1c3576961847da26c91b1e97f226bb66be5fa3f ("blkio: Take
> > care of cgroup deletion and cfq group reference counting") and
> > f8d461d692c341add957fb973fb5ee1f62039dc7 ("blkio: Propagate cgroup weight
> > updation to cfq groups").
> >
> > When adding code that is CONFIG dependent, please build test it with and
> > without the relevant CONFIG setting (in this case
> > CONFIG_CFQ_GROUP_IOSCHED). Also put the extern declarations of global
> > functions into a header file.
>
> The problem looks like a circular dependency betwen BLK_CGROUP and CFQ.
> The Kconfig dependencies doesn't express that blk-cgroup also calls into
> cfq, so you can't have cfq=m (cfq doesn't even export those functions).
> It looks pretty messy, to be honest. I'll see if I can fix it up.
I pushed out the quick fix, just disallowing cfq=m and blk cgroup in
Kconfig. So it should work now.
--
Jens Axboe
Hi Jens,
On Fri, 4 Dec 2009 14:54:22 +0100 Jens Axboe <[email protected]> wrote:
>
> I pushed out the quick fix, just disallowing cfq=m and blk cgroup in
> Kconfig. So it should work now.
Great, thanks.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Sat, Dec 05 2009, Stephen Rothwell wrote:
> Hi Jens,
>
> On Fri, 4 Dec 2009 14:54:22 +0100 Jens Axboe <[email protected]> wrote:
> >
> > I pushed out the quick fix, just disallowing cfq=m and blk cgroup in
> > Kconfig. So it should work now.
>
> Great, thanks.
And later on a proper solution was also implemented, that is what is
currently in the tree since last night.
--
Jens Axboe