diff mbox

potential linking bug in recursive directory descent

Message ID b493f8670902241105l48bd7cdbmb99608e802d2454a@mail.gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Fred Isaman Feb. 24, 2009, 7:05 p.m. UTC 
The pnfs tree base of of 2.6.29-rc5 uses the new find_last_bit
function (defined in
lib/find_last_bit.c) in a file in the fs/nfs directory.  Myself and
another developer (though no one else so far) get the following error
during compile:

   Kernel: arch/x86/boot/bzImage is ready  (#5)
     Building modules, stage 2.
     MODPOST 515 modules
   ERROR: "find_last_bit" [fs/nfs/nfs.ko] undefined!
   make[2]: *** [__modpost] Error 1
   make[1]: *** [modules] Error 2
   make: *** [sub-make] Error 2


Note that find_last_bit() is not used in any file in the fs directory.
If I add it to any function that is EXPORT_SYMBOL'ed
from the fs directory, suddenly the compile errors go away.  (See the
below patch for a more concrete example.)

I am not sure what is going on, and why it only affects some
developers, but it looks a lot like the kbuild system
is deciding that the library does not need to be included at the fs
directory level, so isn't including it in fs/nfs where
it is needed.

Thanks for any help.
Fred

From 4bd89543983640ab01c9b704d427f83dad3aa455 Mon Sep 17 00:00:00 2001
From: Fred Isaman <iisaman@citi.umich.edu>
Date: Fri, 20 Feb 2009 11:58:52 -0500
Subject: [PATCH 1/1] DEBUG: Need this to compile - what the heck?

This looks suspiciously like a bug in the kbuild system, where
the library include is not passed down to fs/nfs unless it is
used by fs.  Without this, I get the following error during linking:

Kernel: arch/x86/boot/bzImage is ready  (#5)
 Building modules, stage 2.
 MODPOST 515 modules
ERROR: "find_last_bit" [fs/nfs/nfs.ko] undefined!
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make: *** [sub-make] Error 2

Signed-off-by: Fred Isaman <iisaman@citi.umich.edu>
---
 fs/inode.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

--
1.6.0.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Randy Dunlap Feb. 24, 2009, 7:19 p.m. UTC | #1 
Fred Isaman wrote:
> The pnfs tree base of of 2.6.29-rc5 uses the new find_last_bit

Where is the pnfs tree?

> function (defined in
> lib/find_last_bit.c) in a file in the fs/nfs directory.  Myself and
> another developer (though no one else so far) get the following error
> during compile:
> 
>    Kernel: arch/x86/boot/bzImage is ready  (#5)
>      Building modules, stage 2.
>      MODPOST 515 modules
>    ERROR: "find_last_bit" [fs/nfs/nfs.ko] undefined!
>    make[2]: *** [__modpost] Error 1
>    make[1]: *** [modules] Error 2
>    make: *** [sub-make] Error 2
> 
> 
> Note that find_last_bit() is not used in any file in the fs directory.
> If I add it to any function that is EXPORT_SYMBOL'ed
> from the fs directory, suddenly the compile errors go away.  (See the
> below patch for a more concrete example.)
> 
> I am not sure what is going on, and why it only affects some
> developers, but it looks a lot like the kbuild system
> is deciding that the library does not need to be included at the fs
> directory level, so isn't including it in fs/nfs where
> it is needed.
> 
> Thanks for any help.
> Fred

A failing .config file would be helpful.

Is CONFIG_GENERIC_FIND_LAST_BIT set in your .config file?

If you change lib/Makefile like this:
-lib-$(CONFIG_GENERIC_FIND_LAST_BIT) += find_last_bit.o
+obj-$(CONFIG_GENERIC_FIND_LAST_BIT) += find_last_bit.o

i.e., s/lib/obj/, does your build succeed?


> From 4bd89543983640ab01c9b704d427f83dad3aa455 Mon Sep 17 00:00:00 2001
> From: Fred Isaman <iisaman@citi.umich.edu>
> Date: Fri, 20 Feb 2009 11:58:52 -0500
> Subject: [PATCH 1/1] DEBUG: Need this to compile - what the heck?
> 
> This looks suspiciously like a bug in the kbuild system, where
> the library include is not passed down to fs/nfs unless it is
> used by fs.  Without this, I get the following error during linking:
> 
> Kernel: arch/x86/boot/bzImage is ready  (#5)
>  Building modules, stage 2.
>  MODPOST 515 modules
> ERROR: "find_last_bit" [fs/nfs/nfs.ko] undefined!
> make[2]: *** [__modpost] Error 1
> make[1]: *** [modules] Error 2
> make: *** [sub-make] Error 2
> 
> Signed-off-by: Fred Isaman <iisaman@citi.umich.edu>
> ---
>  fs/inode.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/fs/inode.c b/fs/inode.c
> index 306faef..a4e29b3 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -226,6 +226,7 @@ EXPORT_SYMBOL(destroy_inode);
>  */
>  void inode_init_once(struct inode *inode)
>  {
> +       find_last_bit((unsigned long *) inode, 5);
>        memset(inode, 0, sizeof(*inode));
>        INIT_HLIST_NODE(&inode->i_hash);
>        INIT_LIST_HEAD(&inode->i_dentry);
> --
Fred Isaman Feb. 24, 2009, 8:19 p.m. UTC | #2 
git://linux-nfs.org/~bhalevy/linux-pnfs.git

On Tue, Feb 24, 2009 at 2:19 PM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> Fred Isaman wrote:
>> The pnfs tree base of of 2.6.29-rc5 uses the new find_last_bit
>
> Where is the pnfs tree?

git://linux-nfs.org/~bhalevy/linux-pnfs.git
branch origin/pnfs-2.6.29

>
>> function (defined in
>> lib/find_last_bit.c) in a file in the fs/nfs directory.  Myself and
>> another developer (though no one else so far) get the following error
>> during compile:
>>
>>    Kernel: arch/x86/boot/bzImage is ready  (#5)
>>      Building modules, stage 2.
>>      MODPOST 515 modules
>>    ERROR: "find_last_bit" [fs/nfs/nfs.ko] undefined!
>>    make[2]: *** [__modpost] Error 1
>>    make[1]: *** [modules] Error 2
>>    make: *** [sub-make] Error 2
>>
>>
>> Note that find_last_bit() is not used in any file in the fs directory.
>> If I add it to any function that is EXPORT_SYMBOL'ed
>> from the fs directory, suddenly the compile errors go away.  (See the
>> below patch for a more concrete example.)
>>
>> I am not sure what is going on, and why it only affects some
>> developers, but it looks a lot like the kbuild system
>> is deciding that the library does not need to be included at the fs
>> directory level, so isn't including it in fs/nfs where
>> it is needed.
>>
>> Thanks for any help.
>> Fred
>
> A failing .config file would be helpful.
>

I've attached the .config

> Is CONFIG_GENERIC_FIND_LAST_BIT set in your .config file?
>

yes

> If you change lib/Makefile like this:
> -lib-$(CONFIG_GENERIC_FIND_LAST_BIT) += find_last_bit.o
> +obj-$(CONFIG_GENERIC_FIND_LAST_BIT) += find_last_bit.o
>
> i.e., s/lib/obj/, does your build succeed?
>

Yes, it does work with that change.

Fred

>
>> From 4bd89543983640ab01c9b704d427f83dad3aa455 Mon Sep 17 00:00:00 2001
>> From: Fred Isaman <iisaman@citi.umich.edu>
>> Date: Fri, 20 Feb 2009 11:58:52 -0500
>> Subject: [PATCH 1/1] DEBUG: Need this to compile - what the heck?
>>
>> This looks suspiciously like a bug in the kbuild system, where
>> the library include is not passed down to fs/nfs unless it is
>> used by fs.  Without this, I get the following error during linking:
>>
>> Kernel: arch/x86/boot/bzImage is ready  (#5)
>>  Building modules, stage 2.
>>  MODPOST 515 modules
>> ERROR: "find_last_bit" [fs/nfs/nfs.ko] undefined!
>> make[2]: *** [__modpost] Error 1
>> make[1]: *** [modules] Error 2
>> make: *** [sub-make] Error 2
>>
>> Signed-off-by: Fred Isaman <iisaman@citi.umich.edu>
>> ---
>>  fs/inode.c |    1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/fs/inode.c b/fs/inode.c
>> index 306faef..a4e29b3 100644
>> --- a/fs/inode.c
>> +++ b/fs/inode.c
>> @@ -226,6 +226,7 @@ EXPORT_SYMBOL(destroy_inode);
>>  */
>>  void inode_init_once(struct inode *inode)
>>  {
>> +       find_last_bit((unsigned long *) inode, 5);
>>        memset(inode, 0, sizeof(*inode));
>>        INIT_HLIST_NODE(&inode->i_hash);
>>        INIT_LIST_HEAD(&inode->i_dentry);
>> --
>
> --
> ~Randy
>
Fred Isaman Feb. 24, 2009, 9:20 p.m. UTC | #3 
On Tue, Feb 24, 2009 at 4:03 PM, Sam Ravnborg <sam@ravnborg.org> wrote:
> On Tue, Feb 24, 2009 at 02:05:25PM -0500, Fred Isaman wrote:
>> The pnfs tree base of of 2.6.29-rc5 uses the new find_last_bit
>> function (defined in
>> lib/find_last_bit.c) in a file in the fs/nfs directory.  Myself and
>> another developer (though no one else so far) get the following error
>> during compile:
>>
>>    Kernel: arch/x86/boot/bzImage is ready  (#5)
>>      Building modules, stage 2.
>>      MODPOST 515 modules
>>    ERROR: "find_last_bit" [fs/nfs/nfs.ko] undefined!
>>    make[2]: *** [__modpost] Error 1
>>    make[1]: *** [modules] Error 2
>>    make: *** [sub-make] Error 2
>>
>>
>> Note that find_last_bit() is not used in any file in the fs directory.
>> If I add it to any function that is EXPORT_SYMBOL'ed
>> from the fs directory, suddenly the compile errors go away.  (See the
>> below patch for a more concrete example.)
>>
>> I am not sure what is going on, and why it only affects some
>> developers, but it looks a lot like the kbuild system
>> is deciding that the library does not need to be included at the fs
>> directory level, so isn't including it in fs/nfs where
>> it is needed.
>
> kbuild only links in libaries if there is any users of siad library.
> And your normal config has no users of lib/find_last_bit.c so
> it is not linked into the kernel.
>

I don't understand your comment.  There *is* a user of the library in the
(modified) fs/nfs/nfs4proc.c.  The problem is that it doesn't compile unless
there is also a user in some fs/*.c.

> The general rule is that if any in tree module uses a library
> then the library is always linked in.
> And to always link in a library you need to patch the Makefile
> as Randy suggest in his mail.
>
>        Sam
>

Again, I suspect I am misunderstanding.  It seems you are suggesting
that to compile the nfs code I have to alter lib/Makefile.  While that is a
useful workaround, that is certainly not a viable solution.

Fred
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Randy Dunlap Feb. 24, 2009, 9:28 p.m. UTC | #4 
Fred Isaman wrote:
> On Tue, Feb 24, 2009 at 4:03 PM, Sam Ravnborg <sam@ravnborg.org> wrote:
>> On Tue, Feb 24, 2009 at 02:05:25PM -0500, Fred Isaman wrote:
>>> The pnfs tree base of of 2.6.29-rc5 uses the new find_last_bit
>>> function (defined in
>>> lib/find_last_bit.c) in a file in the fs/nfs directory.  Myself and
>>> another developer (though no one else so far) get the following error
>>> during compile:
>>>
>>>    Kernel: arch/x86/boot/bzImage is ready  (#5)
>>>      Building modules, stage 2.
>>>      MODPOST 515 modules
>>>    ERROR: "find_last_bit" [fs/nfs/nfs.ko] undefined!
>>>    make[2]: *** [__modpost] Error 1
>>>    make[1]: *** [modules] Error 2
>>>    make: *** [sub-make] Error 2
>>>
>>>
>>> Note that find_last_bit() is not used in any file in the fs directory.
>>> If I add it to any function that is EXPORT_SYMBOL'ed
>>> from the fs directory, suddenly the compile errors go away.  (See the
>>> below patch for a more concrete example.)
>>>
>>> I am not sure what is going on, and why it only affects some
>>> developers, but it looks a lot like the kbuild system
>>> is deciding that the library does not need to be included at the fs
>>> directory level, so isn't including it in fs/nfs where
>>> it is needed.
>> kbuild only links in libaries if there is any users of siad library.
>> And your normal config has no users of lib/find_last_bit.c so
>> it is not linked into the kernel.
>>
> 
> I don't understand your comment.  There *is* a user of the library in the
> (modified) fs/nfs/nfs4proc.c.  The problem is that it doesn't compile unless
> there is also a user in some fs/*.c.

If you build nfs (or pnfs) into the kernel image instead of as a
loadable module, does the build succeed?  I expect that it does
(or would).

>> The general rule is that if any in tree module uses a library
>> then the library is always linked in.
>> And to always link in a library you need to patch the Makefile
>> as Randy suggest in his mail.
>>
>>        Sam
>>
> 
> Again, I suspect I am misunderstanding.  It seems you are suggesting
> that to compile the nfs code I have to alter lib/Makefile.  While that is a
> useful workaround, that is certainly not a viable solution.

Why not?  We do that same change for other library options.
Fred Isaman Feb. 25, 2009, 1:04 a.m. UTC | #5 
On Tue, Feb 24, 2009 at 4:28 PM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> Fred Isaman wrote:
>> On Tue, Feb 24, 2009 at 4:03 PM, Sam Ravnborg <sam@ravnborg.org> wrote:
>>> On Tue, Feb 24, 2009 at 02:05:25PM -0500, Fred Isaman wrote:
>>>> The pnfs tree base of of 2.6.29-rc5 uses the new find_last_bit
>>>> function (defined in
>>>> lib/find_last_bit.c) in a file in the fs/nfs directory.  Myself and
>>>> another developer (though no one else so far) get the following error
>>>> during compile:
>>>>
>>>>    Kernel: arch/x86/boot/bzImage is ready  (#5)
>>>>      Building modules, stage 2.
>>>>      MODPOST 515 modules
>>>>    ERROR: "find_last_bit" [fs/nfs/nfs.ko] undefined!
>>>>    make[2]: *** [__modpost] Error 1
>>>>    make[1]: *** [modules] Error 2
>>>>    make: *** [sub-make] Error 2
>>>>
>>>>
>>>> Note that find_last_bit() is not used in any file in the fs directory.
>>>> If I add it to any function that is EXPORT_SYMBOL'ed
>>>> from the fs directory, suddenly the compile errors go away.  (See the
>>>> below patch for a more concrete example.)
>>>>
>>>> I am not sure what is going on, and why it only affects some
>>>> developers, but it looks a lot like the kbuild system
>>>> is deciding that the library does not need to be included at the fs
>>>> directory level, so isn't including it in fs/nfs where
>>>> it is needed.
>>> kbuild only links in libaries if there is any users of siad library.
>>> And your normal config has no users of lib/find_last_bit.c so
>>> it is not linked into the kernel.
>>>
>>
>> I don't understand your comment.  There *is* a user of the library in the
>> (modified) fs/nfs/nfs4proc.c.  The problem is that it doesn't compile unless
>> there is also a user in some fs/*.c.
>
> If you build nfs (or pnfs) into the kernel image instead of as a
> loadable module, does the build succeed?  I expect that it does
> (or would).
>

Yes, you are correct.


>>> The general rule is that if any in tree module uses a library
>>> then the library is always linked in.
>>> And to always link in a library you need to patch the Makefile
>>> as Randy suggest in his mail.
>>>
>>>        Sam
>>>
>>
>> Again, I suspect I am misunderstanding.  It seems you are suggesting
>> that to compile the nfs code I have to alter lib/Makefile.  While that is a
>> useful workaround, that is certainly not a viable solution.
>
> Why not?  We do that same change for other library options.
>

I was working under the assumption that, in order to compile nfs, I should
only have to adjust the fs/nfs/Makefile.  You seem to be saying that when
we submit upstream a patch that uses find_last_bit(), if there are no other
in-kernel users at that time, we will have to submit a patch to lib/Makefile,
similar to commit 5a6dca7... lib: move bitmap.o from lib-y to obj-y.
If that is what you mean, I can live with that.

Thanks for your help.

Fred


>
> --
> ~Randy
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/fs/inode.c b/fs/inode.c
index 306faef..a4e29b3 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -226,6 +226,7 @@  EXPORT_SYMBOL(destroy_inode);
 */
 void inode_init_once(struct inode *inode)
 {
+       find_last_bit((unsigned long *) inode, 5);
       memset(inode, 0, sizeof(*inode));
       INIT_HLIST_NODE(&inode->i_hash);
       INIT_LIST_HEAD(&inode->i_dentry);