- Linux-stable-mirror - lists.linaro.org

Patch "apparmor: Make path_max parameter readonly" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled apparmor: Make path_max parameter readonly to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: apparmor-make-path_max-parameter-readonly.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 10:11:52 CET 2018 From: John Johansen <john.johansen(a)canonical.com> Date: Thu, 6 Apr 2017 06:55:24 -0700 Subject: apparmor: Make path_max parameter readonly From: John Johansen <john.johansen(a)canonical.com> [ Upstream commit 622f6e3265707ebf02ba776ac6e68003bcc31213 ] The path_max parameter determines the max size of buffers allocated but it should not be setable at run time. If can be used to cause an oops root@ubuntu:~# echo 16777216 > /sys/module/apparmor/parameters/path_max root@ubuntu:~# cat /sys/module/apparmor/parameters/path_max Killed [ 122.141911] BUG: unable to handle kernel paging request at ffff880080945fff [ 122.143497] IP: [<ffffffff81228844>] d_absolute_path+0x44/0xa0 [ 122.144742] PGD 220c067 PUD 0 [ 122.145453] Oops: 0002 [#1] SMP [ 122.146204] Modules linked in: vmw_vsock_vmci_transport vsock ppdev vmw_balloon snd_ens1371 btusb snd_ac97_codec gameport snd_rawmidi btrtl snd_seq_device ac97_bus btbcm btintel snd_pcm input_leds bluetooth snd_timer snd joydev soundcore serio_raw coretemp shpchp nfit parport_pc i2c_piix4 8250_fintek vmw_vmci parport mac_hid ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd vmwgfx psmouse mptspi ttm mptscsih drm_kms_helper mptbase syscopyarea scsi_transport_spi sysfillrect [ 122.163365] ahci sysimgblt e1000 fb_sys_fops libahci drm pata_acpi fjes [ 122.164747] CPU: 3 PID: 1501 Comm: bash Not tainted 4.4.0-59-generic #80-Ubuntu [ 122.166250] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015 [ 122.168611] task: ffff88003496aa00 ti: ffff880076474000 task.ti: ffff880076474000 [ 122.170018] RIP: 0010:[<ffffffff81228844>] [<ffffffff81228844>] d_absolute_path+0x44/0xa0 [ 122.171525] RSP: 0018:ffff880076477b90 EFLAGS: 00010206 [ 122.172462] RAX: ffff880080945fff RBX: 0000000000000000 RCX: 0000000001000000 [ 122.173709] RDX: 0000000000ffffff RSI: ffff880080946000 RDI: ffff8800348a1010 [ 122.174978] RBP: ffff880076477bb8 R08: ffff880076477c80 R09: 0000000000000000 [ 122.176227] R10: 00007ffffffff000 R11: ffff88007f946000 R12: ffff88007f946000 [ 122.177496] R13: ffff880076477c80 R14: ffff8800348a1010 R15: ffff8800348a2400 [ 122.178745] FS: 00007fd459eb4700(0000) GS:ffff88007b6c0000(0000) knlGS:0000000000000000 [ 122.180176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 122.181186] CR2: ffff880080945fff CR3: 0000000073422000 CR4: 00000000001406e0 [ 122.182469] Stack: [ 122.182843] 00ffffff00000001 ffff880080946000 0000000000000000 0000000000000000 [ 122.184409] 00000000570f789c ffff880076477c30 ffffffff81385671 ffff88007a2e7a58 [ 122.185810] 0000000000000000 ffff880076477c88 01000000008a1000 0000000000000000 [ 122.187231] Call Trace: [ 122.187680] [<ffffffff81385671>] aa_path_name+0x81/0x370 [ 122.188637] [<ffffffff813875dd>] profile_transition+0xbd/0xb80 [ 122.190181] [<ffffffff811af9bc>] ? zone_statistics+0x7c/0xa0 [ 122.191674] [<ffffffff81389b20>] apparmor_bprm_set_creds+0x9b0/0xac0 [ 122.193288] [<ffffffff812e1971>] ? ext4_xattr_get+0x81/0x220 [ 122.194793] [<ffffffff812e800c>] ? ext4_xattr_security_get+0x1c/0x30 [ 122.196392] [<ffffffff813449b9>] ? get_vfs_caps_from_disk+0x69/0x110 [ 122.198004] [<ffffffff81232d4f>] ? mnt_may_suid+0x3f/0x50 [ 122.199737] [<ffffffff81344b03>] ? cap_bprm_set_creds+0xa3/0x600 [ 122.201377] [<ffffffff81346e53>] security_bprm_set_creds+0x33/0x50 [ 122.203024] [<ffffffff81214ce5>] prepare_binprm+0x85/0x190 [ 122.204515] [<ffffffff81216545>] do_execveat_common.isra.33+0x485/0x710 [ 122.206200] [<ffffffff81216a6a>] SyS_execve+0x3a/0x50 [ 122.207615] [<ffffffff81838795>] stub_execve+0x5/0x5 [ 122.208978] [<ffffffff818384f2>] ? entry_SYSCALL_64_fastpath+0x16/0x71 [ 122.210615] Code: f8 31 c0 48 63 c2 83 ea 01 48 c7 45 e8 00 00 00 00 48 01 c6 85 d2 48 c7 45 f0 00 00 00 00 48 89 75 e0 89 55 dc 78 0c 48 8d 46 ff <c6> 46 ff 00 48 89 45 e0 48 8d 55 e0 48 8d 4d dc 48 8d 75 e8 e8 [ 122.217320] RIP [<ffffffff81228844>] d_absolute_path+0x44/0xa0 [ 122.218860] RSP <ffff880076477b90> [ 122.219919] CR2: ffff880080945fff [ 122.220936] ---[ end trace 506cdbd85eb6c55e ]--- Reported-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Signed-off-by: John Johansen <john.johansen(a)canonical.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/apparmor/lsm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/security/apparmor/lsm.c +++ b/security/apparmor/lsm.c @@ -735,7 +735,7 @@ module_param_named(logsyscall, aa_g_logs /* Maximum pathname length before accesses will start getting rejected */ unsigned int aa_g_path_max = 2 * PATH_MAX; -module_param_named(path_max, aa_g_path_max, aauint, S_IRUSR | S_IWUSR); +module_param_named(path_max, aa_g_path_max, aauint, S_IRUSR); /* Determines how paranoid loading of policy is and how much verification * on the loaded policy is done. Patches currently in stable-queue which might be from john.johansen(a)canonical.com are queue-3.18/apparmor-make-path_max-parameter-readonly.patch

