Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1511815ybk; Thu, 14 May 2020 10:44:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyBibuEcYnQmasOEP/EcrmAJNPHNvjsRfzJx8a1+njkSuFUM+uSTt0J1YHlX3zafDL6FhmB X-Received: by 2002:a50:c90b:: with SMTP id o11mr4952069edh.311.1589478251004; Thu, 14 May 2020 10:44:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589478250; cv=none; d=google.com; s=arc-20160816; b=xonp1Primn3DNWtFkvKv6T03kdivy/FxdoYHKsxg2nwHdQ8mLCK9FT1ryv0coUXBwd ZFuiA1P7JVRxw/IRZdYCjjXB1SQqM/WbJL0dYR6mRNqy07GdmVpEp1KDBEgrdJxhQbEd nWGa/oprGexqrTgtS/DJCjCcWi2ByM5bVY86KNSw1zTbmUevbXMnD7i9dEJkN1olslw4 e2G1MhgA3omffpdPgbjvSSzF9JTceMJewkIvv9SLFzzwyMTLHjEGU3FkI5gl2L9MrXLj k4DFaTIO8KY99xDpl0l8Ke896k+jNLS+m6gYFmi62XHillgyzuj2fbOGeeGG5DsSsMMW DhsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=cxSNu92aWEbJHTYubFPlwkzoVdqhcuZVPdl0s0Mm9ZQ=; b=pGkAUE3TxvTtoXP6dW1AOB9g0/1OeS66sPPpk9+WpfVZCbcc5bsTYTWO6dK/TgOCq8 XI+N2zft9mVZvBu+CKfkzAulw/sfQk+RjkYywmGq5w4Qmy6evIIj042y6eEwNW8cNR4C EtWkPM8ZnDmXKOKAhe7NjuYsZQ7NgPaPcxUcsCzuN6o1dPS9tMTVxj+TYUbWU9C8l/XV d39Db54N6Taq1LZ3Q0XH1w2oKTiXKEXLNIDetY/Bci7mnxl7f870PSlKiFJBkeTe+jKW pIqI2ztPE1FBuQGSuTek8PcObVMCm44inOe9XiiJ1S1/nu3hzYVV++4AL0xcg/feK4z7 63dw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c20si2399637edn.476.2020.05.14.10.43.46; Thu, 14 May 2020 10:44:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726240AbgENRll (ORCPT + 99 others); Thu, 14 May 2020 13:41:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1725975AbgENRll (ORCPT ); Thu, 14 May 2020 13:41:41 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 24CB4C061A0C; Thu, 14 May 2020 10:41:41 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jZHrP-008NZt-Fd; Thu, 14 May 2020 17:41:31 +0000 Date: Thu, 14 May 2020 18:41:31 +0100 From: Al Viro To: Bartlomiej Zolnierkiewicz Cc: linux-kernel@vger.kernel.org, Linus Torvalds , linux-fsdevel@vger.kernel.org Subject: Re: [PATCH 11/20] amifb: get rid of pointless access_ok() calls Message-ID: <20200514174131.GD23230@ZenIV.linux.org.uk> References: <20200509234124.GM23230@ZenIV.linux.org.uk> <20200509234557.1124086-1-viro@ZenIV.linux.org.uk> <20200509234557.1124086-11-viro@ZenIV.linux.org.uk> <6f89732b-fba9-a947-6c61-5d1680747f3b@samsung.com> <20200514140720.GB23230@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 14, 2020 at 04:25:35PM +0200, Bartlomiej Zolnierkiewicz wrote: > Thank you for in-detail explanations, for this patch: > > Acked-by: Bartlomiej Zolnierkiewicz > > Could you also please take care of adding missing checks for {get,put}_user() > failures later? Umm... OK; put_user() side is trivial - the interesting part is what to do about get_user() failures halfway through. Right now it treats them as "we'd read zeroes". On anything else I would say "screw it, memdup_user() the damn thing on the way in and copy from there", but... Amiga has how much RAM, again? OTOH, from my reading of that code it does appear to be limited to 4Kb of data to copy, so it's probably OK... Hell knows - I'm really confused by those #ifdef __mc68000__ in there; the driver *is* amiga-only: obj-$(CONFIG_FB_AMIGA) += amifb.o c2p_planar.o config FB_AMIGA tristate "Amiga native chipset support" depends on FB && AMIGA and AMIGA is defined only in arch/m68k/Kconfig.machine. So how the hell can it *not* be true? OTOH, it looks like hand-optimized asm equivalents of C they have in #else, so that #else might be meant to document what's going on... I've no idea how to test any changes to that thing - the only m68k emulator I'm reasonably familiar with is aranym, and that's Atari, not Amiga. Never got around to setting up UAE... So I can do a patch more or less blindly (memdup_user() after it has checked the limits on height/width, then dereferencing from copy instead of get_user()), but I won't be able to test it.