Bart,
> Thanks Greg for the ack. I wasn't sure which maintainer to send this
> patch to since lib/klist.c is not mentioned in the MAINTAINERS
> file. Martin, are you OK with queuing this patch?
Sure, no problem.
--
Martin K. Petersen Oracle Linux Engineering
John,
> OK, but please be aware that there may be a more serious issue fixed
> here than the WARN, in that we could try to free memory embedded in a
> structure.
We can still get it into 4.18.x. I'm just wary of submitting stuff to
Linus that has had zero -next exposure.
--
Martin K.
David,
I could see the same issue on sparc64 system, soon we will repost the
patch addressing this.
Thanks,
Chaitra
-Original Message-
From: David Miller [mailto:da...@davemloft.net]
Sent: Thursday, June 28, 2018 5:45 AM
To: chaitra.basa...@broadcom.com
Cc:
On 06/28/18 08:37, Greg Kroah-Hartman wrote:
On Fri, Jun 22, 2018 at 02:54:49PM -0700, Bart Van Assche wrote:
In the scsi_transport_srp implementation it cannot be avoided to
iterate over a klist from atomic context when using the legacy
block layer instead of blk-mq. Hence this patch that
On Fri, Jun 22, 2018 at 02:54:49PM -0700, Bart Van Assche wrote:
> In the scsi_transport_srp implementation it cannot be avoided to
> iterate over a klist from atomic context when using the legacy
> block layer instead of blk-mq. Hence this patch that makes it safe
> to use klists in atomic
Since nr_bytes == blk_rq_bytes(rq) == rq->__data_len, the
rq->__data_len = nr_bytes assignment does not modify the value of
rq->__data_len. Hence remove that assignment. Note: the code in
sd_done() that sets the residual to zero for zone report requests
is not affected by this patch.
> -Original Message-
> From: Dan Carpenter
> Sent: Thursday, June 28, 2018 2:53 PM
> To: Dept-Eng QLogic Storage Upstream upstr...@cavium.com>; Rangankar, Manish
>
> Cc: James E.J. Bottomley ; Martin K. Petersen
> ; linux-scsi@vger.kernel.org; kernel-
> janit...@vger.kernel.org
>
Le Wed, 27 Jun 2018 18:48:56 +
Dave Carroll écrivait:
> Sorry, that comment was incorrect, but I would like to see if the
> size is consistent between the kernels.
>
Yes it is. The only difference is the driver version going from 50834
to 50877. The problem occurs on different setups,
The id_tbl->table pointer points to unsigned long so static checkers
complain that instead of 4 we should be allocating sizeof(long) bytes.
We're trying to allocate enough bits for the bitmap. The size variable
is always 1024. (1024 / 32 * 4) is the same as (1024 / 64 * 8) so this
doesn't
9 matches
Mail list logo
