| Message ID | 20211005063220.1513915-1-frank.heimes@canonical.com |
|---|---|
| Headers | show |
| Series | Problem leading IUCV service down (on s390x) (LP: 1913442) | expand |
Acked-by: Tim Gardner <tim.gardner@canonical.com> On 10/5/21 12:32 AM, frank.heimes@canonical.com wrote: > BugLink: https://bugs.launchpad.net/bugs/1913442 > > SRU Justification: > > [Impact] > > * Problems occur in IBM z/VM's IUCV (Inter User Communication Vehicle) environments and its communication. > > * Errors like "usercopy: Kernel memory overwrite attempt detected to SLUB object 'dma-kmalloc-1 k' (offset 0, size 11)!" pop up and cause failures. > > * This is because IUCV uses kmalloc() with __GFP_DMA because of memory address restrictions. > > * The solution is to mark dma-kmalloc caches as usercopy caches. > > [Fix] > > * 49f2d2419d60a103752e5fbaf158cf8d07c0d884 49f2d2419d60 "usercopy: mark dma-kmalloc caches as usercopy caches" > > * Due to changes in the context of the upstream patch, > a cherry-pick was not possible and the following backport was created: > https://bugs.launchpad.net/bugs/1913442/+attachment/5457885/+files/commit_49f2d2419d60_backport.patch > > [Test Case] > > * Setup Ubuntu Server 20.04 on s390x system as IBM z/VM guest aka virtual machine. > > * Setup IUCV on z/VM: Setting up the (IUCV TCPIP) service machine: > https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.ljdd/ljdd_t_iucv_tcpservice.html > > * Set up a Linux IUCV instance: https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.ljdd/ljdd_t_iucv_scen1_guest.html > > * Set up an IUCV direct: https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.ljdd/ljdd_c_iucv_connect.html > > * Make use of IUCV, for example using ssh on a direct connection. > > * Verify if the connections is stable and watch out for messages starting with "usercopy". > > [Regression Potential] > > * Problems could occure in case the create_kmalloc_cache call is done wrong, > for example with wrong index, wrong size or just wrong comma separations. > > * Wrong size or index will probably lead to similar instability problems that exist today. > > * Problems in the syntax (commas etc.) will be detected at compile time. > > * But it's just a single line modification in function create_kmalloc_caches of /mm/slab_common.c, > > * so the change is very limited and quite traceable. > > * And it was in depth discussed here: > https://lore.kernel.org/kernel-hardening/1515636190-24061-2-git-send-email-keescook@chromium.org/ > > * a reviewed by a lot of kernel engineers (see provenance) > > * and it was already upstream accepted with kernel 5.8. > > [Other] > > * Since the commit is upstream accepted with 5.8, it's already in groovy and hirsute. > > * Hence this kernel SRU submission is for Focal only and covers only the above single but common code commit/patch. > > Frank Heimes (1): > usercopy: mark dma-kmalloc caches as usercopy caches > > mm/slab_common.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >
Applied to focal master-next. Removed the line requested: >> Upstream commit : 49f2d2419d60a103752e5fbaf158cf8d07c0d884 Thank you! -Kelsey On 2021-10-05 08:32:19 , frank.heimes@canonical.com wrote: > BugLink: https://bugs.launchpad.net/bugs/1913442 > > SRU Justification: > > [Impact] > > * Problems occur in IBM z/VM's IUCV (Inter User Communication Vehicle) environments and its communication. > > * Errors like "usercopy: Kernel memory overwrite attempt detected to SLUB object 'dma-kmalloc-1 k' (offset 0, size 11)!" pop up and cause failures. > > * This is because IUCV uses kmalloc() with __GFP_DMA because of memory address restrictions. > > * The solution is to mark dma-kmalloc caches as usercopy caches. > > [Fix] > > * 49f2d2419d60a103752e5fbaf158cf8d07c0d884 49f2d2419d60 "usercopy: mark dma-kmalloc caches as usercopy caches" > > * Due to changes in the context of the upstream patch, > a cherry-pick was not possible and the following backport was created: > https://bugs.launchpad.net/bugs/1913442/+attachment/5457885/+files/commit_49f2d2419d60_backport.patch > > [Test Case] > > * Setup Ubuntu Server 20.04 on s390x system as IBM z/VM guest aka virtual machine. > > * Setup IUCV on z/VM: Setting up the (IUCV TCPIP) service machine: > https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.ljdd/ljdd_t_iucv_tcpservice.html > > * Set up a Linux IUCV instance: https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.ljdd/ljdd_t_iucv_scen1_guest.html > > * Set up an IUCV direct: https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.ljdd/ljdd_c_iucv_connect.html > > * Make use of IUCV, for example using ssh on a direct connection. > > * Verify if the connections is stable and watch out for messages starting with "usercopy". > > [Regression Potential] > > * Problems could occure in case the create_kmalloc_cache call is done wrong, > for example with wrong index, wrong size or just wrong comma separations. > > * Wrong size or index will probably lead to similar instability problems that exist today. > > * Problems in the syntax (commas etc.) will be detected at compile time. > > * But it's just a single line modification in function create_kmalloc_caches of /mm/slab_common.c, > > * so the change is very limited and quite traceable. > > * And it was in depth discussed here: > https://lore.kernel.org/kernel-hardening/1515636190-24061-2-git-send-email-keescook@chromium.org/ > > * a reviewed by a lot of kernel engineers (see provenance) > > * and it was already upstream accepted with kernel 5.8. > > [Other] > > * Since the commit is upstream accepted with 5.8, it's already in groovy and hirsute. > > * Hence this kernel SRU submission is for Focal only and covers only the above single but common code commit/patch. > > Frank Heimes (1): > usercopy: mark dma-kmalloc caches as usercopy caches > > mm/slab_common.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > -- > 2.25.1 > > > -- > kernel-team mailing list > kernel-team@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team
On 14/10/2021 01:41, Kelsey Skunberg wrote: > Applied to focal master-next. Removed the line requested: > >>> Upstream commit : 49f2d2419d60a103752e5fbaf158cf8d07c0d884 > > Thank you! > Hi folks, This patch was applied but it is not there anymore. Maybe it landed in different tree? Could you re-apply it? Best regards, Krzysztof
On 08.12.21 13:43, Krzysztof Kozlowski wrote: > On 14/10/2021 01:41, Kelsey Skunberg wrote: >> Applied to focal master-next. Removed the line requested: >> >>>> Upstream commit : 49f2d2419d60a103752e5fbaf158cf8d07c0d884 >> Thank you! >> > Hi folks, > > This patch was applied but it is not there anymore. Maybe it landed in > different tree? > > Could you re-apply it? > > > Best regards, > Krzysztof > This is now re-applied to focal:linux. It seems we have lost a couple of patches from this branch. Thanks for catching it. Thanks, Kleber