Ondrej Mosnacek wrote:
> Hi Herbert, Mikulas,
>
> I noticed the discussion about using kmalloc() inside crypto code and it
> made me wonder if the code in xts.c can actually be simplified to not
> require kmalloc() at all, while not badly affecting performace. I played
> around with it a little
On Tue, Aug 07, 2018 at 02:18:39PM -0700, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this uses
> the new HASH_MAX_DIGESTSIZE from the crypto layer to allocate the upper
> bounds on stack usage.
>
> [1]
>
On Tue, Aug 07, 2018 at 02:18:43PM -0700, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> caps the skcipher request size similar to other limits and adds a sanity
> check at registration. Looking at instrumented tcrypt output, the largest
> is for lrw:
>
>
On Tue, Aug 07, 2018 at 02:18:34PM -0700, Kees Cook wrote:
> v8 cover letter:
>
> I continue to hope this can land in v4.19, but I realize that's unlikely.
> It would be nice, though, if some of the "trivial" patches could get taken
> (e.g. cbc, xcbc, ccm VLA removals) so I don't have to keep
decipher_sync_action() is only called from raid_status() thus
duplicating tests to define the current synchronization action
(frozen, check, resync, ...) in rs_get_progress().
Change it to return an enum defining the sync states and
share it to avoid code duplication. Introduce sync_str()
to
When a journal device for raid4/5/6 is used,
don't create a mutually exclusive write intent bitmap.
Signed-off-by: Heinz Mauelshagen
---
drivers/md/dm-raid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c
index
This race does not occur with usual raid device sizes but
with small ones (e.g. those created by the lvm2 test suite).
Race scenario:
Loading a new mapping table, the dm-raid target's constructor
retrieves the volatile reshaping state from the raid superblocks.
When the new table is activated
This series of raid patches critically fixes:
- a race causing hangs occuring on tiny devices
- a reshape deadlock / potential data corruption
- a superblock update problem rebuilding individual component devices
In addition, it contains (patches 4+5, less critical) removal
of code duplication
When initiating a stripe adding reshape, a deadlock between
md_stop_writes() waiting for the sync thread to stop and the
running sync thread waiting for inactive stripes occurs
(this frequently happens on single-core but rarely
on multi-core systems).
Resolve by setting MD_RECOVERY_WAIT to
Mikulas,
we're checking for !conf already, so this is different.
You must have hit a window during destruction of a mapping
when raid_dtr is processing md_stop() racing with raid_status()
causing the raid personality configuration referenced
by mddev->private to become stale.
A dm-raid runtime
Hi Eric,
On Wed, Sep 5, 2018 at 8:32 AM Eric Biggers wrote:
> Hi Ondrej,
>
> On Tue, Sep 04, 2018 at 10:06:42AM +0200, Ondrej Mosnacek wrote:
> > Since commit acb9b159c784 ("crypto: gf128mul - define gf128mul_x_* in
> > gf128mul.h"), the gf128mul_x_*() functions are very fast and therefore
> >
Hi Zdenek,
Zdenek Kabelac writes:
> Dne 31.8.2018 v 16:48 Marcin Niestroj napsal(a):
>> Only few libc (e.g. glibc) libraries support full symbol version
>> resolution in runtime. There are lot of standard libraries that do not
>> support that, such as dietlibc, musl and uclibc. Hence there is
There's a deadlock reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=200835
* dm-crypt calls crypt_convert in xts mode
* init_crypt from xts.c calls kmalloc(GFP_KERNEL)
* kmalloc(GFP_KERNEL) recurses into the XFS filesystem, the filesystem
tries to submit some bios and wait for
13 matches
Mail list logo
