From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752857AbdK2E1w (ORCPT ); Tue, 28 Nov 2017 23:27:52 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:43491 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752534AbdK2E1u (ORCPT ); Tue, 28 Nov 2017 23:27:50 -0500 X-ME-Sender: Date: Wed, 29 Nov 2017 15:27:46 +1100 From: "Tobin C. Harding" To: Steven Rostedt Cc: kernel-hardening@lists.openwall.com, Linus Torvalds , "Jason A. Donenfeld" , "Theodore Ts'o" , Kees Cook , Paolo Bonzini , Tycho Andersen , "Roberts, William C" , Tejun Heo , Jordan Glover , Greg KH , Petr Mladek , Joe Perches , Ian Campbell , Sergey Senozhatsky , Catalin Marinas , Will Deacon , Chris Fries , Dave Weinstein , Daniel Micay , Djalal Harouni , Radim =?utf-8?B?S3LEjW3DocWZ?= , linux-kernel@vger.kernel.org, Network Development , David Miller , Stephen Rothwell , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Andrew Morton Subject: Re: [PATCH V11 2/5] vsprintf: refactor %pK code out of pointer() Message-ID: <20171129042746.GF15500@eros> References: <1511921105-3647-1-git-send-email-me@tobin.cc> <1511921105-3647-3-git-send-email-me@tobin.cc> <20171128213957.2edf5069@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171128213957.2edf5069@gandalf.local.home> X-Mailer: Mutt 1.5.24 (2015-08-30) User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 28, 2017 at 09:39:57PM -0500, Steven Rostedt wrote: > On Wed, 29 Nov 2017 13:05:02 +1100 > "Tobin C. Harding" wrote: > > > + /* > > + * kptr_restrict==1 cannot be used in IRQ context > > + * because its test for CAP_SYSLOG would be meaningless. > > + */ > > + if (in_irq() || in_serving_softirq() || in_nmi()) > > This could be replaced with: > > if (!in_task()) > > Which is actually more efficient. thanks for the comment Steve. At this late stage in the game do you mind if I don't include this change in this set. The code line in question is only in the series because of refactoring. I'm comfortable arguing that improving efficiency is out of scope ;) thanks, Tobin.