This is a note to let you know that I've just added the patch titled
libata: Apply NOLPM quirk to Crucial MX100 512GB SSDs
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:
libata-apply-nolpm-quirk-to-crucial-mx100-512gb-ssds.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 9c7be59fc519af9081c46c48f06f2b8fadf55ad8 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Fri, 16 Feb 2018 10:48:20 +0100
Subject: libata: Apply NOLPM quirk to Crucial MX100 512GB SSDs
From: Hans de Goede <hdegoede(a)redhat.com>
commit 9c7be59fc519af9081c46c48f06f2b8fadf55ad8 upstream.
Various people have reported the Crucial MX100 512GB model not working
with LPM set to min_power. I've now received a report that it also does
not work with the new med_power_with_dipm level.
It does work with medium_power, but that has no measurable power-savings
and given the amount of people being bitten by the other levels not
working, this commit just disables LPM altogether.
Note all reporters of this have either the 512GB model (max capacity), or
are not specifying their SSD's size. So for now this quirk assumes this is
a problem with the 512GB model only.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=89261
Buglink: https://github.com/linrunner/TLP/issues/84
Cc: stable(a)vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/libata-core.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4520,6 +4520,11 @@ static const struct ata_blacklist_entry
{ "PIONEER DVD-RW DVR-212D", NULL, ATA_HORKAGE_NOSETXFER },
{ "PIONEER DVD-RW DVR-216D", NULL, ATA_HORKAGE_NOSETXFER },
+ /* The 512GB version of the MX100 has both queued TRIM and LPM issues */
+ { "Crucial_CT512MX100*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
+ ATA_HORKAGE_ZERO_AFTER_TRIM |
+ ATA_HORKAGE_NOLPM, },
+
/* devices that don't properly handle queued TRIM commands */
{ "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.14/libata-apply-nolpm-quirk-to-crucial-m500-480-and-960gb-ssds.patch
queue-4.14/libata-apply-nolpm-quirk-to-crucial-mx100-512gb-ssds.patch
queue-4.14/pci-add-function-1-dma-alias-quirk-for-highpoint-rocketraid-644l.patch
queue-4.14/libata-modify-quirks-for-mx100-to-limit-ncq_trim-quirk-to-mu01-version.patch
queue-4.14/ahci-add-pci-id-for-the-highpoint-rocketraid-644l-card.patch
queue-4.14/libata-make-crucial-bx100-500gb-lpm-quirk-apply-to-all-firmware-versions.patch
queue-4.14/bluetooth-btusb-add-dell-optiplex-3060-to-btusb_needs_reset_resume_table.patch
queue-4.14/bluetooth-btusb-remove-yoga-920-from-the-btusb_needs_reset_resume_table.patch
This is a note to let you know that I've just added the patch titled
libata: Apply NOLPM quirk to Crucial M500 480 and 960GB SSDs
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:
libata-apply-nolpm-quirk-to-crucial-m500-480-and-960gb-ssds.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 62ac3f7305470e3f52f159de448bc1a771717e88 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Mon, 19 Mar 2018 16:33:58 +0100
Subject: libata: Apply NOLPM quirk to Crucial M500 480 and 960GB SSDs
From: Hans de Goede <hdegoede(a)redhat.com>
commit 62ac3f7305470e3f52f159de448bc1a771717e88 upstream.
There have been reports of the Crucial M500 480GB model not working
with LPM set to min_power / med_power_with_dipm level.
It has not been tested with medium_power, but that typically has no
measurable power-savings.
Note the reporters Crucial_CT480M500SSD3 has a firmware version of MU03
and there is a MU05 update available, but that update does not mention any
LPM fixes in its changelog, so the quirk matches all firmware versions.
In my experience the LPM problems with (older) Crucial SSDs seem to be
limited to higher capacity versions of the SSDs (different firmware?),
so this commit adds a NOLPM quirk for the 480 and 960GB versions of the
M500, to avoid LPM causing issues with these SSDs.
Cc: stable(a)vger.kernel.org
Reported-and-tested-by: Martin Steigerwald <martin(a)lichtvoll.de>
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/libata-core.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4528,6 +4528,14 @@ static const struct ata_blacklist_entry
ATA_HORKAGE_ZERO_AFTER_TRIM |
ATA_HORKAGE_NOLPM, },
+ /* 480GB+ M500 SSDs have both queued TRIM and LPM issues */
+ { "Crucial_CT480M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
+ ATA_HORKAGE_ZERO_AFTER_TRIM |
+ ATA_HORKAGE_NOLPM, },
+ { "Crucial_CT960M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
+ ATA_HORKAGE_ZERO_AFTER_TRIM |
+ ATA_HORKAGE_NOLPM, },
+
/* devices that don't properly handle queued TRIM commands */
{ "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.14/libata-apply-nolpm-quirk-to-crucial-m500-480-and-960gb-ssds.patch
queue-4.14/libata-apply-nolpm-quirk-to-crucial-mx100-512gb-ssds.patch
queue-4.14/pci-add-function-1-dma-alias-quirk-for-highpoint-rocketraid-644l.patch
queue-4.14/libata-modify-quirks-for-mx100-to-limit-ncq_trim-quirk-to-mu01-version.patch
queue-4.14/ahci-add-pci-id-for-the-highpoint-rocketraid-644l-card.patch
queue-4.14/libata-make-crucial-bx100-500gb-lpm-quirk-apply-to-all-firmware-versions.patch
queue-4.14/bluetooth-btusb-add-dell-optiplex-3060-to-btusb_needs_reset_resume_table.patch
queue-4.14/bluetooth-btusb-remove-yoga-920-from-the-btusb_needs_reset_resume_table.patch
This is a note to let you know that I've just added the patch titled
cgroup: fix rule checking for threaded mode switching
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:
cgroup-fix-rule-checking-for-threaded-mode-switching.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 d1897c9538edafd4ae6bbd03cc075962ddde2c21 Mon Sep 17 00:00:00 2001
From: Tejun Heo <tj(a)kernel.org>
Date: Wed, 21 Feb 2018 11:39:22 -0800
Subject: cgroup: fix rule checking for threaded mode switching
From: Tejun Heo <tj(a)kernel.org>
commit d1897c9538edafd4ae6bbd03cc075962ddde2c21 upstream.
A domain cgroup isn't allowed to be turned threaded if its subtree is
populated or domain controllers are enabled. cgroup_enable_threaded()
depended on cgroup_can_be_thread_root() test to enforce this rule. A
parent which has populated domain descendants or have domain
controllers enabled can't become a thread root, so the above rules are
enforced automatically.
However, for the root cgroup which can host mixed domain and threaded
children, cgroup_can_be_thread_root() doesn't check any of those
conditions and thus first level cgroups ends up escaping those rules.
This patch fixes the bug by adding explicit checks for those rules in
cgroup_enable_threaded().
Reported-by: Michael Kerrisk (man-pages) <mtk.manpages(a)gmail.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Fixes: 8cfd8147df67 ("cgroup: implement cgroup v2 thread support")
Cc: stable(a)vger.kernel.org # v4.14+
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/cgroup/cgroup.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -3148,6 +3148,16 @@ static int cgroup_enable_threaded(struct
if (cgroup_is_threaded(cgrp))
return 0;
+ /*
+ * If @cgroup is populated or has domain controllers enabled, it
+ * can't be switched. While the below cgroup_can_be_thread_root()
+ * test can catch the same conditions, that's only when @parent is
+ * not mixable, so let's check it explicitly.
+ */
+ if (cgroup_is_populated(cgrp) ||
+ cgrp->subtree_control & ~cgrp_dfl_threaded_ss_mask)
+ return -EOPNOTSUPP;
+
/* we're joining the parent's domain, ensure its validity */
if (!cgroup_is_valid_domain(dom_cgrp) ||
!cgroup_can_be_thread_root(dom_cgrp))
Patches currently in stable-queue which might be from tj(a)kernel.org are
queue-4.14/libata-disable-lpm-for-crucial-bx100-ssd-500gb-drive.patch
queue-4.14/libata-apply-nolpm-quirk-to-crucial-m500-480-and-960gb-ssds.patch
queue-4.14/libata-fix-length-validation-of-atapi-relayed-scsi-commands.patch
queue-4.14/libata-apply-nolpm-quirk-to-crucial-mx100-512gb-ssds.patch
queue-4.14/pci-add-function-1-dma-alias-quirk-for-highpoint-rocketraid-644l.patch
queue-4.14/libata-modify-quirks-for-mx100-to-limit-ncq_trim-quirk-to-mu01-version.patch
queue-4.14/libata-enable-queued-trim-for-samsung-ssd-860.patch
queue-4.14/ahci-add-pci-id-for-the-highpoint-rocketraid-644l-card.patch
queue-4.14/cgroup-fix-rule-checking-for-threaded-mode-switching.patch
queue-4.14/libata-make-crucial-bx100-500gb-lpm-quirk-apply-to-all-firmware-versions.patch
queue-4.14/libata-remove-warn-for-dma-or-pio-command-without-data.patch
queue-4.14/libata-don-t-try-to-pass-through-ncq-commands-to-non-ncq-devices.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: btusb: Remove Yoga 920 from the btusb_needs_reset_resume_table
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:
bluetooth-btusb-remove-yoga-920-from-the-btusb_needs_reset_resume_table.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 f0e8c61110c2c85903b136ba070daf643a8b6842 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Wed, 28 Feb 2018 11:57:50 +0100
Subject: Bluetooth: btusb: Remove Yoga 920 from the btusb_needs_reset_resume_table
From: Hans de Goede <hdegoede(a)redhat.com>
commit f0e8c61110c2c85903b136ba070daf643a8b6842 upstream.
Commit 1fdb92697469 ("Bluetooth: btusb: Use DMI matching for QCA
reset_resume quirking"), added the Lenovo Yoga 920 to the
btusb_needs_reset_resume_table.
Testing has shown that this is a false positive and the problems where
caused by issues with the initial fix: commit fd865802c66b ("Bluetooth:
btusb: fix QCA Rome suspend/resume"), which has already been reverted.
So the QCA Rome BT in the Yoga 920 does not need a reset-resume quirk at
all and this commit removes it from the btusb_needs_reset_resume_table.
Note that after this commit the btusb_needs_reset_resume_table is now
empty. It is kept around on purpose, since this whole series of commits
started for a reason and there are actually broken platforms around,
which need to be added to it.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836
Fixes: 1fdb92697469 ("Bluetooth: btusb: Use DMI matching for QCA ...")
Cc: stable(a)vger.kernel.org
Cc: Brian Norris <briannorris(a)chromium.org>
Cc: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Tested-by: Kevin Fenzi <kevin(a)scrye.com>
Suggested-by: Brian Norris <briannorris(a)chromium.org>
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Reviewed-by: Brian Norris <briannorris(a)chromium.org>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/btusb.c | 7 -------
1 file changed, 7 deletions(-)
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -387,13 +387,6 @@ static const struct usb_device_id blackl
* the module itself. So we use a DMI list to match known broken platforms.
*/
static const struct dmi_system_id btusb_needs_reset_resume_table[] = {
- {
- /* Lenovo Yoga 920 (QCA Rome device 0cf3:e300) */
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
- DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo YOGA 920"),
- },
- },
{}
};
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.14/libata-apply-nolpm-quirk-to-crucial-m500-480-and-960gb-ssds.patch
queue-4.14/libata-apply-nolpm-quirk-to-crucial-mx100-512gb-ssds.patch
queue-4.14/pci-add-function-1-dma-alias-quirk-for-highpoint-rocketraid-644l.patch
queue-4.14/libata-modify-quirks-for-mx100-to-limit-ncq_trim-quirk-to-mu01-version.patch
queue-4.14/ahci-add-pci-id-for-the-highpoint-rocketraid-644l-card.patch
queue-4.14/libata-make-crucial-bx100-500gb-lpm-quirk-apply-to-all-firmware-versions.patch
queue-4.14/bluetooth-btusb-add-dell-optiplex-3060-to-btusb_needs_reset_resume_table.patch
queue-4.14/bluetooth-btusb-remove-yoga-920-from-the-btusb_needs_reset_resume_table.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: btusb: Add Dell OptiPlex 3060 to btusb_needs_reset_resume_table
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:
bluetooth-btusb-add-dell-optiplex-3060-to-btusb_needs_reset_resume_table.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 0c6e526646c04ce31d4aaa280ed2237dd1cd774c Mon Sep 17 00:00:00 2001
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Date: Thu, 1 Mar 2018 13:42:52 +0800
Subject: Bluetooth: btusb: Add Dell OptiPlex 3060 to btusb_needs_reset_resume_table
From: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
commit 0c6e526646c04ce31d4aaa280ed2237dd1cd774c upstream.
The issue can be reproduced before commit fd865802c66b ("Bluetooth:
btusb: fix QCA Rome suspend/resume") gets introduced, so the reset
resume quirk is still needed for this system.
T: Bus=01 Lev=01 Prnt=01 Port=13 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0cf3 ProdID=e007 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
Cc: stable(a)vger.kernel.org
Cc: Brian Norris <briannorris(a)chromium.org>
Cc: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/btusb.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -387,6 +387,13 @@ static const struct usb_device_id blackl
* the module itself. So we use a DMI list to match known broken platforms.
*/
static const struct dmi_system_id btusb_needs_reset_resume_table[] = {
+ {
+ /* Dell OptiPlex 3060 (QCA ROME device 0cf3:e007) */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 3060"),
+ },
+ },
{}
};
Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are
queue-4.14/libata-disable-lpm-for-crucial-bx100-ssd-500gb-drive.patch
queue-4.14/libata-make-crucial-bx100-500gb-lpm-quirk-apply-to-all-firmware-versions.patch
queue-4.14/bluetooth-btusb-add-dell-optiplex-3060-to-btusb_needs_reset_resume_table.patch
queue-4.14/bluetooth-btusb-remove-yoga-920-from-the-btusb_needs_reset_resume_table.patch
This is a note to let you know that I've just added the patch titled
nfsd: remove blocked locks on client teardown
to the 4.9-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:
nfsd-remove-blocked-locks-on-client-teardown.patch
and it can be found in the queue-4.9 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 68ef3bc3166468678d5e1fdd216628c35bd1186f Mon Sep 17 00:00:00 2001
From: Jeff Layton <jlayton(a)redhat.com>
Date: Fri, 16 Mar 2018 11:32:02 -0400
Subject: nfsd: remove blocked locks on client teardown
From: Jeff Layton <jlayton(a)redhat.com>
commit 68ef3bc3166468678d5e1fdd216628c35bd1186f upstream.
We had some reports of panics in nfsd4_lm_notify, and that showed a
nfs4_lockowner that had outlived its so_client.
Ensure that we walk any leftover lockowners after tearing down all of
the stateids, and remove any blocked locks that they hold.
With this change, we also don't need to walk the nbl_lru on nfsd_net
shutdown, as that will happen naturally when we tear down the clients.
Fixes: 76d348fadff5 (nfsd: have nfsd4_lock use blocking locks for v4.1+ locks)
Reported-by: Frank Sorenson <fsorenso(a)redhat.com>
Signed-off-by: Jeff Layton <jlayton(a)redhat.com>
Cc: stable(a)vger.kernel.org # 4.9
Signed-off-by: J. Bruce Fields <bfields(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfsd/nfs4state.c | 62 ++++++++++++++++++++++++++++++++++++----------------
1 file changed, 43 insertions(+), 19 deletions(-)
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -263,6 +263,35 @@ free_blocked_lock(struct nfsd4_blocked_l
kfree(nbl);
}
+static void
+remove_blocked_locks(struct nfs4_lockowner *lo)
+{
+ struct nfs4_client *clp = lo->lo_owner.so_client;
+ struct nfsd_net *nn = net_generic(clp->net, nfsd_net_id);
+ struct nfsd4_blocked_lock *nbl;
+ LIST_HEAD(reaplist);
+
+ /* Dequeue all blocked locks */
+ spin_lock(&nn->blocked_locks_lock);
+ while (!list_empty(&lo->lo_blocked)) {
+ nbl = list_first_entry(&lo->lo_blocked,
+ struct nfsd4_blocked_lock,
+ nbl_list);
+ list_del_init(&nbl->nbl_list);
+ list_move(&nbl->nbl_lru, &reaplist);
+ }
+ spin_unlock(&nn->blocked_locks_lock);
+
+ /* Now free them */
+ while (!list_empty(&reaplist)) {
+ nbl = list_first_entry(&reaplist, struct nfsd4_blocked_lock,
+ nbl_lru);
+ list_del_init(&nbl->nbl_lru);
+ posix_unblock_lock(&nbl->nbl_lock);
+ free_blocked_lock(nbl);
+ }
+}
+
static int
nfsd4_cb_notify_lock_done(struct nfsd4_callback *cb, struct rpc_task *task)
{
@@ -1854,6 +1883,7 @@ static __be32 mark_client_expired_locked
static void
__destroy_client(struct nfs4_client *clp)
{
+ int i;
struct nfs4_openowner *oo;
struct nfs4_delegation *dp;
struct list_head reaplist;
@@ -1883,6 +1913,16 @@ __destroy_client(struct nfs4_client *clp
nfs4_get_stateowner(&oo->oo_owner);
release_openowner(oo);
}
+ for (i = 0; i < OWNER_HASH_SIZE; i++) {
+ struct nfs4_stateowner *so, *tmp;
+
+ list_for_each_entry_safe(so, tmp, &clp->cl_ownerstr_hashtbl[i],
+ so_strhash) {
+ /* Should be no openowners at this point */
+ WARN_ON_ONCE(so->so_is_open_owner);
+ remove_blocked_locks(lockowner(so));
+ }
+ }
nfsd4_return_all_client_layouts(clp);
nfsd4_shutdown_callback(clp);
if (clp->cl_cb_conn.cb_xprt)
@@ -6266,6 +6306,7 @@ nfsd4_release_lockowner(struct svc_rqst
}
spin_unlock(&clp->cl_lock);
free_ol_stateid_reaplist(&reaplist);
+ remove_blocked_locks(lo);
nfs4_put_stateowner(&lo->lo_owner);
return status;
@@ -7051,6 +7092,8 @@ nfs4_state_destroy_net(struct net *net)
}
}
+ WARN_ON(!list_empty(&nn->blocked_locks_lru));
+
for (i = 0; i < CLIENT_HASH_SIZE; i++) {
while (!list_empty(&nn->unconf_id_hashtbl[i])) {
clp = list_entry(nn->unconf_id_hashtbl[i].next, struct nfs4_client, cl_idhash);
@@ -7117,7 +7160,6 @@ nfs4_state_shutdown_net(struct net *net)
struct nfs4_delegation *dp = NULL;
struct list_head *pos, *next, reaplist;
struct nfsd_net *nn = net_generic(net, nfsd_net_id);
- struct nfsd4_blocked_lock *nbl;
cancel_delayed_work_sync(&nn->laundromat_work);
locks_end_grace(&nn->nfsd4_manager);
@@ -7138,24 +7180,6 @@ nfs4_state_shutdown_net(struct net *net)
nfs4_put_stid(&dp->dl_stid);
}
- BUG_ON(!list_empty(&reaplist));
- spin_lock(&nn->blocked_locks_lock);
- while (!list_empty(&nn->blocked_locks_lru)) {
- nbl = list_first_entry(&nn->blocked_locks_lru,
- struct nfsd4_blocked_lock, nbl_lru);
- list_move(&nbl->nbl_lru, &reaplist);
- list_del_init(&nbl->nbl_list);
- }
- spin_unlock(&nn->blocked_locks_lock);
-
- while (!list_empty(&reaplist)) {
- nbl = list_first_entry(&reaplist,
- struct nfsd4_blocked_lock, nbl_lru);
- list_del_init(&nbl->nbl_lru);
- posix_unblock_lock(&nbl->nbl_lock);
- free_blocked_lock(nbl);
- }
-
nfsd4_client_tracking_exit(net);
nfs4_state_destroy_net(net);
}
Patches currently in stable-queue which might be from jlayton(a)redhat.com are
queue-4.9/nfsd-remove-blocked-locks-on-client-teardown.patch
This is a note to let you know that I've just added the patch titled
libata: remove WARN() for DMA or PIO command without data
to the 4.9-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:
libata-remove-warn-for-dma-or-pio-command-without-data.patch
and it can be found in the queue-4.9 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 9173e5e80729c8434b8d27531527c5245f4a5594 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Sat, 3 Feb 2018 20:33:27 -0800
Subject: libata: remove WARN() for DMA or PIO command without data
From: Eric Biggers <ebiggers(a)google.com>
commit 9173e5e80729c8434b8d27531527c5245f4a5594 upstream.
syzkaller hit a WARN() in ata_qc_issue() when writing to /dev/sg0. This
happened because it issued a READ_6 command with no data buffer.
Just remove the WARN(), as it doesn't appear indicate a kernel bug. The
expected behavior is to fail the command, which the code does.
Here's a reproducer that works in QEMU when /dev/sg0 refers to a disk of
the default type ("82371SB PIIX3 IDE"):
#include <fcntl.h>
#include <unistd.h>
int main()
{
char buf[42] = { [36] = 0x8 /* READ_6 */ };
write(open("/dev/sg0", O_RDWR), buf, sizeof(buf));
}
Fixes: f92a26365a72 ("libata: change ATA_QCFLAG_DMAMAP semantics")
Reported-by: syzbot+f7b556d1766502a69d85071d2ff08bd87be53d0f(a)syzkaller.appspotmail.com
Cc: <stable(a)vger.kernel.org> # v2.6.25+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/libata-core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -5265,8 +5265,7 @@ void ata_qc_issue(struct ata_queued_cmd
* We guarantee to LLDs that they will have at least one
* non-zero sg if the command is a data command.
*/
- if (WARN_ON_ONCE(ata_is_data(prot) &&
- (!qc->sg || !qc->n_elem || !qc->nbytes)))
+ if (ata_is_data(prot) && (!qc->sg || !qc->n_elem || !qc->nbytes))
goto sys_err;
if (ata_is_dma(prot) || (ata_is_pio(prot) &&
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.9/libata-fix-length-validation-of-atapi-relayed-scsi-commands.patch
queue-4.9/libata-remove-warn-for-dma-or-pio-command-without-data.patch
queue-4.9/libata-don-t-try-to-pass-through-ncq-commands-to-non-ncq-devices.patch
This is a note to let you know that I've just added the patch titled
libata: Modify quirks for MX100 to limit NCQ_TRIM quirk to MU01 version
to the 4.9-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:
libata-modify-quirks-for-mx100-to-limit-ncq_trim-quirk-to-mu01-version.patch
and it can be found in the queue-4.9 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 d418ff56b8f2d2b296daafa8da151fe27689b757 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Mon, 19 Mar 2018 16:34:00 +0100
Subject: libata: Modify quirks for MX100 to limit NCQ_TRIM quirk to MU01 version
From: Hans de Goede <hdegoede(a)redhat.com>
commit d418ff56b8f2d2b296daafa8da151fe27689b757 upstream.
When commit 9c7be59fc519af ("libata: Apply NOLPM quirk to Crucial MX100
512GB SSDs") was added it inherited the ATA_HORKAGE_NO_NCQ_TRIM quirk
from the existing "Crucial_CT*MX100*" entry, but that entry sets model_rev
to "MU01", where as the entry adding the NOLPM quirk sets it to NULL.
This means that after this commit we no apply the NO_NCQ_TRIM quirk to
all "Crucial_CT512MX100*" SSDs even if they have the fixed "MU02"
firmware. This commit splits the "Crucial_CT512MX100*" quirk into 2
quirks, one for the "MU01" firmware and one for all other firmware
versions, so that we once again only apply the NO_NCQ_TRIM quirk to the
"MU01" firmware version.
Fixes: 9c7be59fc519af ("libata: Apply NOLPM quirk to ... MX100 512GB SSDs")
Cc: stable(a)vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/libata-core.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4406,10 +4406,13 @@ static const struct ata_blacklist_entry
/* Crucial BX100 SSD 500GB has broken LPM support */
{ "CT500BX100SSD1", NULL, ATA_HORKAGE_NOLPM },
- /* The 512GB version of the MX100 has both queued TRIM and LPM issues */
- { "Crucial_CT512MX100*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
+ /* 512GB MX100 with MU01 firmware has both queued TRIM and LPM issues */
+ { "Crucial_CT512MX100*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM |
ATA_HORKAGE_NOLPM, },
+ /* 512GB MX100 with newer firmware has only LPM issues */
+ { "Crucial_CT512MX100*", NULL, ATA_HORKAGE_ZERO_AFTER_TRIM |
+ ATA_HORKAGE_NOLPM, },
/* 480GB+ M500 SSDs have both queued TRIM and LPM issues */
{ "Crucial_CT480M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.9/libata-apply-nolpm-quirk-to-crucial-m500-480-and-960gb-ssds.patch
queue-4.9/libata-apply-nolpm-quirk-to-crucial-mx100-512gb-ssds.patch
queue-4.9/pci-add-function-1-dma-alias-quirk-for-highpoint-rocketraid-644l.patch
queue-4.9/libata-modify-quirks-for-mx100-to-limit-ncq_trim-quirk-to-mu01-version.patch
queue-4.9/ahci-add-pci-id-for-the-highpoint-rocketraid-644l-card.patch
queue-4.9/libata-make-crucial-bx100-500gb-lpm-quirk-apply-to-all-firmware-versions.patch
This is a note to let you know that I've just added the patch titled
libata: Make Crucial BX100 500GB LPM quirk apply to all firmware versions
to the 4.9-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:
libata-make-crucial-bx100-500gb-lpm-quirk-apply-to-all-firmware-versions.patch
and it can be found in the queue-4.9 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 3bf7b5d6d017c27e0d3b160aafb35a8e7cfeda1f Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Mon, 19 Mar 2018 16:33:59 +0100
Subject: libata: Make Crucial BX100 500GB LPM quirk apply to all firmware versions
From: Hans de Goede <hdegoede(a)redhat.com>
commit 3bf7b5d6d017c27e0d3b160aafb35a8e7cfeda1f upstream.
Commit b17e5729a630 ("libata: disable LPM for Crucial BX100 SSD 500GB
drive"), introduced a ATA_HORKAGE_NOLPM quirk for Crucial BX100 500GB SSDs
but limited this to the MU02 firmware version, according to:
http://www.crucial.com/usa/en/support-ssd-firmware
MU02 is the last version, so there are no newer possibly fixed versions
and if the MU02 version has broken LPM then the MU01 almost certainly
also has broken LPM, so this commit changes the quirk to apply to all
firmware versions.
Fixes: b17e5729a630 ("libata: disable LPM for Crucial BX100 SSD 500GB...")
Cc: stable(a)vger.kernel.org
Cc: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/libata-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4404,7 +4404,7 @@ static const struct ata_blacklist_entry
{ "PIONEER DVD-RW DVR-216D", NULL, ATA_HORKAGE_NOSETXFER },
/* Crucial BX100 SSD 500GB has broken LPM support */
- { "CT500BX100SSD1", "MU02", ATA_HORKAGE_NOLPM },
+ { "CT500BX100SSD1", NULL, ATA_HORKAGE_NOLPM },
/* The 512GB version of the MX100 has both queued TRIM and LPM issues */
{ "Crucial_CT512MX100*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.9/libata-apply-nolpm-quirk-to-crucial-m500-480-and-960gb-ssds.patch
queue-4.9/libata-apply-nolpm-quirk-to-crucial-mx100-512gb-ssds.patch
queue-4.9/pci-add-function-1-dma-alias-quirk-for-highpoint-rocketraid-644l.patch
queue-4.9/libata-modify-quirks-for-mx100-to-limit-ncq_trim-quirk-to-mu01-version.patch
queue-4.9/ahci-add-pci-id-for-the-highpoint-rocketraid-644l-card.patch
queue-4.9/libata-make-crucial-bx100-500gb-lpm-quirk-apply-to-all-firmware-versions.patch