On Mon, Jan 17, 2022 at 11:11:42AM -0600, Pierre-Louis Bossart wrote:
>
>
> On 1/17/22 2:49 AM, Takashi Iwai wrote:
> > On Sun, 16 Jan 2022 12:18:17 +0100,
> > Christophe JAILLET wrote:
> >>
> >> The commit below states that dpcm_be_connect() may be called from atomic
> >> context. It changes a GFP_KERNEL into a GFP_ATOMIC to deal with it.
> >>
> >> Another memory allocation is done in dpcm_create_debugfs_state() which is
> >> called by dpcm_be_connect(). Also use GFP_ATOMIC there to be consistent
> >> and be compliant with atomic context.
> >>
> >> Fixes: d8a9c6e1f676 ("ASoC: soc-pcm: use GFP_ATOMIC for dpcm structure")
> >> Signed-off-by: Christophe JAILLET <christophe.jaillet@xxxxxxxxxx>
> >> ---
> >> Not clear to me how dpcm_be_connect() can be called from an atomic context,
> >> though. But better safe than sorry.
> >
> > I don't think this no longer valid for the very latest code.
> > The commit b7898396f4bb dropped the spurious dpcm_lock spinlock, so
> > the code path you touched must be always sleepable.
> >
> > Similarly, the commit d8a9c6e1f676 can be reverted now.
>
> Can we really revert d8a9c6e1f676?
>
> We did propagate the non-atomic FE property to the BE, but if both FE
> and BE are both atomic that constraint would be required, no?
I have a Smatch check for these now, so I reviewed this and came to the
same conclusions as Takashi. If there is really a bug, let me know so
I can figure out where Smatch went wrong.
Unfortunately, I still have 64 sleeping in atomic warnings that I have
yet to triage. It kind of takes a long time to look through the
warnings because of the long call trees involved. Also Smatch the check
needs to be updated to warn about sleeping in IRQ context.
regards,
dan carpenter
