Skip to content
  1. Nov 28, 2023
  2. Nov 25, 2023
    • Markus Weippert's avatar
      bcache: revert replacing IS_ERR_OR_NULL with IS_ERR · bb6cc253
      Markus Weippert authored
      Commit 028ddcac ("bcache: Remove unnecessary NULL point check in
      node allocations") replaced IS_ERR_OR_NULL by IS_ERR. This leads to a
      NULL pointer dereference.
      
      BUG: kernel NULL pointer dereference, address: 0000000000000080
      Call Trace:
       ? __die_body.cold+0x1a/0x1f
       ? page_fault_oops+0xd2/0x2b0
       ? exc_page_fault+0x70/0x170
       ? asm_exc_page_fault+0x22/0x30
       ? btree_node_free+0xf/0x160 [bcache]
       ? up_write+0x32/0x60
       btree_gc_coalesce+0x2aa/0x890 [bcache]
       ? bch_extent_bad+0x70/0x170 [bcache]
       btree_gc_recurse+0x130/0x390 [bcache]
       ? btree_gc_mark_node+0x72/0x230 [bcache]
       bch_btree_gc+0x5da/0x600 [bcache]
       ? cpuusage_read+0x10/0x10
       ? bch_btree_gc+0x600/0x600 [bcache]
       bch_gc_thread+0x135/0x180 [bcache]
      
      The relevant code starts with:
      
          new_nodes[0] = NULL;
      
          for (i = 0; i < nodes; i++) {
              if (__bch_keylist_realloc(&keylist, bkey_u64s(&r[i].b->key)))
                  goto out_nocoalesce;
          // ...
      out_nocoalesce:
          // ...
          for (i = 0; i < nodes; i++)
              if (!IS_ERR(new_nodes[i])) {  // IS_ERR_OR_NULL before
      028ddcac
                  btree_node_free(new_nodes[i]);  // new_nodes[0] is NULL
                  rw_unlock(true, new_nodes[i]);
              }
      
      This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.
      
      Fixes: 028ddcac ("bcache: Remove unnecessary NULL point check in node allocations")
      Link: https://lore.kernel.org/all/3DF4A87A-2AC1-4893-AE5F-E921478419A9@suse.de/
      
      
      Cc: stable@vger.kernel.org
      Cc: Zheng Wang <zyytlz.wz@163.com>
      Cc: Coly Li <colyli@suse.de>
      Signed-off-by: default avatarMarkus Weippert <markus@gekmihesg.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      bb6cc253
  3. Nov 23, 2023
    • Arnd Bergmann's avatar
      nvme: tcp: fix compile-time checks for TLS mode · 0e6c4fe7
      Arnd Bergmann authored
      
      
      When CONFIG_NVME_KEYRING is enabled as a loadable module, but the TCP
      host code is built-in, it fails to link:
      
      arm-linux-gnueabi-ld: drivers/nvme/host/tcp.o: in function `nvme_tcp_setup_ctrl':
      tcp.c:(.text+0x1940): undefined reference to `nvme_tls_psk_default'
      
      The problem is that the compile-time conditionals are inconsistent here,
      using a mix of #ifdef CONFIG_NVME_TCP_TLS, IS_ENABLED(CONFIG_NVME_TCP_TLS)
      and IS_ENABLED(CONFIG_NVME_KEYRING) checks, with CONFIG_NVME_KEYRING
      controlling whether the implementation is actually built.
      
      Change it to use IS_ENABLED(CONFIG_NVME_KEYRING) checks consistently,
      which should help readability and make it less error-prone. Combining
      it with the check for the ctrl->opts->tls flag lets the compiler drop
      all the TLS code in configurations without this feature, which also
      helps runtime behavior in addition to avoiding the link failure.
      
      To make it possible for the compiler to build the dead code, both
      the tls_handshake_timeout variable and the TLS specific members
      of nvme_tcp_queue need to be moved out of the #ifdef block as well,
      but at least the former of these gets optimized out again.
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Link: https://lore.kernel.org/r/20231122224719.4042108-4-arnd@kernel.org
      
      
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      0e6c4fe7
    • Arnd Bergmann's avatar
      nvme: target: fix Kconfig select statements · 65e2a74c
      Arnd Bergmann authored
      
      
      When the NVME target code is built-in but its TCP frontend is a loadable
      module, enabling keyring support causes a link failure:
      
      x86_64-linux-ld: vmlinux.o: in function `nvmet_ports_make':
      configfs.c:(.text+0x100a211): undefined reference to `nvme_keyring_id'
      
      The problem is that CONFIG_NVME_TARGET_TCP_TLS is a 'bool' symbol that
      depends on the tristate CONFIG_NVME_TARGET_TCP, so any 'select' from
      it inherits the state of the tristate symbol rather than the intended
      CONFIG_NVME_TARGET one that contains the actual call.
      
      The same thing is true for CONFIG_KEYS, which itself is required for
      NVME_KEYRING.
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Link: https://lore.kernel.org/r/20231122224719.4042108-3-arnd@kernel.org
      
      
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      65e2a74c
    • Arnd Bergmann's avatar
      nvme: target: fix nvme_keyring_id() references · d78abcba
      Arnd Bergmann authored
      
      
      In configurations without CONFIG_NVME_TARGET_TCP_TLS, the keyring
      code might not be available, or using it will result in a runtime
      failure:
      
      x86_64-linux-ld: vmlinux.o: in function `nvmet_ports_make':
      configfs.c:(.text+0x100a211): undefined reference to `nvme_keyring_id'
      
      Add a check to ensure we only check the keyring if there is a chance
      of it being used, which avoids both the runtime and link-time
      problems.
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Link: https://lore.kernel.org/r/20231122224719.4042108-2-arnd@kernel.org
      
      
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      d78abcba
    • Jens Axboe's avatar
      Merge tag 'nvme-6.7-2023-11-22' of git://git.infradead.org/nvme into block-6.7 · 55072cd7
      Jens Axboe authored
      Pull NVMe fixes from Keith:
      
      "nvme fixes for Linux 6.7
      
       - TCP TLS fixes (Hannes)
       - Authentifaction fixes (Mark, Hannes)
       - Properly terminate target names (Christoph)"
      
      * tag 'nvme-6.7-2023-11-22' of git://git.infradead.org/nvme:
        nvme: move nvme_stop_keep_alive() back to original position
        nvmet-tcp: always initialize tls_handshake_tmo_work
        nvmet: nul-terminate the NQNs passed in the connect command
        nvme: blank out authentication fabrics options if not configured
        nvme: catch errors from nvme_configure_metadata()
        nvme-tcp: only evaluate 'tls' option if TLS is selected
        nvme-auth: set explanation code for failure2 msgs
        nvme-auth: unlock mutex in one place only
      55072cd7
    • Hannes Reinecke's avatar
      nvme: move nvme_stop_keep_alive() back to original position · 3af755a4
      Hannes Reinecke authored
      Stopping keep-alive not only stops the keep-alive workqueue,
      but also needs to be synchronized with I/O termination as we
      must not send a keep-alive command after all I/O had been
      terminated.
      So to avoid any regressions move the call to stop_keep_alive()
      back to its original position and ensure that keep-alive is
      correctly stopped failing to setup the admin queue.
      
      Fixes: 4733b65d
      
       ("nvme: start keep-alive after admin queue setup")
      Suggested-by: default avatarSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: default avatarHannes Reinecke <hare@suse.de>
      Reviewed-by: default avatarSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: default avatarKeith Busch <kbusch@kernel.org>
      3af755a4
  4. Nov 21, 2023
  5. Nov 20, 2023
  6. Nov 18, 2023
  7. Nov 13, 2023