All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Dmitry Safonov <0x7f454c46@gmail.com>,
	James Simmons <jsimmons@infradead.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>,
	Oleg Drokin <oleg.drokin@intel.com>,
	Andreas Dilger <andreas.dilger@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	lustre-devel@lists.lustre.org
Subject: Re: next-20151101 - depmod issues with Lustre modules
Date: Sat, 7 Nov 2015 14:30:44 -0800	[thread overview]
Message-ID: <CA+55aFxJYvGWszcgbWe-xAnrm7p=RpmXz30jRVRTZM4PbQPZbA@mail.gmail.com> (raw)
In-Reply-To: <CAJwJo6YTNB38rYAYwExom4WW5yRJ9eUSXNV4a+xW026VY2iwTg@mail.gmail.com>

On Sat, Nov 7, 2015 at 12:37 PM, Dmitry Safonov <0x7f454c46@gmail.com> wrote:
> Reproduced on mainline v4.3-9038-g27eb427bdc0960 with
> Arch Linux default config (attached):
>
> depmod: ERROR: Found 2 modules in dependency cycles!
> depmod: ERROR: Cycle detected: lnet -> libcfs -> lnet
> make: *** [_modinst_post] Error 1

The reason seems to be that

 - lnet.ko provides the following functions needed by libcfs.ko:

    libcfs_next_nidstring
    libcfs_nid2str_r

 - libcfs.ko provides the following functions needed by lnet.ko:

    libcfs_debug
    libcfs_debug_msg
    libcfs_deregister_ioctl
    libcfs_register_ioctl
    libcfs_subsystem_debug
    lustre_insert_debugfs

but I may have messed up something.

Anyway, the problem seems to be that - insanely - lnet.ko provides
those libcfs nid handling functions. They should be in libcfs, as far
as I can tell, just judging by the name. Also judging by the use.

The cause seems to be commit 47ca6ec2673e ("staging: lustre: move
nidstring handling to LNet layer") by James Simmons.

I do wonder if linux-next could perhaps do some modprobe testing too?

                      Linus

WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org>
To: lustre-devel@lists.lustre.org
Subject: [lustre-devel] next-20151101 - depmod issues with Lustre modules
Date: Sat, 7 Nov 2015 14:30:44 -0800	[thread overview]
Message-ID: <CA+55aFxJYvGWszcgbWe-xAnrm7p=RpmXz30jRVRTZM4PbQPZbA@mail.gmail.com> (raw)
In-Reply-To: <CAJwJo6YTNB38rYAYwExom4WW5yRJ9eUSXNV4a+xW026VY2iwTg@mail.gmail.com>

On Sat, Nov 7, 2015 at 12:37 PM, Dmitry Safonov <0x7f454c46@gmail.com> wrote:
> Reproduced on mainline v4.3-9038-g27eb427bdc0960 with
> Arch Linux default config (attached):
>
> depmod: ERROR: Found 2 modules in dependency cycles!
> depmod: ERROR: Cycle detected: lnet -> libcfs -> lnet
> make: *** [_modinst_post] Error 1

The reason seems to be that

 - lnet.ko provides the following functions needed by libcfs.ko:

    libcfs_next_nidstring
    libcfs_nid2str_r

 - libcfs.ko provides the following functions needed by lnet.ko:

    libcfs_debug
    libcfs_debug_msg
    libcfs_deregister_ioctl
    libcfs_register_ioctl
    libcfs_subsystem_debug
    lustre_insert_debugfs

but I may have messed up something.

Anyway, the problem seems to be that - insanely - lnet.ko provides
those libcfs nid handling functions. They should be in libcfs, as far
as I can tell, just judging by the name. Also judging by the use.

The cause seems to be commit 47ca6ec2673e ("staging: lustre: move
nidstring handling to LNet layer") by James Simmons.

I do wonder if linux-next could perhaps do some modprobe testing too?

                      Linus

  reply	other threads:[~2015-11-07 22:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-02 15:39 next-20151101 - depmod issues with Lustre modules Valdis Kletnieks
2015-11-07 20:37 ` Dmitry Safonov
2015-11-07 20:37   ` [lustre-devel] " Dmitry Safonov
2015-11-07 22:30   ` Linus Torvalds [this message]
2015-11-07 22:30     ` Linus Torvalds
2015-11-12 22:17     ` Stephen Rothwell
2015-11-12 22:17       ` [lustre-devel] " Stephen Rothwell
2015-11-09 21:41   ` Simmons, James A.
2015-11-09 21:41     ` Simmons, James A.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+55aFxJYvGWszcgbWe-xAnrm7p=RpmXz30jRVRTZM4PbQPZbA@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=0x7f454c46@gmail.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=andreas.dilger@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jsimmons@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lustre-devel@lists.lustre.org \
    --cc=oleg.drokin@intel.com \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.