linux-kernel - Re: [PATCH] staging: lustre/lustre/libcfs: Fix type mismatch reported by sparse

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADCM0GJSpbansEjGRcqVX1H2jQUhOC2kNFxk_15Ffo-=VyGq=g@mail.gmail.com>
Date:	Wed, 23 Dec 2015 11:57:50 +0530
From:	Niranjan Dighe <niranjan.dighe@...il.com>
To:	"Dilger, Andreas" <andreas.dilger@...el.com>
Cc:	"Drokin, Oleg" <oleg.drokin@...el.com>,
	"Eremin, Dmitry" <dmitry.eremin@...el.com>,
	James Simmons <jsimmons@...radead.org>,
	Mike Rapoport <mike.rapoport@...il.com>,
	Patrick Boettcher <patrick.boettcher@...teo.de>,
	Matthew Tyler <matt.tyler@...shics.com>,
	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"lustre-devel@...ts.lustre.org" <lustre-devel@...ts.lustre.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] staging: lustre/lustre/libcfs: Fix type mismatch reported
 by sparse

On Wed, Dec 23, 2015 at 3:34 AM, Dilger, Andreas
<andreas.dilger@...el.com> wrote:
> On 2015/12/22, 06:05, "Niranjan Dighe" <niranjan.dighe@...il.com> wrote:
>
>>On Tue, Dec 22, 2015 at 5:14 AM, Greg Kroah-Hartman
>><gregkh@...uxfoundation.org> wrote:
>>> On Wed, Dec 09, 2015 at 10:38:13PM +0530, Niranjan Dighe wrote:
>>>> The third argument to function kportal_memhog_alloc is expected to
>>>> be gfp_t whereas the actual argument was unsigned int. Fix this by
>>>> explicitly typecasting to gfp_t
>>>>
>>>> Signed-off-by: Niranjan Dighe <niranjan.dighe@...il.com>
>>>> ---
>>>>  drivers/staging/lustre/lustre/libcfs/module.c | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/staging/lustre/lustre/libcfs/module.c
>>>>b/drivers/staging/lustre/lustre/libcfs/module.c
>>>> index 96d9d46..9c79f6e 100644
>>>> --- a/drivers/staging/lustre/lustre/libcfs/module.c
>>>> +++ b/drivers/staging/lustre/lustre/libcfs/module.c
>>>> @@ -268,7 +268,7 @@ static int libcfs_ioctl_int(struct cfs_psdev_file
>>>>*pfile, unsigned long cmd,
>>>>                       /* XXX The ioc_flags is not GFP flags now, need
>>>>to be fixed */
>>>>                       err = kportal_memhog_alloc(pfile->private_data,
>>>>                                                  data->ioc_count,
>>>> -                                                data->ioc_flags);
>>>> +                                     (__force gfp_t)data->ioc_flags);
>>>
>>> No, please fix the type to be correct properly, like the comment says
>>> needs to be done.
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>>Hello Greg,
>>
>>I could see that the ioc_flags member of the struct libcfs_ioctl_data
>>is used as gfp_t only in the
>>case of the ioctl IOC_LIBCFS_MEMHOG. I can think of following ways to
>>correct it -
>>
>>1. Create a union that has 2 different types encapsulated, something like
>>this -
>>        union {
>>                __u32 ioc_flags;
>>                gfp_t alloc_flags;
>>        }flags;
>>Because, the ioc_flags seems to be used in different contexts at
>>different places throughout the
>>drivers/staging/lustre directory.
>>
>>2. Is it OK to hardcode the appropriate gfp_t flags for the
>>IOC_LIBCFS_MEMHOG, as the userspace
>>seems to be taking the decision about the page allocation
>>zone/strategy, is this what is intended?
>
> The memhog functionality is used to introduce memory pressure on a client
> or server during operation to test error handling as well as memory
> allocation deadlocks (e.g. GFP_KERNEL used where GFP_NOFS should be used).
> There are other ways to do this in the kernel today, so all of the memhog
> code could just be deleted I think.
>
> This looks like kportal_memhog_alloc(), kportal_memhog_free(),
> IOC_LIBCFS_MEMHOG, and struct libcfs_device_userstate could be removed.
>
>
> Cheers, Andreas
>

Thanks Andreas, I will send out a separate patch with the cleanup as
you suggested.

Regards,
Niranjan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/