December 2017 - Linux-stable-mirror

[Linux-stable-mirror] Patch "IB/hfi1: Do not warn on lid conversions for OPA" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/hfi1: Do not warn on lid conversions for OPA to the 4.14-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: ib-hfi1-do-not-warn-on-lid-conversions-for-opa.patch and it can be found in the queue-4.14 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 4988be5813ff2afdc0d8bfa315ef34a577d3efbf Mon Sep 17 00:00:00 2001 From: Don Hiatt <don.hiatt(a)intel.com> Date: Mon, 2 Oct 2017 11:04:55 -0700 Subject: IB/hfi1: Do not warn on lid conversions for OPA From: Don Hiatt <don.hiatt(a)intel.com> commit 4988be5813ff2afdc0d8bfa315ef34a577d3efbf upstream. On OPA devices opa_local_smp_check will receive 32Bit LIDs when the LID is Extended. In such cases, it is okay to lose the upper 16 bits of the LID as this information is obtained elsewhere. Do not issue a warning when calling ib_lid_cpu16() in this case by masking out the upper 16Bits. [75920.148985] ------------[ cut here ]------------ [75920.154651] WARNING: CPU: 0 PID: 1718 at ./include/rdma/ib_verbs.h:3788 hfi1_process_mad+0x1c1f/0x1c80 [hfi1] [75920.166192] Modules linked in: ib_ipoib hfi1(E) rdmavt(E) rdma_ucm(E) ib_ucm(E) rdma_cm(E) ib_cm(E) iw_cm(E) ib_umad(E) ib_uverbs(E) ib_core(E) libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod dax x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel mei_me ipmi_si iTCO_wdt iTCO_vendor_support crypto_simd ipmi_devintf pcspkr mei sg i2c_i801 glue_helper lpc_ich shpchp ioatdma mfd_core wmi ipmi_msghandler cryptd acpi_power_meter acpi_pad nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm igb ptp ahci libahci pps_core crc32c_intel libata dca i2c_algo_bit i2c_core [last unloaded: ib_core] [75920.246331] CPU: 0 PID: 1718 Comm: kworker/0:1H Tainted: G W I E 4.13.0-rc7+ #1 [75920.255907] Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015 [75920.268158] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core] [75920.274934] task: ffff88084a718000 task.stack: ffffc9000a424000 [75920.282123] RIP: 0010:hfi1_process_mad+0x1c1f/0x1c80 [hfi1] [75920.288881] RSP: 0018:ffffc9000a427c38 EFLAGS: 00010206 [75920.295265] RAX: 0000000000010001 RBX: ffff8808361420e8 RCX: ffff880837811d80 [75920.303784] RDX: 0000000000000002 RSI: 0000000000007fff RDI: ffff880837811d80 [75920.312302] RBP: ffffc9000a427d38 R08: 0000000000000000 R09: ffff8808361420e8 [75920.320819] R10: ffff88083841f0e8 R11: ffffc9000a427da8 R12: 0000000000000001 [75920.329335] R13: ffff880837810000 R14: 0000000000000000 R15: ffff88084f1a4800 [75920.337849] FS: 0000000000000000(0000) GS:ffff88085f400000(0000) knlGS:0000000000000000 [75920.347450] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [75920.354405] CR2: 00007f9e4b3d9000 CR3: 0000000001c09000 CR4: 00000000001406f0 [75920.362947] Call Trace: [75920.366257] ? ib_mad_recv_done+0x258/0x9b0 [ib_core] [75920.372457] ? ib_mad_recv_done+0x258/0x9b0 [ib_core] [75920.378652] ? __kmalloc+0x1df/0x210 [75920.383229] ib_mad_recv_done+0x305/0x9b0 [ib_core] [75920.389270] __ib_process_cq+0x5d/0xb0 [ib_core] [75920.395032] ib_cq_poll_work+0x20/0x60 [ib_core] [75920.400777] process_one_work+0x149/0x360 [75920.405836] worker_thread+0x4d/0x3c0 [75920.410505] kthread+0x109/0x140 [75920.414681] ? rescuer_thread+0x380/0x380 [75920.419731] ? kthread_park+0x60/0x60 [75920.424406] ret_from_fork+0x25/0x30 [75920.428972] Code: 4c 89 9d 58 ff ff ff 49 89 45 00 66 b8 00 02 49 89 45 08 e8 44 27 89 e0 4c 8b 9d 58 ff ff ff e9 d8 f6 ff ff 0f ff e9 55 e7 ff ff <0f> ff e9 3b e5 ff ff 0f ff 0f 1f 84 00 00 00 00 00 e9 4b e9 ff [75921.451269] ---[ end trace cf26df27c9597265 ]--- Fixes: 62ede7779904 ("Add OPA extended LID support") Reviewed-by: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Signed-off-by: Don Hiatt <don.hiatt(a)intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Reviewed-by: Leon Romanovsky <leonro(a)mellanox.com> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/hfi1/mad.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/infiniband/hw/hfi1/mad.c +++ b/drivers/infiniband/hw/hfi1/mad.c @@ -4293,7 +4293,6 @@ static int opa_local_smp_check(struct hf const struct ib_wc *in_wc) { struct hfi1_pportdata *ppd = ppd_from_ibp(ibp); - u16 slid = ib_lid_cpu16(in_wc->slid); u16 pkey; if (in_wc->pkey_index >= ARRAY_SIZE(ppd->pkeys)) @@ -4320,7 +4319,11 @@ static int opa_local_smp_check(struct hf */ if (pkey == LIM_MGMT_P_KEY || pkey == FULL_MGMT_P_KEY) return 0; - ingress_pkey_table_fail(ppd, pkey, slid); + /* + * On OPA devices it is okay to lose the upper 16 bits of LID as this + * information is obtained elsewhere. Mask off the upper 16 bits. + */ + ingress_pkey_table_fail(ppd, pkey, ib_lid_cpu16(0xFFFF & in_wc->slid)); return 1; } Patches currently in stable-queue which might be from don.hiatt(a)intel.com are queue-4.14/ib-hfi1-do-not-warn-on-lid-conversions-for-opa.patch queue-4.14/ib-core-do-not-warn-on-lid-conversions-for-opa.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "IB/core: Do not warn on lid conversions for OPA" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/core: Do not warn on lid conversions for OPA to the 4.14-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: ib-core-do-not-warn-on-lid-conversions-for-opa.patch and it can be found in the queue-4.14 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 6588e412fe872ed81f3fb8d9b4561a66ecb763d0 Mon Sep 17 00:00:00 2001 From: Don Hiatt <don.hiatt(a)intel.com> Date: Mon, 2 Oct 2017 11:04:48 -0700 Subject: IB/core: Do not warn on lid conversions for OPA From: Don Hiatt <don.hiatt(a)intel.com> commit 6588e412fe872ed81f3fb8d9b4561a66ecb763d0 upstream. On OPA devices the user_mad recv_handler can receive 32Bit LIDs (e.g. OPA_PERMISSIVE_LID) and it is okay to lose the upper 16 bits of the LID as this information is obtained elsewhere. Do not issue a warning when calling ib_lid_be16() in this case by masking out the upper 16Bits. [75667.310846] ------------[ cut here ]------------ [75667.316447] WARNING: CPU: 0 PID: 1718 at ./include/rdma/ib_verbs.h:3799 recv_handler+0x15a/0x170 [ib_umad] [75667.327640] Modules linked in: ib_ipoib hfi1(E) rdmavt(E) rdma_ucm(E) ib_ucm(E) rdma_cm(E) ib_cm(E) iw_cm(E) ib_umad(E) ib_uverbs(E) ib_core(E) libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod dax x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel mei_me ipmi_si iTCO_wdt iTCO_vendor_support crypto_simd ipmi_devintf pcspkr mei sg i2c_i801 glue_helper lpc_ich shpchp ioatdma mfd_core wmi ipmi_msghandler cryptd acpi_power_meter acpi_pad nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm igb ptp ahci libahci pps_core crc32c_intel libata dca i2c_algo_bit i2c_core [last unloaded: ib_core] [75667.407704] CPU: 0 PID: 1718 Comm: kworker/0:1H Tainted: G W I E 4.13.0-rc7+ #1 [75667.417310] Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015 [75667.429555] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core] [75667.436360] task: ffff88084a718000 task.stack: ffffc9000a424000 [75667.443549] RIP: 0010:recv_handler+0x15a/0x170 [ib_umad] [75667.450090] RSP: 0018:ffffc9000a427ce8 EFLAGS: 00010286 [75667.456508] RAX: 00000000ffffffff RBX: ffff88085159ce80 RCX: 0000000000000000 [75667.465094] RDX: ffff88085a47b068 RSI: 0000000000000000 RDI: ffff88085159cf00 [75667.473668] RBP: ffffc9000a427d38 R08: 000000000001efc0 R09: ffff88085159ce80 [75667.482228] R10: ffff88085f007480 R11: ffff88084acf20e8 R12: ffff88085a47b020 [75667.490824] R13: ffff881056842e10 R14: ffff881056840200 R15: ffff88104c8d0800 [75667.499390] FS: 0000000000000000(0000) GS:ffff88085f400000(0000) knlGS:0000000000000000 [75667.509028] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [75667.516080] CR2: 00007f9e4b3d9000 CR3: 0000000001c09000 CR4: 00000000001406f0 [75667.524664] Call Trace: [75667.528044] ? find_mad_agent+0x7c/0x1b0 [ib_core] [75667.534031] ? ib_mark_mad_done+0x73/0xa0 [ib_core] [75667.540142] ib_mad_recv_done+0x423/0x9b0 [ib_core] [75667.546215] __ib_process_cq+0x5d/0xb0 [ib_core] [75667.552007] ib_cq_poll_work+0x20/0x60 [ib_core] [75667.557766] process_one_work+0x149/0x360 [75667.562844] worker_thread+0x4d/0x3c0 [75667.567529] kthread+0x109/0x140 [75667.571713] ? rescuer_thread+0x380/0x380 [75667.576775] ? kthread_park+0x60/0x60 [75667.581447] ret_from_fork+0x25/0x30 [75667.586014] Code: 43 4a 0f b6 45 c6 88 43 4b 48 8b 45 b0 48 89 43 4c 48 8b 45 b8 48 89 43 54 8b 45 c0 0f c8 89 43 5c e9 79 ff ff ff e8 16 4e fa e0 <0f> ff e9 42 ff ff ff 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 [75667.608323] ---[ end trace cf26df27c9597264 ]--- Fixes: 62ede7779904 ("Add OPA extended LID support") Reviewed-by: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Signed-off-by: Don Hiatt <don.hiatt(a)intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Reviewed-by: Leon Romanovsky <leonro(a)mellanox.com> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/user_mad.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) --- a/drivers/infiniband/core/user_mad.c +++ b/drivers/infiniband/core/user_mad.c @@ -229,7 +229,16 @@ static void recv_handler(struct ib_mad_a packet->mad.hdr.status = 0; packet->mad.hdr.length = hdr_size(file) + mad_recv_wc->mad_len; packet->mad.hdr.qpn = cpu_to_be32(mad_recv_wc->wc->src_qp); - packet->mad.hdr.lid = ib_lid_be16(mad_recv_wc->wc->slid); + /* + * On OPA devices it is okay to lose the upper 16 bits of LID as this + * information is obtained elsewhere. Mask off the upper 16 bits. + */ + if (agent->device->port_immutable[agent->port_num].core_cap_flags & + RDMA_CORE_PORT_INTEL_OPA) + packet->mad.hdr.lid = ib_lid_be16(0xFFFF & + mad_recv_wc->wc->slid); + else + packet->mad.hdr.lid = ib_lid_be16(mad_recv_wc->wc->slid); packet->mad.hdr.sl = mad_recv_wc->wc->sl; packet->mad.hdr.path_bits = mad_recv_wc->wc->dlid_path_bits; packet->mad.hdr.pkey_index = mad_recv_wc->wc->pkey_index; Patches currently in stable-queue which might be from don.hiatt(a)intel.com are queue-4.14/ib-hfi1-do-not-warn-on-lid-conversions-for-opa.patch queue-4.14/ib-core-do-not-warn-on-lid-conversions-for-opa.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "e1000e: fix the use of magic numbers for buffer overrun issue" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled e1000e: fix the use of magic numbers for buffer overrun issue to the 4.14-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: e1000e-fix-the-use-of-magic-numbers-for-buffer-overrun-issue.patch and it can be found in the queue-4.14 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 c0f4b163a03e73055dd734eaca64b9580e72e7fb Mon Sep 17 00:00:00 2001 From: Sasha Neftin <sasha.neftin(a)intel.com> Date: Mon, 6 Nov 2017 08:31:59 +0200 Subject: e1000e: fix the use of magic numbers for buffer overrun issue From: Sasha Neftin <sasha.neftin(a)intel.com> commit c0f4b163a03e73055dd734eaca64b9580e72e7fb upstream. This is a follow on to commit b10effb92e27 ("fix buffer overrun while the I219 is processing DMA transactions") to address David Laights concerns about the use of "magic" numbers. So define masks as well as add additional code comments to give a better understanding of what needs to be done to avoid a buffer overrun. Signed-off-by: Sasha Neftin <sasha.neftin(a)intel.com> Reviewed-by: Alexander H Duyck <alexander.h.duyck(a)intel.com> Reviewed-by: Dima Ruinskiy <dima.ruinskiy(a)intel.com> Reviewed-by: Raanan Avargil <raanan.avargil(a)intel.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/e1000e/ich8lan.h | 3 ++- drivers/net/ethernet/intel/e1000e/netdev.c | 9 ++++++--- 2 files changed, 8 insertions(+), 4 deletions(-) --- a/drivers/net/ethernet/intel/e1000e/ich8lan.h +++ b/drivers/net/ethernet/intel/e1000e/ich8lan.h @@ -113,7 +113,8 @@ #define NVM_SIZE_MULTIPLIER 4096 /*multiplier for NVMS field */ #define E1000_FLASH_BASE_ADDR 0xE000 /*offset of NVM access regs */ #define E1000_CTRL_EXT_NVMVS 0x3 /*NVM valid sector */ -#define E1000_TARC0_CB_MULTIQ_3_REQ (1 << 28 | 1 << 29) +#define E1000_TARC0_CB_MULTIQ_3_REQ 0x30000000 +#define E1000_TARC0_CB_MULTIQ_2_REQ 0x20000000 #define PCIE_ICH8_SNOOP_ALL PCIE_NO_SNOOP_ALL #define E1000_ICH_RAR_ENTRIES 7 --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -3030,9 +3030,12 @@ static void e1000_configure_tx(struct e1 ew32(IOSFPC, reg_val); reg_val = er32(TARC(0)); - /* SPT and KBL Si errata workaround to avoid Tx hang */ - reg_val &= ~BIT(28); - reg_val |= BIT(29); + /* SPT and KBL Si errata workaround to avoid Tx hang. + * Dropping the number of outstanding requests from + * 3 to 2 in order to avoid a buffer overrun. + */ + reg_val &= ~E1000_TARC0_CB_MULTIQ_3_REQ; + reg_val |= E1000_TARC0_CB_MULTIQ_2_REQ; ew32(TARC(0), reg_val); } } Patches currently in stable-queue which might be from sasha.neftin(a)intel.com are queue-4.14/e1000e-fix-the-use-of-magic-numbers-for-buffer-overrun-issue.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "NFS: revalidate "." etc correctly on "open"." 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 NFS: revalidate "." etc correctly on "open". 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: nfs-revalidate-.-etc-correctly-on-open.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 b688741cb06695312f18b730653d6611e1bad28d Mon Sep 17 00:00:00 2001 From: NeilBrown <neilb(a)suse.com> Date: Fri, 25 Aug 2017 17:34:41 +1000 Subject: NFS: revalidate "." etc correctly on "open". From: NeilBrown <neilb(a)suse.com> commit b688741cb06695312f18b730653d6611e1bad28d upstream. For correct close-to-open semantics, NFS must validate the change attribute of a directory (or file) on open. Since commit ecf3d1f1aa74 ("vfs: kill FS_REVAL_DOT by adding a d_weak_revalidate dentry op"), open() of "." or a path ending ".." is not revalidated reliably (except when that direct is a mount point). Prior to that commit, "." was revalidated using nfs_lookup_revalidate() which checks the LOOKUP_OPEN flag and forces revalidation if the flag is set. Since that commit, nfs_weak_revalidate() is used for NFSv3 (which ignores the flags) and nothing is used for NFSv4. This is fixed by using nfs_lookup_verify_inode() in nfs_weak_revalidate(). This does the revalidation exactly when needed. Also, add a definition of .d_weak_revalidate for NFSv4. The incorrect behavior is easily demonstrated by running "echo *" in some non-mountpoint NFS directory while watching network traffic. Without this patch, "echo *" sometimes doesn't produce any traffic. With the patch it always does. Fixes: ecf3d1f1aa74 ("vfs: kill FS_REVAL_DOT by adding a d_weak_revalidate dentry op") cc: stable(a)vger.kernel.org (3.9+) Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfs/dir.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -1266,7 +1266,7 @@ static int nfs_weak_revalidate(struct de return 0; } - error = nfs_revalidate_inode(NFS_SERVER(inode), inode); + error = nfs_lookup_verify_inode(inode, flags); dfprintk(LOOKUPCACHE, "NFS: %s: inode %lu is %s\n", __func__, inode->i_ino, error ? "invalid" : "valid"); return !error; @@ -1426,6 +1426,7 @@ static int nfs4_lookup_revalidate(struct const struct dentry_operations nfs4_dentry_operations = { .d_revalidate = nfs4_lookup_revalidate, + .d_weak_revalidate = nfs_weak_revalidate, .d_delete = nfs_dentry_delete, .d_iput = nfs_dentry_iput, .d_automount = nfs_d_automount, Patches currently in stable-queue which might be from neilb(a)suse.com are queue-3.18/nfs-revalidate-.-etc-correctly-on-open.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "drm/panel: simple: Add missing panel_simple_unprepare() calls" 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 drm/panel: simple: Add missing panel_simple_unprepare() calls 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: drm-panel-simple-add-missing-panel_simple_unprepare-calls.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 f3621a8eb59a913612c8e6e37d81f16b649f8b6c Mon Sep 17 00:00:00 2001 From: Jonathan Liu <net147(a)gmail.com> Date: Mon, 7 Aug 2017 21:55:45 +1000 Subject: drm/panel: simple: Add missing panel_simple_unprepare() calls From: Jonathan Liu <net147(a)gmail.com> commit f3621a8eb59a913612c8e6e37d81f16b649f8b6c upstream. During panel removal or system shutdown panel_simple_disable() is called which disables the panel backlight but the panel is still powered due to missing calls to panel_simple_unprepare(). Fixes: d02fd93e2cd8 ("drm/panel: simple - Disable panel on shutdown") Signed-off-by: Jonathan Liu <net147(a)gmail.com> Signed-off-by: Thierry Reding <treding(a)nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170807115545.27747-1-net147… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/panel/panel-simple.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -312,6 +312,7 @@ static int panel_simple_remove(struct de drm_panel_remove(&panel->base); panel_simple_disable(&panel->base); + panel_simple_unprepare(&panel->base); if (panel->ddc) put_device(&panel->ddc->dev); @@ -327,6 +328,7 @@ static void panel_simple_shutdown(struct struct panel_simple *panel = dev_get_drvdata(dev); panel_simple_disable(&panel->base); + panel_simple_unprepare(&panel->base); } static const struct drm_display_mode auo_b101aw03_mode = { Patches currently in stable-queue which might be from net147(a)gmail.com are queue-3.18/drm-panel-simple-add-missing-panel_simple_unprepare-calls.patch

