Ping...
Thanks,
Joseph
On 19/7/25 11:03, Joseph Qi wrote:
> Add blkio.throttle.io_service_time and blkio.throttle.io_wait_time to
> get per-cgroup io delay statistics in blk-throttle layer.
> io_service_time represents the time spent after io throttle to io
> completion, while
Now we have counters for wait_time and service_time, so add another
counter for completed ios, then the average latency can be measured.
Signed-off-by: Joseph Qi
---
block/blk-throttle.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/block/blk-throttle.c b
Add another 2 interfaces to stat io throttle information:
blkio.throttle.total_io_queued
blkio.throttle.total_bytes_queued
These interfaces are used for monitoring throttled io/bytes and
analyzing if delay has relations with io throttle.
Signed-off-by: Joseph Qi
---
block/blk-throttle.c
Add blkio.throttle.io_service_time and blkio.throttle.io_wait_time to
get per-cgroup io delay statistics in blk-throttle layer.
io_service_time represents the time spent after io throttle to io
completion, while io_wait_time represents the time spent on throttle
queue.
Signed-off-by: Joseph Qi
On 19/6/5 21:57, Brian Foster wrote:
> On Wed, Jun 05, 2019 at 02:42:27PM +0200, gregkh wrote:
>> On Wed, Jun 05, 2019 at 08:21:44PM +0800, Alvin Zheng wrote:
>>> Hi,
>>> I was using kernel v4.19.48 and found that it cannot pass the generic/538
>>> on xfs. The error output is as follows:
>>
>
For ocfs2 part, node means host in the cluster, not NUMA node.
Thanks,
Joseph
On 18/11/12 10:41, Anshuman Khandual wrote:
> At present there are multiple places where invalid node number is encoded
> as -1. Even though implicitly understood it is always better to have macros
> in there. Replace t
Hi Paolo,
On 18/4/27 01:27, Paolo Valente wrote:
>
>
>> Il giorno 25 apr 2018, alle ore 14:13, Joseph Qi ha
>> scritto:
>>
>> Hi Paolo,
>>
>
> Hi Joseph
>
>> ...
>> Could you run blktrace as well when testing your case? There are seve
Hi Jianchao,
On 18/4/27 10:09, jianchao.wang wrote:
> Hi Tejun and Joseph
>
> On 04/27/2018 02:32 AM, Tejun Heo wrote:
>> Hello,
>>
>> On Tue, Apr 24, 2018 at 02:12:51PM +0200, Paolo Valente wrote:
>>> +Tejun (I guess he might be interested in the results below)
>>
>> Our experiments didn't work
Hi Paolo,
On 18/4/24 20:12, Paolo Valente wrote:
>
>
>> Il giorno 23 apr 2018, alle ore 11:01, Joseph Qi ha
>> scritto:
>>
>>
>>
>> On 18/4/23 15:35, Paolo Valente wrote:
>>>
>>>
>>>> Il giorno 23 apr 2018, alle ore 0
On 18/4/23 15:35, Paolo Valente wrote:
>
>
>> Il giorno 23 apr 2018, alle ore 08:05, Joseph Qi ha
>> scritto:
>>
>> Hi Paolo,
>
> Hi Joseph,
> thanks for chiming in.
>
>> What's your idle and latency config?
>
> I didn't s
Hi Paolo,
What's your idle and latency config?
IMO, io.low will allow others run more bandwidth if cgroup's average
idle time is high or latency is low. In such cases, low limit won't get
guaranteed.
Thanks,
Joseph
On 18/4/22 17:23, Paolo Valente wrote:
> Hi Shaohua, all,
> at last, I started tes
_queue_enter() / blk_queue_exit().
>
> Reported-by: Ming Lei
> Fixes: a063057d7c73 ("block: Fix a race between request queue removal and the
> block cgroup controller")
> Signed-off-by: Bart Van Assche
> Cc: Ming Lei
> Cc: Joseph Qi
I've tested using the followi
Hi Bart,
On 18/4/9 12:47, Bart Van Assche wrote:
> On Sun, 2018-04-08 at 12:21 +0800, Ming Lei wrote:
>> The following kernel oops is triggered by 'removing scsi device' during
>> heavy IO.
>
> Is the below patch sufficient to fix this?
>
> Thanks,
>
> Bart.
>
>
> Subject: blk-mq: Avoid that
Hi Bart,
On 18/4/8 22:50, Bart Van Assche wrote:
> On Sun, 2018-04-08 at 12:21 +0800, Ming Lei wrote:
>> The following kernel oops is triggered by 'removing scsi device' during
>> heavy IO.
>
> How did you trigger this oops?
>
I can reproduce this oops by the following steps:
1) start a fio job
Signed-off-by: Joseph Qi
---
block/blk-cgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index 1c16694..87367d4 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -640,7 +640,7 @@ int blkg_print_stat_bytes(struct
This is because scsi_remove_device() will call blk_cleanup_queue(), and
then all blkgs have been destroyed and root_blkg is NULL.
Thus tg is NULL and trigger NULL pointer dereference when get td from
tg (tg->td).
It seems that we cannot simply move blkcg_exit_queue() up to
blk_cleanup_queue().
Tha
struction (especially
blkg_put()) into blkcg_css_free(), which should be the right way as
discussed.
Fixes: ae1188963611 ("blkcg: consolidate blkg creation in
blkcg_bio_issue_check()")
Reported-by: Jiufei Xue
Signed-off-by: Joseph Qi
Acked-by:
Hello Tejun,
Thanks for your quick response.
On 18/3/14 22:09, Tejun Heo wrote:
> Hello,
>
> On Wed, Mar 14, 2018 at 02:18:04PM +0800, Joseph Qi wrote:
>> Fixes: ae1188963611 ("blkcg: consolidate blkg creation in
>> blkcg_bio_issue_check()")
>>
struction (especially
blkg_put()) into blkcg_css_free(), which should be the right way as
discussed.
Fixes: ae1188963611 ("blkcg: consolidate blkg creation in
blkcg_bio_issue_check()")
Reported-by: Jiufei Xue
Cc: sta...@vger.kernel.org #4.3+
Signed-off-by:
Fine, I will do the corresponding changes and post v5.
Thanks,
Joseph
On 18/3/14 04:19, Tejun Heo wrote:
> Hello, Joseph.
>
> On Mon, Mar 05, 2018 at 11:03:16PM +0800, Joseph Qi wrote:
>> +static void blkg_pd_offline(struct blkcg_gq *blkg)
>> +{
>> +int i;
>&
Hello Tejun,
Could you please help review this version?
Thanks,
Joseph
On 18/3/6 11:53, Joseph Qi wrote:
> We've triggered a WARNING in blk_throtl_bio() when throttling writeback
> io, which complains blkg->refcnt is already 0 when calling blkg_get(),
> and then kernel crashes
blkcg_css_offline(), and move the rest destruction (especially
blkg_put()) into blkcg_css_free(), which should be the right way as
discussed.
Fixes: ae1188963611 ("blkcg: consolidate blkg creation in
blkcg_bio_issue_check()")
Reported-by: Jiufei Xue
Cc: sta...@vger.kernel.org #4.3+
S
blkcg_css_offline(), and move the rest destruction (especially
blkg_put()) into blkcg_css_free(), which should be the right way as
discussed.
Fixes: ae1188963611 ("blkcg: consolidate blkg creation in
blkcg_bio_issue_check()")
Reported-by: Jiufei Xue
Cc: sta...@vger.kernel.org #4.3+
S
On 18/3/5 04:23, Tejun Heo wrote:
> Hello, Joseph.
>
> Sorry about late reply.
>
> On Wed, Feb 28, 2018 at 02:52:10PM +0800, Joseph Qi wrote:
>> In current code, I'm afraid pd_offline_fn() as well as the rest
>> destruction have to be called together und
Hi Tejun,
On 18/2/28 02:33, Tejun Heo wrote:
> Hello, Joseph.
>
> On Sat, Feb 24, 2018 at 09:45:49AM +0800, Joseph Qi wrote:
>>> IIRC, as long as the blkcg and the device are there, the blkgs aren't
>>> gonna be destroyed. So, if you have a ref to the bl
Hi Tejun,
Could you please help take a look at this and give a confirmation?
Thanks,
Joseph
On 18/2/24 09:45, Joseph Qi wrote:
> Hi Tejun,
>
> On 18/2/23 22:23, Tejun Heo wrote:
>> Hello,
>>
>> On Fri, Feb 23, 2018 at 09:56:54AM +0800, xuejiufei wrote:
>>>
Hi Tejun,
On 18/2/23 22:23, Tejun Heo wrote:
> Hello,
>
> On Fri, Feb 23, 2018 at 09:56:54AM +0800, xuejiufei wrote:
>>> On Thu, Feb 22, 2018 at 02:14:34PM +0800, Joseph Qi wrote:
>>>> I still don't get how css_tryget can work here.
>>>>
>>&g
now;
> (6) but unlock internal lock.
>
> This change is safe because only the SCSI core and the NVME core keep
> a reference on a request queue after having called blk_cleanup_queue().
> Neither driver accesses any of the removed data structures between its
> blk_cleanup_queue() an
blk_alloc_queue() call in the driver into a
> blk_alloc_queue_node() call and remove the explicit .queue_lock
> initialization. Additionally, initialize the spin lock that will
> be used as queue lock earlier if necessary.
>
> Reported-by: Joseph Qi
> Signed-off-by: Bart Van Ass
On 18/2/23 09:08, Bart Van Assche wrote:
> Remove the disk, partition and bdi sysfs attributes before cleaning up
> the request queue associated with the disk.
>
> Signed-off-by: Bart Van Assche
> Cc: Minchan Kim
> Cc: Nitin Gupta
> Cc: Sergey Senozhatsky
Looks good.
Reviewed-by: Joseph Qi
On 18/2/23 09:08, Bart Van Assche wrote:
> Remove the disk, partition and bdi sysfs attributes before cleaning up
> the request queue associated with the disk.
>
> Signed-off-by: Bart Van Assche
> Cc: Shaohua Li
Looks good.
Reviewed-by: Joseph Qi
Reinecke
> Cc: Ming Lei
Looks good.
Reviewed-by: Joseph Qi
On 18/2/23 09:08, Bart Van Assche wrote:
> This patch does not change any functionality.
>
> Signed-off-by: Bart Van Assche
> Cc: Christoph Hellwig
> Cc: Joseph Qi
> Cc: Philipp Reisner
> Cc: Ulf Hansson
> Cc: Kees Cook
Looks good.
Reviewed-by: Joseph Qi
On 18/2/23 11:33, Chengguang Xu wrote:
> Hi Tejun,
>
> Sorry for delayed reply, I was on vacation last week.
>
> The problem still exists in current code of 4.16.0-rc2,
> detail test information is below, if further info is needed please let me
> know.
>
> Thanks.
>
That's true, the issue S
Hi Tejun,
Sorry for the delayed reply.
On 18/2/13 01:11, Tejun Heo wrote:
> Hello, Joseph.
>
> On Fri, Feb 09, 2018 at 10:15:19AM +0800, Joseph Qi wrote:
>> IIUC, we have to identify it is in blkcg_css_offline now which will
>> blkg_put. Since percpu_ref_kill_and_confirm
removed data structures between its
> blk_cleanup_queue() and blk_put_queue() calls.
>
> Reported-by: Joseph Qi
> Signed-off-by: Bart Van Assche
> Cc: Jan Kara
> ---
> block/blk-core.c | 31 +++
> block/blk-sysfs.c | 7 ---
>
Hi Tejun,
On 18/2/8 23:23, Tejun Heo wrote:
> Hello, Joseph.
>
> On Thu, Feb 08, 2018 at 10:29:43AM +0800, Joseph Qi wrote:
>> So you mean checking css->refcnt to prevent the further use of
>> blkg_get? I think it makes sense.
>
> Yes.
>
>> IMO, we sh
Hi Tejun,
Thanks very much for reviewing this patch.
On 18/2/8 05:38, Tejun Heo wrote:
> Hello, Joseph.
>
> On Wed, Feb 07, 2018 at 04:40:02PM +0800, Joseph Qi wrote:
>> writeback kworker
>> blkcg_bio_issue_check
>> rcu_read_lock
>> bl
188963611 ("blkcg: consolidate blkg creation in
blkcg_bio_issue_check()")
Reported-by: Jiufei Xue
Signed-off-by: Joseph Qi
Cc: sta...@vger.kernel.org
---
block/blk-cgroup.c | 2 +-
block/blk-throttle.c | 30 ++
block/cfq-iosched.c| 33 +
sue_check()")
Reported-by: Jiufei Xue
Signed-off-by: Joseph Qi
CC: sta...@vger.kernel.org
---
block/blk-cgroup.c | 2 +-
block/blk-throttle.c | 29 +
block/cfq-iosched.c| 33 +++--
include/linux/blk-cgroup.h | 27 ++
Hi Bart,
On 18/2/3 00:21, Bart Van Assche wrote:
> On Fri, 2018-02-02 at 09:02 +0800, Joseph Qi wrote:
>> We triggered this race when using single queue. I'm not sure if it
>> exists in multi-queue.
>
> Regarding the races between modifying the queue_lock pointer and
Hi Bart,
On 18/2/2 00:16, Bart Van Assche wrote:
> On Thu, 2018-02-01 at 09:53 +0800, Joseph Qi wrote:
>> I'm afraid the risk may also exist in blk_cleanup_queue, which will
>> set queue_lock to to the default internal lock.
>>
>> spin_lock_irq(lock);
>>
Hi Bart,
On 18/2/1 07:53, Bart Van Assche wrote:
> Initialize the request queue lock earlier such that the following
> race can no longer occur:
>
> blk_init_queue_node blkcg_print_blkgs
> blk_alloc_queue_node (1)
> q->queue_lock = &q->__queue_lock (2)
> blkcg_init_queue
Hi Bart,
Thanks very much for the quick response.
On 18/1/31 05:19, Bart Van Assche wrote:
> On Tue, 2018-01-30 at 19:21 +0800, Joseph Qi wrote:
>> Hi Jens and Folks,
>>
>> Recently we've gotten a hard LOCKUP issue. After investigating the issue
>> we've fou
Hi Jens and Folks,
Recently we've gotten a hard LOCKUP issue. After investigating the issue
we've found a race between blk_init_queue_node and blkcg_print_blkgs.
The race is described below.
blk_init_queue_node blkcg_print_blkgs
blk_alloc_queue_node (1)
q->queue_lock = &q->_
o
low limit not guaranteed most of time.
Fix this case by moving check logic down, in which we are ready to issue
io to lower layer.
Signed-off-by: Joseph Qi
Reviewed-by: Jiufei Xue
---
block/blk-throttle.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/
tg in throtl_select_dispatch is used first and then do check. Since tg
may be NULL, it has potential NULL pointer dereference risk. So fix it.
Signed-off-by: Joseph Qi
Reviewed-by: Jiufei Xue
---
block/blk-throttle.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/block
x27;t have low limit, ignore checking it
and just depend on child's decision.
Note that we do not support only configure intermediate nodes.
Signed-off-by: Joseph Qi
Reviewed-by: Jiufei Xue
---
block/blk-throttle.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/block/blk-throttle
Hi Mike,
On 18/1/19 11:29, Mike Snitzer wrote:
> On Thu, Jan 18 2018 at 10:09pm -0500,
> Joseph Qi wrote:
>
>> From: Joseph Qi
>>
>> DM device sets QUEUE_FLAG_NONROT after the queue is registered. That is
>> to mean, the previous initialization in blk_throtl_r
From: Joseph Qi
DM device sets QUEUE_FLAG_NONROT after the queue is registered. That is
to mean, the previous initialization in blk_throtl_register_queue is
wrong in this case.
Fix it by checking and then updating the info during root tg
initialization as we don't have a better choice.
S
Sure, I will resend it.
Thanks.
Joseph
On 18/1/19 10:52, Jens Axboe wrote:
> On 1/18/18 7:11 PM, Joseph Qi wrote:
>> Hi Jens,
>> Could you please pick the two pending patches for 4.16?
>> They all have been reviewed by Shaohua.
>
> Sorry, I guess I forgot about t
Hi Jens,
Could you please pick the two pending patches for 4.16?
They all have been reviewed by Shaohua.
Thanks,
Joseph
On 18/1/8 20:05, Joseph Qi wrote:
> A polite ping for the two pending patches...
>
> Thanks,
> Joseph
>
> On 17/11/24 13:13, Jens Axboe wrote:
>>
A polite ping for the two pending patches...
Thanks,
Joseph
On 17/11/24 13:13, Jens Axboe wrote:
> On 11/23/2017 06:31 PM, Joseph Qi wrote:
>> Hi Jens,
>> Could you please give your advice for the two patches or pick them up if
>> you think they are good?
>
>
From: Joseph Qi
Currently downgrade/upgrade check is done when io firstly comes to block
throttle layer. In case of writeback, a large number of ios will firstly
be throttled in throttle queue and then dispatched when timer kicked,
which won't be checked because REQ_THROTTLED is set. This
From: Joseph Qi
Currently if we only configure leaf nodes, downgrade check won't
function properly as parent's last low overflow time is meaningless and
always returns now, thus it will be treated always run above low limit
and doesn't have to do downgrade.
In this case, since
From: Joseph Qi
tg in throtl_select_dispatch is used first and then do check. Since tg
may be NULL, it has potential NULL pointer dereference risk. So fix it.
Signed-off-by: Joseph Qi
---
block/blk-throttle.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/block/blk
Hi Paolo,
On 17/12/27 20:36, Paolo Valente wrote:
>
>
>> Il giorno 25 dic 2017, alle ore 03:44, xuejiufei ha
>> scritto:
>>
>> Hi all,
>>
>> Cgroup writeback is supported since v4.2. I found there exists a
>> problem in the following case.
>>
>> A cgroup may send both buffer and direct/sync IO
Hi Jens,
Could you please give your advice for the two patches or pick them up if
you think they are good?
Thanks,
Joseph
On 17/11/21 09:38, Joseph Qi wrote:
> From: Joseph Qi
>
> In mixed read/write workload on SSD, write latency is much lower than
> read. But now we only trac
From: Joseph Qi
DM device sets QUEUE_FLAG_NONROT after the queue is registered. That is
to mean, the previous initialization in blk_throtl_register_queue is
wrong in this case.
Fix it by checking and then updating the info during root tg
initialization as we don't have a better choice.
S
From: Joseph Qi
In mixed read/write workload on SSD, write latency is much lower than
read. But now we only track and record read latency and then use it as
threshold base for both read and write io latency accounting. As a
result, write io latency will always be considered as good and
On 17/11/21 01:15, Shaohua Li wrote:
> On Mon, Nov 20, 2017 at 10:00:27AM +0800, Joseph Qi wrote:
>> From: Joseph Qi
>>
>> dm device set QUEUE_FLAG_NONROT in resume, which is after register
>> queue. That is to mean, the previous initialization in
>> blk_throt
Hi Mike,
On 17/11/21 05:02, Mike Snitzer wrote:
> On Sun, Nov 19, 2017 at 9:00 PM, Joseph Qi wrote:
>> From: Joseph Qi
>>
>> dm device set QUEUE_FLAG_NONROT in resume, which is after register
>> queue. That is to mean, the previous initialization in
>> blk_throt
From: Joseph Qi
dm device set QUEUE_FLAG_NONROT in resume, which is after register
queue. That is to mean, the previous initialization in
blk_throtl_register_queue is wrong in this case.
Fix it by checking and then updating the info during root tg
initialization as we don't have a better c
From: Joseph Qi
In mixed read/write workload on SSD, write latency is much lower than
read. But now we only track and record read latency and then use it as
threshold base for both read and write io latency accounting. As a
result, write io latency will always be considered as good and
From: Joseph Qi
dm device set QUEUE_FLAG_NONROT in resume, which is after register
queue. That is to mean, the previous initialization in
blk_throtl_register_queue is wrong in this case.
Fix it by checking and then updating the info during root tg
initialization as we don't have a better c
Hi Jens,
Could you please pick this patch?
Thanks,
Joseph
On 17/10/13 01:13, Shaohua Li wrote:
> On Thu, Oct 12, 2017 at 05:15:46PM +0800, Joseph Qi wrote:
>> From: Joseph Qi
>>
>> In mixed read/write workload on SSD, write latency is much lower than
>> read. But n
From: Joseph Qi
In mixed read/write workload on SSD, write latency is much lower than
read. But now we only track and record read latency and then use it as
threshold base for both read and write io latency accounting. As a
result, write io latency will always be considered as good and
On 17/10/12 03:21, Shaohua Li wrote:
> On Wed, Oct 11, 2017 at 05:53:34PM +0800, Joseph Qi wrote:
>> From: Joseph Qi
>>
>> In mixed read/write workload on SSD, write latency is much lower than
>> read. But now we only track and record read latency and then use it as
From: Joseph Qi
In mixed read/write workload on SSD, write latency is much lower than
read. But now we only track and record read latency and then use it as
threshold base for both read and write io latency accounting. As a
result, write io latency will always be considered as good and
From: Joseph Qi
There is a case which will lead to io stall. The case is described as
follows.
/test1
|-subtest1
/test2
|-subtest2
And subtest1 and subtest2 each has 32 queued bios already.
Now upgrade to max. In throtl_upgrade_state, it will try to dispatch
bios as follows:
1) tg=subtest1
On 17/9/28 11:48, Joseph Qi wrote:
> Hi Shahua,
>
> On 17/9/28 05:38, Shaohua Li wrote:
>> On Tue, Sep 26, 2017 at 11:16:05AM +0800, Joseph Qi wrote:
>>>
>>>
>>> On 17/9/26 10:48, Shaohua Li wrote:
>>>> On Tue, Sep 26, 2017 at 09:06:57AM +0
Hi Shahua,
On 17/9/28 05:38, Shaohua Li wrote:
> On Tue, Sep 26, 2017 at 11:16:05AM +0800, Joseph Qi wrote:
>>
>>
>> On 17/9/26 10:48, Shaohua Li wrote:
>>> On Tue, Sep 26, 2017 at 09:06:57AM +0800, Joseph Qi wrote:
>>>> Hi Shaohua,
>>>>
>
On 17/9/26 10:48, Shaohua Li wrote:
> On Tue, Sep 26, 2017 at 09:06:57AM +0800, Joseph Qi wrote:
>> Hi Shaohua,
>>
>> On 17/9/26 01:22, Shaohua Li wrote:
>>> On Mon, Sep 25, 2017 at 06:46:42PM +0800, Joseph Qi wrote:
>>>> From: Joseph Qi
>>
Hi Shaohua,
On 17/9/26 01:22, Shaohua Li wrote:
> On Mon, Sep 25, 2017 at 06:46:42PM +0800, Joseph Qi wrote:
>> From: Joseph Qi
>>
>> Currently it will try to dispatch bio in throtl_upgrade_state. This may
>> lead to io stall in the following case.
>> Say
From: Joseph Qi
Currently it will try to dispatch bio in throtl_upgrade_state. This may
lead to io stall in the following case.
Say the hierarchy is like:
/-test1
|-subtest1
and subtest1 has 32 queued bios now.
throtl_pending_timer_fnthrotl_upgrade_state
Hi Shaohua,
On 17/9/6 05:02, Shaohua Li wrote:
> On Thu, Aug 31, 2017 at 09:24:23AM +0200, Paolo VALENTE wrote:
>>
>>> Il giorno 15 gen 2017, alle ore 04:42, Shaohua Li ha scritto:
>>>
>>> Hi,
>>>
>>> cgroup still lacks a good iocontroller. CFQ works well for hard disk, but
>>> not
>>> much for
From: Joseph Qi
Since throtl_rb_first may return NULL, so it should check tg first and
then use it.
Signed-off-by: Joseph Qi
---
block/blk-throttle.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index a7285bf..c1d2c5b 100644
From: Joseph Qi
Since throtl_rb_first may return NULL, so it should check tg first and
then use it.
Signed-off-by: Joseph Qi
---
block/blk-throttle.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index a7285bf..c1d2c5b 100644
From: Joseph Qi
I have encountered a NULL pointer dereference in
throtl_schedule_pending_timer:
[ 413.735396] BUG: unable to handle kernel NULL pointer dereference at
0038
[ 413.735535] IP: []
throtl_schedule_pending_timer+0x3f/0x210
[ 413.735643] PGD 22c8cf067 PUD
From: Joseph Qi
If error occurs, we have to free the allocated callback in
blk_mq_init_allocated_queue to avoid memory leaking.
Fixes: 34dbad5d26e2 ("blk-stat: convert to callback-based statistics reporting")
Signed-off-by: Joseph Qi
---
block/blk-mq.c | 4 +++-
1 file changed, 3
80 matches
Mail list logo