On Mon, 2018-10-29 at 13:53 -0600, Jens Axboe wrote:
> On 10/29/18 1:40 PM, Bart Van Assche wrote:
> > On Mon, 2018-10-29 at 10:37 -0600, Jens Axboe wrote:
> > > -static int cpu_to_queue_index(unsigned int nr_queues, const int cpu)
> > > +static int cpu_to_queue_index(st
nce, race, religion, or sexual identity and orientation.
+our community a harassment-free experience for everyone.
Our Standards
=
Acked-by: Bart Van Assche
On Mon, 2018-11-05 at 23:14 +0100, Rasmus Villemoes wrote:
> Won't that pessimize the cases where gfp is a constant to actually do
> the table lookup, and add 16 bytes to every translation unit?
>
> Another option is to add a fake KMALLOC_DMA_RECLAIM so the
> kmalloc_caches[] array has size 4, the
On Mon, 2018-11-05 at 14:48 -0800, Alexander Duyck wrote:
> On Mon, Nov 5, 2018 at 2:41 PM Bart Van Assche wrote:
> > How about this version, still untested? My compiler is able to evaluate
> > the switch expression if the argument is constant.
> >
> >
On Mon, 2018-11-05 at 16:11 -0800, Alexander Duyck wrote:
> If we really don't care then why even bother with the switch statement
> anyway? It seems like you could just do one ternary operator and be
> done with it. Basically all you need is:
> return (defined(CONFIG_ZONE_DMA) && (flags & __GFP_DM
On Tue, 2018-11-06 at 09:20 -0800, Alexander Duyck wrote:
> On Mon, Nov 5, 2018 at 4:32 PM Bart Van Assche wrote:
> >
> > On Mon, 2018-11-05 at 16:11 -0800, Alexander Duyck wrote:
> > > If we really don't care then why even bother with the switch statement
> >
On 11/7/18 4:24 PM, kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-7):
commit: 1431aa42b3afc1dd50b292abcc68ccdc3193da63 ("drivers/base: Verify struct
device locking requirements at runtime")
https://github.com/bvanassche/linux for-next
in testcase: boot
on test
+ rename __wait_event_lock_irq_timeout() to make it accept
'state' as a parameter.
Fixes: 00d909a107 ("scsi: target: Make the session shutdown code also wait for
commands that are being aborted")
Cc: Bart Van Assche
Cc: Mike Christie
Cc: Hannes Reinecke
Cc: Christoph Hellwi
On Mon, 2018-10-15 at 11:25 +0800, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 7618616fcdf8a5de9f3dc45fc6281ebd0663bd8a ("sd: Rely on the driver
> core for asynchronous probing")
> https://github.com/bvanassche/linux for-next
>
> in testcase: s
This patch suppresses the following sparse warning:
./include/linux/slab.h:332:43: warning: dubious: x & !y
Fixes: 1291523f2c1d ("mm, slab/slub: introduce kmalloc-reclaimable caches")
Cc: Vlastimil Babka
Cc: Mel Gorman
Cc: Christoph Lameter
Cc: Roman Gushchin
Signed-off-by: B
On Mon, 2018-11-05 at 13:13 -0800, Andrew Morton wrote:
> On Mon, 5 Nov 2018 12:40:00 -0800 Bart Van Assche wrote:
>
> > This patch suppresses the following sparse warning:
> >
> > ./include/linux/slab.h:332:43: warning: dubious: x & !y
> >
> >
these patches for the upstream kernel.
Thanks,
Bart.
Bart Van Assche (3):
kernel/workqueue: Remove lockdep annotation from __flush_work()
kernel/workqueue: Surround work execution with shared lock annotations
kernel/workqueue: Suppress a false positive lockdep complaint
include/linux
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: Johannes Berg
Cc: Christoph Hellwig
Cc: Sagi Grimberg
Signed-off-by: Bart Van Assche
---
include/linu
annotation from __flush_work() because start_flush_work()
already has such an annotation.
Fixes: 87915adc3f0a ("workqueue: re-add lockdep dependencies for flushing")
Cc: Johannes Berg
Cc: Christoph Hellwig
Cc: Sagi Grimberg
Signed-off-by: Bart Van Assche
---
kernel/workqueue.c | 5 -
1 fi
Surround execution of work with a shared lockdep annotation because multiple
work items associated with a work queue may execute concurrently.
Cc: Johannes Berg
Cc: Tejun Heo
Cc: Christoph Hellwig
Cc: Sagi Grimberg
Signed-off-by: Bart Van Assche
---
kernel/workqueue.c | 17
On Thu, 2018-10-25 at 17:27 +0200, Johannes Berg wrote:
> > In my tests with kernel v4.19 I noticed that several new false positive
> > reports were generated by the workqueue lockdep annotations. This patch
> > series addresses one of these false positives.
>
> I tried my best to explain why they
On Thu, 2018-10-25 at 17:34 +0200, Johannes Berg wrote:
> On Thu, 2018-10-25 at 15:05 +0000, Bart Van Assche wrote:
>
> > @@ -2889,7 +2893,7 @@ static bool start_flush_work(struct work_struct
> > *work, struct wq_barrier *barr,
> > * workqueues the deadlock happens
On Thu, 2018-10-25 at 17:31 +0200, Johannes Berg wrote:
> > Remove
> > the lockdep annotation from __flush_work() because start_flush_work()
> > already has such an annotation.
>
> This part at least isn't true, there's no annotation on the work
> *struct*, only one on the work *queue*.
You are r
On Thu, 2018-10-25 at 19:02 +0200, Johannes Berg wrote:
> On Thu, 2018-10-25 at 15:05 +0000, Bart Van Assche wrote:
> > It can happen that the direct I/O queue creates and destroys an empty
> > workqueue from inside a work function.
>
> So, thinking about this more, can y
On Thu, 2018-10-25 at 18:53 +0200, Johannes Berg wrote:
> On Thu, 2018-10-25 at 15:05 +0000, Bart Van Assche wrote:
> > Surround execution of work with a shared lockdep annotation because multiple
> > work items associated with a work queue may execute concurrently.
>
> Hm
On Thu, 2018-10-25 at 21:51 +0200, Johannes Berg wrote:
> [ ... ]
> diff --git a/fs/direct-io.c b/fs/direct-io.c
> index 093fb54cd316..9ef33d6cba56 100644
> --- a/fs/direct-io.c
> +++ b/fs/direct-io.c
> @@ -629,9 +629,16 @@ int sb_init_dio_done_wq(struct super_block *sb)
>* This has to be a
() is neither, I think the word "manually" should
not be used in the comment block above that function. But since the rest of
this patch looks fine to me, feel free to add:
Reviewed-by: Bart Van Assche
On Mon, 2018-10-15 at 08:09 -0700, Alexander Duyck wrote:
> +static void __driver_attach_async_helper(void *_dev, async_cookie_t cookie)
> +{
> + struct device *dev = _dev;
> +
> + __device_driver_lock(dev, dev->parent);
> +
> + /*
> + * If someone attempted to bind a driver either
On Thu, 2018-10-18 at 12:38 -0700, Alexander Duyck wrote:
> Basically if somebody loads a driver the dev->driver becomes set. If a
> driver is removed it will clear dev->driver and set driver_data to
> 0/NULL. That is what I am using as a mutex to track it in conjunction
> with the device mutex.
On 10/18/18 7:20 PM, Alexander Duyck wrote:
I see what you are talking about now. Actually I think this was an
existing issue before my patch even came into play. Basically the code
as it currently stands is device specific in terms of the attach and
release code.
I wonder if we shouldn't have t
a/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
Fixes: 87915adc3f0a ("workqueue: re-add lockdep dependencies for flushing")
Cc: Johannes Berg
Cc: Tejun Heo
Cc: Christoph He
On Mon, 2018-10-22 at 22:28 +0200, Johannes Berg wrote:
> The lockdep report even more or less tells you what's going on. Perhaps
> we need to find a way to make lockdep not print "lock()" but "start()"
> or "flush()" for work items ... but if you read it this way, you see:
>
> CPU0
On Mon, 2018-10-22 at 23:04 +0200, Johannes Berg wrote:
> When lockdep was added, the networking socket locks also were (mostly)
> fine, recursion there only happened on different types of sockets. Yet,
> lockdep did in fact report issues with it, because originally they
> weren't split into differ
On Mon, 2018-10-22 at 22:14 +0200, Johannes Berg wrote:
> I must also say that I'm disappointed you'd try to do things this way.
> I'd be (have been?) willing to actually help you understand the problem
> and add the annotations, but rather than answer my question ("where do I
> find the right git
On 10/22/18 2:04 PM, Johannes Berg wrote:
On Mon, 2018-10-22 at 13:54 -0700, Bart Van Assche wrote:
The code in the column with label "CPU0" is code called by
do_blockdev_direct_IO().
From the body of that function:
/* will be released by direct
On 9/11/22 00:10, Yanjun Zhu wrote:
I also implemented a workqueue for rxe. IMO, can we add a variable to
decide to use tasklet or workqueue?
If user prefer using tasklet, he can set the variable to use
tasklet. And the default is tasklet. Set the variable to another
value to use workqueue.
I'
On 4/5/21 11:39 PM, luojiaxing wrote:
On 2021/4/3 0:01, Bart Van Assche wrote:
On 4/2/21 2:08 AM, Luo Jiaxing wrote:
#define AAP1_MEMMAP(r, c) \
- (*(u32 *)((u8*)pm8001_ha->memoryMap.region[AAP1].virt_ptr + (r)
* 32 \
+ (*(u32 *)((u8 *)pm8001_ha->memoryMap.region[AAP1].virt_pt
On 4/8/21 4:31 AM, Wang Wensheng wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: db7683d7deb2 ("IB/srpt: Fix login-related race conditions")
> Reported-by: Hulk Robot
> Signed-off-by: Wang Wensheng
> ---
>
On 12/08/14 17:49, Jens Axboe wrote:
> On 12/08/2014 07:55 AM, Bart Van Assche wrote:
>> diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
>> index 67ab88b..e88af88 100644
>> --- a/block/blk-mq-tag.c
>> +++ b/block/blk-mq-tag.c
>> @@ -256,6 +256,8 @@ static in
Hello,
While testing the SRP initiator multichannel patches that are present in
Linus' tree and that will be included in kernel 3.19 I came up with
several blk-mq patches. Some of these patches fix bugs I encountered
while running SRP tests; other patches are the result of source reading.
As
[] deactivate_super+0x4e/0x70
[] cleanup_mnt+0x43/0x90
[] __cleanup_mnt+0x12/0x20
[] task_work_run+0xac/0xe0
[] do_notify_resume+0x61/0xa0
[] int_signal+0x12/0x17
Signed-off-by: Bart Van Assche
Cc: Christoph Hellwig
Cc: Robert Elliott
Cc: Ming Lei
Cc: Alexander Gordeev
Cc: # v3.13
the store
operations preceding clear_bit_unlock(). However,
clear_bit_unlock() does not prevent that the wait lists are examined
before that the tag bit is cleared. Hence the addition of a memory
barrier between clear_bit() and the wait list examination.
Signed-off-by: Bart Van Assche
Cc: Christo
do_blockdev_direct_IO+0x1dc8/0x2da0
__blockdev_direct_IO+0x47/0x50
blkdev_direct_IO+0x49/0x50
generic_file_read_iter+0x546/0x610
blkdev_read_iter+0x32/0x40
aio_run_iocb+0x1f8/0x400
do_io_submit+0x121/0x490
SyS_io_submit+0xb/0x10
system_call_fastpath+0x12/0x17
Signed-off-by: Bart Van Assche
Cc
ocket.
Signed-off-by: Bart Van Assche
Reviewed-by: Sagi Grimberg
Cc: Jens Axboe
Cc: Christoph Hellwig
Cc: Ming Lei
Cc: Alexander Gordeev
---
block/blk-mq-cpumap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c
index 10
Remove a superfluous finish_wait() call. Convert the two bt_wait_ptr()
calls into a single call.
Signed-off-by: Bart Van Assche
Cc: Christoph Hellwig
Cc: Robert Elliott
Cc: Ming Lei
Cc: Alexander Gordeev
---
block/blk-mq-tag.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff
wrap-around will occur. Avoid this by introducing an additional
local variable.
Signed-off-by: Bart Van Assche
Cc: Christoph Hellwig
Cc: Robert Elliott
Cc: Ming Lei
Cc: Alexander Gordeev
Cc: # v3.13+
---
block/blk-mq-tag.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff
On 12/02/14 17:35, Sabrina Dubroca wrote:
> @@ -3751,10 +3753,8 @@ void e1000_update_stats(struct e1000_adapter *adapter)
> * @irq: interrupt number
> * @data: pointer to a network interface device structure
> **/
> -static irqreturn_t e1000_intr(int irq, void *data)
> +static irqreturn_t __e
On 11/06/14 14:41, Bart Van Assche wrote:
With kernel 3.18-rc3 and with can_queue=62 I can trigger a hang in
bt_get() easily.
(once more replying to my own e-mail)
Hello Jens,
Finally I found the time to look further into this. The patch below
seems to be sufficient to prevent this hang
messages. For more
information about the GNU error message format, see also
https://www.gnu.org/prep/standards/html_node/Errors.html.
Signed-off-by: Bart Van Assche
Cc: Randy Dunlap
Cc: Johannes Berg
---
scripts/kernel-doc | 38 +++---
1 file changed, 19
On 01/16/15 12:20, Nicholas Mc Guire wrote:
> Signed-off-by: Nicholas Mc Guire
> ---
>
> Patch is against 3.19.0-rc3 -next-20150109
>
> Patch was compiletested only with x86_64_defconfig +
> CONFIG_TARGET_CORE=m, CONFIG_INFINIBAND=m, CONFIG_INFINIBAND_SRPT=m
>
> drivers/infiniband/ulp/srpt/ib_
[scsi_mod]
[] scsi_remove_host+0x86/0x140 [scsi_mod]
[] srp_remove_work+0x9b/0x210 [ib_srp]
[] process_one_work+0x1d8/0x780
[] worker_thread+0x11b/0x460
[] kthread+0xef/0x110
[] ret_from_fork+0x7c/0xb0
Signed-off-by: Bart Van Assche
Cc: Ming Lei
Cc: Sasha Levin
Cc: Christoph Hellwig
---
On 04/05/15 14:06, Julia Lawall wrote:
Return a negative error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
{file}:\$.:
warning:/g;s/Warning(\${file}):/\${file}:1:
warning:/g;s/Info(\${file}:\$.):/\${file}:\$.: info:/g' scripts/kernel-doc
Signed-off-by: Bart Van Assche
Cc: Johannes Berg
---
scripts/kernel-doc | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
On 06/22/15 21:41, Vaishali Thakkar wrote:
if (!slot || slot > 16) {
mad->mad_hdr.status
- = __constant_cpu_to_be16(DM_MAD_STATUS_INVALID_FIELD);
+ = cpu_to_be16(DM_MAD_STATUS_INVALID_FIELD);
return;
}
W
,
replace __constant_cpu_to_be{16,32,64} with cpu_to_be{16,32,64}
with the goal of getting rid of the definitions of
__constant_cpu_to_be{16,32,64} completely.
Reviewed-by: Bart Van Assche
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
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 Wed, 2018-02-28 at 16:55 +0800, Jianchao Wang wrote:
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index a86df9c..6fa7b0c 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -191,7 +191,8 @@ static void __scsi_queue_insert(struct scsi_cmnd *cmd,
> in
On Thu, 2018-03-01 at 09:57 +0800, jianchao.wang wrote:
> On 03/01/2018 01:52 AM, Bart Van Assche wrote:
> > On Wed, 2018-02-28 at 16:55 +0800, Jianchao Wang wrote:
> > > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> > > index a86df9c..6fa7b0c 1006
On Mon, 2017-06-05 at 17:37 +0800, Ganesh Mahendran wrote:
> In android system, when there are lots of threads running. Thread A
> holding *host_busy* count is easily to be preempted, and if at the
> same time, thread B set *host_blocked*, then all other threads will
> be io blocked.
Hello Ganesh,
On Sun, 2018-04-01 at 14:27 -0400, Wakko Warner wrote:
> Wakko Warner wrote:
> > Wakko Warner wrote:
> > > I tested 4.14.32 last night with the same oops. 4.9.91 works fine.
> > > From the initiator, if I do cat /dev/sr1 > /dev/null it works. If I mount
> > > /dev/sr1 and then do find -type f | x
On Wed, 2018-03-28 at 12:15 +0200, bige...@linutronix.de wrote:
> On 2018-03-26 11:13:59 [-0400], Steven Rostedt wrote:
> > > diff --git a/drivers/target/target_core_tmr.c
> > > b/drivers/target/target_core_tmr.c
> > > index 9c7bc1ca341a..3d35dad1de2c 100644
> > > --- a/drivers/target/target_core_
On 03/28/18 08:14, bige...@linutronix.de wrote:
On 2018-03-28 15:05:41 [+], Bart Van Assche wrote:
The names of the two functions touched by patch 1/2 start with a double
underscore. That by itself is already a hint that these should be called with
a lock held (I know that this is not a
On Wed, 2018-03-28 at 17:41 +0100, Colin King wrote:
> From: Colin Ian King
>
> The first assignment to shost->use_blk_mq is redundant as it is
> overwritten by the following statement. Remove this redundant code.
>
> Detected by CoverityScan, CID#1466993 ("Unused valu
On Thu, 2018-03-29 at 10:07 -0600, Logan Gunthorpe wrote:
> + ret = fc_dma_map_sg(fod->tgtport->dev, sg, nent,
> + ((fod->io_dir == NVMET_FCP_WRITE) ?
> + DMA_FROM_DEVICE : DMA_TO_DEVICE));
> + /* note: write from i
On Thu, 2018-04-26 at 11:19 -0700, Greg Thelen wrote:
> INFINIBAND_SRP code depends on INFINIBAND_ADDR_TRANS provided symbols.
> So declare the kconfig dependency. This is necessary to allow for
> enabling INFINIBAND without INFINIBAND_ADDR_TRANS.
Reviewed-by: Bart Van Assche
On Thu, 2018-04-26 at 11:19 -0700, Greg Thelen wrote:
> Allow INFINIBAND without INFINIBAND_ADDR_TRANS because fuzzing has been
> finding fair number of CM bugs. So provide option to disable it.
Reviewed-by: Bart Van Assche
On Thu, 2018-04-26 at 11:19 -0700, Greg Thelen wrote:
> INFINIBAND_SRPT code depends on INFINIBAND_ADDR_TRANS provided symbols.
> So declare the kconfig dependency. This is necessary to allow for
> enabling INFINIBAND without INFINIBAND_ADDR_TRANS.
Reviewed-by: Bart Van Assche
On Tue, 2018-04-24 at 16:49 +0200, Steffen Maier wrote:
> The object life cycle seems to be:
>
> (1) blk_alloc_queue() also creates gendisk kobj
I think this is a misinterpretation. blk_alloc_queue_node() initializes the
request queue kobj as follows:
kobject_init(&q->kobj, &blk_queue_kt
On Tue, 2018-05-29 at 11:17 -0700, Evan Green wrote:
> This change enables writing to fields of the config descriptor
> via sysfs. It can be used to provision an unprovisioned UFS
> device, or reprovision an unlocked device.
>
> Signed-off-by: Evan Green
> ---
> drivers/scsi/ufs/ufs-sysfs.c | 64
On Tue, 2018-05-15 at 12:54 +1000, Michael Ellerman wrote:
> Bart Van Assche writes:
> >
> > +---
> > +| arch |status|
> > +---
> > +| alpha: | ok |
> > +| arc: |
used
the __deadline member to encode both the generation and state information.
Bart Van Assche (2):
arch/*: Add CONFIG_ARCH_HAVE_CMPXCHG64
blk-mq: Rework blk-mq timeout handling again
.../features/locking/cmpxchg64/arch-support.txt| 33
arch/Kconfig
to two functions - one for the
legacy block layer and one for blk-mq.
Signed-off-by: Bart Van Assche
Cc: Tejun Heo
Cc: Christoph Hellwig
Cc: Jianchao Wang
Cc: Ming Lei
Cc: Sebastian Ott
Cc: Sagi Grimberg
Cc: Israel Rukshin ,
Cc: Max Gurtovoy
---
block/blk-core.c | 6 --
block/
ct request and used
the __deadline member to encode both the generation and state information.
Bart Van Assche (2):
arch/*: Add CONFIG_ARCH_HAVE_CMPXCHG64
blk-mq: Rework blk-mq timeout handling again
.../features/locking/cmpxchg64/arch-support.txt| 31
ar
The next patch in this series introduces a call to cmpxchg64()
in the block layer core for those architectures on which this
functionality is available. Make it possible to test whether
cmpxchg64() is available by introducing CONFIG_ARCH_HAVE_CMPXCHG64.
Signed-off-by: Bart Van Assche
Cc: Catalin
to two functions - one for the
legacy block layer and one for blk-mq.
Signed-off-by: Bart Van Assche
Cc: Tejun Heo
Cc: Christoph Hellwig
Cc: Jianchao Wang
Cc: Ming Lei
Cc: Sebastian Ott
Cc: Sagi Grimberg
Cc: Israel Rukshin ,
Cc: Max Gurtovoy
---
block/blk-core.c | 6 --
block/
The next patch in this series introduces a call to cmpxchg64()
in the block layer core for those architectures on which this
functionality is available. Make it possible to test whether
cmpxchg64() is available by introducing CONFIG_ARCH_HAVE_CMPXCHG64.
Signed-off-by: Bart Van Assche
Cc: Catalin
On Wed, 2018-05-16 at 22:05 +0900, Tetsuo Handa wrote:
> One ore more threads are waiting for q->mq_freeze_depth to become 0. But the
> thread who incremented q->mq_freeze_depth at blk_freeze_queue_start(q) from
> blk_freeze_queue() is waiting at blk_mq_freeze_queue_wait(). Therefore,
> atomic_read
On Wed, 2018-05-16 at 17:16 +0200, Dmitry Vyukov wrote:
> On Wed, May 16, 2018 at 4:56 PM, Bart Van Assche
> wrote:
> > On Wed, 2018-05-16 at 22:05 +0900, Tetsuo Handa wrote:
> > > diff --git a/block/blk-core.c b/block/blk-core.c
> > > index 85909b4..59e2496 10064
On Wed, 2018-05-16 at 14:51 +0200, Christoph Hellwig wrote:
> I've been looking at this carefully, and I don't think we need cmpxchg64
> at all, and we don't need anywhere near as many cmpxchg operations either.
>
> The only reason to include the deadline in the atomic operation is the
> blk_abort
On Wed, 2018-05-16 at 18:24 +0200, h...@lst.de wrote:
> On Wed, May 16, 2018 at 04:17:42PM +0000, Bart Van Assche wrote:
> > There is another reason the deadline is included in the atomic operation,
> > namely to handle races between the BLK_EH_RESET_TIMER case in
> >
On Wed, 2018-05-16 at 19:31 +0200, h...@lst.de wrote:
> On Wed, May 16, 2018 at 04:47:54PM +0000, Bart Van Assche wrote:
> > I think your patch changes the order of changing the request state and
> > calling mod_timer(). In my patch the request state and the deadline are
> &
On Tue, 2018-04-24 at 19:10 +0200, Paul Menzel wrote:
> Please find the configuration file attached. The log only has
> `initcall_debug no_console_suspend` added.
What I was looking for in the .config is the following:
CONFIG_SCSI_MQ_DEFAULT=y
Can you also provide the disassembly output for blk_
On Tue, 2018-04-24 at 19:37 +0200, Paul Menzel wrote:
> On 04/24/18 19:31, Bart Van Assche wrote:
> Here it is, pasted as citation, as otherwise Thunderbird would wrap the
> line.
>
> > (gdb) disas blk_set_runtime_active
> > Dump of assembler code for functio
On Tue, 2018-04-24 at 23:04 +0200, Paul Menzel wrote:
> I applied your change, and rebuilt the Linux kernel. Unfortunately, it
> looks like, it didn’t make a difference.
In that case I don't know what is causing the failure. Can you run a bisect
to determine which commit introduced this regressio
On Wed, 2018-04-25 at 07:37 +0200, Paul Menzel wrote:
> Am 24.04.2018 um 23:17 schrieb Bart Van Assche:
> > On Tue, 2018-04-24 at 23:04 +0200, Paul Menzel wrote:
> > > I applied your change, and rebuilt the Linux kernel. Unfortunately, it
> > > looks like, it didn’t mak
On Wed, 2018-04-25 at 15:34 -0700, Greg Thelen wrote:
> Allow INFINIBAND without INFINIBAND_ADDR_TRANS because fuzzing has been
> finding fair number of CM bugs. So provide option to disable it.
>
> Signed-off-by: Greg Thelen
> Cc: Tarick Bedeir
> ---
> drivers/infiniband/Kconfig | 5 -
>
On Thu, 2019-02-28 at 15:38 -0700, Shaobo He wrote:
> In function `c4iw_dealloc_mw`, variable mhp's value is printed after
> freed, which triggers undefined behavior according to this post:
> https://trust-in-soft.com/dangling-pointer-indeterminate/.
>
> This commit fixes it by swapping the order
On Thu, 2019-02-28 at 16:18 -0700, Shaobo He wrote:
> I can't afford a pdf version of the C standard. So I looked at the draft
> version
> used in the link I put in the commit message. It says (in 6.2.4:2),
>
> ```
> The lifetime of an object is the portion of program execution during which
> s
Change "execuing" into "executing" and "guarnateed" into "guaranteed".
Cc: Lai Jiangshan
Signed-off-by: Bart Van Assche
---
kernel/workqueue.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
On Tue, 2019-04-16 at 00:28 -0300, Marcos Paulo de Souza wrote:
> * @set_flags: flags of @set
The above does not look very helpful to me ...
Bart.
On Wed, 2019-04-24 at 22:51 +0200, Pavel Machek wrote:
> Unfortunately, that one does not revert cleanly on top of -next.
Can you try the following:
git revert d16ece577bf2cee7f94bab75a0d967bcb89dd2a7 &&
git revert 21e6ba3f0e0257cce1a226c1f15e0a8ba4338ca3
I will see whether I can come up with
On Wed, 2019-04-24 at 12:17 +0200, Pavel Machek wrote:
> On Tue 2019-04-23 07:09:42, Bart Van Assche wrote:
> > 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
On 4/25/19 12:33 AM, Pavel Machek wrote:
> On Wed 2019-04-24 13:56:01, Bart Van Assche wrote:
>> On Wed, 2019-04-24 at 22:51 +0200, Pavel Machek wrote:
>>> Unfortunately, that one does not revert cleanly on top of -next.
>>
>> Can you try t
On Tue, 2019-03-12 at 05:35 +, Jisheng Zhang wrote:
> I got below warning during resume:
>
> [ 673.65] sd 0:0:0:0: [sda] Starting disk
> [ 673.658899] WARNING: CPU: 3 PID: 1039 at blk_clear_pm_only+0x2a/0x30
> [ 673.658902] CPU: 3 PID: 1039 Comm: kworker/u8:49 Not tainted 5.0.0+ #1
> [
On Tue, 2019-03-26 at 08:35 +0800, shenghui wrote:
> My test steps:
> --
> 1) bootup the system, and check the calltrace in dmesg. Just warning and
> ignore it.
> 2) cat /proc/lockdep # everything is well
> 3) rmmod some module which provides lock_class in lockdep
>In my system,
On Tue, 2019-03-26 at 10:44 -0700, Bart Van Assche wrote:
> On Tue, 2019-03-26 at 08:35 +0800, shenghui wrote:
> > My test steps:
> > --
> > 1) bootup the system, and check the calltrace in dmesg. Just warning and
> > ignore it.
> > 2) cat /proc/loc
h due to a NULL pointer dereference, restore the pre-v5.1 behavior.
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: Waiman Long
Cc: shenghui
Reported-by: shenghui
Fixes: a0b0fd53e1e6 ("locking/lockdep: Free lock classes that are no longer in
use") # v5.1-rc1.
Signed-off-by: Bart Van Assche
On 4/2/19 3:45 AM, kernel test robot wrote:
[ 12.540233] WARNING: CPU: 0 PID: 43 at block/blk-core.c:353
blk_cleanup_queue+0xcc/0xe0
Please ignore this kernel test robot report. It applies to a patch that
I sent to the build robot but that was never posted on any mailing list.
Thanks,
Ba
On Mon, 2019-04-01 at 21:29 +0300, Leon Romanovsky wrote:
> On Mon, Apr 01, 2019 at 02:45:54PM -0300, Jason Gunthorpe wrote:
> > On Mon, Apr 01, 2019 at 10:36:05AM -0700, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:e3ecb83e Add linux-nex
On Wed, 2019-04-03 at 13:44 +0100, Will Deacon wrote:
> On Tue, Mar 26, 2019 at 12:59:12PM -0700, Bart Van Assche wrote:
> > Commit a0b0fd53e1e6 ("locking/lockdep: Free lock classes that are no longer
> > in use") changed the behavior of lockdep_free_key_range() from
&g
On Wed, 2019-04-03 at 13:44 +0100, Will Deacon wrote:
> > --- a/kernel/locking/lockdep.c
> > +++ b/kernel/locking/lockdep.c
> > @@ -4689,8 +4689,7 @@ static void free_zapped_rcu(struct rcu_head *ch)
> > return;
> >
> > raw_local_irq_save(flags);
> > - if (!graph_lock())
> > -
_hwframe+0x49/0xbe
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: Waiman Long
Cc: shenghui
Reported-by: shenghui
Fixes: a0b0fd53e1e6 ("locking/lockdep: Free lock classes that are no longer in
use") # v5.1-rc1.
Signed-off-by: Bart Van Assche
---
Changes compared to v1:
- Restored lockdep recurs
On Tue, 2019-04-09 at 10:44 -0400, Alan Stern wrote:
> On Mon, 8 Apr 2019, Martin K. Petersen wrote:
>
> >
> > Alan,
> >
> > > So it looks as though the SCSI subsystem doesn't like to have a reset
> > > handler call scsi_remove_host.
> >
> > Are you talking about a PCI device removal handler o
On 2/25/19 1:37 AM, Johannes Thumshirn wrote:
On 24/02/2019 11:54, Max Gurtovoy wrote:
What is the status of iSCSI/SRP targets in this case ?
iSCSI/SRP passes in the following:
/*
* Use O_DSYNC by default instead of O_SYNC to forgo syncing
* of pure timestamp updates.
*/
flags =
On Mon, 2019-02-25 at 16:38 +0100, Johannes Thumshirn wrote:
> On Mon, Feb 25, 2019 at 06:49:04AM -0800, Bart Van Assche wrote:
> > On 2/25/19 1:37 AM, Johannes Thumshirn wrote:
> > > On 24/02/2019 11:54, Max Gurtovoy wrote:
> > > > What is the status of
401 - 500 of 1594 matches
Mail list logo
