Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp3944328ybi; Mon, 3 Jun 2019 03:05:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqzBUFai9+os7ygjj8VTbdHQs0wXLvcGaxGXHNIhpeYQ4xLJAUAwF/kr8BTN087jaiM2MtdK X-Received: by 2002:a63:5457:: with SMTP id e23mr1446137pgm.307.1559556333266; Mon, 03 Jun 2019 03:05:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559556333; cv=none; d=google.com; s=arc-20160816; b=Rtrcjvw2eOknjKhkMNs3/IBU3mJtVQEPs5TJiFbAOC3foMCoDoBufHIzOqaToeihff 7IcQrmNC05Qz2IlIszGfmv5KvbvZPLi+biHfbcYJq1oxQJUr4z7KT1e8SWvwP40gjW6x 5Xfmrnpk01sVXZBbIc+OHwSUZgyiIPvLFbbfqrm1ahbuRqPzX/+MH9DlaTTnWTCqV4WH pPvTGhCfe4gLtzD0sZ1uiPfdoANnQ0AtacdUGJ63oI6P+EAd8YMl0WvztpRULC9u/KmX jim8GHhJYbYhzkGsTnDz6luh/7DhFM6sFsuJRPSW5ivTwizVK51nXIYMjJzdFsWOUDfY k/FQ== 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=+2+Zo8zV6av36ZrixvBTklWs9B+xI7QdOqP5ZANAxR8=; b=vu9qGkWsIqP/zM05mjcFRMvFnpqBMo/wdio0EKSEapGyHl30d21IdSYX6nbR65KYb+ TlyZw8RAfND/JXpuSSrpUSrmECHdpagHEzSWvV+LLMUBHJMtaPLbOgg2NL9lsAcL9TwH r3ZNuuILxdkuW3phlPsi7e7wIQw0le1AF5WzAb7qQrHYbKNaXjZxrAjzXy6Kp92k/452 NJLDZm13QFClDoYii9qjrNSOmuzXbDV7xkprANYFMB4PJhWrSSC5ABvbnrvnKy0cdEYR wnVtYbRzk32fmrJh5d+aET1D8LirgUTdDZ31n+RFwdDX0XRATPFAKQnv9YnfdYrsYrNK quLQ== 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 3si18164022plv.102.2019.06.03.03.05.15; Mon, 03 Jun 2019 03:05:33 -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 S1727535AbfFCIHa (ORCPT + 99 others); Mon, 3 Jun 2019 04:07:30 -0400 Received: from mx2.suse.de ([195.135.220.15]:55122 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725856AbfFCIHa (ORCPT ); Mon, 3 Jun 2019 04:07:30 -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 7EDBFB133; Mon, 3 Jun 2019 08:07:29 +0000 (UTC) Date: Mon, 3 Jun 2019 10:07:29 +0200 From: Petr Mladek To: Miroslav Benes Cc: Jiri Kosina , Josh Poimboeuf , Joe Lawrence , Kamalesh Babulal , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/3] livepatch: Use static buffer for debugging messages under rq lock Message-ID: <20190603080729.67je4pl4epsjtgtg@pathway.suse.cz> References: <20190531074147.27616-1-pmladek@suse.com> <20190531074147.27616-4-pmladek@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Fri 2019-05-31 14:37:52, Miroslav Benes wrote: > On Fri, 31 May 2019, Petr Mladek wrote: > > > The err_buf array uses 128 bytes of stack space. Move it off the stack > > by making it static. It's safe to use a shared buffer because > > klp_try_switch_task() is called under klp_mutex. > > > > diff --git a/kernel/livepatch/transition.c b/kernel/livepatch/transition.c > > index 1bf362df76e1..5c4f0c1f826e 100644 > > --- a/kernel/livepatch/transition.c > > +++ b/kernel/livepatch/transition.c > > @@ -327,7 +327,6 @@ static bool klp_try_switch_task(struct task_struct *task) > > pr_debug("%s", err_buf); > > > > return success; > > - > > } > > This could go in separately as it is not connected to the rest of the > series. I have never seen a standalone commit just removing an empty line. It is usually done when one touches the code around. If you resist, we could omit this hunk from the patch and leave the code as is. Best Regards, Petr