From: Jens Axboe <axboe@kernel.dk>
To: Tejun Heo <tj@kernel.org>, Li Lingfeng <lilingfeng3@huawei.com>
Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
akpm@linux-foundation.org, jack@suse.cz, bingjingc@synology.com,
ebiggers@google.com, james.smart@broadcom.com,
houtao1@huawei.com, yi.zhang@huawei.com, yangerkun@huawei.com,
yukuai3@huawei.com
Subject: Re: [PATCH-next v3] lib: parser: optimize match_NUMER apis to use local array
Date: Thu, 19 Jan 2023 20:50:31 -0700 [thread overview]
Message-ID: <3ed9db5a-f527-2c53-3926-74bd802a3086@kernel.dk> (raw)
In-Reply-To: <Y8n1rOLdMGDfOgpe@slm.duckdns.org>
On 1/19/23 7:00?PM, Tejun Heo wrote:
> On Fri, Jan 20, 2023 at 10:13:04AM +0800, Li Lingfeng wrote:
>> Memory will be allocated to store substring_t in match_strdup(), which means
>> the caller of match_strdup() may need to be scheduled out to wait for reclaiming
>> memory.
>>
>> Using local array to store substring_t to remove the restriction.
>>
>> Link: https://lore.kernel.org/all/20221104023938.2346986-5-yukuai1@huaweicloud.com/
>> Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
>
> Acked-by: Tejun Heo <tj@kernel.org>
>
> This fixes a sleep-while-atomic splat in blk-iocost, so it'd be a good idea to add:
>
> Fixes: 2c0647988433 ("blk-iocost: don't release 'ioc->lock' while updating params").
>
> The mm tree likely is the best fit but given the splat the block tree can
> work too. Andrew, Jens, what do you think?
I can take it through the block tree once folks are happy with it, as
the buggy patch came through there. Doesn't really matter to me,
however.
Why is it marked for-next though, seems like this is a regression in
this series?
--
Jens Axboe
next prev parent reply other threads:[~2023-01-20 3:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-20 2:13 Li Lingfeng
2023-01-20 2:00 ` Tejun Heo
2023-01-20 3:50 ` Jens Axboe [this message]
2023-01-20 2:07 ` Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3ed9db5a-f527-2c53-3926-74bd802a3086@kernel.dk \
--to=axboe@kernel.dk \
--cc=akpm@linux-foundation.org \
--cc=bingjingc@synology.com \
--cc=ebiggers@google.com \
--cc=houtao1@huawei.com \
--cc=jack@suse.cz \
--cc=james.smart@broadcom.com \
--cc=lilingfeng3@huawei.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai3@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®