7 years

1
0
0 0

Re: [Linux-stable-mirror] FAILED: patch "[PATCH] NFS: revalidate "." etc correctly on "open"." failed to apply to 3.18-stable tree

by Greg KH

On Wed, Nov 29, 2017 at 01:06:35PM +1100, NeilBrown wrote: > > Subject: [PATCH] NFS: revalidate "." etc correctly on "open". > > commit b688741cb06695312f18b730653d6611e1bad28d upstream. > > For correct close-to-open semantics, NFS must validate > the change attribute of a directory (or file) on open. > > Since commit ecf3d1f1aa74 ("vfs: kill FS_REVAL_DOT by adding a > d_weak_revalidate dentry op"), open() of "." or a path ending ".." is > not revalidated reliably (except when that direct is a mount point). > > Prior to that commit, "." was revalidated using nfs_lookup_revalidate() > which checks the LOOKUP_OPEN flag and forces revalidation if the flag is > set. > Since that commit, nfs_weak_revalidate() is used for NFSv3 (which > ignores the flags) and nothing is used for NFSv4. > > This is fixed by using nfs_lookup_verify_inode() in > nfs_weak_revalidate(). This does the revalidation exactly when needed. > Also, add a definition of .d_weak_revalidate for NFSv4. > > The incorrect behavior is easily demonstrated by running "echo *" in > some non-mountpoint NFS directory while watching network traffic. > Without this patch, "echo *" sometimes doesn't produce any traffic. > With the patch it always does. > > Fixes: ecf3d1f1aa74 ("vfs: kill FS_REVAL_DOT by adding a d_weak_revalidate dentry op") > cc: stable(a)vger.kernel.org (3.9+) > Signed-off-by: NeilBrown <neilb(a)suse.com> > Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com> > --- > fs/nfs/dir.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > This version applies to 3.18.y 4.4.y and 4.9.y Thanks for the backport, now applied. greg k-h

