Hi Yafang,
On Thu, Aug 08, 2024 at 10:49:17AM GMT, Yafang Shao wrote:
> > > Now, it might be a good idea to also verify that 'buf' is an actual
> > > array, and that this code doesn't do some silly "sizeof(ptr)" thing.
> >
> > I decided to use NITEMS() instead of sizeof() for that reason.
> > (NIT
On Wed, Aug 7, 2024 at 1:28 AM Alejandro Colomar wrote:
>
> Hi Linus,
>
> Serge let me know about this thread earlier today.
>
> On 2024-08-05, Linus Torvalds wrote:
> > On Mon, 5 Aug 2024 at 20:01, Yafang Shao wrote:
> > >
> > > One concern about removing the BUILD_BUG_ON() is that if we extend
Hi Linus,
Serge let me know about this thread earlier today.
On 2024-08-05, Linus Torvalds wrote:
> On Mon, 5 Aug 2024 at 20:01, Yafang Shao wrote:
> >
> > One concern about removing the BUILD_BUG_ON() is that if we extend
> > TASK_COMM_LEN to a larger size, such as 24, the caller with a
> > ha
On Tue, Aug 6, 2024 at 11:10 AM Linus Torvalds
wrote:
>
> On Mon, 5 Aug 2024 at 20:01, Yafang Shao wrote:
> >
> > One concern about removing the BUILD_BUG_ON() is that if we extend
> > TASK_COMM_LEN to a larger size, such as 24, the caller with a
> > hardcoded 16-byte buffer may overflow.
>
> No,
On Mon, 5 Aug 2024 at 20:01, Yafang Shao wrote:
>
> One concern about removing the BUILD_BUG_ON() is that if we extend
> TASK_COMM_LEN to a larger size, such as 24, the caller with a
> hardcoded 16-byte buffer may overflow.
No, not at all. Because get_task_comm() - and the replacements - would
ne
On Tue, Aug 6, 2024 at 5:28 AM Linus Torvalds
wrote:
>
> On Sun, 4 Aug 2024 at 00:56, Yafang Shao wrote:
> >
> > There is a BUILD_BUG_ON() inside get_task_comm(), so when you use
> > get_task_comm(), it implies that the BUILD_BUG_ON() is necessary.
>
> Let's just remove that silly BUILD_BUG_ON().
On Sun, 4 Aug 2024 at 00:56, Yafang Shao wrote:
>
> There is a BUILD_BUG_ON() inside get_task_comm(), so when you use
> get_task_comm(), it implies that the BUILD_BUG_ON() is necessary.
Let's just remove that silly BUILD_BUG_ON(). I don't think it adds any
value, and honestly, it really only make
Using {memcpy,strncpy,strcpy,kstrdup} to copy the task comm relies on the
length of task comm. Changes in the task comm could result in a destination
string that is overflow. Therefore, we should explicitly ensure the destination
string is always NUL-terminated, regardless of the task comm. This ap
