Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753712AbdLSVgx (ORCPT ); Tue, 19 Dec 2017 16:36:53 -0500 Received: from mail-it0-f41.google.com ([209.85.214.41]:35714 "EHLO mail-it0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752585AbdLSVgr (ORCPT ); Tue, 19 Dec 2017 16:36:47 -0500 X-Google-Smtp-Source: ACJfBot00U/pn+rtkAHFXNqcLWbCuA3KTxtmKRcO1iR1qSDczKZIOUWAM5TLgxBaP+0CvXo3BtbdoRxdMGQN+zb4Yjo= MIME-Version: 1.0 In-Reply-To: <20171219132246.GD13680@bombadil.infradead.org> References: <001a113e9ca8a3affd05609d7ccf@google.com> <6a50d160-56d0-29f9-cfed-6c9202140b43@I-love.SAKURA.ne.jp> <20171219083746.GR19604@eros> <20171219132246.GD13680@bombadil.infradead.org> From: Linus Torvalds Date: Tue, 19 Dec 2017 13:36:46 -0800 X-Google-Sender-Auth: J_BnViJQ1BHr2Las5rnbnklMk-k Message-ID: Subject: Re: BUG: bad usercopy in memdup_user To: Matthew Wilcox Cc: "Tobin C. Harding" , Dmitry Vyukov , Kees Cook , Tetsuo Handa , Linux-MM , syzbot , David Windsor , keun-o.park@darkmatter.ae, Laura Abbott , LKML , Mark Rutland , Ingo Molnar , syzkaller-bugs@googlegroups.com, Will Deacon 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: 1569 Lines: 41 On Tue, Dec 19, 2017 at 5:22 AM, Matthew Wilcox wrote: > > Could we have a way to know that the printed address is hashed and not just > a pointer getting completely scrogged? Perhaps prefix it with ... a hash! > So this line would look like: The problem with that is that it will break tools that parse things. So no, it won't work. When we find something like this, we should either remove it, fix the permissions, or switch to %px. In this case, there's obviously no permission issue: it's an error report. So it's either "remove it, or switch to %px". I'm personally not clear on whether the pointer really makes any sense at all. But if it does, it should just be changed to %px, since it's a bug report. But honestly, what do people expect that the pointer value will actually tell you if it is unhashed? I suspect that an "offset and size within the kernel object" value might make sense. But what does the _pointer_ tell you? I've noticed this with pretty much every report. People get upset about the hashing, but don't seem to actually be able to ever tell what the f*ck they would use the non-hashed pointer value for. I've asked for this before: whenever somebody complains about the hashing, you had better tell exactly what the unhashed value would have given you, and how it would have helped debug the problem. Because if you can't tell that, then dammit, then we should just _remove_ the stupid %p. Instead, people ask for "can I get everything unhashed" even when they can't give a reason for it. Linus