7 years

1
0
0 0

Re: [Linux-stable-mirror] FAILED: patch "[PATCH] md: forbid a RAID5 from having both a bitmap and a journal." failed to apply to 4.14-stable tree

by Greg KH

On Wed, Nov 29, 2017 at 01:00:25PM +1100, NeilBrown wrote: > > Subject: [PATCH] md: forbid a RAID5 from having both a bitmap and a journal. > > commit 230b55fa8d64007339319539f8f8e68114d08529 upstream. > > Having both a bitmap and a journal is pointless. > Attempting to do so can corrupt the bitmap if the journal > replay happens before the bitmap is initialized. > Rather than try to avoid this corruption, simply > refuse to allow arrays with both a bitmap and a journal. > So: > - if raid5_run sees both are present, fail. > - if adding a bitmap finds a journal is present, fail > - if adding a journal finds a bitmap is present, fail. > > Cc: stable(a)vger.kernel.org (4.10+) > Signed-off-by: NeilBrown <neilb(a)suse.com> > Tested-by: Joshua Kinard <kumba(a)gentoo.org> > Acked-by: Joshua Kinard <kumba(a)gentoo.org> > Signed-off-by: Shaohua Li <shli(a)fb.com> > --- > drivers/md/bitmap.c | 6 ++++++ > drivers/md/md.c | 2 +- > drivers/md/raid5.c | 7 +++++++ > 3 files changed, 14 insertions(+), 1 deletion(-) > > This commit only had problems due to a filename change. Oops, I should have caught that one, sorry about that. Thanks for the patch. greg k-h

