public inbox for linux-nvme@lists.infradead.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@meta.com>
Cc: linux-nvme@lists.infradead.org, hch@lst.de, hare@suse.de,
	rnd@arndb.de, Arnd Bergmann <arnd@arndb.de>,
	Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCHv3 2/2] nvme: keyring: fix conditional compilation
Date: Wed, 8 Nov 2023 08:11:04 +0100	[thread overview]
Message-ID: <20231108071104.GC4684@lst.de> (raw)
In-Reply-To: <20231107181421.593353-3-kbusch@meta.com>

On Tue, Nov 07, 2023 at 10:14:21AM -0800, Keith Busch wrote:
> From: Hannes Reinecke <hare@suse.de>
> 
> The keyring and auth functions can be called from both the host and
> the target side and are controlled by Kconfig options for each of the
> combinations, but the declarations are controlled by #ifdef checks
> on the shared Kconfig symbols.
> 
> This leads to link failures in combinations where one of the frontends
> is built-in and the other one is a module, and the keyring code
> ends up in a module that is not reachable from the builtin code:
> 
> ld: drivers/nvme/host/core.o: in function `nvme_core_exit':
> core.c:(.exit.text+0x4): undefined reference to `nvme_keyring_exit'
> ld: drivers/nvme/host/core.o: in function `nvme_core_init':
> core.c:(.init.text+0x94): undefined reference to `nvme_keyring_init
> 
> ld: drivers/nvme/host/tcp.o: in function `nvme_tcp_setup_ctrl':
> tcp.c:(.text+0x4c18): undefined reference to `nvme_tls_psk_default'
> 
> Address this by moving nvme_keyring_init()/nvme_keyring_exit() into
> module init/exit functions for the keyring module.
> 
> Fixes: be8e82caa6859 ("nvme-tcp: enable TLS handshake upcall")
> Signed-off-by: Hannes Reinecke <hare@suse.de>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Keith Busch <kbusch@kernel.org>

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

If we go with my suggestion on the previous patch this should
still work at least for now.  If the auth side would ever grow
initialization helpers we'd then need to move the main
module_init/exit to the common file and call out to auth and
keyring.



      reply	other threads:[~2023-11-08  7:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-07 18:14 [PATCHv5 0/2] nvme: fixup module compilation Keith Busch
2023-11-07 18:14 ` [PATCHv3 1/2] nvme: common: make keyring and auth separate modules Keith Busch
2023-11-08  7:09   ` Christoph Hellwig
2023-11-07 18:14 ` [PATCHv3 2/2] nvme: keyring: fix conditional compilation Keith Busch
2023-11-08  7:11   ` Christoph Hellwig [this message]

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=20231108071104.GC4684@lst.de \
    --to=hch@lst.de \
    --cc=arnd@arndb.de \
    --cc=hare@suse.de \
    --cc=kbusch@kernel.org \
    --cc=kbusch@meta.com \
    --cc=linux-nvme@lists.infradead.org \
    --cc=rnd@arndb.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox