This is a note to let you know that I've just added the patch titled
macvlan: Only deliver one copy of the frame to the macvlan interface
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:
macvlan-only-deliver-one-copy-of-the-frame-to-the-macvlan-interface.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 …
[View More]tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Alexander Duyck <alexander.h.duyck(a)intel.com>
Date: Fri, 13 Oct 2017 13:40:24 -0700
Subject: macvlan: Only deliver one copy of the frame to the macvlan interface
From: Alexander Duyck <alexander.h.duyck(a)intel.com>
[ Upstream commit dd6b9c2c332b40f142740d1b11fb77c653ff98ea ]
This patch intoduces a slight adjustment for macvlan to address the fact
that in source mode I was seeing two copies of any packet addressed to the
macvlan interface being delivered where there should have been only one.
The issue appears to be that one copy was delivered based on the source MAC
address and then the second copy was being delivered based on the
destination MAC address. To fix it I am just treating a unicast address
match as though it is not a match since source based macvlan isn't supposed
to be matching based on the destination MAC anyway.
Fixes: 79cf79abce71 ("macvlan: add source mode")
Signed-off-by: Alexander Duyck <alexander.h.duyck(a)intel.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/macvlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -441,7 +441,7 @@ static rx_handler_result_t macvlan_handl
struct macvlan_dev, list);
else
vlan = macvlan_hash_lookup(port, eth->h_dest);
- if (vlan == NULL)
+ if (!vlan || vlan->mode == MACVLAN_MODE_SOURCE)
return RX_HANDLER_PASS;
dev = vlan->dev;
Patches currently in stable-queue which might be from alexander.h.duyck(a)intel.com are
queue-4.4/macvlan-only-deliver-one-copy-of-the-frame-to-the-macvlan-interface.patch
[View Less]
This is a note to let you know that I've just added the patch titled
l2tp: cleanup l2tp_tunnel_delete calls
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:
l2tp-cleanup-l2tp_tunnel_delete-calls.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 …
[View More]about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Jiri Slaby <jslaby(a)suse.cz>
Date: Wed, 25 Oct 2017 15:57:55 +0200
Subject: l2tp: cleanup l2tp_tunnel_delete calls
From: Jiri Slaby <jslaby(a)suse.cz>
[ Upstream commit 4dc12ffeaeac939097a3f55c881d3dc3523dff0c ]
l2tp_tunnel_delete does not return anything since commit 62b982eeb458
("l2tp: fix race condition in l2tp_tunnel_delete"). But call sites of
l2tp_tunnel_delete still do casts to void to avoid unused return value
warnings.
Kill these now useless casts.
Signed-off-by: Jiri Slaby <jslaby(a)suse.cz>
Cc: Sabrina Dubroca <sd(a)queasysnail.net>
Cc: Guillaume Nault <g.nault(a)alphalink.fr>
Cc: David S. Miller <davem(a)davemloft.net>
Cc: netdev(a)vger.kernel.org
Acked-by: Guillaume Nault <g.nault(a)alphalink.fr>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/l2tp/l2tp_core.c | 2 +-
net/l2tp/l2tp_netlink.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1856,7 +1856,7 @@ static __net_exit void l2tp_exit_net(str
rcu_read_lock_bh();
list_for_each_entry_rcu(tunnel, &pn->l2tp_tunnel_list, list) {
- (void)l2tp_tunnel_delete(tunnel);
+ l2tp_tunnel_delete(tunnel);
}
rcu_read_unlock_bh();
}
--- a/net/l2tp/l2tp_netlink.c
+++ b/net/l2tp/l2tp_netlink.c
@@ -285,7 +285,7 @@ static int l2tp_nl_cmd_tunnel_delete(str
l2tp_tunnel_notify(&l2tp_nl_family, info,
tunnel, L2TP_CMD_TUNNEL_DELETE);
- (void) l2tp_tunnel_delete(tunnel);
+ l2tp_tunnel_delete(tunnel);
out:
return ret;
Patches currently in stable-queue which might be from jslaby(a)suse.cz are
queue-4.4/l2tp-cleanup-l2tp_tunnel_delete-calls.patch
[View Less]
This is a note to let you know that I've just added the patch titled
iscsi-target: fix memory leak in lio_target_tiqn_addtpg()
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:
iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.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 <…
[View More]stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: tangwenji <tang.wenji(a)zte.com.cn>
Date: Fri, 15 Sep 2017 16:03:13 +0800
Subject: iscsi-target: fix memory leak in lio_target_tiqn_addtpg()
From: tangwenji <tang.wenji(a)zte.com.cn>
[ Upstream commit 12d5a43b2dffb6cd28062b4e19024f7982393288 ]
tpg must free when call core_tpg_register() return fail
Signed-off-by: tangwenji <tang.wenji(a)zte.com.cn>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/iscsi/iscsi_target_configfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/target/iscsi/iscsi_target_configfs.c
+++ b/drivers/target/iscsi/iscsi_target_configfs.c
@@ -1210,7 +1210,7 @@ static struct se_portal_group *lio_targe
ret = core_tpg_register(wwn, &tpg->tpg_se_tpg, SCSI_PROTOCOL_ISCSI);
if (ret < 0)
- return NULL;
+ goto free_out;
ret = iscsit_tpg_add_portal_group(tiqn, tpg);
if (ret != 0)
@@ -1222,6 +1222,7 @@ static struct se_portal_group *lio_targe
return &tpg->tpg_se_tpg;
out:
core_tpg_deregister(&tpg->tpg_se_tpg);
+free_out:
kfree(tpg);
return NULL;
}
Patches currently in stable-queue which might be from tang.wenji(a)zte.com.cn are
queue-4.4/target-fix-condition-return-in-core_pr_dump_initiator_port.patch
queue-4.4/iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch
[View Less]
This is a note to let you know that I've just added the patch titled
intel_th: pci: Add Gemini Lake support
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:
intel_th-pci-add-gemini-lake-support.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 …
[View More]it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Date: Thu, 30 Jun 2016 16:10:51 +0300
Subject: intel_th: pci: Add Gemini Lake support
From: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
[ Upstream commit 340837f985c2cb87ca0868d4aa9ce42b0fab3a21 ]
This adds Intel(R) Trace Hub PCI ID for Gemini Lake SOC.
Signed-off-by: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hwtracing/intel_th/pci.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/hwtracing/intel_th/pci.c
+++ b/drivers/hwtracing/intel_th/pci.c
@@ -82,6 +82,11 @@ static const struct pci_device_id intel_
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x9da6),
.driver_data = (kernel_ulong_t)0,
},
+ {
+ /* Gemini Lake */
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x318e),
+ .driver_data = (kernel_ulong_t)0,
+ },
{ 0 },
};
Patches currently in stable-queue which might be from alexander.shishkin(a)linux.intel.com are
queue-4.4/intel_th-pci-add-gemini-lake-support.patch
[View Less]
This is a note to let you know that I've just added the patch titled
Input: i8042 - add TUXEDO BU1406 (N24_25BU) to the nomux list
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:
input-i8042-add-tuxedo-bu1406-n24_25bu-to-the-nomux-list.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 …
[View More]<stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Date: Tue, 28 Feb 2017 17:14:41 -0800
Subject: Input: i8042 - add TUXEDO BU1406 (N24_25BU) to the nomux list
From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
[ Upstream commit a4c2a13129f7c5bcf81704c06851601593303fd5 ]
TUXEDO BU1406 does not implement active multiplexing mode properly,
and takes around 550 ms in i8042_set_mux_mode(). Given that the
device does not have external AUX port, there is no downside in
disabling the MUX mode.
Reported-by: Paul Menzel <pmenzel(a)molgen.mpg.de>
Suggested-by: Vojtech Pavlik <vojtech(a)suse.cz>
Reviewed-by: Marcos Paulo de Souza <marcos.souza.org(a)gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/input/serio/i8042-x86ia64io.h | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -520,6 +520,13 @@ static const struct dmi_system_id __init
DMI_MATCH(DMI_PRODUCT_NAME, "IC4I"),
},
},
+ {
+ /* TUXEDO BU1406 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "N24_25BU"),
+ },
+ },
{ }
};
Patches currently in stable-queue which might be from dmitry.torokhov(a)gmail.com are
queue-4.4/input-i8042-add-tuxedo-bu1406-n24_25bu-to-the-nomux-list.patch
[View Less]
This is a note to let you know that I've just added the patch titled
IB/ipoib: Grab rtnl lock on heavy flush when calling ndo_open/stop
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:
ib-ipoib-grab-rtnl-lock-on-heavy-flush-when-calling-ndo_open-stop.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 …
[View More]tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Alex Vesker <valex(a)mellanox.com>
Date: Tue, 10 Oct 2017 10:36:41 +0300
Subject: IB/ipoib: Grab rtnl lock on heavy flush when calling ndo_open/stop
From: Alex Vesker <valex(a)mellanox.com>
[ Upstream commit b4b678b06f6eef18bff44a338c01870234db0bc9 ]
When ndo_open and ndo_stop are called RTNL lock should be held.
In this specific case ipoib_ib_dev_open calls the offloaded ndo_open
which re-sets the number of TX queue assuming RTNL lock is held.
Since RTNL lock is not held, RTNL assert will fail.
Signed-off-by: Alex Vesker <valex(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/ulp/ipoib/ipoib_ib.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
@@ -1044,10 +1044,15 @@ static void __ipoib_ib_dev_flush(struct
ipoib_ib_dev_down(dev);
if (level == IPOIB_FLUSH_HEAVY) {
+ rtnl_lock();
if (test_bit(IPOIB_FLAG_INITIALIZED, &priv->flags))
ipoib_ib_dev_stop(dev);
- if (ipoib_ib_dev_open(dev) != 0)
+
+ result = ipoib_ib_dev_open(dev);
+ rtnl_unlock();
+ if (result)
return;
+
if (netif_queue_stopped(dev))
netif_start_queue(dev);
}
Patches currently in stable-queue which might be from valex(a)mellanox.com are
queue-4.4/ib-ipoib-grab-rtnl-lock-on-heavy-flush-when-calling-ndo_open-stop.patch
[View Less]
This is a note to let you know that I've just added the patch titled
GFS2: Take inode off order_write list when setting jdata flag
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:
gfs2-take-inode-off-order_write-list-when-setting-jdata-flag.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 …
[View More]let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Bob Peterson <rpeterso(a)redhat.com>
Date: Wed, 20 Sep 2017 08:30:04 -0500
Subject: GFS2: Take inode off order_write list when setting jdata flag
From: Bob Peterson <rpeterso(a)redhat.com>
[ Upstream commit cc555b09d8c3817aeebda43a14ab67049a5653f7 ]
This patch fixes a deadlock caused when the jdata flag is set for
inodes that are already on the ordered write list. Since it is
on the ordered write list, log_flush calls gfs2_ordered_write which
calls filemap_fdatawrite. But since the inode had the jdata flag
set, that calls gfs2_jdata_writepages, which tries to start a new
transaction. A new transaction cannot be started because it tries
to acquire the log_flush rwsem which is already locked by the log
flush operation.
The bottom line is: We cannot switch an inode from ordered to jdata
until we eliminate any ordered data pages (via log flush) or any
log_flush operation afterward will create the circular dependency
above. So we need to flush the log before setting the diskflags to
switch the file mode, then we need to remove the inode from the
ordered writes list.
Before this patch, the log flush was done for jdata->ordered, but
that's wrong. If we're going from jdata to ordered, we don't need
to call gfs2_log_flush because the call to filemap_fdatawrite will
do it for us:
filemap_fdatawrite() -> __filemap_fdatawrite_range()
__filemap_fdatawrite_range() -> do_writepages()
do_writepages() -> gfs2_jdata_writepages()
gfs2_jdata_writepages() -> gfs2_log_flush()
This patch modifies function do_gfs2_set_flags so that if a file
has its jdata flag set, and it's already on the ordered write list,
the log will be flushed and it will be removed from the list
before setting the flag.
Signed-off-by: Bob Peterson <rpeterso(a)redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com>
Acked-by: Abhijith Das <adas(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/gfs2/file.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/gfs2/file.c
+++ b/fs/gfs2/file.c
@@ -255,7 +255,7 @@ static int do_gfs2_set_flags(struct file
goto out;
}
if ((flags ^ new_flags) & GFS2_DIF_JDATA) {
- if (flags & GFS2_DIF_JDATA)
+ if (new_flags & GFS2_DIF_JDATA)
gfs2_log_flush(sdp, ip->i_gl, NORMAL_FLUSH);
error = filemap_fdatawrite(inode->i_mapping);
if (error)
@@ -263,6 +263,8 @@ static int do_gfs2_set_flags(struct file
error = filemap_fdatawait(inode->i_mapping);
if (error)
goto out;
+ if (new_flags & GFS2_DIF_JDATA)
+ gfs2_ordered_del_inode(ip);
}
error = gfs2_trans_begin(sdp, RES_DINODE, 0);
if (error)
Patches currently in stable-queue which might be from rpeterso(a)redhat.com are
queue-4.4/gfs2-take-inode-off-order_write-list-when-setting-jdata-flag.patch
[View Less]
This is a note to let you know that I've just added the patch titled
fjes: Fix wrong netdevice feature flags
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:
fjes-fix-wrong-netdevice-feature-flags.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 …
[View More]about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Taku Izumi <izumi.taku(a)jp.fujitsu.com>
Date: Wed, 15 Mar 2017 13:47:50 +0900
Subject: fjes: Fix wrong netdevice feature flags
From: Taku Izumi <izumi.taku(a)jp.fujitsu.com>
[ Upstream commit fe8daf5fa715f7214952f06a387e4b7de818c5be ]
This patch fixes netdev->features for Extended Socket network device.
Currently Extended Socket network device's netdev->feature claims
NETIF_F_HW_CSUM, however this is completely wrong. There's no feature
of checksum offloading.
That causes invalid TCP/UDP checksum and packet rejection when IP
forwarding from Extended Socket network device to other network device.
NETIF_F_HW_CSUM should be omitted.
Signed-off-by: Taku Izumi <izumi.taku(a)jp.fujitsu.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/fjes/fjes_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/fjes/fjes_main.c
+++ b/drivers/net/fjes/fjes_main.c
@@ -1205,7 +1205,7 @@ static void fjes_netdev_setup(struct net
fjes_set_ethtool_ops(netdev);
netdev->mtu = fjes_support_mtu[0];
netdev->flags |= IFF_BROADCAST;
- netdev->features |= NETIF_F_HW_CSUM | NETIF_F_HW_VLAN_CTAG_FILTER;
+ netdev->features |= NETIF_F_HW_VLAN_CTAG_FILTER;
}
static void fjes_irq_watch_task(struct work_struct *work)
Patches currently in stable-queue which might be from izumi.taku(a)jp.fujitsu.com are
queue-4.4/fjes-fix-wrong-netdevice-feature-flags.patch
[View Less]
This is a note to let you know that I've just added the patch titled
fbdev: controlfb: Add missing modes to fix out of bounds access
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:
fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.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,
…
[View More]please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
Date: Thu, 9 Nov 2017 18:09:33 +0100
Subject: fbdev: controlfb: Add missing modes to fix out of bounds access
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
[ Upstream commit ac831a379d34109451b3c41a44a20ee10ecb615f ]
Dan's static analysis says:
drivers/video/fbdev/controlfb.c:560 control_setup()
error: buffer overflow 'control_mac_modes' 20 <= 21
Indeed, control_mac_modes[] has only 20 elements, while VMODE_MAX is 22,
which may lead to an out of bounds read when parsing vmode commandline
options.
The bug was introduced in v2.4.5.6, when 2 new modes were added to
macmodes.h, but control_mac_modes[] wasn't updated:
https://kernel.opensuse.org/cgit/kernel/diff/include/video/macmodes.h?h=v2.…
Augment control_mac_modes[] with the two new video modes to fix this.
Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org>
Cc: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/fbdev/controlfb.h | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/video/fbdev/controlfb.h
+++ b/drivers/video/fbdev/controlfb.h
@@ -141,5 +141,7 @@ static struct max_cmodes control_mac_mod
{{ 1, 2}}, /* 1152x870, 75Hz */
{{ 0, 1}}, /* 1280x960, 75Hz */
{{ 0, 1}}, /* 1280x1024, 75Hz */
+ {{ 1, 2}}, /* 1152x768, 60Hz */
+ {{ 0, 1}}, /* 1600x1024, 60Hz */
};
Patches currently in stable-queue which might be from geert(a)linux-m68k.org are
queue-4.4/fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.patch
[View Less]
This is a note to let you know that I've just added the patch titled
efi/esrt: Cleanup bad memory map log messages
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:
efi-esrt-cleanup-bad-memory-map-log-messages.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…
[View More]> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Daniel Drake <drake(a)endlessm.com>
Date: Tue, 7 Feb 2017 13:08:23 -0600
Subject: efi/esrt: Cleanup bad memory map log messages
From: Daniel Drake <drake(a)endlessm.com>
[ Upstream commit 822f5845f710e57d7e2df1fd1ee00d6e19d334fe ]
The Intel Compute Stick STCK1A8LFC and Weibu F3C platforms both
log 2 error messages during boot:
efi: requested map not found.
esrt: ESRT header is not in the memory map.
Searching the web, this seems to affect many other platforms too.
Since these messages are logged as errors, they appear on-screen during
the boot process even when using the "quiet" boot parameter used by
distros.
Demote the ESRT error to a warning so that it does not appear on-screen,
and delete the error logging from efi_mem_desc_lookup; both callsites
of that function log more specific messages upon failure.
Out of curiosity I looked closer at the Weibu F3C. There is no entry in
the UEFI-provided memory map which corresponds to the ESRT pointer, but
hacking the code to map it anyway, the ESRT does appear to be valid with
2 entries.
Signed-off-by: Daniel Drake <drake(a)endlessm.com>
Cc: Matt Fleming <matt(a)codeblueprint.co.uk>
Acked-by: Peter Jones <pjones(a)redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/firmware/efi/efi.c | 1 -
drivers/firmware/efi/esrt.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -310,7 +310,6 @@ int __init efi_mem_desc_lookup(u64 phys_
early_memunmap(md, sizeof (*md));
}
- pr_err_once("requested map not found.\n");
return -ENOENT;
}
--- a/drivers/firmware/efi/esrt.c
+++ b/drivers/firmware/efi/esrt.c
@@ -253,7 +253,7 @@ void __init efi_esrt_init(void)
rc = efi_mem_desc_lookup(efi.esrt, &md);
if (rc < 0) {
- pr_err("ESRT header is not in the memory map.\n");
+ pr_warn("ESRT header is not in the memory map.\n");
return;
}
Patches currently in stable-queue which might be from drake(a)endlessm.com are
queue-4.4/efi-esrt-cleanup-bad-memory-map-log-messages.patch
[View Less]