Re: [PATCH] loop: remember whether sysfs_create_group() succeeded

On 05/05/2018 01:49 PM, Tetsuo Handa wrote: > Milan Broz wrote: >>> Do we want to abort LOOP_SET_FD request if sysfs_create_group() failed? >> >> I would prefer failure - there are several utilities that expects attributes >> in >> sysfs to be valid

Re: [PATCH] loop: remember whether sysfs_create_group() succeeded

On 05/04/2018 04:40 PM, Tetsuo Handa wrote: > The loop module ignores sysfs_create_group() failure and pretends that > LOOP_SET_FD request succeeded. I guess that the author of commit > ee86273062cbb310 ("loop: add some basic read-only sysfs attributes") > assumed that it is not a fatal error

Re: [PATCH v2 0/3] loop: LO_FLAGS_BLOCKSIZE fixes

On 08/18/2017 09:27 PM, Omar Sandoval wrote: > From: Omar Sandoval > > Patches 1 and 3 are from the original series. > > Patch 2 gets rid of the redundant struct loop_device.lo_logical_blocksize > in favor of using the queue's own logical_block_size. Karel, I decided > against

Re: [PATCH] loop: Fix freeze if configured block size is not supported

On 08/21/2017 08:47 PM, Omar Sandoval wrote: > On Fri, Aug 18, 2017 at 03:07:33PM +0200, Milan Broz wrote: >> The commit f2c6df7dbf9a60e1cd9941f9fb376d4d9ad1e8dd >> >> loop: support 4k physical blocksize >> >> adds support for loop block size with only specif

[PATCH] loop: Fix freeze if configured block size is not supported

-off-by: Milan Broz <gmazyl...@gmail.com> --- drivers/block/loop.c | 24 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index ef8334949b42..26548e07bc31 100644 --- a/drivers/block/loop.c +++ b/drivers/block/

Re: [PATCH] bio-integrity: revert "stop abusing bi_end_io"

Hi, On 08/07/2017 05:48 PM, Martin K. Petersen wrote: > >> If you create the integrity tag at or above device mapper level, you >> will run into problems because the same device can be accessed using >> device mapper and using physical volume /dev/sd*. If you create >> integrity tags at device

Re: [RFC PATCH] bio-integrity: Fix regression if profile verify_fn is NULL

On 08/02/2017 04:11 PM, Martin K. Petersen wrote: >> And the integrity profile is perfect interface for this, we register >> own profile through the proper interface. (Any other solution for >> per-sector metadata would be worse, I tried...) > > The DM use case seems a bit weird and I would

[RFC PATCH] bio-integrity: Fix regression if profile verify_fn is NULL

SS:ESP: 0068:f4b5dea4 : CR2: Patch just skip the whole verify workqueue if verify_fn is set to NULL. Signed-off-by: Milan Broz <gmazyl...@gmail.com> --- block/bio-integrity.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/block/bio-integrity.c

Re: [RFC PATCH 0/4] Allow file systems to selectively bypass dm-crypt

On 06/15/2017 07:24 PM, Michael Halcrow wrote: ... >> If this is accepted, we basically allow attacker to trick system to >> write plaintext to media just by setting this flag. This must never >> ever happen with FDE - BY DESIGN. > > That's an important point. This expands the attack surface to

Re: [RFC PATCH 0/4] Allow file systems to selectively bypass dm-crypt

On 06/15/2017 01:40 AM, Michael Halcrow wrote: > Several file systems either have already implemented encryption or are > in the process of doing so. This addresses usability and storage > isolation requirements on mobile devices and in multi-tenant > environments. > > While distinct keys locked

Re: dm-crypt: Fix error with too large bios

On 08/31/2016 12:27 AM, Mikulas Patocka wrote: ... > > Drop that "#ifdef CONFIG_BCACHE". Anyone should be allowed to create a big > bio, not just bcache. Yes. Please, do not hide it behind #ifdef. If it is in code, it should be enabled always. There can third party modules or some new code