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@vatsul.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@vatsul.com Signed-off-by: Darren Hart (VMware) dvhart@infradead.org Signed-off-by: Sasha Levin alexander.levin@microsoft.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.