All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sven Schnelle <svens@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>
Cc: Yafang Shao <laoar.shao@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	netdev <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
	"linux-perf-use." <linux-perf-users@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org, Linux MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	kernel test robot <oliver.sang@intel.com>,
	kbuild test robot <lkp@intel.com>,
	Andrii Nakryiko <andrii@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
	Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	Michal Miroslaw <mirq-linux@rere.qmqm.pl>,
	Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Matthew Wilcox <willy@infradead.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Kees Cook <keescook@chromium.org>, Petr Mladek <pmladek@suse.com>
Subject: Re: [PATCH v2 7/7] tools/testing/selftests/bpf: replace open-coded 16 with TASK_COMM_LEN
Date: Mon, 29 Nov 2021 15:38:43 +0100	[thread overview]
Message-ID: <yt9dy257uivg.fsf@linux.ibm.com> (raw)
In-Reply-To: <54e1b56c-e424-a4b3-4d61-3018aa095f36@redhat.com> (David Hildenbrand's message of "Mon, 29 Nov 2021 15:32:26 +0100")

Hi,

David Hildenbrand <david@redhat.com> writes:
> On 29.11.21 15:21, Sven Schnelle wrote:
>> Yafang Shao <laoar.shao@gmail.com> writes:
>>> Thanks for the report and debugging!
>>> Seems we should explicitly define it as signed ?
>>> Could you pls. help verify it?
>>>
>>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>>> index cecd4806edc6..44d36c6af3e1 100644
>>> --- a/include/linux/sched.h
>>> +++ b/include/linux/sched.h
>>> @@ -278,7 +278,7 @@ struct task_group;
>>>   * Define the task command name length as enum, then it can be visible to
>>>   * BPF programs.
>>>   */
>>> -enum {
>>> +enum SignedEnum {
>>>         TASK_COMM_LEN = 16,
>>>  };
>> 
>> Umm no. What you're doing here is to define the name of the enum as
>> 'SignedEnum'. This doesn't change the type. I think before C++0x you
>> couldn't force an enum type.
>
> I think there are only some "hacks" to modify the type with GCC. For
> example, with "__attribute__((packed))" we can instruct GCC to use the
> smallest type possible for the defined enum values.

Yes, i meant no way that the standard defines. You could force it to
signed by having a negative member.

> I think with some fake entries one can eventually instruct GCC to use an
> unsigned type in some cases:
>
> https://stackoverflow.com/questions/14635833/is-there-a-way-to-make-an-enum-unsigned-in-the-c90-standard-misra-c-2004-compl
>
> enum {
> 	TASK_COMM_LEN = 16,
> 	TASK_FORCE_UNSIGNED = 0x80000000,
> };
>
> Haven't tested it, though, and I'm not sure if we should really do that
> ... :)

TBH, i would vote for reverting the change. defining an array size as
enum feels really odd.

Regards
Sven

  reply	other threads:[~2021-11-29 14:41 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-20 11:27 [PATCH v2 0/7] task comm cleanups Yafang Shao
2021-11-20 11:27 ` [PATCH v2 1/7] fs/exec: replace strlcpy with strscpy_pad in __set_task_comm Yafang Shao
2021-11-20 11:27 ` [PATCH v2 2/7] fs/exec: replace strncpy with strscpy_pad in __get_task_comm Yafang Shao
2021-11-20 11:27 ` [PATCH v2 3/7] drivers/infiniband: replace open-coded string copy with get_task_comm Yafang Shao
2021-11-20 11:27 ` [PATCH v2 4/7] fs/binfmt_elf: " Yafang Shao
2021-11-29 16:01   ` Steven Rostedt
2021-11-30  3:01     ` Yafang Shao
2021-11-30 14:22       ` Steven Rostedt
2021-11-30 15:53         ` Yafang Shao
2021-11-20 11:27 ` [PATCH v2 5/7] samples/bpf/test_overhead_kprobe_kern: replace bpf_probe_read_kernel with bpf_probe_read_kernel_str to get task comm Yafang Shao
2021-11-20 11:27 ` [PATCH v2 6/7] tools/bpf/bpftool/skeleton: " Yafang Shao
2021-11-20 11:27 ` [PATCH v2 7/7] tools/testing/selftests/bpf: replace open-coded 16 with TASK_COMM_LEN Yafang Shao
2021-11-29 10:13   ` Sven Schnelle
2021-11-29 13:41     ` Yafang Shao
2021-11-29 14:21       ` Sven Schnelle
2021-11-29 14:32         ` David Hildenbrand
2021-11-29 14:38           ` Sven Schnelle [this message]
2021-11-29 15:33             ` Yafang Shao
2021-11-29 16:07               ` Steven Rostedt
2021-11-29 16:08                 ` Steven Rostedt
2021-11-29 15:28         ` Yafang Shao
2021-11-29 17:30     ` Steven Rostedt
2021-11-29 17:56       ` Sven Schnelle
2021-11-30  3:03       ` Yafang Shao
2021-11-30 14:23         ` Steven Rostedt
2021-11-30 15:46           ` Yafang Shao
2023-02-08 21:55   ` John Stultz
2023-02-09  0:10     ` Alexei Starovoitov
2023-02-09  0:54       ` John Stultz
2023-02-09  2:06         ` Mathieu Desnoyers
2023-02-09  6:20           ` Yafang Shao
2023-02-09 14:27             ` Kajetan Puchalski
2023-02-09 15:37               ` Yafang Shao
2023-02-10 18:09                 ` Kajetan Puchalski
2023-02-11 16:51                 ` Qais Yousef
2023-02-12  3:19                   ` Yafang Shao
2023-02-09  2:28         ` Steven Rostedt
2023-02-09  2:33           ` Steven Rostedt
2023-02-11 19:00             ` Steven Rostedt
2023-02-12  3:38               ` Yafang Shao
2023-02-12  3:44                 ` Steven Rostedt
2023-02-13 17:43                   ` Namhyung Kim
2023-02-13 17:46                     ` Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yt9dy257uivg.fsf@linux.ibm.com \
    --to=svens@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=arnaldo.melo@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=david@redhat.com \
    --cc=keescook@chromium.org \
    --cc=laoar.shao@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mirq-linux@rere.qmqm.pl \
    --cc=netdev@vger.kernel.org \
    --cc=oliver.sang@intel.com \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.