7 years, 7 months

1
0
0 0

Patch "wil6210: fix memory access violation in wil_memcpy_from/toio_32" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled wil6210: fix memory access violation in wil_memcpy_from/toio_32 to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: wil6210-fix-memory-access-violation-in-wil_memcpy_from-toio_32.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Dedy Lansky <qca_dlansky(a)qca.qualcomm.com> Date: Wed, 5 Apr 2017 14:58:11 +0300 Subject: wil6210: fix memory access violation in wil_memcpy_from/toio_32 From: Dedy Lansky <qca_dlansky(a)qca.qualcomm.com> [ Upstream commit 0f6edfe2bbbb59d161580cb4870fcc46f5490f85 ] In case count is not multiple of 4, there is a read access in wil_memcpy_toio_32() from outside src buffer boundary. In wil_memcpy_fromio_32(), in case count is not multiple of 4, there is a write access to outside dst io memory boundary. Fix these issues with proper handling of the last 1 to 4 copied bytes. Signed-off-by: Dedy Lansky <qca_dlansky(a)qca.qualcomm.com> Signed-off-by: Maya Erez <qca_merez(a)qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/wil6210/main.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) --- a/drivers/net/wireless/ath/wil6210/main.c +++ b/drivers/net/wireless/ath/wil6210/main.c @@ -125,9 +125,15 @@ void wil_memcpy_fromio_32(void *dst, con u32 *d = dst; const volatile u32 __iomem *s = src; - /* size_t is unsigned, if (count%4 != 0) it will wrap */ - for (count += 4; count > 4; count -= 4) + for (; count >= 4; count -= 4) *d++ = __raw_readl(s++); + + if (unlikely(count)) { + /* count can be 1..3 */ + u32 tmp = __raw_readl(s); + + memcpy(d, &tmp, count); + } } void wil_memcpy_toio_32(volatile void __iomem *dst, const void *src, @@ -136,8 +142,16 @@ void wil_memcpy_toio_32(volatile void __ volatile u32 __iomem *d = dst; const u32 *s = src; - for (count += 4; count > 4; count -= 4) + for (; count >= 4; count -= 4) __raw_writel(*s++, d++); + + if (unlikely(count)) { + /* count can be 1..3 */ + u32 tmp = 0; + + memcpy(&tmp, s, count); + __raw_writel(tmp, d); + } } static void wil_disconnect_cid(struct wil6210_priv *wil, int cid, Patches currently in stable-queue which might be from qca_dlansky(a)qca.qualcomm.com are queue-4.4/wil6210-fix-memory-access-violation-in-wil_memcpy_from-toio_32.patch

7 years, 7 months

1
0
0 0

Patch "vxlan: vxlan dev should inherit lowerdev's gso_max_size" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vxlan: vxlan dev should inherit lowerdev's gso_max_size to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: vxlan-vxlan-dev-should-inherit-lowerdev-s-gso_max_size.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Felix Manlunas <felix.manlunas(a)cavium.com> Date: Wed, 29 Mar 2017 17:56:43 -0700 Subject: vxlan: vxlan dev should inherit lowerdev's gso_max_size From: Felix Manlunas <felix.manlunas(a)cavium.com> [ Upstream commit d6acfeb17d030bb3907e77c048b0e7783ad8e5a9 ] vxlan dev currently ignores lowerdev's gso_max_size, which adversely affects TSO performance of liquidio if it's the lowerdev. Egress TCP packets' skb->len often exceed liquidio's advertised gso_max_size. This may happen on other NIC drivers. Fix it by assigning lowerdev's gso_max_size to that of vxlan dev. Might as well do likewise for gso_max_segs. Single flow TSO throughput of liquidio as lowerdev (using iperf3): Before the patch: 139 Mbps After the patch : 8.68 Gbps Percent increase: 6,144 % Signed-off-by: Felix Manlunas <felix.manlunas(a)cavium.com> Signed-off-by: Satanand Burla <satananda.burla(a)cavium.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/vxlan.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/net/vxlan.c +++ b/drivers/net/vxlan.c @@ -2834,6 +2834,11 @@ static int vxlan_dev_configure(struct ne needed_headroom = lowerdev->hard_header_len; } + if (lowerdev) { + dev->gso_max_size = lowerdev->gso_max_size; + dev->gso_max_segs = lowerdev->gso_max_segs; + } + if (conf->mtu) { err = __vxlan_change_mtu(dev, lowerdev, dst, conf->mtu, false); if (err) Patches currently in stable-queue which might be from felix.manlunas(a)cavium.com are queue-4.4/vxlan-vxlan-dev-should-inherit-lowerdev-s-gso_max_size.patch

7 years, 7 months

1
0
0 0

Patch "video/hdmi: Allow "empty" HDMI infoframes" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled video/hdmi: Allow "empty" HDMI infoframes to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: video-hdmi-allow-empty-hdmi-infoframes.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: "Ville Syrjälä" <ville.syrjala(a)linux.intel.com> Date: Mon, 13 Nov 2017 19:04:18 +0200 Subject: video/hdmi: Allow "empty" HDMI infoframes From: "Ville Syrjälä" <ville.syrjala(a)linux.intel.com> [ Upstream commit 593f4b19a094c4426bd1e1e3cbab87a48bd13c71 ] HDMI 2.0 Appendix F suggest that we should keep sending the infoframe when switching from 3D to 2D mode, even if the infoframe isn't strictly necessary (ie. not needed to transmit the VIC or stereo information). This is a workaround against some sinks that fail to realize that they should switch from 3D to 2D mode when the source stop transmitting the infoframe. v2: Handle unpack() as well Pull the length calculation into a helper Cc: Shashank Sharma <shashank.sharma(a)intel.com> Cc: Andrzej Hajda <a.hajda(a)samsung.com> Cc: Thierry Reding <thierry.reding(a)gmail.com> Cc: Hans Verkuil <hans.verkuil(a)cisco.com> Cc: linux-media(a)vger.kernel.org Reviewed-by: Andrzej Hajda <a.hajda(a)samsung.com> #v1 Signed-off-by: Ville SyrjÃ¤lÃ¤ <ville.syrjala(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171113170427.4150-2-ville.s… Reviewed-by: Shashank Sharma <shashank.sharma(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/hdmi.c | 51 +++++++++++++++++++++++++++++++-------------------- 1 file changed, 31 insertions(+), 20 deletions(-) --- a/drivers/video/hdmi.c +++ b/drivers/video/hdmi.c @@ -321,6 +321,17 @@ int hdmi_vendor_infoframe_init(struct hd } EXPORT_SYMBOL(hdmi_vendor_infoframe_init); +static int hdmi_vendor_infoframe_length(const struct hdmi_vendor_infoframe *frame) +{ + /* for side by side (half) we also need to provide 3D_Ext_Data */ + if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) + return 6; + else if (frame->vic != 0 || frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) + return 5; + else + return 4; +} + /** * hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary buffer * @frame: HDMI infoframe @@ -341,19 +352,11 @@ ssize_t hdmi_vendor_infoframe_pack(struc u8 *ptr = buffer; size_t length; - /* empty info frame */ - if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID) - return -EINVAL; - /* only one of those can be supplied */ if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) return -EINVAL; - /* for side by side (half) we also need to provide 3D_Ext_Data */ - if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) - frame->length = 6; - else - frame->length = 5; + frame->length = hdmi_vendor_infoframe_length(frame); length = HDMI_INFOFRAME_HEADER_SIZE + frame->length; @@ -372,14 +375,16 @@ ssize_t hdmi_vendor_infoframe_pack(struc ptr[5] = 0x0c; ptr[6] = 0x00; - if (frame->vic) { - ptr[7] = 0x1 << 5; /* video format */ - ptr[8] = frame->vic; - } else { + if (frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) { ptr[7] = 0x2 << 5; /* video format */ ptr[8] = (frame->s3d_struct & 0xf) << 4; if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) ptr[9] = (frame->s3d_ext_data & 0xf) << 4; + } else if (frame->vic) { + ptr[7] = 0x1 << 5; /* video format */ + ptr[8] = frame->vic; + } else { + ptr[7] = 0x0 << 5; /* video format */ } hdmi_infoframe_set_checksum(buffer, length); @@ -1161,7 +1166,7 @@ hdmi_vendor_any_infoframe_unpack(union h if (ptr[0] != HDMI_INFOFRAME_TYPE_VENDOR || ptr[1] != 1 || - (ptr[2] != 5 && ptr[2] != 6)) + (ptr[2] != 4 && ptr[2] != 5 && ptr[2] != 6)) return -EINVAL; length = ptr[2]; @@ -1189,16 +1194,22 @@ hdmi_vendor_any_infoframe_unpack(union h hvf->length = length; - if (hdmi_video_format == 0x1) { - hvf->vic = ptr[4]; - } else if (hdmi_video_format == 0x2) { + if (hdmi_video_format == 0x2) { + if (length != 5 && length != 6) + return -EINVAL; hvf->s3d_struct = ptr[4] >> 4; if (hvf->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) { - if (length == 6) - hvf->s3d_ext_data = ptr[5] >> 4; - else + if (length != 6) return -EINVAL; + hvf->s3d_ext_data = ptr[5] >> 4; } + } else if (hdmi_video_format == 0x1) { + if (length != 5) + return -EINVAL; + hvf->vic = ptr[4]; + } else { + if (length != 4) + return -EINVAL; } return 0; Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are queue-4.4/drm-defer-disabling-the-vblank-irq-until-the-next-interrupt-for-instant-off.patch queue-4.4/video-hdmi-allow-empty-hdmi-infoframes.patch queue-4.4/drm-edid-set-eld-connector-type-in-drm_edid_to_eld.patch

7 years, 7 months

1
0
0 0

Patch "video: ARM CLCD: fix dma allocation size" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled video: ARM CLCD: fix dma allocation size to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: video-arm-clcd-fix-dma-allocation-size.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Liam Beguin <lbeguin(a)tycoint.com> Date: Fri, 7 Apr 2017 17:03:24 +0200 Subject: video: ARM CLCD: fix dma allocation size From: Liam Beguin <lbeguin(a)tycoint.com> [ Upstream commit 9a1c779e6b06855e41099caa6f15b3b584dfa88c ] This patch forces the frambuffer size to be aligned on kernel pages. During the board startup, the splash screed did appear; the "ts_test" program or our application were not able to start. The following error message was reported: error: failed to map framebuffer device to memory. LinuxFB: driver cannot connect The issue was discovered, on the LPC32xx platform, during the migration of the LCD definition from the board file to the device tree. Signed-off-by: Liam Beguin <lbeguin(a)tycoint.com> Signed-off-by: Sylvain Lemieux <slemieux(a)tycoint.com> Cc: Vladimir Zapolskiy <vz(a)mleia.com> Cc: Russell King <linux(a)armlinux.org.uk> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/amba-clcd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/video/fbdev/amba-clcd.c +++ b/drivers/video/fbdev/amba-clcd.c @@ -759,8 +759,8 @@ static int clcdfb_of_dma_setup(struct cl if (err) return err; - framesize = fb->panel->mode.xres * fb->panel->mode.yres * - fb->panel->bpp / 8; + framesize = PAGE_ALIGN(fb->panel->mode.xres * fb->panel->mode.yres * + fb->panel->bpp / 8); fb->fb.screen_base = dma_alloc_coherent(&fb->dev->dev, framesize, &dma, GFP_KERNEL); if (!fb->fb.screen_base) Patches currently in stable-queue which might be from lbeguin(a)tycoint.com are queue-4.4/video-arm-clcd-fix-dma-allocation-size.patch

7 years, 7 months

1
0
0 0

Patch "veth: set peer GSO values" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled veth: set peer GSO values to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: veth-set-peer-gso-values.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Stephen Hemminger <stephen(a)networkplumber.org> Date: Thu, 7 Dec 2017 15:40:20 -0800 Subject: veth: set peer GSO values From: Stephen Hemminger <stephen(a)networkplumber.org> [ Upstream commit 72d24955b44a4039db54a1c252b5031969eeaac3 ] When new veth is created, and GSO values have been configured on one device, clone those values to the peer. For example: # ip link add dev vm1 gso_max_size 65530 type veth peer name vm2 This should create vm1 <--> vm2 with both having GSO maximum size set to 65530. Signed-off-by: Stephen Hemminger <sthemmin(a)microsoft.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/veth.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/net/veth.c +++ b/drivers/net/veth.c @@ -399,6 +399,9 @@ static int veth_newlink(struct net *src_ if (ifmp && (dev->ifindex != 0)) peer->ifindex = ifmp->ifi_index; + peer->gso_max_size = dev->gso_max_size; + peer->gso_max_segs = dev->gso_max_segs; + err = register_netdevice(peer); put_net(net); net = NULL; Patches currently in stable-queue which might be from stephen(a)networkplumber.org are queue-4.4/veth-set-peer-gso-values.patch

7 years, 7 months

1
0
0 0

Patch "usb: gadget: dummy_hcd: Fix wrong power status bit clear/reset in dummy_hub_control()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: gadget: dummy_hcd: Fix wrong power status bit clear/reset in dummy_hub_control() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-gadget-dummy_hcd-fix-wrong-power-status-bit-clear-reset-in-dummy_hub_control.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Yuyang Du <yuyang.du(a)intel.com> Date: Fri, 24 Mar 2017 04:06:11 +0800 Subject: usb: gadget: dummy_hcd: Fix wrong power status bit clear/reset in dummy_hub_control() From: Yuyang Du <yuyang.du(a)intel.com> [ Upstream commit 9f20dfb44d03745d0d3cef2ffb3abf8d8024fa61 ] This fixes the commit: 1cd8fd2887e1 ("usb: gadget: dummy_hcd: add SuperSpeed support"). In the case of ClearPortFeature and USB_PORT_FEAT_POWER, simply clear the right bit regardless of what the wValue is. Acked-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Yuyang Du <yuyang.du(a)intel.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/udc/dummy_hcd.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) --- a/drivers/usb/gadget/udc/dummy_hcd.c +++ b/drivers/usb/gadget/udc/dummy_hcd.c @@ -2105,16 +2105,13 @@ static int dummy_hub_control( } break; case USB_PORT_FEAT_POWER: - if (hcd->speed == HCD_USB3) { - if (dum_hcd->port_status & USB_PORT_STAT_POWER) - dev_dbg(dummy_dev(dum_hcd), - "power-off\n"); - } else - if (dum_hcd->port_status & - USB_SS_PORT_STAT_POWER) - dev_dbg(dummy_dev(dum_hcd), - "power-off\n"); - /* FALLS THROUGH */ + dev_dbg(dummy_dev(dum_hcd), "power-off\n"); + if (hcd->speed == HCD_USB3) + dum_hcd->port_status &= ~USB_SS_PORT_STAT_POWER; + else + dum_hcd->port_status &= ~USB_PORT_STAT_POWER; + set_link_state(dum_hcd); + break; default: dum_hcd->port_status &= ~(1 << wValue); set_link_state(dum_hcd); @@ -2285,14 +2282,13 @@ static int dummy_hub_control( if ((dum_hcd->port_status & USB_SS_PORT_STAT_POWER) != 0) { dum_hcd->port_status |= (1 << wValue); - set_link_state(dum_hcd); } } else if ((dum_hcd->port_status & USB_PORT_STAT_POWER) != 0) { dum_hcd->port_status |= (1 << wValue); - set_link_state(dum_hcd); } + set_link_state(dum_hcd); } break; case GetPortErrorCount: Patches currently in stable-queue which might be from yuyang.du(a)intel.com are queue-4.4/usb-gadget-dummy_hcd-fix-wrong-power-status-bit-clear-reset-in-dummy_hub_control.patch

7 years, 7 months

1
0
0 0

Patch "usb: dwc2: Make sure we disconnect the gadget state" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: dwc2: Make sure we disconnect the gadget state to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-dwc2-make-sure-we-disconnect-the-gadget-state.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: John Stultz <john.stultz(a)linaro.org> Date: Mon, 13 Feb 2017 20:08:08 -0800 Subject: usb: dwc2: Make sure we disconnect the gadget state From: John Stultz <john.stultz(a)linaro.org> [ Upstream commit dad3f793f20fbb5c0c342f0f5a0bdf69a4d76089 ] I had seen some odd behavior with HiKey's usb-gadget interface that I finally seemed to have chased down. Basically every other time I plugged in the OTG port, the gadget interface would properly initialize. The other times, I'd get a big WARN_ON in dwc2_hsotg_init_fifo() about the fifo_map not being clear. Ends up if we don't disconnect the gadget state, the fifo-map doesn't get cleared properly, which causes WARN_ON messages and also results in the device not properly being setup as a gadget every other time the OTG port is connected. So this patch adds a call to dwc2_hsotg_disconnect() in the reset path so the state is properly cleared. With it, the gadget interface initializes properly on every plug in. Cc: Wei Xu <xuwei5(a)hisilicon.com> Cc: Guodong Xu <guodong.xu(a)linaro.org> Cc: Amit Pundir <amit.pundir(a)linaro.org> Cc: Rob Herring <robh+dt(a)kernel.org> Cc: John Youn <johnyoun(a)synopsys.com> Cc: Douglas Anderson <dianders(a)chromium.org> Cc: Chen Yu <chenyu56(a)huawei.com> Cc: Felipe Balbi <felipe.balbi(a)linux.intel.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: linux-usb(a)vger.kernel.org Acked-by: John Youn <johnyoun(a)synopsys.com> Signed-off-by: John Stultz <john.stultz(a)linaro.org> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/dwc2/hcd.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/dwc2/hcd.c +++ b/drivers/usb/dwc2/hcd.c @@ -1385,6 +1385,7 @@ static void dwc2_conn_id_status_change(s dwc2_core_init(hsotg, false, -1); dwc2_enable_global_interrupts(hsotg); spin_lock_irqsave(&hsotg->lock, flags); + dwc2_hsotg_disconnect(hsotg); dwc2_hsotg_core_init_disconnected(hsotg, false); spin_unlock_irqrestore(&hsotg->lock, flags); dwc2_hsotg_core_connect(hsotg); Patches currently in stable-queue which might be from john.stultz(a)linaro.org are queue-4.4/usb-dwc2-make-sure-we-disconnect-the-gadget-state.patch queue-4.4/sysrq-reset-the-watchdog-timers-while-displaying-high-resolution-timers.patch queue-4.4/timers-sched_clock-update-timeout-for-clock-wrap.patch

7 years, 7 months

1
0
0 0

Patch "timers, sched_clock: Update timeout for clock wrap" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled timers, sched_clock: Update timeout for clock wrap to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: timers-sched_clock-update-timeout-for-clock-wrap.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: David Engraf <david.engraf(a)sysgo.com> Date: Fri, 17 Feb 2017 08:51:03 +0100 Subject: timers, sched_clock: Update timeout for clock wrap From: David Engraf <david.engraf(a)sysgo.com> [ Upstream commit 1b8955bc5ac575009835e371ae55e7f3af2197a9 ] The scheduler clock framework may not use the correct timeout for the clock wrap. This happens when a new clock driver calls sched_clock_register() after the kernel called sched_clock_postinit(). In this case the clock wrap timeout is too long thus sched_clock_poll() is called too late and the clock already wrapped. On my ARM system the scheduler was no longer scheduling any other task than the idle task because the sched_clock() wrapped. Signed-off-by: David Engraf <david.engraf(a)sysgo.com> Signed-off-by: John Stultz <john.stultz(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/time/sched_clock.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/kernel/time/sched_clock.c +++ b/kernel/time/sched_clock.c @@ -205,6 +205,11 @@ sched_clock_register(u64 (*read)(void), update_clock_read_data(&rd); + if (sched_clock_timer.function != NULL) { + /* update timeout for clock wrap */ + hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL); + } + r = rate; if (r >= 4000000) { r /= 1000000; Patches currently in stable-queue which might be from david.engraf(a)sysgo.com are queue-4.4/timers-sched_clock-update-timeout-for-clock-wrap.patch

7 years, 7 months

1
0
0 0

Patch "tools/usbip: fixes build with musl libc toolchain" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tools/usbip: fixes build with musl libc toolchain to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: tools-usbip-fixes-build-with-musl-libc-toolchain.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Mar 19 09:58:12 CET 2018 From: Julien BOIBESSOT <julien.boibessot(a)armadeus.com> Date: Tue, 5 Dec 2017 18:48:14 +0100 Subject: tools/usbip: fixes build with musl libc toolchain From: Julien BOIBESSOT <julien.boibessot(a)armadeus.com> [ Upstream commit 77be4c878c72e411ad22af96b6f81dd45c26450a ] Indeed musl doesn't define old SIGCLD signal name but only new one SIGCHLD. SIGCHLD is the new POSIX name for that signal so it doesn't change anything on other libcs. This fixes this kind of build error: usbipd.c: In function ‘set_signal’: usbipd.c:459:12: error: 'SIGCLD' undeclared (first use in this function) sigaction(SIGCLD, &act, NULL); ^~~~~~ usbipd.c:459:12: note: each undeclared identifier is reported only once for each function it appears in Makefile:407: recipe for target 'usbipd.o' failed make[3]: *** [usbipd.o] Error 1 Signed-off-by: Julien BOIBESSOT <julien.boibessot(a)armadeus.com> Acked-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/usb/usbip/src/usbipd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/usb/usbip/src/usbipd.c +++ b/tools/usb/usbip/src/usbipd.c @@ -451,7 +451,7 @@ static void set_signal(void) sigaction(SIGTERM, &act, NULL); sigaction(SIGINT, &act, NULL); act.sa_handler = SIG_IGN; - sigaction(SIGCLD, &act, NULL); + sigaction(SIGCHLD, &act, NULL); } static const char *pid_file; Patches currently in stable-queue which might be from julien.boibessot(a)armadeus.com are queue-4.4/tools-usbip-fixes-build-with-musl-libc-toolchain.patch

7 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror