Hi all,
[Also in the device-mapper tree]
In commit
900095bfbbf6 ("nvme-fabrics: error out to unlock the mutex")
Fixes tag
Fixes: f0cebf82004d ("nvme-fabrics: prevent overriding of existing host")
has these problem(s):
- Target SHA1 does not exist
Maybe you meant
Fixes: ae8bd606e09b ("nvme-fabrics: prevent overriding of existing host")
--
Cheers,
Stephen Rothwell
On 6/18/23 15:22, Stephen Rothwell wrote:
> Hi all,
>
> [Also in the device-mapper tree]
>
> In commit
>
> 900095bfbbf6 ("nvme-fabrics: error out to unlock the mutex")
>
> Fixes tag
>
> Fixes: f0cebf82004d ("nvme-fabrics: prevent overriding of existing host")
sorry I didn't understand this with above tag I could format a patch
that leads to above subject line :-
nvme (nvme-6.5) # git format-patch f0cebf82004d -1
0001-nvme-fabrics-prevent-overriding-of-existing-host.patch
directory
nvme (nvme-6.5) # cat
0001-nvme-fabrics-prevent-overriding-of-existing-host.patch
From f0cebf82004d610be3ef47abf315ddf95aa2dcd1 Mon Sep 17 00:00:00 2001
From: Max Gurtovoy <[email protected]>
Date: Fri, 12 May 2023 18:41:55 +0300
Subject: [PATCH] nvme-fabrics: prevent overriding of existing host
When first connecting a target using the "default" host parameters,
setting the hostid from the command line during a subsequent connection
establishment would override the "default" hostid parameter. This would
cause an existing connection that is already using the host definitions
to lose its hostid.
To address this issue, the code has been modified to allow only 1:1
mapping between hostnqn and hostid. This will maintain unambiguous host
identification. Any non 1:1 mapping will be rejected during connection
establishment.
Tested-by: Noam Gottlieb <[email protected]>
Reviewed-by: Israel Rukshin <[email protected]>
Signed-off-by: Max Gurtovoy <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Keith Busch <[email protected]>
---
> has these problem(s):
>
> - Target SHA1 does not exist
>
> Maybe you meant
>
> Fixes: ae8bd606e09b ("nvme-fabrics: prevent overriding of existing host")
>
Hi,
在 2023/08/15 7:19, Stephen Rothwell 写道:
> Hi all,
>
> In commit
>
> 71070e7bd25d ("md/raid10: fix a 'conf->barrier' leakage in raid10_takeover()")
>
> Fixes tag
>
> Fixes: 4d27e927344a ("md: don't quiesce in mddev_suspend()")
>
> has these problem(s):
>
> - Target SHA1 does not exist
Sorry about this, the commit was picked from previous md-next branch,
and I didn't know that it will change...
Is there any way that I can fix this ?
Thanks,
Kuai
>
> Maybe you meant
>
> Fixes: b39f35ebe86d ("md: don't quiesce in mddev_suspend()")
>
On Wed, Aug 16, 2023 at 12:20 AM Jens Axboe <[email protected]> wrote:
>
> On 8/15/23 10:17 AM, Song Liu wrote:
> > On Wed, Aug 16, 2023 at 12:07?AM Jens Axboe <[email protected]> wrote:
> >>
> >> On 8/15/23 9:58 AM, Song Liu wrote:
> >>> On Tue, Aug 15, 2023 at 11:08?PM Jens Axboe <[email protected]> wrote:
> >>>>
> >>>> On 8/14/23 9:21 PM, Yu Kuai wrote:
> >>>>> Hi,
> >>>>>
> >>>>> ? 2023/08/15 7:19, Stephen Rothwell ??:
> >>>>>> Hi all,
> >>>>>>
> >>>>>> In commit
> >>>>>>
> >>>>>> 71070e7bd25d ("md/raid10: fix a 'conf->barrier' leakage in raid10_takeover()")
> >>>>>>
> >>>>>> Fixes tag
> >>>>>>
> >>>>>> Fixes: 4d27e927344a ("md: don't quiesce in mddev_suspend()")
> >>>>>>
> >>>>>> has these problem(s):
> >>>>>>
> >>>>>> - Target SHA1 does not exist
> >>>>>
> >>>>> Sorry about this, the commit was picked from previous md-next branch,
> >>>>> and I didn't know that it will change...
> >>>>
> >>>> It's most likely not your fault, I'm guessing Song rebased that branch
> >>>> and this is why the sha changed. Song?
> >>>
> >>> Yeah, it is my fault. I am really sorry for this issue.
> >>>
> >>>>
> >>>>> Is there any way that I can fix this ?
> >>>>
> >>>> Only way to fix this is if I rewind my branch and Song updates his
> >>>> branch to not have this issue, and then sends a new pull request.
> >>>
> >>> Yes please. Let's fix this.
> >>
> >> Please send a new one, I've dropped the old one.
> >
> > Is this the for-6.6/block branch? I haven't seen the change yet. The top
> > commit on the branch (as I see) is
> >
> > 306d74055754 ("ublk: Switch to memdup_user_nul() helper")
>
> Where are you looking? It's at:
I am looking at
https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
It appears to be some lag from git server?
Thanks,
Song
>
> commit 66a6a5d0ec852eaced589da066376e69397cd71e (origin/for-6.6/block, for-6.6/block)
> Author: Ruan Jinjie <[email protected]>
> Date: Tue Aug 15 19:48:14 2023 +0800
>
> ublk: Switch to memdup_user_nul() helper
>
> since about 15 min ago.
On Tue, Aug 15, 2023 at 11:08 PM Jens Axboe <[email protected]> wrote:
>
> On 8/14/23 9:21 PM, Yu Kuai wrote:
> > Hi,
> >
> > ? 2023/08/15 7:19, Stephen Rothwell ??:
> >> Hi all,
> >>
> >> In commit
> >>
> >> 71070e7bd25d ("md/raid10: fix a 'conf->barrier' leakage in raid10_takeover()")
> >>
> >> Fixes tag
> >>
> >> Fixes: 4d27e927344a ("md: don't quiesce in mddev_suspend()")
> >>
> >> has these problem(s):
> >>
> >> - Target SHA1 does not exist
> >
> > Sorry about this, the commit was picked from previous md-next branch,
> > and I didn't know that it will change...
>
> It's most likely not your fault, I'm guessing Song rebased that branch
> and this is why the sha changed. Song?
Yeah, it is my fault. I am really sorry for this issue.
>
> > Is there any way that I can fix this ?
>
> Only way to fix this is if I rewind my branch and Song updates his
> branch to not have this issue, and then sends a new pull request.
Yes please. Let's fix this.
Song
On Wed, Aug 16, 2023 at 12:07 AM Jens Axboe <[email protected]> wrote:
>
> On 8/15/23 9:58 AM, Song Liu wrote:
> > On Tue, Aug 15, 2023 at 11:08?PM Jens Axboe <[email protected]> wrote:
> >>
> >> On 8/14/23 9:21 PM, Yu Kuai wrote:
> >>> Hi,
> >>>
> >>> ? 2023/08/15 7:19, Stephen Rothwell ??:
> >>>> Hi all,
> >>>>
> >>>> In commit
> >>>>
> >>>> 71070e7bd25d ("md/raid10: fix a 'conf->barrier' leakage in raid10_takeover()")
> >>>>
> >>>> Fixes tag
> >>>>
> >>>> Fixes: 4d27e927344a ("md: don't quiesce in mddev_suspend()")
> >>>>
> >>>> has these problem(s):
> >>>>
> >>>> - Target SHA1 does not exist
> >>>
> >>> Sorry about this, the commit was picked from previous md-next branch,
> >>> and I didn't know that it will change...
> >>
> >> It's most likely not your fault, I'm guessing Song rebased that branch
> >> and this is why the sha changed. Song?
> >
> > Yeah, it is my fault. I am really sorry for this issue.
> >
> >>
> >>> Is there any way that I can fix this ?
> >>
> >> Only way to fix this is if I rewind my branch and Song updates his
> >> branch to not have this issue, and then sends a new pull request.
> >
> > Yes please. Let's fix this.
>
> Please send a new one, I've dropped the old one.
Is this the for-6.6/block branch? I haven't seen the change yet. The top
commit on the branch (as I see) is
306d74055754 ("ublk: Switch to memdup_user_nul() helper")
Thanks,
Song
On Wed, Aug 16, 2023 at 12:31 AM Jens Axboe <[email protected]> wrote:
>
> On 8/15/23 10:26 AM, Song Liu wrote:
> > On Wed, Aug 16, 2023 at 12:20?AM Jens Axboe <[email protected]> wrote:
> >>
> >> On 8/15/23 10:17 AM, Song Liu wrote:
> >>> On Wed, Aug 16, 2023 at 12:07?AM Jens Axboe <[email protected]> wrote:
> >>>>
> >>>> On 8/15/23 9:58 AM, Song Liu wrote:
> >>>>> On Tue, Aug 15, 2023 at 11:08?PM Jens Axboe <[email protected]> wrote:
> >>>>>>
> >>>>>> On 8/14/23 9:21 PM, Yu Kuai wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> ? 2023/08/15 7:19, Stephen Rothwell ??:
> >>>>>>>> Hi all,
> >>>>>>>>
> >>>>>>>> In commit
> >>>>>>>>
> >>>>>>>> 71070e7bd25d ("md/raid10: fix a 'conf->barrier' leakage in raid10_takeover()")
> >>>>>>>>
> >>>>>>>> Fixes tag
> >>>>>>>>
> >>>>>>>> Fixes: 4d27e927344a ("md: don't quiesce in mddev_suspend()")
> >>>>>>>>
> >>>>>>>> has these problem(s):
> >>>>>>>>
> >>>>>>>> - Target SHA1 does not exist
> >>>>>>>
> >>>>>>> Sorry about this, the commit was picked from previous md-next branch,
> >>>>>>> and I didn't know that it will change...
> >>>>>>
> >>>>>> It's most likely not your fault, I'm guessing Song rebased that branch
> >>>>>> and this is why the sha changed. Song?
> >>>>>
> >>>>> Yeah, it is my fault. I am really sorry for this issue.
> >>>>>
> >>>>>>
> >>>>>>> Is there any way that I can fix this ?
> >>>>>>
> >>>>>> Only way to fix this is if I rewind my branch and Song updates his
> >>>>>> branch to not have this issue, and then sends a new pull request.
> >>>>>
> >>>>> Yes please. Let's fix this.
> >>>>
> >>>> Please send a new one, I've dropped the old one.
> >>>
> >>> Is this the for-6.6/block branch? I haven't seen the change yet. The top
> >>> commit on the branch (as I see) is
> >>>
> >>> 306d74055754 ("ublk: Switch to memdup_user_nul() helper")
> >>
> >> Where are you looking? It's at:
> >
> > I am looking at
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
> >
> > It appears to be some lag from git server?
>
> That's just a backup, I always pull and push from git.kernel.dk. The
> korg one will lag about an hour, depending on when things are pushed.
> I've never used the korg one as the canonical location.
Got it. I will update my git config.
Here is the updated PR:
The following changes since commit 66a6a5d0ec852eaced589da066376e69397cd71e:
ublk: Switch to memdup_user_nul() helper (2023-08-15 10:06:54 -0600)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/song/md.git
tags/md-next-20230814-resend
for you to fetch changes up to 0d0bd28c500173bfca78aa840f8f36d261ef1765:
md/raid5-cache: fix null-ptr-deref for r5l_flush_stripe_to_raid()
(2023-08-15 09:40:27 -0700)
----------------------------------------------------------------
Li Lingfeng (1):
md: Hold mddev->reconfig_mutex when trying to get mddev->sync_thread
WANG Xuerui (5):
raid6: remove the <linux/export.h> include from recov.c
raid6: guard the tables.c include of <linux/export.h> with __KERNEL__
raid6: test: cosmetic cleanups for the test Makefile
raid6: test: make sure all intermediate and artifact files are .gitignored
raid6: test: only check for Altivec if building on powerpc hosts
Yu Kuai (3):
md/raid5-cache: fix a deadlock in r5l_exit_log()
md/raid10: fix a 'conf->barrier' leakage in raid10_takeover()
md/raid5-cache: fix null-ptr-deref for r5l_flush_stripe_to_raid()
Zhang Shurong (1):
md: raid1: fix potential OOB in raid1_remove_disk()
drivers/md/md-cluster.c | 8 ++++----
drivers/md/md.c | 9 +++++----
drivers/md/md.h | 2 +-
drivers/md/raid1.c | 8 ++++++--
drivers/md/raid10.c | 3 +--
drivers/md/raid5-cache.c | 14 ++++++++------
drivers/md/raid5.c | 2 +-
lib/raid6/mktables.c | 2 ++
lib/raid6/recov.c | 1 -
lib/raid6/test/.gitignore | 3 +++
lib/raid6/test/Makefile | 50
++++++++++++++++++++++++++------------------------
11 files changed, 57 insertions(+), 45 deletions(-)
create mode 100644 lib/raid6/test/.gitignore
Thanks,
Song
On 8/15/23 10:17 AM, Song Liu wrote:
> On Wed, Aug 16, 2023 at 12:07?AM Jens Axboe <[email protected]> wrote:
>>
>> On 8/15/23 9:58 AM, Song Liu wrote:
>>> On Tue, Aug 15, 2023 at 11:08?PM Jens Axboe <[email protected]> wrote:
>>>>
>>>> On 8/14/23 9:21 PM, Yu Kuai wrote:
>>>>> Hi,
>>>>>
>>>>> ? 2023/08/15 7:19, Stephen Rothwell ??:
>>>>>> Hi all,
>>>>>>
>>>>>> In commit
>>>>>>
>>>>>> 71070e7bd25d ("md/raid10: fix a 'conf->barrier' leakage in raid10_takeover()")
>>>>>>
>>>>>> Fixes tag
>>>>>>
>>>>>> Fixes: 4d27e927344a ("md: don't quiesce in mddev_suspend()")
>>>>>>
>>>>>> has these problem(s):
>>>>>>
>>>>>> - Target SHA1 does not exist
>>>>>
>>>>> Sorry about this, the commit was picked from previous md-next branch,
>>>>> and I didn't know that it will change...
>>>>
>>>> It's most likely not your fault, I'm guessing Song rebased that branch
>>>> and this is why the sha changed. Song?
>>>
>>> Yeah, it is my fault. I am really sorry for this issue.
>>>
>>>>
>>>>> Is there any way that I can fix this ?
>>>>
>>>> Only way to fix this is if I rewind my branch and Song updates his
>>>> branch to not have this issue, and then sends a new pull request.
>>>
>>> Yes please. Let's fix this.
>>
>> Please send a new one, I've dropped the old one.
>
> Is this the for-6.6/block branch? I haven't seen the change yet. The top
> commit on the branch (as I see) is
>
> 306d74055754 ("ublk: Switch to memdup_user_nul() helper")
Where are you looking? It's at:
commit 66a6a5d0ec852eaced589da066376e69397cd71e (origin/for-6.6/block, for-6.6/block)
Author: Ruan Jinjie <[email protected]>
Date: Tue Aug 15 19:48:14 2023 +0800
ublk: Switch to memdup_user_nul() helper
since about 15 min ago.
--
Jens Axboe