Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964919AbbFJOMx (ORCPT ); Wed, 10 Jun 2015 10:12:53 -0400 Received: from chaos.universe-factory.net ([37.72.148.22]:46950 "EHLO chaos.universe-factory.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965384AbbFJOKb (ORCPT ); Wed, 10 Jun 2015 10:10:31 -0400 X-Greylist: delayed 587 seconds by postgrey-1.27 at vger.kernel.org; Wed, 10 Jun 2015 10:10:31 EDT Message-ID: <55784305.4040309@universe-factory.net> Date: Wed, 10 Jun 2015 16:00:37 +0200 From: Matthias Schiffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "gregkh@linuxfoundation.org" CC: Lisa Du , "linux-kernel@vger.kernel.org" Subject: Re: A race condition between debugfs and seq_file operation References: <3626bdb18cfc40c98618d0ee68816ab0@SC-EXCH04.marvell.com> <20150609211202.GA16801@kroah.com> <9473dc801fb245ea8df91da31d426f7f@SC-EXCH04.marvell.com> <20150610052023.GA23451@kroah.com> In-Reply-To: <20150610052023.GA23451@kroah.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HTSB3SCGTLnfkonqjnRJbMOnU3sDpes38" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4564 Lines: 121 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HTSB3SCGTLnfkonqjnRJbMOnU3sDpes38 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/10/2015 07:20 AM, gregkh@linuxfoundation.org wrote: > On Wed, Jun 10, 2015 at 05:00:03AM +0000, Lisa Du wrote: >>> -----Original Message----- >>> From: gregkh@linuxfoundation.org [mailto:gregkh@linuxfoundation.org] >>> Sent: 2015=E5=B9=B46=E6=9C=8810=E6=97=A5 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 =3D { >>>> .open =3D ion_debug_client_open, >>>> .read =3D seq_read, >>>> .llseek =3D seq_lseek, >>>> .release =3D single_release, >>>> }; >>>> client->debug_root =3D debugfs_create_file(client->display_name, 066= 4, >>>> 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 th= e only >>> one :( >> Thanks for the reply!=20 >> Not sure if there is any plan to resolve such races in the future? >=20 > Yes, I have "plans", but it's on my very long todo list behind lots of > other things... >=20 > If you want to look into it, please, that would be wonderful. >=20 > thanks, >=20 > greg k-h I've stumbled across related issues a few days ago (mostly in network drivers). What I've found out: * I couldn't find any driver using device-specific debugfs files removing them in a race-free way * Userspace can make the race window arbitrarily large by opening a debugfs file and reading from it later: modprobe batman-adv modprobe dummy echo bat0 > /sys/class/net/dummy0/batman_adv/mesh_iface (sleep 5; cat) < /sys/kernel/debug/batman_adv/bat0/originators & echo none > /sys/class/net/dummy0/batman_adv/mesh_iface # When the sleep finishs, batman-adv will read from a freed net_device * There also seems to be a bug debugfs_remove_recursive hanging when removing subdirectories with files that are still open: modprobe mac80211_hwsim # Or whatever phyX the hwsim PHY is (sleep 5; cat) < \ /sys/kernel/debug/ieee80211/phy0/statistics/retry_count & rmmod mac80211_hwsim # Will hang in wiphy_unregister() until the sleep finishes, # with RTNL held! Is there a sane way to check from the read fops callback if the file has been removed (and lock against removal while doing that)? The nice debugfs_create_u32() etc. helpers are useless as well for dynamic files at the moment as they can't be used without this race condition... I'd also like to get this cleaned up as soon as possible as changes I plan for batman-adv might make the issue more prominent there. Matthias --HTSB3SCGTLnfkonqjnRJbMOnU3sDpes38 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVeEMFAAoJEBbvP2TLIB2chOIQAOin5z5ODjYoKBeUxFcuvSe6 SSOMQ7ISS8JVMHvGXl78A2ta4c8utGxOOqdK5XU4HH3vOnBLhVUIzASViJy4puXZ Djjkxnztz9j4m/+rHvu1YmCY2QukZoqu+LaRecKZXkzVismUA6IoSAUhriwQ0F/p umNM69AqHsNhD6vzr67xYJTfHCYzLc01pTWE69BKfybP/EpxsVCvq8nGMX47TP9v hWUJjP77TK9+Wva64P1MmeyAe8jetSDt7w0FmXZSR3dDDkT/iDMsy2J2TlIDwnNn zLYeb10em5zMtNsoG16pjATN7bTYU9z7oC6YfnkGzRAPLGPK/cCwoSOGtkNZMqFJ SGFbUm9/zEEVqGU8m/RUxpMOt99JrZC1RcPsoRChBurpoAAXeEFYjT7U9JJ3IGcA O9ZsIDM3JK+6GpRvobjnRTG8LAQ5Xl4x7r3QuKnvOVAMAcrHIXlIon/6OF60ZEid sscHeHqpg5UaWTDvJPp+Euj2aAeGKt/PsrDgvIM407hq1AGbYtr0X5pCO/aixpbC fJHXtvgMnfsXfWJVxpb3cy5A965K3JavCnjAi6S9Lj1HcH8eRKyddeiX3oTlWkd1 cKSM1mp5isrBJSC/si99T0joGZ51guBYCwfKfLKlCsWda+PblhTdnH6Hd+xEYAY4 i4XQLHdA0nricUfPSeKf =dh1a -----END PGP SIGNATURE----- --HTSB3SCGTLnfkonqjnRJbMOnU3sDpes38-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/