Re: [PATCH bpf] net/bpfilter: specify the log level for the kmsg message

[Daniel Borkmann <daniel@iogearbox.net>]

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 <me@ubique.spb.ru> 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 <glin@suse.com> wrote:
>>>>>
>>>>> Per the kmsg document(*), if we don't specify the log level with a
>>>>> prefix "<N>" 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 <mloviska@suse.com>
>>>>> Signed-off-by: Gary Lin <glin@suse.com>
>>>>> ---
>>>>>   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!