From: Jakub Kicinski <kuba@kernel.org>
To: Daniele Palmas <dnlplm@gmail.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
pabeni@redhat.com,
syzbot+d55372214aff0faa1f1f@syzkaller.appspotmail.com,
jhs@mojatatu.com, xiyou.wangcong@gmail.com, jiri@resnulli.us
Subject: Re: [RFC net-next] net: don't dump stack on queue timeout
Date: Fri, 10 Nov 2023 11:21:37 -0800 [thread overview]
Message-ID: <20231110112137.20930a9c@kernel.org> (raw)
In-Reply-To: <CAGRyCJFLytO-k1ekbQE5Z3LN7RVJciB_4Yh9PUVYA3EZeWMG5A@mail.gmail.com>
On Fri, 10 Nov 2023 09:01:29 +0100 Daniele Palmas wrote:
> The problem is that the MBIM standard does not define the
> CDC_NOTIFY_NETWORK_CONNECTION, so carrier loss detection is managed
> through the indications on the control channel.
>
> But the kernel is not aware of what's passing through the control
> channel, so it's the userspace tool that should detect carrier loss,
> disconnect the bearers and set the network interface down.
>
> For example, ModemManager is capable of doing that, but the problem is
> that usually the standard modem notifications on the control channel
> arrive later than the splat: increasing watchdog_timeo does not seem
> to me a good option, since the notification could arrive much later.
>
> One possible solution is to have some proprietary notifications on the
> control channel that detect RLF early and trigger the above described
> process before the warn happens: by coincidence, I wrote a custom
> ModemManager patch for this a few days ago
> https://gitlab.freedesktop.org/dnlplm/ModemManager/-/commit/89ba8ab65d4bfbd4cf1ff11ed58c08b112aca80f
I see, thanks for the extra info!
next prev parent reply other threads:[~2023-11-10 19:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-09 0:09 [RFC net-next] net: don't dump stack on queue timeout Jakub Kicinski
2023-11-09 7:40 ` Daniele Palmas
2023-11-09 15:18 ` Jakub Kicinski
2023-11-10 8:01 ` Daniele Palmas
2023-11-10 19:21 ` Jakub Kicinski [this message]
2023-11-09 13:15 ` Jiri Pirko
2023-11-09 15:21 ` Eric Dumazet
2023-11-10 13:11 ` Jamal Hadi Salim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231110112137.20930a9c@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=dnlplm@gmail.com \
--cc=edumazet@google.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=syzbot+d55372214aff0faa1f1f@syzkaller.appspotmail.com \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.