From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Berg Subject: Re: gcc tickets for sparse attributes Date: Fri, 17 Jan 2014 11:23:25 +0100 Message-ID: <1389954205.10404.1.camel@jlt4.sipsolutions.net> References: <52D8BF2C.9090604@zytor.com> <1389947596.4354.2.camel@jlt4.sipsolutions.net> <20140117092223.GC577@leaf> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from s3.sipsolutions.net ([144.76.43.152]:46608 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751296AbaAQKX3 (ORCPT ); Fri, 17 Jan 2014 05:23:29 -0500 In-Reply-To: <20140117092223.GC577@leaf> Sender: linux-sparse-owner@vger.kernel.org List-Id: linux-sparse@vger.kernel.org To: Josh Triplett Cc: "H. Peter Anvin" , Linux-Sparse , Linux Kernel Mailing List > > IMHO the context extension doesn't work well enough in sparse to > > document and implement as is. It would be much better if it actually was > > able to differentiate between contexts, rather than treating each one > > the same. > > That would certainly be nice, but that's something actually much more > easily done in GCC than in Sparse, given the types of information GCC > already has available to implement features like alias analysis. Right. > In any case, the spec I wrote up assumes a distinction between contexts, > but allows for an initial implementation like Sparse's that ignores the > distinction. Ok cool. :) > > This would avoid the problem that locking one lock and > > unlocking another (in the kernel's __acquire/ __release mechanism) could > > still result in a warning. > > That would actually *not* produce a warning, though it should. In > general, I *think* an implementation like Sparse's that ignores the > distinction between locks should produce false negatives but not false > positives. Right, it doesn't report one now. johannes