On Mon, 2019-01-14 at 13:52 +0100, Peter Zijlstra wrote:
> On Fri, Jan 11, 2019 at 09:01:41AM -0800, Bart Van Assche wrote:
> > The list_del_rcu() call must only happen once.
>
> Yes; obviously. But if we need to check all @pf's, that means the entry
> is still r
On 1/18/19 1:48 AM, Peter Zijlstra wrote:
On Mon, Jan 14, 2019 at 08:52:33AM -0800, Bart Van Assche wrote:
On Mon, 2019-01-14 at 13:52 +0100, Peter Zijlstra wrote:
On Fri, Jan 11, 2019 at 09:01:41AM -0800, Bart Van Assche wrote:
The list_del_rcu() call must only happen once.
Yes; obviously
On 2/1/19 4:15 AM, Peter Zijlstra wrote:
On Fri, Jan 18, 2019 at 06:34:20PM -0800, Bart Van Assche wrote:
I agree with what you wrote. The only code I know of that accesses list
entries using RCU is the __bfs() function. In that function I found the
following loop
On Thu, 2019-01-24 at 09:22 -0700, Jens Axboe wrote:
> On 1/24/19 8:09 AM, Jeff Moyer wrote:
> > Jianchao Wang writes:
> >
> > > Swap REQ_NOWAIT and REQ_NOUNMAP and add REQ_HIPRI.
> > >
> > > Signed-off-by: Jianchao Wang
> > > ---
> > > block/blk-mq-debugfs.c | 3 ++-
> > > 1 file changed, 2 i
)
{
Reviewed-by: Bart Van Assche
@@
-ccflags-y := -Idrivers/target
obj-$(CONFIG_INFINIBAND_SRPT) += ib_srpt.o
Reviewed-by: Bart Van Assche
R(host->ufs_sys_ctrl);
>
> - return 0;
> + return PTR_ERR_OR_ZERO(host->ufs_sys_ctrl);
> }
Although I'm not sure this patch improves readability of the source code:
Reviewed-by: Bart Van Assche
return SCSI_DH_DEV_TEMP_BUSY;
> - }
> + if (!kaluad_wq)
> + return -ENOMEM;
>
> r = scsi_register_device_handler(&alua_dh);
> if (r != 0) {
>
Reviewed-by: Bart Van Assche
On 4/4/19 8:25 PM, Stephen Rothwell wrote:
Hi James,
After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
drivers/scsi/lpfc/lpfc_nvme.c:2140:1: warning: 'lpfc_nvme_lport_unreg_wait'
defined but not used [-Wunused-function]
lpfc_nvme_lport_unr
On 3/30/19 2:58 PM, syzbot wrote:
syzbot has bisected this bug to:
commit 669de8bda87b92ab9a2fc663b3f5743c2ad1ae9f
Author: Bart Van Assche
Date: Thu Feb 14 23:00:54 2019 +
kernel/workqueue: Use dynamic lockdep keys for workqueues
bisection log: https://syzkaller.appspot.com/x
On 4/23/19 3:22 AM, Pavel Machek wrote:
>>> It boots ok (unlike mainline -- I'm debugging that), and I can suspend
>>> and resume... but then cursor in X is moving and I can talk to
>>> applications cached in memory, but any access to disk hangs.
>>
>> Mainline problem was identified.
>>
>> But res
On Fri, 2019-04-26 at 12:32 +0200, Pavel Machek wrote:
> [detached HEAD 916db0d] Revert "scsi: sd: Inline sd_probe_part2()"
> 1 file changed, 58 insertions(+), 43 deletions(-)
> pavel@duo:/data/l/linux-next-32$ git revert
> 21e6ba3f0e0257cce1a226c1f15e0a8ba4338ca3
> Editing file: /data/fast/l/l
On Thu, 2019-05-02 at 13:48 -0600, Raul E Rangel wrote:
> The comment was out of date.
Reviewed-by: Bart Van Assche
On 7/10/19 3:09 PM, Peter Zijlstra wrote:
One thing I mentioned when Thomas did the unwinder API changes was
trying to move lockdep over to something like stackdepot.
We can't directly use stackdepot as is, because it uses locks and memory
allocation, but we could maybe add a lower level API to
On 7/12/19 1:55 AM, Peter Zijlstra wrote:
On Thu, Jul 11, 2019 at 11:53:12AM -0700, Bart Van Assche wrote:
On 7/10/19 3:09 PM, Peter Zijlstra wrote:
One thing I mentioned when Thomas did the unwinder API changes was
trying to move lockdep over to something like stackdepot.
We can't dir
this patch series
for Linux kernel v5.4.
Thanks,
Bart.
Bart Van Assche (4):
locking/lockdep: Make it clear that what lock_class::key points at is
not modified
stacktrace: Constify 'entries' arguments
locking/lockdep: Reduce space occupied by stack traces
locking/lockdep: Rep
This patch does not change the behavior of the lockdep code.
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: Waiman Long
Signed-off-by: Bart Van Assche
---
include/linux/lockdep.h| 2 +-
kernel/locking/lockdep.c | 2 +-
kernel/locking/lockdep_internals.h | 3 ++-
kernel/locking
and/rdma_cm", O_RDWR);
close(fd);
}
}
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: Yuyang Du
Cc: Waiman Long
Reported-by: Eric Biggers
Suggested-by: Peter Zijlstra
Signed-off-by: Bart Van Assche
---
include/linux/lockdep.h
Report the number of stack traces and the number of stack trace hash
chains. These two numbers are useful because these allow to estimate
the number of stack trace hash collisions.
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: Waiman Long
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c
Make it clear to humans and to the compiler that the stack trace
('entries') arguments are not modified.
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: Waiman Long
Signed-off-by: Bart Van Assche
---
include/linux/stacktrace.h | 4 ++--
kernel/stacktrace.c| 4 ++--
2 files
On 7/23/19 9:56 PM, Eric Biggers wrote:
Does this also fix any of the other bugs listed at
https://lore.kernel.org/lkml/20190710055838.GC2152@sol.localdomain/
?
BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
BUG: MAX_LOCKDEP_CHAINS too low!
BUG: MAX_LOCK_DEPTH too low! (2)
BUG: MAX_LOCKDEP_ENTRIES too l
On 6/17/19 5:19 AM, Christoph Hellwig wrote:
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 65d0a10c76ad..d333bb6b1c59 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1775,7 +1775,8 @@ void __scsi_init_queue(struct Scsi_Host *shost, struct
request_que
On 6/17/19 5:19 AM, Christoph Hellwig wrote:
We need to limit the devices max_sectors to what the DMA mapping
implementation can support. If not we risk running out of swiotlb
buffers easily.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/scsi_lib.c | 2 ++
1 file changed, 2 insertions(+
r_groups,
Reviewed-by: Bart Van Assche
viewed-by: Bart Van Assche
On 6/17/19 5:19 AM, Christoph Hellwig wrote:
This ensures all proper DMA layer handling is taken care of by the
SCSI midlayer.
Acked-by: Bart Van Assche
On 6/12/19 6:59 AM, Marc Gonzalez wrote:
According to the option's help message, SCSI_PROC_FS has been
superseded for ~15 years. Don't select it by default anymore.
Signed-off-by: Marc Gonzalez
---
drivers/scsi/Kconfig | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/scsi/Kconfi
On 6/17/19 5:35 PM, Douglas Gilbert wrote:
For sg3_utils:
$ find . -name '*.c' -exec grep "/proc/scsi" {} \; -print
static const char * proc_allow_dio = "/proc/scsi/sg/allow_dio";
./src/sg_read.c
static const char * proc_allow_dio = "/proc/scsi/sg/allow_dio";
./src/sgp_dd.c
static const char * p
On 6/28/19 6:05 AM, syzbot wrote:
syzbot has bisected this bug to:
commit a0b0fd53e1e67639b303b15939b9c653dbe7a8c4
Author: Bart Van Assche
Date: Thu Feb 14 23:00:46 2019 +
locking/lockdep: Free lock classes that are no longer in use
bisection log: https://syzkaller.appspot.com/x
On 7/4/19 2:55 AM, Ding Xiang wrote:
The return code after switch default is unreachable,
so remove it.
Signed-off-by: Ding Xiang
---
drivers/scsi/scsi_error.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index bfa569f..12180f0 1006
ected to a commit from the following person:
Bart Van Assche
(+jeffv)
Hi Eric,
Several days ago I had already explained to you that the bisection
result that led to one of my commits did not make any sense to me. So I
do not appreciate this kind of fingerpointing. Please stop doing this.
Bart.
On 7/9/19 10:30 PM, Eric Biggers wrote:
[Moved most people to Bcc; syzbot added way too many random people to this.]
Hi Bart,
On Sat, Mar 30, 2019 at 07:17:09PM -0700, Bart Van Assche wrote:
On 3/30/19 2:58 PM, syzbot wrote:
syzbot has bisected this bug to:
commit
On 7/10/19 10:21 AM, Eric Biggers wrote:
> With my simplified reproducer, on commit 669de8bda87b ("kernel/workqueue: Use
> dynamic lockdep keys for workqueues") I see:
>
> WARNING: CPU: 3 PID: 189 at kernel/locking/lockdep.c:747
> register_lock_class+0x4f6/0x580
>
> and then somewhat later
On 7/10/19 11:02 AM, Eric Biggers wrote:
> I already mentioned that io_uring triggers it too.
>
> Those are just 2 cases that syzbot happened to generate reproducers for. I
> expect there are many others too, since many places in the kernel allocate
> workqueues. AFAICS most are placed in static
On 7/10/19 11:44 AM, Eric Dumazet wrote:
> If anything using workqueues in dynamically allocated objects can turn off
> lockdep,
> we have a serious issue.
As far as I know that issue is only hit by syzbot tests. Anyway, I see
two possible paths forward:
* Revert the patch that makes workqueues u
On 7/10/19 1:47 PM, Eric Dumazet wrote:
>
>
> On 7/10/19 9:09 PM, Bart Van Assche wrote:
>> On 7/10/19 11:44 AM, Eric Dumazet wrote:
>>> If anything using workqueues in dynamically allocated objects can turn off
>>> lockdep,
>>> we have a serious issue.
pool_size), GFP_KERNEL);
> if (!pool)
> goto err;
> pool->size = pool_size;
Reviewed-by: Bart Van Assche
sd.h, but each are
only referenced in sd.c, relocate them to that same c file.
The inline specifier is dropped also, since gcc should be able to make the
decision to inline.
Reviewed-by: Bart Van Assche
ke the use of label names more
consistent with the rest of the block layer. Once these two comments are
addressed, feel free to add:
Reviewed-by: Bart Van Assche
Make sure that the lockdep_register_key() and lockdep_unregister_key()
code is tested when running the lockdep tests.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
tools/lib/lockdep/include/liblockdep/common.h | 2 ++
tools/lib/lockdep/include
lude the size of the chain_hlocks[] array.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.
Instead of abandoning elements of list_entries[] that are no longer in
use, make alloc_list_entry() reuse array elements that have been freed.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c | 48
This patch does not change any functionality but makes the next patch in
this series easier to read.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c | 16 +++-
kernel/locking/lockdep_internals.h | 3
n check_data_structures().
- Left out the patch that causes lockdep to complain if no name has been
assigned to a lock object. That patch namely causes the build bot to
complain about certain lock objects but I have not yet had the time to
figure out the identity of these lock objects.
Bar
encountering a dynamically
allocated key.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
include/linux/lockdep.h | 13 -
kernel/locking/lockdep.c | 123 ---
2 files changed, 125 insertions(+), 11 deletions
df/0xbb0
generic_file_direct_write+0x119/0x220
__generic_file_write_iter+0x131/0x2d0
ext4_file_write_iter+0x3fa/0x710
aio_write+0x235/0x330
io_submit_one+0x510/0xeb0
__x64_sys_io_submit+0x122/0x340
do_syscall_64+0x71/0x220
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Cc: Ingo Molna
: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index e52ce8745cba..5ca5904ad489 100644
--- a/kernel
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index acf61dbb8b30..72cff86829e6 100644
--- a/kernel/locking
Debugging lockdep data structure inconsistencies is challenging. Add
code that verifies data structure consistency at runtime. That code is
disabled by default because it is very CPU intensive.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
kernel
Make sure that add_chain_cache() returns 0 and does not modify the
chain hash if nr_chain_hlocks == MAX_LOCKDEP_CHAIN_HLOCKS before this
function is called.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c | 11 +--
1
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
include/linux/lockdep.h | 9 +-
kernel/locking/lockdep.c | 434 +--
2 files changed, 381 insertions(+), 62 deletions(-)
diff --git a/include/linux/lockdep.h b/inc
A previous patch introduced a lock chain leak. Fix that leak by reusing
lock chains that have been freed.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c | 62 ++--
1 file changed, 34
context of a lockdep selftest.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
include/linux/lockdep.h | 5 +
kernel/locking/lockdep.c | 6 ++
lib/locking-selftest.c | 2 ++
3 files changed, 13 insertions(+)
diff --git a/include/linux/lockdep.h b
Make sure that all lock order entries that refer to a class are removed
from the list_entries[] array when a kernel module is unloaded.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
include/linux/lockdep.h | 1 +
kernel/locking/lockdep.c | 19
This patch does not change any functionality but makes the patch that
frees lock classes that are no longer in use easier to read.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
include/linux/lockdep.h | 14 +++---
1 file changed, 7 insertions
This patch does not change the behavior of these functions but makes the
patch that frees unused lock classes easier to read.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c | 74 +---
1 file
On 3/7/19 11:37 PM, Kefeng Wang wrote:
syzkaller report an issue "KASAN: use-after-free Read in alloc_workqueue",
alloc_workqueue
- kzalloc wq
- wq_init_lockdep(wq);
- lockdep_register_key(&wq->key); // add to hlist
- kfree wq
But forget to call wq_unregister_lockdep()->lockdep_unreg
On Fri, 2019-03-08 at 12:48 +0800, kernel test robot wrote:
> [1.855169] spin_lock-torture: lock_torture_stats task started
> [2.565387] workingset: timestamp_bits=14 max_order=17 bucket_order=3
> [2.567522] NFS: Registering the id_resolver key type
> [2.568478] Key type id_resolver
On Mon, 2019-03-11 at 06:26 -0700, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit 669de8bda87b92ab9a2fc663b3f5743c2ad1ae9f
> Author: Bart Van Assche
> Date: Thu Feb 14 23:00:54 2019 +
>
> kernel/workqueue: Use dynamic lockdep keys for workqueu
On Mon, 2019-03-11 at 10:48 -0700, Linus Torvalds wrote:
> On Mon, Mar 11, 2019 at 8:19 AM Bart Van Assche wrote:
> >
> > I think this issue has been fixed by a commit that went upstream yesterday.
> > Hence:
> >
> > #syz fix: workqueue, lockdep: Fix an alloc
:
WARN_ON_ONCE(!found);
Cc: Tejun Heo
Cc: Qian Cai
Reported-by: syzbot+be0c198232f86389c...@syzkaller.appspotmail.com
Fixes: 009bb421b6ce ("workqueue, lockdep: Fix an alloc_workqueue() error path")
Signed-off-by: Bart Van Assche
---
kernel/workqueue.c | 5 +++--
1 file
On Thu, 2019-01-10 at 16:24 +0100, Peter Zijlstra wrote:
> [ ... ]
> @@ -4579,17 +4559,19 @@ static void lockdep_reset_lock_reg(struc
> */
> static void lockdep_reset_lock_imm(struct lockdep_map *lock)
> {
> - struct pending_free *pf;
> unsigned long flags;
> + LIST_HEAD(zapped);
On Fri, 2019-02-08 at 11:43 +, Will Deacon wrote:
> I've also been trying to understand why it's necessary to check both of the
> pending_free entries, and I'm still struggling somewhat. It's true that the
> wakeup in get_pending_free_lock() could lead to both entries being used
> without the R
no sleeping, as far as I could see. Additionally, the code that
> later allocates the block queue for the device (scsi_mq_alloc_queue())
> already uses GFP_KERNEL.
>
>
> [ ... ]
>
> So replace all these, and give them a bit of a better chance to succeed,
> with more chance
On Thu, 2019-02-14 at 15:00 -0800, Bart Van Assche wrote:
> A known shortcoming of the current lockdep implementation is that it requires
> lock keys to be allocated statically. This forces certain unrelated
> synchronization objects to share keys and this key sharing can cause false
&
On 2/22/19 8:26 AM, Peter Zijlstra wrote:
I've gone over all and I think it looks ok now; I'll give it another
round tomorrow^Wmonday and then queue bits.
So far the only changes I've made are the below. I'm not entirely sure
on the unconditional validity check on DEBUG_LOCKDEP, maybe I'll add a
On 3/22/19 7:37 PM, Kangjie Lu wrote:
On Mar 8, 2019, at 11:19 PM, Kangjie Lu wrote:
get_skb may fail and return NULL. The fix returns "ENOMEM"
when it fails to avoid NULL dereference.
Signed-off-by: Kangjie Lu
---
drivers/infiniband/hw/cxgb4/cm.c | 3 +++
1 file changed, 3 insertions(+)
diff
On Mon, 2019-03-25 at 17:45 +0800, shenghui wrote:
> Sorry to trouble you.
>
> I installed virtualbox-5.2.24 on my system (x86 32) and on bootup I got some
> warning:
> -
> 1251 [ 42.640869] DEBUG_LOCKS_WARN_ON(!current->hardirqs_enabled)
> 1252 [ 42.640880] WARNING: CPU:
On Mon, 2019-03-25 at 17:45 +0800, shenghui wrote:
> I installed virtualbox-5.2.24 on my system (x86 32) and on bootup I got some
> warning:
> -
> 1251 [ 42.640869] DEBUG_LOCKS_WARN_ON(!current->hardirqs_enabled)
> 1252 [ 42.640880] WARNING: CPU: 0 PID: 841 at kernel/lockin
On 3/25/19 5:27 PM, shenghui wrote:
On 3/26/19 1:06 AM, Bart Van Assche wrote:
On Mon, 2019-03-25 at 17:45 +0800, shenghui wrote:
[ 47.103637] vboxdrv: loading out-of-tree module taints kernel.
[ 47.111919] vboxdrv: Found 2 processor cores
[ 47.119013] vboxdrv: fAsync=0 offMin=0x2ee
.
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 21cb81fe6359..c8c83e1e2664 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockde
(GFP_KERNEL, "%s%s", "(wq_completion)", wq->name);
if (!lock_name)
lock_name = wq->name;
+
+ wq->lock_name = lock_name;
lockdep_init_map(&wq->lockdep_map, lock_name, &wq->key, 0);
}
Not sure how this got overlooked. Anyway:
Reviewed-by: Bart Van Assche
On 3/3/19 10:22 AM, syzbot wrote:
syzbot found the following crash on:
HEAD commit: c63e9e91a254 Add linux-next specific files for 20190301
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16ac728d20
kernel config: https://syzkaller.appspot.com/x/.conf
[888090fc2580, 888090fc2780)
Reported-by: syzbot+17335689e239ce135...@syzkaller.appspotmail.com
Fixes: 669de8bda87b ("kernel/workqueue: Use dynamic lockdep keys for
workqueues")
Signed-off-by: Bart Van Assche
---
kernel/workqueue.c | 2 ++
1 file changed, 2 insertions(+)
diff --gi
(+Tejun)
On 3/3/19 2:00 PM, Bart Van Assche wrote:
This patch fixes a use-after-free and a memory leak in an alloc_workqueue()
error path. This patch avoids that e.g. the following complaint gets
reported:
BUG: KASAN: use-after-free in __read_once_size include/linux/compiler.h:197
[inline
y
Cc: Rasmus Villemoes
Fixes: 0c66847793d1 ("overflow.h: Add arithmetic shift helper") # v4.19
Signed-off-by: Bart Van Assche
---
include/linux/overflow.h | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/include/linux/overflow.h b/include/linux/ove
On 3/6/19 5:24 PM, Jason Gunthorpe wrote:
On Wed, Mar 06, 2019 at 05:01:53PM -0800, Bart Van Assche wrote:
This patch avoids that the following warning is reported when building
the mlx5 driver with W=1:
drivers/infiniband/hw/mlx5/qp.c: In function set_user_rq_size:
./include/linux/overflow.h
On 3/6/19 11:24 PM, Leon Romanovsky wrote:
My simple patch passes too :).
Can you repost your patch?
Thanks,
Bart.
,9 @@ static bool class_lock_list_valid(struct lock_class *c,
> struct list_head *h)
> return true;
> }
>
> -static u16 chain_hlocks[];
> +#ifdef CONFIG_PROVE_LOCKING
> +static u16 chain_hlocks[MAX_LOCKDEP_CHAIN_HLOCKS];
> +#endif
>
> static bool check_lock_chain_key(struct lock_chain *chain)
> {
Reviewed-by: Bart Van Assche
On Thu, 2019-03-07 at 08:18 +0100, Rasmus Villemoes wrote:
> On 07/03/2019 03.14, Bart Van Assche wrote:
> > On 3/6/19 5:24 PM, Jason Gunthorpe wrote:
> > > >
> > > > diff --git a/include/linux/overflow.h b/include/linux/overflow.h
> > > > index 40
On Thu, 2019-01-10 at 16:24 +0100, Peter Zijlstra wrote:
> /*
> * A data structure for delayed freeing of data structures that may be
> - * accessed by RCU readers at the time these were freed. The size of the
> array
> - * is a compromise between minimizing the amount of memory used by this ar
On Thu, 2019-01-10 at 16:28 +0100, Peter Zijlstra wrote:
> On Mon, Dec 17, 2018 at 01:29:54PM -0800, Bart Van Assche wrote:
> > +static bool inside_selftest(void)
> > +{
> > + return current == lockdep_selftest_task_struct;
> > +}
> > +void lockdep_free_key_rang
On Thu, 2019-01-10 at 20:44 +0100, Peter Zijlstra wrote:
> On Thu, Jan 10, 2019 at 10:51:27AM -0800, Bart Van Assche wrote:
> > On Thu, 2019-01-10 at 16:24 +0100, Peter Zijlstra wrote:
> > > /*
> > > * A data structure for delayed freeing of data structures that may b
On Fri, 2019-01-11 at 13:48 +0100, Peter Zijlstra wrote:
> I spotted this new v6 in my inbox and have rebased to it.
Thanks!
> On Wed, Jan 09, 2019 at 01:01:48PM -0800, Bart Van Assche wrote:
>
> > The changes compared to v5 are:
> > - Modified zap_class() such that it
On Fri, 2019-01-11 at 17:55 +0100, Peter Zijlstra wrote:
> On Fri, Jan 11, 2019 at 07:55:03AM -0800, Bart Van Assche wrote:
> > On Fri, 2019-01-11 at 13:48 +0100, Peter Zijlstra wrote:
> > > I spotted this new v6 in my inbox and have rebased to it.
> >
> > Thanks!
&
On Mon, 2018-09-24 at 17:43 +0300, Andrey Ryabinin wrote:
>
> On 09/24/2018 05:19 PM, Bart Van Assche wrote:
> > On 9/24/18 2:46 AM, Andrey Ryabinin wrote:
> > > On 09/24/2018 01:42 AM, Ming Lei wrote:
> > > > On Fri, Sep 21, 2018 at 03:04:18PM +0200, Vitaly Kuz
n the 32-bit builds with an
> overspecified length parameter.
Otherwise,
Reviewed-by: Bart Van Assche
int which, in the case of number of
> elements, matches the underlying struct scatterlist.
Anyway,
Reviewed-by: Bart Van Assche
On Wed, 2018-09-26 at 15:16 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> sg_init_table will clear the allocated block so requesting zeroed memory
> from the allocator is redundant.
Reviewed-by: Bart Van Assche
x this by cleaning up using sgl_free_n_order which allows the correct
> page order to be passed in.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Bart Van Assche
> Cc: Hannes Reinecke
> Cc: Johannes Thumshirn
> Cc: Jens Axboe
> ---
> lib/scatterlist.c | 6 --
On Wed, 2018-09-26 at 15:16 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> We should not use an explicit width u32 for elem_len but unsinged int to
> match the underlying type in struct scatterlist.
Reviewed-by: Bart Van Assche
the right hand side unsigned int
> number of elements multiplied by element size.
Reviewed-by: Bart Van Assche
On Wed, 2018-09-26 at 15:16 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Mostly same fixes and cleanups I've sent earlier in the year, but with some
> patches dropped and some split into smaller ones as per request.
I think in order for a patch series to get noticed that the maintaine
On Wed, 2018-10-03 at 17:55 +0200, Paolo Valente wrote:
> The problem, in particular, is that bfq is a complex beast, fighting
> against a jungle of I/O issues. You have to be really into bfq, even
> to just know all of its features!
This is a problem by itself. I don't know anyone who wants to h
On Thu, Aug 30, 2018 at 3:35 PM Igor Stoppa wrote:
>
> WARN_ON() already contains an unlikely(), so it's not necessary to
> wrap it into another.
Reviewed-by: Bart Van Assche
On Sun, 2018-05-20 at 07:54 +0530, Alim Akhtar wrote:
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index a355d98..9a1374e 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -7781,6 +7781,9 @@ EXPORT_SYMBOL_GPL(ufshcd_dealloc_host);
> */
> st
On Sun, 2018-05-20 at 18:17 -0400, Kent Overstreet wrote:
> On Fri, May 18, 2018 at 03:12:27PM +0000, Bart Van Assche wrote:
> > On Fri, 2018-05-18 at 05:06 -0400, Kent Overstreet wrote:
> > > On Thu, May 17, 2018 at 08:54:57PM +0000, Bart Van Assche wrote:
> > > &
On Sun, 2018-05-20 at 18:31 -0400, Kent Overstreet wrote:
> On Sun, May 20, 2018 at 10:19:13PM +0000, Bart Van Assche wrote:
> > On Sun, 2018-05-20 at 18:17 -0400, Kent Overstreet wrote:
> > > On Fri, May 18, 2018 at 03:12:27PM +0000, Bart Van Assche wrote:
> > > &g
On Sun, 2018-05-20 at 19:00 -0400, Kent Overstreet wrote:
> On Sun, May 20, 2018 at 10:35:29PM +0000, Bart Van Assche wrote:
> > On Sun, 2018-05-20 at 18:31 -0400, Kent Overstreet wrote:
> > > On Sun, May 20, 2018 at 10:19:13PM +0000, Bart Van Assche wrote:
> > > &g
On Sun, 2018-05-20 at 19:21 -0400, Kent Overstreet wrote:
> I really have better things to do than debug someone else's tests...
> [ ... ]
> ../run_tests: line 65: cd: /lib/modules/4.16.0+/kernel/block: No such file or
> directory
Kernel v4.16 is too old to run these tests. The srp-test script ne
801 - 900 of 1594 matches
Mail list logo
