| Message ID | 1523270781-22627-1-git-send-email-baijiaju1990@gmail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | f2126f6d4fedfee6065351da4bab6b89d0ba4d1d |
| Headers | show |
On 4/9/18 5:46 AM, Jia-Ju Bai wrote: > broxton_audio_probe() is never called in atomic context. > This function is only set as ".probe" in "struct platform_driver". > > Despite never getting called from atomic context, > broxton_audio_probe() calls devm_kzalloc() with GFP_ATOMIC, > which waits busily for allocation. > GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL, > to avoid busy waiting and improve the possibility of sucessful allocation. [answering for the series] Humm, this is interesting. If indeed we can afford to sleep then the change should be done on ALL 14 boards in sound/soc/intel/boards which follow the same code pattern. If we cannot sleep then then none of these changes should be applied. Liam and Vinod? > > This is found by a static analysis tool named DCNS written by myself. > > Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> > --- > sound/soc/intel/boards/bxt_da7219_max98357a.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/sound/soc/intel/boards/bxt_da7219_max98357a.c b/sound/soc/intel/boards/bxt_da7219_max98357a.c > index ce35ec7..f4361b7 100644 > --- a/sound/soc/intel/boards/bxt_da7219_max98357a.c > +++ b/sound/soc/intel/boards/bxt_da7219_max98357a.c > @@ -585,7 +585,7 @@ static int broxton_audio_probe(struct platform_device *pdev) > { > struct bxt_card_private *ctx; > > - ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_ATOMIC); > + ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL); > if (!ctx) > return -ENOMEM; > >
On Mon, 09 Apr 2018 20:57:43 +0200, Pierre-Louis Bossart wrote: > > On 4/9/18 5:46 AM, Jia-Ju Bai wrote: > > broxton_audio_probe() is never called in atomic context. > > This function is only set as ".probe" in "struct platform_driver". > > > > Despite never getting called from atomic context, > > broxton_audio_probe() calls devm_kzalloc() with GFP_ATOMIC, > > which waits busily for allocation. > > GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL, > > to avoid busy waiting and improve the possibility of sucessful allocation. > > [answering for the series] > Humm, this is interesting. > If indeed we can afford to sleep then the change should be done on ALL > 14 boards in sound/soc/intel/boards which follow the same code > pattern. > If we cannot sleep then then none of these changes should be applied. > Liam and Vinod? It must be sleepable context as it's a standard platform driver probe callback. And now looking at grep output, only sound/soc/intel contains so many calls with GFP_ATOMIC. I bet that almost all can be done with GFP_KERNEL, maybe only one or two in atom/sst would be conditionally with GFP_ATOMIC. thanks, Takashi
On Mon, Apr 09, 2018 at 09:39:06PM +0200, Takashi Iwai wrote: > It must be sleepable context as it's a standard platform driver probe > callback. > And now looking at grep output, only sound/soc/intel contains so many > calls with GFP_ATOMIC. I bet that almost all can be done with > GFP_KERNEL, maybe only one or two in atom/sst would be conditionally > with GFP_ATOMIC. Yeah, it's not like it'd be the first code quality problem found in the Intel drivers.
On Mon, Apr 09, 2018 at 09:39:06PM +0200, Takashi Iwai wrote: > On Mon, 09 Apr 2018 20:57:43 +0200, > Pierre-Louis Bossart wrote: > > > > On 4/9/18 5:46 AM, Jia-Ju Bai wrote: > > > broxton_audio_probe() is never called in atomic context. > > > This function is only set as ".probe" in "struct platform_driver". > > > > > > Despite never getting called from atomic context, > > > broxton_audio_probe() calls devm_kzalloc() with GFP_ATOMIC, > > > which waits busily for allocation. > > > GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL, > > > to avoid busy waiting and improve the possibility of sucessful allocation. > > > > [answering for the series] > > Humm, this is interesting. > > If indeed we can afford to sleep then the change should be done on ALL > > 14 boards in sound/soc/intel/boards which follow the same code > > pattern. > > If we cannot sleep then then none of these changes should be applied. > > Liam and Vinod? > > It must be sleepable context as it's a standard platform driver probe > callback. > > And now looking at grep output, only sound/soc/intel contains so many > calls with GFP_ATOMIC. I bet that almost all can be done with > GFP_KERNEL, maybe only one or two in atom/sst would be conditionally > with GFP_ATOMIC. Yeah I don't see many cases which would warrant atomic context, I will review them and fix these after merge window closes. Clearly machines have no reason for that, and I guess most are copy-paste from 1st culprit
On Mon, Apr 09, 2018 at 06:46:21PM +0800, Jia-Ju Bai wrote: > broxton_audio_probe() is never called in atomic context. > This function is only set as ".probe" in "struct platform_driver". Please submit patches using subject lines reflecting the style for the subsystem. This makes it easier for people to identify relevant patches. Look at what existing commits in the area you're changing are doing and make sure your subject lines visually resemble what they're doing.
On 2018/4/13 18:41, Mark Brown wrote: > On Mon, Apr 09, 2018 at 06:46:21PM +0800, Jia-Ju Bai wrote: >> broxton_audio_probe() is never called in atomic context. >> This function is only set as ".probe" in "struct platform_driver". > Please submit patches using subject lines reflecting the style for the > subsystem. This makes it easier for people to identify relevant > patches. Look at what existing commits in the area you're changing are > doing and make sure your subject lines visually resemble what they're > doing. Oh, sorry for my improper subjects. Thanks for your very helpful advice :) I looked at previous related patches, and find the subject should be "ASoC: Intel: ...." I will follow it in my future patches. Do I need to send V2 patches? Best wishes, Jia-Ju Bai
On Fri, Apr 13, 2018 at 06:54:15PM +0800, Jia-Ju Bai wrote: > I looked at previous related patches, and find the subject should be "ASoC: > Intel: ...." > I will follow it in my future patches. Right, that's it for these thanks. > Do I need to send V2 patches? No, it's OK - I already applied them.
diff --git a/sound/soc/intel/boards/bxt_da7219_max98357a.c b/sound/soc/intel/boards/bxt_da7219_max98357a.c index ce35ec7..f4361b7 100644 --- a/sound/soc/intel/boards/bxt_da7219_max98357a.c +++ b/sound/soc/intel/boards/bxt_da7219_max98357a.c @@ -585,7 +585,7 @@ static int broxton_audio_probe(struct platform_device *pdev) { struct bxt_card_private *ctx; - ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_ATOMIC); + ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL); if (!ctx) return -ENOMEM;
broxton_audio_probe() is never called in atomic context. This function is only set as ".probe" in "struct platform_driver". Despite never getting called from atomic context, broxton_audio_probe() calls devm_kzalloc() with GFP_ATOMIC, which waits busily for allocation. GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL, to avoid busy waiting and improve the possibility of sucessful allocation. This is found by a static analysis tool named DCNS written by myself. Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> --- sound/soc/intel/boards/bxt_da7219_max98357a.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)