On Wed, Jun 10, 2015 at 04:00:37PM +0200, Matthias Schiffer wrote: > On 06/10/2015 07:20 AM, gre...@linuxfoundation.org wrote: > > On Wed, Jun 10, 2015 at 05:00:03AM +0000, Lisa Du wrote: > >>> -----Original Message----- > >>> From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] > >>> Sent: 2015年6月10日 5:12 > >>> To: Lisa Du > >>> Cc: linux-kernel@vger.kernel.org > >>> Subject: Re: A race condition between debugfs and seq_file operation > >>> > >>> On Mon, Jun 08, 2015 at 04:28:10AM +0000, Lisa Du wrote: > >>>> Hi, All > >>>> Recently I met one race condition related to debugfs. > >>>> > >>>> Take an example from ion.c in kernel3.14: > >>>> static int ion_debug_client_open(struct inode *inode, struct file > >>>> *file) { > >>>> return single_open(file, ion_debug_client_show, inode->i_private); } > >>>> > >>>> static const struct file_operations debug_client_fops = { > >>>> .open = ion_debug_client_open, > >>>> .read = seq_read, > >>>> .llseek = seq_lseek, > >>>> .release = single_release, > >>>> }; > >>>> client->debug_root = debugfs_create_file(client->display_name, 0664, > >>>> dev->clients_debug_root, > >>>> client, &debug_client_fops); > >>>> > >>>> I find during I read the debugfs node, driver can do > >>>> debugfs_remove_recursive(dentry); Is it expected? > >>> > >>> Yes. Well, not "expected", but a mess, yes. > >>> > >>> Removing debugfs files are known to have lots of races, this isn't the > >>> only > >>> one :( > >> Thanks for the reply! > >> Not sure if there is any plan to resolve such races in the future? > > > > Yes, I have "plans", but it's on my very long todo list behind lots of > > other things... > > > > If you want to look into it, please, that would be wonderful. > > > > thanks, > > > > greg k-h > > I've stumbled across related issues a few days ago (mostly in network > drivers). What I've found out:
<snip> Yes, all of these are issues, as I mentioned. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
