This is the start of the stable review cycle for the 4.13.2 release.
There are 27 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu Sep 14 16:52:56 UTC 2017.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.13.2-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.13.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.13.2-rc1
Trond Myklebust <[email protected]>
NFSv4: Fix up mirror allocation
[email protected] <[email protected]>
NFS: Sync the correct byte range during synchronous writes
Trond Myklebust <[email protected]>
NFS: Fix 2 use after free issues in the I/O code
Mark Rutland <[email protected]>
ARM: 8692/1: mm: abort uaccess retries upon fatal signal
Marc Zyngier <[email protected]>
ARM64: dts: marvell: armada-37xx: Fix GIC maintenance interrupt
Ben Seri <[email protected]>
Bluetooth: Properly check L2CAP config option output buffer length
Stanislaw Gruszka <[email protected]>
rt2800: fix TX_PIN_CFG setting for non MT7620 chips
Linus Torvalds <[email protected]>
Revert "firmware: add sanity check on shutdown/suspend"
Brijesh Singh <[email protected]>
KVM: SVM: Limit PFERR_NESTED_GUEST_PAGE error_code check to L1 guest
Laurent Dufour <[email protected]>
mm/memory.c: fix mem_cgroup_oom_disable() call missing
Michal Hocko <[email protected]>
mm/sparse.c: fix typo in online_mem_sections
David Rientjes <[email protected]>
mm/swapfile.c: fix swapon frontswap_map memory leak on error
Darrick J. Wong <[email protected]>
mm: kvfree the swap cluster info if the swap file is unsatisfactory
Andy Lutomirski <[email protected]>
selftests/x86/fsgsbase: Test selectors 1, 2, and 3
Shuah Khan <[email protected]>
selftests: timers: Fix run_destructive_tests target to handle skipped tests
John Stultz <[email protected]>
kselftests: timers: leap-a-day: Change default arguments to help test runs
Ian W MORRISON <[email protected]>
brcmfmac: feature check for multi-scheduled scan fails on bcm4345 devices
Eric Dumazet <[email protected]>
radix-tree: must check __radix_tree_preload() return value
Larry Finger <[email protected]>
rtlwifi: btcoexist: Fix antenna selection code
Larry Finger <[email protected]>
rtlwifi: btcoexist: Fix breakage of ant_sel for rtl8723be
Aleksa Sarai <[email protected]>
btrfs: resume qgroup rescan on rw remount
Daniel Verkamp <[email protected]>
nvme-fabrics: generate spec-compliant UUID NQNs
Abhishek Sahu <[email protected]>
mtd: nand: qcom: fix config error for BCH
Abhishek Sahu <[email protected]>
mtd: nand: qcom: fix read failure without complete bootchain
Boris Brezillon <[email protected]>
mtd: nand: mxc: Fix mxc_v1 ooblayout
Martin Blumenstingl <[email protected]>
mtd: nand: hynix: add support for 20nm NAND chips
Lothar Waßmann <[email protected]>
mtd: nand: make Samsung SLC NAND usable again
-------------
Diffstat:
.../driver-api/firmware/request_firmware.rst | 11 ---
Makefile | 4 +-
arch/arm/mm/fault.c | 5 +-
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 1 +
arch/x86/kvm/mmu.c | 3 +-
drivers/base/firmware_class.c | 99 ----------------------
drivers/mtd/nand/mxc_nand.c | 7 +-
drivers/mtd/nand/nand_base.c | 7 +-
drivers/mtd/nand/nand_hynix.c | 4 +-
drivers/mtd/nand/qcom_nandc.c | 18 ++--
.../wireless/broadcom/brcm80211/brcmfmac/feature.c | 3 +-
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 5 +-
.../realtek/rtlwifi/btcoexist/halbtc8723b2ant.c | 5 +-
.../realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 23 +++--
drivers/nvme/host/fabrics.c | 2 +-
fs/btrfs/super.c | 2 +
fs/nfs/file.c | 6 +-
fs/nfs/internal.h | 1 -
fs/nfs/pagelist.c | 99 +++++++++++-----------
fs/nfs/pnfs.c | 2 -
lib/radix-tree.c | 9 +-
mm/memory.c | 10 +--
mm/sparse.c | 2 +-
mm/swapfile.c | 3 +-
net/bluetooth/l2cap_core.c | 80 +++++++++--------
tools/testing/selftests/timers/Makefile | 26 +++---
tools/testing/selftests/timers/leap-a-day.c | 17 ++--
tools/testing/selftests/x86/fsgsbase.c | 41 +++++++--
28 files changed, 229 insertions(+), 266 deletions(-)
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
commit bc9ae2247ac92fd4d962507bafa3afffff6660ff upstream.
__radix_tree_preload() only disables preemption if no error is returned.
So we really need to make sure callers always check the return value.
idr_preload() contract is to always disable preemption, so we need
to add a missing preempt_disable() if an error happened.
Similarly, ida_pre_get() only needs to call preempt_enable() in the
case no error happened.
Link: http://lkml.kernel.org/r/[email protected]
Fixes: 0a835c4f090a ("Reimplement IDR and IDA using the radix tree")
Fixes: 7ad3d4d85c7a ("ida: Move ida_bitmap to a percpu variable")
Signed-off-by: Eric Dumazet <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: "Kirill A. Shutemov" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
lib/radix-tree.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/lib/radix-tree.c
+++ b/lib/radix-tree.c
@@ -463,7 +463,7 @@ radix_tree_node_free(struct radix_tree_n
* To make use of this facility, the radix tree must be initialised without
* __GFP_DIRECT_RECLAIM being passed to INIT_RADIX_TREE().
*/
-static int __radix_tree_preload(gfp_t gfp_mask, unsigned nr)
+static __must_check int __radix_tree_preload(gfp_t gfp_mask, unsigned nr)
{
struct radix_tree_preload *rtp;
struct radix_tree_node *node;
@@ -2103,7 +2103,8 @@ EXPORT_SYMBOL(radix_tree_tagged);
*/
void idr_preload(gfp_t gfp_mask)
{
- __radix_tree_preload(gfp_mask, IDR_PRELOAD_SIZE);
+ if (__radix_tree_preload(gfp_mask, IDR_PRELOAD_SIZE))
+ preempt_disable();
}
EXPORT_SYMBOL(idr_preload);
@@ -2117,13 +2118,13 @@ EXPORT_SYMBOL(idr_preload);
*/
int ida_pre_get(struct ida *ida, gfp_t gfp)
{
- __radix_tree_preload(gfp, IDA_PRELOAD_SIZE);
/*
* The IDA API has no preload_end() equivalent. Instead,
* ida_get_new() can return -EAGAIN, prompting the caller
* to return to the ida_pre_get() step.
*/
- preempt_enable();
+ if (!__radix_tree_preload(gfp, IDA_PRELOAD_SIZE))
+ preempt_enable();
if (!this_cpu_read(ida_bitmap)) {
struct ida_bitmap *bitmap = kmalloc(sizeof(*bitmap), gfp);
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Stultz <[email protected]>
commit 98b74e1f31045a63f6148b2d129ca9bf244e24ab upstream.
Change default arguments for leap-a-day to always set the time
each iteration (rather then waiting for midnight UTC), and to
only run 10 interations (rather then infinite).
If one wants to wait for midnight UTC, they can use the new -w
flag, and we add a note to the argument help that -i -1 will
run infinitely.
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Miroslav Lichvar <[email protected]>
Cc: Richard Cochran <[email protected]>
Cc: Prarit Bhargava <[email protected]>
Cc: Stephen Boyd <[email protected]>
Cc: Shuah Khan <[email protected]>
Cc: [email protected]
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/testing/selftests/timers/leap-a-day.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
--- a/tools/testing/selftests/timers/leap-a-day.c
+++ b/tools/testing/selftests/timers/leap-a-day.c
@@ -190,18 +190,18 @@ int main(int argc, char **argv)
struct sigevent se;
struct sigaction act;
int signum = SIGRTMAX;
- int settime = 0;
+ int settime = 1;
int tai_time = 0;
int insert = 1;
- int iterations = -1;
+ int iterations = 10;
int opt;
/* Process arguments */
while ((opt = getopt(argc, argv, "sti:")) != -1) {
switch (opt) {
- case 's':
- printf("Setting time to speed up testing\n");
- settime = 1;
+ case 'w':
+ printf("Only setting leap-flag, not changing time. It could take up to a day for leap to trigger.\n");
+ settime = 0;
break;
case 'i':
iterations = atoi(optarg);
@@ -210,9 +210,10 @@ int main(int argc, char **argv)
tai_time = 1;
break;
default:
- printf("Usage: %s [-s] [-i <iterations>]\n", argv[0]);
- printf(" -s: Set time to right before leap second each iteration\n");
- printf(" -i: Number of iterations\n");
+ printf("Usage: %s [-w] [-i <iterations>]\n", argv[0]);
+ printf(" -w: Set flag and wait for leap second each iteration");
+ printf(" (default sets time to right before leapsecond)\n");
+ printf(" -i: Number of iterations (-1 = infinite, default is 10)\n");
printf(" -t: Print TAI time\n");
exit(-1);
}
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shuah Khan <[email protected]>
commit df9c011c0a23cf1399c01f896cd359d932ab49b5 upstream.
When a test exits with skip exit code of 4, "make run_destructive_tests"
halts testing. Fix run_destructive_tests target to handle error exit codes.
Reported-by: John Stultz <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/testing/selftests/timers/Makefile | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
--- a/tools/testing/selftests/timers/Makefile
+++ b/tools/testing/selftests/timers/Makefile
@@ -14,20 +14,20 @@ TEST_GEN_PROGS_EXTENDED = alarmtimer-sus
include ../lib.mk
+define RUN_DESTRUCTIVE_TESTS
+ @for TEST in $(TEST_GEN_PROGS_EXTENDED); do \
+ BASENAME_TEST=`basename $$TEST`; \
+ if [ ! -x $$BASENAME_TEST ]; then \
+ echo "selftests: Warning: file $$BASENAME_TEST is not executable, correct this.";\
+ echo "selftests: $$BASENAME_TEST [FAIL]"; \
+ else \
+ cd `dirname $$TEST`; (./$$BASENAME_TEST && echo "selftests: $$BASENAME_TEST [PASS]") || echo "selftests: $$BASENAME_TEST [FAIL]"; cd -;\
+ fi; \
+ done;
+endef
+
# these tests require escalated privileges
# and may modify the system time or trigger
# other behavior like suspend
run_destructive_tests: run_tests
- ./alarmtimer-suspend
- ./valid-adjtimex
- ./adjtick
- ./change_skew
- ./skew_consistency
- ./clocksource-switch
- ./freq-step
- ./leap-a-day -s -i 10
- ./leapcrash
- ./set-tz
- ./set-tai
- ./set-2038
-
+ $(RUN_DESTRUCTIVE_TESTS)
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Blumenstingl <[email protected]>
commit fd213b5bae800dc00a2930dcd07f63ab9bbff3f9 upstream.
According to the datasheet of the H27UCG8T2BTR the NAND Technology field
(6th byte of the "Device Identifier Description", bits 0-2) the
following values are possible:
- 0x0 = 48nm
- 0x1 = 41nm
- 0x2 = 32nm
- 0x3 = 26nm
- 0x4 = 20nm
- (all others are reserved)
Fix this by extending the mask for this field to allow detecting value
0x4 (20nm) as valid NAND technology.
Without this the detection of the ECC requirements fails, because the
code assumes that the device is a 48nm device (0x4 & 0x3 = 0x0) and
aborts with "Invalid ECC requirements" because it cannot map the "ECC
Level". Extending the mask makes the ECC requirement detection code
recognize this chip as <= 26nm and sets up the ECC step size and ECC
strength correctly.
Signed-off-by: Martin Blumenstingl <[email protected]>
Fixes: 78f3482d7480 ("mtd: nand: hynix: Rework NAND ID decoding to extract more information")
Signed-off-by: Boris Brezillon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mtd/nand/nand_hynix.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/mtd/nand/nand_hynix.c
+++ b/drivers/mtd/nand/nand_hynix.c
@@ -477,7 +477,7 @@ static void hynix_nand_extract_ecc_requi
* The ECC requirements field meaning depends on the
* NAND technology.
*/
- u8 nand_tech = chip->id.data[5] & 0x3;
+ u8 nand_tech = chip->id.data[5] & 0x7;
if (nand_tech < 3) {
/* > 26nm, reference: H27UBG8T2A datasheet */
@@ -533,7 +533,7 @@ static void hynix_nand_extract_scramblin
if (nand_tech > 0)
chip->options |= NAND_NEED_SCRAMBLING;
} else {
- nand_tech = chip->id.data[5] & 0x3;
+ nand_tech = chip->id.data[5] & 0x7;
/* < 32nm */
if (nand_tech > 2)
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aleksa Sarai <[email protected]>
commit 6c6b5a39c4bf3dbd8cf629c9f5450e983c19dbb9 upstream.
Several distributions mount the "proper root" as ro during initrd and
then remount it as rw before pivot_root(2). Thus, if a rescan had been
aborted by a previous shutdown, the rescan would never be resumed.
This issue would manifest itself as several btrfs ioctl(2)s causing the
entire machine to hang when btrfs_qgroup_wait_for_completion was hit
(due to the fs_info->qgroup_rescan_running flag being set but the rescan
itself not being resumed). Notably, Docker's btrfs storage driver makes
regular use of BTRFS_QUOTA_CTL_DISABLE and BTRFS_IOC_QUOTA_RESCAN_WAIT
(causing this problem to be manifested on boot for some machines).
Cc: Jeff Mahoney <[email protected]>
Fixes: b382a324b60f ("Btrfs: fix qgroup rescan resume on mount")
Signed-off-by: Aleksa Sarai <[email protected]>
Reviewed-by: Nikolay Borisov <[email protected]>
Tested-by: Nikolay Borisov <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/super.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1814,6 +1814,8 @@ static int btrfs_remount(struct super_bl
goto restore;
}
+ btrfs_qgroup_rescan_resume(fs_info);
+
if (!fs_info->uuid_root) {
btrfs_info(fs_info, "creating UUID tree");
ret = btrfs_create_uuid_tree(fs_info);
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Abhishek Sahu <[email protected]>
commit d8a9b320a26c1ea28e51e4f3ecfb593d5aac2910 upstream.
The NAND page read fails without complete boot chain since
NAND_DEV_CMD_VLD value is not proper. The default power on reset
value for this register is
0xe - ERASE_START_VALID | WRITE_START_VALID | READ_STOP_VALID
The READ_START_VALID should be enabled for sending PAGE_READ
command. READ_STOP_VALID should be cleared since normal NAND
page read does not require READ_STOP command.
Fixes: c76b78d8ec05a ("mtd: nand: Qualcomm NAND controller driver")
Reviewed-by: Archit Taneja <[email protected]>
Signed-off-by: Abhishek Sahu <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mtd/nand/qcom_nandc.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -109,7 +109,11 @@
#define READ_ADDR 0
/* NAND_DEV_CMD_VLD bits */
-#define READ_START_VLD 0
+#define READ_START_VLD BIT(0)
+#define READ_STOP_VLD BIT(1)
+#define WRITE_START_VLD BIT(2)
+#define ERASE_START_VLD BIT(3)
+#define SEQ_READ_START_VLD BIT(4)
/* NAND_EBI2_ECC_BUF_CFG bits */
#define NUM_STEPS 0
@@ -148,6 +152,10 @@
#define FETCH_ID 0xb
#define RESET_DEVICE 0xd
+/* Default Value for NAND_DEV_CMD_VLD */
+#define NAND_DEV_CMD_VLD_VAL (READ_START_VLD | WRITE_START_VLD | \
+ ERASE_START_VLD | SEQ_READ_START_VLD)
+
/*
* the NAND controller performs reads/writes with ECC in 516 byte chunks.
* the driver calls the chunks 'step' or 'codeword' interchangeably
@@ -672,8 +680,7 @@ static int nandc_param(struct qcom_nand_
/* configure CMD1 and VLD for ONFI param probing */
nandc_set_reg(nandc, NAND_DEV_CMD_VLD,
- (nandc->vld & ~(1 << READ_START_VLD))
- | 0 << READ_START_VLD);
+ (nandc->vld & ~READ_START_VLD));
nandc_set_reg(nandc, NAND_DEV_CMD1,
(nandc->cmd1 & ~(0xFF << READ_ADDR))
| NAND_CMD_PARAM << READ_ADDR);
@@ -1972,13 +1979,14 @@ static int qcom_nandc_setup(struct qcom_
{
/* kill onenand */
nandc_write(nandc, SFLASHC_BURST_CFG, 0);
+ nandc_write(nandc, NAND_DEV_CMD_VLD, NAND_DEV_CMD_VLD_VAL);
/* enable ADM DMA */
nandc_write(nandc, NAND_FLASH_CHIP_SELECT, DM_EN);
/* save the original values of these registers */
nandc->cmd1 = nandc_read(nandc, NAND_DEV_CMD1);
- nandc->vld = nandc_read(nandc, NAND_DEV_CMD_VLD);
+ nandc->vld = NAND_DEV_CMD_VLD_VAL;
return 0;
}
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
commit 196639ebbe63a037fe9a80669140bd292d8bcd80 upstream.
The writeback code wants to send a commit after processing the pages,
which is why we want to delay releasing the struct path until after
that's done.
Also, the layout code expects that we do not free the inode before
we've put the layout segments in pnfs_writehdr_free() and
pnfs_readhdr_free()
Fixes: 919e3bd9a875 ("NFS: Ensure we commit after writeback is complete")
Fixes: 4714fb51fd03 ("nfs: remove pgio_header refcount, related cleanup")
Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nfs/internal.h | 1 -
fs/nfs/pagelist.c | 26 ++++++++++++--------------
fs/nfs/pnfs.c | 2 --
3 files changed, 12 insertions(+), 17 deletions(-)
--- a/fs/nfs/internal.h
+++ b/fs/nfs/internal.h
@@ -251,7 +251,6 @@ int nfs_iocounter_wait(struct nfs_lock_c
extern const struct nfs_pageio_ops nfs_pgio_rw_ops;
struct nfs_pgio_header *nfs_pgio_header_alloc(const struct nfs_rw_ops *);
void nfs_pgio_header_free(struct nfs_pgio_header *);
-void nfs_pgio_data_destroy(struct nfs_pgio_header *);
int nfs_generic_pgio(struct nfs_pageio_descriptor *, struct nfs_pgio_header *);
int nfs_initiate_pgio(struct rpc_clnt *clnt, struct nfs_pgio_header *hdr,
struct rpc_cred *cred, const struct nfs_rpc_ops *rpc_ops,
--- a/fs/nfs/pagelist.c
+++ b/fs/nfs/pagelist.c
@@ -530,16 +530,6 @@ struct nfs_pgio_header *nfs_pgio_header_
}
EXPORT_SYMBOL_GPL(nfs_pgio_header_alloc);
-/*
- * nfs_pgio_header_free - Free a read or write header
- * @hdr: The header to free
- */
-void nfs_pgio_header_free(struct nfs_pgio_header *hdr)
-{
- hdr->rw_ops->rw_free_header(hdr);
-}
-EXPORT_SYMBOL_GPL(nfs_pgio_header_free);
-
/**
* nfs_pgio_data_destroy - make @hdr suitable for reuse
*
@@ -548,14 +538,24 @@ EXPORT_SYMBOL_GPL(nfs_pgio_header_free);
*
* @hdr: A header that has had nfs_generic_pgio called
*/
-void nfs_pgio_data_destroy(struct nfs_pgio_header *hdr)
+static void nfs_pgio_data_destroy(struct nfs_pgio_header *hdr)
{
if (hdr->args.context)
put_nfs_open_context(hdr->args.context);
if (hdr->page_array.pagevec != hdr->page_array.page_array)
kfree(hdr->page_array.pagevec);
}
-EXPORT_SYMBOL_GPL(nfs_pgio_data_destroy);
+
+/*
+ * nfs_pgio_header_free - Free a read or write header
+ * @hdr: The header to free
+ */
+void nfs_pgio_header_free(struct nfs_pgio_header *hdr)
+{
+ nfs_pgio_data_destroy(hdr);
+ hdr->rw_ops->rw_free_header(hdr);
+}
+EXPORT_SYMBOL_GPL(nfs_pgio_header_free);
/**
* nfs_pgio_rpcsetup - Set up arguments for a pageio call
@@ -669,7 +669,6 @@ EXPORT_SYMBOL_GPL(nfs_initiate_pgio);
static void nfs_pgio_error(struct nfs_pgio_header *hdr)
{
set_bit(NFS_IOHDR_REDO, &hdr->flags);
- nfs_pgio_data_destroy(hdr);
hdr->completion_ops->completion(hdr);
}
@@ -680,7 +679,6 @@ static void nfs_pgio_error(struct nfs_pg
static void nfs_pgio_release(void *calldata)
{
struct nfs_pgio_header *hdr = calldata;
- nfs_pgio_data_destroy(hdr);
hdr->completion_ops->completion(hdr);
}
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -2274,7 +2274,6 @@ pnfs_write_through_mds(struct nfs_pageio
nfs_pageio_reset_write_mds(desc);
mirror->pg_recoalesce = 1;
}
- nfs_pgio_data_destroy(hdr);
hdr->release(hdr);
}
@@ -2398,7 +2397,6 @@ pnfs_read_through_mds(struct nfs_pageio_
nfs_pageio_reset_read_mds(desc);
mirror->pg_recoalesce = 1;
}
- nfs_pgio_data_destroy(hdr);
hdr->release(hdr);
}
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larry Finger <[email protected]>
commit 6d622692836950b3c943776f84c4557ff6c02f3b upstream.
In commit 87d8a9f35202 ("rtlwifi: btcoex: call bind to setup btcoex"),
the code turns on a call to exhalbtc_bind_bt_coex_withadapter(). This
routine contains a bug that causes incorrect antenna selection for those
HP laptops with only one antenna and an incorrectly programmed EFUSE.
These boxes are the ones that need the ant_sel module parameter.
Fixes: 87d8a9f35202 ("rtlwifi: btcoex: call bind to setup btcoex")
Signed-off-by: Larry Finger <[email protected]>
Cc: Ping-Ke Shih <[email protected]>
Cc: Yan-Hsuan Chuang <[email protected]>
Cc: Birming Chiu <[email protected]>
Cc: Shaofu <[email protected]>
Cc: Steven Ting <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 23 ++++++----
1 file changed, 16 insertions(+), 7 deletions(-)
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -173,6 +173,16 @@ static u8 halbtc_get_wifi_central_chnl(s
u8 rtl_get_hwpg_single_ant_path(struct rtl_priv *rtlpriv)
{
+ struct rtl_mod_params *mod_params = rtlpriv->cfg->mod_params;
+
+ /* override ant_num / ant_path */
+ if (mod_params->ant_sel) {
+ rtlpriv->btcoexist.btc_info.ant_num =
+ (mod_params->ant_sel == 1 ? ANT_X2 : ANT_X1);
+
+ rtlpriv->btcoexist.btc_info.single_ant_path =
+ (mod_params->ant_sel == 1 ? 0 : 1);
+ }
return rtlpriv->btcoexist.btc_info.single_ant_path;
}
@@ -183,6 +193,7 @@ u8 rtl_get_hwpg_bt_type(struct rtl_priv
u8 rtl_get_hwpg_ant_num(struct rtl_priv *rtlpriv)
{
+ struct rtl_mod_params *mod_params = rtlpriv->cfg->mod_params;
u8 num;
if (rtlpriv->btcoexist.btc_info.ant_num == ANT_X2)
@@ -190,6 +201,10 @@ u8 rtl_get_hwpg_ant_num(struct rtl_priv
else
num = 1;
+ /* override ant_num / ant_path */
+ if (mod_params->ant_sel)
+ num = (mod_params->ant_sel == 1 ? ANT_X2 : ANT_X1) + 1;
+
return num;
}
@@ -861,7 +876,7 @@ bool exhalbtc_bind_bt_coex_withadapter(v
{
struct btc_coexist *btcoexist = &gl_bt_coexist;
struct rtl_priv *rtlpriv = adapter;
- u8 ant_num = 2, chip_type, single_ant_path = 0;
+ u8 ant_num = 2, chip_type;
if (btcoexist->binded)
return false;
@@ -896,12 +911,6 @@ bool exhalbtc_bind_bt_coex_withadapter(v
ant_num = rtl_get_hwpg_ant_num(rtlpriv);
exhalbtc_set_ant_num(rtlpriv, BT_COEX_ANT_TYPE_PG, ant_num);
- /* set default antenna position to main port */
- btcoexist->board_info.btdm_ant_pos = BTC_ANTENNA_AT_MAIN_PORT;
-
- single_ant_path = rtl_get_hwpg_single_ant_path(rtlpriv);
- exhalbtc_set_single_ant_path(single_ant_path);
-
if (rtl_get_hwpg_package_type(rtlpriv) == 0)
btcoexist->board_info.tfbga_package = false;
else if (rtl_get_hwpg_package_type(rtlpriv) == 1)
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Rientjes <[email protected]>
commit b6b1fd2a6bedd533aeed83924d7be0e944fded9f upstream.
Free frontswap_map if an error is encountered before enable_swap_info().
Signed-off-by: David Rientjes <[email protected]>
Reviewed-by: "Huang, Ying" <[email protected]>
Cc: Darrick J. Wong <[email protected]>
Cc: Hugh Dickins <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/swapfile.c | 1 +
1 file changed, 1 insertion(+)
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -3053,6 +3053,7 @@ bad_swap:
spin_unlock(&swap_lock);
vfree(swap_map);
kvfree(cluster_info);
+ kvfree(frontswap_map);
if (swap_file) {
if (inode && S_ISREG(inode->i_mode)) {
inode_unlock(inode);
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Torvalds <[email protected]>
commit f007cad159e99fa2acd3b2e9364fbb32ad28b971 upstream.
This reverts commit 81f95076281fdd3bc382e004ba1bce8e82fccbce.
It causes random failures of firmware loading at resume time (well,
random for me, it seems to be more reliable for others) because the
firmware disabling is not actually synchronous with any particular
resume event, and at least the btusb driver that uses a workqueue to
load the firmware at resume seems to occasionally hit the "firmware
loading is disabled" logic because the firmware loader hasn't gotten the
resume event yet.
Some kind of sanity check for not trying to load firmware when it's not
possible might be a good thing, but this commit was not it.
Greg seems to have silently suffered the same issue, and pointed to the
likely culprit, and Gabriel C verified the revert fixed it for him too.
Reported-by: Linus Torvalds <[email protected]>
Pointed-at-by: Greg Kroah-Hartman <[email protected]>
Tested-by: Gabriel C <[email protected]>
Cc: Luis R. Rodriguez <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
Documentation/driver-api/firmware/request_firmware.rst | 11 -
drivers/base/firmware_class.c | 99 -----------------
2 files changed, 110 deletions(-)
--- a/Documentation/driver-api/firmware/request_firmware.rst
+++ b/Documentation/driver-api/firmware/request_firmware.rst
@@ -44,17 +44,6 @@ request_firmware_nowait
.. kernel-doc:: drivers/base/firmware_class.c
:functions: request_firmware_nowait
-Considerations for suspend and resume
-=====================================
-
-During suspend and resume only the built-in firmware and the firmware cache
-elements of the firmware API can be used. This is managed by fw_pm_notify().
-
-fw_pm_notify
-------------
-.. kernel-doc:: drivers/base/firmware_class.c
- :functions: fw_pm_notify
-
request firmware API expected driver use
========================================
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -256,38 +256,6 @@ static int fw_cache_piggyback_on_request
* guarding for corner cases a global lock should be OK */
static DEFINE_MUTEX(fw_lock);
-static bool __enable_firmware = false;
-
-static void enable_firmware(void)
-{
- mutex_lock(&fw_lock);
- __enable_firmware = true;
- mutex_unlock(&fw_lock);
-}
-
-static void disable_firmware(void)
-{
- mutex_lock(&fw_lock);
- __enable_firmware = false;
- mutex_unlock(&fw_lock);
-}
-
-/*
- * When disabled only the built-in firmware and the firmware cache will be
- * used to look for firmware.
- */
-static bool firmware_enabled(void)
-{
- bool enabled = false;
-
- mutex_lock(&fw_lock);
- if (__enable_firmware)
- enabled = true;
- mutex_unlock(&fw_lock);
-
- return enabled;
-}
-
static struct firmware_cache fw_cache;
static struct firmware_buf *__allocate_fw_buf(const char *fw_name,
@@ -1239,12 +1207,6 @@ _request_firmware(const struct firmware
if (ret <= 0) /* error or already assigned */
goto out;
- if (!firmware_enabled()) {
- WARN(1, "firmware request while host is not available\n");
- ret = -EHOSTDOWN;
- goto out;
- }
-
ret = fw_get_filesystem_firmware(device, fw->priv);
if (ret) {
if (!(opt_flags & FW_OPT_NO_WARN))
@@ -1755,62 +1717,6 @@ static void device_uncache_fw_images_del
msecs_to_jiffies(delay));
}
-/**
- * fw_pm_notify - notifier for suspend/resume
- * @notify_block: unused
- * @mode: mode we are switching to
- * @unused: unused
- *
- * Used to modify the firmware_class state as we move in between states.
- * The firmware_class implements a firmware cache to enable device driver
- * to fetch firmware upon resume before the root filesystem is ready. We
- * disable API calls which do not use the built-in firmware or the firmware
- * cache when we know these calls will not work.
- *
- * The inner logic behind all this is a bit complex so it is worth summarizing
- * the kernel's own suspend/resume process with context and focus on how this
- * can impact the firmware API.
- *
- * First a review on how we go to suspend::
- *
- * pm_suspend() --> enter_state() -->
- * sys_sync()
- * suspend_prepare() -->
- * __pm_notifier_call_chain(PM_SUSPEND_PREPARE, ...);
- * suspend_freeze_processes() -->
- * freeze_processes() -->
- * __usermodehelper_set_disable_depth(UMH_DISABLED);
- * freeze all tasks ...
- * freeze_kernel_threads()
- * suspend_devices_and_enter() -->
- * dpm_suspend_start() -->
- * dpm_prepare()
- * dpm_suspend()
- * suspend_enter() -->
- * platform_suspend_prepare()
- * dpm_suspend_late()
- * freeze_enter()
- * syscore_suspend()
- *
- * When we resume we bail out of a loop from suspend_devices_and_enter() and
- * unwind back out to the caller enter_state() where we were before as follows::
- *
- * enter_state() -->
- * suspend_devices_and_enter() --> (bail from loop)
- * dpm_resume_end() -->
- * dpm_resume()
- * dpm_complete()
- * suspend_finish() -->
- * suspend_thaw_processes() -->
- * thaw_processes() -->
- * __usermodehelper_set_disable_depth(UMH_FREEZING);
- * thaw_workqueues();
- * thaw all processes ...
- * usermodehelper_enable();
- * pm_notifier_call_chain(PM_POST_SUSPEND);
- *
- * fw_pm_notify() works through pm_notifier_call_chain().
- */
static int fw_pm_notify(struct notifier_block *notify_block,
unsigned long mode, void *unused)
{
@@ -1824,7 +1730,6 @@ static int fw_pm_notify(struct notifier_
*/
kill_pending_fw_fallback_reqs(true);
device_cache_fw_images();
- disable_firmware();
break;
case PM_POST_SUSPEND:
@@ -1837,7 +1742,6 @@ static int fw_pm_notify(struct notifier_
mutex_lock(&fw_lock);
fw_cache.state = FW_LOADER_NO_CACHE;
mutex_unlock(&fw_lock);
- enable_firmware();
device_uncache_fw_images_delay(10 * MSEC_PER_SEC);
break;
@@ -1886,7 +1790,6 @@ static void __init fw_cache_init(void)
static int fw_shutdown_notify(struct notifier_block *unused1,
unsigned long unused2, void *unused3)
{
- disable_firmware();
/*
* Kill all pending fallback requests to avoid both stalling shutdown,
* and avoid a deadlock with the usermode_lock.
@@ -1902,7 +1805,6 @@ static struct notifier_block fw_shutdown
static int __init firmware_class_init(void)
{
- enable_firmware();
fw_cache_init();
register_reboot_notifier(&fw_shutdown_nb);
#ifdef CONFIG_FW_LOADER_USER_HELPER
@@ -1914,7 +1816,6 @@ static int __init firmware_class_init(vo
static void __exit firmware_class_exit(void)
{
- disable_firmware();
#ifdef CONFIG_PM_SLEEP
unregister_syscore_ops(&fw_syscore_ops);
unregister_pm_notifier(&fw_cache.pm_notify);
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Zyngier <[email protected]>
commit 95696d292e204073433ed2ef3ff4d3d8f42a8248 upstream.
The GIC-500 integrated in the Armada-37xx SoCs is compliant with
the GICv3 architecture, and thus provides a maintenance interrupt
that is required for hypervisors to function correctly.
With the interrupt provided in the DT, KVM now works as it should.
Tested on an Espressobin system.
Fixes: adbc3695d9e4 ("arm64: dts: add the Marvell Armada 3700 family and a development board")
Signed-off-by: Marc Zyngier <[email protected]>
Signed-off-by: Gregory CLEMENT <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -323,6 +323,7 @@
interrupt-controller;
reg = <0x1d00000 0x10000>, /* GICD */
<0x1d40000 0x40000>; /* GICR */
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
};
};
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Seri <[email protected]>
commit e860d2c904d1a9f38a24eb44c9f34b8f915a6ea3 upstream.
Validate the output buffer length for L2CAP config requests and responses
to avoid overflowing the stack buffer used for building the option blocks.
Signed-off-by: Ben Seri <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/bluetooth/l2cap_core.c | 80 ++++++++++++++++++++++++---------------------
1 file changed, 43 insertions(+), 37 deletions(-)
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -58,7 +58,7 @@ static struct sk_buff *l2cap_build_cmd(s
u8 code, u8 ident, u16 dlen, void *data);
static void l2cap_send_cmd(struct l2cap_conn *conn, u8 ident, u8 code, u16 len,
void *data);
-static int l2cap_build_conf_req(struct l2cap_chan *chan, void *data);
+static int l2cap_build_conf_req(struct l2cap_chan *chan, void *data, size_t data_size);
static void l2cap_send_disconn_req(struct l2cap_chan *chan, int err);
static void l2cap_tx(struct l2cap_chan *chan, struct l2cap_ctrl *control,
@@ -1473,7 +1473,7 @@ static void l2cap_conn_start(struct l2ca
set_bit(CONF_REQ_SENT, &chan->conf_state);
l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
- l2cap_build_conf_req(chan, buf), buf);
+ l2cap_build_conf_req(chan, buf, sizeof(buf)), buf);
chan->num_conf_req++;
}
@@ -2987,12 +2987,15 @@ static inline int l2cap_get_conf_opt(voi
return len;
}
-static void l2cap_add_conf_opt(void **ptr, u8 type, u8 len, unsigned long val)
+static void l2cap_add_conf_opt(void **ptr, u8 type, u8 len, unsigned long val, size_t size)
{
struct l2cap_conf_opt *opt = *ptr;
BT_DBG("type 0x%2.2x len %u val 0x%lx", type, len, val);
+ if (size < L2CAP_CONF_OPT_SIZE + len)
+ return;
+
opt->type = type;
opt->len = len;
@@ -3017,7 +3020,7 @@ static void l2cap_add_conf_opt(void **pt
*ptr += L2CAP_CONF_OPT_SIZE + len;
}
-static void l2cap_add_opt_efs(void **ptr, struct l2cap_chan *chan)
+static void l2cap_add_opt_efs(void **ptr, struct l2cap_chan *chan, size_t size)
{
struct l2cap_conf_efs efs;
@@ -3045,7 +3048,7 @@ static void l2cap_add_opt_efs(void **ptr
}
l2cap_add_conf_opt(ptr, L2CAP_CONF_EFS, sizeof(efs),
- (unsigned long) &efs);
+ (unsigned long) &efs, size);
}
static void l2cap_ack_timeout(struct work_struct *work)
@@ -3191,11 +3194,12 @@ static inline void l2cap_txwin_setup(str
chan->ack_win = chan->tx_win;
}
-static int l2cap_build_conf_req(struct l2cap_chan *chan, void *data)
+static int l2cap_build_conf_req(struct l2cap_chan *chan, void *data, size_t data_size)
{
struct l2cap_conf_req *req = data;
struct l2cap_conf_rfc rfc = { .mode = chan->mode };
void *ptr = req->data;
+ void *endptr = data + data_size;
u16 size;
BT_DBG("chan %p", chan);
@@ -3220,7 +3224,7 @@ static int l2cap_build_conf_req(struct l
done:
if (chan->imtu != L2CAP_DEFAULT_MTU)
- l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, chan->imtu);
+ l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, chan->imtu, endptr - ptr);
switch (chan->mode) {
case L2CAP_MODE_BASIC:
@@ -3239,7 +3243,7 @@ done:
rfc.max_pdu_size = 0;
l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC, sizeof(rfc),
- (unsigned long) &rfc);
+ (unsigned long) &rfc, endptr - ptr);
break;
case L2CAP_MODE_ERTM:
@@ -3259,21 +3263,21 @@ done:
L2CAP_DEFAULT_TX_WINDOW);
l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC, sizeof(rfc),
- (unsigned long) &rfc);
+ (unsigned long) &rfc, endptr - ptr);
if (test_bit(FLAG_EFS_ENABLE, &chan->flags))
- l2cap_add_opt_efs(&ptr, chan);
+ l2cap_add_opt_efs(&ptr, chan, endptr - ptr);
if (test_bit(FLAG_EXT_CTRL, &chan->flags))
l2cap_add_conf_opt(&ptr, L2CAP_CONF_EWS, 2,
- chan->tx_win);
+ chan->tx_win, endptr - ptr);
if (chan->conn->feat_mask & L2CAP_FEAT_FCS)
if (chan->fcs == L2CAP_FCS_NONE ||
test_bit(CONF_RECV_NO_FCS, &chan->conf_state)) {
chan->fcs = L2CAP_FCS_NONE;
l2cap_add_conf_opt(&ptr, L2CAP_CONF_FCS, 1,
- chan->fcs);
+ chan->fcs, endptr - ptr);
}
break;
@@ -3291,17 +3295,17 @@ done:
rfc.max_pdu_size = cpu_to_le16(size);
l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC, sizeof(rfc),
- (unsigned long) &rfc);
+ (unsigned long) &rfc, endptr - ptr);
if (test_bit(FLAG_EFS_ENABLE, &chan->flags))
- l2cap_add_opt_efs(&ptr, chan);
+ l2cap_add_opt_efs(&ptr, chan, endptr - ptr);
if (chan->conn->feat_mask & L2CAP_FEAT_FCS)
if (chan->fcs == L2CAP_FCS_NONE ||
test_bit(CONF_RECV_NO_FCS, &chan->conf_state)) {
chan->fcs = L2CAP_FCS_NONE;
l2cap_add_conf_opt(&ptr, L2CAP_CONF_FCS, 1,
- chan->fcs);
+ chan->fcs, endptr - ptr);
}
break;
}
@@ -3312,10 +3316,11 @@ done:
return ptr - data;
}
-static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data)
+static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data, size_t data_size)
{
struct l2cap_conf_rsp *rsp = data;
void *ptr = rsp->data;
+ void *endptr = data + data_size;
void *req = chan->conf_req;
int len = chan->conf_len;
int type, hint, olen;
@@ -3417,7 +3422,7 @@ done:
return -ECONNREFUSED;
l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC, sizeof(rfc),
- (unsigned long) &rfc);
+ (unsigned long) &rfc, endptr - ptr);
}
if (result == L2CAP_CONF_SUCCESS) {
@@ -3430,7 +3435,7 @@ done:
chan->omtu = mtu;
set_bit(CONF_MTU_DONE, &chan->conf_state);
}
- l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, chan->omtu);
+ l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, chan->omtu, endptr - ptr);
if (remote_efs) {
if (chan->local_stype != L2CAP_SERV_NOTRAFIC &&
@@ -3444,7 +3449,7 @@ done:
l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS,
sizeof(efs),
- (unsigned long) &efs);
+ (unsigned long) &efs, endptr - ptr);
} else {
/* Send PENDING Conf Rsp */
result = L2CAP_CONF_PENDING;
@@ -3477,7 +3482,7 @@ done:
set_bit(CONF_MODE_DONE, &chan->conf_state);
l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC,
- sizeof(rfc), (unsigned long) &rfc);
+ sizeof(rfc), (unsigned long) &rfc, endptr - ptr);
if (test_bit(FLAG_EFS_ENABLE, &chan->flags)) {
chan->remote_id = efs.id;
@@ -3491,7 +3496,7 @@ done:
le32_to_cpu(efs.sdu_itime);
l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS,
sizeof(efs),
- (unsigned long) &efs);
+ (unsigned long) &efs, endptr - ptr);
}
break;
@@ -3505,7 +3510,7 @@ done:
set_bit(CONF_MODE_DONE, &chan->conf_state);
l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC, sizeof(rfc),
- (unsigned long) &rfc);
+ (unsigned long) &rfc, endptr - ptr);
break;
@@ -3527,10 +3532,11 @@ done:
}
static int l2cap_parse_conf_rsp(struct l2cap_chan *chan, void *rsp, int len,
- void *data, u16 *result)
+ void *data, size_t size, u16 *result)
{
struct l2cap_conf_req *req = data;
void *ptr = req->data;
+ void *endptr = data + size;
int type, olen;
unsigned long val;
struct l2cap_conf_rfc rfc = { .mode = L2CAP_MODE_BASIC };
@@ -3548,13 +3554,13 @@ static int l2cap_parse_conf_rsp(struct l
chan->imtu = L2CAP_DEFAULT_MIN_MTU;
} else
chan->imtu = val;
- l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, chan->imtu);
+ l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, chan->imtu, endptr - ptr);
break;
case L2CAP_CONF_FLUSH_TO:
chan->flush_to = val;
l2cap_add_conf_opt(&ptr, L2CAP_CONF_FLUSH_TO,
- 2, chan->flush_to);
+ 2, chan->flush_to, endptr - ptr);
break;
case L2CAP_CONF_RFC:
@@ -3568,13 +3574,13 @@ static int l2cap_parse_conf_rsp(struct l
chan->fcs = 0;
l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC,
- sizeof(rfc), (unsigned long) &rfc);
+ sizeof(rfc), (unsigned long) &rfc, endptr - ptr);
break;
case L2CAP_CONF_EWS:
chan->ack_win = min_t(u16, val, chan->ack_win);
l2cap_add_conf_opt(&ptr, L2CAP_CONF_EWS, 2,
- chan->tx_win);
+ chan->tx_win, endptr - ptr);
break;
case L2CAP_CONF_EFS:
@@ -3587,7 +3593,7 @@ static int l2cap_parse_conf_rsp(struct l
return -ECONNREFUSED;
l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs),
- (unsigned long) &efs);
+ (unsigned long) &efs, endptr - ptr);
break;
case L2CAP_CONF_FCS:
@@ -3692,7 +3698,7 @@ void __l2cap_connect_rsp_defer(struct l2
return;
l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
- l2cap_build_conf_req(chan, buf), buf);
+ l2cap_build_conf_req(chan, buf, sizeof(buf)), buf);
chan->num_conf_req++;
}
@@ -3900,7 +3906,7 @@ sendresp:
u8 buf[128];
set_bit(CONF_REQ_SENT, &chan->conf_state);
l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
- l2cap_build_conf_req(chan, buf), buf);
+ l2cap_build_conf_req(chan, buf, sizeof(buf)), buf);
chan->num_conf_req++;
}
@@ -3978,7 +3984,7 @@ static int l2cap_connect_create_rsp(stru
break;
l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
- l2cap_build_conf_req(chan, req), req);
+ l2cap_build_conf_req(chan, req, sizeof(req)), req);
chan->num_conf_req++;
break;
@@ -4090,7 +4096,7 @@ static inline int l2cap_config_req(struc
}
/* Complete config. */
- len = l2cap_parse_conf_req(chan, rsp);
+ len = l2cap_parse_conf_req(chan, rsp, sizeof(rsp));
if (len < 0) {
l2cap_send_disconn_req(chan, ECONNRESET);
goto unlock;
@@ -4124,7 +4130,7 @@ static inline int l2cap_config_req(struc
if (!test_and_set_bit(CONF_REQ_SENT, &chan->conf_state)) {
u8 buf[64];
l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
- l2cap_build_conf_req(chan, buf), buf);
+ l2cap_build_conf_req(chan, buf, sizeof(buf)), buf);
chan->num_conf_req++;
}
@@ -4184,7 +4190,7 @@ static inline int l2cap_config_rsp(struc
char buf[64];
len = l2cap_parse_conf_rsp(chan, rsp->data, len,
- buf, &result);
+ buf, sizeof(buf), &result);
if (len < 0) {
l2cap_send_disconn_req(chan, ECONNRESET);
goto done;
@@ -4214,7 +4220,7 @@ static inline int l2cap_config_rsp(struc
/* throw out any old stored conf requests */
result = L2CAP_CONF_SUCCESS;
len = l2cap_parse_conf_rsp(chan, rsp->data, len,
- req, &result);
+ req, sizeof(req), &result);
if (len < 0) {
l2cap_send_disconn_req(chan, ECONNRESET);
goto done;
@@ -4791,7 +4797,7 @@ static void l2cap_do_create(struct l2cap
set_bit(CONF_REQ_SENT, &chan->conf_state);
l2cap_send_cmd(chan->conn, l2cap_get_ident(chan->conn),
L2CAP_CONF_REQ,
- l2cap_build_conf_req(chan, buf), buf);
+ l2cap_build_conf_req(chan, buf, sizeof(buf)), buf);
chan->num_conf_req++;
}
}
@@ -7465,7 +7471,7 @@ static void l2cap_security_cfm(struct hc
set_bit(CONF_REQ_SENT, &chan->conf_state);
l2cap_send_cmd(conn, l2cap_get_ident(conn),
L2CAP_CONF_REQ,
- l2cap_build_conf_req(chan, buf),
+ l2cap_build_conf_req(chan, buf, sizeof(buf)),
buf);
chan->num_conf_req++;
}
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanislaw Gruszka <[email protected]>
commit 83ec489193894e52bd395eec470f4f7c4286d4a5 upstream.
Since commit 41977e86c984 ("rt2x00: add support for MT7620") we do not
initialize TX_PIN_CFG setting. This cause breakage at least on some
RT3573 devices. To fix the problem patch restores previous behaviour
for non MT7620 chips.
Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1480829
Reported-and-tested-by: Jussi Eloranta <[email protected]>
Cc: Daniel Golle <[email protected]>
Signed-off-by: Stanislaw Gruszka <[email protected]>
Acked-by: Daniel Golle <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -3702,7 +3702,10 @@ static void rt2800_config_channel(struct
if (rt2x00_rt(rt2x00dev, RT3572))
rt2800_rfcsr_write(rt2x00dev, 8, 0);
- tx_pin = rt2800_register_read(rt2x00dev, TX_PIN_CFG);
+ if (rt2x00_rt(rt2x00dev, RT6352))
+ tx_pin = rt2800_register_read(rt2x00dev, TX_PIN_CFG);
+ else
+ tx_pin = 0;
switch (rt2x00dev->default_ant.tx_chain_num) {
case 3:
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Laurent Dufour <[email protected]>
commit de0c799bba2610a8e1e9a50d76a28614520a4cd4 upstream.
Seen while reading the code, in handle_mm_fault(), in the case
arch_vma_access_permitted() is failing the call to
mem_cgroup_oom_disable() is not made.
To fix that, move the call to mem_cgroup_oom_enable() after calling
arch_vma_access_permitted() as it should not have entered the memcg OOM.
Link: http://lkml.kernel.org/r/[email protected]
Fixes: bae473a423f6 ("mm: introduce fault_env")
Signed-off-by: Laurent Dufour <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/memory.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3888,6 +3888,11 @@ int handle_mm_fault(struct vm_area_struc
/* do counter updates before entering really critical section. */
check_sync_rss_stat(current);
+ if (!arch_vma_access_permitted(vma, flags & FAULT_FLAG_WRITE,
+ flags & FAULT_FLAG_INSTRUCTION,
+ flags & FAULT_FLAG_REMOTE))
+ return VM_FAULT_SIGSEGV;
+
/*
* Enable the memcg OOM handling for faults triggered in user
* space. Kernel faults are handled more gracefully.
@@ -3895,11 +3900,6 @@ int handle_mm_fault(struct vm_area_struc
if (flags & FAULT_FLAG_USER)
mem_cgroup_oom_enable();
- if (!arch_vma_access_permitted(vma, flags & FAULT_FLAG_WRITE,
- flags & FAULT_FLAG_INSTRUCTION,
- flags & FAULT_FLAG_REMOTE))
- return VM_FAULT_SIGSEGV;
-
if (unlikely(is_vm_hugetlb_page(vma)))
ret = hugetlb_fault(vma->vm_mm, vma, address, flags);
else
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 23d98c204386a98d9ef9f9e744f41443ece4929f upstream.
Those are funny cases. Make sure they work.
(Something is screwy with signal handling if a selector is 1, 2, or 3.
Anyone who wants to dive into that rabbit hole is welcome to do so.)
Signed-off-by: Andy Lutomirski <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: Chang Seok <[email protected]>
Cc: Denys Vlasenko <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Josh Poimboeuf <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/testing/selftests/x86/fsgsbase.c | 41 ++++++++++++++++++++++++++++-----
1 file changed, 35 insertions(+), 6 deletions(-)
--- a/tools/testing/selftests/x86/fsgsbase.c
+++ b/tools/testing/selftests/x86/fsgsbase.c
@@ -285,9 +285,12 @@ static void *threadproc(void *ctx)
}
}
-static void set_gs_and_switch_to(unsigned long local, unsigned long remote)
+static void set_gs_and_switch_to(unsigned long local,
+ unsigned short force_sel,
+ unsigned long remote)
{
unsigned long base;
+ unsigned short sel_pre_sched, sel_post_sched;
bool hard_zero = false;
if (local == HARD_ZERO) {
@@ -297,6 +300,8 @@ static void set_gs_and_switch_to(unsigne
printf("[RUN]\tARCH_SET_GS(0x%lx)%s, then schedule to 0x%lx\n",
local, hard_zero ? " and clear gs" : "", remote);
+ if (force_sel)
+ printf("\tBefore schedule, set selector to 0x%hx\n", force_sel);
if (syscall(SYS_arch_prctl, ARCH_SET_GS, local) != 0)
err(1, "ARCH_SET_GS");
if (hard_zero)
@@ -307,18 +312,35 @@ static void set_gs_and_switch_to(unsigne
printf("[FAIL]\tGSBASE wasn't set as expected\n");
}
+ if (force_sel) {
+ asm volatile ("mov %0, %%gs" : : "rm" (force_sel));
+ sel_pre_sched = force_sel;
+ local = read_base(GS);
+
+ /*
+ * Signal delivery seems to mess up weird selectors. Put it
+ * back.
+ */
+ asm volatile ("mov %0, %%gs" : : "rm" (force_sel));
+ } else {
+ asm volatile ("mov %%gs, %0" : "=rm" (sel_pre_sched));
+ }
+
remote_base = remote;
ftx = 1;
syscall(SYS_futex, &ftx, FUTEX_WAKE, 0, NULL, NULL, 0);
while (ftx != 0)
syscall(SYS_futex, &ftx, FUTEX_WAIT, 1, NULL, NULL, 0);
+ asm volatile ("mov %%gs, %0" : "=rm" (sel_post_sched));
base = read_base(GS);
- if (base == local) {
- printf("[OK]\tGSBASE remained 0x%lx\n", local);
+ if (base == local && sel_pre_sched == sel_post_sched) {
+ printf("[OK]\tGS/BASE remained 0x%hx/0x%lx\n",
+ sel_pre_sched, local);
} else {
nerrs++;
- printf("[FAIL]\tGSBASE changed to 0x%lx\n", base);
+ printf("[FAIL]\tGS/BASE changed from 0x%hx/0x%lx to 0x%hx/0x%lx\n",
+ sel_pre_sched, local, sel_post_sched, base);
}
}
@@ -381,8 +403,15 @@ int main()
for (int local = 0; local < 4; local++) {
for (int remote = 0; remote < 4; remote++) {
- set_gs_and_switch_to(bases_with_hard_zero[local],
- bases_with_hard_zero[remote]);
+ for (unsigned short s = 0; s < 5; s++) {
+ unsigned short sel = s;
+ if (s == 4)
+ asm ("mov %%ss, %0" : "=rm" (sel));
+ set_gs_and_switch_to(
+ bases_with_hard_zero[local],
+ sel,
+ bases_with_hard_zero[remote]);
+ }
}
}
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Hocko <[email protected]>
commit b4ccec41af82b5a5518c6534444412961894f07c upstream.
online_mem_sections() accidentally marks online only the first section
in the given range. This is a typo which hasn't been noticed because I
haven't tested large 2GB blocks previously. All users of
pfn_to_online_page would get confused on the the rest of the pfn range
in the block.
All we need to fix this is to use iterator (pfn) rather than start_pfn.
Link: http://lkml.kernel.org/r/[email protected]
Fixes: 2d070eab2e82 ("mm: consider zone which is not fully populated to have holes")
Signed-off-by: Michal Hocko <[email protected]>
Acked-by: Vlastimil Babka <[email protected]>
Cc: Anshuman Khandual <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/sparse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -630,7 +630,7 @@ void online_mem_sections(unsigned long s
unsigned long pfn;
for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
- unsigned long section_nr = pfn_to_section_nr(start_pfn);
+ unsigned long section_nr = pfn_to_section_nr(pfn);
struct mem_section *ms;
/* onlining code should never touch invalid ranges */
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Darrick J. Wong <[email protected]>
commit 8606a1a94da5c4e49c0fb28af62d2e75c6747716 upstream.
If initializing a small swap file fails because the swap file has a
problem (holes, etc.) then we need to free the cluster info as part of
cleanup. Unfortunately a previous patch changed the code to use kvzalloc
but did not change all the vfree calls to use kvfree.
Found by running generic/357 from xfstests.
Link: http://lkml.kernel.org/r/20170831233515.GR3775@magnolia
Fixes: 54f180d3c181 ("mm, swap: use kvzalloc to allocate some swap data structures")
Signed-off-by: Darrick J. Wong <[email protected]>
Reviewed-by: "Huang, Ying" <[email protected]>
Acked-by: David Rientjes <[email protected]>
Cc: Hugh Dickins <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/swapfile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -3052,7 +3052,7 @@ bad_swap:
p->flags = 0;
spin_unlock(&swap_lock);
vfree(swap_map);
- vfree(cluster_info);
+ kvfree(cluster_info);
if (swap_file) {
if (inode && S_ISREG(inode->i_mode)) {
inode_unlock(inode);
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
commit 14abcb0bf59a30cf65a74f6c6f53974cd7224bc6 upstream.
There are a number of callers of nfs_pageio_complete() that want to
continue using the nfs_pageio_descriptor without needing to call
nfs_pageio_init() again. Examples include nfs_pageio_resend() and
nfs_pageio_cond_complete().
The problem is that nfs_pageio_complete() also calls
nfs_pageio_cleanup_mirroring(), which frees up the array of mirrors.
This can lead to writeback errors, in the next call to
nfs_pageio_setup_mirroring().
Fix by simply moving the allocation of the mirrors to
nfs_pageio_setup_mirroring().
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196709
Reported-by: JianhongYin <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nfs/pagelist.c | 73 ++++++++++++++++++++++++++++--------------------------
1 file changed, 39 insertions(+), 34 deletions(-)
--- a/fs/nfs/pagelist.c
+++ b/fs/nfs/pagelist.c
@@ -712,9 +712,6 @@ void nfs_pageio_init(struct nfs_pageio_d
int io_flags,
gfp_t gfp_flags)
{
- struct nfs_pgio_mirror *new;
- int i;
-
desc->pg_moreio = 0;
desc->pg_inode = inode;
desc->pg_ops = pg_ops;
@@ -730,21 +727,9 @@ void nfs_pageio_init(struct nfs_pageio_d
desc->pg_mirror_count = 1;
desc->pg_mirror_idx = 0;
- if (pg_ops->pg_get_mirror_count) {
- /* until we have a request, we don't have an lseg and no
- * idea how many mirrors there will be */
- new = kcalloc(NFS_PAGEIO_DESCRIPTOR_MIRROR_MAX,
- sizeof(struct nfs_pgio_mirror), gfp_flags);
- desc->pg_mirrors_dynamic = new;
- desc->pg_mirrors = new;
-
- for (i = 0; i < NFS_PAGEIO_DESCRIPTOR_MIRROR_MAX; i++)
- nfs_pageio_mirror_init(&desc->pg_mirrors[i], bsize);
- } else {
- desc->pg_mirrors_dynamic = NULL;
- desc->pg_mirrors = desc->pg_mirrors_static;
- nfs_pageio_mirror_init(&desc->pg_mirrors[0], bsize);
- }
+ desc->pg_mirrors_dynamic = NULL;
+ desc->pg_mirrors = desc->pg_mirrors_static;
+ nfs_pageio_mirror_init(&desc->pg_mirrors[0], bsize);
}
EXPORT_SYMBOL_GPL(nfs_pageio_init);
@@ -863,32 +848,52 @@ static int nfs_generic_pg_pgios(struct n
return ret;
}
+static struct nfs_pgio_mirror *
+nfs_pageio_alloc_mirrors(struct nfs_pageio_descriptor *desc,
+ unsigned int mirror_count)
+{
+ struct nfs_pgio_mirror *ret;
+ unsigned int i;
+
+ kfree(desc->pg_mirrors_dynamic);
+ desc->pg_mirrors_dynamic = NULL;
+ if (mirror_count == 1)
+ return desc->pg_mirrors_static;
+ ret = kmalloc_array(mirror_count, sizeof(*ret), GFP_NOFS);
+ if (ret != NULL) {
+ for (i = 0; i < mirror_count; i++)
+ nfs_pageio_mirror_init(&ret[i], desc->pg_bsize);
+ desc->pg_mirrors_dynamic = ret;
+ }
+ return ret;
+}
+
/*
* nfs_pageio_setup_mirroring - determine if mirroring is to be used
* by calling the pg_get_mirror_count op
*/
-static int nfs_pageio_setup_mirroring(struct nfs_pageio_descriptor *pgio,
+static void nfs_pageio_setup_mirroring(struct nfs_pageio_descriptor *pgio,
struct nfs_page *req)
{
- int mirror_count = 1;
-
- if (!pgio->pg_ops->pg_get_mirror_count)
- return 0;
+ unsigned int mirror_count = 1;
- mirror_count = pgio->pg_ops->pg_get_mirror_count(pgio, req);
-
- if (pgio->pg_error < 0)
- return pgio->pg_error;
-
- if (!mirror_count || mirror_count > NFS_PAGEIO_DESCRIPTOR_MIRROR_MAX)
- return -EINVAL;
+ if (pgio->pg_ops->pg_get_mirror_count)
+ mirror_count = pgio->pg_ops->pg_get_mirror_count(pgio, req);
+ if (mirror_count == pgio->pg_mirror_count || pgio->pg_error < 0)
+ return;
- if (WARN_ON_ONCE(!pgio->pg_mirrors_dynamic))
- return -EINVAL;
+ if (!mirror_count || mirror_count > NFS_PAGEIO_DESCRIPTOR_MIRROR_MAX) {
+ pgio->pg_error = -EINVAL;
+ return;
+ }
+ pgio->pg_mirrors = nfs_pageio_alloc_mirrors(pgio, mirror_count);
+ if (pgio->pg_mirrors == NULL) {
+ pgio->pg_error = -ENOMEM;
+ pgio->pg_mirrors = pgio->pg_mirrors_static;
+ mirror_count = 1;
+ }
pgio->pg_mirror_count = mirror_count;
-
- return 0;
}
/*
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: [email protected] <[email protected]>
commit e973b1a5999e57da677ab50da5f5479fdc0f0c31 upstream.
Since commit 18290650b1c8 ("NFS: Move buffered I/O locking into
nfs_file_write()") nfs_file_write() has not flushed the correct byte
range during synchronous writes. generic_write_sync() expects that
iocb->ki_pos points to the right edge of the range rather than the
left edge.
To replicate the problem, open a file with O_DSYNC, have the client
write at increasing offsets, and then print the successful offsets.
Block port 2049 partway through that sequence, and observe that the
client application indicates successful writes in advance of what the
server received.
Fixes: 18290650b1c8 ("NFS: Move buffered I/O locking into nfs_file_write()")
Signed-off-by: Jacob Strauss <[email protected]>
Signed-off-by: Tarang Gupta <[email protected]>
Tested-by: Tarang Gupta <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nfs/file.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@ -631,11 +631,11 @@ ssize_t nfs_file_write(struct kiocb *ioc
if (result <= 0)
goto out;
- result = generic_write_sync(iocb, result);
- if (result < 0)
- goto out;
written = result;
iocb->ki_pos += written;
+ result = generic_write_sync(iocb, written);
+ if (result < 0)
+ goto out;
/* Return error values */
if (nfs_need_check_write(file, inode)) {
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
commit 746a272e44141af24a02f6c9b0f65f4c4598ed42 upstream.
When there's a fatal signal pending, arm's do_page_fault()
implementation returns 0. The intent is that we'll return to the
faulting userspace instruction, delivering the signal on the way.
However, if we take a fatal signal during fixing up a uaccess, this
results in a return to the faulting kernel instruction, which will be
instantly retried, resulting in the same fault being taken forever. As
the task never reaches userspace, the signal is not delivered, and the
task is left unkillable. While the task is stuck in this state, it can
inhibit the forward progress of the system.
To avoid this, we must ensure that when a fatal signal is pending, we
apply any necessary fixup for a faulting kernel instruction. Thus we
will return to an error path, and it is up to that code to make forward
progress towards delivering the fatal signal.
Signed-off-by: Mark Rutland <[email protected]>
Reviewed-by: Steve Capper <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/mm/fault.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -315,8 +315,11 @@ retry:
* signal first. We do not need to release the mmap_sem because
* it would already be released in __lock_page_or_retry in
* mm/filemap.c. */
- if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+ if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
+ if (!user_mode(regs))
+ goto no_context;
return 0;
+ }
/*
* Major/minor page fault accounting is only done on the
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larry Finger <[email protected]>
commit a33fcba6ec01efcca33b1afad91057020f247f15 upstream.
In commit bcd37f4a0831 ("rtlwifi: btcoex: 23b 2ant: let bt transmit when
hw initialisation done"), there is an additional error when the module
parameter ant_sel is used to select the auxilary antenna. The error is
that the antenna selection is not checked when writing the antenna
selection register.
Fixes: bcd37f4a0831 ("rtlwifi: btcoex: 23b 2ant: let bt transmit when hw initialisation done")
Signed-off-by: Larry Finger <[email protected]>
Cc: Ping-Ke Shih <[email protected]>
Cc: Yan-Hsuan Chuang <[email protected]>
Cc: Birming Chiu <[email protected]>
Cc: Shaofu <[email protected]>
Cc: Steven Ting <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
@@ -1183,7 +1183,10 @@ static void btc8723b2ant_set_ant_path(st
}
/* fixed internal switch S1->WiFi, S0->BT */
- btcoexist->btc_write_4byte(btcoexist, 0x948, 0x0);
+ if (board_info->btdm_ant_pos == BTC_ANTENNA_AT_MAIN_PORT)
+ btcoexist->btc_write_2byte(btcoexist, 0x948, 0x0);
+ else
+ btcoexist->btc_write_2byte(btcoexist, 0x948, 0x280);
switch (antpos_type) {
case BTC_ANT_WIFI_AT_MAIN:
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Verkamp <[email protected]>
commit 40a5fce495715c48c2e02668144e68a507ac5a30 upstream.
The default host NQN, which is generated based on the host's UUID,
does not follow the UUID-based NQN format laid out in the NVMe 1.3
specification. Remove the "NVMf:" portion of the NQN to match the spec.
Signed-off-by: Daniel Verkamp <[email protected]>
Reviewed-by: Max Gurtovoy <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/nvme/host/fabrics.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/nvme/host/fabrics.c
+++ b/drivers/nvme/host/fabrics.c
@@ -75,7 +75,7 @@ static struct nvmf_host *nvmf_host_defau
kref_init(&host->ref);
snprintf(host->nqn, NVMF_NQN_SIZE,
- "nqn.2014-08.org.nvmexpress:NVMf:uuid:%pUb", &host->id);
+ "nqn.2014-08.org.nvmexpress:uuid:%pUb", &host->id);
mutex_lock(&nvmf_hosts_mutex);
list_add_tail(&host->list, &nvmf_hosts);
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Abhishek Sahu <[email protected]>
commit 10777de570016471fd929869c7830a7772893e39 upstream.
The configuration for BCH is not correct in the current driver.
The ECC_CFG_ECC_DISABLE bit defines whether to enable or disable the
BCH ECC in which
0x1 : BCH_DISABLED
0x0 : BCH_ENABLED
But currently host->bch_enabled is being assigned to BCH_DISABLED.
Fixes: c76b78d8ec05a ("mtd: nand: Qualcomm NAND controller driver")
Signed-off-by: Abhishek Sahu <[email protected]>
Reviewed-by: Archit Taneja <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mtd/nand/qcom_nandc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -1900,7 +1900,7 @@ static int qcom_nand_host_setup(struct q
| wide_bus << WIDE_FLASH
| 1 << DEV0_CFG1_ECC_DISABLE;
- host->ecc_bch_cfg = host->bch_enabled << ECC_CFG_ECC_DISABLE
+ host->ecc_bch_cfg = !host->bch_enabled << ECC_CFG_ECC_DISABLE
| 0 << ECC_SW_RESET
| host->cw_data << ECC_NUM_DATA_BYTES
| 1 << ECC_FORCE_CLK_OPEN
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boris Brezillon <[email protected]>
commit 3bff08dffe3115a25ce04b95ea75f6d868572c60 upstream.
Commit a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops")
introduced a bug in the OOB layout description. Even if the driver claims
that 3 ECC bytes are reserved to protect 512 bytes of data, it's actually
5 ECC bytes to protect 512+6 bytes of data (some OOB bytes are also
protected using extra ECC bytes).
Fix the mxc_v1_ooblayout_{free,ecc}() functions to reflect this behavior.
Signed-off-by: Boris Brezillon <[email protected]>
Fixes: a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops")
Signed-off-by: Boris Brezillon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mtd/nand/mxc_nand.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/mtd/nand/mxc_nand.c
+++ b/drivers/mtd/nand/mxc_nand.c
@@ -876,6 +876,8 @@ static void mxc_do_addr_cycle(struct mtd
}
}
+#define MXC_V1_ECCBYTES 5
+
static int mxc_v1_ooblayout_ecc(struct mtd_info *mtd, int section,
struct mtd_oob_region *oobregion)
{
@@ -885,7 +887,7 @@ static int mxc_v1_ooblayout_ecc(struct m
return -ERANGE;
oobregion->offset = (section * 16) + 6;
- oobregion->length = nand_chip->ecc.bytes;
+ oobregion->length = MXC_V1_ECCBYTES;
return 0;
}
@@ -907,8 +909,7 @@ static int mxc_v1_ooblayout_free(struct
oobregion->length = 4;
}
} else {
- oobregion->offset = ((section - 1) * 16) +
- nand_chip->ecc.bytes + 6;
+ oobregion->offset = ((section - 1) * 16) + MXC_V1_ECCBYTES + 6;
if (section < nand_chip->ecc.steps)
oobregion->length = (section * 16) + 6 -
oobregion->offset;
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ian W MORRISON <[email protected]>
commit f957dd3c8db2781c8a334b166800788feb618625 upstream.
The firmware feature check introduced for multi-scheduled scan is also
failing for bcm4345 devices resulting in a firmware crash.
The reason for this crash has not yet been root cause so this patch avoids
the feature check for those device as a short-term fix.
Fixes: 9fe929aaace6 ("brcmfmac: add firmware feature detection for gscan feature")
Signed-off-by: Ian W MORRISON <[email protected]>
Acked-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
@@ -159,7 +159,8 @@ void brcmf_feat_attach(struct brcmf_pub
brcmf_feat_firmware_capabilities(ifp);
memset(&gscan_cfg, 0, sizeof(gscan_cfg));
- if (drvr->bus_if->chip != BRCM_CC_43430_CHIP_ID)
+ if (drvr->bus_if->chip != BRCM_CC_43430_CHIP_ID &&
+ drvr->bus_if->chip != BRCM_CC_4345_CHIP_ID)
brcmf_feat_iovar_data_set(ifp, BRCMF_FEAT_GSCAN,
"pfn_gscan_cfg",
&gscan_cfg, sizeof(gscan_cfg));
On Tue, Sep 12, 2017 at 10:00:00AM -0700, Greg Kroah-Hartman wrote:
> 4.13-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Linus Torvalds <[email protected]>
>
> commit f007cad159e99fa2acd3b2e9364fbb32ad28b971 upstream.
>
> This reverts commit 81f95076281fdd3bc382e004ba1bce8e82fccbce.
I'm not convinced reverting this commit is the right thing to do at
this point given it would seem other errors were happening prior to
v4.13 and this commit would rather just bring to light the core of
the issue which needs to be addressed.
If reverting this commit please consider reverting also commit
06a45a93e7d34a ("firmware: move umh try locks into the umh code").
> It causes random failures of firmware loading at resume time (well,
> random for me, it seems to be more reliable for others)
That randomness is expected, as well as the old issues without this
commit and commit 06a45a93e7d34a. By removing this commit though we
should also be introducing another vector of possible issues though,
and I'm afraid that it may be hard to predict when they were caused
by a race issue on resume.
> because the
> firmware disabling is not actually synchronous with any particular
> resume event, and at least the btusb driver that uses a workqueue to
> load the firmware at resume seems to occasionally hit the "firmware
> loading is disabled" logic because the firmware loader hasn't gotten the
> resume event yet.
It would seem that without these commits the issue was present also:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1356076
These commits just bring forward the issues closer to attention. They
have my attention now and I am looking at a clean way to address it
with Marcel.
> Some kind of sanity check for not trying to load firmware when it's not
> possible might be a good thing, but this commit was not it.
>
> Greg seems to have silently suffered the same issue, and pointed to the
> likely culprit, and Gabriel C verified the revert fixed it for him too.
If testing against old behaviour the right way would be to also revert
commit 06a45a93e7d34a ("firmware: move umh try locks into the umh code").
Luis
>
> Reported-by: Linus Torvalds <[email protected]>
> Pointed-at-by: Greg Kroah-Hartman <[email protected]>
> Tested-by: Gabriel C <[email protected]>
> Cc: Luis R. Rodriguez <[email protected]>
> Signed-off-by: Linus Torvalds <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> ---
> Documentation/driver-api/firmware/request_firmware.rst | 11 -
> drivers/base/firmware_class.c | 99 -----------------
> 2 files changed, 110 deletions(-)
>
> --- a/Documentation/driver-api/firmware/request_firmware.rst
> +++ b/Documentation/driver-api/firmware/request_firmware.rst
> @@ -44,17 +44,6 @@ request_firmware_nowait
> .. kernel-doc:: drivers/base/firmware_class.c
> :functions: request_firmware_nowait
>
> -Considerations for suspend and resume
> -=====================================
> -
> -During suspend and resume only the built-in firmware and the firmware cache
> -elements of the firmware API can be used. This is managed by fw_pm_notify().
> -
> -fw_pm_notify
> -------------
> -.. kernel-doc:: drivers/base/firmware_class.c
> - :functions: fw_pm_notify
> -
> request firmware API expected driver use
> ========================================
>
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -256,38 +256,6 @@ static int fw_cache_piggyback_on_request
> * guarding for corner cases a global lock should be OK */
> static DEFINE_MUTEX(fw_lock);
>
> -static bool __enable_firmware = false;
> -
> -static void enable_firmware(void)
> -{
> - mutex_lock(&fw_lock);
> - __enable_firmware = true;
> - mutex_unlock(&fw_lock);
> -}
> -
> -static void disable_firmware(void)
> -{
> - mutex_lock(&fw_lock);
> - __enable_firmware = false;
> - mutex_unlock(&fw_lock);
> -}
> -
> -/*
> - * When disabled only the built-in firmware and the firmware cache will be
> - * used to look for firmware.
> - */
> -static bool firmware_enabled(void)
> -{
> - bool enabled = false;
> -
> - mutex_lock(&fw_lock);
> - if (__enable_firmware)
> - enabled = true;
> - mutex_unlock(&fw_lock);
> -
> - return enabled;
> -}
> -
> static struct firmware_cache fw_cache;
>
> static struct firmware_buf *__allocate_fw_buf(const char *fw_name,
> @@ -1239,12 +1207,6 @@ _request_firmware(const struct firmware
> if (ret <= 0) /* error or already assigned */
> goto out;
>
> - if (!firmware_enabled()) {
> - WARN(1, "firmware request while host is not available\n");
> - ret = -EHOSTDOWN;
> - goto out;
> - }
> -
> ret = fw_get_filesystem_firmware(device, fw->priv);
> if (ret) {
> if (!(opt_flags & FW_OPT_NO_WARN))
> @@ -1755,62 +1717,6 @@ static void device_uncache_fw_images_del
> msecs_to_jiffies(delay));
> }
>
> -/**
> - * fw_pm_notify - notifier for suspend/resume
> - * @notify_block: unused
> - * @mode: mode we are switching to
> - * @unused: unused
> - *
> - * Used to modify the firmware_class state as we move in between states.
> - * The firmware_class implements a firmware cache to enable device driver
> - * to fetch firmware upon resume before the root filesystem is ready. We
> - * disable API calls which do not use the built-in firmware or the firmware
> - * cache when we know these calls will not work.
> - *
> - * The inner logic behind all this is a bit complex so it is worth summarizing
> - * the kernel's own suspend/resume process with context and focus on how this
> - * can impact the firmware API.
> - *
> - * First a review on how we go to suspend::
> - *
> - * pm_suspend() --> enter_state() -->
> - * sys_sync()
> - * suspend_prepare() -->
> - * __pm_notifier_call_chain(PM_SUSPEND_PREPARE, ...);
> - * suspend_freeze_processes() -->
> - * freeze_processes() -->
> - * __usermodehelper_set_disable_depth(UMH_DISABLED);
> - * freeze all tasks ...
> - * freeze_kernel_threads()
> - * suspend_devices_and_enter() -->
> - * dpm_suspend_start() -->
> - * dpm_prepare()
> - * dpm_suspend()
> - * suspend_enter() -->
> - * platform_suspend_prepare()
> - * dpm_suspend_late()
> - * freeze_enter()
> - * syscore_suspend()
> - *
> - * When we resume we bail out of a loop from suspend_devices_and_enter() and
> - * unwind back out to the caller enter_state() where we were before as follows::
> - *
> - * enter_state() -->
> - * suspend_devices_and_enter() --> (bail from loop)
> - * dpm_resume_end() -->
> - * dpm_resume()
> - * dpm_complete()
> - * suspend_finish() -->
> - * suspend_thaw_processes() -->
> - * thaw_processes() -->
> - * __usermodehelper_set_disable_depth(UMH_FREEZING);
> - * thaw_workqueues();
> - * thaw all processes ...
> - * usermodehelper_enable();
> - * pm_notifier_call_chain(PM_POST_SUSPEND);
> - *
> - * fw_pm_notify() works through pm_notifier_call_chain().
> - */
> static int fw_pm_notify(struct notifier_block *notify_block,
> unsigned long mode, void *unused)
> {
> @@ -1824,7 +1730,6 @@ static int fw_pm_notify(struct notifier_
> */
> kill_pending_fw_fallback_reqs(true);
> device_cache_fw_images();
> - disable_firmware();
> break;
>
> case PM_POST_SUSPEND:
> @@ -1837,7 +1742,6 @@ static int fw_pm_notify(struct notifier_
> mutex_lock(&fw_lock);
> fw_cache.state = FW_LOADER_NO_CACHE;
> mutex_unlock(&fw_lock);
> - enable_firmware();
>
> device_uncache_fw_images_delay(10 * MSEC_PER_SEC);
> break;
> @@ -1886,7 +1790,6 @@ static void __init fw_cache_init(void)
> static int fw_shutdown_notify(struct notifier_block *unused1,
> unsigned long unused2, void *unused3)
> {
> - disable_firmware();
> /*
> * Kill all pending fallback requests to avoid both stalling shutdown,
> * and avoid a deadlock with the usermode_lock.
> @@ -1902,7 +1805,6 @@ static struct notifier_block fw_shutdown
>
> static int __init firmware_class_init(void)
> {
> - enable_firmware();
> fw_cache_init();
> register_reboot_notifier(&fw_shutdown_nb);
> #ifdef CONFIG_FW_LOADER_USER_HELPER
> @@ -1914,7 +1816,6 @@ static int __init firmware_class_init(vo
>
> static void __exit firmware_class_exit(void)
> {
> - disable_firmware();
> #ifdef CONFIG_PM_SLEEP
> unregister_syscore_ops(&fw_syscore_ops);
> unregister_pm_notifier(&fw_cache.pm_notify);
>
>
>
--
Luis Rodriguez, SUSE LINUX GmbH
Maxfeldstrasse 5; D-90409 Nuernberg
On 09/12/2017 10:59 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.13.2 release.
> There are 27 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Sep 14 16:52:56 UTC 2017.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.13.2-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.13.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
On Tue, Sep 12, 2017 at 07:20:08PM +0200, Luis R. Rodriguez wrote:
> On Tue, Sep 12, 2017 at 10:00:00AM -0700, Greg Kroah-Hartman wrote:
> > 4.13-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Linus Torvalds <[email protected]>
> >
> > commit f007cad159e99fa2acd3b2e9364fbb32ad28b971 upstream.
> >
> > This reverts commit 81f95076281fdd3bc382e004ba1bce8e82fccbce.
>
> I'm not convinced reverting this commit is the right thing to do at
> this point given it would seem other errors were happening prior to
> v4.13 and this commit would rather just bring to light the core of
> the issue which needs to be addressed.
Given that this fixes a reported regression, yes, it is the right thing
to do.
> If reverting this commit please consider reverting also commit
> 06a45a93e7d34a ("firmware: move umh try locks into the umh code").
Ok, I can queue that revert up in my tree and will send it to Linus once
4.14-rc1 is out.
thanks,
greg k-h
On Tue, Sep 12, 2017 at 06:13:32PM -0600, Shuah Khan wrote:
> On 09/12/2017 10:59 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.13.2 release.
> > There are 27 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu Sep 14 16:52:56 UTC 2017.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.13.2-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.13.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Compiled and booted on my test system. No dmesg regressions.
Thanks for testing these and letting me know.
greg k-h
On Tue, Sep 12, 2017 at 03:57:50PM -0700, kernelci.org bot wrote:
> stable-rc/linux-4.13.y boot: 210 boots: 7 failed, 200 passed with 3 conflicts (v4.13.1-28-g0a9a7505477b)
7 failures here, and 8 for 4.12, are these to be expected?
thanks,
greg k-h
On Tue, Sep 12, 2017 at 05:47:58PM -0700, Greg Kroah-Hartman wrote:
> On Tue, Sep 12, 2017 at 07:20:08PM +0200, Luis R. Rodriguez wrote:
> > On Tue, Sep 12, 2017 at 10:00:00AM -0700, Greg Kroah-Hartman wrote:
> > > 4.13-stable review patch. If anyone has any objections, please let me know.
> > >
> > > ------------------
> > >
> > > From: Linus Torvalds <[email protected]>
> > >
> > > commit f007cad159e99fa2acd3b2e9364fbb32ad28b971 upstream.
> > >
> > > This reverts commit 81f95076281fdd3bc382e004ba1bce8e82fccbce.
> >
> > I'm not convinced reverting this commit is the right thing to do at
> > this point given it would seem other errors were happening prior to
> > v4.13 and this commit would rather just bring to light the core of
> > the issue which needs to be addressed.
>
> Given that this fixes a reported regression, yes, it is the right thing
> to do.
Once 06a45a93e7d34a is also reverted I believe it may be revealed this was
not a regression after all.
> > If reverting this commit please consider reverting also commit
> > 06a45a93e7d34a ("firmware: move umh try locks into the umh code").
>
> Ok, I can queue that revert up in my tree and will send it to Linus once
> 4.14-rc1 is out.
But lets find out.
Luis
On Wed, Sep 13, 2017 at 03:22:52AM +0200, Luis R. Rodriguez wrote:
> On Tue, Sep 12, 2017 at 05:47:58PM -0700, Greg Kroah-Hartman wrote:
> > On Tue, Sep 12, 2017 at 07:20:08PM +0200, Luis R. Rodriguez wrote:
> > > On Tue, Sep 12, 2017 at 10:00:00AM -0700, Greg Kroah-Hartman wrote:
> > > > 4.13-stable review patch. If anyone has any objections, please let me know.
> > > >
> > > > ------------------
> > > >
> > > > From: Linus Torvalds <[email protected]>
> > > >
> > > > commit f007cad159e99fa2acd3b2e9364fbb32ad28b971 upstream.
> > > >
> > > > This reverts commit 81f95076281fdd3bc382e004ba1bce8e82fccbce.
> > >
> > > I'm not convinced reverting this commit is the right thing to do at
> > > this point given it would seem other errors were happening prior to
> > > v4.13 and this commit would rather just bring to light the core of
> > > the issue which needs to be addressed.
> >
> > Given that this fixes a reported regression, yes, it is the right thing
> > to do.
>
> Once 06a45a93e7d34a is also reverted I believe it may be revealed this was
> not a regression after all.
Then we will put it back :)
On Tue, Sep 12, 2017 at 5:47 PM, Greg Kroah-Hartman
<[email protected]> wrote:
>
>> If reverting this commit please consider reverting also commit
>> 06a45a93e7d34a ("firmware: move umh try locks into the umh code").
>
> Ok, I can queue that revert up in my tree and will send it to Linus once
> 4.14-rc1 is out.
I want to see a _reason_ for that revert. The two have absolutely
nothing to do with each other., Reverting one is *not* a reason for
reverting the other.
Commit 06a45a93e7d34a seems to be a cleanup. The arguments in
06a45a93e7d3 ("firmware: move umh try locks into the umh code") seem
valid, and there's no real reason to worry about that FW_OPT_NOWAIT
etc for the direct-from-filesystem loading. That's simply not
sensible.
That whole FW_OPT_NOWAIT thing only makes sense for the actual
user-mode helper, so that commit actually seems to move the testing
and the logic to a place that really does make sense.
So why would we revert a commit that makes SENSE?
In contrast, the commit that already got reverted, added random
locking state logic associated with a callback that didn't actually
make any sense in that context.
Honestly, what we need here is less "let's do random changes", and
more "have actual reasons for those changes".
For example, I'm the first to tell people that they shouldn't just try
to load firmware from random contexts. If you're bringing up a device,
loading firmware might depend on *another* device that hasn't been
brought up yet, and you might end up with essentially a deadlock
waiting for IO from another device that just isn't going to happen.
But we shouldn't fix that by then adding a flag that gets set
asynchronously by some random callback, and that then causes a
workqueue entry that *could* sleep to just fail. There's no "root
cause logic" there. That's the wrong kind of random change. There may
be a reason for it in some situation, but in another situation it just
fails for no good reason.
For example, what might be senseible is to add a warning that tries to
verify that people do *not* do firmware loads from the ->resume()
callbacks. But then it should literally check *that*: it could do
something like
WARN_ON_ONCE(current == resume_thread, "Firmware loading
called synchronously during resume");
or whatever, exactly because it's obviously *not* ok to block the same
process that is going to resume all the other devices that might be
*needed* for the firmware loading.
But on the other hand, if somebody then does an independent thread to
resume their firmware, we could just block to wait for it - it
wouldn't be the same kind of chicken-and-egg issue with IO at resume
time.
So instead of "arbitrary rules", there should be things that actually
make sense.
The commit that Luis now argues for _also_ reverting makes a lot of
sense to me to keep. I'm not seeing why that should be reverted, when
the _only_ reason seems to be some spiteful "well, if you reverted one
commit, you should randomly revert another one too".
Linus
On Tue, Sep 12, 2017 at 09:59:40AM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.13.2 release.
> There are 27 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Sep 14 16:52:56 UTC 2017.
> Anything received after that time might be too late.
>
Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 122 pass: 122 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
Rafeal a question for you below.
On Tue, Sep 12, 2017 at 09:11:46PM -0700, Linus Torvalds wrote:
> On Tue, Sep 12, 2017 at 5:47 PM, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> >> If reverting this commit please consider reverting also commit
> >> 06a45a93e7d34a ("firmware: move umh try locks into the umh code").
> >
> > Ok, I can queue that revert up in my tree and will send it to Linus once
> > 4.14-rc1 is out.
>
> I want to see a _reason_ for that revert. The two have absolutely
> nothing to do with each other., Reverting one is *not* a reason for
> reverting the other.
There is a dependency between both commits, the reason is not obvious though.
I'll explain below.
> Commit 06a45a93e7d34a seems to be a cleanup. The arguments in
> 06a45a93e7d3 ("firmware: move umh try locks into the umh code") seem
> valid, and there's no real reason to worry about that FW_OPT_NOWAIT
> etc for the direct-from-filesystem loading. That's simply not
> sensible.
Indeed! That stupid UMH lock *seems* wrong on the direct filesystem path!
Hence these changes.
The devil is in the details though. That UMH lock however carried an implicit
suspend guard, the "cleanup" actually then has a functional change. The commit
which was reverted provided the safe guard in generic form, in case we already
had become dependent on the suspend guard. This UMH lock on the direct FS path
then added an implicit "arbitrary rule", as you put it, on the firmware API.
Commit 81f95076281fd clarified and made it explicit just to be safe.
*Only* carrying 06a45a93e7d34a then was a long term goal, eventually I intended
to remove the code which you removed, but I would have preferred to have waited
at least a release.
By only having 06a45a93e7d34a we then loose the suspend guard from the direct
FS lookup path immediately. If we're happy to live with that right away then
great, this may be one of those *random arbitrary rules* inherited worth
removing, it was a long term goal to remove that code, however I just want
folks to be very well aware of the original goal: 06a45a93e7d34a without
81f95076281fd is not a cleanup, there is a hidden functional change there.
So to be clear: I'm happy with 81f95076281fd reverted as it was my long term
goal, however I would not be doing my job if I were not explaining that
06a45a93e7d34a *has* a functional change and that 81f95076281fd was an
attempt at a safe baby step forward.
> That whole FW_OPT_NOWAIT thing only makes sense for the actual
> user-mode helper, so that commit actually seems to move the testing
> and the logic to a place that really does make sense.
Indeed!
> So why would we revert a commit that makes SENSE?
Because although the UMH lock should only be used for code which needs the UMH
helpers, the UMH lock also had added a suspend guard which we grew to rely on.
Removing it could mean allowing races on resume, and there was no clear way
generically detecting this. The UMH lock was *also* never used on *any other*
UMH code, so from the UMH perspective it also begs the question if the other
UMH code is error prone as it lacks the safe UMH locking safe guards.
> For example, what might be senseible is to add a warning that tries to
> verify that people do *not* do firmware loads from the ->resume()
> callbacks.
The firmware API *allows* for resume() callbacks to use the firmware API in
ways which *should* not block much if any at all, however they must have first
at least called the firmware API once so that the device gets a devres entry
with a string associated; this is the firmware cache. Then upon suspend the
firmware API requests for each of these firmwares. If a resume() callback then
calls the firmware API for any of these files it would work without issue as
the firmware is loaded in the cache, as simple pointer reference. Processing
and consuming the firmware on the driver though *can* take a while and block
longer.
Because of the firmware cache implementation then we needed a whitelist, so the
check which I implemented in 81f95076281fd *only* complains if we've passed the
firmware cache check, and we *know* then the incoming call is new.
> But then it should literally check *that*: it could do
> something like
>
> WARN_ON_ONCE(current == resume_thread, "Firmware loading
> called synchronously during resume");
Sure that would be *much* smaller code.
Rafael do you have helpers for this sort of thing or are OK with them being
added?
> or whatever, exactly because it's obviously *not* ok to block the same
> process that is going to resume all the other devices that might be
> *needed* for the firmware loading.
Your interest in this seems to be the blocking implications on synchronous
calls. That's certainly a new concern I had not heard raised yet and is
worthwhile addressing. Are you not concerned in any way though about the
filesystem being ready?
> But on the other hand, if somebody then does an independent thread to
> resume their firmware, we could just block to wait for it - it
> wouldn't be the same kind of chicken-and-egg issue with IO at resume
> time.
>
> So instead of "arbitrary rules", there should be things that actually
> make sense.
The arbitrary rule here was hidden underneath code Rafael added years ago.
I'm pretty sure he did not intend to add the check on the direct FS path
as direct FS path came later as the code evolved, *but* we kept the lock
on the direct FS path so we have no option but to review carefully its
removal.
> The commit that Luis now argues for _also_ reverting makes a lot of
> sense to me to keep. I'm not seeing why that should be reverted, when
> the _only_ reason seems to be some spiteful "well, if you reverted one
> commit, you should randomly revert another one too".
I hope to have clarified there is no spite here, I'm simply being very
careful to avoid a regression with a real hidden functional change.
Luis
On Wed, Sep 13, 2017 at 07:35:06AM -0700, Guenter Roeck wrote:
> On Tue, Sep 12, 2017 at 09:59:40AM -0700, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.13.2 release.
> > There are 27 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu Sep 14 16:52:56 UTC 2017.
> > Anything received after that time might be too late.
> >
> Build results:
> total: 145 pass: 145 fail: 0
> Qemu test results:
> total: 122 pass: 122 fail: 0
>
> Details are available at http://kerneltests.org/builders.
Thanks for testing all of these and letting me know.
greg k-h
On Wed, Sep 13, 2017 at 11:38 AM, Luis R. Rodriguez <[email protected]> wrote:
>> Commit 06a45a93e7d34a seems to be a cleanup. The arguments in
>> 06a45a93e7d3 ("firmware: move umh try locks into the umh code") seem
>> valid, and there's no real reason to worry about that FW_OPT_NOWAIT
>> etc for the direct-from-filesystem loading. That's simply not
>> sensible.
>
> Indeed! That stupid UMH lock *seems* wrong on the direct filesystem path!
>
> Hence these changes.
>
> The devil is in the details though. That UMH lock however carried an implicit
> suspend guard, the "cleanup" actually then has a functional change. The commit
> which was reverted provided the safe guard in generic form, in case we already
> had become dependent on the suspend guard. This UMH lock on the direct FS path
> then added an implicit "arbitrary rule", as you put it, on the firmware API.
I still refuse to revert a commit "just because".
It improved the code.
There is no actual sign that it causes problems.
Yes, moving the lock may change behavior, but nothing you say actually
makes me think it regressed anything.
I refuse to do this "let's just go back to what we used to have,
without an actual _reason_ to go back to it".
The old user-mode-helper crap was crap that had its own totally
separate issues. Even without the problems that we had with incredibly
bad maintainership of the user mode side, the usermode helper had
serious issues with just the fact that user mode itself is disabled by
the suspend/resume process.
So getting rid of the locking that was added for usermode helper ion
the direct file loading path makes a lot of sense.
Just saying that "we tried to re-introduce that locking in another
form, and that was a mistake, and got reverted" is *not* a reason to
then revert the movement.
Yes, the movement of the locking might need to be reverted too - but
only if it actually shows problems.
We should *not* go back to old code "just because".
Linus
On Wed, Sep 13, 2017 at 12:30:44PM -0700, Linus Torvalds wrote:
> Yes, the movement of the locking might need to be reverted too - but
> only if it actually shows problems.
This speeds up the cleanup of that crap UMH code so I'm happy to
wait to hear if just the move the UMH lock it creates an issue.
I suspect it wont.
Luis
Greg Kroah-Hartman <[email protected]> writes:
> On Tue, Sep 12, 2017 at 03:57:50PM -0700, kernelci.org bot wrote:
>> stable-rc/linux-4.13.y boot: 210 boots: 7 failed, 200 passed with 3 conflicts (v4.13.1-28-g0a9a7505477b)
>
> 7 failures here, and 8 for 4.12, are these to be expected?
They are expected in the sense that nobody seems to care about the
defconfigs that are failing, so nobody is looking into the failures.
Since almost all of these failures seem to be related to various
defconfnig + kconfig-fragment builds that nobody is taking the time to
fix, I'm going reduce the set of defconfig that are built for stable
trees to just the in-tree defconfigs.
That should greatly reduce the signal-to-noise for these stable
reports. We can then add back defconfigs as needed, on the condition
that someone has the time/energy to keep those configs working in stable
trees.
Kevin