Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp5916909ybp; Tue, 8 Oct 2019 10:07:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqyDgrVIni7z0e91yrelMdjCKgharE+joj6e96Pqo3BwZXe4QYqe1w6dGCE2jrl2874BatFW X-Received: by 2002:a05:6402:750:: with SMTP id p16mr35323296edy.188.1570554464009; Tue, 08 Oct 2019 10:07:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570554464; cv=none; d=google.com; s=arc-20160816; b=m3cD3+bqVYGYymVf5GXVskTw1WGpROEemaFoEreK0Mznhj8eWBD4BoYIdXkKv8n804 ckOFQxFoA2qYBwjDMmY0FYV71rYunAxZeeN5jxIWDQgT6ryUKgX35JQtvpmHwoubMjrF DHx0SDQG6d+w98AuG7GcKRZ19dgueyN7YF2I9H/uIcnjaJ6yOPpMgtD/fs3Z1CBi5kzm ycXweJjCvrac/w9rNabvZw44ja/Y8aDA+Ds+Y5EOWv1gQZvZPFJSA+Jv1TsT8l5oEsRS J1Cw8b9ZDoJqaWkWFZDeEzwuV1i6DpGGmU1dVdFrGMKqIsnHtpSuyMVdi63+NYkr0V9x HkSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ENAa+/lpX5O8pGlpwavdPSeQ0owxbOuHKg9UqXvqvVI=; b=00D1GEJ05wpjuBrF37Qo1QYH5DS0Qj/R5y/gHnbzF07YvtkrwLQefSWpXJvHV3wMT4 exifBT5zNWaKSMlODWjFLiSOOiLtDczf5PWA+wRQ1esewjtcooR/aniXXQoL0ut6cyP/ K+y4wlMMkdiZeA4gg7RwkPkt1SHllwLMC2maN25T+4+fBprHRTqs/R5kciv7ixh7rHYV tLCLXdMtJwqEJWIKZcaFhVgyrgvH5IQaJiqS8UgAe9+zKGB+K3mhJohUFlf9rIQRLGgH BxM6CGDvP2HlAjEAI7tkzQFSzVnYPc+9IuI3yNraC4JeLTNPZx6Qb5fsLIoC+md/yzAG e+jA== 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 j47si10486021ede.117.2019.10.08.10.07.19; Tue, 08 Oct 2019 10:07:43 -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 S1727771AbfJHRG4 (ORCPT + 99 others); Tue, 8 Oct 2019 13:06:56 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:60104 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725917AbfJHRG4 (ORCPT ); Tue, 8 Oct 2019 13:06:56 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.2 #3 (Red Hat Linux)) id 1iHswm-0005iH-Jz; Tue, 08 Oct 2019 17:06:53 +0000 Date: Tue, 8 Oct 2019 18:06:52 +0100 From: Al Viro To: Greg KH Cc: Linus Torvalds , Guenter Roeck , Linux Kernel Mailing List , linux-fsdevel Subject: Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user() Message-ID: <20191008170652.GU26530@ZenIV.linux.org.uk> References: <20191007025046.GL26530@ZenIV.linux.org.uk> <20191008032912.GQ26530@ZenIV.linux.org.uk> <20191008045712.GR26530@ZenIV.linux.org.uk> <20191008131416.GA2860109@kroah.com> <20191008152900.GT26530@ZenIV.linux.org.uk> <20191008153831.GA2881123@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191008153831.GA2881123@kroah.com> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 08, 2019 at 05:38:31PM +0200, Greg KH wrote: > On Tue, Oct 08, 2019 at 04:29:00PM +0100, Al Viro wrote: > > On Tue, Oct 08, 2019 at 03:14:16PM +0200, Greg KH wrote: > > > On Tue, Oct 08, 2019 at 05:57:12AM +0100, Al Viro wrote: > > > > > > > > OK... BTW, do you agree that the use of access_ok() in > > > > drivers/tty/n_hdlc.c:n_hdlc_tty_read() is wrong? It's used as an early > > > > cutoff, so we don't bother waiting if user has passed an obviously bogus > > > > address. copy_to_user() is used for actual copying there... > > > > > > Yes, it's wrong, and not needed. I'll go rip it out unless you want to? > > > > I'll throw it into misc queue for now; it has no prereqs and nothing is going > > to depend upon it. > > Great, thanks. > > > While looking for more of the same pattern: usb_device_read(). Frankly, > > usb_device_dump() calling conventions look ugly - it smells like it > > would be much happier as seq_file. Iterator would take some massage, > > but that seems to be doable. Anyway, that's a separate story... > > That's just a debugfs file, and yes, it should be moved to seq_file. I > think I tried it a long time ago, but given it's just a debugging thing, > I gave up as it wasn't worth it. > > But yes, the access_ok() there also seems odd, and should be dropped. I'm almost tempted to keep it there as a reminder/grep fodder ;-) Seriously, though, it might be useful to have a way of marking the places in need of gentle repair of retrocranial inversions _without_ attracting the "checkpatch warning of the week" crowd...