linux-kernel - Re: [PATCH] media: add GFP flag to media_*() that could get called in atomic context

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160314105253.GQ11084@valkosipuli.retiisi.org.uk>
Date:	Mon, 14 Mar 2016 12:52:54 +0200
From:	Sakari Ailus <sakari.ailus@....fi>
To:	Mauro Carvalho Chehab <mchehab@....samsung.com>
Cc:	Shuah Khan <shuahkh@....samsung.com>, kyungmin.park@...sung.com,
	a.hajda@...sung.com, s.nawrocki@...sung.com, kgene@...nel.org,
	k.kozlowski@...sung.com, laurent.pinchart@...asonboard.com,
	hyun.kwon@...inx.com, soren.brinkmann@...inx.com,
	gregkh@...uxfoundation.org, perex@...ex.cz, tiwai@...e.com,
	hans.verkuil@...co.com, lixiubo@...s.chinamobile.com,
	javier@....samsung.com, g.liakhovetski@....de,
	chehabrafael@...il.com, crope@....fi, tommi.franttila@...el.com,
	dan.carpenter@...cle.com, prabhakar.csengg@...il.com,
	hamohammed.sa@...il.com, der.herr@...r.at, navyasri.tech@...il.com,
	Julia.Lawall@...6.fr, amitoj1606@...il.com,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-samsung-soc@...r.kernel.org,
	linux-renesas-soc@...r.kernel.org, devel@...verdev.osuosl.org,
	alsa-devel@...a-project.org
Subject: Re: [PATCH] media: add GFP flag to media_*() that could get called
 in atomic context

Hi Mauro,

On Mon, Mar 14, 2016 at 07:13:58AM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 14 Mar 2016 09:22:37 +0200
> Sakari Ailus <sakari.ailus@....fi> escreveu:
> 
> > Hi Shuah,
> > 
> > On Sat, Mar 12, 2016 at 06:48:09PM -0700, Shuah Khan wrote:
> > > Add GFP flags to media_create_pad_link(), media_create_intf_link(),
> > > media_devnode_create(), and media_add_link() that could get called
> > > in atomic context to allow callers to pass in the right flags for
> > > memory allocation.
> > > 
> > > tree-wide driver changes for media_*() GFP flags change:
> > > Change drivers to add gfpflags to interffaces, media_create_pad_link(),
> > > media_create_intf_link() and media_devnode_create().
> > > 
> > > Signed-off-by: Shuah Khan <shuahkh@....samsung.com>
> > > Suggested-by: Mauro Carvalho Chehab <mchehab@....samsung.com>  
> > 
> > What's the use case for calling the above functions in an atomic context?
> > 
> 
> ALSA code seems to do a lot of stuff at atomic context. That's what
> happens on my test machine when au0828 gets probed before
> snd-usb-audio:
> 	http://pastebin.com/LEX5LD5K
> 
> It seems that ALSA USB probe routine (usb_audio_probe) happens in
> atomic context.

usb_audio_probe() grabs a mutex (register_mutex) on its own. It certainly
cannot be called in atomic context.

In the above log, what I did notice, though, was that because *we* grab
mdev->lock spinlock in media_device_register_entity(), we may not sleep
which is what the notify() callback implementation in au0828 driver does
(for memory allocation).

Could we instead replace mdev->lock by a mutex?

If there is no pressing need to implement atomic memory allocation I simply
wouldn't do it, especially in device initialisation where an allocation
failure will lead to probe failure as well.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@....fi	XMPP: sailus@...iisi.org.uk