Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Ahsan Atta <ahsan.atta@intel.com>
Cc: linux-crypto@vger.kernel.org, qat-linux@intel.com
Subject: Re: [PATCH 0/2] crypto: qat - fix config table locking
Date: Wed, 23 Sep 2026 18:51:54 +1000	[thread overview]
Message-ID: <arOTKjeCqb-QKKHT@gondor.apana.org.au> (raw)
In-Reply-To: <20260918124112.537571-1-ahsan.atta@intel.com>

On Fri, Sep 18, 2026 at 01:41:10PM +0100, Ahsan Atta wrote:
> The per-device configuration table is protected by cfg->lock, but not
> every access to it takes that lock. adf_cfg_sec_find() walks the section
> list unlocked and returns a pointer that its callers then dereference
> under cfg->lock, so the section can be freed between the lookup and the
> use. The dev_cfg debugfs reader walks both the section list and each
> section's key-value list under a driver-global mutex that none of the
> writers take, so it does not serialise against config writes, device down
> or device removal, any of which can free the entry it is walking. This
> series moves these accesses under the per-device cfg->lock and then drops
> the redundant list walks that are no longer needed once the section is
> resolved under that lock.
> 
> Note on the debugfs lock change:
> The dev_cfg reader now takes a lock that lives inside the structure freed
> by adf_cfg_dev_remove(). This is safe because every cleanup path calls
> adf_dbgfs_exit(), which removes the dev_cfg file, before
> adf_cfg_dev_remove() frees the table, and debugfs_remove() waits for
> in-flight file operations to complete.
> 
> In summary:
> Patch #1: Take cfg->lock around the config section lookups and switch the
> dev_cfg debugfs reader to the same per-device lock. This closes the
> use-after-free windows against section deletion and key updates, makes the
> lookup and insert in adf_cfg_section_add() atomic so that a section can no
> longer be created twice, and removes the now unused global
> qat_cfg_read_lock.
> 
> Patch #2: Look up an existing key-value entry once in
> adf_cfg_add_key_value_param() and act on that pointer directly. With the
> section already resolved under cfg->lock, the list walks done by
> adf_cfg_key_val_get() and adf_cfg_keyval_remove() are redundant, so both
> those calls and the on-stack value copy are dropped. No functional change.
> 
> Ahsan Atta (2):
>   crypto: qat - hold cfg->lock when accessing config sections
>   crypto: qat - avoid redundant config list walks when adding a key
> 
>  drivers/crypto/intel/qat/qat_common/adf_cfg.c | 84 +++++++++----------
>  1 file changed, 38 insertions(+), 46 deletions(-)
> 
> 
> base-commit: c72ab95b5aae0f0412dc1d3284ec446ad1b315e2
> -- 
> 2.50.1

All applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

      parent reply	other threads:[~2026-09-23  8:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-18 12:41 [PATCH 0/2] crypto: qat - fix config table locking Ahsan Atta
2026-09-18 12:41 ` [PATCH 1/2] crypto: qat - hold cfg->lock when accessing config sections Ahsan Atta
2026-09-18 12:41 ` [PATCH 2/2] crypto: qat - avoid redundant config list walks when adding a key Ahsan Atta
2026-09-23  8:51 ` Herbert Xu [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=arOTKjeCqb-QKKHT@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=ahsan.atta@intel.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=qat-linux@intel.com \
    /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