Hi Greg,
Kindly review and consider following mm/OOM upstream fixes for stable 4.9.y.
88ed365ea227 ("mm: don't steal highatomic pageblock") 04c8716f7b00 ("mm: try to exhaust highatomic reserve before the OOM") 29fac03bef72 ("mm: make unreserve highatomic functions reliable")
The original 4 patch series is archived here https://lkml.org/lkml/2016/10/12/77 for review. One of the patch from this series: 4855e4a7f29d ("mm: prevent double decrease of nr_reserved_highatomic") has already been picked up for 4.9.y and 4.4.y.
I ran into these fixes in one of the msm-4.9(android) trees. Cherry-picked and build tested on Linux 4.9.148 for ARCH=arm/arm64 defconfig.
Only the first patch from this series can be applied cleanly on v4.4.y, while others fail to apply cleanly due to OOM rework done in v4.7 release cycle, 0a0337e0d1d1 ("mm, oom: rework oom detection"). Plus I don't see this series backported to v4.4 in any of the msm-4.4(android) trees either. So I'm skipping it for v4.4.y.
Regards, Amit Pundir
On Mon, Jan 07, 2019 at 03:10:35PM +0530, Amit Pundir wrote:
Hi Greg,
Kindly review and consider following mm/OOM upstream fixes for stable 4.9.y.
88ed365ea227 ("mm: don't steal highatomic pageblock") 04c8716f7b00 ("mm: try to exhaust highatomic reserve before the OOM") 29fac03bef72 ("mm: make unreserve highatomic functions reliable")
The original 4 patch series is archived here https://lkml.org/lkml/2016/10/12/77 for review. One of the patch from this series: 4855e4a7f29d ("mm: prevent double decrease of nr_reserved_highatomic") has already been picked up for 4.9.y and 4.4.y.
I ran into these fixes in one of the msm-4.9(android) trees. Cherry-picked and build tested on Linux 4.9.148 for ARCH=arm/arm64 defconfig.
Only the first patch from this series can be applied cleanly on v4.4.y, while others fail to apply cleanly due to OOM rework done in v4.7 release cycle, 0a0337e0d1d1 ("mm, oom: rework oom detection"). Plus I don't see this series backported to v4.4 in any of the msm-4.4(android) trees either. So I'm skipping it for v4.4.y.
Can you get an ack from the mm developers that these really are viable for backporting to older kernel trees as they solve a real issue?
thanks,
greg k-h
On Mon, 7 Jan 2019 at 15:18, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, Jan 07, 2019 at 03:10:35PM +0530, Amit Pundir wrote:
Hi Greg,
Kindly review and consider following mm/OOM upstream fixes for stable 4.9.y.
88ed365ea227 ("mm: don't steal highatomic pageblock") 04c8716f7b00 ("mm: try to exhaust highatomic reserve before the OOM") 29fac03bef72 ("mm: make unreserve highatomic functions reliable")
The original 4 patch series is archived here https://lkml.org/lkml/2016/10/12/77 for review. One of the patch from this series: 4855e4a7f29d ("mm: prevent double decrease of nr_reserved_highatomic") has already been picked up for 4.9.y and 4.4.y.
I ran into these fixes in one of the msm-4.9(android) trees. Cherry-picked and build tested on Linux 4.9.148 for ARCH=arm/arm64 defconfig.
Only the first patch from this series can be applied cleanly on v4.4.y, while others fail to apply cleanly due to OOM rework done in v4.7 release cycle, 0a0337e0d1d1 ("mm, oom: rework oom detection"). Plus I don't see this series backported to v4.4 in any of the msm-4.4(android) trees either. So I'm skipping it for v4.4.y.
Can you get an ack from the mm developers that these really are viable for backporting to older kernel trees as they solve a real issue?
I forgot to mention that marking the original series for stable (v4.4+) was discussed as well, and was sort of NACked https://lkml.org/lkml/2016/10/12/655 because no one else reported this OOM behavior. And the only reason I submitted this series for v4.9 is msm-4.9 Android trees which cherry-picked this whole series as is.
Regards, Amit Pundir
thanks,
greg k-h
On Mon, Jan 07, 2019 at 03:25:42PM +0530, Amit Pundir wrote:
On Mon, 7 Jan 2019 at 15:18, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, Jan 07, 2019 at 03:10:35PM +0530, Amit Pundir wrote:
Hi Greg,
Kindly review and consider following mm/OOM upstream fixes for stable 4.9.y.
88ed365ea227 ("mm: don't steal highatomic pageblock") 04c8716f7b00 ("mm: try to exhaust highatomic reserve before the OOM") 29fac03bef72 ("mm: make unreserve highatomic functions reliable")
The original 4 patch series is archived here https://lkml.org/lkml/2016/10/12/77 for review. One of the patch from this series: 4855e4a7f29d ("mm: prevent double decrease of nr_reserved_highatomic") has already been picked up for 4.9.y and 4.4.y.
I ran into these fixes in one of the msm-4.9(android) trees. Cherry-picked and build tested on Linux 4.9.148 for ARCH=arm/arm64 defconfig.
Only the first patch from this series can be applied cleanly on v4.4.y, while others fail to apply cleanly due to OOM rework done in v4.7 release cycle, 0a0337e0d1d1 ("mm, oom: rework oom detection"). Plus I don't see this series backported to v4.4 in any of the msm-4.4(android) trees either. So I'm skipping it for v4.4.y.
Can you get an ack from the mm developers that these really are viable for backporting to older kernel trees as they solve a real issue?
I forgot to mention that marking the original series for stable (v4.4+) was discussed as well, and was sort of NACked https://lkml.org/lkml/2016/10/12/655 because no one else reported this OOM behavior. And the only reason I submitted this series for v4.9 is msm-4.9 Android trees which cherry-picked this whole series as is.
I remember that thread, which is why I asked for explicit "yes this is good" for 4.9. Just because a crazy vendor dropped patches in their tree is not always a good reason to actually put them in everyone's tree. That vendor is liable for the fallout as-is, do not transfer that liability to upstream when they explicitly said "do not apply these"...
thanks,
greg k-h
On Mon, 7 Jan 2019 at 15:37, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, Jan 07, 2019 at 03:25:42PM +0530, Amit Pundir wrote:
On Mon, 7 Jan 2019 at 15:18, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, Jan 07, 2019 at 03:10:35PM +0530, Amit Pundir wrote:
Hi Greg,
Kindly review and consider following mm/OOM upstream fixes for stable 4.9.y.
88ed365ea227 ("mm: don't steal highatomic pageblock") 04c8716f7b00 ("mm: try to exhaust highatomic reserve before the OOM") 29fac03bef72 ("mm: make unreserve highatomic functions reliable")
The original 4 patch series is archived here https://lkml.org/lkml/2016/10/12/77 for review. One of the patch from this series: 4855e4a7f29d ("mm: prevent double decrease of nr_reserved_highatomic") has already been picked up for 4.9.y and 4.4.y.
I ran into these fixes in one of the msm-4.9(android) trees. Cherry-picked and build tested on Linux 4.9.148 for ARCH=arm/arm64 defconfig.
Only the first patch from this series can be applied cleanly on v4.4.y, while others fail to apply cleanly due to OOM rework done in v4.7 release cycle, 0a0337e0d1d1 ("mm, oom: rework oom detection"). Plus I don't see this series backported to v4.4 in any of the msm-4.4(android) trees either. So I'm skipping it for v4.4.y.
Can you get an ack from the mm developers that these really are viable for backporting to older kernel trees as they solve a real issue?
I forgot to mention that marking the original series for stable (v4.4+) was discussed as well, and was sort of NACked https://lkml.org/lkml/2016/10/12/655 because no one else reported this OOM behavior. And the only reason I submitted this series for v4.9 is msm-4.9 Android trees which cherry-picked this whole series as is.
I remember that thread, which is why I asked for explicit "yes this is good" for 4.9. Just because a crazy vendor dropped patches in their tree is not always a good reason to actually put them in everyone's tree. That vendor is liable for the fallout as-is, do not transfer that liability to upstream when they explicitly said "do not apply these"...
Got it. Thanks.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Amit Pundir -
Greg Kroah-Hartman