On Thu, Jun 18, 2026 at 09:14:05PM +0300, Andy Shevchenko wrote: > On Thu, Jun 18, 2026 at 05:14:19PM +0100, Rodrigo Alencar wrote: > > On 18/06/26 16:06, Nuno Sá wrote: > > > On Thu, Jun 18, 2026 at 02:27:22PM +0100, Rodrigo Alencar via B4 Relay > > > wrote: > > ... > > > > > + dev_attr->attr.name = kasprintf(GFP_KERNEL, "%s%s", prefix, > > > > postfix); > > > > + if (!dev_attr->attr.name) > > > > return -ENOMEM; > > > > > > I don't oppose the change. Looks like a nice cleanup. > > May I oppose it? I found use scnprintf() is harder to follow in comparison to > nice kasprintf() that takes care for the dynamically allocated buffer.
Tend to agree a bit given I was used to the older code. So matching the old logic with the new one is an exercise, yes. > > Also there is a chance to get a name silently cut due to insufficient space. > Besides that this function can't be used (again due to 'c') in > kasprintf()-like > wrapper. I do not consider this as a good approach. Have you looked at seq_buf > instead? Not so sure the above bothers me that much. > > > > But bear in mind this very sensible as any subtle mistake means ABI > > > breakage. > > Which immediately raises a question of test coverage. Do we have one? If not, > this code must be accompanied with one. The above is the more concerning part to me. - Nuno Sá > > > Yes! I tried to be careful... this is dangerous stuff! > > -- > With Best Regards, > Andy Shevchenko > >
