Re: [dm-devel] [PATCH] dm-region-hash: fix strange usage of mempool_alloc.

2017-05-03 Thread NeilBrown
On Wed, May 03 2017, Mikulas Patocka wrote: > On Mon, 24 Apr 2017, NeilBrown wrote: >> >> I had a look at how the allocation 'dm_region' objects are used, >> and it would take a bit of work to make it really safe. >> My guess is __rh_find() should be allowed to fail, and the various >> callers

Re: [dm-devel] [git pull] device mapper changes for 4.12

2017-05-03 Thread Mike Snitzer
On Wed, May 03 2017 at 1:51pm -0400, Linus Torvalds wrote: > On Tue, May 2, 2017 at 11:58 AM, Mike Snitzer wrote: > > > > - Add a new DM integrity target that emulates a block device that has > > additional per-sector tags that can be used

Re: [dm-devel] [PATCH] dm-region-hash: fix strange usage of mempool_alloc.

2017-05-03 Thread Mikulas Patocka
On Mon, 24 Apr 2017, NeilBrown wrote: > On Fri, Apr 21 2017, Mikulas Patocka wrote: > > > On Mon, 10 Apr 2017, NeilBrown wrote: > > > >> mempool_alloc() should only be called with GFP_ATOMIC when > >> it is not safe to wait. Passing __GFP_NOFAIL to kmalloc() > >> says that it is safe to wait

Re: [dm-devel] [git pull] device mapper changes for 4.12

2017-05-03 Thread Linus Torvalds
On Tue, May 2, 2017 at 11:58 AM, Mike Snitzer wrote: > > - Add a new DM integrity target that emulates a block device that has > additional per-sector tags that can be used for storing integrity > information. So this one comes with a nice documentation file and

Re: [dm-devel] [PATCH 25/27] block: remove the discard_zeroes_data flag

2017-05-03 Thread Mike Snitzer
On Tue, May 02 2017 at 11:33pm -0400, Nicholas A. Bellinger wrote: > On Tue, 2017-05-02 at 09:23 +0200, h...@lst.de wrote: > > On Tue, May 02, 2017 at 12:16:13AM -0700, Nicholas A. Bellinger wrote: > > > Or, another options is use bdev_write_zeroes_sectors() to determine

Re: [dm-devel] [mdadm PATCH] Create: tell udev md device is not ready when first created.

2017-05-03 Thread Peter Rajnoha
On 05/02/2017 03:42 PM, Jes Sorensen wrote: > On 04/28/2017 01:05 AM, NeilBrown wrote: >> >> When an array is created the content is not initialized, >> so it could have remnants of an old filesystem or md array >> etc on it. >> udev will see this and might try to activate it, which is almost >>

Re: [dm-devel] [mdadm PATCH 4/4] Create: tell udev device is not ready when first created.

2017-05-03 Thread Peter Rajnoha
On 05/02/2017 03:40 PM, Jes Sorensen wrote: > On 05/02/2017 07:40 AM, Peter Rajnoha wrote: >> On 05/01/2017 06:35 AM, NeilBrown wrote: >>> On Fri, Apr 28 2017, Peter Rajnoha wrote: Then mdadm opens the devive, clears any old content/signatures the data area may contain, then closes it -

Re: [dm-devel] [mdadm PATCH] Create: tell udev md device is not ready when first created.

2017-05-03 Thread Peter Rajnoha
On 05/02/2017 03:32 PM, Jes Sorensen wrote: > On 04/28/2017 05:28 AM, Peter Rajnoha wrote: >> On 04/28/2017 07:05 AM, NeilBrown wrote: >>> >>> When an array is created the content is not initialized, >>> so it could have remnants of an old filesystem or md array >>> etc on it. >>> udev will see

Re: [dm-devel] [mdadm PATCH] Create: tell udev md device is not ready when first created.

2017-05-03 Thread Jes Sorensen
On 04/28/2017 01:05 AM, NeilBrown wrote: When an array is created the content is not initialized, so it could have remnants of an old filesystem or md array etc on it. udev will see this and might try to activate it, which is almost certainly not what is wanted. So create a mechanism for mdadm

Re: [dm-devel] [PATCH 25/27] block: remove the discard_zeroes_data flag

2017-05-03 Thread Nicholas A. Bellinger
On Tue, 2017-05-02 at 09:23 +0200, h...@lst.de wrote: > On Tue, May 02, 2017 at 12:16:13AM -0700, Nicholas A. Bellinger wrote: > > Or, another options is use bdev_write_zeroes_sectors() to determine when > > dev_attrib->unmap_zeroes_data should be set. > > Yes, that in combination with your patch

Re: [dm-devel] [mdadm PATCH 4/4] Create: tell udev device is not ready when first created.

2017-05-03 Thread Jes Sorensen
On 05/02/2017 07:40 AM, Peter Rajnoha wrote: On 05/01/2017 06:35 AM, NeilBrown wrote: On Fri, Apr 28 2017, Peter Rajnoha wrote: Then mdadm opens the devive, clears any old content/signatures the data area may contain, then closes it - this generates the third event - which is the "synthetic

Re: [dm-devel] [mdadm PATCH] Create: tell udev md device is not ready when first created.

2017-05-03 Thread Jes Sorensen
On 04/28/2017 05:28 AM, Peter Rajnoha wrote: On 04/28/2017 07:05 AM, NeilBrown wrote: When an array is created the content is not initialized, so it could have remnants of an old filesystem or md array etc on it. udev will see this and might try to activate it, which is almost certainly not