* [git pull] device mapper fixes for 5.19-rc1
@ 2022-06-01 20:59 ` Mike Snitzer
0 siblings, 0 replies; 8+ messages in thread
From: Mike Snitzer @ 2022-06-01 20:59 UTC (permalink / raw)
To: Linus Torvalds
Cc: dm-devel, linux-block, Alasdair G Kergon, Sarthak Kukreti, Kees Cook
Hi Linus,
The following changes since commit ca522482e3eafd005b8d4e8b1331c911505a58d5:
dm: pass NULL bdev to bio_alloc_clone (2022-05-11 13:58:52 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git tags/for-5.19/dm-fixes
for you to fetch changes up to 4caae58406f8ceb741603eee460d79bacca9b1b5:
dm verity: set DM_TARGET_IMMUTABLE feature flag (2022-05-31 16:22:30 -0400)
Please pull, thanks.
Mike
----------------------------------------------------------------
- Fix DM core's dm_table_supports_poll to return false if no data
devices.
- Fix DM verity target so that it cannot be switched to a different DM
target type (e.g. dm-linear) via DM table reload.
----------------------------------------------------------------
Mike Snitzer (1):
dm table: fix dm_table_supports_poll to return false if no data devices
Sarthak Kukreti (1):
dm verity: set DM_TARGET_IMMUTABLE feature flag
drivers/md/dm-table.c | 19 +++++++++++++++----
drivers/md/dm-verity-target.c | 1 +
2 files changed, 16 insertions(+), 4 deletions(-)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [dm-devel] [git pull] device mapper fixes for 5.19-rc1
@ 2022-06-01 20:59 ` Mike Snitzer
0 siblings, 0 replies; 8+ messages in thread
From: Mike Snitzer @ 2022-06-01 20:59 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-block, Sarthak Kukreti, dm-devel, Kees Cook, Alasdair G Kergon
Hi Linus,
The following changes since commit ca522482e3eafd005b8d4e8b1331c911505a58d5:
dm: pass NULL bdev to bio_alloc_clone (2022-05-11 13:58:52 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git tags/for-5.19/dm-fixes
for you to fetch changes up to 4caae58406f8ceb741603eee460d79bacca9b1b5:
dm verity: set DM_TARGET_IMMUTABLE feature flag (2022-05-31 16:22:30 -0400)
Please pull, thanks.
Mike
----------------------------------------------------------------
- Fix DM core's dm_table_supports_poll to return false if no data
devices.
- Fix DM verity target so that it cannot be switched to a different DM
target type (e.g. dm-linear) via DM table reload.
----------------------------------------------------------------
Mike Snitzer (1):
dm table: fix dm_table_supports_poll to return false if no data devices
Sarthak Kukreti (1):
dm verity: set DM_TARGET_IMMUTABLE feature flag
drivers/md/dm-table.c | 19 +++++++++++++++----
drivers/md/dm-verity-target.c | 1 +
2 files changed, 16 insertions(+), 4 deletions(-)
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [git pull] device mapper fixes for 5.19-rc1
2022-06-01 20:59 ` [dm-devel] " Mike Snitzer
@ 2022-06-01 21:43 ` Linus Torvalds
-1 siblings, 0 replies; 8+ messages in thread
From: Linus Torvalds @ 2022-06-01 21:43 UTC (permalink / raw)
To: Mike Snitzer
Cc: device-mapper development, linux-block, Alasdair G Kergon,
Sarthak Kukreti, Kees Cook
On Wed, Jun 1, 2022 at 1:59 PM Mike Snitzer <snitzer@kernel.org> wrote:
>
> ----------------------------------------------------------------
> - Fix DM core's dm_table_supports_poll to return false if no data
> devices.
So looking at that one (mainly because of the incomprehensible
explanation), I do note:
(a) the caller does
for (i = 0; i < t->num_targets; i++) {
ti = t->targets + i;
while the callee does
unsigned i = 0;
while (i < dm_table_get_num_targets(t)) {
ti = dm_table_get_target(t, i++);
Now, those things are entirely equivalent, but that latter form is
likely to generate horribly bad code because those helper functions
aren't some kind of trivial inline, they are actually normal functions
that are defined later in that same source file.
Maybe a compiler will do optimizations within that source file even
for functions that haven't been defined yet. Traditionally not.
Whatever. Probably not a case where anybody cares about performance,
but it does strike me that the "use abstractions" version probably not
only generates worse code, it seems less legible too.
Very odd pattern.
(b) The commit message (which is why I started looking at this) says
that it used to return true even if there are no data devices.
But dm_table_supports_poll() actually _still_ returns true for at
least one case of no data devices: if the dm_table has no targets at
all.
So I don't know. Maybe that is a "can't happen". But since I looked at
this, I thought I'd just point out the two oddities I found while
doing so.
Linus
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-devel] [git pull] device mapper fixes for 5.19-rc1
@ 2022-06-01 21:43 ` Linus Torvalds
0 siblings, 0 replies; 8+ messages in thread
From: Linus Torvalds @ 2022-06-01 21:43 UTC (permalink / raw)
To: Mike Snitzer
Cc: linux-block, Sarthak Kukreti, device-mapper development,
Kees Cook, Alasdair G Kergon
On Wed, Jun 1, 2022 at 1:59 PM Mike Snitzer <snitzer@kernel.org> wrote:
>
> ----------------------------------------------------------------
> - Fix DM core's dm_table_supports_poll to return false if no data
> devices.
So looking at that one (mainly because of the incomprehensible
explanation), I do note:
(a) the caller does
for (i = 0; i < t->num_targets; i++) {
ti = t->targets + i;
while the callee does
unsigned i = 0;
while (i < dm_table_get_num_targets(t)) {
ti = dm_table_get_target(t, i++);
Now, those things are entirely equivalent, but that latter form is
likely to generate horribly bad code because those helper functions
aren't some kind of trivial inline, they are actually normal functions
that are defined later in that same source file.
Maybe a compiler will do optimizations within that source file even
for functions that haven't been defined yet. Traditionally not.
Whatever. Probably not a case where anybody cares about performance,
but it does strike me that the "use abstractions" version probably not
only generates worse code, it seems less legible too.
Very odd pattern.
(b) The commit message (which is why I started looking at this) says
that it used to return true even if there are no data devices.
But dm_table_supports_poll() actually _still_ returns true for at
least one case of no data devices: if the dm_table has no targets at
all.
So I don't know. Maybe that is a "can't happen". But since I looked at
this, I thought I'd just point out the two oddities I found while
doing so.
Linus
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [git pull] device mapper fixes for 5.19-rc1
2022-06-01 20:59 ` [dm-devel] " Mike Snitzer
@ 2022-06-01 21:52 ` pr-tracker-bot
-1 siblings, 0 replies; 8+ messages in thread
From: pr-tracker-bot @ 2022-06-01 21:52 UTC (permalink / raw)
To: Mike Snitzer
Cc: Linus Torvalds, dm-devel, linux-block, Alasdair G Kergon,
Sarthak Kukreti, Kees Cook
The pull request you sent on Wed, 1 Jun 2022 16:59:46 -0400:
> git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git tags/for-5.19/dm-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fa78526accfd68966fb50a429439e9085f9c88d6
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-devel] [git pull] device mapper fixes for 5.19-rc1
@ 2022-06-01 21:52 ` pr-tracker-bot
0 siblings, 0 replies; 8+ messages in thread
From: pr-tracker-bot @ 2022-06-01 21:52 UTC (permalink / raw)
To: Mike Snitzer
Cc: Kees Cook, Sarthak Kukreti, linux-block, dm-devel,
Linus Torvalds, Alasdair G Kergon
The pull request you sent on Wed, 1 Jun 2022 16:59:46 -0400:
> git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git tags/for-5.19/dm-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fa78526accfd68966fb50a429439e9085f9c88d6
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [git pull] device mapper fixes for 5.19-rc1
2022-06-01 21:43 ` [dm-devel] " Linus Torvalds
@ 2022-06-01 23:10 ` Mike Snitzer
-1 siblings, 0 replies; 8+ messages in thread
From: Mike Snitzer @ 2022-06-01 23:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-block, Sarthak Kukreti, device-mapper development,
Kees Cook, Alasdair G Kergon
On Wed, Jun 01 2022 at 5:43P -0400,
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, Jun 1, 2022 at 1:59 PM Mike Snitzer <snitzer@kernel.org> wrote:
> >
> > ----------------------------------------------------------------
> > - Fix DM core's dm_table_supports_poll to return false if no data
> > devices.
>
> So looking at that one (mainly because of the incomprehensible
> explanation), I do note:
>
> (a) the caller does
>
> for (i = 0; i < t->num_targets; i++) {
> ti = t->targets + i;
>
> while the callee does
>
> unsigned i = 0;
>
> while (i < dm_table_get_num_targets(t)) {
> ti = dm_table_get_target(t, i++);
>
> Now, those things are entirely equivalent, but that latter form is
> likely to generate horribly bad code because those helper functions
> aren't some kind of trivial inline, they are actually normal functions
> that are defined later in that same source file.
Yes, that needs fixing.. but not urgently so.
> Maybe a compiler will do optimizations within that source file even
> for functions that haven't been defined yet. Traditionally not.
>
> Whatever. Probably not a case where anybody cares about performance,
> but it does strike me that the "use abstractions" version probably not
> only generates worse code, it seems less legible too.
>
> Very odd pattern.
OK, I can just nuke those wrappers. But yeah, none of this setup code
is fast path.
> (b) The commit message (which is why I started looking at this) says
> that it used to return true even if there are no data devices.
>
> But dm_table_supports_poll() actually _still_ returns true for at
> least one case of no data devices: if the dm_table has no targets at
> all.
Right, I'm aware.. ugly but not a case that really matters (more below).
> So I don't know. Maybe that is a "can't happen". But since I looked at
> this, I thought I'd just point out the two oddities I found while
> doing so.
It can happen that someone loads a table without any targets but it
isn't a case that matters given IO cannot be sent anywhere. For that
to happen the DM table will have been reloaded to have targets (at
which point all will be setup properly, assuming no bugs like was
fixed here).
I do see you've since pulled the changes.
Thanks,
Mike
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-devel] [git pull] device mapper fixes for 5.19-rc1
@ 2022-06-01 23:10 ` Mike Snitzer
0 siblings, 0 replies; 8+ messages in thread
From: Mike Snitzer @ 2022-06-01 23:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-block, Sarthak Kukreti, device-mapper development,
Kees Cook, Alasdair G Kergon
On Wed, Jun 01 2022 at 5:43P -0400,
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, Jun 1, 2022 at 1:59 PM Mike Snitzer <snitzer@kernel.org> wrote:
> >
> > ----------------------------------------------------------------
> > - Fix DM core's dm_table_supports_poll to return false if no data
> > devices.
>
> So looking at that one (mainly because of the incomprehensible
> explanation), I do note:
>
> (a) the caller does
>
> for (i = 0; i < t->num_targets; i++) {
> ti = t->targets + i;
>
> while the callee does
>
> unsigned i = 0;
>
> while (i < dm_table_get_num_targets(t)) {
> ti = dm_table_get_target(t, i++);
>
> Now, those things are entirely equivalent, but that latter form is
> likely to generate horribly bad code because those helper functions
> aren't some kind of trivial inline, they are actually normal functions
> that are defined later in that same source file.
Yes, that needs fixing.. but not urgently so.
> Maybe a compiler will do optimizations within that source file even
> for functions that haven't been defined yet. Traditionally not.
>
> Whatever. Probably not a case where anybody cares about performance,
> but it does strike me that the "use abstractions" version probably not
> only generates worse code, it seems less legible too.
>
> Very odd pattern.
OK, I can just nuke those wrappers. But yeah, none of this setup code
is fast path.
> (b) The commit message (which is why I started looking at this) says
> that it used to return true even if there are no data devices.
>
> But dm_table_supports_poll() actually _still_ returns true for at
> least one case of no data devices: if the dm_table has no targets at
> all.
Right, I'm aware.. ugly but not a case that really matters (more below).
> So I don't know. Maybe that is a "can't happen". But since I looked at
> this, I thought I'd just point out the two oddities I found while
> doing so.
It can happen that someone loads a table without any targets but it
isn't a case that matters given IO cannot be sent anywhere. For that
to happen the DM table will have been reloaded to have targets (at
which point all will be setup properly, assuming no bugs like was
fixed here).
I do see you've since pulled the changes.
Thanks,
Mike
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-06-01 23:10 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-01 20:59 [git pull] device mapper fixes for 5.19-rc1 Mike Snitzer
2022-06-01 20:59 ` [dm-devel] " Mike Snitzer
2022-06-01 21:43 ` Linus Torvalds
2022-06-01 21:43 ` [dm-devel] " Linus Torvalds
2022-06-01 23:10 ` Mike Snitzer
2022-06-01 23:10 ` [dm-devel] " Mike Snitzer
2022-06-01 21:52 ` pr-tracker-bot
2022-06-01 21:52 ` [dm-devel] " pr-tracker-bot
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.