| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 24 Mar 2009 10:02:43 -0400 (EDT)
From: Mikulas Patocka <mpatocka@...hat.com>
To: device-mapper development <dm-devel@...hat.com>
cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andi Kleen <ak@...e.de>,
"MASON, CHRISTOPHER" <CHRIS.MASON@...cle.com>,
Jens Axboe <jens.axboe@...cle.com>
Subject: Re: [dm-devel] Barriers still not passing on simple dm devices...
On Mon, 23 Mar 2009, Eric Sandeen wrote:
> I've noticed that on 2.6.29-rcX, with Andi's patch
> (ab4c1424882be9cd70b89abf2b484add355712fa, dm: support barriers on
> simple devices) barriers are still getting rejected on these simple devices.
>
> The problem is in __generic_make_request():
>
> if (bio_barrier(bio) && bio_has_data(bio) &&
> (q->next_ordered == QUEUE_ORDERED_NONE)) {
> err = -EOPNOTSUPP;
> goto end_io;
> }
>
> and dm isn't flagging its queue as supporting ordered writes, so it's
> rejected here.
>
> Doing something like this:
>
> + if (t->barriers_supported)
> + blk_queue_ordered(q, QUEUE_ORDERED_DRAIN, NULL);
>
> somewhere in dm (I stuck it in dm_table_set_restrictions() - almost
> certainly the wrong thing to do) did get my dm-linear device to mount
> with xfs, w/o xfs complaining that its mount-time barrier tests failed.
>
> So what's the right way around this? What should dm (or md for that
> matter) advertise on their queues about ordered-ness? Should there be
> some sort of "QUEUE_ORDERED_PASSTHROUGH" or something to say "this level
> doesn't care, ask the next level" or somesuch? Or should it inherit the
> flag from the next level down? Ideas?
>
> Thanks,
> -Eric
>
> --
> dm-devel mailing list
> dm-devel@...hat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
Hi
This is misdesign in generic bio layer and it should be fixed there. I
think it is blocking barrier support in md-raid1 too. Jens, pls apply the
attached patch.
Mikulas
----
Move test for not-supported barriers to __make_request.
This test prevents barriers from being dispatched to device mapper
and md.
This test is sensible only for drivers that use requests (such as disk
drivers), not for drivers that use bios.
It is better to fix it in generic code than to make workaround for it
in device mapper and md.
Signed-off-by: Mikulas Patocka <mpatocka@...hat.com>
---
block/blk-core.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
Index: linux-2.6.29-rc6-devel/block/blk-core.c
===================================================================
--- linux-2.6.29-rc6-devel.orig/block/blk-core.c 2009-02-23 18:43:37.000000000 +0100
+++ linux-2.6.29-rc6-devel/block/blk-core.c 2009-02-23 18:44:27.000000000 +0100
@@ -1145,6 +1145,12 @@ static int __make_request(struct request
const int unplug = bio_unplug(bio);
int rw_flags;
+ if (bio_barrier(bio) && bio_has_data(bio) &&
+ (q->next_ordered == QUEUE_ORDERED_NONE)) {
+ bio_endio(bio, -EOPNOTSUPP);
+ return 0;
+ }
+
nr_sectors = bio_sectors(bio);
/*
@@ -1450,11 +1456,6 @@ static inline void __generic_make_reques
err = -EOPNOTSUPP;
goto end_io;
}
- if (bio_barrier(bio) && bio_has_data(bio) &&
- (q->next_ordered == QUEUE_ORDERED_NONE)) {
- err = -EOPNOTSUPP;
- goto end_io;
- }
ret = q->make_request_fn(q, bio);
} while (ret);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists