Linux RAID subsystem development
 help / color / mirror / Atom feed
From: Mikulas Patocka <mpatocka@redhat.com>
To: Luca Boccassi <luca.boccassi@gmail.com>
Cc: Xiao Ni <xni@redhat.com>, Yu Kuai <yukuai3@huawei.com>,
	 Song Liu <song@kernel.org>,
	linux-raid@vger.kernel.org,  vkuznets@redhat.com,
	yuwatana@redhat.com
Subject: Re: md regression caused by commit 9e59d609763f70a992a8f3808dabcce60f14eb5c
Date: Thu, 7 Aug 2025 16:17:57 +0200 (CEST)	[thread overview]
Message-ID: <8c1bf191-a741-cd7a-29dc-babf24a13777@redhat.com> (raw)
In-Reply-To: <CAMw=ZnTosW4OecBCFdVNqiw9VjSL6msUx6yYBE=9vsEn7JeKqA@mail.gmail.com>



On Thu, 7 Aug 2025, Luca Boccassi wrote:

> On Thu, 7 Aug 2025 at 01:04, Xiao Ni <xni@redhat.com> wrote:
> >
> > Hi all
> >
> > It needs to use the latest upstream mdadm
> > https://github.com/md-raid-utilities/mdadm/ which has fixed this
> > problem. And for fedora, it hasn't updated to the latest upstream. So
> > it has this problem. I'll update fedora mdadm to latest upstream.
> >
> > Best Regards
> > Xiao
> 
> Thank you for looking into it and providing a solution - however,
> isn't it against the rules to break existing released userspace
> components and requiring new versions to be released in order to use a
> new kernel version? Is there any way this kernel patch could be
> amended to avoid breaking the existing userspace as it is?
> 
> Thanks

I also think that the misbehavior should be fixed in the kernel.

We shouldn't use arbitrary timeouts to clean up the sysfs entries, because 
it would introduce race conditions.

What about destroying the sysfs entries when the file descriptor is 
closed? (instead of on the STOP_ARRAY ioctl) That wouldn't interfere with 
other code trying to stop the array and it would make it work with the 
buggy mdadm that calls STOP_ARRAY and then tries to find the sysfs entries 
and then calls SET_ARRAY_INFO.

Mikulas


  reply	other threads:[~2025-08-07 14:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-06 15:28 md regression caused by commit 9e59d609763f70a992a8f3808dabcce60f14eb5c Mikulas Patocka
2025-08-07  0:04 ` Xiao Ni
2025-08-07  8:40   ` Luca Boccassi
2025-08-07 14:17     ` Mikulas Patocka [this message]
2025-08-08  5:28       ` Xiao Ni
2025-08-08  6:40         ` Yu Kuai
2025-08-08  7:01           ` Xiao Ni
2025-08-08  8:07           ` Luca Boccassi
2025-08-11 18:31             ` Luca Boccassi
2025-08-12  7:40               ` Xiao Ni
2025-08-12  8:50                 ` Luca Boccassi

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=8c1bf191-a741-cd7a-29dc-babf24a13777@redhat.com \
    --to=mpatocka@redhat.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=luca.boccassi@gmail.com \
    --cc=song@kernel.org \
    --cc=vkuznets@redhat.com \
    --cc=xni@redhat.com \
    --cc=yukuai3@huawei.com \
    --cc=yuwatana@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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