linux-kernel - Re: [dm-devel] [RFC PATCH 00/32] separate operations from flags in the bio/request structs

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <563A36FC.6010001@sandisk.com>
Date:	Wed, 4 Nov 2015 08:49:00 -0800
From:	Bart Van Assche <bart.vanassche@...disk.com>
To:	device-mapper development <dm-devel@...hat.com>,
	<linux-fsdevel@...r.kernel.org>, <linux-raid@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-scsi@...r.kernel.org>,
	<drbd-dev@...ts.linbit.com>
Subject: Re: [dm-devel] [RFC PATCH 00/32] separate operations from flags in
 the bio/request structs

On 11/04/2015 08:32 AM, mchristi@...hat.com wrote:
> There are a couple new block layer commands we are trying to add support
> for in the near term:
>
> compare and write
> http://www.spinics.net/lists/target-devel/msg07826.html
>
> copy offload/extended copy/xcopy
> https://www.redhat.com/archives/dm-devel/2014-July/msg00070.html
>
> The problem is if we contine to add more commands we will have to one day
> extend the cmd_flags/bi_rw fields again. To prevent that, this patchset
> separates the operation (REQ_WRITE, REQ_DISCARD, REQ_WRITE_SAME, etc) from
> the flags (REQ_SYNC, REQ_QUIET, etc) in the bio and request structs. In the
> end of this set, we will have two fields bio->bi_op/request->op and
> bio->bi_rw/request->cmd_flags.
>
> The patches were made against Jens's linux-block tree's for-linus branch:
> https://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git/log/?h=for-linus
> (last commit a22c4d7e34402ccdf3414f64c50365436eba7b93).
>
> I have done some basic testing for a lot of the drivers and filesystems,
> but I wanted to get comments before trying to track down more hardware/
> systems for testing.
>
>
> Known issues:
> - REQ_FLUSH is still a flag, but should probably be a operation.
>   For lower level drivers like SCSI where we only get a flush, it makes
> more sense to be a operation. However, upper layers like filesystems
> can send down flushes with writes, so it is more of a flag for them.
> I am still working on this.
>
> - There is a regression with the dm flakey target. It currently
> cannot corrupt the operation values.
>
> - The patchset is a little awkward. It touches so much code,
> but I wanted to maintain git bisectibility, so there is lots of compat code
> left around until the last patches where everyting is cleaned up.

Hello Mike,

If you have to touch submit_bio() and submit_bio_wait(), how about 
requiring the callers of these functions to set the cmd and flags 
arguments in the bio structure and to leave out the cmd and flags 
arguments from the submit_bio() and submit_bio_wait() functions ? A 
(compile tested only) patch that implements this idea is available at 
https://lkml.org/lkml/2014/6/2/173.

Bart.
--
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/