Re: BUG at mm/mmap.c:2309 when cx18.ko and cx18-alsa.ko loaded

[Takashi Iwai]

At Fri, 04 Mar 2011 12:13:04 -0500,
Andy Walls wrote:
> 
> On Fri, 2011-03-04 at 10:50 -0500, Devin Heitmueller wrote:
> > On Thu, Mar 3, 2011 at 9:06 PM, Andy Walls <awalls@xxxxxxxxxxxxxxxx> wrote:
> > > Hi,
> > >
> > > I got a BUG when loading the cx18.ko module (which in turn requests the
> > > cx18-alsa.ko module) on a kernel built from this repository
> > >
> > >        http://git.linuxtv.org/media_tree.git staging/for_v2.6.39
> > >
> > > which I beleive is based on 2.6.38-rc2.
> > >
> > > The BUG is mmap related and I'm almost certain it has to do with
> > > userspace accessing cx18-alsa.ko ALSA device nodes, since cx18.ko
> > > doesn't provide any mmap() related file ops.
> > >
> > > So here is my transcription of a fuzzy digital photo of the screen:
> > <snip>
> > > I'm not very familiar with mmap() nor ALSA and I did not author the
> > > cx18-alsa part of the cx18 driver, so any hints at where to look for the
> > > problem are appreciated.
> > 
> > Hi Andy,
> > 
> > I'm traveling on business for about two weeks, so I won't be able to
> > look into this right now.
> > 
> > Any idea whether this is some new regression?
> 
> I do not know.  I normally don't let cx18-alsa.ko load, due to
> PulseAudio's persistence at keeping the device nodes open (which makes
> unloading the cx18.ko module for development a hassle.)
> 
> 
> >   I'm just trying to
> > understand whether this is something that has always been there since
> > I originally added the ALSA support to cx18 or whether it's something
> > that is new, in which case it might make sense to drag the ALSA people
> > into the conversation since there haven't been any changes in the cx18
> > driver lately.
> 
> I can add some information about what is going on in userspace.  This
> was on a Fedora 10 machine.  When devices nodes show up, the HAL daemon
> and PulseAudio start using the device nodes right away.
> 
> That activity  triggers cx18.ko to do a firmware load which gets udevd
> running to satisfy firmware requests, and then the cx18 driver issues
> some simple commands to the CX23418 firmware, which will have
> acknowledgment interrupts coming back from the CX23418.  I resolved the
> firmware race in cx18*.ko a while ago, so I'm confident its not an
> issue.
> 
> The BUG looks like some sort of mmap() race or memory management problem
> outside of the cx18*.ko modules, given that mmput(), which appears to be
> an mm specific reference counting function, is involved.
> 
> It could also be in ALSA I guess.

There is no change in ALSA core regarding mmap for really long time.
If it's a regression, it must be triggered by some other changes.


Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/