mbox series

[GIT,PULL] DRBD fixes for Linux 5.18

Message ID 60bf3e8f-9cfb-00d1-5fea-71a72ba93258@linbit.com (mailing list archive)
State New, archived
Headers show
Series [GIT,PULL] DRBD fixes for Linux 5.18 | expand

Pull-request

https://github.com/LINBIT/linux-drbd.git tags/drbd-fixes-5.18-2022-04-06

Message

Christoph Böhmwalder April 6, 2022, 8:06 a.m. UTC
Hi Jens,

this is the first batch of DRBD updates, catching up from the last few years.
These fixes are a bit more substantial, so it would be great if they could still
go into 5.18.

Please pull.


The following changes since commit ff0f3f83175274daf2eb4fd4db6430ab71c66e80:

  Merge branch 'for-5.19/io_uring-xattr' into for-next (2022-04-04 17:59:51 -0600)

are available in the Git repository at:

  https://github.com/LINBIT/linux-drbd.git tags/drbd-fixes-5.18-2022-04-06

for you to fetch changes up to 0ab5e2117763190f684fdedb6f171abd4b939f1b:

  drbd: set QUEUE_FLAG_STABLE_WRITES (2022-04-06 09:16:13 +0200)

----------------------------------------------------------------
DRBD fixes for Linux 5.18

- enable stable writes for DRBD (Christoph Böhmwalder)
- fix a potential invalid memory access (Xiaomeng Tong)
- fix a use-after-free bug (Lv Yunlong)

----------------------------------------------------------------
Christoph Böhmwalder (1):
      drbd: set QUEUE_FLAG_STABLE_WRITES

Lv Yunlong (1):
      drbd: Fix five use after free bugs in get_initial_state

Xiaomeng Tong (1):
      drbd: fix an invalid memory access caused by incorrect use of list iterator

 drivers/block/drbd/drbd_int.h          |  8 ++++----
 drivers/block/drbd/drbd_main.c         |  7 +++----
 drivers/block/drbd/drbd_nl.c           | 41 +++++++++++++++++++++++++----------------
 drivers/block/drbd/drbd_state.c        | 18 +++++++++---------
 drivers/block/drbd/drbd_state_change.h |  8 ++++----
 5 files changed, 45 insertions(+), 37 deletions(-)

Comments

Jens Axboe April 6, 2022, 12:35 p.m. UTC | #1
On 4/6/22 2:06 AM, Christoph B?hmwalder wrote:
> Hi Jens,
> 
> this is the first batch of DRBD updates, catching up from the last few
> years. These fixes are a bit more substantial, so it would be great if
> they could still go into 5.18.

Thanks for sending these, but you based the repo on my 5.19 branch,
which won't work as pulling your tree will then result in me getting
your 5.18 changes with my 5.19 as well.

As it happens, this is also a problem for your 5.19 based changes. My
for-next branch is not stable, just like linux-next isn't stable. In
terms of shas, not how it runs...

In general, for the block tree, here's what you want to base the changes
on, using 5.18/5.19 as examples as current/next tree.

- If they are bound for 5.18, base them on block-5.18. That branch may
  not exist if nothing is queued up yet, in which case just base them on
  the last -rc1 tag for that series. That'd be 5.18-rc1 in this case.

- If they are bound for 5.19, usually I will have a 5.19 driver and core
  block branch. Base them against for-5.19/drivers. If it doesn't exist,
  previous -rc is a good choice again.

Usually post -rc2 all of the above branches will exist, during merge
window and right after things are a bit more influx and haven't really
settled down yet.

Now, there's also the fact that you're using a non kernel.org git tree.
That's fine, but ideally we'd like you to use signed tags in that case.
But not sure your key has been signed by anyone in the korg ring of
trust? Since I've already seen these patches this isn't a huge concern
for now, but something to get sorted out going forward.

Can you rebase your two pull requests and send them in again? Either
that, or just git send-email the two series, that'll work too. I'm fine
applying series from maintainers like that, it doesn't have to be a git
pull request.
Christoph Böhmwalder April 6, 2022, 7:02 p.m. UTC | #2
Am 06.04.22 um 14:35 schrieb Jens Axboe:
> On 4/6/22 2:06 AM, Christoph B?hmwalder wrote:
>> Hi Jens,
>>
>> this is the first batch of DRBD updates, catching up from the last few
>> years. These fixes are a bit more substantial, so it would be great if
>> they could still go into 5.18.
> 
> Thanks for sending these, but you based the repo on my 5.19 branch,
> which won't work as pulling your tree will then result in me getting
> your 5.18 changes with my 5.19 as well.
> 
> As it happens, this is also a problem for your 5.19 based changes. My
> for-next branch is not stable, just like linux-next isn't stable. In
> terms of shas, not how it runs...
> 
> In general, for the block tree, here's what you want to base the changes
> on, using 5.18/5.19 as examples as current/next tree.
> 
> - If they are bound for 5.18, base them on block-5.18. That branch may
>   not exist if nothing is queued up yet, in which case just base them on
>   the last -rc1 tag for that series. That'd be 5.18-rc1 in this case.
> 
> - If they are bound for 5.19, usually I will have a 5.19 driver and core
>   block branch. Base them against for-5.19/drivers. If it doesn't exist,
>   previous -rc is a good choice again.
> 
> Usually post -rc2 all of the above branches will exist, during merge
> window and right after things are a bit more influx and haven't really
> settled down yet.
> 
> Now, there's also the fact that you're using a non kernel.org git tree.
> That's fine, but ideally we'd like you to use signed tags in that case.
> But not sure your key has been signed by anyone in the korg ring of
> trust? Since I've already seen these patches this isn't a huge concern
> for now, but something to get sorted out going forward.
> 
> Can you rebase your two pull requests and send them in again? Either
> that, or just git send-email the two series, that'll work too. I'm fine
> applying series from maintainers like that, it doesn't have to be a git
> pull request.
> 

Good to know, thanks for the pointers and sorry for the mess. I'll
resend based on block-5.18 and 5.18-rc1 respectively.