linux-kernel - Re: [PATCH] binder: fix sparse warnings on locking context

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

Message-ID: <20181205162926.GA7185@kroah.com>
Date:   Wed, 5 Dec 2018 17:29:26 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Todd Kjos <tkjos@...gle.com>
Cc:     Todd Kjos <tkjos@...roid.com>,
        Arve Hjønnevåg <arve@...roid.com>,
        "open list:ANDROID DRIVERS" <devel@...verdev.osuosl.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Martijn Coenen <maco@...gle.com>, joel@...lfernandes.org,
        Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [PATCH] binder: fix sparse warnings on locking context

On Wed, Dec 05, 2018 at 06:02:22AM -0800, Todd Kjos wrote:
> On Wed, Dec 5, 2018 at 2:57 AM Greg KH <gregkh@...uxfoundation.org> wrote:
> 
> > On Mon, Dec 03, 2018 at 12:24:54PM -0800, Todd Kjos wrote:
> > > Add __acquire()/__release() annnotations to fix warnings
> > > in sparse context checking
> > >
> > > There is one case where the warning was due to a lack of
> > > a "default:" case in a switch statement where a lock was
> > > being released in each of the cases, so the default
> > > case was added.
> > >
> > > Signed-off-by: Todd Kjos <tkjos@...gle.com>
> >
> > You sent out 4 patches here, as a series, but with no numbering so I
> > don't know what order to put them in :(
> >
> > Can you resend them properly numbered so I have a chance to get it
> > right?
> >
> 
> I didn't number them because they are independent and can go in any order.

Ah, that wasn't obvious :)

> They are not really a series. I can resend with numbers though if you want
> to reflect the order I sent them in.

Ok, no need for numbering them, but they do need to be resent based on
the feedback I gave.  I've dropped them all from my queue because of
that.

thanks,

greg k-h