Messages in this thread | | | From | Lisa Du <> | Subject | RE: A race condition between debugfs and seq_file operation | Date | Wed, 10 Jun 2015 05:00:03 +0000 |
| |
> -----Original Message----- > From: gregkh@linuxfoundation.org [mailto:gregkh@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? > > thanks, > > greg k-h
| |