From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F660C31E40 for ; Thu, 15 Aug 2019 10:36:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EA58221743 for ; Thu, 15 Aug 2019 10:36:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="n5uEtNR+" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731119AbfHOKgK (ORCPT ); Thu, 15 Aug 2019 06:36:10 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:49000 "EHLO aserp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730996AbfHOKgJ (ORCPT ); Thu, 15 Aug 2019 06:36:09 -0400 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x7FAYPJD122956; Thu, 15 Aug 2019 10:35:39 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=message-id : subject : from : to : cc : date : in-reply-to : references : content-type : mime-version : content-transfer-encoding; s=corp-2019-08-05; bh=B844NRkiFX/nARJ/+oFK5xLBlkISe3Mkaclr3CxPrX0=; b=n5uEtNR+N/27rSpNgw4NCJ6G1jIOoey/GiYCBampeHs4mDc6iyH5SAYswmxPAMCWX/3P TP8OmJCr5lLn6bbe1IMBGh1ojBznCYMIH6s8vyIPODzb+qnBZpgQqeSZfJ74B0dJxZqd svyMJ/+7JResOTqrba2CKsbIdH3E21nhhsabAIBYSn1xHc1tVGE5k5cHSYrUgZ3EDIxR WtOejxOSSDIVQki45mzRw/6vK3b5U0qt1zjBYgTqEzxtiB/LnoiYoAYBaZuxZnaS4mcQ s4M5lZhSpKbk6JNHueCQmfrat9RwygXYwQ+zBTkMXAUgTQw6PvCFcIInDs8RUQI4aevW zA== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 2u9nvpj7ys-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 15 Aug 2019 10:35:39 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x7FAXFfa104652; Thu, 15 Aug 2019 10:35:38 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 2ucmwjj2wg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 15 Aug 2019 10:35:38 +0000 Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x7FAZVdP032402; Thu, 15 Aug 2019 10:35:31 GMT Received: from abi.no.oracle.com (/141.143.213.43) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Aug 2019 03:35:30 -0700 Message-ID: <9629068a41a160de0145a18dd22924bce70f37fe.camel@oracle.com> Subject: Re: [RFC 06/19] ktf: A simple debugfs interface to test results From: Knut Omang To: Greg Kroah-Hartman Cc: linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org, Shuah Khan , Jonathan Corbet , Masahiro Yamada , Michal Marek , Shreyans Devendra Doshi <0xinfosect0r@gmail.com>, Alan Maguire , Brendan Higgins , Kevin Hilman , Hidenori Yamaji , Frank Rowand , Timothy Bird , Luis Chamberlain , "Theodore Ts'o" , Daniel Vetter , Stephen Boyd Date: Thu, 15 Aug 2019 12:35:26 +0200 In-Reply-To: <20190815084921.GE3512@kroah.com> References: <20190813082152.GA17627@kroah.com> <20190815084921.GE3512@kroah.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9349 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908150113 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9349 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908150113 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2019-08-15 at 10:49 +0200, Greg Kroah-Hartman wrote: > On Wed, Aug 14, 2019 at 07:17:07PM +0200, Knut Omang wrote: > > I notice the discussion and your response here: > > http://linux-kernel.2935.n7.nabble.com/debugfs-and-module-unloading-td865175.html > > I assume that means that protection against module unload while a debugfs file > > is open is now safe. > > It should be, if you set the *owner field of your file_operations > properly. Try it and see! Might be a case for a KTF selftest to play with the timing to increase the chance :) Wasn't able to make it crash with these simple, short files. I notice I had set the .owner field correctly myself in that driver code I referred to, so that's a "copy regression". > > On older kernels, having this code in place is far better than an unprotected > > debugfs entry/exit - I have tested it extensively in the past :-) > > Yes, it seems to work, but again, it really is racy and will fail. > Please don't use it. > > > I perfectly agree with you that reducing the hole for a race condition > > is generally a bad idea, but from the above mail thread > > it seems that's the only available choice for older kernels? > > I have no idea, but please, do not use that pattern of code as it is > racy in all kernels, from all of time. Ok, will remove it :-) I tried in vain to find the commit from Al Viro that made the code safe, to identify which kernels that are safe from this issue, but he has a **lot** of commits, do you have a clue for what/where to look? It will be good to have a mention/comment on this for future reference, like the earliest kernel version where this is safe. Maybe we can even get rid of some more of the remaining of these too.. (I notice there's 65 cases of 'if (!try_module_get(THIS_MODULE))' right now) Thanks! Knut > > thanks, > > greg k-h