Re: linux-next: build failure after merge of the akpm tree

[Stephen Rothwell]

Hi all,

On Fri, 22 Jan 2016 11:24:42 +1100 Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
>
> On Thu, 21 Jan 2016 07:38:59 +1100 Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
> >
> > On Wed, 20 Jan 2016 15:09:47 +0100 Takashi Iwai <tiwai@xxxxxxx> wrote:  
> > >
> > > On Sat, 16 Jan 2016 09:51:29 +0100,
> > > Takashi Iwai wrote:    
> > > > 
> > > > There are a few ways to fix this, but all are not comfortable.
> > > > 
> > > > A. Disable compress API for powerpc.    
> > 
> > This also affects alpha, mips and (maybe) sparc.  
> 
> This was exposed on PowerPC by commit bf76f73c5f65 ("powerpc: enable
> UBSAN support") which is in Linus' tree as of this morning.  The only
> relevant change that made was in the compiler flags (I tested this by
> building the file without that commit but with these new compiler flags:
> 
> -fsanitize=shift -fsanitize=integer-divide-by-zero
> -fsanitize=unreachable -fsanitize=vla-bound -fsanitize=null
> -fsanitize=signed-integer-overflow -fsanitize=bounds
> -fsanitize=object-size -fsanitize=returns-nonnull-attribute
> -fsanitize=bool -fsanitize=enum -fsanitize=alignment
> 
> The preprocessed file is the same in both cases, but with these flags
> the compiler errors.

I have discussed this with the PowerPC maintainer (Michael) and he
figured out why the compiler does not produce an error (normally).  It
is because this driver is using _IOC_NR(xxx) to match ioctls instead of
the full ioctl number.  Because of that, the compiler can figure out
that it does not care about the undefined reference to
__invalid_size_argument_for_IOC that the size check shouold generate
(since _IOC_NR shifts and masks it out).

So, the switch statement in snd_compr_ioctl() should be rewritten to
check against the full ioctl number (since currently it could
theoretically match any number of ioctls, not just the relevant ones).
And then something needs to be done about the very large structure
being passed.
-- 
Cheers,
Stephen Rothwell                    sfr@xxxxxxxxxxxxxxxx