Fail to remove a device via "mdadm -r" on ubuntu server 22.04.3

[shangsong]

[ Impact ]

 * An explanation of the effects of the bug on users and

 * justification for backporting the fix to the stable release.

 * In addition, it is helpful, but not required, to include an
   explanation of how the upload fixes this bug.

=>The customer will fail to remove NVME disk from container when they use "-r" option. if the fix can be backport into stable release , the users will remove successfully, no matter useing option '-r' or '--remove'.

[ Test Plan ]
To reproduce the issue:
1. Fresh install Ubuntu server 22.04.3
2. Create a container via below command:
# mdadm -C /dev/md0 /dev/nvme0n1 /dev/nvme1n1 -n 2 -e imsm
3. It will fail during removing a device from container /dev/md0
 # mdadm -r /dev/md0 /dev/nvme0n1
  mdadm: /dev/nvme0n1 does not appear to be an md device
 # mdadm /dev/md0 -r /dev/nvme0n1
  ==> No output

It can pass via "mdadm --remove /dev/md0 /dev/nvme0n1"

[ Where problems could occur ]

 * Think about what the upload changes in the software. Imagine the change is
   wrong or breaks something else: how would this show up?

 * It is assumed that any SRU candidate patch is well-tested before
   upload and has a low overall risk of regression, but it's important
   to make the effort to think about what ''could'' happen in the
   event of a regression.

 * This must '''never''' be "None" or "Low", or entirely an argument as to why
   your upload is low risk.

 * This both shows the SRU team that the risks have been considered,
   and provides guidance to testers in regression-testing the SRU.

[ Other Info ]

This was fixed upstream with this commit:
https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/commit/?id=190dc029b141c423e724566cbed5d5afbb10b05a

We pulled this in earlier this year here:
commit d1b153f83da24d9398a2c677d5bd962d622bf673 (tag: import/4.2+20230223-1)
Author: Daniel Baumann <email address hidden>
Date: Sat Feb 25 18:55:13 2023 +0100

    4.2+20230223-1 (patches unapplied)

    Imported using git-ubuntu import.

[shangsong (shangsong2)]

Based on the code of 4.2+20230508-6ubuntu1, it can fix this issue, but still does not enable it in jammy(4.2-0ubuntu2), please help enable it ASAP, thanks.
https://launchpad.net/ubuntu/+source/mdadm/4.2+20230508-6ubuntu1

[Jeff Lane  (bladernr)]

This change appears to have been pulled in here:
commit d1b153f83da24d9398a2c677d5bd962d622bf673 (tag: import/4.2+20230223-1)
Author: Daniel Baumann <email address hidden>
Date: Sat Feb 25 18:55:13 2023 +0100

    4.2+20230223-1 (patches unapplied)

    Imported using git-ubuntu import.

[shangsong (shangsong2)]

Hi Jeff,
  Is there any progress on this issue?

[Julian Andres Klode (juliank)]

We are not convinced that this is material for an SRU:

1. The impact is very low: If you pass -r nothing happens. Specifically there is no data loss
2. The workaround is trivial: Just pass --remove instead

Also the regression potential is significant as that change fixed a crash. While the crash is no longer present in upstream git at the point the commit was reverted, we'd have to ensure it also no longer happens in 22.04.

I think it's also fair to say we will definitely not be fixing this in lunar seeing as mantic is released and this is a very insignificant bug.

[shangsong (shangsong2)]

Hi Julian,
  What about the fix schedule on 22.04 or it will same with Lunar(Won't fix)?

Thanks,
Song

[shangsong (shangsong2)]

Hi Julian,Jeff,
  I known this is a low priority issue and need more time to confirm it does not bring any other issue when you revert it, but i think it is better to have fix schedule rather than endless waiting.
Thus, could you setup a fix schedule for this issue?