Re: [PATCH v1 1/1] usb: f_mass_storage: Bump local buffer size in fsg_common_create_luns()

[Alan Stern]

On Mon, Aug 17, 2026 at 06:00:53PM +0300, Andy Shevchenko wrote:
> On Mon, Aug 17, 2026 at 09:47:45AM -0400, Alan Stern wrote:
> > On Mon, Aug 17, 2026 at 12:47:34PM +0200, Andy Shevchenko wrote:
> > > GCC is not happy about the buffer size:
> > > 
> > > drivers/usb/gadget/function/f_mass_storage.c:2970:48: error: ‘%d’ directive output may be truncated writing between 1 and 9 bytes into a region of size 5 [-Werror=format-truncation=]
> > > 
> > > Bump the size to get it enough for all possible values.
> > > 
> > > Note, the existing comment is wrong as size 8 for the whole buffer doesn't
> > > cover 100 mil numbers, hence drop it altogether.
> > 
> > It seems highly unlikely that anyone would ever want to create 100 million
> > LUNs.
> 
> Completely agree (but see below).
> 
> > Why not limit the number of LUNs to some more reasonable value, like 1000?
> 
> I chose the robust way as different versions of the compiler may or may not
> that limit (yes, we had such a case in the past [1] and it required to replace
> also specifier and variable type altogether. Given that, I'm not feeling to
> rework that way. Up to you to implement, though. If you think this patch is
> not good enough, consider this then as a bug report (with `make W=1` it breaks
> the build, exactly what my case is).

Okay, now I get it.  The compilers' limitations are a big part of the 
reason for this change.

And looking through the code, I see the only way that the existing 
drivers ever construct a struct fsg_config is by calling 
fsg_config_from_params(), which does indeed limit the number of LUNs to 
FSG_MAX_LUNS.

So yes, please update the patch description to mention that although 
cfg->nluns is limited to FSG_MAX_LUNS (16), the compiler doesn't realize 
this and complains about the buffer size.  Then you can add:

Acked-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>

Do you think it's worth adding an explicit check in 
fsg_common_create_luns(), such as:

	if (cfg->nluns > FSG_MAX_LUNS)
		return -EINVAL;

to catch the case where someone tries to bypass 
fsg_config_from_params()?  That alone might well be enough to prevent 
the compiler from warning about the field length.

Alan Stern