Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp820829ybn; Tue, 24 Sep 2019 10:01:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqwUKW+4lbNomlTe0I7bbF0TJOXC3uv+NtNXrRKLbQj0+eEHZgwSxz8hd3wmKs/3Qwd3DuCu X-Received: by 2002:a17:906:cf82:: with SMTP id um2mr3531888ejb.254.1569344481477; Tue, 24 Sep 2019 10:01:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569344481; cv=none; d=google.com; s=arc-20160816; b=vV7UGEGCnCPqBc11le2jj+911Ic2OAoBj63+uK2IBJS0LFOEiAk91Pvu+IWEYu/cDV cVHB8z50rjJVepWqnfazJoDedTyAXwuq3cbQ4RQCk7qtNIqZf6BqORO4JkvvRoKvU+p/ /EC+VGuzhEZ7Ib06eHKAPAXFCtxmnz37fwKwrKWXEV4as5dUhUUujYljSFmNk2D+wftC 9g5bdHteZbIvtDi9/W1O5q9Nj0m6elyI7vihcVtqQLCB4Ih7uUygQKULWlyXNgSccc+p knt3hfOxBqQrYaS2/lpVUhpcqUi3P0jd7fmHZe8yg7p3WPLig0fT7EhaHfWxPvyVwPLc zOVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=lmz7IKZ8gZ2YId97V9WKRyVJHsp3ja+Jq2L1R3JFGjk=; b=A9086CdF7bknt8gJNlLEYeaDZjCqSvcwZsZkQT0wre1ggTnARj7qcI8F10oHuKt9Iv 5NeO7C5BpM8BLEZXjhNzuj5gWbDHyZNnufNEpjrv91Gjh0L+nMLRvvQkck3EnzYVHzZ6 Jsx3eMn668A/xeuQRAJfYcRmls/K9g4+lreXX+G5xSkjUWj4jRGMUE08ICvNr3l56J5l NnS6R4Z1gf0M2FyMA/0D3j/qoJHzwx26sQntHKyFO3QtszoX1jv/HIOExPvvmulfZ6ii 3+gBiajhM0wnAv99wbXPiQ0MiOUrjvSSYCFdj4w2UttFIZai9dT9aP9FegcleEFRCEgj LJhA== 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 y11si1308153ejj.363.2019.09.24.10.00.56; Tue, 24 Sep 2019 10:01:21 -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 S2393807AbfIWL0r (ORCPT + 99 others); Mon, 23 Sep 2019 07:26:47 -0400 Received: from foss.arm.com ([217.140.110.172]:40734 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387657AbfIWL0r (ORCPT ); Mon, 23 Sep 2019 07:26:47 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E29C2142F; Mon, 23 Sep 2019 04:26:46 -0700 (PDT) Received: from [10.1.194.37] (e113632-lin.cambridge.arm.com [10.1.194.37]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8451E3F694; Mon, 23 Sep 2019 04:26:45 -0700 (PDT) Subject: Re: sched: make struct task_struct::state 32-bit To: Julia Lawall Cc: Markus Elfring , Alexey Dobriyan , dm-devel@redhat.com, linux-block@vger.kernel.org, rcu@vger.kernel.org, linux-kernel@vger.kernel.org, Andrea Arcangeli , Ingo Molnar , Jens Axboe , Peter Zijlstra References: <7e3e784c-e8e6-f9ba-490f-ec3bf956d96b@web.de> <0c4dcb91-4830-0013-b8c6-64b9e1ce47d4@arm.com> <32d65b15-1855-e7eb-e9c4-81560fab62ea@arm.com> From: Valentin Schneider Message-ID: Date: Mon, 23 Sep 2019 12:26:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/09/2019 11:34, Julia Lawall wrote: >> // FIXME: current not recognized as task_struct*, fixhack with regexp >> identifier current =~ "^current$"; > > Please don't do this. Just use the word current. It doesn't have to be a > metavariable. You will though get a warning about it. To eliminate the > warning, you can say symbol current; > Didn't know about that way to get rid of the warning, thanks! >> identifier task_state =~ "^TASK_"; > > Are there a lot of options? You can also enumerate them in {}, ie > > identifier task_state = {TASK_BLAH, TASK_BLAHBLAH}; > Around a dozen, can be enumerated easily and is indeed probably better than a regexp. >> identifier state_var; >> position pos; >> @@ >> >> ( >> p->state & state_var@pos >> | >> current->state & state_var@pos >> | >> p->state | state_var@pos >> | >> current->state | state_var@pos >> | >> p->state < state_var@pos >> | >> current->state < state_var@pos >> | >> p->state > state_var@pos >> | >> current->state > state_var@pos >> | >> state_var@pos = p->state >> | >> state_var@pos = current->state >> | >> p->state == state_var@pos >> | >> current->state == state_var@pos >> | >> p->state != state_var@pos >> | >> current->state != state_var@pos >> | >> // FIXME: match functions that do something with state_var underneath? >> // How to do recursive rules? > > You want to look at the definitions of called functions? Coccinelle > doesn't really support that, but there are hackish ways to add that. How > many function calls would you expect have to be unrolled? > I wouldn't expect more than a handful (~5). I suppose this has to do with injecting some Python/Ocaml code? I have some examples bookmarked but haven't gotten to stare at them long enough. >> set_current_state(state_var@pos) >> | >> set_special_state(state_var@pos) >> | >> signal_pending_state(state_var@pos, p) >> | >> signal_pending_state(state_var@pos, current) >> | >> state_var@pos & task_state >> | >> state_var@pos | task_state >> ) >> >> // Fixup local variables >> @depends on patch && state_access@ >> identifier state_var = state_access.state_var; >> @@ >> ( >> - long >> + int >> | >> - unsigned long >> + unsigned int >> ) >> state_var; >> >> // Fixup function parameters >> @depends on patch && state_access@ >> identifier fn; >> identifier state_var = state_access.state_var; >> @@ >> >> fn(..., >> - long state_var >> + int state_var >> ,...) >> { >> ... >> } >> >> // FIXME: find a way to squash that with the above? > > I think that you can make a disjunction on a function parameter > > fn(..., > ( > - T1 x1 > + T2 x2 > | > - T3 x3 > + T4 x4 > ) > , ...) { ... } > My attempt at this gives me "minus: parse error", which is why I went with the split. Something simple like this works: --- virtual patch virtual report @@ identifier fn; identifier p; @@ fn(..., - long + int p ,...) { ... } --- but this doesn't: --- virtual patch virtual report @@ identifier fn; identifier p; @@ fn(..., ( - long p + int p | - unsigned long p + unsigned int p ) ,...) { ... } --- > julia >