* [PATCH 0/3] AF_ALG: Remove support for AIO and old-style drivers
From: Demi Marie Obenour via B4 Relay @ 2026-05-23 19:43 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Eric Dumazet, Kuniyuki Iwashima,
Paolo Abeni, Willem de Bruijn, Jens Axboe, Jakub Kicinski,
Simon Horman, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Jonathan Corbet, Shuah Khan, Eric Biggers,
Ard Biesheuvel
Cc: linux-crypto, linux-kernel, io-uring, netdev, linux-perf-users,
linux-doc, Demi Marie Obenour
AF_ALG is a deprecated API only useful for compatibility with existing
userspace. It has had a lot of vulnerabilities, including the infamous
CopyFail.
Rip out support for offload drivers, which tend to be buggy. Also rip
out support for AIO, which actually bloats the entire socket subsystem.
Only compile-tested.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
---
Demi Marie Obenour (3):
net: Remove support for AIO on sockets
AF_ALG: Drop support for off-CPU cryptography
AF_ALG: Document that it is *always* slower
Documentation/crypto/userspace-if.rst | 26 ++++++++--
crypto/af_alg.c | 35 ++------------
crypto/algif_aead.c | 43 ++++-------------
crypto/algif_hash.c | 4 +-
crypto/algif_rng.c | 4 +-
crypto/algif_skcipher.c | 66 ++++++--------------------
include/crypto/if_alg.h | 19 ++++++--
include/linux/socket.h | 1 -
io_uring/net.c | 1 -
net/compat.c | 1 -
net/socket.c | 7 +--
tools/perf/trace/beauty/include/linux/socket.h | 1 -
12 files changed, 70 insertions(+), 138 deletions(-)
---
base-commit: 49e05bb00f2e8168695f7af4d694c39e1423e8a2
change-id: 20260502-af-alg-harden-900849451653
Best regards,
--
Demi Marie Obenour <demiobenour@gmail.com>
^ permalink raw reply
* [PATCH 2/3] AF_ALG: Drop support for off-CPU cryptography
From: Demi Marie Obenour via B4 Relay @ 2026-05-23 19:43 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Eric Dumazet, Kuniyuki Iwashima,
Paolo Abeni, Willem de Bruijn, Jens Axboe, Jakub Kicinski,
Simon Horman, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Jonathan Corbet, Shuah Khan, Eric Biggers,
Ard Biesheuvel
Cc: linux-crypto, linux-kernel, io-uring, netdev, linux-perf-users,
linux-doc, Demi Marie Obenour
In-Reply-To: <20260523-af-alg-harden-v1-0-c76755c3a5c5@gmail.com>
From: Demi Marie Obenour <demiobenour@gmail.com>
AF_ALG is deprecated and exposed to unprivileged userspace. Only
use the least buggy algorithm implementations: the pure software ones.
This removes one of the main advantages of AF_ALG, which is the
ability to use it with off-CPU accelerators. However, using off-CPU
accelerators has huge overheads, both in performance and attack surface.
I have yet to see real-world, performance-critical workloads where using
an accelerator via AF_ALG is actually a win over doing cryptography in
userspace.
If using an off-CPU accelerator really does turn out to be a win, a new
API should be developed that is actually a good fit for it.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
---
Documentation/crypto/userspace-if.rst | 7 ++++++-
crypto/af_alg.c | 2 +-
crypto/algif_aead.c | 4 ++--
crypto/algif_hash.c | 4 ++--
crypto/algif_rng.c | 4 ++--
crypto/algif_skcipher.c | 4 ++--
include/crypto/if_alg.h | 14 +++++++++++++-
7 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/Documentation/crypto/userspace-if.rst b/Documentation/crypto/userspace-if.rst
index ea1b1b3f4049fd4673528dc2a6234f6376a3489f..b31117d4415dda6ad6ca36275e615bec7df9552e 100644
--- a/Documentation/crypto/userspace-if.rst
+++ b/Documentation/crypto/userspace-if.rst
@@ -9,7 +9,8 @@ symmetric cipher, AEAD, and RNG algorithms that are implemented in kernel-mode
code.
AF_ALG is insecure and is deprecated. Originally added to the kernel in 2010,
-most kernel developers now consider it to be a mistake.
+most kernel developers now consider it to be a mistake. Support for hardware
+accelerators, which was the original purpose of AF_ALG, has been removed.
AF_ALG continues to be supported only for backwards compatibility. On systems
where no programs using AF_ALG remain, the support for it should be disabled by
@@ -59,6 +60,10 @@ Some of the examples include:
- CVE-2013-7421
- CVE-2011-4081
+Hardware accelerator drivers are frequently buggy. To reduce attack surface,
+AF_ALG now only provides access to algorithms implemented in software. This
+means that AF_ALG no longer fulfills its original purpose.
+
It is recommended that, whenever possible, userspace programs be migrated to
userspace crypto code (which again, is what is normally used anyway) and
``CONFIG_CRYPTO_USER_API_*`` be disabled. On systems that use SELinux, SELinux
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 8ccf7a737cd6ca9a5d5bf47050c9afea0dfd61bf..cce000e8590e469927b5a5a0ceccfdf0ef54633d 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -181,7 +181,7 @@ static int alg_bind(struct socket *sock, struct sockaddr_unsized *uaddr, int add
if (IS_ERR(type))
return PTR_ERR(type);
- private = type->bind(sa->salg_name, sa->salg_feat, sa->salg_mask);
+ private = type->bind(sa->salg_name);
if (IS_ERR(private)) {
module_put(type->owner);
return PTR_ERR(private);
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 60f06597cb0b13036bc975641a0b02ea8a41ad03..787aac8aeb24eed128f08345ba730478113919b3 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -342,9 +342,9 @@ static struct proto_ops algif_aead_ops_nokey = {
.poll = af_alg_poll,
};
-static void *aead_bind(const char *name, u32 type, u32 mask)
+static void *aead_bind(const char *name)
{
- return crypto_alloc_aead(name, type, mask);
+ return crypto_alloc_aead(name, 0, AF_ALG_CRYPTOAPI_MASK);
}
static void aead_release(void *private)
diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index 4d3dfc60a16a6d8b677d903d209df18d67202c98..5452ad6c15069c3cb0ff78fe58868fe7ce4b0fc3 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -380,9 +380,9 @@ static struct proto_ops algif_hash_ops_nokey = {
.accept = hash_accept_nokey,
};
-static void *hash_bind(const char *name, u32 type, u32 mask)
+static void *hash_bind(const char *name)
{
- return crypto_alloc_ahash(name, type, mask);
+ return crypto_alloc_ahash(name, 0, AF_ALG_CRYPTOAPI_MASK);
}
static void hash_release(void *private)
diff --git a/crypto/algif_rng.c b/crypto/algif_rng.c
index a9fb492e929a70c94476f296f5f5e7c42f0313b7..4dfe7899f8fa4ce82d5f2236297230fb44bc35d6 100644
--- a/crypto/algif_rng.c
+++ b/crypto/algif_rng.c
@@ -197,7 +197,7 @@ static struct proto_ops __maybe_unused algif_rng_test_ops = {
.sendmsg = rng_test_sendmsg,
};
-static void *rng_bind(const char *name, u32 type, u32 mask)
+static void *rng_bind(const char *name)
{
struct rng_parent_ctx *pctx;
struct crypto_rng *rng;
@@ -206,7 +206,7 @@ static void *rng_bind(const char *name, u32 type, u32 mask)
if (!pctx)
return ERR_PTR(-ENOMEM);
- rng = crypto_alloc_rng(name, type, mask);
+ rng = crypto_alloc_rng(name, 0, AF_ALG_CRYPTOAPI_MASK);
if (IS_ERR(rng)) {
kfree(pctx);
return ERR_CAST(rng);
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 9dbccabd87b13920c27aff5a450a235cc6a27d59..df20bdfe1f1f4e453782dee3b743dd1939ab4c6c 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -307,9 +307,9 @@ static struct proto_ops algif_skcipher_ops_nokey = {
.poll = af_alg_poll,
};
-static void *skcipher_bind(const char *name, u32 type, u32 mask)
+static void *skcipher_bind(const char *name)
{
- return crypto_alloc_skcipher(name, type, mask);
+ return crypto_alloc_skcipher(name, 0, AF_ALG_CRYPTOAPI_MASK);
}
static void skcipher_release(void *private)
diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
index 62867daca47d76c9ea1a7ed233188788c5f6c3c0..7643ba954125aba0c06aaf19de087985325885ad 100644
--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -41,7 +41,7 @@ struct af_alg_control {
};
struct af_alg_type {
- void *(*bind)(const char *name, u32 type, u32 mask);
+ void *(*bind)(const char *name);
void (*release)(void *private);
int (*setkey)(void *private, const u8 *key, unsigned int keylen);
int (*setentropy)(void *private, sockptr_t entropy, unsigned int len);
@@ -243,4 +243,16 @@ int af_alg_get_rsgl(struct sock *sk, struct msghdr *msg, int flags,
struct af_alg_async_req *areq, size_t maxsize,
size_t *outlen);
+/*
+ * Mask used to disable unsupported algorithm implementations.
+ *
+ * This is the same as FSCRYPT_CRYPTOAPI_MASK in fs/crypto/fscrypt_private.h.
+ * In additions to the motivations there, this API is exposed to userspace
+ * that might not be fully trusted.
+ */
+#define AF_ALG_CRYPTOAPI_MASK \
+ (CRYPTO_ALG_ASYNC | CRYPTO_ALG_ALLOCATES_MEMORY | \
+ CRYPTO_ALG_KERN_DRIVER_ONLY)
+
+
#endif /* _CRYPTO_IF_ALG_H */
--
2.54.0
^ permalink raw reply related
* [PATCH 3/3] AF_ALG: Document that it is *always* slower
From: Demi Marie Obenour via B4 Relay @ 2026-05-23 19:43 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Eric Dumazet, Kuniyuki Iwashima,
Paolo Abeni, Willem de Bruijn, Jens Axboe, Jakub Kicinski,
Simon Horman, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Jonathan Corbet, Shuah Khan, Eric Biggers,
Ard Biesheuvel
Cc: linux-crypto, linux-kernel, io-uring, netdev, linux-perf-users,
linux-doc, Demi Marie Obenour
In-Reply-To: <20260523-af-alg-harden-v1-0-c76755c3a5c5@gmail.com>
From: Demi Marie Obenour <demiobenour@gmail.com>
Without support for zero-copy or off-CPU offloads, AF_ALG is always
slower than software cryptography. Its only advantage is that it might
save code size. However, this is largely mitigated by lightweight
userspace cryptographic libraries.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
---
Documentation/crypto/userspace-if.rst | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/Documentation/crypto/userspace-if.rst b/Documentation/crypto/userspace-if.rst
index b31117d4415dda6ad6ca36275e615bec7df9552e..ab93300c8e04524469f284704c7c5ed582fdcbc0 100644
--- a/Documentation/crypto/userspace-if.rst
+++ b/Documentation/crypto/userspace-if.rst
@@ -28,8 +28,8 @@ functionality than that. It actually provides access to all software algorithms.
This includes arbitrary compositions of different algorithms created via a
complex template system, as well as algorithms that only make sense as internal
-implementation details of other algorithms. It also includes full zero-copy
-support, which is difficult for the kernel to implement securely.
+implementation details of other algorithms. In the past, it also included full
+zero-copy support, which was difficult for the kernel to implement securely.
Ultimately, these algorithms are just math computations. They use the same
instructions that userspace programs already have access to, just accessed in a
@@ -38,6 +38,21 @@ much more convoluted and less efficient way.
Indeed, userspace code is nearly always what is being used anyway. These same
algorithms are widely implemented in userspace crypto libraries.
+Even when zero-copy and off-CPU accelerators were supported, AF_ALG was usually
+much slower than optimized software cryptography in userspace. This was
+especially true for the small message sizes usually seen in performance-critical
+workloads. While it was possible to demonstrate performance wins for hashing
+large files on embedded devices, it is hard to imagine a situation where this
+would be performance-critical.
+
+Nowadays, AF_ALG no longer supports zero-copy or off-CPU accelerators.
+Therefore, it is *always* slower than an optimized userspace implementation,
+even for large messages. The only possible advantage left is that it avoids
+duplicating code between kernel and userspace. However, userspace
+implementations, especially hardware-accelerated ones, do not need to be large.
+Just because OpenSSL is huge does not mean that all userspace cryptography
+libraries are.
+
Meanwhile, AF_ALG hasn't been withstanding modern vulnerability discovery tools
such as syzbot and large language models. It receives a steady stream of CVEs.
Some of the examples include:
--
2.54.0
^ permalink raw reply related
* [PATCH 1/3] net: Remove support for AIO on sockets
From: Demi Marie Obenour via B4 Relay @ 2026-05-23 19:43 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Eric Dumazet, Kuniyuki Iwashima,
Paolo Abeni, Willem de Bruijn, Jens Axboe, Jakub Kicinski,
Simon Horman, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Jonathan Corbet, Shuah Khan, Eric Biggers,
Ard Biesheuvel
Cc: linux-crypto, linux-kernel, io-uring, netdev, linux-perf-users,
linux-doc, Demi Marie Obenour
In-Reply-To: <20260523-af-alg-harden-v1-0-c76755c3a5c5@gmail.com>
From: Demi Marie Obenour <demiobenour@gmail.com>
The only user of msg->msg_iocb was AF_ALG, but that's deprecated.
It can be removed entirely at the cost of only supporting synchronous
operations. This doesn't break userspace, which will silently block
(for a bounded amount of time) in io_submit instead of operating
asynchronously.
This also makes struct msghdr smaller, helping every other caller of
sendmsg().
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
---
crypto/af_alg.c | 33 +-------------
crypto/algif_aead.c | 39 ++++------------
crypto/algif_skcipher.c | 62 +++++---------------------
include/crypto/if_alg.h | 5 +--
include/linux/socket.h | 1 -
io_uring/net.c | 1 -
net/compat.c | 1 -
net/socket.c | 7 +--
tools/perf/trace/beauty/include/linux/socket.h | 1 -
9 files changed, 25 insertions(+), 125 deletions(-)
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 48c53f488e0fd30818e72439fe0c0d7e4cee1432..8ccf7a737cd6ca9a5d5bf47050c9afea0dfd61bf 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -1085,35 +1085,6 @@ void af_alg_free_resources(struct af_alg_async_req *areq)
}
EXPORT_SYMBOL_GPL(af_alg_free_resources);
-/**
- * af_alg_async_cb - AIO callback handler
- * @data: async request completion data
- * @err: if non-zero, error result to be returned via ki_complete();
- * otherwise return the AIO output length via ki_complete().
- *
- * This handler cleans up the struct af_alg_async_req upon completion of the
- * AIO operation.
- *
- * The number of bytes to be generated with the AIO operation must be set
- * in areq->outlen before the AIO callback handler is invoked.
- */
-void af_alg_async_cb(void *data, int err)
-{
- struct af_alg_async_req *areq = data;
- struct sock *sk = areq->sk;
- struct kiocb *iocb = areq->iocb;
- unsigned int resultlen;
-
- /* Buffer size written by crypto operation. */
- resultlen = areq->outlen;
-
- af_alg_free_resources(areq);
- sock_put(sk);
-
- iocb->ki_complete(iocb, err ? err : (int)resultlen);
-}
-EXPORT_SYMBOL_GPL(af_alg_async_cb);
-
/**
* af_alg_poll - poll system call handler
* @file: file pointer
@@ -1154,8 +1125,8 @@ struct af_alg_async_req *af_alg_alloc_areq(struct sock *sk,
struct af_alg_ctx *ctx = alg_sk(sk)->private;
struct af_alg_async_req *areq;
- /* Only one AIO request can be in flight. */
- if (ctx->inflight)
+ /* Only one request can be in flight. */
+ if (WARN_ON_ONCE(ctx->inflight))
return ERR_PTR(-EBUSY);
areq = sock_kmalloc(sk, areqlen, GFP_KERNEL);
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index c6c2ce21895dd7df51dc825ed886ba7e1aa37130..60f06597cb0b13036bc975641a0b02ea8a41ad03 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -197,37 +197,14 @@ static int _aead_recvmsg(struct socket *sock, struct msghdr *msg,
aead_request_set_ad(&areq->cra_u.aead_req, ctx->aead_assoclen);
aead_request_set_tfm(&areq->cra_u.aead_req, tfm);
- if (msg->msg_iocb && !is_sync_kiocb(msg->msg_iocb)) {
- /* AIO operation */
- sock_hold(sk);
- areq->iocb = msg->msg_iocb;
-
- /* Remember output size that will be generated. */
- areq->outlen = outlen;
-
- aead_request_set_callback(&areq->cra_u.aead_req,
- CRYPTO_TFM_REQ_MAY_SLEEP,
- af_alg_async_cb, areq);
- err = ctx->enc ? crypto_aead_encrypt(&areq->cra_u.aead_req) :
- crypto_aead_decrypt(&areq->cra_u.aead_req);
-
- /* AIO operation in progress */
- if (err == -EINPROGRESS)
- return -EIOCBQUEUED;
-
- sock_put(sk);
- } else {
- /* Synchronous operation */
- aead_request_set_callback(&areq->cra_u.aead_req,
- CRYPTO_TFM_REQ_MAY_SLEEP |
- CRYPTO_TFM_REQ_MAY_BACKLOG,
- crypto_req_done, &ctx->wait);
- err = crypto_wait_req(ctx->enc ?
- crypto_aead_encrypt(&areq->cra_u.aead_req) :
- crypto_aead_decrypt(&areq->cra_u.aead_req),
- &ctx->wait);
- }
-
+ aead_request_set_callback(&areq->cra_u.aead_req,
+ CRYPTO_TFM_REQ_MAY_SLEEP |
+ CRYPTO_TFM_REQ_MAY_BACKLOG,
+ crypto_req_done, &ctx->wait);
+ err = crypto_wait_req(ctx->enc ?
+ crypto_aead_encrypt(&areq->cra_u.aead_req) :
+ crypto_aead_decrypt(&areq->cra_u.aead_req),
+ &ctx->wait);
free:
af_alg_free_resources(areq);
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index ba0a17fd95aca22aa58ebf510c7d9b5f0cea2c2e..9dbccabd87b13920c27aff5a450a235cc6a27d59 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -79,20 +79,6 @@ static int algif_skcipher_export(struct sock *sk, struct skcipher_request *req)
return err;
}
-static void algif_skcipher_done(void *data, int err)
-{
- struct af_alg_async_req *areq = data;
- struct sock *sk = areq->sk;
-
- if (err)
- goto out;
-
- err = algif_skcipher_export(sk, &areq->cra_u.skcipher_req);
-
-out:
- af_alg_async_cb(data, err);
-}
-
static int _skcipher_recvmsg(struct socket *sock, struct msghdr *msg,
size_t ignored, int flags)
{
@@ -171,43 +157,19 @@ static int _skcipher_recvmsg(struct socket *sock, struct msghdr *msg,
cflags |= CRYPTO_SKCIPHER_REQ_CONT;
}
- if (msg->msg_iocb && !is_sync_kiocb(msg->msg_iocb)) {
- /* AIO operation */
- sock_hold(sk);
- areq->iocb = msg->msg_iocb;
+ skcipher_request_set_callback(&areq->cra_u.skcipher_req,
+ cflags |
+ CRYPTO_TFM_REQ_MAY_SLEEP |
+ CRYPTO_TFM_REQ_MAY_BACKLOG,
+ crypto_req_done, &ctx->wait);
+ err = crypto_wait_req(ctx->enc ?
+ crypto_skcipher_encrypt(&areq->cra_u.skcipher_req) :
+ crypto_skcipher_decrypt(&areq->cra_u.skcipher_req),
+ &ctx->wait);
- /* Remember output size that will be generated. */
- areq->outlen = len;
-
- skcipher_request_set_callback(&areq->cra_u.skcipher_req,
- cflags |
- CRYPTO_TFM_REQ_MAY_SLEEP,
- algif_skcipher_done, areq);
- err = ctx->enc ?
- crypto_skcipher_encrypt(&areq->cra_u.skcipher_req) :
- crypto_skcipher_decrypt(&areq->cra_u.skcipher_req);
-
- /* AIO operation in progress */
- if (err == -EINPROGRESS)
- return -EIOCBQUEUED;
-
- sock_put(sk);
- } else {
- /* Synchronous operation */
- skcipher_request_set_callback(&areq->cra_u.skcipher_req,
- cflags |
- CRYPTO_TFM_REQ_MAY_SLEEP |
- CRYPTO_TFM_REQ_MAY_BACKLOG,
- crypto_req_done, &ctx->wait);
- err = crypto_wait_req(ctx->enc ?
- crypto_skcipher_encrypt(&areq->cra_u.skcipher_req) :
- crypto_skcipher_decrypt(&areq->cra_u.skcipher_req),
- &ctx->wait);
-
- if (!err)
- err = algif_skcipher_export(
- sk, &areq->cra_u.skcipher_req);
- }
+ if (!err)
+ err = algif_skcipher_export(
+ sk, &areq->cra_u.skcipher_req);
free:
af_alg_free_resources(areq);
diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
index 0cc8fa749f68d2356789f72771c9e550b79e0b3d..62867daca47d76c9ea1a7ed233188788c5f6c3c0 100644
--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -80,7 +80,6 @@ struct af_alg_rsgl {
/**
* struct af_alg_async_req - definition of crypto request
- * @iocb: IOCB for AIO operations
* @sk: Socket the request is associated with
* @first_rsgl: First RX SG
* @last_rsgl: Pointer to last RX SG
@@ -92,7 +91,6 @@ struct af_alg_rsgl {
* @cra_u: Cipher request
*/
struct af_alg_async_req {
- struct kiocb *iocb;
struct sock *sk;
struct af_alg_rsgl first_rsgl;
@@ -138,7 +136,7 @@ struct af_alg_async_req {
* @write: True if we are in the middle of a write.
* @init: True if metadata has been sent.
* @len: Length of memory allocated for this data structure.
- * @inflight: Non-zero when AIO requests are in flight.
+ * @inflight: Non-zero when requests are in flight, for debugging only.
*/
struct af_alg_ctx {
struct list_head tsgl_list;
@@ -237,7 +235,6 @@ int af_alg_wait_for_data(struct sock *sk, unsigned flags, unsigned min);
int af_alg_sendmsg(struct socket *sock, struct msghdr *msg, size_t size,
unsigned int ivsize);
void af_alg_free_resources(struct af_alg_async_req *areq);
-void af_alg_async_cb(void *data, int err);
__poll_t af_alg_poll(struct file *file, struct socket *sock,
poll_table *wait);
struct af_alg_async_req *af_alg_alloc_areq(struct sock *sk,
diff --git a/include/linux/socket.h b/include/linux/socket.h
index ec4a0a0257939a5363c55bed3ccb20182965b2e3..3ffdfe184b23d0a739e095407e956885d116c299 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -89,7 +89,6 @@ struct msghdr {
bool msg_get_inq : 1;/* return INQ after receive */
unsigned int msg_flags; /* flags on received message */
__kernel_size_t msg_controllen; /* ancillary data buffer length */
- struct kiocb *msg_iocb; /* ptr to iocb for async requests */
struct ubuf_info *msg_ubuf;
int (*sg_from_iter)(struct sk_buff *skb,
struct iov_iter *from, size_t length);
diff --git a/io_uring/net.c b/io_uring/net.c
index 30cd22c0b934b97ce6e265756b24daca7d398361..22100933966af547dfe6a52e69fc6882b4197234 100644
--- a/io_uring/net.c
+++ b/io_uring/net.c
@@ -771,7 +771,6 @@ static int io_recvmsg_prep_setup(struct io_kiocb *req)
kmsg->msg.msg_control = NULL;
kmsg->msg.msg_get_inq = 1;
kmsg->msg.msg_controllen = 0;
- kmsg->msg.msg_iocb = NULL;
kmsg->msg.msg_ubuf = NULL;
if (req->flags & REQ_F_BUFFER_SELECT)
diff --git a/net/compat.c b/net/compat.c
index 2c9bd0edac997bc8c6ebd1bc8b92d8437ff32ea4..d68cf9c3aad5f7f1de84edbfffcf99d71e89292a 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -75,7 +75,6 @@ int __get_compat_msghdr(struct msghdr *kmsg,
if (msg->msg_iovlen > UIO_MAXIOV)
return -EMSGSIZE;
- kmsg->msg_iocb = NULL;
kmsg->msg_ubuf = NULL;
return 0;
}
diff --git a/net/socket.c b/net/socket.c
index 22a412fdec079cf8fd829a15236de9daea09d2f2..9785363858cef0c4e6f0efc45b17c3d2add5a53c 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1213,8 +1213,7 @@ static ssize_t sock_read_iter(struct kiocb *iocb, struct iov_iter *to)
{
struct file *file = iocb->ki_filp;
struct socket *sock = file->private_data;
- struct msghdr msg = {.msg_iter = *to,
- .msg_iocb = iocb};
+ struct msghdr msg = {.msg_iter = *to};
ssize_t res;
if (file->f_flags & O_NONBLOCK || (iocb->ki_flags & IOCB_NOWAIT))
@@ -1235,8 +1234,7 @@ static ssize_t sock_write_iter(struct kiocb *iocb, struct iov_iter *from)
{
struct file *file = iocb->ki_filp;
struct socket *sock = file->private_data;
- struct msghdr msg = {.msg_iter = *from,
- .msg_iocb = iocb};
+ struct msghdr msg = {.msg_iter = *from};
ssize_t res;
if (iocb->ki_pos != 0)
@@ -2612,7 +2610,6 @@ int __copy_msghdr(struct msghdr *kmsg,
if (msg->msg_iovlen > UIO_MAXIOV)
return -EMSGSIZE;
- kmsg->msg_iocb = NULL;
kmsg->msg_ubuf = NULL;
return 0;
}
diff --git a/tools/perf/trace/beauty/include/linux/socket.h b/tools/perf/trace/beauty/include/linux/socket.h
index ec715ad4bf25f5f759d2cab3c6b796fed84df932..2a0a50fd66f41589f2699f7288a143873ce1bba6 100644
--- a/tools/perf/trace/beauty/include/linux/socket.h
+++ b/tools/perf/trace/beauty/include/linux/socket.h
@@ -89,7 +89,6 @@ struct msghdr {
bool msg_get_inq : 1;/* return INQ after receive */
unsigned int msg_flags; /* flags on received message */
__kernel_size_t msg_controllen; /* ancillary data buffer length */
- struct kiocb *msg_iocb; /* ptr to iocb for async requests */
struct ubuf_info *msg_ubuf;
int (*sg_from_iter)(struct sk_buff *skb,
struct iov_iter *from, size_t length);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v5 00/21] nfsd: add support for CB_NOTIFY callbacks in directory delegations
From: Chuck Lever @ 2026-05-23 17:00 UTC (permalink / raw)
To: NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Trond Myklebust, Anna Schumaker, Jonathan Corbet, Shuah Khan,
Jeff Layton
Cc: Chuck Lever, Steven Rostedt, Alexander Aring, Amir Goldstein,
Jan Kara, Alexander Viro, Christian Brauner, Calum Mackay,
linux-kernel, linux-doc, linux-nfs
In-Reply-To: <20260522-dir-deleg-v5-0-542cddfad576@kernel.org>
From: Chuck Lever <chuck.lever@oracle.com>
On Fri, 22 May 2026 15:42:05 -0400, Jeff Layton wrote:
> This patchset builds on the directory delegation work we did a few
> months ago, to add support for CB_NOTIFY callbacks for some events. In
> particular, creates, unlinks and renames. The server also sends updated
> directory attributes in the notifications. With this support, the client
> can register interest in a directory and get notifications about changes
> within it without losing its lease.
>
> [...]
Applied to nfsd-testing, thanks!
[01/21] nfsd: check fl_lmops in nfsd_breaker_owns_lease()
commit: 106d7871db32223d589617d9be914ff2ba51727a
[02/21] nfsd: add protocol support for CB_NOTIFY
commit: 06688aedf70b8da555a5c1d9f7feb786eb329eb4
[03/21] nfs_common: add new NOTIFY4_* flags proposed in RFC8881bis
commit: 1bdad6b6988d15ae56c97a94802cb2a603492a30
[04/21] nfsd: allow nfsd to get a dir lease with an ignore mask
commit: 6d767c6080b49d8c3d0a4971d5c30d0ad9345622
[05/21] nfsd: update the fsnotify mark when setting or removing a dir delegation
commit: b8d98337e97ca91b057abf2374dbd2a846663f68
[06/21] nfsd: make nfsd4_callback_ops->prepare operation bool return
commit: 35b3e3c47909fba5ad04349fb6ba3287c2c70d81
[07/21] nfsd: add callback encoding and decoding linkages for CB_NOTIFY
commit: 920a750c30c51ac7a884fbe93e9dc42b2ba37992
[08/21] nfsd: use RCU to protect fi_deleg_file
commit: 1b21b493326b3a782c7f0ede6d8cd47b9af662d1
[09/21] nfsd: add data structures for handling CB_NOTIFY
commit: c1810ecdb4e5c9205a6c88c86cf61689115d696f
[10/21] nfsd: add notification handlers for dir events
commit: e38c39f77041388190ebdcde9230371c180769a0
[11/21] nfsd: add tracepoint to dir_event handler
commit: cc1687d186b0542390badca86c6a87e17c95b378
[12/21] nfsd: apply the notify mask to the delegation when requested
commit: 552de5c66f1cd234bff61b5afc802cbb58928e36
[13/21] nfsd: add helper to marshal a fattr4 from completed args
commit: c452947ca425c5e5bb21382f58db015df37bb007
[14/21] nfsd: allow nfsd4_encode_fattr4_change() to work with no export
commit: ae845b96ebda28672ae1ea1ade51954cea62c2c8
[15/21] nfsd: send basic file attributes in CB_NOTIFY
commit: 259bcf6151f873f5476412140fd423a96dca7302
[16/21] nfsd: allow encoding a filehandle into fattr4 without a svc_fh
commit: 772fb85f866cb7e90a1603052416122ccdd48403
[17/21] nfsd: add a fi_connectable flag to struct nfs4_file
commit: 465b30cd8c24b04f2dcdf1e644ecae87cf847e8b
[18/21] nfsd: add the filehandle to returned attributes in CB_NOTIFY
commit: b146f3a075b320e76fccecc0dcebef7cd894364f
[19/21] nfsd: properly track requested child attributes
commit: 8a5ceb0668d694dd8370ee1d702800e730c862b7
[20/21] nfsd: track requested dir attributes
commit: 824c7f03f1fbeea6f92d0f4da7dca3ecad27cc3a
[21/21] nfsd: add support to CB_NOTIFY for dir attribute changes
commit: 9e0982d08e135a46aab2bd6d7fe8609c27a8806e
--
Chuck Lever <chuck.lever@oracle.com>
^ permalink raw reply
* Re: DEPT (the dependency tracker) as AI review prompt?
From: Yunseong Kim @ 2026-05-23 15:04 UTC (permalink / raw)
To: Harry Yoo, Yunseong Kim
Cc: Byungchul Park, linux-kernel, kernel_team, torvalds,
damien.lemoal, linux-ide, adilger.kernel, linux-ext4, mingo,
peterz, will, tglx, rostedt, joel, sashal, daniel.vetter,
duyuyang, johannes.berg, tj, tytso, willy, david, amir73il,
gregkh, kernel-team, linux-mm, akpm, mhocko, minchan, hannes,
vdavydov.dev, sj, jglisse, dennis, cl, penberg, rientjes, vbabka,
ngupta, linux-block, linux-fsdevel, jack, jlayton, dan.j.williams,
hch, djwong, dri-devel, rodrigosiqueiramelo, melissa.srw,
hamohammed.sa, harry.yoo, chris.p.wilson, gwan-gyeong.mun,
max.byungchul.park, boqun.feng, longman, yunseong.kim,
yeoreum.yun, netdev, matthew.brost, her0gyugyu, corbet,
catalin.marinas, bp, x86, hpa, luto, sumit.semwal, gustavo,
christian.koenig, andi.shyti, arnd, lorenzo.stoakes, Liam.Howlett,
rppt, surenb, mcgrof, petr.pavlu, da.gomez, samitolvanen, paulmck,
frederic, neeraj.upadhyay, joelagnelf, josh, urezki,
mathieu.desnoyers, jiangshanlai, qiang.zhang, juri.lelli,
vincent.guittot, dietmar.eggemann, bsegall, mgorman, vschneid,
chuck.lever, neil, okorniev, Dai.Ngo, tom, trondmy, anna, kees,
bigeasy, clrkwllms, mark.rutland, ada.coupriediaz,
kristina.martsenko, wangkefeng.wang, broonie, kevin.brodsky, dwmw,
shakeel.butt, ast, ziy, yuzhao, baolin.wang, usamaarif642,
joel.granados, richard.weiyang, geert+renesas, tim.c.chen, linux,
alexander.shishkin, lillian, chenhuacai, francesco,
guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, miguel.ojeda.sandonis, neilb, bagasdotme,
wsa+renesas, dave.hansen, geert, ojeda, alex.gaynor, gary,
bjorn3_gh, lossin, a.hindborg, aliceryhl, tmgross, rust-for-linux,
Chris Mason, Roman Gushchin, Josef Bacik
In-Reply-To: <0592b09b-a084-4d9d-bcbf-1b77e45226cf@kernel.org>
Hi Harry,
On 5/23/26 16:34, Harry Yoo wrote:
>
>
> On 5/23/26 11:00 PM, Yunseong Kim wrote:
>> I've previously experimented with running DEPT alongside syzkaller fuzzing,
>> and many hung tasks missed by lockdep are caught by DEPT, but the resulting
>> high volume of reports makes it easy for issues to get lost in the massive
>> log output. Sorting through that output manually is a huge bottleneck, so
>> leveraging a well-crafted AI prompt to triage the warnings and filter out
>> the false positives would be incredibly valuable.
>
> I mean both 1) detection of deadlock issues AND 2) false positive elimination with AI.
I completely agree. Implanting DEPT's model into an AI review prompt
is a great idea. As you suggested, the patterns we develop for the AI
could provide valuable feedback to enhance DEPT's itself.
> If the review prompt is only used to eliminate DEPT's false positives, I think that would be quite hard to get broad use.
>
> Someone would have to build out-of-tree DEPT, collect the reports, and then feed those back into the AI. I don't think building that kind of pipeline would actually work well in practice.
I also have a huge dept report of DEPT reports, and manually
reviewing all of them is makes me sigh. The constant kernel rebuilds
required for lockup testing every time are also quite expensive.
Thanks for the summary!
Best Regards,
Yunseong
^ permalink raw reply
* Re: DEPT (the dependency tracker) as AI review prompt?
From: Harry Yoo @ 2026-05-23 14:34 UTC (permalink / raw)
To: Yunseong Kim
Cc: Byungchul Park, linux-kernel, kernel_team, torvalds,
damien.lemoal, linux-ide, adilger.kernel, linux-ext4, mingo,
peterz, will, tglx, rostedt, joel, sashal, daniel.vetter,
duyuyang, johannes.berg, tj, tytso, willy, david, amir73il,
gregkh, kernel-team, linux-mm, akpm, mhocko, minchan, hannes,
vdavydov.dev, sj, jglisse, dennis, cl, penberg, rientjes, vbabka,
ngupta, linux-block, linux-fsdevel, jack, jlayton, dan.j.williams,
hch, djwong, dri-devel, rodrigosiqueiramelo, melissa.srw,
hamohammed.sa, harry.yoo, chris.p.wilson, gwan-gyeong.mun,
max.byungchul.park, boqun.feng, longman, yunseong.kim,
yeoreum.yun, netdev, matthew.brost, her0gyugyu, corbet,
catalin.marinas, bp, x86, hpa, luto, sumit.semwal, gustavo,
christian.koenig, andi.shyti, arnd, lorenzo.stoakes, Liam.Howlett,
rppt, surenb, mcgrof, petr.pavlu, da.gomez, samitolvanen, paulmck,
frederic, neeraj.upadhyay, joelagnelf, josh, urezki,
mathieu.desnoyers, jiangshanlai, qiang.zhang, juri.lelli,
vincent.guittot, dietmar.eggemann, bsegall, mgorman, vschneid,
chuck.lever, neil, okorniev, Dai.Ngo, tom, trondmy, anna, kees,
bigeasy, clrkwllms, mark.rutland, ada.coupriediaz,
kristina.martsenko, wangkefeng.wang, broonie, kevin.brodsky, dwmw,
shakeel.butt, ast, ziy, yuzhao, baolin.wang, usamaarif642,
joel.granados, richard.weiyang, geert+renesas, tim.c.chen, linux,
alexander.shishkin, lillian, chenhuacai, francesco,
guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, miguel.ojeda.sandonis, neilb, bagasdotme,
wsa+renesas, dave.hansen, geert, ojeda, alex.gaynor, gary,
bjorn3_gh, lossin, a.hindborg, aliceryhl, tmgross, rust-for-linux,
Chris Mason, Roman Gushchin, Josef Bacik, Yunseong Kim
In-Reply-To: <CA+7O06GxeDLR9RcKDN2i-Rgc4kgzz6BfF4b0XAH4tFx=A723Nw@mail.gmail.com>
On 5/23/26 11:00 PM, Yunseong Kim wrote:
> I've previously experimented with running DEPT alongside syzkaller fuzzing,
> and many hung tasks missed by lockdep are caught by DEPT, but the resulting
> high volume of reports makes it easy for issues to get lost in the massive
> log output. Sorting through that output manually is a huge bottleneck, so
> leveraging a well-crafted AI prompt to triage the warnings and filter out
> the false positives would be incredibly valuable.
I mean both 1) detection of deadlock issues AND 2) false positive
elimination with AI.
If the review prompt is only used to eliminate DEPT's false positives, I
think that would be quite hard to get broad use.
Someone would have to build out-of-tree DEPT, collect the reports, and
then feed those back into the AI. I don't think building that kind of
pipeline would actually work well in practice.
--
Cheers,
Harry / Hyeonggon
^ permalink raw reply
* Re: [PATCH 4/5] mm: enable map_anon_folio_pmd_nopf to handle unshare
From: kernel test robot @ 2026-05-23 14:25 UTC (permalink / raw)
To: Luka Bai, Luka Bai
Cc: oe-lkp, lkp, linux-mm, Jonathan Corbet, Shuah Khan, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Zi Yan, Baolin Wang,
Liam R. Howlett, Nico Pache, Ryan Roberts, Dev Jain, Barry Song,
Lance Yang, Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan,
Michal Hocko, Jann Horn, Arnd Bergmann, Kairui Song, linux-kernel,
linux-arch, linux-doc, Luka Bai, oliver.sang
In-Reply-To: <20260501-thp_cow-v1-4-005377483738@tencent.com>
Hello,
kernel test robot noticed "BUG:kernel_NULL_pointer_dereference,address" on:
commit: 419ac88f7d747a174b48e12d2fd2178a128f54de ("[PATCH 4/5] mm: enable map_anon_folio_pmd_nopf to handle unshare")
url: https://github.com/intel-lab-lkp/linux/commits/Luka-Bai/mm-add-basic-madvise-helpers-and-branch-for-THP-setup/20260502-230731
patch link: https://lore.kernel.org/all/20260501-thp_cow-v1-4-005377483738@tencent.com/
patch subject: [PATCH 4/5] mm: enable map_anon_folio_pmd_nopf to handle unshare
in testcase: boot
config: x86_64-kexec
compiler: clang-20
test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 32G
(please refer to attached dmesg/kmsg for entire log/backtrace)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202605231645.88096ca9-lkp@intel.com
[ 15.354503][ T37] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 15.355458][ T37] #PF: supervisor write access in kernel mode
[ 15.356077][ T37] #PF: error_code(0x0002) - not-present page
[ 15.356690][ T37] PGD 0 P4D 0
[ 15.357088][ T37] Oops: Oops: 0002 [#1] SMP PTI
[ 15.357612][ T37] CPU: 0 UID: 0 PID: 37 Comm: khugepaged Not tainted 7.1.0-rc1-00099-g419ac88f7d74 #1 PREEMPT(lazy)
[ 15.358688][ T37] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 15.362222][ T37] RIP: 0010:map_anon_folio_pmd_nopf (x86/include/asm/pgtable_64.h:79 x86/include/asm/pgtable.h:1210 huge_memory.c:1448)
[ 15.364849][ T37] Code: e0 ff 48 89 df 4c 89 f6 4c 89 c2 b9 01 00 00 00 e8 b7 a2 fa ff 48 89 df 4c 89 f6 e8 6c 93 f4 ff 4c 89 64 24 20 48 8b 44 24 20 <49> 89 07 48 89 df 31 f6 48 83 c4 28 5b 41 5c 41 5d 41 5e 41 5f 5d
All code
========
0: e0 ff loopne 0x1
2: 48 89 df mov %rbx,%rdi
5: 4c 89 f6 mov %r14,%rsi
8: 4c 89 c2 mov %r8,%rdx
b: b9 01 00 00 00 mov $0x1,%ecx
10: e8 b7 a2 fa ff call 0xfffffffffffaa2cc
15: 48 89 df mov %rbx,%rdi
18: 4c 89 f6 mov %r14,%rsi
1b: e8 6c 93 f4 ff call 0xfffffffffff4938c
20: 4c 89 64 24 20 mov %r12,0x20(%rsp)
25: 48 8b 44 24 20 mov 0x20(%rsp),%rax
2a:* 49 89 07 mov %rax,(%r15) <-- trapping instruction
2d: 48 89 df mov %rbx,%rdi
30: 31 f6 xor %esi,%esi
32: 48 83 c4 28 add $0x28,%rsp
36: 5b pop %rbx
37: 41 5c pop %r12
39: 41 5d pop %r13
3b: 41 5e pop %r14
3d: 41 5f pop %r15
3f: 5d pop %rbp
Code starting with the faulting instruction
===========================================
0: 49 89 07 mov %rax,(%r15)
3: 48 89 df mov %rbx,%rdi
6: 31 f6 xor %esi,%esi
8: 48 83 c4 28 add $0x28,%rsp
c: 5b pop %rbx
d: 41 5c pop %r12
f: 41 5d pop %r13
11: 41 5e pop %r14
13: 41 5f pop %r15
15: 5d pop %rbp
[ 15.372240][ T37] RSP: 0000:ffffc9000013fb70 EFLAGS: 00010282
[ 15.374712][ T37] RAX: 8000000143a000e7 RBX: ffffea00050e8000 RCX: 0000000000000000
[ 15.377932][ T37] RDX: 000000000000021f RSI: ffff88881fc271b0 RDI: ffff88881fc30640
[ 15.381250][ T37] RBP: 0000000000000000 R08: 0000000000071ce9 R09: 000000000000b2e9
[ 15.384563][ T37] R10: 0000000000000001 R11: 000000000000003f R12: 8000000143a000e7
[ 15.387726][ T37] R13: 8000000000000025 R14: ffff88810e098900 R15: 0000000000000000
[ 15.391175][ T37] FS: 0000000000000000(0000) GS:ffff88889c101000(0000) knlGS:0000000000000000
[ 15.394883][ T37] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 15.397492][ T37] CR2: 0000000000000000 CR3: 0000000163644000 CR4: 00000000000406f0
[ 15.400508][ T37] Call Trace:
[ 15.403414][ T37] <TASK>
[ 15.404723][ T37] ? lruvec_stat_mod_folio (memcontrol.c:993)
[ 15.406687][ T37] collapse_single_pmd (khugepaged.c:1411)
[ 15.408449][ T37] ? __pfx_wq_barrier_func (workqueue.c:1144)
[ 15.410197][ T37] ? __thp_vma_allowable_orders (huge_memory.c:124)
[ 15.412115][ T37] khugepaged (khugepaged.c:2901)
[ 15.413596][ T37] ? __pfx_khugepaged (khugepaged.c:3113)
[ 15.415388][ T37] kthread (kthread.c:436)
[ 15.416719][ T37] ? __pfx_kthread (kthread.c:1738)
[ 15.418155][ T37] ret_from_fork (x86/kernel/process.c:158)
[ 15.419600][ T37] ? __pfx_kthread (kthread.c:1738)
[ 15.421001][ T37] ret_from_fork_asm (x86/entry/entry_64.S:245)
[ 15.422510][ T37] </TASK>
[ 15.423538][ T37] Modules linked in: sr_mod cdrom sg ata_generic fuse
[ 15.425454][ T37] CR2: 0000000000000000
[ 15.426674][ T37] ---[ end trace 0000000000000000 ]---
[ 15.428142][ T37] RIP: 0010:map_anon_folio_pmd_nopf (x86/include/asm/pgtable_64.h:79 x86/include/asm/pgtable.h:1210 huge_memory.c:1448)
[ 15.429793][ T37] Code: e0 ff 48 89 df 4c 89 f6 4c 89 c2 b9 01 00 00 00 e8 b7 a2 fa ff 48 89 df 4c 89 f6 e8 6c 93 f4 ff 4c 89 64 24 20 48 8b 44 24 20 <49> 89 07 48 89 df 31 f6 48 83 c4 28 5b 41 5c 41 5d 41 5e 41 5f 5d
All code
========
0: e0 ff loopne 0x1
2: 48 89 df mov %rbx,%rdi
5: 4c 89 f6 mov %r14,%rsi
8: 4c 89 c2 mov %r8,%rdx
b: b9 01 00 00 00 mov $0x1,%ecx
10: e8 b7 a2 fa ff call 0xfffffffffffaa2cc
15: 48 89 df mov %rbx,%rdi
18: 4c 89 f6 mov %r14,%rsi
1b: e8 6c 93 f4 ff call 0xfffffffffff4938c
20: 4c 89 64 24 20 mov %r12,0x20(%rsp)
25: 48 8b 44 24 20 mov 0x20(%rsp),%rax
2a:* 49 89 07 mov %rax,(%r15) <-- trapping instruction
2d: 48 89 df mov %rbx,%rdi
30: 31 f6 xor %esi,%esi
32: 48 83 c4 28 add $0x28,%rsp
36: 5b pop %rbx
37: 41 5c pop %r12
39: 41 5d pop %r13
3b: 41 5e pop %r14
3d: 41 5f pop %r15
3f: 5d pop %rbp
Code starting with the faulting instruction
===========================================
0: 49 89 07 mov %rax,(%r15)
3: 48 89 df mov %rbx,%rdi
6: 31 f6 xor %esi,%esi
8: 48 83 c4 28 add $0x28,%rsp
c: 5b pop %rbx
d: 41 5c pop %r12
f: 41 5d pop %r13
11: 41 5e pop %r14
13: 41 5f pop %r15
15: 5d pop %rbp
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260523/202605231645.88096ca9-lkp@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v4 2/4] hwmon: (pmbus/tps25990): Rework TPS25990 direct conversion handling
From: Guenter Roeck @ 2026-05-23 14:17 UTC (permalink / raw)
To: Stoyan Bogdanov, jbrunet, robh, krzk+dt, conor+dt, corbet, skhan
Cc: linux-hwmon, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260522082349.2749970-3-sbogdanov@baylibre.com>
On 5/22/26 01:23, Stoyan Bogdanov wrote:
> Rework the existing implementation of direct format conversion for
> TPS25990 non-standard parameters to improve code reusability and
> integration with the PMBus direct conversion helpers.
>
> Changes include:
> - Add an enum describing the supported parameters
> - Add structure to hold m, b, R per-device coefficients
> - Add data structures for pmbus_driver_info and local direct values
> - Use the generic PMBus conversion helpers:
> pmbus_reg2data_direct_calc()
> pmbus_data2reg_direct_calc()
> - Replace previously used defines with structured data
>
> This reduces duplicated conversion logic and makes handling of
> non-standard parameters more maintainable.
>
> Signed-off-by: Stoyan Bogdanov <sbogdanov@baylibre.com>
> ---
> drivers/hwmon/pmbus/tps25990.c | 197 +++++++++++++++++++++------------
> 1 file changed, 127 insertions(+), 70 deletions(-)
>
> diff --git a/drivers/hwmon/pmbus/tps25990.c b/drivers/hwmon/pmbus/tps25990.c
> index 05c6288ecafc..1e252844217b 100644
> --- a/drivers/hwmon/pmbus/tps25990.c
> +++ b/drivers/hwmon/pmbus/tps25990.c
> @@ -36,17 +36,63 @@
> #define TPS25990_UNLOCKED BIT(7)
>
> #define TPS25990_8B_SHIFT 2
> -#define TPS25990_VIN_OVF_NUM 525100
> -#define TPS25990_VIN_OVF_DIV 10163
> -#define TPS25990_VIN_OVF_OFF 155
> -#define TPS25990_IIN_OCF_NUM 953800
> -#define TPS25990_IIN_OCF_DIV 129278
> -#define TPS25990_IIN_OCF_OFF 157
>
> #define PK_MIN_AVG_RST_MASK (PK_MIN_AVG_RST_PEAK | \
> PK_MIN_AVG_RST_AVG | \
> PK_MIN_AVG_RST_MIN)
>
> +enum chips {
> + tps25990,
> +};
> +
> +enum tps25990_parameters {
> + TPS25990_VIN_OVF = 0, /* VIN over volatage fault */
> + TPS25990_IIN_OCF, /* IIN Over currect fault */
> + TPS25990_DIRECT_VALUES_COUNT,
> +};
> +
> +struct tps25990_local_direct_value {
> + int m[TPS25990_DIRECT_VALUES_COUNT]; /* mantissa */
> + int b[TPS25990_DIRECT_VALUES_COUNT]; /* offset */
> + int R[TPS25990_DIRECT_VALUES_COUNT]; /* exponent */
> +};
> +
> +struct tps25990_data {
> + struct pmbus_driver_info info;
> + struct tps25990_local_direct_value info_local;
> +};
> +
> +static s64 tps25990_reg2data_direct(struct i2c_client *client, int param, s32 raw)
> +{
> + struct pmbus_driver_info *info = i2c_get_clientdata(client);
> + struct tps25990_data *data = container_of(info, struct tps25990_data, info);
> + struct tps25990_local_direct_value *info_local = &data->info_local;
> + s64 b, val;
> + s32 m, R;
> +
> + val = (s16)raw;
> + m = info_local->m[param];
> + b = info_local->b[param];
> + R = info_local->R[param];
> +
> + return pmbus_reg2data_direct_calc(val, b, m, R);
> +}
> +
> +static u16 tps25990_data2reg_direct(struct i2c_client *client, int param, s64 val)
> +{
> + struct pmbus_driver_info *info = i2c_get_clientdata(client);
> + struct tps25990_data *data = container_of(info, struct tps25990_data, info);
> + struct tps25990_local_direct_value *info_local = &data->info_local;
> + s32 m, R;
> + s64 b;
> +
> + m = info_local->m[param];
> + b = info_local->b[param];
> + R = info_local->R[param];
> +
> + return pmbus_data2reg_direct_calc(val, b, m, R);
> +}
> +
> /*
> * Arbitrary default Rimon value: 1kOhm
> * This correspond to an overcurrent limit of 55A, close to the specified limit
> @@ -184,9 +230,7 @@ static int tps25990_read_word_data(struct i2c_client *client,
> ret = pmbus_read_word_data(client, page, phase, reg);
> if (ret < 0)
> break;
> - ret = DIV_ROUND_CLOSEST(ret * TPS25990_VIN_OVF_NUM,
> - TPS25990_VIN_OVF_DIV);
> - ret += TPS25990_VIN_OVF_OFF;
> + ret = tps25990_reg2data_direct(client, TPS25990_VIN_OVF, ret);
The result is again evaluated by the PMBus core as direct register value,
not as calculated fault limit. I don't think this works as expected.
This isn't about converting a register value to a voltage, it is about
converting one direct format into another. Using (or trying to use)
reg2data_direct is at the very least misleading, if not completely wrong.
The m/b/R parameters below are the coefficients from the datasheet to convert
the register values into voltages. The PMBus core will take that value and
convert it again into a voltage, this time using the m/b/R coefficients
for input voltages. This can not be correct. To be technically correct,
the core would have to convert the register value to a voltage using one
set of m/b/R coefficients and then convert it back to direct format using
the other set of m/b/R coefficients. The current code does that by adjusting
the values directly. I don't think changing is really beneficial. If anything,
documenting it would be more helpful.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v1 1/4] driver core: allow certain drivers prohibit override via sysfs
From: kernel test robot @ 2026-05-23 14:13 UTC (permalink / raw)
To: Andy Shevchenko
Cc: oe-lkp, lkp, driver-core, Danilo Krummrich, Andy Shevchenko,
Mark Brown, linux-doc, linux-kernel, linux-iio, linux-spi,
Greg Kroah-Hartman, Rafael J. Wysocki, Jonathan Corbet,
Shuah Khan, Jean-Baptiste Maneyrol, Jonathan Cameron,
David Lechner, =?UTF-8?q?Nuno=20S=C3=A1?=, Andy Shevchenko,
oliver.sang
In-Reply-To: <20260508095224.1275645-2-andriy.shevchenko@linux.intel.com>
Hello,
kernel test robot noticed "Oops:general_protection_fault,probably_for_non-canonical_address#:#[##]SMP_KASAN_PTI" on:
commit: f93c013feebc74afe81ce1ffd045c1625b86c4ce ("[PATCH v1 1/4] driver core: allow certain drivers prohibit override via sysfs")
url: https://github.com/intel-lab-lkp/linux/commits/Andy-Shevchenko/driver-core-allow-certain-drivers-prohibit-override-via-sysfs/20260513-124947
patch link: https://lore.kernel.org/all/20260508095224.1275645-2-andriy.shevchenko@linux.intel.com/
patch subject: [PATCH v1 1/4] driver core: allow certain drivers prohibit override via sysfs
in testcase: boot
config: x86_64-rhel-9.4-kunit
compiler: gcc-14
test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 32G
(please refer to attached dmesg/kmsg for entire log/backtrace)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202605231602.b6990b2a-lkp@intel.com
[ 98.674811][ T2697] ppdev: user-space parallel port driver
[ 98.682051][ T2693] RAPL PMU: API unit is 2^-32 Joules, 0 fixed counters, 10737418240 ms ovfl timer
[ 98.749342][ T2701] Error: Driver 'pcspkr' is already registered, aborting...
[ 98.754059][ T2699] sr 1:0:0:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray
[ 98.754984][ T2699] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 98.756646][ T2690] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000004: 0000 [#1] SMP KASAN PTI
[ 98.757883][ T2690] KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
[ 98.758816][ T2690] CPU: 1 UID: 0 PID: 2690 Comm: udevd Not tainted 7.1.0-rc1+ #1 PREEMPT(lazy)
[ 98.759772][ T2690] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 98.760884][ T2690] RIP: 0010:bus_remove_device (kbuild/src/drivers/base/bus.c:656 (discriminator 1))
[ 98.761606][ T2690] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 dc 01 00 00 48 ba 00 00 00 00 00 fc ff df 48 8b 43 68 48 8d 78 21 48 89 f9 48 c1 e9 03 <0f> b6 14 11 48 89 f9 83 e1 07 38 ca 7f 08 84 d2 0f 85 84 01 00 00
All code
========
0: 48 89 fa mov %rdi,%rdx
3: 48 c1 ea 03 shr $0x3,%rdx
7: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1)
b: 0f 85 dc 01 00 00 jne 0x1ed
11: 48 ba 00 00 00 00 00 movabs $0xdffffc0000000000,%rdx
18: fc ff df
1b: 48 8b 43 68 mov 0x68(%rbx),%rax
1f: 48 8d 78 21 lea 0x21(%rax),%rdi
23: 48 89 f9 mov %rdi,%rcx
26: 48 c1 e9 03 shr $0x3,%rcx
2a:* 0f b6 14 11 movzbl (%rcx,%rdx,1),%edx <-- trapping instruction
2e: 48 89 f9 mov %rdi,%rcx
31: 83 e1 07 and $0x7,%ecx
34: 38 ca cmp %cl,%dl
36: 7f 08 jg 0x40
38: 84 d2 test %dl,%dl
3a: 0f 85 84 01 00 00 jne 0x1c4
Code starting with the faulting instruction
===========================================
0: 0f b6 14 11 movzbl (%rcx,%rdx,1),%edx
4: 48 89 f9 mov %rdi,%rcx
7: 83 e1 07 and $0x7,%ecx
a: 38 ca cmp %cl,%dl
c: 7f 08 jg 0x16
e: 84 d2 test %dl,%dl
10: 0f 85 84 01 00 00 jne 0x19a
[ 98.763619][ T2690] RSP: 0018:ffffc9000075efd0 EFLAGS: 00010202
[ 98.764294][ T2690] RAX: 0000000000000000 RBX: ffff8881d0677010 RCX: 0000000000000004
[ 98.765179][ T2690] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: 0000000000000021
[ 98.766066][ T2690] RBP: ffff888100348c00 R08: 0000000000000001 R09: ffffed1020060f55
[ 98.766979][ T2690] R10: ffff888100307aaf R11: fffffffface0012b R12: ffffffffb0964be0
[ 98.767842][ T2690] R13: 1ffff920000ebdfc R14: ffff888100348c58 R15: ffff8881d0677060
[ 98.768702][ T2690] FS: 00007fb9b77bc300(0000) GS:ffff88876b59b000(0000) knlGS:0000000000000000
[ 98.769674][ T2690] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 98.770377][ T2690] CR2: 00007fb9b77898e0 CR3: 000000023c500000 CR4: 00000000000406f0
[ 98.771294][ T2690] Call Trace:
[ 98.771694][ T2690] <TASK>
[ 98.772063][ T2690] ? __pfx_bus_remove_device (kbuild/src/drivers/base/bus.c:623)
[ 98.772686][ T2690] ? __pfx_device_remove_attrs (kbuild/src/drivers/base/core.c:3073)
[ 98.773297][ T2690] device_del (kbuild/src/drivers/base/core.c:3891)
[ 98.773787][ T2690] ? __pfx_device_del (kbuild/src/include/linux/kobject.h:89)
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260523/202605231602.b6990b2a-lkp@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: DEPT (the dependency tracker) as AI review prompt? (was: DEPT v18)
From: Yunseong Kim @ 2026-05-23 14:00 UTC (permalink / raw)
To: Harry Yoo
Cc: Byungchul Park, linux-kernel, kernel_team, torvalds,
damien.lemoal, linux-ide, adilger.kernel, linux-ext4, mingo,
peterz, will, tglx, rostedt, joel, sashal, daniel.vetter,
duyuyang, johannes.berg, tj, tytso, willy, david, amir73il,
gregkh, kernel-team, linux-mm, akpm, mhocko, minchan, hannes,
vdavydov.dev, sj, jglisse, dennis, cl, penberg, rientjes, vbabka,
ngupta, linux-block, linux-fsdevel, jack, jlayton, dan.j.williams,
hch, djwong, dri-devel, rodrigosiqueiramelo, melissa.srw,
hamohammed.sa, harry.yoo, chris.p.wilson, gwan-gyeong.mun,
max.byungchul.park, boqun.feng, longman, yunseong.kim, ysk,
yeoreum.yun, netdev, matthew.brost, her0gyugyu, corbet,
catalin.marinas, bp, x86, hpa, luto, sumit.semwal, gustavo,
christian.koenig, andi.shyti, arnd, lorenzo.stoakes, Liam.Howlett,
rppt, surenb, mcgrof, petr.pavlu, da.gomez, samitolvanen, paulmck,
frederic, neeraj.upadhyay, joelagnelf, josh, urezki,
mathieu.desnoyers, jiangshanlai, qiang.zhang, juri.lelli,
vincent.guittot, dietmar.eggemann, bsegall, mgorman, vschneid,
chuck.lever, neil, okorniev, Dai.Ngo, tom, trondmy, anna, kees,
bigeasy, clrkwllms, mark.rutland, ada.coupriediaz,
kristina.martsenko, wangkefeng.wang, broonie, kevin.brodsky, dwmw,
shakeel.butt, ast, ziy, yuzhao, baolin.wang, usamaarif642,
joel.granados, richard.weiyang, geert+renesas, tim.c.chen, linux,
alexander.shishkin, lillian, chenhuacai, francesco,
guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, miguel.ojeda.sandonis, neilb, bagasdotme,
wsa+renesas, dave.hansen, geert, ojeda, alex.gaynor, gary,
bjorn3_gh, lossin, a.hindborg, aliceryhl, tmgross, rust-for-linux,
Chris Mason, Roman Gushchin, Josef Bacik, Yunseong Kim
In-Reply-To: <6b2a816f-eb3b-4e0c-a024-ee2e3743eb04@kernel.org>
Hi Harry,
On Sat, May 23, 2026 at 2:33 PM Harry Yoo <harry@kernel.org> wrote:
>
> Can we start DEPT as an AI review prompt, by documenting DEPT's
> dependency tracking model and false positive elimination rules as a
> carefully crafted prompt?
>
> While DEPT can identify deadlock issues beyond lockdep's capabilities,
> it is hard to enable in automated testing; without fine-grained
> annotations it can produce a high rate of false positives, and verifying
> them requires significant human effort.
>
> The open source AI Review Prompt has locking.md file [1] that teaches
> the AI how to review locks and detect misuse.
>
> If we can write a review prompt for DEPT in a similar manner and have
> the AI do the deadlock detection and false positive elimination, I think
> we could identify those problems more effectively with much less human
> effort.
>
> [1]
> https://github.com/masoncl/review-prompts/blob/main/kernel/subsystem/locking.md
>
> --
> Cheers,
> Harry / Hyeonggon
I think this is an excellent idea, Harry.
I've previously experimented with running DEPT alongside syzkaller fuzzing,
and many hung tasks missed by lockdep are caught by DEPT, but the resulting
high volume of reports makes it easy for issues to get lost in the massive
log output. Sorting through that output manually is a huge bottleneck, so
leveraging a well-crafted AI prompt to triage the warnings and filter out
the false positives would be incredibly valuable.
Leveraging an AI prompt to triage these warnings would be incredibly valuable.
I'd be happy to help translate DEPT's tracking model into specific rules for
reducing false positives and establishing solid filtering patterns.
> On 12/5/25 4:18 PM, Byungchul Park wrote:
> > I'm happy to see that DEPT reported real problems in practice:
> >
> > https://lore.kernel.org/lkml/6383cde5-cf4b-facf-6e07-1378a485657d@I-love.SAKURA.ne.jp/
> > https://lore.kernel.org/lkml/1674268856-31807-1-git-send-email-byungchul.park@lge.com/
> > https://lore.kernel.org/all/b6e00e77-4a8c-4e05-ab79-266bf05fcc2d@igalia.com/
> >
> > I’ve added documentation describing DEPT — this should help you
> > understand what DEPT is and how it works. You can use DEPT simply by
> > enabling CONFIG_DEPT and checking dmesg at runtime.
> > ---
> >
> > Hi Linus and folks,
> >
> > I’ve been developing a tool to detect deadlock possibilities by tracking
> > waits/events — rather than lock acquisition order — to cover all the
> > synchronization mechanisms. To summarize the design rationale, starting
> > from the problem statement, through analysis, to the solution:
> >
> > CURRENT STATUS
> > --------------
> > Lockdep tracks lock acquisition order to identify deadlock conditions.
> > Additionally, it tracks IRQ state changes — via {en,dis}able — to
> > detect cases where locks are acquired unintentionally during
> > interrupt handling.
> >
> > PROBLEM
> > -------
> > Waits and their associated events that are never reachable can
> > eventually lead to deadlocks. However, since Lockdep focuses solely
> > on lock acquisition order, it has inherent limitations when handling
> > waits and events.
> >
> > Moreover, by tracking only lock acquisition order, Lockdep cannot
> > properly handle read locks or cross-event scenarios — such as
> > wait_for_completion() and complete() — making it increasingly
> > inadequate as a general-purpose deadlock detection tool.
> >
> > SOLUTION
> > --------
> > Once again, waits and their associated events that are never
> > reachable can eventually lead to deadlocks. The new solution, DEPT,
> > focuses directly on waits and events. DEPT monitors waits and events,
> > and reports them when any become unreachable.
> >
> > DEPT provides:
> >
> > * Correct handling of read locks.
> > * Support for general waits and events.
> > * Continuous operation, even after multiple reports.
> > * Simple, intuitive annotation APIs.
> >
> > There are still false positives, and some are already being worked on
> > for suppression. Especially splitting the folio class into several
> > appropriate classes e.g. block device mapping class and regular file
> > mapping class, is currently under active development by me and Yeoreum
> > Yun.
> >> Anyway, these efforts will need to continue for a while, as we’ve seen
> > with lockdep over two decades. DEPT is tagged as EXPERIMENTAL in
> > Kconfig — meaning it’s not yet suitable for use as an automation tool.
> >
> > However, for those who are interested in using DEPT to analyze complex
> > synchronization patterns and extract dependency insights, DEPT would be
> > a great tool for the purpose.
Best regards,
Yunseong
^ permalink raw reply
* Re: [PATCH v3] killswitch: add per-function short-circuit mitigation primitive
From: Sasha Levin @ 2026-05-23 13:41 UTC (permalink / raw)
To: Song Liu
Cc: Daniel Borkmann, linux-kernel, linux-doc, linux-kselftest, bpf,
live-patching, Greg Kroah-Hartman, Andrew Morton, Jonathan Corbet,
Mathieu Desnoyers, Joshua Peisach, Florian Weimer, Breno Leitao,
Anthony Iliopoulos, Michal Hocko, Jiri Olsa, John Fastabend,
Christian Brauner, KP Singh
In-Reply-To: <CAPhsuW7sbt5B+ZeGW8O2JMJ0ELPU-vhZFNvbB+0Q8XhZg6pKYw@mail.gmail.com>
On Thu, May 21, 2026 at 11:16:46AM -0700, Song Liu wrote:
>On Thu, May 21, 2026 at 8:31 AM Sasha Levin <sashal@kernel.org> wrote:
>>
>> On Thu, May 21, 2026 at 11:11:16AM +0200, Daniel Borkmann wrote:
>> >On 5/19/26 9:57 PM, Sasha Levin wrote:
>> >>Sure, this would also work. How do you see this happening? Can we let a certain
>> >>user/pid/etc disable the allowlist if they choose to?
>> >
>> >I don't think we should, given then we're back to square one where root
>> >or some other user would be able to just override/bypass an LSM.
>>
>> killswitch already disables itself when lockdown is active. We can easily
>> disable it too when one of the LSMs that cares about this is active.
>>
>> >[...]
>> >>How do you see this working with the allowlist?
>> >
>> >We should look at the underlying areas where most of the CVE-like fixes
>> >took place (these days should be more easily doable given Claude and friends)
>> >and based on that either extend ALLOW_ERROR_INJECTION() or (better) create
>> >new hooks which BPF LSM can consume where you can then have a policy to reject
>> >requests and tighten the attack surface. For example, the AF_ALG stuff you
>>
>> So we could grow the LSM tentacles deeper into the kernel, and we can see where
>> current CVEs are happening, which I suspect is the darker corners of the kernel
>> (old unmaintained, rarely used code), but this definitely won't stay the case,
>> right? Newer and better LLMs will discover issues elsewhere, and once the low
>> hanging fruits are picked off of the current target subsystems, researchers
>> will move elsewhere. We will be dooming ourselves to an endless cat and mouse
>> game where we go add LSM hooks after some big security issue goes public.
>
>Do we really need to add new LSM hooks for recent CVEs?
>
>The LSM hooks are designed to cover all the user-kernel interfaces. Then
>with properly designed policies, we should have coverage for potential CVEs.
>Existing LSM hooks may not be perfect, but we can improve the hooks,
>potentially with the help of smart LLMs, so that these hooks can cover
>future security issues. In some cases, we will need new policies, but I don't
>think new hooks will be needed for most of these CVEs.
Running a quick LLM evaluation on the last ~70 severe CVEs, it seems that about
40% is doable with the current hooks.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v4 1/4] hwmon: (pmbus) Add and export direct conversion calculation helpers
From: Guenter Roeck @ 2026-05-23 13:25 UTC (permalink / raw)
To: Stoyan Bogdanov, jbrunet, robh, krzk+dt, conor+dt, corbet, skhan
Cc: linux-hwmon, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260522082349.2749970-2-sbogdanov@baylibre.com>
On 5/22/26 01:23, Stoyan Bogdanov wrote:
> TPS25990 and upcoming TPS1689 need common computation APIs but
> the current implementation is static to TPS25990. As a preparation for
> TPS1689 support, split the math-only parts of pmbus_reg2data_direct() and
> pmbus_data2reg_direct() into separate helper functions:
>
> - pmbus_reg2data_direct_calc()
> - pmbus_data2reg_direct_calc()
>
> export them so the upcoming TPS1689 can use the same APIs.
>
> This has no behavioral change on TPS25990 while allowing TPS1689
> to use the same.
>
> Signed-off-by: Stoyan Bogdanov <sbogdanov@baylibre.com>
Please do not introduce new API functions without discussing it first.
Keep this in the driver.
Thanks,
Guenter
^ permalink raw reply
* DEPT (the dependency tracker) as AI review prompt? (was: DEPT v18)
From: Harry Yoo @ 2026-05-23 12:32 UTC (permalink / raw)
To: Byungchul Park, linux-kernel
Cc: kernel_team, torvalds, damien.lemoal, linux-ide, adilger.kernel,
linux-ext4, mingo, peterz, will, tglx, rostedt, joel, sashal,
daniel.vetter, duyuyang, johannes.berg, tj, tytso, willy, david,
amir73il, gregkh, kernel-team, linux-mm, akpm, mhocko, minchan,
hannes, vdavydov.dev, sj, jglisse, dennis, cl, penberg, rientjes,
vbabka, ngupta, linux-block, josef, linux-fsdevel, jack, jlayton,
dan.j.williams, hch, djwong, dri-devel, rodrigosiqueiramelo,
melissa.srw, hamohammed.sa, harry.yoo, chris.p.wilson,
gwan-gyeong.mun, max.byungchul.park, boqun.feng, longman,
yunseong.kim, ysk, yeoreum.yun, netdev, matthew.brost, her0gyugyu,
corbet, catalin.marinas, bp, x86, hpa, luto, sumit.semwal,
gustavo, christian.koenig, andi.shyti, arnd, lorenzo.stoakes,
Liam.Howlett, rppt, surenb, mcgrof, petr.pavlu, da.gomez,
samitolvanen, paulmck, frederic, neeraj.upadhyay, joelagnelf,
josh, urezki, mathieu.desnoyers, jiangshanlai, qiang.zhang,
juri.lelli, vincent.guittot, dietmar.eggemann, bsegall, mgorman,
vschneid, chuck.lever, neil, okorniev, Dai.Ngo, tom, trondmy,
anna, kees, bigeasy, clrkwllms, mark.rutland, ada.coupriediaz,
kristina.martsenko, wangkefeng.wang, broonie, kevin.brodsky, dwmw,
shakeel.butt, ast, ziy, yuzhao, baolin.wang, usamaarif642,
joel.granados, richard.weiyang, geert+renesas, tim.c.chen, linux,
alexander.shishkin, lillian, chenhuacai, francesco,
guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, miguel.ojeda.sandonis, neilb, bagasdotme,
wsa+renesas, dave.hansen, geert, ojeda, alex.gaynor, gary,
bjorn3_gh, lossin, a.hindborg, aliceryhl, tmgross, rust-for-linux,
Chris Mason, Roman Gushchin, Josef Bacik
In-Reply-To: <20251205071855.72743-1-byungchul@sk.com>
Can we start DEPT as an AI review prompt, by documenting DEPT's
dependency tracking model and false positive elimination rules as a
carefully crafted prompt?
While DEPT can identify deadlock issues beyond lockdep's capabilities,
it is hard to enable in automated testing; without fine-grained
annotations it can produce a high rate of false positives, and verifying
them requires significant human effort.
The open source AI Review Prompt has locking.md file [1] that teaches
the AI how to review locks and detect misuse.
If we can write a review prompt for DEPT in a similar manner and have
the AI do the deadlock detection and false positive elimination, I think
we could identify those problems more effectively with much less human
effort.
[1]
https://github.com/masoncl/review-prompts/blob/main/kernel/subsystem/locking.md
--
Cheers,
Harry / Hyeonggon
On 12/5/25 4:18 PM, Byungchul Park wrote:
> I'm happy to see that DEPT reported real problems in practice:
>
> https://lore.kernel.org/lkml/6383cde5-cf4b-facf-6e07-1378a485657d@I-love.SAKURA.ne.jp/
> https://lore.kernel.org/lkml/1674268856-31807-1-git-send-email-byungchul.park@lge.com/
> https://lore.kernel.org/all/b6e00e77-4a8c-4e05-ab79-266bf05fcc2d@igalia.com/
>
> I’ve added documentation describing DEPT — this should help you
> understand what DEPT is and how it works. You can use DEPT simply by
> enabling CONFIG_DEPT and checking dmesg at runtime.
> ---
>
> Hi Linus and folks,
>
> I’ve been developing a tool to detect deadlock possibilities by tracking
> waits/events — rather than lock acquisition order — to cover all the
> synchronization mechanisms. To summarize the design rationale, starting
> from the problem statement, through analysis, to the solution:
>
> CURRENT STATUS
> --------------
> Lockdep tracks lock acquisition order to identify deadlock conditions.
> Additionally, it tracks IRQ state changes — via {en,dis}able — to
> detect cases where locks are acquired unintentionally during
> interrupt handling.
>
> PROBLEM
> -------
> Waits and their associated events that are never reachable can
> eventually lead to deadlocks. However, since Lockdep focuses solely
> on lock acquisition order, it has inherent limitations when handling
> waits and events.
>
> Moreover, by tracking only lock acquisition order, Lockdep cannot
> properly handle read locks or cross-event scenarios — such as
> wait_for_completion() and complete() — making it increasingly
> inadequate as a general-purpose deadlock detection tool.
>
> SOLUTION
> --------
> Once again, waits and their associated events that are never
> reachable can eventually lead to deadlocks. The new solution, DEPT,
> focuses directly on waits and events. DEPT monitors waits and events,
> and reports them when any become unreachable.
>
> DEPT provides:
>
> * Correct handling of read locks.
> * Support for general waits and events.
> * Continuous operation, even after multiple reports.
> * Simple, intuitive annotation APIs.
>
> There are still false positives, and some are already being worked on
> for suppression. Especially splitting the folio class into several
> appropriate classes e.g. block device mapping class and regular file
> mapping class, is currently under active development by me and Yeoreum
> Yun.
>> Anyway, these efforts will need to continue for a while, as we’ve seen
> with lockdep over two decades. DEPT is tagged as EXPERIMENTAL in
> Kconfig — meaning it’s not yet suitable for use as an automation tool.
>
> However, for those who are interested in using DEPT to analyze complex
> synchronization patterns and extract dependency insights, DEPT would be
> a great tool for the purpose.
^ permalink raw reply
* Re: [PATCH v3 15/16] userfaultfd.2: Add read-write protect mode
From: Mike Rapoport @ 2026-05-23 10:37 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: akpm, peterx, david, ljs, surenb, vbabka, Liam.Howlett, ziy,
corbet, skhan, seanjc, pbonzini, jthoughton, aarcange, sj,
usama.arif, linux-mm, linux-kernel, linux-doc, linux-kselftest,
kvm, kernel-team, linux-man, alx, Kiryl Shutsemau (Meta)
In-Reply-To: <20260522133857.552279-16-kirill@shutemov.name>
On Fri, May 22, 2026 at 02:38:56PM +0100, Kiryl Shutsemau wrote:
> From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
>
> Read-write protect mode (UFFDIO_REGISTER_MODE_RWP) is supported starting
> from Linux 7.2. It traps every access -- read or write -- to a present
> page within a registered range. The matching UAPI consists of:
>
> - UFFDIO_REGISTER_MODE_RWP registration-mode bit
> - UFFD_FEATURE_RWP capability bit
> - UFFD_FEATURE_RWP_ASYNC async (in-kernel) fault resolution
> - UFFDIO_RWPROTECT install / remove RWP on a range
> - UFFDIO_SET_MODE runtime sync/async toggle
> - UFFD_PAGEFAULT_FLAG_RWP new pagefault.flags bit
>
> Document the new registration-mode entry, the "Userfaultfd read-write
> protect mode" section, the new pagefault flag, and a VERSIONS line.
>
> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> ---
> man2/userfaultfd.2 | 147 ++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 146 insertions(+), 1 deletion(-)
This doesn't apply to the current man-pages tree
https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
and reading raw groff hurts eyes too much.
What linux-man tree did you use to generate those?
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v3 14/16] Documentation/userfaultfd: document RWP working set tracking
From: Mike Rapoport @ 2026-05-23 10:30 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: akpm, peterx, david, ljs, surenb, vbabka, Liam.Howlett, ziy,
corbet, skhan, seanjc, pbonzini, jthoughton, aarcange, sj,
usama.arif, linux-mm, linux-kernel, linux-doc, linux-kselftest,
kvm, kernel-team, linux-man, alx, Kiryl Shutsemau (Meta)
In-Reply-To: <20260522133857.552279-15-kirill@shutemov.name>
On Fri, May 22, 2026 at 02:38:55PM +0100, Kiryl Shutsemau wrote:
> From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
>
> Add an admin-guide section covering UFFDIO_REGISTER_MODE_RWP:
>
> - sync and async fault models;
> - UFFDIO_RWPROTECT semantics;
> - UFFD_FEATURE_RWP_ASYNC;
> - UFFDIO_SET_MODE runtime mode flips.
>
> It also covers typical VMM working-set-tracking workflow from detection
> loop through sync-mode eviction and back to async.
>
> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> Assisted-by: Claude:claude-opus-4-6
Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
with some nits below
> ---
> Documentation/admin-guide/mm/userfaultfd.rst | 226 ++++++++++++++++++-
> 1 file changed, 220 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst
> index 1e533639fd50..cb5d0e0c9fff 100644
> --- a/Documentation/admin-guide/mm/userfaultfd.rst
> +++ b/Documentation/admin-guide/mm/userfaultfd.rst
...
> The user app can collect the "written/dirty" status by looking up the
> -uffd-wp bit for the pages being interested in /proc/pagemap.
> +uffd bit for the pages being interested in /proc/pagemap.
It's pre-existing, but "being interested" sounds weird to me
Maybe let's change "being interested" to "of interest" or "the app is
interested in".
> -The page will not be under track of uffd-wp async mode until the page is
> +The page will not be under track of userfaultfd-wp async mode until the page is
Here as well I'd s/will not be under track of/will not be tracked by/
> explicitly write-protected by ``ioctl(UFFDIO_WRITEPROTECT)`` with the mode
> flag ``UFFDIO_WRITEPROTECT_MODE_WP`` set. Trying to resolve a page fault
> that was tracked by async mode userfaultfd-wp is invalid.
> @@ -307,6 +307,220 @@ transparent to the guest, we want that same address range to act as if it was
> still poisoned, even though it's on a new physical host which ostensibly
> doesn't have a memory error in the exact same spot.
>
> +Read-Write Protection
> +---------------------
...
> +**Setup:**
> +
> +1. Open a userfaultfd and enable ``UFFD_FEATURE_RWP`` via ``UFFDIO_API``.
> + Optionally request ``UFFD_FEATURE_RWP_ASYNC`` as well — it requires
> + ``UFFD_FEATURE_RWP`` to be set in the same ``UFFDIO_API`` call.
> +
> +2. Register the guest memory range with ``UFFDIO_REGISTER_MODE_RWP``
> + (and ``UFFDIO_REGISTER_MODE_MISSING`` if evicted pages will need to be
> + fetched back from storage).
I'd make it
2. Register the guest memory range with ``UFFDIO_REGISTER_MODE_RWP``.
Add ``UFFDIO_REGISTER_MODE_MISSING`` if evicted pages will need to be
fetched back from storage.
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v3 13/16] selftests/mm: add userfaultfd RWP tests
From: Mike Rapoport @ 2026-05-23 10:07 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: akpm, peterx, david, ljs, surenb, vbabka, Liam.Howlett, ziy,
corbet, skhan, seanjc, pbonzini, jthoughton, aarcange, sj,
usama.arif, linux-mm, linux-kernel, linux-doc, linux-kselftest,
kvm, kernel-team, linux-man, alx, Kiryl Shutsemau (Meta)
In-Reply-To: <20260522133857.552279-14-kirill@shutemov.name>
On Fri, May 22, 2026 at 02:38:54PM +0100, Kiryl Shutsemau wrote:
> From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
>
> Coverage for UFFDIO_REGISTER_MODE_RWP and UFFDIO_RWPROTECT:
>
> rwp-async async mode — touch pages, verify permissions are
> auto-restored without a message
> rwp-sync sync mode — access blocks, handler resolves via
> UFFDIO_RWPROTECT
> rwp-pagemap PAGEMAP_SCAN reports still-cold pages via
> inverted PAGE_IS_ACCESSED
> rwp-mprotect RWP survives mprotect(PROT_NONE) ->
> mprotect(PROT_READ|PROT_WRITE) round-trip
> rwp-gup GUP walks through a protnone RWP PTE (pipe
> write/read drives the GUP path)
> rwp-async-toggle UFFDIO_SET_MODE flips between sync and async
> without re-registering
> rwp-close closing the uffd restores page permissions
> rwp-fork RWP survives fork() with EVENT_FORK; child's
> PTEs keep the uffd bit
> rwp-fork-pin RWP survives fork() on an RO-longterm-pinned
> anon page (forces copy_present_page()); child
> read auto-resolves and clears the bit, proving
> PAGE_NONE was in place
> rwp-wp-exclusive register with MODE_WP|MODE_RWP returns -EINVAL
>
> All tests run against anon, shmem, shmem-private, hugetlb, and
> hugetlb-private memory, except rwp-fork-pin which is anon-only —
> copy_present_page() is the private-anon pinned-exclusive fork path.
>
> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> Assisted-by: Claude:claude-opus-4-6
Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
> tools/testing/selftests/mm/uffd-unit-tests.c | 766 +++++++++++++++++++
> 1 file changed, 766 insertions(+)
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v3 05/16] mm: add MM_CP_UFFD_RWP change_protection() flag
From: Mike Rapoport @ 2026-05-23 10:03 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: akpm, peterx, david, ljs, surenb, vbabka, Liam.Howlett, ziy,
corbet, skhan, seanjc, pbonzini, jthoughton, aarcange, sj,
usama.arif, linux-mm, linux-kernel, linux-doc, linux-kselftest,
kvm, kernel-team, linux-man, alx, Kiryl Shutsemau (Meta)
In-Reply-To: <20260522133857.552279-6-kirill@shutemov.name>
On Fri, May 22, 2026 at 02:38:46PM +0100, Kiryl Shutsemau wrote:
> From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
>
> Preparatory patch. Add the change_protection() primitive that
> userfaultfd RWP will use.
>
> An RWP-protected PTE is PAGE_NONE with the uffd PTE bit set. The
> PROT_NONE half makes the CPU fault on any access; the uffd bit
> distinguishes an RWP fault from a plain mprotect(PROT_NONE) or NUMA
> hinting fault. MM_CP_UFFD_WP and MM_CP_UFFD_RWP share the same PTE
> bit, so the two cannot be used together on the same range.
>
> Two new change_protection() flags:
>
> MM_CP_UFFD_RWP install PAGE_NONE and set the uffd bit
> MM_CP_UFFD_RWP_RESOLVE restore vma->vm_page_prot, clear the uffd bit
>
> Both are wired through change_pte_range(), change_huge_pmd(), and
> hugetlb_change_protection() so anon, shmem, THP, and hugetlb all
> share the same semantics.
>
> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> Assisted-by: Claude:claude-opus-4-6
Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
> include/linux/mm.h | 5 ++++
> include/linux/userfaultfd_k.h | 1 -
> mm/huge_memory.c | 30 +++++++++++++----------
> mm/hugetlb.c | 25 ++++++++++++++-----
> mm/mprotect.c | 46 +++++++++++++++++++++++++++--------
> 5 files changed, 77 insertions(+), 30 deletions(-)
--
Sincerely yours,
Mike.
^ permalink raw reply
* [PATCH 2/2] docs/zh_TW: update DAMON usage sysfs documentation
From: Doehyun Baek @ 2026-05-23 9:44 UTC (permalink / raw)
To: Alex Shi, Yanteng Si, Hu Haowen
Cc: Dongliang Mu, Jonathan Corbet, Shuah Khan, SeongJae Park,
linux-doc, linux-kernel, damon, Doehyun Baek
In-Reply-To: <20260523094420.741003-1-doehyunbaek@gmail.com>
The DAMON usage documentation translation is missing recent sysfs
interface updates that are already documented in the English version,
including refresh_ms, addr_unit, obsolete_target, goal_tuner, nid, and
max_nr_snapshots.
Update the Traditional Chinese translation for those stale sysfs entries.
Signed-off-by: Doehyun Baek <doehyunbaek@gmail.com>
---
.../zh_TW/admin-guide/mm/damon/usage.rst | 56 +++++++++++++------
1 file changed, 40 insertions(+), 16 deletions(-)
diff --git a/Documentation/translations/zh_TW/admin-guide/mm/damon/usage.rst b/Documentation/translations/zh_TW/admin-guide/mm/damon/usage.rst
index d3fd4f850793..debe455723af 100644
--- a/Documentation/translations/zh_TW/admin-guide/mm/damon/usage.rst
+++ b/Documentation/translations/zh_TW/admin-guide/mm/damon/usage.rst
@@ -15,6 +15,10 @@
DAMON 爲不同的用戶提供了下面這些接口。
+- *專用DAMON模塊。*
+ :ref:`這 <damon_modules_special_purpose>` 是爲構建、發佈或管理帶有專用DAMON用法的內
+ 核的用戶準備的。使用它，用戶可以在構建、啓動或運行時以簡單的方式爲給定目的使用DAMON的主要
+ 功能。
- *DAMON用戶空間工具。*
`這 <https://github.com/damonitor/damo>`_ 爲有這特權的人， 如系統管理員，希望有一個剛好
可以工作的人性化界面。
@@ -55,14 +59,14 @@ DAMON sysfs接口的文件層次結構如下圖所示。在下圖中，父子關
/sys/kernel/mm/damon/admin
│ kdamonds/nr_kdamonds
- │ │ 0/state,pid
+ │ │ 0/state,pid,refresh_ms
│ │ │ contexts/nr_contexts
- │ │ │ │ 0/operations
+ │ │ │ │ 0/operations,addr_unit
│ │ │ │ │ monitoring_attrs/
│ │ │ │ │ │ intervals/sample_us,aggr_us,update_us
│ │ │ │ │ │ nr_regions/min,max
│ │ │ │ │ targets/nr_targets
- │ │ │ │ │ │ 0/pid_target
+ │ │ │ │ │ │ 0/pid_target,obsolete_target
│ │ │ │ │ │ │ regions/nr_regions
│ │ │ │ │ │ │ │ 0/start,end
│ │ │ │ │ │ │ │ ...
@@ -73,10 +77,12 @@ DAMON sysfs接口的文件層次結構如下圖所示。在下圖中，父子關
│ │ │ │ │ │ │ │ sz/min,max
│ │ │ │ │ │ │ │ nr_accesses/min,max
│ │ │ │ │ │ │ │ age/min,max
- │ │ │ │ │ │ │ quotas/ms,bytes,reset_interval_ms
+ │ │ │ │ │ │ │ quotas/ms,bytes,reset_interval_ms,goal_tuner
│ │ │ │ │ │ │ │ weights/sz_permil,nr_accesses_permil,age_permil
+ │ │ │ │ │ │ │ │ goals/nr_goals
+ │ │ │ │ │ │ │ │ │ 0/target_metric,target_value,current_value,nid
│ │ │ │ │ │ │ watermarks/metric,interval_us,high,mid,low
- │ │ │ │ │ │ │ stats/nr_tried,sz_tried,nr_applied,sz_applied,qt_exceeds
+ │ │ │ │ │ │ │ stats/nr_tried,sz_tried,nr_applied,sz_applied,qt_exceeds,nr_snapshots,max_nr_snapshots
│ │ │ │ │ │ │ tried_regions/
│ │ │ │ │ │ │ │ 0/start,end,nr_accesses,age
│ │ │ │ │ │ │ │ ...
@@ -104,7 +110,8 @@ kdamonds/
kdamonds/<N>/
-------------
-在每個kdamond目錄中，存在兩個文件（``state`` 和 ``pid`` ）和一個目錄( ``contexts`` )。
+在每個kdamond目錄中，存在三個文件（``state``、``pid`` 和 ``refresh_ms``）和一個目錄
+(``contexts``)。
讀取 ``state`` 時，如果kdamond當前正在運行，則返回 ``on`` ，如果沒有運行則返回 ``off`` 。
寫入 ``on`` 或 ``off`` 使kdamond處於狀態。向 ``state`` 文件寫 ``update_schemes_stats`` ，
@@ -117,6 +124,10 @@ kdamonds/<N>/
如果狀態爲 ``on``，讀取 ``pid`` 顯示kdamond線程的pid。
+用戶可以要求內核通過 ``refresh_ms`` 文件週期性地更新顯示自動調優參數和DAMOS統計信息的文件。
+向該文件寫入希望的更新時間間隔（毫秒）。如果間隔爲零，則禁用週期性更新。讀取該文件會顯示當前
+設置的時間間隔。
+
``contexts`` 目錄包含控制這個kdamond要執行的監測上下文的文件。
kdamonds/<N>/contexts/
@@ -129,8 +140,8 @@ kdamonds/<N>/contexts/
contexts/<N>/
-------------
-在每個上下文目錄中，存在一個文件(``operations``)和三個目錄(``monitoring_attrs``,
-``targets``, 和 ``schemes``)。
+在每個上下文目錄中，存在兩個文件（``operations`` 和 ``addr_unit``）和三個目錄
+（``monitoring_attrs``、``targets`` 和 ``schemes``）。
DAMON支持多種類型的監測操作，包括對虛擬地址空間和物理地址空間的監測。你可以通過向文件
中寫入以下關鍵詞之一，並從文件中讀取，來設置和獲取DAMON將爲上下文使用何種類型的監測操作。
@@ -138,6 +149,8 @@ DAMON支持多種類型的監測操作，包括對虛擬地址空間和物理地
- vaddr: 監測特定進程的虛擬地址空間
- paddr: 監視系統的物理地址空間
+``addr_unit`` 文件用於設置和獲取操作集的 :ref:`地址單位 <damon_design_addr_unit>` 參數。
+
contexts/<N>/monitoring_attrs/
------------------------------
@@ -161,11 +174,15 @@ contexts/<N>/targets/
targets/<N>/
------------
-在每個目標目錄中，存在一個文件(``pid_target``)和一個目錄(``regions``)。
+在每個目標目錄中，存在兩個文件（``pid_target`` 和 ``obsolete_target``）和一個目錄
+（``regions``）。
如果你把 ``vaddr`` 寫到 ``contexts/<N>/operations`` 中，每個目標應該是一個進程。你
可以通過將進程的pid寫到 ``pid_target`` 文件中來指定DAMON的進程。
+用戶可以向 ``obsolete_target`` 文件寫入非零值並提交它（向 ``state`` 文件寫入 ``commit``），
+從目標數組中間選擇性地刪除目標。
+
targets/<N>/regions
-------------------
@@ -239,14 +256,20 @@ schemes/<N>/quotas/
當預計超過配額限制時，DAMON會根據 ``目標訪問模式`` 的大小、訪問頻率和年齡，對找到的內存區域
進行優先排序。爲了進行個性化的優先排序，用戶可以爲這三個屬性設置權重。
-在 ``quotas`` 目錄下，存在三個文件（``ms``, ``bytes``, ``reset_interval_ms``）和一個
-目錄(``weights``)，其中有三個文件(``sz_permil``, ``nr_accesses_permil``, 和
-``age_permil``)。
+在 ``quotas`` 目錄下，存在四個文件（``ms``、``bytes``、``reset_interval_ms`` 和
+``goal_tuner``）和兩個目錄（``weights`` 和 ``goals``）。
你可以設置以毫秒爲單位的 ``時間配額`` ，以字節爲單位的 ``大小配額`` ，以及以毫秒爲單位的 ``重
置間隔`` ，分別向這三個文件寫入數值。你還可以通過向 ``weights`` 目錄下的三個文件寫入數值來設
置大小、訪問頻率和年齡的優先權，單位爲千分之一。
+你可以通過向 ``goal_tuner`` 文件寫入算法名稱，設置要使用的基於目標的有效配額自動調優算法。
+讀取該文件會返回當前選定的調優器算法。
+
+``goals`` 目錄用於設置自動配額調優目標。每個目標目錄包含 ``target_metric``、
+``target_value``、``current_value`` 和 ``nid`` 文件。用戶可以讀寫這些文件來設置和獲取配額
+自動調優目標的參數。
+
schemes/<N>/watermarks/
-----------------------
@@ -271,10 +294,11 @@ schemes/<N>/stats/
DAMON統計每個方案被嘗試應用的區域的總數量和字節數，每個方案被成功應用的區域的兩個數字，以及
超過配額限制的總數量。這些統計數據可用於在線分析或調整方案。
-可以通過讀取 ``stats`` 目錄下的文件(``nr_tried``, ``sz_tried``, ``nr_applied``,
-``sz_applied``, 和 ``qt_exceeds``)）分別檢索這些統計數據。這些文件不是實時更新的，所以
-你應該要求DAMON sysfs接口通過在相關的 ``kdamonds/<N>/state`` 文件中寫入一個特殊的關鍵字
-``update_schemes_stats`` 來更新統計信息的文件內容。
+可以通過讀取 ``stats`` 目錄下的文件（``nr_tried``、``sz_tried``、``nr_applied``、
+``sz_applied``、``qt_exceeds``、``nr_snapshots`` 和 ``max_nr_snapshots``）分別檢索這些
+統計數據。這些文件默認不是實時更新的。你應該要求DAMON sysfs接口通過 ``refresh_ms`` 週期性地
+更新這些文件，或者通過在相關的 ``kdamonds/<N>/state`` 文件中寫入一個特殊的關鍵字
+``update_schemes_stats`` 來執行一次性更新。
schemes/<N>/tried_regions/
--------------------------
--
2.43.0
^ permalink raw reply related
* [PATCH 1/2] docs/zh_CN: update DAMON usage sysfs documentation
From: Doehyun Baek @ 2026-05-23 9:44 UTC (permalink / raw)
To: Alex Shi, Yanteng Si, Hu Haowen
Cc: Dongliang Mu, Jonathan Corbet, Shuah Khan, SeongJae Park,
linux-doc, linux-kernel, damon, Doehyun Baek
In-Reply-To: <20260523094420.741003-1-doehyunbaek@gmail.com>
The DAMON usage documentation translation is missing recent sysfs
interface updates that are already documented in the English version,
including refresh_ms, addr_unit, obsolete_target, goal_tuner, nid, and
max_nr_snapshots.
Update the Simplified Chinese translation for those stale sysfs entries.
Signed-off-by: Doehyun Baek <doehyunbaek@gmail.com>
---
.../zh_CN/admin-guide/mm/damon/usage.rst | 56 +++++++++++++------
1 file changed, 40 insertions(+), 16 deletions(-)
diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst
index 9d7cb51be493..3fbfa9df9935 100644
--- a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst
+++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst
@@ -15,6 +15,10 @@
DAMON 为不同的用户提供了下面这些接口。
+- *专用DAMON模块。*
+ :ref:`这 <damon_modules_special_purpose>` 是为构建、发布或管理带有专用DAMON用法的内
+ 核的用户准备的。使用它，用户可以在构建、启动或运行时以简单的方式为给定目的使用DAMON的主要
+ 功能。
- *DAMON用户空间工具。*
`这 <https://github.com/damonitor/damo>`_ 为有这特权的人， 如系统管理员，希望有一个刚好
可以工作的人性化界面。
@@ -55,14 +59,14 @@ DAMON sysfs接口的文件层次结构如下图所示。在下图中，父子关
/sys/kernel/mm/damon/admin
│ kdamonds/nr_kdamonds
- │ │ 0/state,pid
+ │ │ 0/state,pid,refresh_ms
│ │ │ contexts/nr_contexts
- │ │ │ │ 0/operations
+ │ │ │ │ 0/operations,addr_unit
│ │ │ │ │ monitoring_attrs/
│ │ │ │ │ │ intervals/sample_us,aggr_us,update_us
│ │ │ │ │ │ nr_regions/min,max
│ │ │ │ │ targets/nr_targets
- │ │ │ │ │ │ 0/pid_target
+ │ │ │ │ │ │ 0/pid_target,obsolete_target
│ │ │ │ │ │ │ regions/nr_regions
│ │ │ │ │ │ │ │ 0/start,end
│ │ │ │ │ │ │ │ ...
@@ -73,10 +77,12 @@ DAMON sysfs接口的文件层次结构如下图所示。在下图中，父子关
│ │ │ │ │ │ │ │ sz/min,max
│ │ │ │ │ │ │ │ nr_accesses/min,max
│ │ │ │ │ │ │ │ age/min,max
- │ │ │ │ │ │ │ quotas/ms,bytes,reset_interval_ms
+ │ │ │ │ │ │ │ quotas/ms,bytes,reset_interval_ms,goal_tuner
│ │ │ │ │ │ │ │ weights/sz_permil,nr_accesses_permil,age_permil
+ │ │ │ │ │ │ │ │ goals/nr_goals
+ │ │ │ │ │ │ │ │ │ 0/target_metric,target_value,current_value,nid
│ │ │ │ │ │ │ watermarks/metric,interval_us,high,mid,low
- │ │ │ │ │ │ │ stats/nr_tried,sz_tried,nr_applied,sz_applied,qt_exceeds
+ │ │ │ │ │ │ │ stats/nr_tried,sz_tried,nr_applied,sz_applied,qt_exceeds,nr_snapshots,max_nr_snapshots
│ │ │ │ │ │ │ tried_regions/
│ │ │ │ │ │ │ │ 0/start,end,nr_accesses,age
│ │ │ │ │ │ │ │ ...
@@ -104,7 +110,8 @@ kdamonds/
kdamonds/<N>/
-------------
-在每个kdamond目录中，存在两个文件（``state`` 和 ``pid`` ）和一个目录( ``contexts`` )。
+在每个kdamond目录中，存在三个文件（``state``、``pid`` 和 ``refresh_ms``）和一个目录
+(``contexts``)。
读取 ``state`` 时，如果kdamond当前正在运行，则返回 ``on`` ，如果没有运行则返回 ``off`` 。
写入 ``on`` 或 ``off`` 使kdamond处于状态。向 ``state`` 文件写 ``update_schemes_stats`` ，
@@ -117,6 +124,10 @@ kdamonds/<N>/
如果状态为 ``on``，读取 ``pid`` 显示kdamond线程的pid。
+用户可以要求内核通过 ``refresh_ms`` 文件周期性地更新显示自动调优参数和DAMOS统计信息的文件。
+向该文件写入希望的更新时间间隔（毫秒）。如果间隔为零，则禁用周期性更新。读取该文件会显示当前
+设置的时间间隔。
+
``contexts`` 目录包含控制这个kdamond要执行的监测上下文的文件。
kdamonds/<N>/contexts/
@@ -129,8 +140,8 @@ kdamonds/<N>/contexts/
contexts/<N>/
-------------
-在每个上下文目录中，存在一个文件(``operations``)和三个目录(``monitoring_attrs``,
-``targets``, 和 ``schemes``)。
+在每个上下文目录中，存在两个文件（``operations`` 和 ``addr_unit``）和三个目录
+（``monitoring_attrs``、``targets`` 和 ``schemes``）。
DAMON支持多种类型的监测操作，包括对虚拟地址空间和物理地址空间的监测。你可以通过向文件
中写入以下关键词之一，并从文件中读取，来设置和获取DAMON将为上下文使用何种类型的监测操作。
@@ -138,6 +149,8 @@ DAMON支持多种类型的监测操作，包括对虚拟地址空间和物理地
- vaddr: 监测特定进程的虚拟地址空间
- paddr: 监视系统的物理地址空间
+``addr_unit`` 文件用于设置和获取操作集的 :ref:`地址单位 <damon_design_addr_unit>` 参数。
+
contexts/<N>/monitoring_attrs/
------------------------------
@@ -161,11 +174,15 @@ contexts/<N>/targets/
targets/<N>/
------------
-在每个目标目录中，存在一个文件(``pid_target``)和一个目录(``regions``)。
+在每个目标目录中，存在两个文件（``pid_target`` 和 ``obsolete_target``）和一个目录
+（``regions``）。
如果你把 ``vaddr`` 写到 ``contexts/<N>/operations`` 中，每个目标应该是一个进程。你
可以通过将进程的pid写到 ``pid_target`` 文件中来指定DAMON的进程。
+用户可以向 ``obsolete_target`` 文件写入非零值并提交它（向 ``state`` 文件写入 ``commit``），
+从目标数组中间选择性地删除目标。
+
targets/<N>/regions
-------------------
@@ -239,14 +256,20 @@ schemes/<N>/quotas/
当预计超过配额限制时，DAMON会根据 ``目标访问模式`` 的大小、访问频率和年龄，对找到的内存区域
进行优先排序。为了进行个性化的优先排序，用户可以为这三个属性设置权重。
-在 ``quotas`` 目录下，存在三个文件（``ms``, ``bytes``, ``reset_interval_ms``）和一个
-目录(``weights``)，其中有三个文件(``sz_permil``, ``nr_accesses_permil``, 和
-``age_permil``)。
+在 ``quotas`` 目录下，存在四个文件（``ms``、``bytes``、``reset_interval_ms`` 和
+``goal_tuner``）和两个目录（``weights`` 和 ``goals``）。
你可以设置以毫秒为单位的 ``时间配额`` ，以字节为单位的 ``大小配额`` ，以及以毫秒为单位的 ``重
置间隔`` ，分别向这三个文件写入数值。你还可以通过向 ``weights`` 目录下的三个文件写入数值来设
置大小、访问频率和年龄的优先权，单位为千分之一。
+你可以通过向 ``goal_tuner`` 文件写入算法名称，设置要使用的基于目标的有效配额自动调优算法。
+读取该文件会返回当前选定的调优器算法。
+
+``goals`` 目录用于设置自动配额调优目标。每个目标目录包含 ``target_metric``、
+``target_value``、``current_value`` 和 ``nid`` 文件。用户可以读写这些文件来设置和获取配额
+自动调优目标的参数。
+
schemes/<N>/watermarks/
-----------------------
@@ -271,10 +294,11 @@ schemes/<N>/stats/
DAMON统计每个方案被尝试应用的区域的总数量和字节数，每个方案被成功应用的区域的两个数字，以及
超过配额限制的总数量。这些统计数据可用于在线分析或调整方案。
-可以通过读取 ``stats`` 目录下的文件(``nr_tried``, ``sz_tried``, ``nr_applied``,
-``sz_applied``, 和 ``qt_exceeds``)）分别检索这些统计数据。这些文件不是实时更新的，所以
-你应该要求DAMON sysfs接口通过在相关的 ``kdamonds/<N>/state`` 文件中写入一个特殊的关键字
-``update_schemes_stats`` 来更新统计信息的文件内容。
+可以通过读取 ``stats`` 目录下的文件（``nr_tried``、``sz_tried``、``nr_applied``、
+``sz_applied``、``qt_exceeds``、``nr_snapshots`` 和 ``max_nr_snapshots``）分别检索这些
+统计数据。这些文件默认不是实时更新的。你应该要求DAMON sysfs接口通过 ``refresh_ms`` 周期性地
+更新这些文件，或者通过在相关的 ``kdamonds/<N>/state`` 文件中写入一个特殊的关键字
+``update_schemes_stats`` 来执行一次性更新。
schemes/<N>/tried_regions/
--------------------------
--
2.43.0
^ permalink raw reply related
* [PATCH 0/2] docs/zh: update DAMON usage sysfs documentation
From: Doehyun Baek @ 2026-05-23 9:44 UTC (permalink / raw)
To: Alex Shi, Yanteng Si, Hu Haowen
Cc: Dongliang Mu, Jonathan Corbet, Shuah Khan, SeongJae Park,
linux-doc, linux-kernel, damon, Doehyun Baek
Hi,
The Simplified and Traditional Chinese DAMON usage translations are
missing selected updates that are already documented in the English file.
As a result, parts of the translated sysfs hierarchy and descriptions are
stale, and the translations also lack the newer introduction of DAMON's
special-purpose modules.
The gaps correspond to the following English documentation commits:
commit a7bb1e754559 ("Docs/admin-guide/mm/damon/usage: document 'nid' file")
commit e85e965bdbec ("Docs/admin-guide/mm/damon/usage: document refresh_ms file")
commit e0c725455fd5 ("Docs/admin-guide/mm/damon/usage: document addr_unit file")
commit e06469cdf1fd ("Docs/admin-guide/mm/damon/usage: document obsolete_target file")
commit 2584dd7496c5 ("Docs/admin-guide/mm/damon/usage: update for max_nr_snapshots")
commit 652fd06d20da ("Docs/admin-guide/mm/damon/usage: update stats update process for refresh_ms")
commit e7df7a0bfc90 ("Docs/admin-guide/mm/damon/usage: introduce DAMON modules at the beginning")
commit d9cfe515d36e ("Docs/admin-guide/mm/damon/usage: document goal_tuner sysfs file")
Update both translations only for those stale DAMON usage entries,
including refresh_ms, addr_unit, obsolete_target, goal_tuner, nid, and
max_nr_snapshots.
Doehyun Baek (2):
docs/zh_CN: update DAMON usage sysfs documentation
docs/zh_TW: update DAMON usage sysfs documentation
.../zh_CN/admin-guide/mm/damon/usage.rst | 56 +++++++++++++------
.../zh_TW/admin-guide/mm/damon/usage.rst | 56 +++++++++++++------
2 files changed, 80 insertions(+), 32 deletions(-)
base-commit: 79bd2dded182b1d458b18e62684b7f82ffc682e5
--
2.43.0
^ permalink raw reply
* [PATCH v2 24/24] dyndbg: improve section names
From: Jim Cromie @ 2026-05-23 7:14 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Arnd Bergmann, Jason Baron,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Andrew Morton, Shuah Khan
Cc: linux-doc, linux-kernel, linux-arch, linux-modules,
linux-kselftest, Jim Cromie
In-Reply-To: <20260523-dd-maint-2-v2-0-b937312aa083@gmail.com>
change __dyndbg to __dyndbg_descs
change __dyndbg_classes to __dyndbg_class_maps
this sets up for adding __dyndbg_class_users
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
include/asm-generic/dyndbg.lds.h | 14 +++++++-------
include/linux/dynamic_debug.h | 4 ++--
kernel/module/main.c | 2 +-
lib/dynamic_debug.c | 24 ++++++++++++------------
4 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/include/asm-generic/dyndbg.lds.h b/include/asm-generic/dyndbg.lds.h
index 9d8951bef688..ec661f9f3793 100644
--- a/include/asm-generic/dyndbg.lds.h
+++ b/include/asm-generic/dyndbg.lds.h
@@ -3,16 +3,16 @@
#define __ASM_GENERIC_DYNDBG_LDS_H
#include <asm-generic/bounded_sections.lds.h>
-#define DYNDBG_SECTIONS() \
- BOUNDED_SECTION_BY(__dyndbg, ___dyndbg) \
- BOUNDED_SECTION_BY(__dyndbg_classes, ___dyndbg_classes)
+#define DYNDBG_SECTIONS() \
+ BOUNDED_SECTION_BY(__dyndbg_descs, ___dyndbg_descs) \
+ BOUNDED_SECTION_BY(__dyndbg_class_maps, ___dyndbg_class_maps)
#define MOD_DYNDBG_SECTIONS() \
- __dyndbg 0 : ALIGN(8) { \
- KEEP(*(__dyndbg)) \
+ __dyndbg_descs 0 : ALIGN(8) { \
+ KEEP(*(__dyndbg_descs)) \
} \
- __dyndbg_classes 0 : ALIGN(8) { \
- KEEP(*(__dyndbg_classes)) \
+ __dyndbg_class_maps 0 : ALIGN(8) { \
+ KEEP(*(__dyndbg_class_maps)) \
}
#endif /* __ASM_GENERIC_DYNDBG_LDS_H */
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index fe73aa27b350..206337af71e9 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -128,7 +128,7 @@ struct _ddebug_class_param {
#define DECLARE_DYNDBG_CLASSMAP(_var, _maptype, _base, ...) \
static const char *_var##_classnames[] = { __VA_ARGS__ }; \
static struct _ddebug_class_map __aligned(8) __used \
- __section("__dyndbg_classes") _var = { \
+ __section("__dyndbg_class_maps") _var = { \
.mod = THIS_MODULE, \
.mod_name = KBUILD_MODNAME, \
.base = _base, \
@@ -168,7 +168,7 @@ void __dynamic_ibdev_dbg(struct _ddebug *descriptor,
#define DEFINE_DYNAMIC_DEBUG_METADATA_CLS(name, cls, fmt) \
static struct _ddebug __aligned(8) \
- __section("__dyndbg") name = { \
+ __section("__dyndbg_descs") name = { \
.modname = KBUILD_MODNAME, \
.function = __func__, \
.filename = __FILE__, \
diff --git a/kernel/module/main.c b/kernel/module/main.c
index c2b6e70f2e77..bd7899a91755 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -2774,7 +2774,7 @@ static int find_module_sections(struct module *mod, struct load_info *info)
pr_warn("%s: Ignoring obsolete parameters\n", mod->name);
#ifdef CONFIG_DYNAMIC_DEBUG_CORE
- mod->dyndbg_info.descs.start = section_objs(info, "__dyndbg_descriptors",
+ mod->dyndbg_info.descs.start = section_objs(info, "__dyndbg_descs",
sizeof(*mod->dyndbg_info.descs.start),
&mod->dyndbg_info.descs.len);
mod->dyndbg_info.maps.start = section_objs(info, "__dyndbg_class_maps",
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index b877f4c6d778..ce70cfee50c5 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -40,10 +40,10 @@
#include <rdma/ib_verbs.h>
-extern struct _ddebug __start___dyndbg[];
-extern struct _ddebug __stop___dyndbg[];
-extern struct _ddebug_class_map __start___dyndbg_classes[];
-extern struct _ddebug_class_map __stop___dyndbg_classes[];
+extern struct _ddebug __start___dyndbg_descs[];
+extern struct _ddebug __stop___dyndbg_descs[];
+extern struct _ddebug_class_map __start___dyndbg_class_maps[];
+extern struct _ddebug_class_map __stop___dyndbg_class_maps[];
struct ddebug_table {
struct list_head link;
@@ -1379,10 +1379,10 @@ static int __init dynamic_debug_init(void)
char *cmdline;
struct _ddebug_info di = {
- .descs.start = __start___dyndbg,
- .maps.start = __start___dyndbg_classes,
- .descs.len = __stop___dyndbg - __start___dyndbg,
- .maps.len = __stop___dyndbg_classes - __start___dyndbg_classes,
+ .descs.start = __start___dyndbg_descs,
+ .maps.start = __start___dyndbg_class_maps,
+ .descs.len = __stop___dyndbg_descs - __start___dyndbg_descs,
+ .maps.len = __stop___dyndbg_class_maps - __start___dyndbg_class_maps,
};
#ifdef CONFIG_MODULES
@@ -1393,7 +1393,7 @@ static int __init dynamic_debug_init(void)
}
#endif /* CONFIG_MODULES */
- if (&__start___dyndbg == &__stop___dyndbg) {
+ if (&__start___dyndbg_descs == &__stop___dyndbg_descs) {
if (IS_ENABLED(CONFIG_DYNAMIC_DEBUG)) {
pr_warn("_ddebug table is empty in a CONFIG_DYNAMIC_DEBUG build\n");
return 1;
@@ -1403,11 +1403,11 @@ static int __init dynamic_debug_init(void)
return 0;
}
- iter = iter_mod_start = __start___dyndbg;
+ iter = iter_mod_start = __start___dyndbg_descs;
modname = iter->modname;
i = mod_sites = mod_ct = 0;
- for (; iter < __stop___dyndbg; iter++, i++, mod_sites++) {
+ for (; iter < __stop___dyndbg_descs; iter++, i++, mod_sites++) {
if (strcmp(modname, iter->modname)) {
mod_ct++;
@@ -1431,7 +1431,7 @@ static int __init dynamic_debug_init(void)
goto out_err;
ddebug_init_success = 1;
- vpr_info("%d prdebugs in %d modules, %d KiB in ddebug tables, %d kiB in __dyndbg section\n",
+ vpr_info("%d prdebugs in %d modules, %d KiB in ddebug tables, %d kiB in __dyndbg_descs section\n",
i, mod_ct, (int)((mod_ct * sizeof(struct ddebug_table)) >> 10),
(int)((i * sizeof(struct _ddebug)) >> 10));
--
2.54.0
^ permalink raw reply related
* [PATCH v2 23/24] dyndbg: change __dynamic_func_call_cls* macros into expressions
From: Jim Cromie @ 2026-05-23 7:14 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Arnd Bergmann, Jason Baron,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Andrew Morton, Shuah Khan
Cc: linux-doc, linux-kernel, linux-arch, linux-modules,
linux-kselftest, Jim Cromie, Louis Chauvet
In-Reply-To: <20260523-dd-maint-2-v2-0-b937312aa083@gmail.com>
The Xe driver's XE_IOCTL_DBG macro calls drm_dbg() from inside an if
(expression). This breaks when CONFIG_DRM_USE_DYNAMIC_DEBUG=y because
the invoked macro has a do-while-0 wrapper, and is not an expression.
if (cond && (drm_dbg("expr-form"),1)) {
... do some more stuff
}
Fix for this usage by changing __dynamic_func_call_cls{,_no_desc}
macros into expressions, by replacing the do-while-0s with a ({ })
wrapper. In the common usage, the trailing ';' converts the
expression into a statement.
drm_dbg("statement form");
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
---
v2:
fix statement-expressions to return 0 (not void) like their respective fallbacks
1. Add 0; to __dynamic_func_call_cls
2. Add 0; to __dynamic_func_call_cls_no_desc
3. Convert the disabled fallback of dynamic_hex_dump from do { ... } while(0) to ({ ... 0; })
move RvB after SoB
---
include/linux/dynamic_debug.h | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 11ec40f488f3..fe73aa27b350 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -224,24 +224,26 @@ void __dynamic_ibdev_dbg(struct _ddebug *descriptor,
* (|_cls): adds in _DPRINT_CLASS_DFLT as needed
* (|_no_desc): former gets callsite descriptor as 1st arg (for prdbgs)
*/
-#define __dynamic_func_call_cls(id, cls, fmt, func, ...) do { \
+#define __dynamic_func_call_cls(id, cls, fmt, func, ...) ({ \
DEFINE_DYNAMIC_DEBUG_METADATA_CLS(id, cls, fmt); \
if (DYNAMIC_DEBUG_BRANCH(id)) { \
func(&id, ##__VA_ARGS__); \
__dynamic_dump_stack(id); \
} \
-} while (0)
+ 0; /* match no_printk return value */ \
+})
#define __dynamic_func_call(id, fmt, func, ...) \
__dynamic_func_call_cls(id, _DPRINTK_CLASS_DFLT, fmt, \
func, ##__VA_ARGS__)
-#define __dynamic_func_call_cls_no_desc(id, cls, fmt, func, ...) do { \
+#define __dynamic_func_call_cls_no_desc(id, cls, fmt, func, ...) ({ \
DEFINE_DYNAMIC_DEBUG_METADATA_CLS(id, cls, fmt); \
if (DYNAMIC_DEBUG_BRANCH(id)) { \
func(__VA_ARGS__); \
__dynamic_dump_stack(id); \
} \
-} while (0)
+ 0; /* match no_printk return value */ \
+})
#define __dynamic_func_call_no_desc(id, fmt, func, ...) \
__dynamic_func_call_cls_no_desc(id, _DPRINTK_CLASS_DFLT, \
fmt, func, ##__VA_ARGS__)
@@ -321,10 +323,12 @@ void __dynamic_ibdev_dbg(struct _ddebug *descriptor,
dev_no_printk(KERN_DEBUG, dev, fmt, ##__VA_ARGS__)
#define dynamic_hex_dump(prefix_str, prefix_type, rowsize, \
groupsize, buf, len, ascii) \
- do { if (0) \
+({ \
+ if (0) \
print_hex_dump(KERN_DEBUG, prefix_str, prefix_type, \
- rowsize, groupsize, buf, len, ascii); \
- } while (0)
+ rowsize, groupsize, buf, len, ascii); \
+ 0; \
+})
#endif /* CONFIG_DYNAMIC_DEBUG || (CONFIG_DYNAMIC_DEBUG_CORE && DYNAMIC_DEBUG_MODULE) */
--
2.54.0
^ permalink raw reply related
* [PATCH v2 22/24] selftests-dyndbg: add a dynamic_debug run_tests target
From: Jim Cromie @ 2026-05-23 7:14 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Arnd Bergmann, Jason Baron,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Andrew Morton, Shuah Khan
Cc: linux-doc, linux-kernel, linux-arch, linux-modules,
linux-kselftest, Jim Cromie, Łukasz Bartosik, Louis Chauvet
In-Reply-To: <20260523-dd-maint-2-v2-0-b937312aa083@gmail.com>
Add a selftest script for dynamic-debug. The config requires
CONFIG_TEST_DYNAMIC_DEBUG=m and CONFIG_TEST_DYNAMIC_DEBUG_SUBMOD=m,
which tacitly requires either CONFIG_DYNAMIC_DEBUG=y or
CONFIG_DYNAMIC_DEBUG_CORE=y
ATM this has just basic_tests(), which modify pr_debug() flags in the
builtin params module. This means they're available to manipulate and
observe the effects in "cat control".
This is backported from another feature branch; the support-fns (thx
Lukas) have unused features at the moment, they'll get used shortly.
The script enables simple virtme-ng testing:
[jimc@gandalf b0-ftrace]$ vrun_t
virtme-ng 1.32+115.g07b109d
doing: vng --name v6.14-rc4-60-gd5f48427de0c \
--user root -v -p 4 -a dynamic_debug.verbose=3 V=1 \
-- ../tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh
virtme: waiting for virtiofsd to start
..
And add dynamic_debug to TARGETS, so `make run_tests` sees it properly
For the impatient, set TARGETS explicitly:
[root@v6 selftests]# make TARGETS=dynamic_debug run_tests
make[1]: Nothing to be done for 'all'.
TAP version 13
1..1
# timeout set to 45
# selftests: dynamic_debug: dyndbg_selftest.sh
# # BASIC_TESTS 95.422122] dyndbg: query 0: 0"=_" mod:*
...
NOTES
check KCONFIG_CONFIG to avoid silly fails
Several tests are dependent upon config choices. Lets avoid failing
where that is noise.
The KCONFIG_CONFIG var exists to convey the config-file around. If
the var names a file, read it and extract the relevant CONFIG items,
and use them to skip the dependent tests, thus avoiding the fails that
would follow, and the disruption to whatever CI is running these
selftests.
If the envar doesn't name a config-file, ".config" is assumed.
CONFIG_DYNAMIC_DEBUG=y:
basic-tests() and comma-terminator-tests() test for the presence of
the builtin pr_debugs in module/main.c, which I deemed stable and
therefore safe to count. That said, the test fails if only
CONFIG_DYNAMIC_DEBUG_CORE=y is set. It could be rewritten to test
against test-dynamic-debug.ko, but that just trades one config
dependence for another.
Co-developed-by: Łukasz Bartosik <ukaszb@chromium.org>
Signed-off-by: Łukasz Bartosik <ukaszb@chromium.org>
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
---
v2:
drop commit-msg mention of yet-to-be-submitted tests
move RvB after SoB
script fixups per sashiko review
1. CONFIG_DYNAMIC_DEBUG=y is set correctly.
2. All subshell captures $( ( ... ) 2>&1 ) are fixed.
3. All echo variables are safely quoted to prevent word-splitting.
4. Standardized on modern /sys/kernel/tracing/ paths.
5. exit $exp_exit_code correctly propagates failure status.
---
MAINTAINERS | 1 +
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/dynamic_debug/Makefile | 9 +
tools/testing/selftests/dynamic_debug/config | 8 +
.../selftests/dynamic_debug/dyndbg_selftest.sh | 257 +++++++++++++++++++++
5 files changed, 276 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e87bfe2e9e62..3f1c7dd278d4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9083,6 +9083,7 @@ F: include/asm-generic/dyndbg.lds.h
F: include/linux/dynamic_debug.h
F: lib/dynamic_debug.c
F: lib/test_dynamic_debug.c
+F: tools/testing/selftests/dynamic_debug/*
DYNAMIC INTERRUPT MODERATION
M: Tal Gilboa <talgi@nvidia.com>
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 6e59b8f63e41..17c4ddbcee89 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -27,6 +27,7 @@ TARGETS += drivers/net/team
TARGETS += drivers/net/virtio_net
TARGETS += drivers/platform/x86/intel/ifs
TARGETS += dt
+TARGETS += dynamic_debug
TARGETS += efivarfs
TARGETS += exec
TARGETS += fchmodat2
diff --git a/tools/testing/selftests/dynamic_debug/Makefile b/tools/testing/selftests/dynamic_debug/Makefile
new file mode 100644
index 000000000000..6d06fa7f1040
--- /dev/null
+++ b/tools/testing/selftests/dynamic_debug/Makefile
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0-only
+# borrowed from Makefile for user memory selftests
+
+# No binaries, but make sure arg-less "make" doesn't trigger "run_tests"
+all:
+
+TEST_PROGS := dyndbg_selftest.sh
+
+include ../lib.mk
diff --git a/tools/testing/selftests/dynamic_debug/config b/tools/testing/selftests/dynamic_debug/config
new file mode 100644
index 000000000000..ec478b17873d
--- /dev/null
+++ b/tools/testing/selftests/dynamic_debug/config
@@ -0,0 +1,8 @@
+
+# basic tests ref the builtin params module
+CONFIG_DYNAMIC_DEBUG=y
+
+# more testing is possible with these,
+# but insisting on them here skips testing entirely for such configs
+# CONFIG_TEST_DYNAMIC_DEBUG=m
+# CONFIG_TEST_DYNAMIC_DEBUG_SUBMOD=m
diff --git a/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh b/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh
new file mode 100755
index 000000000000..01c035fe8c9a
--- /dev/null
+++ b/tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh
@@ -0,0 +1,257 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0-only
+
+V=${V:=0} # invoke as V=1 $0 for global verbose
+RED="\033[0;31m"
+GREEN="\033[0;32m"
+YELLOW="\033[0;33m"
+BLUE="\033[0;34m"
+MAGENTA="\033[0;35m"
+CYAN="\033[0;36m"
+NC="\033[0;0m"
+error_msg=""
+
+[ -e /proc/dynamic_debug/control ] || {
+ echo -e "${RED}: this test requires CONFIG_DYNAMIC_DEBUG=y ${NC}"
+ exit 0 # nothing to test here, no good reason to fail.
+}
+
+# need info to avoid failures due to untestable configs
+
+[ -f "$KCONFIG_CONFIG" ] || KCONFIG_CONFIG=".config"
+if [ -f "$KCONFIG_CONFIG" ]; then
+ echo "# consulting KCONFIG_CONFIG: $KCONFIG_CONFIG"
+ grep -q "CONFIG_DYNAMIC_DEBUG=y" $KCONFIG_CONFIG ; LACK_DD_BUILTIN=$?
+ grep -q "CONFIG_TEST_DYNAMIC_DEBUG=m" $KCONFIG_CONFIG ; LACK_TMOD=$?
+ grep -q "CONFIG_TEST_DYNAMIC_DEBUG_SUBMOD=m" $KCONFIG_CONFIG ; LACK_TMOD_SUBMOD=$?
+ if [ $V -eq 1 ]; then
+ echo LACK_DD_BUILTIN: $LACK_DD_BUILTIN
+ echo LACK_TMOD: $LACK_TMOD
+ echo LACK_TMOD_SUBMOD: $LACK_TMOD_SUBMOD
+ fi
+else
+ LACK_DD_BUILTIN=0
+ LACK_TMOD=0
+ LACK_TMOD_SUBMOD=0
+fi
+
+function vx () {
+ echo "$1" > /sys/module/dynamic_debug/parameters/verbose
+}
+
+function ddgrep () {
+ grep "$1" /proc/dynamic_debug/control
+}
+
+function doprints () {
+ cat /sys/module/test_dynamic_debug/parameters/do_prints
+}
+
+function ddcmd () {
+ exp_exit_code=0
+ num_args=$#
+ if [ "${@:$#}" = "pass" ]; then
+ num_args=$#-1
+ elif [ "${@:$#}" = "fail" ]; then
+ num_args=$#-1
+ exp_exit_code=1
+ fi
+ args=${@:1:$num_args}
+ output=$( (echo "$args" > /proc/dynamic_debug/control) 2>&1)
+ exit_code=$?
+ error_msg=$(echo "$output" | cut -d ":" -f 5 | sed -e 's/^[[:space:]]*//')
+ handle_exit_code $BASH_LINENO $FUNCNAME $exit_code $exp_exit_code
+}
+
+function handle_exit_code() {
+ local exp_exit_code=0
+ [ $# == 4 ] && exp_exit_code=$4
+ if [ $3 -ne $exp_exit_code ]; then
+ echo -e "${RED}: $BASH_SOURCE:$1 $2() expected to exit with code $exp_exit_code"
+ [ $3 == 1 ] && echo "Error: '$error_msg'"
+ exit $exp_exit_code
+ fi
+}
+
+# $1 - pattern to match, pattern in $1 is enclosed by spaces for a match ""\s$1\s"
+# $2 - number of times the pattern passed in $1 is expected to match
+# $3 - optional can be set either to "-r" or "-v"
+# "-r" means relaxed matching in this case pattern provided in $1 is passed
+# as is without enclosing it with spaces
+# "-v" prints matching lines
+# $4 - optional when $3 is set to "-r" then $4 can be used to pass "-v"
+function check_match_ct {
+ pattern="\s$1\s"
+ exp_cnt=0
+
+ [ "$3" == "-r" ] && pattern="$1"
+ let cnt=$(ddgrep "$pattern" | wc -l)
+ if [ $V -eq 1 ] || [ "$3" == "-v" ] || [ "$4" == "-v" ]; then
+ echo -ne "${BLUE}" && ddgrep $pattern && echo -ne "${NC}"
+ fi
+ [ $# -gt 1 ] && exp_cnt=$2
+ if [ $cnt -ne $exp_cnt ]; then
+ echo -e "${RED}: $BASH_SOURCE:$BASH_LINENO check failed expected $exp_cnt on $1, got $cnt"
+ exit
+ else
+ echo ": $cnt matches on $1"
+ fi
+}
+
+# $1 - trace instance name
+# #2 - if > 0 then directory is expected to exist, if <= 0 then otherwise
+# $3 - "-v" for verbose
+function check_trace_instance_dir {
+ if [ -e /sys/kernel/tracing/instances/$1 ]; then
+ if [ "$3" == "-v" ] ; then
+ echo "ls -l /sys/kernel/tracing/instances/$1: "
+ ls -l /sys/kernel/tracing/instances/$1
+ fi
+ if [ $2 -le 0 ]; then
+ echo -e "${RED}: $BASH_SOURCE:$BASH_LINENO error trace instance \
+ '/sys/kernel/tracing/instances/$1' does exist"
+ exit
+ fi
+ else
+ if [ $2 -gt 0 ]; then
+ echo -e "${RED}: $BASH_SOURCE:$BASH_LINENO error trace instance \
+ '/sys/kernel/tracing/instances/$1' does not exist"
+ exit
+ fi
+ fi
+}
+
+function tmark {
+ echo $* > /sys/kernel/tracing/trace_marker
+}
+
+# $1 - trace instance name
+# $2 - line number
+# $3 - if > 0 then the instance is expected to be opened, otherwise
+# the instance is expected to be closed
+function check_trace_instance {
+ output=$(tail -n9 /proc/dynamic_debug/control | grep ": Opened trace instances" \
+ | xargs -n1 | grep $1)
+ if [ "$output" != $1 ] && [ $3 -gt 0 ]; then
+ echo -e "${RED}: $BASH_SOURCE:$2 trace instance $1 is not opened"
+ exit
+ fi
+ if [ "$output" == $1 ] && [ $3 -le 0 ]; then
+ echo -e "${RED}: $BASH_SOURCE:$2 trace instance $1 is not closed"
+ exit
+ fi
+}
+
+function is_trace_instance_opened {
+ check_trace_instance $1 $BASH_LINENO 1
+}
+
+function is_trace_instance_closed {
+ check_trace_instance $1 $BASH_LINENO 0
+}
+
+# $1 - trace instance directory to delete
+# $2 - if > 0 then directory is expected to be deleted successfully, if <= 0 then otherwise
+function del_trace_instance_dir() {
+ exp_exit_code=1
+ [ $2 -gt 0 ] && exp_exit_code=0
+ output=$( (rmdir /sys/kernel/tracing/instances/$1) 2>&1)
+ exit_code=$?
+ error_msg=$(echo "$output" | cut -d ":" -f 3 | sed -e 's/^[[:space:]]*//')
+ handle_exit_code $BASH_LINENO $FUNCNAME $exit_code $exp_exit_code
+}
+
+function error_log_ref {
+ # to show what I got
+ : echo "# error-log-ref: $1"
+ : echo cat \$2
+}
+
+function ifrmmod {
+ lsmod | grep $1 2>&1>/dev/null && rmmod $1
+}
+
+# $1 - text to search for
+function search_trace() {
+ search_trace_name 0 1 $1
+}
+
+# $1 - trace instance name, 0 for global event trace
+# $2 - line number counting from the bottom
+# $3 - text to search for
+function search_trace_name() {
+ if [ "$1" = "0" ]; then
+ buf=$(cat /sys/kernel/tracing/trace)
+ line=$(tail -$2 /sys/kernel/tracing/trace | head -1 | sed -e 's/^[[:space:]]*//')
+ else
+ buf=$(cat /sys/kernel/tracing/instances/$1/trace)
+ line=$(tail -$2 /sys/kernel/tracing/instances/$1/trace | head -1 | \
+ sed -e 's/^[[:space:]]*//')
+ fi
+ if [ $2 = 0 ]; then
+ # whole-buf check
+ output=$(echo "$buf" | grep "$3")
+ else
+ output=$(echo "$line" | grep "$3")
+ fi
+ if [ "$output" = "" ]; then
+ echo -e "${RED}: $BASH_SOURCE:$BASH_LINENO search for '$3' failed \
+ in line '$line' or '$buf'"
+ exit
+ fi
+ if [ $V = 1 ]; then
+ echo -e "${MAGENTA}: search_trace_name in $1 found: \n$output \nin:${BLUE} $buf ${NC}"
+ fi
+}
+
+# $1 - error message to check
+function check_err_msg() {
+ if [ "$error_msg" != "$1" ]; then
+ echo -e "${RED}: $BASH_SOURCE:$BASH_LINENO error message '$error_msg' \
+ does not match with '$1'"
+ exit
+ fi
+}
+
+function basic_tests {
+ echo -e "${GREEN}# BASIC_TESTS ${NC}"
+ if [ $LACK_DD_BUILTIN -eq 1 ]; then
+ echo "SKIP"
+ return
+ fi
+ ddcmd =_ # zero everything
+ check_match_ct =p 0
+
+ # module params are builtin to handle boot args
+ check_match_ct '\[params\]' 4 -r
+ ddcmd module params +mpf
+ check_match_ct =pmf 4
+
+ # multi-cmd input, newline separated, with embedded comments
+ cat <<"EOF" > /proc/dynamic_debug/control
+ module params =_ # clear params
+ module params +mf # set flags
+ module params func parse_args +sl # other flags
+EOF
+ check_match_ct =mf 3
+ check_match_ct =mfsl 1
+ ddcmd =_
+}
+
+tests_list=(
+ basic_tests
+)
+
+# Run tests
+
+ifrmmod test_dynamic_debug_submod
+ifrmmod test_dynamic_debug
+
+for test in "${tests_list[@]}"
+do
+ $test
+ echo ""
+done
+echo -en "${GREEN}# Done on: "
+date
+echo -en "${NC}"
--
2.54.0
^ permalink raw reply related
* [PATCH v2 21/24] dyndbg: hoist classmap-filter-by-modname up to ddebug_add_module
From: Jim Cromie @ 2026-05-23 7:14 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Arnd Bergmann, Jason Baron,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Andrew Morton, Shuah Khan
Cc: linux-doc, linux-kernel, linux-arch, linux-modules,
linux-kselftest, Jim Cromie, Louis Chauvet
In-Reply-To: <20260523-dd-maint-2-v2-0-b937312aa083@gmail.com>
The body of ddebug_attach_module_classes() is just a code-block that
finds the contiguous subrange of classmaps matching on modname, and
saves it into the ddebug_table's info record.
Implement this block in a macro to accommodate different component
vectors in the "box" (as named in the for_subvec macro). We will
reuse this macro shortly.
And hoist its invocation out of ddebug_attach_module_classes() up into
ddebug_add_module(). This moves the filtering step up closer to
dynamic_debug_init(), which already segments the builtin pr_debug
descriptors on their mod_name boundaries.
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
---
v2:
move RvB after SoB
finish hoist - drop old fn - ddebug_attach_module_classes
the v1 rev left the old ddebug_attach_module_classes in place, but it
is completely redundant now, since it already lost the list-linking
job it was doing.
It was being cut out later in the patchset (in the unsent API
adaptation phase), but for cleaner review, lets excise it now.
OLD all-in-1-series (pre split into reviewable chunks)
v10?- reordered params to match kdoc
v12- refactor/rename: s/dd_mark_vector_subrange/dd_set_module_subrange/
1. Renamed the macro from dd_mark_vector_subrange to
dd_set_module_subrange to better reflect its purpose of narrowing a
vector to a module-specific subrange.
2. Simplified the arguments by removing the redundant _dst, as the _di
pointer already provides access to the target _ddebug_info struct.
3. Refactored for Clarity: Instead of overwriting the struct's start
pointer while the for_subvec loop is using it to iterate, I
introduced a temporary __start variable. This avoids the "subtle"
side effect and makes the logic easier to follow.
4. Updated Documentation: Improved the comment block to explicitly
state that the macro scans for the first match and counts
contiguous elements.
---
lib/dynamic_debug.c | 65 +++++++++++++++++++++++++++--------------------------
1 file changed, 33 insertions(+), 32 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 4a9b9bc9efc5..b877f4c6d778 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -162,8 +162,8 @@ static void vpr_info_dq(const struct ddebug_query *query, const char *msg)
}
static struct _ddebug_class_map *ddebug_find_valid_class(struct ddebug_table const *dt,
- const char *class_string,
- int *class_id)
+ const char *class_string,
+ int *class_id)
{
struct _ddebug_class_map *map;
int i, idx;
@@ -1166,34 +1166,34 @@ static const struct proc_ops proc_fops = {
.proc_write = ddebug_proc_write
};
-static void ddebug_attach_module_classes(struct ddebug_table *dt, struct _ddebug_info *di)
-{
- struct _ddebug_class_map *cm;
- int i, nc = 0;
-
- /*
- * Find this module's classmaps in a subrange/wholerange of
- * the builtin/modular classmap vector/section. Save the start
- * and length of the subrange at its edges.
- */
- for_subvec(i, cm, di, maps) {
- if (!strcmp(cm->mod_name, dt->info.mod_name)) {
- if (!nc) {
- v2pr_info("start subrange, class[%d]: module:%s base:%d len:%d ty:%d\n",
- i, cm->mod_name, cm->base, cm->length, cm->map_type);
- dt->info.maps.start = cm;
- }
- nc++;
- } else if (nc) {
- /* end of matching classmaps */
- break;
- }
- }
- if (nc) {
- dt->info.maps.len = nc;
- vpr_info("module:%s attached %d classes\n", dt->info.mod_name, nc);
- }
-}
+/*
+ * Narrow a _ddebug_info's vector (@_vec) to the contiguous subrange
+ * of elements where ->mod_name matches @__di->mod_name.
+ *
+ * This scans the @_di->_vec for the first element matching the module
+ * name, and counts contiguous matches to define the subrange.
+ *
+ * @_i: caller-provided index var
+ * @_sp: cursor into @_vec
+ * @_di: pointer to the struct _ddebug_info to be narrowed
+ * @_vec: name of the vector member (must have .start and .len)
+ */
+#define dd_set_module_subrange(_i, _sp, _di, _vec) ({ \
+ struct _ddebug_info *__di = (_di); \
+ typeof(__di->_vec.start) __start = NULL; \
+ int __nc = 0; \
+ for_subvec(_i, _sp, __di, _vec) { \
+ if (!strcmp((_sp)->mod_name, __di->mod_name)) { \
+ if (!__nc++) \
+ __start = (_sp); \
+ } else if (__nc) { \
+ break; /* end of consecutive matches */ \
+ } \
+ } \
+ if (__nc) \
+ __di->_vec.start = __start; \
+ __di->_vec.len = __nc; \
+})
/*
* Allocate a new ddebug_table for the given module
@@ -1202,6 +1202,8 @@ static void ddebug_attach_module_classes(struct ddebug_table *dt, struct _ddebug
static int ddebug_add_module(struct _ddebug_info *di)
{
struct ddebug_table *dt;
+ struct _ddebug_class_map *cm;
+ int i;
if (!di->descs.len)
return 0;
@@ -1223,8 +1225,7 @@ static int ddebug_add_module(struct _ddebug_info *di)
INIT_LIST_HEAD(&dt->link);
- if (di->maps.len)
- ddebug_attach_module_classes(dt, di);
+ dd_set_module_subrange(i, cm, &dt->info, maps);
mutex_lock(&ddebug_lock);
list_add_tail(&dt->link, &ddebug_tables);
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox