On 04/19/2016 09:23 PM, Davidlohr Bueso wrote:
On Tue, 19 Apr 2016, Bart Van Assche wrote:
On 04/16/2016 01:55 PM, Davidlohr Bueso wrote:
... as the call obviously already implies unlock/RC semantics,
therefore lets get rid of the superfluous smp_mb calls.
Hello Davidlohr,
Are you sure
On 03/22/16 15:03, Ming Lin wrote:
From: Ming Lin
Rename SCSI_MAX_SG_SEGMENTS to SG_CHUNK_SIZE, which means the amount
we fit into a single scatterlist chunk.
Rename SCSI_MAX_SG_CHAIN_SEGMENTS to SG_MAX_SEGMENTS.
Will move these 2 generic definitions to scatterlist.h later.
Signed-off-by: Mi
On 04/11/16 15:04, Ming Lin wrote:
On Mon, Apr 11, 2016 at 2:34 PM, Martin K. Petersen
wrote:
"Ming" == Ming Lin writes:
Ming> Are we ready to merge it?
We're still missing an ack from Sagi.
Thought we already had a ack from Bart.
OK, let's get one more from Sagi.
Hmm ... this patch doe
On 11/20/2015 02:16 AM, Christoph Hellwig wrote:
> On Wed, Nov 18, 2015 at 10:20:14AM -0800, Bart Van Assche wrote:
>> Are you perhaps referring to the sysfs CPU mask that allows to control
>> workqueue affinity ?
>
> I think he is referring to the defintion of WQ_UNBOUN
On 11/20/2015 03:52 AM, Christoph Hellwig wrote:
the memory leak looks real, and your fix looks corret, but I still
don't like it.
I think it's reasonable for SCSI to assume that the final put_device
fully frees the struct device including the name pointer that is
assigned entirely behind the ba
On 11/22/15 06:57, Sagi Grimberg wrote:
I think that bart wants to allow the caller to select cpu affinity
per CQ. In this case ib_alloc_cq in workqueue mode would need to
accept a affinity_hint from the caller (default to wild-card
WORK_CPU_UNBOUND).
Hmm, true. How would be set that hint from
On 11/23/2015 12:37 PM, Jason Gunthorpe wrote:
On Sat, Nov 14, 2015 at 08:13:44AM +0100, Christoph Hellwig wrote:
On Fri, Nov 13, 2015 at 03:06:36PM -0700, Jason Gunthorpe wrote:
Looking at that thread and then at the patch a bit more..
+void ib_process_cq_direct(struct ib_cq *cq)
[..]
+
On 11/23/2015 01:28 PM, Jason Gunthorpe wrote:
On Mon, Nov 23, 2015 at 01:04:25PM -0800, Bart Van Assche wrote:
Considerable time ago the send queue in the SRP initiator driver was
modified from signaled to non-signaled to reduce the number of interrupts
triggered by the SRP initiator driver
On 11/23/2015 02:18 PM, Jason Gunthorpe wrote:
On Mon, Nov 23, 2015 at 01:54:05PM -0800, Bart Van Assche wrote:
What I don't see is how SRP handles things when the
sendq fills up, ie the case where __srp_get_tx_iu() == NULL. It looks
like the driver starts to panic and generates printks. I
completely eliminated the memory
corruption panics.
If you have to repost this series please convert
BUG_ON(!spin_is_locked(&ioc->sas_device_lock)); into
lockdep_is_held(...). Otherwise, for the whole series:
Reviewed-by: Bart Van Assche
--
To unsubscribe from this list: send the line &
On 11/15/2015 01:34 AM, Sagi Grimberg wrote:
This is taken from srp, and srp drains using a recv wr due to a race
causing a use-after-free condition in srp which re-posts a recv buffer
in the recv completion handler.
Hello Sagi,
Would it be possible to clarify this ? Does this refer to an exis
On 11/13/2015 11:02 PM, Christoph Hellwig wrote:
On Fri, Nov 13, 2015 at 11:19:24AM -0800, Bart Van Assche wrote:
On 11/13/2015 05:46 AM, Christoph Hellwig wrote:
The new name is irq_poll as iopoll is already taken. Better suggestions
welcome.
Would it be possible to provide more background
On 11/17/2015 09:16 AM, Bart Van Assche wrote:
On 11/13/2015 11:02 PM, Christoph Hellwig wrote:
On Fri, Nov 13, 2015 at 11:19:24AM -0800, Bart Van Assche wrote:
On 11/13/2015 05:46 AM, Christoph Hellwig wrote:
The new name is irq_poll as iopoll is already taken. Better suggestions
welcome
On 11/13/2015 05:46 AM, Christoph Hellwig wrote:
+ * context and does not ask from completion interrupts from the HCA.
Should this perhaps be changed into "for" ?
+ */
+void ib_process_cq_direct(struct ib_cq *cq)
+{
+ WARN_ON_ONCE(cq->poll_ctx != IB_PO
On 11/13/2015 05:46 AM, Christoph Hellwig wrote:
> [ ... ]
The previous patch and this patch look like great work to me. However,
this patch not only reworks the SRP target driver but also prevents
users to move the SRP completion thread to another CPU core than the CPU
core that processes the
On 11/13/2015 05:46 AM, Christoph Hellwig wrote:
[ ... ]
This patch contains two logical changes:
- Conversion to the new CQ API.
- Removal of the ib_srpt_compl thread.
Had it been considered to implement these changes as two separate patches ?
Thanks,
Bart.
--
To unsubscribe from this list:
On 11/13/2015 05:46 AM, Christoph Hellwig wrote:
+static void srp_inv_rkey_done(struct ib_cq *cq, struct ib_wc *wc)
+{
+ srp_handle_qp_err(cq, wc, "INV RKEY");
+}
>
[ ... ]
>
+static void srp_reg_mr_done(struct ib_cq *cq, struct ib_wc *wc)
+{
+ srp_handle_qp_err(cq, wc, "FAST REG"
On 11/04/2015 08:32 AM, mchri...@redhat.com wrote:
There are a couple new block layer commands we are trying to add support
for in the near term:
compare and write
http://www.spinics.net/lists/target-devel/msg07826.html
copy offload/extended copy/xcopy
https://www.redhat.com/archives/dm-devel/2
On 11/04/2015 02:08 PM, mchri...@redhat.com wrote:
From: Mike Christie
In later patches the op will no longer be a bitmap, so we will
not have REQ_WRITE set for all non reads like discard, flush,
and write same. Drivers will still want to treat them as writes
for accounting reasons, so this pat
On Mon, 2019-03-18 at 16:57 +0800, Yuyang Du wrote:
> - if (ret < 0) {
> + if (unlikely(ret < 0)) {
> print_bfs_bug(ret);
> return 0;
> }
> - if (ret == 1)
> + else if (ret == 1)
> return ret;
Have you verified this pa
On Mon, 2019-03-18 at 02:45 -0700, Joe Perches wrote:
> > -static void
> > -print_circular_lock_scenario(struct held_lock *src,
> > -struct held_lock *tgt,
> > -struct lock_list *prt)
> > +static void print_circular_lock_scenario(struct held_lock *src
On Mon, 2019-03-18 at 16:57 +0800, Yuyang Du wrote:
> Being paranoid to see function arguments lines are aligned.
This patch changes code that conforms to the kernel coding style into
code that does not conform to the kernel coding style. If you have a
look at the c-lineup-arglist-tabs-only functi
On Mon, 2019-03-18 at 16:57 +0800, Yuyang Du wrote:
> struct lock_chain {
> - /* see BUILD_BUG_ON()s in lookup_chain_cache() */
> + /*
> +* irq_context: the same as irq_context in held_lock below
> +* depth: the number of held locks in this chain
> +* base
On Mon, 2019-03-18 at 16:57 +0800, Yuyang Du wrote:
> Its lockdep_map argument is not used, remove it.
Maybe update the commit message to reflect that the same unused argument is
also removed from check_deadlock()? Anyway:
Reviewed-by: Bart Van Assche
On Mon, 2019-03-18 at 16:57 +0800, Yuyang Du wrote:
> check_prev_add() always has save_trace() as an input argument, which is
> unnecessary.
I think this kind of transformation is called constant propagation. You may
want to mention that name. Anyway:
Reviewed-by: Bart Van Assche
On Mon, 2019-03-18 at 16:57 +0800, Yuyang Du wrote:
> The element field is an array in struct circular_queue to keep track of locks
> in the search. Making it the same type as the locks avoids type cast. Also
> fix a typo.
>
> No functional change.
Reviewed-by: Bart Van Assche
On Mon, 2019-03-18 at 16:57 +0800, Yuyang Du wrote:
> The element field is an array in struct circular_queue to keep track of locks
> in the search. Making it the same type as the locks avoids type cast. Also
> fix a typo.
BTW, your patch does more than fixing a typo. This patch elaborates the co
On Mon, 2019-03-18 at 16:57 +0800, Yuyang Du wrote:
> __cq_empty() can be embeded in __cq_dequeue(), removing it. We get slightly
> simpler code. No functional change.
Does inlining __cq_empty() really improve readability of the lockdep code?
> -static inline int __cq_dequeue(struct circular_queu
On Mon, 2019-03-18 at 16:57 +0800, Yuyang Du wrote:
> +static inline struct list_head *get_forward_dep(struct lock_list * lock)
> +{
> + return &lock->class->locks_after;
> +}
> +
> +static inline struct list_head *get_backward_dep(struct lock_list * lock)
> +{
> + return &lock->class->
ngshan
Cc: Alexander Duyck
Cc: Dan Williams
Fixes: 669de8bda87b ("kernel/workqueue: Use dynamic lockdep keys for
workqueues")
Signed-off-by: Bart Van Assche
---
include/linux/workqueue.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/workqueue.h b/include/linux/w
This patch avoids that the following warning is reported when building
with W=1:
kernel/workqueue.c:938: warning: Function parameter or member 'task' not
described in 'wq_worker_last_func'
Signed-off-by: Bart Van Assche
---
kernel/workqueue.c | 1 +
1 file changed, 1 inse
On Tue, 2019-03-19 at 16:41 +0200, Maxim Levitsky wrote:
> * Polling kernel thread is used. The polling is stopped after a
> predefined timeout (1/2 sec by default).
> Support for all interrupt driven mode is planned, and it shows promising
> results.
Which cgroup will the CPU cycles used for po
On Tue, 2019-03-19 at 16:41 +0200, Maxim Levitsky wrote:
> * All guest memory is mapped into the physical nvme device
>but not 1:1 as vfio-pci would do this.
>This allows very efficient DMA.
>To support this, patch 2 adds ability for a mdev device to listen on
>guest's memory map
On 8/14/19 9:52 AM, Abdul Haleem wrote:
> Greeting's
>
> Today's linux-next kernel (5.3.0-rc4-next-20190813) booted with warning on
> my powerpc power 8 lpar
>
> The WARN_ON_ONCE() was introduced by commit 88263208 (scsi: qla2xxx: Complain
> if sp->done() is not...)
>
> boot logs:
>
> WARNIN
On 8/14/19 10:18 AM, Abdul Haleem wrote:
On Wed, 2019-08-14 at 10:05 -0700, Bart Van Assche wrote:
On 8/14/19 9:52 AM, Abdul Haleem wrote:
Greeting's
Today's linux-next kernel (5.3.0-rc4-next-20190813) booted with warning on my
powerpc power 8 lpar
The WARN_ON_ONCE() was int
75c2500b69)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=130ffe4a60
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17137d2c60
The bug was bisected to:
commit a0b0fd53e1e67639b303b15939b9c653dbe7a8c4
Author: Bart Van Assche
Date: Thu Feb 14 23:00:46 2019 +
On 8/27/19 1:53 AM, Ming Lei wrote:
If one vector is spread on several CPUs, usually the interrupt is only
handled on one of these CPUs.
Is that perhaps a limitation of x86 interrupt handling hardware? See
also the description of physical and logical destination mode of the
local APIC in the
On 8/30/19 2:13 PM, Qian Cai wrote:
https://raw.githubusercontent.com/cailca/linux-mm/master/powerpc.config
Once in a while, booting an IBM POWER9 PowerNV system (8335-GTH) would generate
a warning in lockdep_register_key() at,
if (WARN_ON_ONCE(static_obj(key)))
because
key = 0xc19ad1
On 9/3/19 12:50 AM, Daniel Lezcano wrote:
On 03/09/2019 09:28, Ming Lei wrote:
On Tue, Sep 03, 2019 at 08:40:35AM +0200, Daniel Lezcano wrote:
It is a scheduler problem then ?
Scheduler can do nothing if the CPU is taken completely by handling
interrupt & softirq, so seems not a scheduler pro
On 9/4/19 10:31 AM, Daniel Lezcano wrote:
On 04/09/2019 19:07, Bart Van Assche wrote:
Only if CONFIG_IRQ_TIME_ACCOUNTING has been enabled. However, I don't
know any Linux distro that enables that option. That's probably because
that option introduces two rdtsc() calls in each interr
On 9/4/19 11:02 AM, Peter Zijlstra wrote:
On Wed, Sep 04, 2019 at 10:38:59AM -0700, Bart Van Assche wrote:
I think it is widely known that rdtsc is a relatively slow x86 instruction.
So I expect that using that instruction will cause a measurable overhead if
it is called frequently enough. I&#
On 9/11/19 4:48 PM, Dan Williams wrote:
> At last years Plumbers Conference I proposed the Maintainer Entry
> Profile as a document that a maintainer can provide to set contributor
> expectations and provide fodder for a discussion between maintainers
> about the merits of different maintainer poli
On 9/11/19 5:40 PM, Martin K. Petersen wrote:
> * Do not use custom To: and Cc: for individual patches. We want to see the
> whole series, even patches that potentially need to go through a different
> subsystem tree.
Hi Martin,
Thanks for having written this summary. This is very helpful. Fo
On 9/12/19 8:34 AM, Joe Perches wrote:
> On Thu, 2019-09-12 at 14:31 +0100, Bart Van Assche wrote:
>> On 9/11/19 5:40 PM, Martin K. Petersen wrote:
>>> * The patch must compile without warnings (make C=1 CF="-D__CHECK_ENDIAN__")
>>> and does not incur any zer
On 10/8/19 9:35 AM, Gabriel Krisman Bertazi wrote:
André Almeida writes:
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index e0fce93ac127..8b745f229789 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -10,74 +10,153 @@ struct blk_mq_tags;
struct blk_flush_qu
On 10/3/19 2:19 PM, Randy Dunlap wrote:
[add linux-scsi mailing list]
On 10/3/19 1:32 PM, Bradley LaBoon wrote:
Hello, LKML!
Beginning with kernel 5.3 the order in which SCSI devices are probed and
named has become non-deterministic. This is a result of a patch that was
submitted to add asynch
lock_class_key has size zero.
This patch is an improvement for commit 027a485d12e0 ("sysfs: use a
separate locking class for open files depending on mmap"; v3.13).
Cc: Dave Jones
Cc: Tejun Heo
Cc: Greg Kroah-Hartman
Signed-off-by: Bart Van Assche
---
fs/kernfs/file.c
On 9/22/19 11:01 PM, Milan P. Gandhi wrote:
+ off += scnprintf(logbuf + off, logbuf_len - off,
+"cmd-age=%lus", cmd_age);
Have you considered to change cmd-age into cmd_age? I'm afraid otherwise
someone might interpret the hyphen as a subtraction sign...
Thanks,
On 2019-09-25 05:39, Daniel Wagner wrote:
> So I after starring on the code I am not sure if the WARN_ON_ONCE is
> correct. It assumes that after processing one status continuation,
> there is no more work. Though it looks like there is another element
> to process. Is it possible that two sense co
oving kfree
out of critical section(s) after causing softlockups due to increased lock
contention.
The above would be a great addition for the commit description. Anyway:
Reviewed-by: Bart Van Assche
On 9/26/19 1:40 AM, Yunfeng Ye wrote:
current_is_async() can be implemented using current_work(), it's better
not to be aware of the workqueue's internal information.
Reviewed-by: Bart Van Assche
command failures:
Reviewed-by: Bart Van Assche
ons element. According to the firmware documentation
> it is possible that multiple status continuations are emitted by the
> firmware.
>
> Cc: Bart Van Assche
> Signed-off-by: Daniel Wagner
> ---
> drivers/scsi/qla2xxx/qla_isr.c | 2 --
> 1 file changed, 2 deletions(-)
&
On 2020-04-30 22:12, Can Guo wrote:
> diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
> index 3717eea..d18271d 100644
> --- a/drivers/scsi/scsi_pm.c
> +++ b/drivers/scsi/scsi_pm.c
> @@ -74,12 +74,15 @@ static int scsi_dev_type_resume(struct device *dev,
> {
> const struct dev_
On 2020-04-29 00:46, Luis Chamberlain wrote:
> The last reference for the request_queue must not be called from atomic
> conext. *When* the last reference to the request_queue reaches 0 varies,
^^
context?
> and so let's take the opportunity to document when that is expected to
> happen and
t;name, blk_debugfs_root);
> + if (!dir)
> + bt->dir = dir = debugfs_create_dir(buts->name,
> blk_debugfs_root);
> +
> + return dir;
> +}
Initializing 'dir' is not necessary since the first statement overwrites
'dir'. Anyway:
Reviewed-by: Bart Van Assche
On 2020-04-29 21:10, Can Guo wrote:
> During system resume, scsi_resume_device() decreases a request queue's
> pm_only counter if the scsi device was quiesced before. But after that,
> if the scsi device's RPM status is RPM_SUSPENDED, the pm_only counter is
> still held (non-zero). Current scsi res
On 2020-04-29 22:40, Can Guo wrote:
> On 2020-04-30 13:08, Bart Van Assche wrote:
>> On 2020-04-29 21:10, Can Guo wrote:
>>> During system resume, scsi_resume_device() decreases a request queue's
>>> pm_only counter if the scsi device was quiesced before. But afte
On 2020-04-30 18:42, Can Guo wrote:
> On 2020-05-01 04:32, Bart Van Assche wrote:
> > Has it been considered to test directly whether a SCSI device has been
> > runtime suspended instead of relying on blk_queue_pm_only()? How about
> > using pm_runtime_status_suspended() or
*mpi_fw_dump;
> u32 mpi_fw_dump_len;
> - int mpi_fw_dump_reading:1;
> - int mpi_fw_dumped:1;
> + unsigned intmpi_fw_dump_reading:1;
> + unsigned intmpi_fw_dumped:1;
> int prev_minidump_failed;
> dma_addr_t eft_dma;
> void*eft;
Reviewed-by: Bart Van Assche
On 10/7/19 1:16 PM, Stephen Rothwell wrote:
In commit
1d200e9d6f63 ("block: Fix writeback throttling W=1 compiler warnings")
Fixes tag
Fixes: e34cbd307477 ("blk-wbt: add general throttling mechanism"; v4.10).
has these problem(s):
- Subject has leading but no trailing quotes
- Su
On 10/14/19 5:16 AM, Colin King wrote:
diff --git a/drivers/scsi/scsi_trace.c b/drivers/scsi/scsi_trace.c
index 0f17e7dac1b0..1d3a5a2dc229 100644
--- a/drivers/scsi/scsi_trace.c
+++ b/drivers/scsi/scsi_trace.c
@@ -38,7 +38,7 @@ scsi_trace_rw10(struct trace_seq *p, unsigned char *cdb, int
len)
On Thu, 2019-02-14 at 10:04 -0800, Evan Green wrote:
> Greetings, block experts!
>
> I'm trying to track down a KASAN warning I'm seeing in our downstream
> 4.19 kernel, and I could use a little help. The warning looks like
> this:
>
> [ 224.564894] BUG: KASAN: use-after-free in bt_for_each+0x1a
On Thu, 2019-02-14 at 13:50 -0700, Jens Axboe wrote:
> On 2/14/19 1:45 PM, Evan Green wrote:
> > On Thu, Feb 14, 2019 at 11:33 AM Bart Van Assche wrote:
> > >
> > > On Thu, 2019-02-14 at 10:04 -0800, Evan Green wrote:
> > > > Greetings, block experts!
>
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 193fef487a15..b00c6edd6a28 100644
--- a/kernel/locking/lockdep.c
+++ b/kern
.
- Avoid that lockdep_init_map() complains when encountering a dynamically
allocated key.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
include/linux/lockdep.h | 21 ++-
kernel/locking/lockdep.c | 122 ---
2
Use %zu to format size_t instead of %lu to avoid that the compiler
complains about a mismatch between format specifier and argument on
32-bit systems.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c | 4 ++--
1 file changed, 2
synchronize_sched() has been removed recently. Update the comments that
refer to synchronize_sched().
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Fixes: 51959d85f32d ("lockdep: Replace synchronize_sched() with
synchronize_rcu()") # v5.0-rc1
Signed-off-by: Bart Van Assche
-
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.
Bart Van Assche (23):
locking/lockdep: Fix two 32-bit compiler warnings
locking/lockdep: Fix reported required memory size
tests: Improve testing accuracy") #
v5.0-rc1
Signed-off-by: Bart Van Assche
---
tools/lib/lockdep/run_tests.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/lib/lockdep/run_tests.sh b/tools/lib/lockdep/run_tests.sh
index c8fbd0306960..11f425662b43 100755
--- a
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
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
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
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 | 57 ++--
1 file changed, 37
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
uest+0x1a/0x100
blk_flush_complete_seq+0xe5/0x350
flush_end_io+0x12f/0x1d0
blk_done_softirq+0x9f/0xd0
__do_softirq+0xca/0x440
run_ksoftirqd+0x24/0x50
smpboot_thread_fn+0x113/0x1e0
kthread+0x121/0x140
ret_from_fork+0x3a/0x50
Cc: Jens Axboe
Cc: Ming Lei
Cc: Theodore Ts'o
Signed-off-by: Ba
: Ingo Molnar
Cc: Will Deacon
Signed-off-by: Bart Van Assche
---
include/linux/spinlock.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
index e089157dcf97..09b3e27ed21d 100644
--- a/include/linux/spinlock.h
+++ b/include
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 | 24
1
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 | 72
1 file
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
ned-off-by: Bart Van Assche
---
include/linux/lockdep.h | 9 +-
kernel/locking/lockdep.c | 396 ++-
2 files changed, 354 insertions(+), 51 deletions(-)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 66eee1ba0f2a..619ec3f26cdc 100644
---
Reflect that add_chain_cache() is always called with the graph lock held.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/locking/lockdep.c b/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 f5df97812dfa..93216e195b4f 100644
--- a/kernel/locking
: 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 16657662ca4f..9967599d7864 100644
--- a/kernel
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
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
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
that array from struct list_head into struct hlist_head.
Cc: Peter Zijlstra
Cc: Waiman Long
Cc: Johannes Berg
Signed-off-by: Bart Van Assche
---
kernel/locking/lockdep.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking
On Fri, 2019-02-15 at 10:26 +0800, Ming Lei wrote:
> There might be lots of blk_flush_queue instance which is allocated
> for each hctx, then lots of class key slot may be wasted.
>
> So I suggest to use one nvmet_loop_flush_lock_key for this particular issue,
> something like the following patch:
On Fri, 2019-02-15 at 08:49 -0700, Jens Axboe wrote:
> On 2/15/19 4:13 AM, Ming Lei wrote:
> > This patchset brings multi-page bvec into block layer:
>
> Applied, thanks Ming. Let's hope it sticks!
Hi Jens and Ming,
Test nvmeof-mp/002 fails with Jens' for-next branch from this morning.
I have no
On Sun, 2019-02-17 at 21:11 +0800, Ming Lei wrote:
> The following patch should fix this issue:
>
>
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index bed065904677..066b66430523 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -363,13 +363,15 @@ static unsigned int __blk_
On Tue, 2019-02-19 at 15:27 +0800, Jason Yan wrote:
> If we remove the scsi disk when running io with fio, oops occured with
> the following condition.
>
> [scsi_eh_0] [fio]
> scsi_end_request
> ->blk_update_request
> ->end_bio(io returned to userspace)
>
On Sun, 2019-02-17 at 08:30 +0200, Avri Altman wrote:
> Those are no longer in use since commit 242f9dcb8ba6
> ("block: unify request timeout handling").
Reviewed-by: Bart Van Assche
On 2/19/19 5:17 PM, Ming Lei wrote:
On Tue, Feb 19, 2019 at 08:28:19AM -0800, Bart Van Assche wrote:
With this patch applied test nvmeof-mp/002 fails as follows:
[ 694.700400] kernel BUG at lib/sg_pool.c:103!
[ 694.705932] invalid opcode: [#1] PREEMPT SMP KASAN
[ 694.708297] CPU: 2 PID
On Wed, 2019-02-20 at 19:48 +0100, Benjamin Block wrote:
> We had a test-report where, under memory pressure, adding LUNs to the
> systems would fail (the tests add LUNs strictly in sequence):
Hi Benjamin,
There are two more instances of GFP_ATOMIC in scsi_scan.c. Have you verified
whether or not
d in the log as an I/O error, which is scary and not
> helpful in debugging.
Reviewed-by: Bart Van Assche
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
: Bart Van Assche
---
Changes compared to v1: instead of modifying rhashtable_init(), modify its
caller.
lib/test_rhashtable.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/lib/test_rhashtable.c b/lib/test_rhashtable.c
index 6a8ac7626797
eviewed-by: Bart Van Assche
st this patch, please use that opportunity to join
the above split strings. Additionally, since this patch touches much
more SCSI code than ATA code I think it should have been sent to Martin
instead of to Jens. Anyway:
Reviewed-by: Bart Van Assche
701 - 800 of 1594 matches
Mail list logo
