On Thu, Aug 31, 2023 at 4:16 PM Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > On Thu, Aug 31, 2023 at 3:22 PM Philipp Stanner <pstanner@xxxxxxxxxx> wrote: > > On Wed, 2023-08-30 at 17:11 +0300, Andy Shevchenko wrote: > > > On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner <pstanner@xxxxxxxxxx> > > > wrote: ... > > > I'm wondering if this has no side-effects as string.h/string.c IIRC > > > is used also for early stages where some of the APIs are not available. > > > > I forgot to address this point in my previous reply. > > > > Who's going to decide whether this is a problem or not? > > > > My personal guess is that this is unlikely to be a problem because > > > > A. either (v)memdup_user() is available, in which case > > (v)memdup_array_user() will always work – > > B. or (v)memdup_user() is not available, which would cause the code > > that currently uses (v)memdup_user() for copying arrays to fail > > anyways. > > It also uses something from overflow.h. I don't remember if that > header was ever been used in early stage modules (like > boot/decompressor). Also we need to be sure UML is still buildable. Dunno if they are using anything from this, but it appeared to me recently that someone tried to optimize something using (internal) kernel headers and broke the build in some cases. -- With Best Regards, Andy Shevchenko
