Thread (6 messages) 6 messages, 3 authors, 2018-06-26

Re: INFO: rcu detected stall in vprintk_emit

From: Dmitry Vyukov <dvyukov@google.com>
Date: 2018-06-26 05:04:25
Also in: linux-wireless, lkml

On Tue, Jun 26, 2018 at 4:59 AM, Steven Rostedt [off-list ref] wrote:
On Tue, 26 Jun 2018 10:49:24 +0900
Sergey Senozhatsky [off-list ref] wrote:
quoted
So we can try switching to ratelimited error reporting
[that would be option A]:

---
diff --git a/net/nfc/llcp_commands.c b/net/nfc/llcp_commands.c
index 2ceefa183cee..2f3becb709b8 100644
--- a/net/nfc/llcp_commands.c
+++ b/net/nfc/llcp_commands.c
@@ -755,7 +755,7 @@ int nfc_llcp_send_ui_frame(struct nfc_llcp_sock *sock, u8 ssap, u8 dsap,
              pdu = nfc_alloc_send_skb(sock->dev, &sock->sk, MSG_DONTWAIT,
                                       frag_len + LLCP_HEADER_SIZE, &err);
              if (pdu == NULL) {
-                     pr_err("Could not allocate PDU\n");
+                     pr_err_ratelimited("Could not allocate PDU\n");
                      continue;
              }

---

Or ratelimited error reporting and cond_resched()
[that would be option B]:
I don't think this is a printk() issue per se, so I think Option B is
the only option. You should not get stuck in an infinite loop if we run
short on memory. Perhaps we could have an Option C which would exit
this loop gracefully with some kind of error. But I haven't looked at
the surrounding code to be sure if that is possible.
I suspect this is not even OOM. This is probably some persistent
logical condition that makes the allocation function fail, either we
ask for too much, or socket in some bad state. Potentially this is
even triggerable remotely because there are some remove variables
involved in size calculation.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help