| Message ID | 20250113015833.698458-1-ming.lei@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | block: mark GFP_NOIO around sysfs ->store() | expand |
On Mon, Jan 13, 2025 at 09:58:33AM +0800, Ming Lei wrote: > sysfs ->store is called with queue freezed, meantime we have several > ->store() callbacks(update_nr_requests, wbt, scheduler) to allocate > memory with GFP_KERNEL which may run into direct reclaim code path, > then potential deadlock can be caused. > > Fix the issue by marking NOIO around sysfs ->store() Yes, that's a good thing, and we should aim for more of that for block layer code that requires NOIO: Reviewed-by: Christoph Hellwig <hch@lst.de>
On 13/01/2025 01:58, Ming Lei wrote: > sysfs ->store is called with queue freezed, meantime we have several > ->store() callbacks(update_nr_requests, wbt, scheduler) to allocate > memory with GFP_KERNEL which may run into direct reclaim code path, > then potential deadlock can be caused. > > Fix the issue by marking NOIO around sysfs ->store() > > Reported-by: Thomas Hellström<thomas.hellstrom@linux.intel.com> > Cc:stable@vger.kernel.org > Signed-off-by: Ming Lei<ming.lei@redhat.com> I guess that you should be including a link to https://lore.kernel.org/linux-block/Z4RkemI9f6N5zoEF@fedora/T/#mc774c65eeca5c024d29695f9ac6152b87763f305 Regardless, FWIW: Reviewed-by: John Garry <john.g.garry@oracle.com>
On Mon, Jan 13, 2025 at 08:23:19AM +0000, John Garry wrote: > On 13/01/2025 01:58, Ming Lei wrote: > > sysfs ->store is called with queue freezed, meantime we have several > > ->store() callbacks(update_nr_requests, wbt, scheduler) to allocate > > memory with GFP_KERNEL which may run into direct reclaim code path, > > then potential deadlock can be caused. > > > > Fix the issue by marking NOIO around sysfs ->store() > > > > Reported-by: Thomas Hellström<thomas.hellstrom@linux.intel.com> > > Cc:stable@vger.kernel.org > > Signed-off-by: Ming Lei<ming.lei@redhat.com> > > I guess that you should be including a link to https://lore.kernel.org/linux-block/Z4RkemI9f6N5zoEF@fedora/T/#mc774c65eeca5c024d29695f9ac6152b87763f305 > Indeed, I will add a Closes tag in V2. > Regardless, FWIW: > Reviewed-by: John Garry <john.g.garry@oracle.com> Thanks,
On Mon, 13 Jan 2025 09:58:33 +0800, Ming Lei wrote: > sysfs ->store is called with queue freezed, meantime we have several > ->store() callbacks(update_nr_requests, wbt, scheduler) to allocate > memory with GFP_KERNEL which may run into direct reclaim code path, > then potential deadlock can be caused. > > Fix the issue by marking NOIO around sysfs ->store() > > [...] Applied, thanks! [1/1] block: mark GFP_NOIO around sysfs ->store() commit: 7c0be4ead1f8f5f8be0803f347de0de81e3b8e1c Best regards,
diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c index e828be777206..e09b455874bf 100644 --- a/block/blk-sysfs.c +++ b/block/blk-sysfs.c @@ -681,6 +681,7 @@ queue_attr_store(struct kobject *kobj, struct attribute *attr, struct queue_sysfs_entry *entry = to_queue(attr); struct gendisk *disk = container_of(kobj, struct gendisk, queue_kobj); struct request_queue *q = disk->queue; + unsigned int noio_flag; ssize_t res; if (!entry->store_limit && !entry->store) @@ -711,7 +712,9 @@ queue_attr_store(struct kobject *kobj, struct attribute *attr, mutex_lock(&q->sysfs_lock); blk_mq_freeze_queue(q); + noio_flag = memalloc_noio_save(); res = entry->store(disk, page, length); + memalloc_noio_restore(noio_flag); blk_mq_unfreeze_queue(q); mutex_unlock(&q->sysfs_lock); return res;
sysfs ->store is called with queue freezed, meantime we have several ->store() callbacks(update_nr_requests, wbt, scheduler) to allocate memory with GFP_KERNEL which may run into direct reclaim code path, then potential deadlock can be caused. Fix the issue by marking NOIO around sysfs ->store() Reported-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by: Ming Lei <ming.lei@redhat.com> --- block/blk-sysfs.c | 3 +++ 1 file changed, 3 insertions(+)