archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <>
To: Thorsten Leemhuis <>,
	Daniel Harding <>,
	Pavel Begunkov <>
	Christian Brauner <>
Subject: Re: [REGRESSION] lxc-stop hang on 5.17.x kernels
Date: Mon, 16 May 2022 12:39:04 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 5/16/22 12:34 PM, Thorsten Leemhuis wrote:
> On 16.05.22 20:22, Jens Axboe wrote:
>> On 5/16/22 12:17 PM, Thorsten Leemhuis wrote:
>>>>> Pavel, I had actually just started a draft email with the same theory
>>>>> (although you stated it much more clearly than I could have).  I'm
>>>>> working on debugging the LXC side, but I'm pretty sure the issue is
>>>>> due to LXC using blocking reads and getting stuck exactly as you
>>>>> describe.  If I can confirm this, I'll go ahead and mark this
>>>>> regression as invalid and file an issue with LXC. Thanks for your help
>>>>> and patience.
>>>> Yes, it does appear that was the problem.  The attach POC patch against
>>>> LXC fixes the hang.  The kernel is working as intended.
>>>> #regzbot invalid:  userspace programming error
>>> Hmmm, not sure if I like this. So yes, this might be a bug in LXC, but
>>> afaics it's a bug that was exposed by kernel change in 5.17 (correct me
>>> if I'm wrong!). The problem thus still qualifies as a kernel regression
>>> that normally needs to be fixed, as can be seen my some of the quotes
>>> from Linus in this file:
>> Sorry, but that's really BS in this particularly case. This could always
>> have triggered, it's the way multishot works. Will we count eg timing
>> changes as potential regressions, because an application relied on
>> something there? That does not make it ABI.
>> In general I agree with Linus on this, a change in behavior breaking
>> something should be investigated and figured out (and reverted, if need
>> be). This is not that.
> Sorry, I have to deal with various subsystems and a lot of regressions
> reports. I can't know the details of each of issue and there are
> developers around that are not that familiar with all the practical
> implications of the "no regressions". That's why I was just trying to
> ensure that this is something safe to ignore. If you say it is, than I'm
> totally happy and now rest my case. :-D

It's just a slippery slope that quickly leads to the fact that _any_
kernel change is a potential regressions, as it may change something
that an app unknowingly depends on. For this case, the multishot ended
up being downgraded to single shot on older kernels, so you'd never see
multiple triggers of it. And multiple triggers is a natural effect of
the level triggered poll that io_uring does. The app didn't handle
multiple events in between reading them, which was an oversight in how
that was done.

Hence I do think this one can be safely closed.

Jens Axboe

  reply	other threads:[~2022-05-16 18:39 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-02 13:17 [REGRESSION] lxc-stop hang on 5.17.x kernels Daniel Harding
2022-05-02 13:26 ` Jens Axboe
2022-05-02 13:36   ` Daniel Harding
2022-05-02 13:59     ` Jens Axboe
2022-05-02 17:00       ` Jens Axboe
2022-05-02 17:40         ` Pavel Begunkov
2022-05-02 18:49           ` Daniel Harding
2022-05-02 23:14             ` Pavel Begunkov
2022-05-03  7:13               ` Daniel Harding
2022-05-03  7:37               ` Daniel Harding
2022-05-03 14:14                 ` Pavel Begunkov
2022-05-04  6:54                   ` Daniel Harding
2022-05-15  8:20                     ` Thorsten Leemhuis
2022-05-15 18:34                       ` Daniel Harding
2022-05-16 12:12                         ` Pavel Begunkov
2022-05-16 13:25                           ` Pavel Begunkov
2022-05-16 13:57                             ` Daniel Harding
2022-05-16 15:13                               ` Daniel Harding
2022-05-16 18:13                                 ` Pavel Begunkov
2022-05-17  8:19                                   ` Christian Brauner
2022-05-17 10:31                                     ` Pavel Begunkov
2022-05-16 18:17                                 ` Thorsten Leemhuis
2022-05-16 18:22                                   ` Jens Axboe
2022-05-16 18:34                                     ` Thorsten Leemhuis
2022-05-16 18:39                                       ` Jens Axboe [this message]
2022-05-16 19:07                                         ` Thorsten Leemhuis
2022-05-16 19:14                                           ` Jens Axboe

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).