Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753281AbdLSWQg (ORCPT ); Tue, 19 Dec 2017 17:16:36 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:50609 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751496AbdLSWQd (ORCPT ); Tue, 19 Dec 2017 17:16:33 -0500 Date: Tue, 19 Dec 2017 14:16:25 -0800 From: Matthew Wilcox To: Linus Torvalds 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 Subject: Re: BUG: bad usercopy in memdup_user Message-ID: <20171219221625.GB22696@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1106 Lines: 26 On Tue, Dec 19, 2017 at 01:36:46PM -0800, Linus Torvalds wrote: > 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. Yeah, but the problem is that until people know to expect hashes, it breaks people. I spent most of a day last week puzzling over a value coming from a VM_BUG_ON that was explicitly tested for and couldn't happen. > When we find something like this, we should either remove it, fix the > permissions, or switch to %px. Right; I sent a patch to fix VM_BUG_ON earlier today after reading this thread. > But honestly, what do people expect that the pointer value will > actually tell you if it is unhashed? It would have been meaningful to me. For a start, I would have seen that the bottom two bits were clear, so this was actually a pointer and not something masquerading as a pointer.