From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by kanga.kvack.org (Postfix) with ESMTP id 752286B0003 for ; Thu, 28 Jun 2018 02:18:03 -0400 (EDT) Received: by mail-ed1-f71.google.com with SMTP id w22-v6so899334edr.14 for ; Wed, 27 Jun 2018 23:18:03 -0700 (PDT) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id o12-v6sor2120117edr.4.2018.06.27.23.18.01 for (Google Transport Security); Wed, 27 Jun 2018 23:18:01 -0700 (PDT) Date: Thu, 28 Jun 2018 08:17:59 +0200 From: Luc Van Oostenryck Subject: Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel Message-ID: <20180628061758.j6bytsaj5jk4aocg@ltop.local> References: <20180626172900.ufclp2pfrhwkxjco@armageddon.cambridge.arm.com> <0cef1643-a523-98e7-95e2-9ec595137642@arm.com> <20180627171757.amucnh5znld45cpc@armageddon.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180627171757.amucnh5znld45cpc@armageddon.cambridge.arm.com> Sender: owner-linux-mm@kvack.org List-ID: To: Catalin Marinas Cc: Ramana Radhakrishnan , Andrey Konovalov , Mark Rutland , Kate Stewart , "linux-doc@vger.kernel.org" , Will Deacon , Kostya Serebryany , "linux-kselftest@vger.kernel.org" , Chintan Pandya , Shuah Khan , Ingo Molnar , "linux-arch@vger.kernel.org" , Jacob Bramley , Dmitry Vyukov , Evgeniy Stepanov , Kees Cook , Ruben Ayrapetyan , Al Viro nd , Linux ARM , Linux Memory Management List , Greg Kroah-Hartman , LKML , Lee Smith , Andrew Morton , Robin Murphy , "Kirill A . Shutemov" On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote: > > sparse is indeed an option. The current implementation doesn't warn on > an explicit cast from (void __user *) to (unsigned long) since that's a > valid thing in the kernel. I couldn't figure out if there's any other > __attribute__ that could be used to warn of such conversion. Hi, sparse doesn't have such attribute but would an new option that would warn on such cast be a solution for your case? -- Luc