[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANn89iLYV+R1CQiuvjtU=aQinVAKyhQiJVUxWG7t=-M72ZsToA@mail.gmail.com>
Date: Thu, 6 Feb 2025 11:09:40 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Liang Jie <buaajxlj@....com>
Cc: kuniyu@...zon.com, davem@...emloft.net, horms@...nel.org, kuba@...nel.org,
liangjie@...iang.com, linux-kernel@...r.kernel.org, mhal@...x.co,
netdev@...r.kernel.org, pabeni@...hat.com
Subject: Re: [PATCH net-next v2] af_unix: Refine UNIX pathname sockets
autobind identifier length
On Thu, Feb 6, 2025 at 10:45 AM Liang Jie <buaajxlj@....com> wrote:
>
> From: Kuniyuki Iwashima <kuniyu@...zon.com>
> Date: Thu, 6 Feb 2025 17:58:34 +0900
> > From: Liang Jie <buaajxlj@....com>
> > Date: Thu, 6 Feb 2025 16:19:05 +0800
> > > Hi Kuniyuki,
> > >
> > > The logs from 'netdev/build_allmodconfig_warn' is as follows:
> > > ../net/unix/af_unix.c: In function ‘unix_autobind’:
> > > ../net/unix/af_unix.c:1222:52: warning: ‘snprintf’ output truncated before the last format character [-Wformat-truncation=]
> > > 1222 | snprintf(addr->name->sun_path + 1, 5, "%05x", ordernum);
> > > | ^
> > > ../net/unix/af_unix.c:1222:9: note: ‘snprintf’ output 6 bytes into a destination of size 5
> > > 1222 | snprintf(addr->name->sun_path + 1, 5, "%05x", ordernum);
> > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > > snprintf() also append a trailing '\0' at the end of the sun_path.
> >
> > I didn't say snprintf() would work rather we need a variant of it that
> > does not terminate string with \0.
> >
> >
> > >
> > > Now, I think of three options. Which one do you think we should choose?
> > >
> > > 1. Allocate an additional byte during the kzalloc phase.
> > > addr = kzalloc(sizeof(*addr) + offsetof(struct sockaddr_un, sun_path) +
> > > UNIX_AUTOBIND_LEN + 1, GFP_KERNEL);
> > >
> > > 2. Use temp buffer and memcpy() for handling.
> > >
> > > 3. Keep the current code as it is.
> > >
> > > Do you have any other suggestions?
> >
> > I'd choose 3. as said in v1 thread. We can't avoid hard-coding and
> > adjustment like +1 and -1 here.
>
> The option 3 would result in a waste of ten bytes. Why not choose option 1.
>
> I have a question about the initial use of the hardcoded value 16.
> Why was this value chosen and not another? sizeof(struct sockaddr)?
>
> Its introduction felt abrupt and made understanding the code challenging for me,
> which is why I submitted a patch to address this.
To be clear, we are discussing here about using kmalloc-16 slab
instead of kmalloc-32
I find this a bit distracting to be honest, given the cost of a file +
inode + af_unix socket.
IMO it might be more interesting to document why abstract sockets
names are limited to 5 hex digits...
Powered by blists - more mailing lists