From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6EA17C49EA7 for ; Fri, 25 Jun 2021 11:16:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5884561477 for ; Fri, 25 Jun 2021 11:16:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231235AbhFYLSx (ORCPT ); Fri, 25 Jun 2021 07:18:53 -0400 Received: from www62.your-server.de ([213.133.104.62]:53788 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230359AbhFYLSw (ORCPT ); Fri, 25 Jun 2021 07:18:52 -0400 Received: from sslproxy01.your-server.de ([78.46.139.224]) by www62.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1lwjoz-0000r7-8Z; Fri, 25 Jun 2021 13:16:29 +0200 Received: from [85.7.101.30] (helo=linux-3.home) by sslproxy01.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lwjoz-0005f1-2J; Fri, 25 Jun 2021 13:16:29 +0200 Subject: Re: [PATCH bpf] net/bpfilter: specify the log level for the kmsg message To: Dmitrii Banshchikov , Alexei Starovoitov Cc: Gary Lin , Alexei Starovoitov , bpf , Network Development , Martin Loviska References: <20210623040918.8683-1-glin@suse.com> <20210623065744.igawwy424y2zy26t@amnesia> <20210625073621.zmd2w33wi335lya3@amnesia> From: Daniel Borkmann Message-ID: Date: Fri, 25 Jun 2021 13:16:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20210625073621.zmd2w33wi335lya3@amnesia> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.103.2/26211/Thu Jun 24 13:04:24 2021) Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 6/25/21 9:36 AM, Dmitrii Banshchikov wrote: > On Thu, Jun 24, 2021 at 08:47:06PM -0700, Alexei Starovoitov wrote: >> On Tue, Jun 22, 2021 at 11:57 PM Dmitrii Banshchikov wrote: >>> On Tue, Jun 22, 2021 at 09:38:38PM -0700, Alexei Starovoitov wrote: >>>> On Tue, Jun 22, 2021 at 9:09 PM Gary Lin wrote: >>>>> >>>>> Per the kmsg document(*), if we don't specify the log level with a >>>>> prefix "" in the message string, the default log level will be >>>>> applied to the message. Since the default level could be warning(4), >>>>> this would make the log utility such as journalctl treat the message, >>>>> "Started bpfilter", as a warning. To avoid confusion, this commit adds >>>>> the prefix "<5>" to make the message always a notice. >>>>> >>>>> (*) https://www.kernel.org/doc/Documentation/ABI/testing/dev-kmsg >>>>> >>>>> Fixes: 36c4357c63f3 ("net: bpfilter: print umh messages to /dev/kmsg") >>>>> Reported-by: Martin Loviska >>>>> Signed-off-by: Gary Lin >>>>> --- >>>>> net/bpfilter/main.c | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/net/bpfilter/main.c b/net/bpfilter/main.c >>>>> index 05e1cfc1e5cd..291a92546246 100644 >>>>> --- a/net/bpfilter/main.c >>>>> +++ b/net/bpfilter/main.c >>>>> @@ -57,7 +57,7 @@ int main(void) >>>>> { >>>>> debug_f = fopen("/dev/kmsg", "w"); >>>>> setvbuf(debug_f, 0, _IOLBF, 0); >>>>> - fprintf(debug_f, "Started bpfilter\n"); >>>>> + fprintf(debug_f, "<5>Started bpfilter\n"); >>>>> loop(); >>>>> fclose(debug_f); >>>>> return 0; >>>> >>>> Adding Dmitrii who is redesigning the whole bpfilter. >>> >>> Thanks. The same logic already exists in the bpfilter v1 patchset >>> - [1]. >>> >>> 1. https://lore.kernel.org/bpf/c72bac57-84a0-ac4c-8bd8-08758715118e@fb.com/T/#mb36e20c4e5e4a70746bd50a109b1630687990214 >> >> Dmitrii, >> >> what do you prefer we should do with this patch then? > > There was an explicit request to make an event of loading a UMH > visible - [1]. Given that the default for MaxLevelConsole is info > and the patch makes the behavior slightly more accurate - ack > from me. Ok, sounds good, applied, thanks!