Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753396AbdHULYf (ORCPT ); Mon, 21 Aug 2017 07:24:35 -0400 Received: from mx2.suse.de ([195.135.220.15]:58669 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752804AbdHULYe (ORCPT ); Mon, 21 Aug 2017 07:24:34 -0400 Date: Mon, 21 Aug 2017 13:24:32 +0200 From: Petr Mladek To: Joe Lawrence Cc: live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Josh Poimboeuf , Jessica Yu , Jiri Kosina , Miroslav Benes Subject: Re: [PATCH v4] livepatch: introduce shadow variable API Message-ID: <20170821112432.GB27895@pathway.suse.cz> References: <1502740963-31310-1-git-send-email-joe.lawrence@redhat.com> <1502740963-31310-2-git-send-email-joe.lawrence@redhat.com> <20170817140545.GF601@pathway.suse.cz> <461bd75a-c1bb-e616-c9af-83b969df7344@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <461bd75a-c1bb-e616-c9af-83b969df7344@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1236 Lines: 34 On Fri 2017-08-18 16:25:42, Joe Lawrence wrote: > On 08/17/2017 10:05 AM, Petr Mladek wrote: > > On Mon 2017-08-14 16:02:43, Joe Lawrence wrote: > >> [ ... snip ... ] > >> + /* Allocate a new shadow variable for use inside the lock below */ > >> + new_shadow = kzalloc(size + sizeof(*new_shadow), gfp_flags); > > > > We should print an error message when the memory cannot be allocated. > > Otherwise we will return NULL without explanation. It will be > > especially helpful when a caller forgets to check for NULL. > > Interesting, I hadn't seen this checkpatch complaint before: > > WARNING: Possible unnecessary 'out of memory' message > #416: FILE: kernel/livepatch/shadow.c:143: > + if (!new_shadow) { > + pr_err("failed to allocate shadow variable <0x%p, %lu>\n", > > Discussion thread: > https://lkml.org/lkml/2014/6/10/382 Interesting, I was not aware of this. > Think the stack trace that the memory subsystem would emit is good > enough, or would you like to see for debugging purposes? I agree that the backtrace should be enough to locate the problematic call quickly. Feel free to omit it. Now, I just need to update my patterns when looking for problematic code. Best Regards, Petr