From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752888AbeAJUtk (ORCPT + 1 other); Wed, 10 Jan 2018 15:49:40 -0500 Received: from mail-io0-f177.google.com ([209.85.223.177]:46358 "EHLO mail-io0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751794AbeAJUtj (ORCPT ); Wed, 10 Jan 2018 15:49:39 -0500 X-Google-Smtp-Source: ACJfBos6euT8Uss/ahsNX1qBwnXl1jLf8BNKL+Dfxk00Em971pni0mm0wMUUYj9bALmNuUVjlPKF9/SAWeBZzZmELjo= MIME-Version: 1.0 In-Reply-To: <20180110203352.GS6176@hirez.programming.kicks-ass.net> References: <20180110003139.10531-1-andi@firstfloor.org> <1515568506.22302.72.camel@infradead.org> <1515578735.22302.91.camel@infradead.org> <20180110112815.mgciyf5acwacphkq@pd.tnic> <20180110201532.5jnji6ypfl6slzvb@treble> <20180110203352.GS6176@hirez.programming.kicks-ass.net> From: Linus Torvalds Date: Wed, 10 Jan 2018 12:49:37 -0800 X-Google-Sender-Auth: NlysSYVQaMVwByFj1vFsNqdUt4E Message-ID: Subject: Re: [PATCH] x86/alternatives: Fix optimize_nops() checking To: Peter Zijlstra Cc: Josh Poimboeuf , Thomas Gleixner , Borislav Petkov , David Woodhouse , Andi Kleen , "the arch/x86 maintainers" , Linux Kernel Mailing List , Paul Turner , Andrew Lutomirski , Tom Lendacky , Tim Chen , Greg Kroah-Hartman , Dave Hansen , Jiri Kosina , Andi Kleen Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Wed, Jan 10, 2018 at 12:33 PM, Peter Zijlstra wrote: > > Use gdb on /proc/kcore and disassemble self to see the _real_ code. Yes, because that works so well when you get these random reports of crazy behavior that simply doesn't ever trigger on any machine you have. > But yes, tricky stuff. Not arguing we need relocations in alternatives, > just saying debugging them (and static keys and others) is great fun. Yes. It's definitely a good challenge, and can be _very_ satisfying when you then finally figure it out. I'm not sure it's worth the pain before that point, though. So I think we should strive to make our alternatives code just catch some of the more subtle errors early instead. Linus