7 years

1
0
0 0

Re: [Linux-stable-mirror] Patch "e1000e: fix buffer overrun while the I219 is processing DMA transactions" has been added to the 4.14-stable tree

by Greg KH

On Tue, Nov 28, 2017 at 11:23:23AM -0800, Jeff Kirsher wrote: > On Tue, 2017-11-28 at 11:18 +0100, Greg KH wrote: > > On Tue, Nov 28, 2017 at 11:56:41AM +0200, Neftin, Sasha wrote: > > > On 28/11/2017 11:27, gregkh(a)linuxfoundation.org wrote: > > > > This is a note to let you know that I've just added the patch titled > > > > > > > > e1000e: fix buffer overrun while the I219 is processing DMA > > > > transactions > > > > > > > > to the 4.14-stable tree which can be found at: > > > > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queu > > > > e.git;a=summary > > > > > > > > The filename of the patch is: > > > > e1000e-fix-buffer-overrun-while-the-i219-is-processing-dma- > > > > transactions.patch > > > > and it can be found in the queue-4.14 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 b10effb92e272051dd1ec0d7be56bf9ca85ab927 Mon Sep 17 00:00:00 > > > > 2001 > > > > From: Sasha Neftin <sasha.neftin(a)intel.com> > > > > Date: Sun, 6 Aug 2017 16:49:18 +0300 > > > > Subject: e1000e: fix buffer overrun while the I219 is processing DMA > > > > transactions > > > > MIME-Version: 1.0 > > > > Content-Type: text/plain; charset=UTF-8 > > > > Content-Transfer-Encoding: 8bit > > > > > > > > From: Sasha Neftin <sasha.neftin(a)intel.com> > > > > > > > > commit b10effb92e272051dd1ec0d7be56bf9ca85ab927 upstream. > > > > > > > > Intel® 100/200 Series Chipset platforms reduced the round-trip > > > > latency for the LAN Controller DMA accesses, causing in some high > > > > performance cases a buffer overrun while the I219 LAN Connected > > > > Device is processing the DMA transactions. I219LM and I219V devices > > > > can fall into unrecovered Tx hang under very stressfully UDP traffic > > > > and multiple reconnection of Ethernet cable. This Tx hang of the LAN > > > > Controller is only recovered if the system is rebooted. Slightly slow > > > > down DMA access by reducing the number of outstanding requests. > > > > This workaround could have an impact on TCP traffic performance > > > > on the platform. Disabling TSO eliminates performance loss for TCP > > > > traffic without a noticeable impact on CPU performance. > > > > > > > > Please, refer to I218/I219 specification update: > > > > https://www.intel.com/content/www/us/en/embedded/products/networking/ > > > > ethernet-connection-i218-family-documentation.html > > > > > > > > Signed-off-by: Sasha Neftin <sasha.neftin(a)intel.com> > > > > Reviewed-by: Dima Ruinskiy <dima.ruinskiy(a)intel.com> > > > > Reviewed-by: Raanan Avargil <raanan.avargil(a)intel.com> > > > > Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> > > > > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> > > > > Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> > > > > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > > > > > > > > --- > > > > drivers/net/ethernet/intel/e1000e/netdev.c | 8 +++++--- > > > > 1 file changed, 5 insertions(+), 3 deletions(-) > > > > > > > > --- a/drivers/net/ethernet/intel/e1000e/netdev.c > > > > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c > > > > @@ -3021,8 +3021,8 @@ static void e1000_configure_tx(struct e1 > > > > hw->mac.ops.config_collision_dist(hw); > > > > - /* SPT and CNP Si errata workaround to avoid data corruption > > > > */ > > > > - if (hw->mac.type >= e1000_pch_spt) { > > > > + /* SPT and KBL Si errata workaround to avoid data corruption > > > > */ > > > > + if (hw->mac.type == e1000_pch_spt) { > > > > u32 reg_val; > > > > reg_val = er32(IOSFPC); > > > > @@ -3030,7 +3030,9 @@ static void e1000_configure_tx(struct e1 > > > > ew32(IOSFPC, reg_val); > > > > reg_val = er32(TARC(0)); > > > > - reg_val |= E1000_TARC0_CB_MULTIQ_3_REQ; > > > > + /* SPT and KBL Si errata workaround to avoid Tx hang > > > > */ > > > > + reg_val &= ~BIT(28); > > > > + reg_val |= BIT(29); > > > > ew32(TARC(0), reg_val); > > > > } > > > > } > > > > > > > > > > > > Patches currently in stable-queue which might be from sasha.neftin@in > > > > tel.com are > > > > > > > > queue-4.14/e1000e-fix-buffer-overrun-while-the-i219-is-processing- > > > > dma-transactions.patch > > > > > > This is good. To follow of this one we have sent (Jeff sent today) > > > another > > > one, same functionality but more fundamental and clear patch, please, > > > refer > > > to https://patchwork.ozlabs.org/patch/834472/. I believe you can take > > > it too > > > for stable build . > > > > What is the git commit id of the patch in Linus's tree? > > > > You all do know how to properly tag patches to be included automatically > > in stable releases, right? If so, how come no one does this for this > > driver? > > Sorry Greg, I did not realize the above commit was queued up for stable, > which is why the follow on commit that Sasha was referring to was not CC'd > to stable mailing list. I do and will usual add the stable mailing list > to commits that need to be queued up for the stable trees. > > Anyways, here is the commit id for the follow on patch for the changes > above. David Miller just accepted it into his net tree this morning, here > is the commit id info: > > commit c0f4b163a03e73055dd734eaca64b9580e72e7fb > Author: Sasha Neftin <sasha.neftin(a)intel.com> > Date: Mon Nov 6 08:31:59 2017 +0200 > > e1000e: fix the use of magic numbers for buffer overrun issue > > This is a follow on to commit b10effb92e27 ("fix buffer overrun while > the > I219 is processing DMA transactions") to address David Laights > concerns > about the use of "magic" numbers. So define masks as well as add > additional code comments to give a better understanding of what needs > to > be done to avoid a buffer overrun. > > Signed-off-by: Sasha Neftin <sasha.neftin(a)intel.com> > Reviewed-by: Alexander H Duyck <alexander.h.duyck(a)intel.com> > Reviewed-by: Dima Ruinskiy <dima.ruinskiy(a)intel.com> > Reviewed-by: Raanan Avargil <raanan.avargil(a)intel.com> > Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Now added to the 4.14-stable tree, thanks. greg k-h

