On Friday 15 December 2017 02:15 PM, Pavel Machek wrote: > On Tue 2017-12-12 15:58:00, Geert Uytterhoeven wrote: >> Hi Shrikant, >> >> On Tue, Dec 12, 2017 at 2:45 PM, <shrikant.mau...@techveda.org> wrote: >>> From: Shrikant Maurya <shrikant.mau...@techveda.org> >>> >>> As reported by Jia-Ju Bai (https://lkml.org/lkml/2017/12/11/872): >>> API's are using GFP_KERNEL to allocate memory which may sleep. >>> >>> To ensure atomicity such allocations must be avoided in critical >>> sections under spinlock. >>> Fixed by replacing GFP_KERNEL to GFP_ATOMIC. >>> >>> Reported-by: Jia-Ju Bai <baijiaju1...@gmail.com> >>> Signed-off-by: Shrikant Maurya <shrikant.mau...@techveda.org> >>> Signed-off-by: Suniel Mahesh <suni...@techveda.org> >>> Signed-off-by: Raghu Bharadwaj <ra...@techveda.org> >>> Signed-off-by: Karthik Tummala <kart...@techveda.org> >> >> Can't the call to device_init_wakeup() in isp116x_start() just be moved >> below the spinlock release? >> >>> --- a/drivers/base/power/wakeup.c >>> +++ b/drivers/base/power/wakeup.c >>> @@ -92,11 +92,11 @@ struct wakeup_source *wakeup_source_create(const char >>> *name) >>> { >>> struct wakeup_source *ws; >>> >>> - ws = kmalloc(sizeof(*ws), GFP_KERNEL); >>> + ws = kmalloc(sizeof(*ws), GFP_ATOMIC); >> >> With GFP_ATOMIC, allocation failure is much more likely to occur. >> So IMHO it's better to fix the isp116x, than to impose this burden on >> every user. >> >>> if (!ws) >>> return NULL; >>> >>> - wakeup_source_prepare(ws, name ? kstrdup_const(name, GFP_KERNEL) : >>> NULL); >>> + wakeup_source_prepare(ws, name ? kstrdup_const(name, GFP_ATOMIC) : >>> NULL); >>> return ws; > > NAK. This will silently replace name with NULL if memory is low.
Yes, replacing GFP_KERNEL with GFP_ATOMIC in both places will cause more issues than it fixes. > > Pavel > Thank you Pavel. -- Shrikant techveda.org
