Hello,
==
WARNING: possible circular locking dependency detected
4.13.0-rc6-next-20170822-dbg-00020-g39758ed8aae0-dirty #1746 Not tainted
--
fsck.ext4/148 is trying to acquire lock:
(&
On Sat, Aug 19, 2017 at 01:52:26PM +0530, Bhumika Goyal wrote:
> Make this const as it is only stored in the type field of a device
> structure, which is const.
> Done using Coccinelle.
>
> Signed-off-by: Bhumika Goyal
Acked-by: Heikki Krogerus
> ---
> drivers/usb/common/ulpi.c | 2 +-
> 1 fi
> Wouldn't it make sense to backport the changes to set the virt_boundary
> (which probably still is the SG_GAPS flag in such an old kernel)?
We can make storvsc use SG_GAPS. But the following patch is missing in 4.1
stable block layer to make this work on some I/O situations. Backporting is
m
Remove variable assignments. The value stored in local variable _rc_ is
overwritten at line 2448:rc = lpfc_sli4_bsg_set_link_diag_state(phba, 0);
before it can be used.
Addresses-Coverity-ID: 1226935
Signed-off-by: Gustavo A. R. Silva
---
This issue was detected by Coverity and it was tested by c
On 2017-08-16 12:48 AM, Todd Poynor wrote:
Commit 1bc0eb044615 ("scsi: sg: protect accesses to 'reserved' page
array") adds needed concurrency protection for the "reserve" buffer.
Some checks that are initially made outside the lock are replicated once
the lock is taken to ensure the checks and r
On Tue, 2017-08-22 at 19:47 +0900, Sergey Senozhatsky wrote:
> ==
> WARNING: possible circular locking dependency detected
> 4.13.0-rc6-next-20170822-dbg-00020-g39758ed8aae0-dirty #1746 No
On Tue, Aug 22, 2017 at 09:43:56PM +, Bart Van Assche wrote:
> On Tue, 2017-08-22 at 19:47 +0900, Sergey Senozhatsky wrote:
> > ==
> > WARNING: possible circular locking dependency detected
> > 4.13.0-rc6-next-20170822-db
Todd,
> Commit 1bc0eb044615 ("scsi: sg: protect accesses to 'reserved' page
> array") adds needed concurrency protection for the "reserve" buffer.
> Some checks that are initially made outside the lock are replicated once
> the lock is taken to ensure the checks and resulting decisions are made
>
On 2017-08-16 01:41 AM, Todd Poynor wrote:
Take f_mutex around mmap() processing to protect against races with
the SG_SET_RESERVED_SIZE ioctl. Ensure the reserve buffer length
remains consistent during the mapping operation, and set the
"mmap called" flag to prevent further changes to the reserv
On 2017-08-17 03:09 AM, Dan Carpenter wrote:
If "val" is SG_MAX_QUEUE then we are one element beyond the end of the
"rinfo" array so the > should be >=.
Fixes: 109bade9c625 ("scsi: sg: use standard lists for sg_requests")
Signed-off-by: Dan Carpenter
Acked-by: Douglas Gilbert
Thanks.
diff
Suganath,
> mpt3sas: SGL to PRP Translation for I/Os to NVMe devices
I'm still confused about this patch.
- I don't understand why you go through all these hoops to decide
whether to use PRPs or IEEE scatterlists. If the firmware translation
is slow, why even bother with the SG format
Todd,
> Take f_mutex around mmap() processing to protect against races with
> the SG_SET_RESERVED_SIZE ioctl. Ensure the reserve buffer length
> remains consistent during the mapping operation, and set the
> "mmap called" flag to prevent further changes to the reserved buffer
> size as an atomic
Dan,
> If "val" is SG_MAX_QUEUE then we are one element beyond the end of the
> "rinfo" array so the > should be >=.
Applied to 4.13/scsi-fixes. Thanks!
--
Martin K. Petersen Oracle Linux Engineering
On (08/23/17 09:03), Byungchul Park wrote:
[..]
aha, ok
> The report is talking about the following lockup:
>
> A work in a worker A task work on exit to user
> -- ---
> mutex_lock(&bdev->bd_mutex)
>
On Wed, Aug 23, 2017 at 11:36:49AM +0900, Sergey Senozhatsky wrote:
> On (08/23/17 09:03), Byungchul Park wrote:
> [..]
>
> aha, ok
>
> > The report is talking about the following lockup:
> >
> > A work in a worker A task work on exit to user
> > --
> > WARNING: possible circular locking dependency detected
> > > 4.13.0-rc6-next-20170822-dbg-00020-g39758ed8aae0-dirty #1746 Not tainted
> > > --
> > > fsck.ext4/148 is trying to acquire lock:
> >
Sergey Senozhatsky wrote:
> > > > ==
> > > > WARNING: possible circular locking dependency detected
> > > > 4.13.0-rc6-next-20170822-dbg-00020-g39758ed8aae0-dirty #1746 Not tainted
> > > > --
Sergey Senozhatsky wrote:
> > > > ==
> > > > WARNING: possible circular locking dependency detected
> > > > 4.13.0-rc6-next-20170822-dbg-00020-g39758ed8aae0-dirty #1746 Not tainted
> > > > --
On (08/23/17 12:38), Boqun Feng wrote:
[..]
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 642fb5362507..a3709e15f609 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -1156,6 +1156,23 @@ print_circular_lock_scenario(struct held_lock *src,
>
t Van Assche wrote:
> > > > On Tue, 2017-08-22 at 19:47 +0900, Sergey Senozhatsky wrote:
> > > > > ==
> > > > > WARNING: possible circular locking dependency detected
> > > > &
On Wed, Aug 23, 2017 at 01:46:48PM +0900, Sergey Senozhatsky wrote:
> On (08/23/17 12:38), Boqun Feng wrote:
> [..]
> > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> > index 642fb5362507..a3709e15f609 100644
> > --- a/kernel/locking/lockdep.c
> > +++ b/kernel/locking/lockdep.c
On (08/23/17 13:35), Boqun Feng wrote:
[..]
> > > printk(KERN_CONT ");\n");
> >
> > KERN_CONT and "\n" should not be together. "\n" flushes the cont
> > buffer immediately.
> >
>
> Hmm.. Not quite familiar with printk() stuffs, but I could see several
> usages of printk(KERN_CONT "...\
On Wed, Aug 23, 2017 at 12:38:13PM +0800, Boqun Feng wrote:
> From: Boqun Feng
> Date: Wed, 23 Aug 2017 12:12:16 +0800
> Subject: [PATCH] lockdep: Print proper scenario if cross deadlock detected at
> acquisition time
>
> For a potential deadlock about CROSSRELEASE as follow:
>
> P1
On (08/23/17 13:35), Boqun Feng wrote:
> > KERN_CONT and "\n" should not be together. "\n" flushes the cont
> > buffer immediately.
> >
>
> Hmm.. Not quite familiar with printk() stuffs, but I could see several
> usages of printk(KERN_CONT "...\n") in kernel.
>
> Did a bit research myself, and I
Six minor and error leg fixes, plus one major change: the reversion of
scsi-mq as the default. We're doing the latter temporarily (with a
backport to stable) to give us time to fix all the issues that turned
up with this default before trying again.
The patch is available here:
git://git.kernel.
Ok. If the stable maintainers are ok with your small fix
I'm not going to complain too loudly. But I'm always worried about
stable trees divering too much from mainline.
26 matches
Mail list logo