7 years

1
0
0 0

[Linux-stable-mirror] [PATCH] mtd: nand: Fix writing mtdoops to nand flash

by motobud＠gmail.com

From: Brent Taylor <motobud(a)gmail.com> Gregg, I apologize for the 4.4.y patch, I screwed up the branching in my local tree and tried to submit one patch that would cover versions 4.4.y and 3.18.y. Here is a valid 4.4.y patch. -- Brent commit 30863e38ebeb500a31cecee8096fb5002677dd9b upstream. When mtdoops calls mtd_panic_write(), it eventually calls panic_nand_write() in nand_base.c. In order to properly wait for the nand chip to be ready in panic_nand_wait(), the chip must first be selected. When using the atmel nand flash controller, a panic would occur due to a NULL pointer exception. Fixes: 2af7c6539931 ("mtd: Add panic_write for NAND flashes") Cc: <stable(a)vger.kernel.org> # 4.4.x Signed-off-by: Brent Taylor <motobud(a)gmail.com> --- drivers/mtd/nand/nand_base.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 54ab48827258..7ba109e8cf88 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -2663,15 +2663,18 @@ static int panic_nand_write(struct mtd_info *mtd, loff_t to, size_t len, size_t *retlen, const uint8_t *buf) { struct nand_chip *chip = mtd->priv; + int chipnr = (int)(to >> chip->chip_shift); struct mtd_oob_ops ops; int ret; - /* Wait for the device to get ready */ - panic_nand_wait(mtd, chip, 400); - /* Grab the device */ panic_nand_get_device(chip, mtd, FL_WRITING); + chip->select_chip(mtd, chipnr); + + /* Wait for the device to get ready */ + panic_nand_wait(mtd, chip, 400); + memset(&ops, 0, sizeof(ops)); ops.len = len; ops.datbuf = (uint8_t *)buf; -- 2.15.0

7 years

2
1
0 0

[Linux-stable-mirror] Fixing CVE-2017-16939 in v4.4.y and possibly v3.18.y

by Guenter Roeck

Hi, The fix for CVE-2017-16939 has been applied to v4.9.y, but not to v4.4.y and older kernels. However, I confirmed that running the published POC (see https://blogs.securiteam.com/index.php/archives/3535) does crash a 4.4 kernel. I confirmed that the following two patches fix the problem in v4.4.y. Please consider applying them to v4.4.y (and possibly v3.18.y). fc9e50f5a5a4e ("netlink: add a start callback for starting a netlink dump") 1137b5e2529a8 ("ipsec: Fix aborted xfrm policy dump crash") My apologies for the noise if this is already under consideration. Thanks, Guenter

7 years

3
5
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2017