Hi Greg,
I had a brief look at Fedora and a discussion with Fedora, I realised she's already doing a decent job at sending you patches that might've been missed from stable.
So started looking at Ubuntu 4.4 (xenial), and could find some patches that seem good candidates for stable.
I'm just listing them down with upstream commit ID, description and a remark, but if you prefer another way (txt file, xls, or anything else), please let me know, and we can start following that :) (This is just something to begin with, not done the whole list of candidate patches. I will continue to monitor and send).
Patches cc'ed to stable: 91a25e463130c8e19bdb42f2d827836c7937992e drm/dp/mst: deallocate payload on port destruction 8a580f70f6936ec095da217018cdeeb5835c0207 x86/irq: Do not use apic_chip_data.old_domain as temporary buffer 3716fd27a604d61a91cda47083504971486b80f1 x86/irq: Check vector allocation early 8244062ef1e54502ef55f54cced659913f244c3e modules: fix longstanding /proc/kallsyms vs module insertion race.
Patches not CC to stable, but seem a good fix 2b2f5ff00f63847d95adad6289bd8b05f5983dd5 rtc: interface: ignore expired timers when enqueuing new timers 3084558658c2f9a48d7c460d57aeb30964c06b7e megaraid_sas: Don't issue kill adapter for MFI controllers in case of PD list DCMD failure => fixes 3084558658c2f9a48d7c460d57aeb30964c06b7e
87c279e613f848c691111b29d49de8df3f4f56da blk-mq: really fix plug list flushing for nomerge queues =>fixes 0809e3ac6231
Also wanted to ask you if there's a better way in your opinion than using "git cherry -v" to : 1. find patches IN distro, and IN mainline, 2. get patches IN distro, and NOT IN stable and then scan through them to scout? :) (If you're able to share any of your scripts for hunting distros, it'd be pretty good I suppose!)
On Thu, Feb 23, 2017 at 10:01:44PM +0530, Sumit Semwal wrote:
Hi Greg,
I had a brief look at Fedora and a discussion with Fedora, I realised she's already doing a decent job at sending you patches that might've been missed from stable.
Really? I haven't seen a report in a long time, am I just staying on top of things that well?
So started looking at Ubuntu 4.4 (xenial), and could find some patches that seem good candidates for stable.
I'm just listing them down with upstream commit ID, description and a remark, but if you prefer another way (txt file, xls, or anything else), please let me know, and we can start following that :) (This is just something to begin with, not done the whole list of candidate patches. I will continue to monitor and send).
Patches cc'ed to stable: 91a25e463130c8e19bdb42f2d827836c7937992e drm/dp/mst: deallocate payload on port destruction
This is already in a 4.4 release, a really old one, 4.4.4, what tree are you checking against to verify I haven't already applied this?
8a580f70f6936ec095da217018cdeeb5835c0207 x86/irq: Do not use apic_chip_data.old_domain as temporary buffer
Also already in 4.4.4.
3716fd27a604d61a91cda47083504971486b80f1 x86/irq: Check vector allocation early
Also in 4.4.4.
8244062ef1e54502ef55f54cced659913f244c3e modules: fix longstanding /proc/kallsyms vs module insertion race.
Showed up in 4.4.5.
How old is the ubuntu base kernel right now? Have they been keeping it up to date?
Patches not CC to stable, but seem a good fix 2b2f5ff00f63847d95adad6289bd8b05f5983dd5 rtc: interface: ignore expired timers when enqueuing new timers
Nice, now queued up.
3084558658c2f9a48d7c460d57aeb30964c06b7e megaraid_sas: Don't issue kill adapter for MFI controllers in case of PD list DCMD failure => fixes 3084558658c2f9a48d7c460d57aeb30964c06b7e
Does not apply to the 4.4-stable tree, care to provide a backport?
87c279e613f848c691111b29d49de8df3f4f56da blk-mq: really fix plug list flushing for nomerge queues =>fixes 0809e3ac6231
Nice, now added.
Also wanted to ask you if there's a better way in your opinion than using "git cherry -v" to :
- find patches IN distro, and IN mainline,
- get patches IN distro, and NOT IN stable
and then scan through them to scout? :) (If you're able to share any of your scripts for hunting distros, it'd be pretty good I suppose!)
It all depends on the distro and how they manage their kernels. You can just do a list of what they applied against a stable kernel release and dig through those. Or for good ones (i.e. ones that use rpm), you can just list the patches directly in the source rpm.
I don't have any distro-hunting scripts, sorry, that's why I don't do it :)
thanks,
greg k-h
Hello Greg,
On 23 February 2017 at 22:40, Greg KH gregkh@google.com wrote:
On Thu, Feb 23, 2017 at 10:01:44PM +0530, Sumit Semwal wrote:
Hi Greg,
I had a brief look at Fedora and a discussion with Fedora, I realised she's already doing a decent job at sending you patches that might've been missed from stable.
Really? I haven't seen a report in a long time, am I just staying on top of things that well?
(s/with Fedora/with Laura)
:) must be that. Though their's being a moving kernel might have something to do with you not seeing a report in some time. Still, Laura told me she mentioned that if she finds any critical fixes that might be relevant, she would still make it a point to share.
So started looking at Ubuntu 4.4 (xenial), and could find some patches that seem good candidates for stable.
I'm just listing them down with upstream commit ID, description and a remark, but if you prefer another way (txt file, xls, or anything else), please let me know, and we can start following that :) (This is just something to begin with, not done the whole list of candidate patches. I will continue to monitor and send).
Patches cc'ed to stable: 91a25e463130c8e19bdb42f2d827836c7937992e drm/dp/mst: deallocate payload on port destruction
This is already in a 4.4 release, a really old one, 4.4.4, what tree are you checking against to verify I haven't already applied this?
8a580f70f6936ec095da217018cdeeb5835c0207 x86/irq: Do not use apic_chip_data.old_domain as temporary buffer
Also already in 4.4.4.
3716fd27a604d61a91cda47083504971486b80f1 x86/irq: Check vector allocation early
Also in 4.4.4.
8244062ef1e54502ef55f54cced659913f244c3e modules: fix longstanding /proc/kallsyms vs module insertion race.
Showed up in 4.4.5.
How old is the ubuntu base kernel right now? Have they been keeping it up to date?
Yes, I checked again manually, and of course, these seem present! Sorry about the noise.
I used "git cherry -v" to get the list of patches in ubuntu and not-in linux-4.4.y, and these patches showed up as 'not in 4.4.y'. Perhaps I have to use more git-foo. Will try to get it correct.
Patches not CC to stable, but seem a good fix 2b2f5ff00f63847d95adad6289bd8b05f5983dd5 rtc: interface: ignore expired timers when enqueuing new timers
Nice, now queued up.
3084558658c2f9a48d7c460d57aeb30964c06b7e megaraid_sas: Don't issue kill adapter for MFI controllers in case of PD list DCMD failure => fixes 3084558658c2f9a48d7c460d57aeb30964c06b7e
Does not apply to the 4.4-stable tree, care to provide a backport?
Sure, let me do that today and send.
87c279e613f848c691111b29d49de8df3f4f56da blk-mq: really fix plug list flushing for nomerge queues =>fixes 0809e3ac6231
Nice, now added.
Also wanted to ask you if there's a better way in your opinion than using "git cherry -v" to :
- find patches IN distro, and IN mainline,
- get patches IN distro, and NOT IN stable
and then scan through them to scout? :) (If you're able to share any of your scripts for hunting distros, it'd be pretty good I suppose!)
It all depends on the distro and how they manage their kernels. You can just do a list of what they applied against a stable kernel release and dig through those. Or for good ones (i.e. ones that use rpm), you can just list the patches directly in the source rpm.
Sure. Thanks for the pointers.
I don't have any distro-hunting scripts, sorry, that's why I don't do it :)
Np, was just trying my luck ;)
thanks,
greg k-h
Best, Sumit.
On Mon, Feb 27, 2017 at 01:31:06PM +0530, Sumit Semwal wrote:
8244062ef1e54502ef55f54cced659913f244c3e modules: fix longstanding /proc/kallsyms vs module insertion race.
Showed up in 4.4.5.
How old is the ubuntu base kernel right now? Have they been keeping it up to date?
Yes, I checked again manually, and of course, these seem present! Sorry about the noise.
I used "git cherry -v" to get the list of patches in ubuntu and not-in linux-4.4.y, and these patches showed up as 'not in 4.4.y'. Perhaps I have to use more git-foo. Will try to get it correct.
A simple search of 'git log' will show you that those commits are in the tree, not much 'git-foo' needed here. I've never used 'git cherry', so perhaps it is not catching something, or due to the changelog text changing when I commit the patch to the stable tree (I add the original commit id to the changelog.)
thanks,
greg k-h