Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751113AbdFTHM1 (ORCPT ); Tue, 20 Jun 2017 03:12:27 -0400 Received: from mail-io0-f171.google.com ([209.85.223.171]:34576 "EHLO mail-io0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750925AbdFTHMZ (ORCPT ); Tue, 20 Jun 2017 03:12:25 -0400 MIME-Version: 1.0 X-Originating-IP: [2a02:168:5640:0:960b:2678:e223:c1c6] In-Reply-To: <20170619163438.GE10672@ZenIV.linux.org.uk> References: <20170619161509.GA25997@jcrouse-lnx.qualcomm.com> <20170619163438.GE10672@ZenIV.linux.org.uk> From: Daniel Vetter Date: Tue, 20 Jun 2017 09:12:23 +0200 X-Google-Sender-Auth: 9F5ukussNeJA3NIe7BuT2Cz-ZXk Message-ID: Subject: Re: __user with scalar data types To: Al Viro , "Clark, Rob" , Gerd Hoffmann Cc: linux-sparse@vger.kernel.org, Linux Kernel Mailing List , dri-devel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1171 Lines: 27 On Mon, Jun 19, 2017 at 6:34 PM, Al Viro wrote: > On Mon, Jun 19, 2017 at 10:15:09AM -0600, Jordan Crouse wrote: > >> Which raised a bikeshed debate over whether it is appropriate to mark a scalar >> type as __user. My opinion is that it is appropriate because __user should mark >> user memory regardless of the container. > > What the hell? __user is a qualifier like const, volatile, etc. It's a property > of *pointer* *type*. Not some nebulous "marks userland memory" thing. > >> I'm looking for opinions or semi-authoritative edicts to determine if we should >> either start changing our uapi headers or go off and try to figure out how to >> make sparse understand this particular usage. > > Stop cargo-culting, please. Yep that's cargo-culted, but from a quick grep only msm and qxl headers do this (the other __user annotations in uapi/drm are for pointers, where it's correct). Adding those maintainers. Also, if you use u64_to_user_ptr helper macro sparse should have caught this (if not we'd need to improve the macro). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch