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 -- 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/
