[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=s-KFuUnmNaDN6OYaiwZiaBLbYB5MCwde7tvvw@mail.gmail.com>
Date: Thu, 12 Aug 2010 14:41:51 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Takashi Iwai <tiwai@...e.de>, Eric Paris <eparis@...hat.com>,
Al Viro <viro@...iv.linux.org.uk>
Cc: Jiri Slaby <jirislaby@...il.com>,
Pekka Enberg <penberg@...nel.org>,
Thomas Meyer <thomas@...3r.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.36: Sound stop working
On Thu, Aug 12, 2010 at 2:17 PM, Takashi Iwai <tiwai@...e.de> wrote:
> At Thu, 12 Aug 2010 23:01:04 +0200,
> Jiri Slaby wrote:
>>
>> Probably I got into this problem yesterday. Found out that PA fails to
>> open /dev/snd/pcmC0D0p _second_ time. It opens it, then closes, then
>> opens it again and gets EBUSY. aplay is OK.
>
> Yes, I can also confirm that it's broken on my machine in the same
> way now :) PA log shows that the succeeding open failed.
>
> PA tries to do quick open/close of the same device to figure out which
> configuration is available at start-up. This implies that the
> fs/notify commits touching the open/close stuff can be the culprit.
Yeah. The f_count stuff is disgusting. This revert patch makes things
work for me again. And I suspect it's the right thing to do
regardless. I reacted to that ugly __fput() hackery when I pulled the
fanotify tree, but I let it slide. I clearly should have let my taste
guide me more.
fsnotify playing games with fput/fget is almost certainly totally wrong.
Al, what was the problem that caused you to think that we want to have
a 'struct file' here? Is it just the fact that some of those fsnotify
things use that 'path' structure that is embedded in the parent? But
isn't the simplest fix for that to just _copy_ the "struct path"
rather than pass the "struct file" around?
Linus
View attachment "diff.txt" of type "text/plain" (15771 bytes)
Powered by blists - more mailing lists