Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5400710ybi; Wed, 12 Jun 2019 01:46:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqyFz5sLk8ewrMm3OFIvNYFuL0AxZ6XY/ppRQCah5ZNeaFUQS+IHSRLGjYQx/qSRIeS0cMrb X-Received: by 2002:a17:902:b215:: with SMTP id t21mr79906975plr.152.1560329180263; Wed, 12 Jun 2019 01:46:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560329180; cv=none; d=google.com; s=arc-20160816; b=Kz349y8eU3ukFY5jwTELZJSSFXfLvUPeB03TSfIGJiFqj3HiZ94gXzUDbeOU4sfc27 di7ls1MIwspWNNshdqVw137hNM9f5fTwGlzPIWzniaz+zeZbPlcst5V073e8xfCq30mh nxDQXF5E/H/Ka2GXJ7xwEGeVXXPvuXlsnNVMQd4i6NbzlEtNkpnVYiydV8sy1GNCZvuC P/hVF2c+5DJtmevfM4nqoCez8zNB9MxED6cFeJ5Lx5vaLpqWDUuy6m3jy0PGCpZIFkC2 5jdYQdV3jiQkE/ORsqrI7YNT1bNT8pm8vqxycKpY565s2NCbLrh2K7DybXOCwLawqH75 yIHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Br7r3cXpoG+1hsKvexnW3XXzFw0uhMbH679ILNFB8Gk=; b=Jrfz4AGBS90zF/rxD5I8zTN3fpoxDWJbKPjDyeo7P0wjM+V80GXijGTH64y6s8WmcV ZUOgpPunvlXdBLLyCGyvcQ9QQ0lHaWrptGCRKbRA6Hhh3fDNf06I4oHgSDaikKTyZcqt 443DRPOpLPrXD3wqvw3tb+wIvHjySp/6WZ8LeCI0CJ8nV1IHOgP50Q+5xncBejpyredb hNQ3cBcuuauAQ6x0G5P1imNu51JoOG8HAa03r5ytgHSNZ7wJuHbLQb69m6Y0QE9W2IoP XrAxcxtc2jvn9NK9V2RB47q/wY8TScE3H1Ey0fe3/hPTOI0lewVH2FdXJR6RBbB9OvNf kv5Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m2si4833761pjk.63.2019.06.12.01.46.04; Wed, 12 Jun 2019 01:46:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2436763AbfFLIMp (ORCPT + 99 others); Wed, 12 Jun 2019 04:12:45 -0400 Received: from mx2.suse.de ([195.135.220.15]:42844 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730479AbfFLIMp (ORCPT ); Wed, 12 Jun 2019 04:12:45 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D8BF6AF03; Wed, 12 Jun 2019 08:12:43 +0000 (UTC) Date: Wed, 12 Jun 2019 10:12:43 +0200 From: Petr Mladek To: Miroslav Benes Cc: jpoimboe@redhat.com, jikos@kernel.org, joe.lawrence@redhat.com, kamalesh@linux.vnet.ibm.com, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner Subject: Re: [PATCH v4 1/3] stacktrace: Remove weak version of save_stack_trace_tsk_reliable() Message-ID: <20190612081243.4pnj4bqpy4xto6nf@pathway.suse.cz> References: <20190611141320.25359-1-mbenes@suse.cz> <20190611141320.25359-2-mbenes@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190611141320.25359-2-mbenes@suse.cz> User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 2019-06-11 16:13:18, Miroslav Benes wrote: > Recent rework of stack trace infrastructure introduced a new set of > helpers for common stack trace operations (commit e9b98e162aa5 > ("stacktrace: Provide helpers for common stack trace operations") and > related). As a result, save_stack_trace_tsk_reliable() is not directly > called anywhere. Livepatch, currently the only user of the reliable > stack trace feature, now calls stack_trace_save_tsk_reliable(). > > When CONFIG_HAVE_RELIABLE_STACKTRACE is set and depending on > CONFIG_ARCH_STACKWALK, stack_trace_save_tsk_reliable() calls either > arch_stack_walk_reliable() or mentioned save_stack_trace_tsk_reliable(). > x86_64 defines the former, ppc64le the latter. All other architectures > do not have HAVE_RELIABLE_STACKTRACE and include/linux/stacktrace.h > defines -ENOSYS returning version for them. > > In short, stack_trace_save_tsk_reliable() returning -ENOSYS defined in > include/linux/stacktrace.h serves the same purpose as the old weak > version of save_stack_trace_tsk_reliable() which is therefore no longer > needed. > > Cc: Thomas Gleixner > Signed-off-by: Miroslav Benes Reviewed-by: Petr Mladek Best Regards, Petr