Re: [patch] x86/ldt: make a size variable unsigned

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 8 Dec 2016, Dan Carpenter wrote:
> My static checker complains that we put an upper bound on the "size"
> variable but not a lower bound.  The checker is not smart enough to know
> the possible ranges of "old_mm->context.ldt->size" from
> init_new_context_ldt() so it thinks maybe it could be negative.
> 
> Let's make it unsigned to silence the warning and future proof the code
> a bit.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
> 
> diff --git a/arch/x86/kernel/ldt.c b/arch/x86/kernel/ldt.c
> index 4d12cdf2b453..d6320c63be45 100644
> --- a/arch/x86/kernel/ldt.c
> +++ b/arch/x86/kernel/ldt.c
> @@ -34,7 +34,7 @@ static void flush_ldt(void *current_mm)
>  }
>  
>  /* The caller must call finalize_ldt_struct on the result. LDT starts zeroed. */
> -static struct ldt_struct *alloc_ldt_struct(int size)
> +static struct ldt_struct *alloc_ldt_struct(unsigned int size)
>  {
>  	struct ldt_struct *new_ldt;
>  	int alloc_size;

So yes, this fixes the checker warning, but then it leaves the code in
inconsistent state:

	alloc_size = size * LDT_ENTRY_SIZE;

Why not doing the obvious

-	int alloc_size;
+	unsigned int alloc_size;

right away?

We have lots of places where we 'fixup' stuff and leave the rest untouched,
which then causes trouble a few month down the road. Probably not in this
case, but still.

I'm all for addressing such issues, but then please take the time aside of
mechanically fixing the checker fallout to make the overall usage
consistent.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Development]     [Kernel Announce]     [Kernel Newbies]     [Linux Networking Development]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Device Mapper]

  Powered by Linux