Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp2086299ybb; Thu, 9 Apr 2020 15:01:29 -0700 (PDT) X-Google-Smtp-Source: APiQypKW/5LgVQEjWs4TYX8k3UdW06blx5Rbva+yczono3LcypjrMxHeQkxE8qHIHYodNOfK2I2J X-Received: by 2002:a37:aec3:: with SMTP id x186mr1033298qke.419.1586469689457; Thu, 09 Apr 2020 15:01:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586469689; cv=none; d=google.com; s=arc-20160816; b=UbSyLlqlaNOFZ0+eXVQPTbh0mLUV2/yLTaFEzB/yn11x2vxe5Dci9ejq/4rTAZGFMr 8A76ftj6ayrjwSv8IHgVGFG4oWd2y6EZjAAd7d7bcNzUOtw/GNvZRkxAK1t3992n5u0Q Mp3qv6sxVz0c6m4sOzzdeCASRPi/SxATyV4P2keSAih68eh7Y2inQX9vjXdW3mXFSHfD K64vr7d521nueIxUdOoB3EGAvWry3R/plTt/Dt8cPJLN0QD6O123KW+dkL5RhDoY8YpB Qk3DSF+laOJXsdo4nxfHQ40LOSNDJjNi96Cj19anEywX8BDxiuPMSKs1dHVZ/wVp/P8m h1dA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=Qskn21EkPdHYT8zkk+vxIl0tJkllOXlBdz4NiCQMXlc=; b=vdHLSSXTnV87+hDsSidWJFONPnjeeLFdLcXJRTAChk0zpZ2f/3UrxX4TsdVBl1aZoq trPo/HIqlVLQ1ODGNOXXEA0Sm1dw+MkZA+w/jz/mORRowpIrS1U5nUbgzPQrnw4jJDUh 5yvBWtUBsleWO14xeQnaljrO2PgfM1jhzdwfBWutgWs97XfLKYIbp+8QY47Qg6h8FtTN MJD0ZjUc1lxGzY94gaaMCxClg10C31MilB5NpSOHnIBKEWXL4xhKt5w4BGMokz6XLh5r iT4K5utASArwg3+6xcXEMI4Lcv3yBL3/opnBlw6GRjbkzuZH1DR+vQo3GOgWvjx+Llym xIBg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i17si197051qkl.246.2020.04.09.15.01.14; Thu, 09 Apr 2020 15:01:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727079AbgDIUqB (ORCPT + 99 others); Thu, 9 Apr 2020 16:46:01 -0400 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:14446 "EHLO mail2-relais-roc.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726725AbgDIUqB (ORCPT ); Thu, 9 Apr 2020 16:46:01 -0400 X-IronPort-AV: E=Sophos;i="5.72,364,1580770800"; d="scan'208";a="444630938" Received: from abo-173-121-68.mrs.modulonet.fr (HELO hadrien) ([85.68.121.173]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Apr 2020 22:46:00 +0200 Date: Thu, 9 Apr 2020 22:45:59 +0200 (CEST) From: Julia Lawall X-X-Sender: jll@hadrien To: Alexander Popov cc: Gilles Muller , Nicolas Palix , Michal Marek , cocci@systeme.lip6.fr, "kernel-hardening@lists.openwall.com" , Jann Horn , Kees Cook , Hans Verkuil , Mauro Carvalho Chehab , Linux Media Mailing List , LKML , Markus Elfring Subject: Re: [Cocci] Coccinelle rule for CVE-2019-18683 In-Reply-To: <3c92523d-4b3f-e805-84e6-6abd1eedd683@linux.com> Message-ID: References: <3c92523d-4b3f-e805-84e6-6abd1eedd683@linux.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > >> kthread_stop@stop_p(...) > >> ... > >> mutex_lock@lock_p(E) > >> > >> @script:python@ > >> stop_p << race.stop_p; > >> unlock_p << race.unlock_p; > >> lock_p << race.lock_p; > >> E << race.E; > >> @@ > >> > >> coccilib.report.print_report(unlock_p[0], 'mutex_unlock(' + E + ') here') > >> coccilib.report.print_report(stop_p[0], 'kthread_stop here') > >> coccilib.report.print_report(lock_p[0], 'mutex_lock(' + E + ') here\n') > > ... > > > Based on Jann's suggestion, it seem like it could be interesting to find > > these locking pauses, and then collect functions that are used in locks > > and in lock pauses. If a function is mostly used with locks held, then > > using it in a lock pause could be a sign of a bug. I will see if it turns > > up anything interesting. > > Do you mean collecting the behaviour that happens between unlocking and locking > and then analysing it somehow? Yes. I have tried doing what I described, but I'm not sure that the results are very reliable at the moment. julia