linux-kernel - Re: [PATCH AUTOSEL for 4.9 025/190] platform/x86: asus-nb-wmi: Add wapf4 quirk for the X302UA

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20180309163738.cxddga5qzwm4n3bz@sasha-lappy>
Date:   Fri, 9 Mar 2018 16:37:40 +0000
From:   Sasha Levin <Alexander.Levin@...rosoft.com>
To:     Darren Hart <dvhart@...radead.org>
CC:     Greg KH <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Santeri Toivonen <santeri.toivonen@...sul.com>
Subject: Re: [PATCH AUTOSEL for 4.9 025/190] platform/x86: asus-nb-wmi: Add
 wapf4 quirk for the X302UA

On Thu, Mar 08, 2018 at 10:37:21AM -0800, Darren Hart wrote:
>On Thu, Mar 08, 2018 at 06:15:27PM +0000, Sasha Levin wrote:
>> On Thu, Mar 08, 2018 at 09:47:54AM -0800, Greg KH wrote:
>> >On Thu, Mar 08, 2018 at 09:39:14AM -0800, Darren Hart wrote:
>> >> On Thu, Mar 08, 2018 at 04:59:01AM +0000, Sasha Levin wrote:
>> >> > From: Santeri Toivonen <santeri.toivonen@...sul.com>
>> >> >
>> >> > [ Upstream commit f35823619db8bbaa2afea8705f239c3cecb9d22f ]
>> >> >
>> >> > Asus laptop X302UA starts up with Wi-Fi disabled,
>> >> > without a way to enable it. Set wapf=4 to fix the problem.
>> >> >
>> >> > Signed-off-by: Santeri Toivonen <santeri.toivonen@...sul.com>
>> >> > Signed-off-by: Darren Hart (VMware) <dvhart@...radead.org>
>> >> > Signed-off-by: Sasha Levin <alexander.levin@...rosoft.com>
>> >>
>> >> Hi Sasha,
>> >>
>> >> I'm curious about this AUTOSEL tag, and what about this patch triggered
>> >> its selection?
>> >
>> >It's "magic"!  :)
>> >
>> >Seriously, it's close to magic, there's a tool that Sasha is using that
>> >takes "machine learning" to match patches that we have not applied in
>> >stable kernels to ones that we have, and try to catch those that we
>> >forgot to tag for the stable tree.  Not all subsystems mark stable
>> >patches, so this is an attempt to catch those fixes that should be
>> >getting backported but are not either because the developer/maintainer
>> >forgot to mark it as such, or because they just never mark those types
>> >of patches.
>> >
>> >Sasha has a better write up about how this all works somewhere, and
>> >given that this type of question keeps coming up every other week or so,
>> >I think I need to add it to a FAQ somewhere to point people at to make
>> >it more obvious what is happening.
>>
>> It's pretty much a neural network that knows how to classify a "bug
>> fixing patch" based on things such as:
>>
>>  - Code metrics
>>  - Words in the commit message (the NN knows about the 10,000 most used
>>    words, and their likehood to appear in a bug fixing patch).
>>  - Which files were modified.
>>  - Authors of the commit, and persons who got Cc'ed/Signed-off/etc.
>>
>> So in this case, there are a few things that "helped" this patch get
>> selected:
>>
>>  - The word "quirk" in the subject line.
>>  - "fix" + "problem" in the commit log.
>>  - Modifies drivers/platform/x86/asus-nb-wmi.c which contains mostly
>>    quirks.
>>  - The patch has minimal changes in code metrics. I don't have exact
>>    numbers for this, but it seems that in general patches that do very
>> little have more odds of fixing bugs.
>>
>> And I also manually review all the stuff that get sent out, and to my
>> human brain it looks like something that should be in stable :)
>
>This is really cool to see, thanks for the effort here. Good place for the
>application of AI/ML.
>
>Have you considered having this work on patches submitted? If the machine could
>respond to patches that don't have stable or fixes tags that it thinks should,
>we could address this a bit earlier in the process, and perhaps get a more
>consistent labeling, as well as get the maintainer eyes on this, reducing the
>amount of manual auditing you have to do.

Yup, there are a few ideas on how to get this done earlier in the
process such as integration with checkpatch and a mail bot a-la 0day.

Right now it's still in the experimentation phase, I'm trying to improve
the results based on review feedback I get from maintainers/authors.

A good example of the above was that the NN was very keen on including
commits that added devicetree bindings since those usually happen with
hardware enablement which usually goes in stable. The issue was that
sometimes the code for the hardware didn't exist back in older stable
trees, and building the kernel wouldn't catch this error, so it's one of
the things I'm hoping to deal with before it goes too public.

-- 

Thanks,
Sasha