linux-kernel - Re: [PATCH] rdma: siw: remove unused variable

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] [day] [month] [year] [list]

Date:   Mon, 29 Jul 2019 13:14:59 -0700
From:   John Hubbard <jhubbard@...dia.com>
To:     Doug Ledford <dledford@...hat.com>, Jason Gunthorpe <jgg@...pe.ca>
CC:     Anders Roxell <anders.roxell@...aro.org>, <bmt@...ich.ibm.com>,
        <linux-rdma@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] rdma: siw: remove unused variable

On 7/29/19 12:45 PM, Doug Ledford wrote:
> On Mon, 2019-07-29 at 16:03 -0300, Jason Gunthorpe wrote:
>> On Mon, Jul 29, 2019 at 02:19:35PM -0400, Doug Ledford wrote:
>>> On Fri, 2019-07-26 at 11:25 +0200, Anders Roxell wrote:
>>>> The variable 'p' si no longer used and the compiler rightly
>>>> complains
>>>> that it should be removed.
>>>>
>>>> ../drivers/infiniband/sw/siw/siw_mem.c: In function
>>>> ‘siw_free_plist’:
>>>> ../drivers/infiniband/sw/siw/siw_mem.c:66:16: warning: unused
>>>> variable
>>>>  ‘p’ [-Wunused-variable]
>>>>   struct page **p = chunk->plist;
>>>>                 ^
>>>>
>>>> Rework to remove unused variable.
>>>>
>>>> Fixes: 8288d030447f ("mm/gup: add make_dirty arg to
>>>> put_user_pages_dirty_lock()")
>>>
>>> This commit hash and the commit subject does not exist in Linus'
>>> tree as
>>> of today.  What tree is this being merged through, and is it slated
>>> to
>>> merge soon or is this a for-next item?
>>
>> This is though -mm, maybe John knows what is what
> 
> Hmmm...if it's through -mm, doesn't that mean that we can't rely on the
> hash because the next time Andrew's tree rebases (using quilt or
> whatever it is he does) that the hash will change?  It doesn't really
> matter too much...we can't take the fix anyway, it should probably be
> squashed into the patch that it's fixing, and if you follow Bernard's
> advice, you fix the problem by eliminating this function and changing
> the sole call site to just call put_user_pages_dirty_lock() directly.
> 

Hi,

Although I don't know which tree has 8288d030447f, I did get a report
from linux-next last night with that report about the warning, and so
I believe that the patch flowed from Andrew's -mm tree (which has 
speculatively added my patches), to linux-next

(+CC Andrew)

I also sent out a fix for it, as a reply-to the warning report:

    https://lore.kernel.org/r/20190729074306.10368-1-jhubbard@nvidia.com

Pasting in my response (minus the trivial fix), to save you a click:

"This fixes the warning. Ideally this should be merged with the commit
that it fixes, if that's still possible.

"Andrew, would you also like a fixed version of this patch posted
as a new version of the 3-patch set that it came with?"

thanks,
-- 
John Hubbard
NVIDIA