Jens,
can you pick this series up?
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
We check udev_device_get_syspath return value before
dereference it.
Signed-off-by: Lixiaokeng
Signed-off-by: Zhiqiang Liu
Signed-off-by: Linfeilong
---
libmultipath/foreign/nvme.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libmultipath/foreign/nvme.c b/libmultipat
We check return value of udev_device_get_devtype before
dereference it.
Signed-off-by:Lixiaokeng
Signed-off-by: Zhiqiang Liu
Signed-off-by: Linfeilong
---
libmultipath/foreign/nvme.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libmultipath/foreign/nvme.c b/libmultipa
We check the return value of udev_device_get_devtype before
dereference it.
Signed-off-by:Lixiaokeng
Signed-off-by: Zhiqiang Liu
Signed-off-by: Linfeilong
---
libmultipath/configure.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libmultipath/configure.c b/libmultipath
Hi,
The udev* function may return NULL,and it will be
dereferenced in str* and sscanf func. For example,
there is a coredump caused in add func, which show in
be7a043(commit id) in upstream-queue. We check the
return value to avoid dereference NULL.
repo: openSUSE/multipath-tools
repo link: http
udev_device_get_sysname may return NULL. We check the return value.
Signed-off-by:Lixiaokeng
Signed-off-by: Zhiqiang Liu
Signed-off-by: Linfeilong
---
libmultipath/discovery.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libmultipath/discovery.c b/libmultipath/discovery.c
index 3f1b1d
We check the return value of udev_device_get_sysname.
Signed-off-by:Lixiaokeng
Signed-off-by: Zhiqiang Liu
Signed-off-by: Linfeilong
---
libmultipath/discovery.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libmultipath/discovery.c b/libmultipath/discovery.c
index 4264b0da..27cb67f8 10
We check the return value of udev_device_get_parent and
udev_device_get_sysname.
Signed-off-by:lixiaokeng
Signed-off-by: Zhiqiang Liu
Signed-off-by: Linfeilong
---
libmultipath/discovery.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libmultipath/discovery.c b/libmult
On 2020/09/15 10:10, Damien Le Moal wrote:
> On 2020/09/15 0:04, Mike Snitzer wrote:
>> On Sun, Sep 13 2020 at 8:46pm -0400,
>> Damien Le Moal wrote:
>>
>>> On 2020/09/12 6:53, Mike Snitzer wrote:
blk_queue_get_max_sectors() has been trained for REQ_OP_WRITE_SAME and
REQ_OP_WRITE_ZEROES
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
dm-5.10
head: 86958eac97c2edd72a4a36ac2c7c257aee639711
commit: 7a888ac0a16dbdff2889066f35580575c56ebf0c [3/6] dm table: stack
'chunk_sectors' limit to account for target-specific splitting
config: microblaze-ran
On 2020/09/15 11:04, Ming Lei wrote:
> On Mon, Sep 14, 2020 at 12:43:06AM +, Damien Le Moal wrote:
>> On 2020/09/12 22:53, Ming Lei wrote:
>>> On Fri, Sep 11, 2020 at 05:53:36PM -0400, Mike Snitzer wrote:
blk_queue_get_max_sectors() has been trained for REQ_OP_WRITE_SAME and
REQ_OP_WR
On Mon, Sep 14, 2020 at 12:43:06AM +, Damien Le Moal wrote:
> On 2020/09/12 22:53, Ming Lei wrote:
> > On Fri, Sep 11, 2020 at 05:53:36PM -0400, Mike Snitzer wrote:
> >> blk_queue_get_max_sectors() has been trained for REQ_OP_WRITE_SAME and
> >> REQ_OP_WRITE_ZEROES yet blk_rq_get_max_sectors()
On Mon, Sep 14, 2020 at 10:49:28AM -0400, Mike Snitzer wrote:
> On Sat, Sep 12 2020 at 9:52am -0400,
> Ming Lei wrote:
>
> > On Fri, Sep 11, 2020 at 05:53:36PM -0400, Mike Snitzer wrote:
> > > blk_queue_get_max_sectors() has been trained for REQ_OP_WRITE_SAME and
> > > REQ_OP_WRITE_ZEROES yet bl
On Thu, Sep 10 2020 at 3:29pm -0400,
Vijayendra Suman wrote:
> Hello Mike,
>
> I checked with upstream, performance measurement is similar and
> shows performance improvement when
> 120c9257f5f19e5d1e87efcbb5531b7cd81b7d74 is reverted.
>
> On 9/10/2020 7:54 PM, Mike Snitzer wrote:
> >[cc'ing d
On 2020/09/15 0:04, Mike Snitzer wrote:
> On Sun, Sep 13 2020 at 8:46pm -0400,
> Damien Le Moal wrote:
>
>> On 2020/09/12 6:53, Mike Snitzer wrote:
>>> blk_queue_get_max_sectors() has been trained for REQ_OP_WRITE_SAME and
>>> REQ_OP_WRITE_ZEROES yet blk_rq_get_max_sectors() didn't call it for
>
On 2020/09/14 23:52, Mike Snitzer wrote:
> On Sun, Sep 13 2020 at 8:43pm -0400,
> Damien Le Moal wrote:
>
>> On 2020/09/12 22:53, Ming Lei wrote:
>>> On Fri, Sep 11, 2020 at 05:53:36PM -0400, Mike Snitzer wrote:
blk_queue_get_max_sectors() has been trained for REQ_OP_WRITE_SAME and
REQ
Hi Liu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on next-20200911]
url:
https://github.com/0day-ci/linux/commits/Liu-Shixin/dm-integrity-convert-to-use-le64_add_cpu/20200914-115650
base:d5b2251d63b5344ee827d3680fa79bdb9f9ddfa1
config: x86_64
On Sun, Sep 13 2020 at 8:46pm -0400,
Damien Le Moal wrote:
> On 2020/09/12 6:53, Mike Snitzer wrote:
> > blk_queue_get_max_sectors() has been trained for REQ_OP_WRITE_SAME and
> > REQ_OP_WRITE_ZEROES yet blk_rq_get_max_sectors() didn't call it for
> > those operations.
> >
> > Also, there is no
On Sun, Sep 13 2020 at 8:43pm -0400,
Damien Le Moal wrote:
> On 2020/09/12 22:53, Ming Lei wrote:
> > On Fri, Sep 11, 2020 at 05:53:36PM -0400, Mike Snitzer wrote:
> >> blk_queue_get_max_sectors() has been trained for REQ_OP_WRITE_SAME and
> >> REQ_OP_WRITE_ZEROES yet blk_rq_get_max_sectors() di
On Sat, Sep 12 2020 at 9:52am -0400,
Ming Lei wrote:
> On Fri, Sep 11, 2020 at 05:53:36PM -0400, Mike Snitzer wrote:
> > blk_queue_get_max_sectors() has been trained for REQ_OP_WRITE_SAME and
> > REQ_OP_WRITE_ZEROES yet blk_rq_get_max_sectors() didn't call it for
> > those operations.
>
> Actua
Joe,
Please drop this chunk: it's a successive controller version number
which are all backward compatible with "fallthrough" on each case so
removing from this last one makes it inconsistent.
In sort: NACK for atmel-mci.
Best regards,
Nicolas
On 09/09/2020 at 22:06, Joe Perches wrote:
>
On Sat, Sep 12, 2020 at 10:06:30PM +0800, Ming Lei wrote:
> On Fri, Sep 11, 2020 at 05:53:38PM -0400, Mike Snitzer wrote:
> > It is possible for a block device to use a non power-of-2 for chunk
> > size which results in a full-stripe size that is also a non
> > power-of-2.
> >
> > Update blk_queue
On 2020-08-31 10:02 a.m., Mimi Zohar wrote:
On Thu, 2020-08-27 at 18:57 -0700, Tushar Sugandhi wrote:
process_buffer_measurement() currently only measures the input buffer.
When the buffer being measured is too large, it may result in bloated
IMA logs.
The subject of this sentence refers to
On 2020-08-31 11:23 a.m., Mimi Zohar wrote:
diff --git a/security/integrity/ima/ima_main.c
b/security/integrity/ima/ima_main.c
index 52cbbc1f7ea2..a889bf40cb7e 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -869,6 +869,30 @@ void ima_kexec_cmdline(int
On 2020-08-31 11:15 a.m., Mimi Zohar wrote:
On Thu, 2020-08-27 at 18:57 -0700, Tushar Sugandhi wrote:
There would be several candidate kernel components suitable for IMA
measurement. Not all of them would have support for IMA measurement.
Also, system administrators may not want to measure dat
> -Original Message-
> From: Ard Biesheuvel
> Sent: Friday, September 11, 2020 6:30 PM
> To: Van Leeuwen, Pascal ; dm-devel@redhat.com; Milan
> Broz
> Cc: linux-cry...@vger.kernel.org; herb...@gondor.apana.org.au;
> ebigg...@kernel.org
> Subject: Re: [PATCH] crypto: mark unused ciphers
On 2020-09-09 21:06, Joe Perches wrote:
fallthrough to a separate case/default label break; isn't very readable.
Convert pseudo-keyword fallthrough; statements to a simple break; when
the next label is case or default and the only statement in the next
label block is break;
Found using:
$ grep
Thanks for taking a look at this patch Milan.
Appreciate it.
Sorry for responding late. I was on vacation last week.
My responses below.
On 2020-08-31 3:54 a.m., Milan Broz wrote:
On 28/08/2020 22:27, Tushar Sugandhi wrote:
Currently, dm-crypt does not take advantage of IMA measuring
capabili
On Thu, Sep 10, 2020 at 7:48 AM Christoph Hellwig wrote:
>
> The raid5 and raid10 drivers currently update the read-ahead size,
> but not the optimal I/O size on reshape. To prepare for deriving the
> read-ahead size from the optimal I/O size make sure it is updated
> as well.
>
> Signed-off-by:
Convert cpu_to_le64(le64_to_cpu(E1) + E2) to use le64_add_cpu().
Signed-off-by: Liu Shixin
---
drivers/md/dm-integrity.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integrity.c
index 3fc3757def55..cf9dadd55625 100644
--- a/drivers
(cc Milan and dm-devel)
On Fri, 11 Sep 2020 at 19:24, Van Leeuwen, Pascal
wrote:
>
> > -Original Message-
> > From: linux-crypto-ow...@vger.kernel.org
> > On Behalf Of Ard Biesheuvel
> > Sent: Friday, September 11, 2020 4:11 PM
> > To: linux-cry...@vger.kernel.org
> > Cc: herb...@gondor
On 09/09/2020 22:06, Joe Perches wrote:
diff --git a/drivers/net/wireless/mediatek/mt7601u/dma.c
b/drivers/net/wireless/mediatek/mt7601u/dma.c
index 09f931d4598c..778be26d329f 100644
--- a/drivers/net/wireless/mediatek/mt7601u/dma.c
+++ b/drivers/net/wireless/mediatek/mt7601u/dma.c
@@ -193,11
On 2020-08-31 4:55 a.m., Mimi Zohar wrote:
On Thu, 2020-08-27 at 18:56 -0700, Tushar Sugandhi wrote:
IMA functions such as ima_match_keyring(), process_buffer_measurement(),
ima_match_policy() etc. handle data specific to keyrings. Currently,
these constructs are not generic to handle any func
Hello Mike,
I checked with upstream, performance measurement is similar and shows
performance improvement when 120c9257f5f19e5d1e87efcbb5531b7cd81b7d74 is
reverted.
On 9/10/2020 7:54 PM, Mike Snitzer wrote:
[cc'ing dm-devel and linux-block because this is upstream concern too]
On Wed, Sep 0
On 9/9/20 10:06 PM, Joe Perches wrote:
fallthrough to a separate case/default label break; isn't very readable.
Convert pseudo-keyword fallthrough; statements to a simple break; when
the next label is case or default and the only statement in the next
label block is break;
Found using:
$ grep-
On 2020-08-31 4:36 a.m., Mimi Zohar wrote:
On Thu, 2020-08-27 at 18:57 -0700, Tushar Sugandhi wrote:
process_buffer_measurement() does not return the result of the operation.
Therefore, the consumers of this function cannot act on it, if needed.
Update return type of process_buffer_measureme
Hi,
Joe Perches writes:
> drivers/usb/dwc3/core.c | 2 +-
> drivers/usb/gadget/legacy/inode.c | 2 +-
> drivers/usb/gadget/udc/pxa25x_udc.c | 4 ++--
> drivers/usb/phy/phy-fsl-usb.c |
37 matches
Mail list logo
