From: Johannes Berg <johannes.berg(a)intel.com>
Before deleting a time event (remain-on-channel instance), flush
the queue so that frames cannot get stuck on it. We already flush
the AUX STA queues, but a separate station is used for the P2P
Device queue.
Cc: stable(a)vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 2 ++
.../net/wireless/intel/iwlwifi/mvm/time-event.c | 24 ++++++++++++++++++++--
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index 6a9a25beab3f..55ab5349dd40 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -1061,6 +1061,7 @@ struct iwl_mvm {
* @IWL_MVM_STATUS_ROC_AUX_RUNNING: AUX remain-on-channel is running
* @IWL_MVM_STATUS_D3_RECONFIG: D3 reconfiguration is being done
* @IWL_MVM_STATUS_FIRMWARE_RUNNING: firmware is running
+ * @IWL_MVM_STATUS_NEED_FLUSH_P2P: need to flush P2P bcast STA
*/
enum iwl_mvm_status {
IWL_MVM_STATUS_HW_RFKILL,
@@ -1072,6 +1073,7 @@ enum iwl_mvm_status {
IWL_MVM_STATUS_ROC_AUX_RUNNING,
IWL_MVM_STATUS_D3_RECONFIG,
IWL_MVM_STATUS_FIRMWARE_RUNNING,
+ IWL_MVM_STATUS_NEED_FLUSH_P2P,
};
/* Keep track of completed init configuration */
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c b/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c
index 4d0314912e94..e25cda9fbf6c 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c
@@ -132,6 +132,24 @@ void iwl_mvm_roc_done_wk(struct work_struct *wk)
* executed, and a new time event means a new command.
*/
iwl_mvm_flush_sta(mvm, &mvm->aux_sta, true, CMD_ASYNC);
+
+ /* Do the same for the P2P device queue (STA) */
+ if (test_and_clear_bit(IWL_MVM_STATUS_NEED_FLUSH_P2P, &mvm->status)) {
+ struct iwl_mvm_vif *mvmvif;
+
+ /*
+ * NB: access to this pointer would be racy, but the flush bit
+ * can only be set when we had a P2P-Device VIF, and we have a
+ * flush of this work in iwl_mvm_prepare_mac_removal() so it's
+ * not really racy.
+ */
+
+ if (!WARN_ON(!mvm->p2p_device_vif)) {
+ mvmvif = iwl_mvm_vif_from_mac80211(mvm->p2p_device_vif);
+ iwl_mvm_flush_sta(mvm, &mvmvif->bcast_sta, true,
+ CMD_ASYNC);
+ }
+ }
}
static void iwl_mvm_roc_finished(struct iwl_mvm *mvm)
@@ -855,10 +873,12 @@ void iwl_mvm_stop_roc(struct iwl_mvm *mvm)
mvmvif = iwl_mvm_vif_from_mac80211(te_data->vif);
- if (te_data->vif->type == NL80211_IFTYPE_P2P_DEVICE)
+ if (te_data->vif->type == NL80211_IFTYPE_P2P_DEVICE) {
iwl_mvm_remove_time_event(mvm, mvmvif, te_data);
- else
+ set_bit(IWL_MVM_STATUS_NEED_FLUSH_P2P, &mvm->status);
+ } else {
iwl_mvm_remove_aux_roc_te(mvm, mvmvif, te_data);
+ }
iwl_mvm_roc_finished(mvm);
}
--
2.15.0
xHC can generate two events for a short transfer if the short TRB and
last TRB in the TD are not the same TRB.
The driver will handle the TD after the first short event, and remove
it from its internal list. Driver then incorrectly prints a warning
for the second event:
"WARN Event TRB for slot x ep y with no TDs queued"
Fix this by not printing a warning if we get a event on a empty list
if the previous event was a short event.
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
---
drivers/usb/host/xhci-ring.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index c239c68..6eb87c6 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2477,12 +2477,16 @@ static int handle_tx_event(struct xhci_hcd *xhci,
*/
if (list_empty(&ep_ring->td_list)) {
/*
- * A stopped endpoint may generate an extra completion
- * event if the device was suspended. Don't print
- * warnings.
+ * Don't print wanings if it's due to a stopped endpoint
+ * generating an extra completion event if the device
+ * was suspended. Or, a event for the last TRB of a
+ * short TD we already got a short event for.
+ * The short TD is already removed from the TD list.
*/
+
if (!(trb_comp_code == COMP_STOPPED ||
- trb_comp_code == COMP_STOPPED_LENGTH_INVALID)) {
+ trb_comp_code == COMP_STOPPED_LENGTH_INVALID ||
+ ep_ring->last_td_was_short)) {
xhci_warn(xhci, "WARN Event TRB for slot %d ep %d with no TDs queued?\n",
TRB_TO_SLOT_ID(le32_to_cpu(event->flags)),
ep_index);
--
2.7.4
The commit de3ee99b097d ("mmc: Delete bounce buffer handling") deletes the
bounce buffer handling, but also causes the max_req_size for sdhci to be
increased, in case when max_segs == 1. This causes errors for sdhci-pci
Ricoh variant, about the swiotlb buffer to become full.
Fix the issue, by taking IO_TLB_SEGSIZE and IO_TLB_SHIFT into account when
deciding the max_req_size for sdhci.
Reported-by: Jiri Slaby <jslaby(a)suse.cz>
Fixes: de3ee99b097d ("mmc: Delete bounce buffer handling")
Cc: <stable(a)vger.kernel.org> # v4.14+
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Tested-by: Jiri Slaby <jslaby(a)suse.cz>
---
drivers/mmc/host/sdhci.c | 28 ++++++++++++++++++----------
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 2f14334..e9290a3 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -21,6 +21,7 @@
#include <linux/dma-mapping.h>
#include <linux/slab.h>
#include <linux/scatterlist.h>
+#include <linux/swiotlb.h>
#include <linux/regulator/consumer.h>
#include <linux/pm_runtime.h>
#include <linux/of.h>
@@ -3651,22 +3652,29 @@ int sdhci_setup_host(struct sdhci_host *host)
spin_lock_init(&host->lock);
/*
+ * Maximum number of sectors in one transfer. Limited by SDMA boundary
+ * size (512KiB). Note some tuning modes impose a 4MiB limit, but this
+ * is less anyway.
+ */
+ mmc->max_req_size = 524288;
+
+ /*
* Maximum number of segments. Depends on if the hardware
* can do scatter/gather or not.
*/
- if (host->flags & SDHCI_USE_ADMA)
+ if (host->flags & SDHCI_USE_ADMA) {
mmc->max_segs = SDHCI_MAX_SEGS;
- else if (host->flags & SDHCI_USE_SDMA)
+ } else if (host->flags & SDHCI_USE_SDMA) {
mmc->max_segs = 1;
- else /* PIO */
+ if (swiotlb_max_segment()) {
+ unsigned int max_req_size = (1 << IO_TLB_SHIFT) *
+ IO_TLB_SEGSIZE;
+ mmc->max_req_size = min(mmc->max_req_size,
+ max_req_size);
+ }
+ } else { /* PIO */
mmc->max_segs = SDHCI_MAX_SEGS;
-
- /*
- * Maximum number of sectors in one transfer. Limited by SDMA boundary
- * size (512KiB). Note some tuning modes impose a 4MiB limit, but this
- * is less anyway.
- */
- mmc->max_req_size = 524288;
+ }
/*
* Maximum segment size. Could be one segment with the maximum number
--
2.7.4
BCM43341 devices soldered onto the PCB (non-removable) always (AFAICT)
use an UART connection for bluetooth. But they also advertise btsdio
support on their 3th sdio function, this causes 2 problems:
1) A non functioning BT HCI getting registered
2) Since the btsdio driver does not have suspend/resume callbacks,
mmc_sdio_pre_suspend will return -ENOSYS, causing mmc_pm_notify()
to react as if the SDIO-card is removed and since the slot is
marked as non-removable it will never get detected as inserted again.
Which results in wifi no longer working after a suspend/resume.
This commit fixes both by making btsdio ignore BCM43341 devices
when connected to a slot which is marked non-removable.
Cc: stable(a)vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/bluetooth/btsdio.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/bluetooth/btsdio.c b/drivers/bluetooth/btsdio.c
index c8e945d19ffe..76c1405c7242 100644
--- a/drivers/bluetooth/btsdio.c
+++ b/drivers/bluetooth/btsdio.c
@@ -31,6 +31,7 @@
#include <linux/errno.h>
#include <linux/skbuff.h>
+#include <linux/mmc/host.h>
#include <linux/mmc/sdio_ids.h>
#include <linux/mmc/sdio_func.h>
@@ -292,6 +293,15 @@ static int btsdio_probe(struct sdio_func *func,
tuple = tuple->next;
}
+ /*
+ * BCM43341 devices soldered onto the PCB (non-removable) use an
+ * uart connection for bluetooth, ignore the BT SDIO interface.
+ */
+ if (func->vendor == SDIO_VENDOR_ID_BROADCOM &&
+ func->device == SDIO_DEVICE_ID_BROADCOM_43341 &&
+ !mmc_card_is_removable(func->card->host))
+ return -ENODEV;
+
data = devm_kzalloc(&func->dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
--
2.14.3
SMSM is not symmetrical, the incoming bits from WCNSS are available at
index 6, but the outgoing host id for WCNSS is 3. Further more, upstream
references the base of APCS (in contrast to downstream), so the register
offset of 8 must be included.
Fixes: 1fb47e0a9ba4 ("arm64: dts: qcom: msm8916: Add smsm and smp2p nodes")
Cc: stable(a)vger.kernel.org
Reported-by: Ramon Fried <rfried(a)codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org>
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 9fb317853a5c..a8e1e3b4562c 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -1437,8 +1437,8 @@
#address-cells = <1>;
#size-cells = <0>;
- qcom,ipc-1 = <&apcs 0 13>;
- qcom,ipc-6 = <&apcs 0 19>;
+ qcom,ipc-1 = <&apcs 8 13>;
+ qcom,ipc-3 = <&apcs 8 19>;
apps_smsm: apps@0 {
reg = <0>;
--
2.15.0
Hi Greg,
At 10/05/2017 04:30 PM, gregkh(a)linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> x86/acpi: Restore the order of CPU IDs
>
> 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…
>
Dao found a bug in Linux 4.9 LTS which shows below.
The reason of the bug is that we just backport the patch titled
x86/acpi: Restore the order of CPU IDs
but, ignored the other patches in the series[1].
IMO, the commit c962cff17dfa
("Revert "x86/acpi: Set persistent cpuid <-> nodeid mapping when
booting"")
in the series can fixed this bug. I suggest to backport it.
BTW, I read the rules in Documentation/process/stable-kernel-rules.rst,
and found that:
...
- It cannot be bigger than 100 lines, with context.
...
I guess it seems that it's the reason why it did not be pulled in
stable tree. Is it right? Can you tell more details about it. :-)
[1] https://lkml.org/lkml/2017/3/3/71
Thanks,
dou.
...
[ 3.210401] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 3.219161] IP: [<ffffffffa5e77158>] __queue_work+0x78/0x420
[ 3.225491] PGD 0 [ 3.227537]
[ 3.229205] Oops: 0000 [#1] SMP
[ 3.232707] Modules linked in:
[ 3.236124] CPU: 25 PID: 1 Comm: swapper/0 Not tainted
4.9.59-cloudflare-2017.10.3 #1
[ 3.244857] Hardware name: IBM x3630M4 -[7158OCN]-/00KF922, BIOS
-[BEE142AUS-1.71]- 07/30/2014
[ 3.254461] task: ffff8dc2b2281e00 task.stack: ffffaa348c474000
[ 3.261068] RIP: 0010:[<ffffffffa5e77158>] [<ffffffffa5e77158>]
__queue_work+0x78/0x420
[ 3.270112] RSP: 0000:ffffaa348c477cb0 EFLAGS: 00010046
[ 3.276039] RAX: 0000000000000000 RBX: 0000000000000000 RCX:
0000000000000000
[ 3.284002] RDX: ffff8dc2b0272000 RSI: 000000007fffffff RDI:
ffff8dc2b0272000
[ 3.291965] RBP: ffffaa348c477ce8 R08: 000000000001b3a0 R09:
ffff8dc2be807840
[ 3.299929] R10: 0000000000ffff0a R11: 0000000000000003 R12:
ffff8dc2b0272000
[ 3.307894] R13: 0000000000000200 R14: ffff8dc2be8a2000 R15:
0000000000013198
[ 3.315857] FS: 0000000000000000(0000) GS:ffff8dc2bf440000(0000)
knlGS:0000000000000000
[ 3.324890] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.331301] CR2: 0000000000000000 CR3: 00000001a2c07000 CR4:
00000000001406e0
[ 3.339264] Stack:
[ 3.341505] ffff8dc2afcea000 0000001900000800 0000000000000246
0000000000000000
[ 3.349801] 0000000000000000 ffffffffa686bdbd ffff8dc2b13e39c0
ffffaa348c477d00
[ 3.358094] ffffffffa5e77519 ffff8dc2b0272000 ffffaa348c477d40
ffffffffa5e73eae
[ 3.366390] Call Trace:
[ 3.369121] [<ffffffffa5e77519>] queue_work_on+0x19/0x30
[ 3.375146] [<ffffffffa5e73eae>] call_usermodehelper_exec+0x7e/0x130
[ 3.382337] [<ffffffffa6242157>] kobject_uevent_env+0x4b7/0x510
[ 3.389033] [<ffffffffa62421bb>] kobject_uevent+0xb/0x10
[ 3.395058] [<ffffffffa62416e9>] kset_register+0x59/0x70
[ 3.401086] [<ffffffffa63268b0>] bus_register+0xd0/0x260
[ 3.407114] [<ffffffffa6bdd7bf>] ? acpi_int340x_thermal_init+0x12/0x12
[ 3.414496] [<ffffffffa6bdd7cf>] pnp_init+0x10/0x12
[ 3.420039] [<ffffffffa5e00440>] do_one_initcall+0x50/0x180
[ 3.426357] [<ffffffffa6b97077>] kernel_init_freeable+0x1a2/0x22a
[ 3.433258] [<ffffffffa655df40>] ? rest_init+0x80/0x80
[ 3.439089] [<ffffffffa655df4e>] kernel_init+0xe/0x100
[ 3.444921] [<ffffffffa6564da2>] ret_from_fork+0x22/0x30
[ 3.450945] Code: 00 00 41 f6 86 00 01 00 00 02 0f 85 ee 00 0
...
> The filename of the patch is:
> x86-acpi-restore-the-order-of-cpu-ids.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 foo@baz Thu Oct 5 10:28:31 CEST 2017
> From: Dou Liyang <douly.fnst(a)cn.fujitsu.com>
> Date: Fri, 3 Mar 2017 16:02:25 +0800
> Subject: x86/acpi: Restore the order of CPU IDs
>
> From: Dou Liyang <douly.fnst(a)cn.fujitsu.com>
>
>
> [ Upstream commit 2b85b3d22920db7473e5fed5719e7955c0ec323e ]
>
> The following commits:
>
> f7c28833c2 ("x86/acpi: Enable acpi to register all possible cpus at
> boot time") and 8f54969dc8 ("x86/acpi: Introduce persistent storage
> for cpuid <-> apicid mapping")
>
> ... registered all the possible CPUs at boot time via ACPI tables to
> make the mapping of cpuid <-> apicid fixed. Both enabled and disabled
> CPUs could have a logical CPU ID after boot time.
>
> But, ACPI tables are unreliable. the number amd order of Local APIC
> entries which depends on the firmware is often inconsistent with the
> physical devices. Even if they are consistent, The disabled CPUs which
> take up some logical CPU IDs will also make the order discontinuous.
>
> Revert the part of disabled CPUs registration, keep the allocation
> logic of logical CPU IDs and also keep some code location changes.
>
> Signed-off-by: Dou Liyang <douly.fnst(a)cn.fujitsu.com>
> Tested-by: Xiaolong Ye <xiaolong.ye(a)intel.com>
> Cc: rjw(a)rjwysocki.net
> Cc: linux-acpi(a)vger.kernel.org
> Cc: guzheng1(a)huawei.com
> Cc: izumi.taku(a)jp.fujitsu.com
> Cc: lenb(a)kernel.org
> Link: http://lkml.kernel.org/r/1488528147-2279-4-git-send-email-douly.fnst@cn.fuj…
> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
> ---
> arch/x86/kernel/acpi/boot.c | 7 ++++++-
> arch/x86/kernel/apic/apic.c | 26 +++++++-------------------
> 2 files changed, 13 insertions(+), 20 deletions(-)
>
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -176,10 +176,15 @@ static int acpi_register_lapic(int id, u
> return -EINVAL;
> }
>
> + if (!enabled) {
> + ++disabled_cpus;
> + return -EINVAL;
> + }
> +
> if (boot_cpu_physical_apicid != -1U)
> ver = boot_cpu_apic_version;
>
> - cpu = __generic_processor_info(id, ver, enabled);
> + cpu = generic_processor_info(id, ver);
> if (cpu >= 0)
> early_per_cpu(x86_cpu_to_acpiid, cpu) = acpiid;
>
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -2070,7 +2070,7 @@ static int allocate_logical_cpuid(int ap
> return nr_logical_cpuids++;
> }
>
> -int __generic_processor_info(int apicid, int version, bool enabled)
> +int generic_processor_info(int apicid, int version)
> {
> int cpu, max = nr_cpu_ids;
> bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid,
> @@ -2128,11 +2128,9 @@ int __generic_processor_info(int apicid,
> if (num_processors >= nr_cpu_ids) {
> int thiscpu = max + disabled_cpus;
>
> - if (enabled) {
> - pr_warning("APIC: NR_CPUS/possible_cpus limit of %i "
> - "reached. Processor %d/0x%x ignored.\n",
> - max, thiscpu, apicid);
> - }
> + pr_warning("APIC: NR_CPUS/possible_cpus limit of %i "
> + "reached. Processor %d/0x%x ignored.\n",
> + max, thiscpu, apicid);
>
> disabled_cpus++;
> return -EINVAL;
> @@ -2184,23 +2182,13 @@ int __generic_processor_info(int apicid,
> apic->x86_32_early_logical_apicid(cpu);
> #endif
> set_cpu_possible(cpu, true);
> -
> - if (enabled) {
> - num_processors++;
> - physid_set(apicid, phys_cpu_present_map);
> - set_cpu_present(cpu, true);
> - } else {
> - disabled_cpus++;
> - }
> + physid_set(apicid, phys_cpu_present_map);
> + set_cpu_present(cpu, true);
> + num_processors++;
>
> return cpu;
> }
>
> -int generic_processor_info(int apicid, int version)
> -{
> - return __generic_processor_info(apicid, version, true);
> -}
> -
> int hard_smp_processor_id(void)
> {
> return read_apic_id();
>
>
> Patches currently in stable-queue which might be from douly.fnst(a)cn.fujitsu.com are
>
> queue-4.9/x86-acpi-restore-the-order-of-cpu-ids.patch
>
>
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Greg,
Pleae pull commits for Linux 4.4 .
I've sent a review request for all commits over a week ago and all
comments were addressed.
Thanks,
Sasha
=====
The following changes since commit 08c15ad2e6278a5fe1b209e8fcdbd2d235c48f34:
Linux 4.4.103 (2017-11-30 08:37:28 +0000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git for-greg/4.14/4.4
for you to fetch changes up to 35875b21e77f03b5e0ce4278579294af69da5d00:
kprobes/x86: Disable preemption in ftrace-based jprobes (2017-11-30 16:49:32 -0500)
- ----------------------------------------------------------------
Aaron Sierra (1):
serial: 8250: Preserve DLD[7:4] for PORT_XR17V35X
Alexey Khoroshilov (1):
usb: phy: tahvo: fix error handling in tahvo_usb_probe()
Andy Lutomirski (1):
selftests/x86/ldt_get: Add a few additional tests for limits
Ben Hutchings (1):
usbip: tools: Install all headers needed for libusbip development
Boshi Wang (1):
ima: fix hash algorithm initialization
Christian Borntraeger (1):
s390/pci: do not require AIS facility
Dave Hansen (1):
x86/entry: Use SYSCALL_DEFINE() macros for sys_modify_ldt()
Gustavo A. R. Silva (1):
EDAC, sb_edac: Fix missing break in switch
Hiromitsu Yamasaki (1):
spi: sh-msiof: Fix DMA transfer size check
Jibin Xu (1):
sysrq : fix Show Regs call trace on ARM
John Stultz (2):
usb: dwc2: Fix UDC state tracking
usb: dwc2: Error out of dwc2_hsotg_ep_disable() if we're in host mode
Lukas Wunner (1):
serial: 8250_fintek: Fix rs485 disablement on invalid ioctl()
Masami Hiramatsu (1):
kprobes/x86: Disable preemption in ftrace-based jprobes
Thomas Richter (1):
perf test attr: Fix ignored test case result
arch/s390/include/asm/pci_insn.h | 2 +-
arch/s390/pci/pci.c | 5 +++--
arch/s390/pci/pci_insn.c | 6 +++++-
arch/x86/include/asm/syscalls.h | 2 +-
arch/x86/kernel/kprobes/ftrace.c | 23 ++++++++++++++---------
arch/x86/kernel/ldt.c | 16 +++++++++++++---
arch/x86/um/ldt.c | 7 +++++--
drivers/edac/sb_edac.c | 1 +
drivers/spi/spi-sh-msiof.c | 2 +-
drivers/tty/serial/8250/8250_fintek.c | 2 +-
drivers/tty/serial/8250/8250_port.c | 5 ++++-
drivers/tty/sysrq.c | 9 +++++++--
drivers/usb/dwc2/gadget.c | 7 +++++++
drivers/usb/phy/phy-tahvo.c | 3 ++-
security/integrity/ima/ima_main.c | 4 ++++
tools/perf/tests/attr.c | 2 +-
tools/testing/selftests/x86/ldt_gdt.c | 17 ++++++++++++++++-
tools/usb/usbip/Makefile.am | 3 ++-
18 files changed, 88 insertions(+), 28 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJaIH/+AAoJEN6mb/eXdyzcQQkP/j3Cdl+nqMgY28ui3xmFG/7N
rmTIjsIjS9lCPHH2i53jR518WPwKwte47k25FzOZi0kwdG2Q7Ds8N0jxJhs/rquU
lrz9T41bO7wihILHTFBOca185Mzf7elXF+VATP+dtVz51JnqvpL1vtZe29Wsv9We
WTuCdjnc9Sv6DP0DbctxQToUCc+SFT/DqOlgdTQfZJmhQAcNrCxmfzKjMJ48W38V
P4FgBdZ7I1pkaNIXWbzDB8XARzesdupFjMjACgTCQ/XdhodgdPwgssNMURX8uKC8
PIpbW8syYQPGmepLv7hiDoFgPKxDPgfSVQXgFIQkfFWXSMnnulI+sj7gi2F8u1fS
MVENj75UTBKL1RgbwFxuIZLRZKDcMi/RRjAdOxiMQWY5v0PWMnCwta1/CtGKnkBT
Wf1do7Lt0ce8sstd+udztNvfQToSBi47LMC/Sdn2GcXTCM1MTUUXiMHeybYLZR1+
Kpsjpj4Fc1CqIrelJUA78KpDpCpUb5osj8tnahx4pYmBp11V3G6jGQZYLPZDUxdU
0vpzAaeeVIRg2X17VB4zuDdLzVMrB0ChImRcXIDht7wuyMG2+vqKX7IB+Mit7yEQ
md6Benpeok44SSxlXKRrVz37ZlStxGSVIG+F1DTR4dE17N/4ZUNpKx/eXP8pFtlh
QVkzov+tpzlMNXSB1cg6
=BCzy
-----END PGP SIGNATURE-----
From: Sachin Sant <sachinp(a)linux.vnet.ibm.com>
[ Upstream commit a6d8a21596df041f36f4c2ccc260c459e3e851f1 ]
Tests under alignment subdirectory are skipped when executed on previous
generation hardware, but harness still marks them as failed.
test: test_copy_unaligned
tags: git_version:unknown
[SKIP] Test skipped on line 26
skip: test_copy_unaligned
selftests: copy_unaligned [FAIL]
The MAGIC_SKIP_RETURN_VALUE value assigned to rc variable is retained till
the program exit which causes the test to be marked as failed.
This patch resets the value before returning to the main() routine.
With this patch the test o/p is as follows:
test: test_copy_unaligned
tags: git_version:unknown
[SKIP] Test skipped on line 26
skip: test_copy_unaligned
selftests: copy_unaligned [PASS]
Signed-off-by: Sachin Sant <sachinp(a)linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
---
tools/testing/selftests/powerpc/harness.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/powerpc/harness.c b/tools/testing/selftests/powerpc/harness.c
index 8ebc58a09311..d1ed7bab65a5 100644
--- a/tools/testing/selftests/powerpc/harness.c
+++ b/tools/testing/selftests/powerpc/harness.c
@@ -105,9 +105,11 @@ int test_harness(int (test_function)(void), char *name)
rc = run_test(test_function, name);
- if (rc == MAGIC_SKIP_RETURN_VALUE)
+ if (rc == MAGIC_SKIP_RETURN_VALUE) {
test_skip(name);
- else
+ /* so that skipped test is not marked as failed */
+ rc = 0;
+ } else
test_finish(name, rc);
return rc;
--
2.11.0
The patch titled
Subject: mm/hugetlb: fix NULL-pointer dereference on 5-level paging machine
has been removed from the -mm tree. Its filename was
mm-hugetlb-fix-null-pointer-dereference-on-5-level-paging-machine.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Subject: mm/hugetlb: fix NULL-pointer dereference on 5-level paging machine
I made a mistake during converting hugetlb code to 5-level paging: in
huge_pte_alloc() we have to use p4d_alloc(), not p4d_offset(). Otherwise
it leads to crash -- NULL-pointer dereference in pud_alloc() if p4d table
is not yet allocated.
It only can happen in 5-level paging mode. In 4-level paging mode
p4d_offset() always returns pgd, so we are fine.
Link: http://lkml.kernel.org/r/20171122121921.64822-1-kirill.shutemov@linux.intel…
Fixes: c2febafc6773 ("mm: convert generic code to 5-level paging")
Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Acked-by: Vlastimil Babka <vbabka(a)suse.cz>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: <stable(a)vger.kernel.org> [4.11+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/hugetlb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -puN mm/hugetlb.c~mm-hugetlb-fix-null-pointer-dereference-on-5-level-paging-machine mm/hugetlb.c
--- a/mm/hugetlb.c~mm-hugetlb-fix-null-pointer-dereference-on-5-level-paging-machine
+++ a/mm/hugetlb.c
@@ -4635,7 +4635,9 @@ pte_t *huge_pte_alloc(struct mm_struct *
pte_t *pte = NULL;
pgd = pgd_offset(mm, addr);
- p4d = p4d_offset(pgd, addr);
+ p4d = p4d_alloc(mm, pgd, addr);
+ if (!p4d)
+ return NULL;
pud = pud_alloc(mm, p4d, addr);
if (pud) {
if (sz == PUD_SIZE) {
_
Patches currently in -mm which might be from kirill.shutemov(a)linux.intel.com are
The patch titled
Subject: autofs: revert "autofs: fix AT_NO_AUTOMOUNT not being honored"
has been removed from the -mm tree. Its filename was
autofs-revert-fix-at_no_automount-not-being-honored.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Ian Kent <raven(a)themaw.net>
Subject: autofs: revert "autofs: fix AT_NO_AUTOMOUNT not being honored"
42f4614821 ("autofs: fix AT_NO_AUTOMOUNT not being honored") allowed the
fstatat(2) system call to properly honor the AT_NO_AUTOMOUNT flag but
introduced a semantic change.
In order to honor AT_NO_AUTOMOUNT a semantic change was made to the
negative dentry case for stat family system calls in follow_automount().
This changed the unconditional triggering of an automount in this case to
no longer be done and an error returned instead.
This has caused more problems than I expected so reverting the change is
needed.
In a discussion with Neil Brown it was concluded that the automount(8)
daemon can implement this change without kernel modifications. So that
will be done instead and the autofs module documentation updated with a
description of the problem and what needs to be done by module users for
this specific case.
Link: http://lkml.kernel.org/r/151174730120.6162.3848002191530283984.stgit@pluto.…
Fixes: 42f4614821 ("autofs: fix AT_NO_AUTOMOUNT not being honored")
Signed-off-by: Ian Kent <raven(a)themaw.net>
Cc: Neil Brown <neilb(a)suse.com>
Cc: Al Viro <viro(a)ZenIV.linux.org.uk>
Cc: David Howells <dhowells(a)redhat.com>
Cc: Colin Walters <walters(a)redhat.com>
Cc: Ondrej Holy <oholy(a)redhat.com>
Cc: <stable(a)vger.kernel.org> [4.11+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/namei.c | 15 +++------------
include/linux/fs.h | 3 ++-
2 files changed, 5 insertions(+), 13 deletions(-)
diff -puN fs/namei.c~autofs-revert-fix-at_no_automount-not-being-honored fs/namei.c
--- a/fs/namei.c~autofs-revert-fix-at_no_automount-not-being-honored
+++ a/fs/namei.c
@@ -1129,18 +1129,9 @@ static int follow_automount(struct path
* of the daemon to instantiate them before they can be used.
*/
if (!(nd->flags & (LOOKUP_PARENT | LOOKUP_DIRECTORY |
- LOOKUP_OPEN | LOOKUP_CREATE |
- LOOKUP_AUTOMOUNT))) {
- /* Positive dentry that isn't meant to trigger an
- * automount, EISDIR will allow it to be used,
- * otherwise there's no mount here "now" so return
- * ENOENT.
- */
- if (path->dentry->d_inode)
- return -EISDIR;
- else
- return -ENOENT;
- }
+ LOOKUP_OPEN | LOOKUP_CREATE | LOOKUP_AUTOMOUNT)) &&
+ path->dentry->d_inode)
+ return -EISDIR;
if (path->dentry->d_sb->s_user_ns != &init_user_ns)
return -EACCES;
diff -puN include/linux/fs.h~autofs-revert-fix-at_no_automount-not-being-honored include/linux/fs.h
--- a/include/linux/fs.h~autofs-revert-fix-at_no_automount-not-being-honored
+++ a/include/linux/fs.h
@@ -3088,7 +3088,8 @@ static inline int vfs_lstat(const char _
static inline int vfs_fstatat(int dfd, const char __user *filename,
struct kstat *stat, int flags)
{
- return vfs_statx(dfd, filename, flags, stat, STATX_BASIC_STATS);
+ return vfs_statx(dfd, filename, flags | AT_NO_AUTOMOUNT,
+ stat, STATX_BASIC_STATS);
}
static inline int vfs_fstat(int fd, struct kstat *stat)
{
_
Patches currently in -mm which might be from raven(a)themaw.net are
The patch titled
Subject: autofs: revert "autofs: take more care to not update last_used on path walk"
has been removed from the -mm tree. Its filename was
autofs-revert-take-more-care-to-not-update-last_used-on-path-walk.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Ian Kent <raven(a)themaw.net>
Subject: autofs: revert "autofs: take more care to not update last_used on path walk"
While 092a53452b ("autofs: take more care to not update last_used on path
walk") helped (partially) resolve a problem where automounts were not
expiring due to aggressive accesses from user space it has a side effect
for very large environments.
This change helps with the expire problem by making the expire more
aggressive but, for very large environments, that means more mount
requests from clients. When there are a lot of clients that can mean
fairly significant server load increases.
It turns out I put the last_used in this position to solve this very
problem and failed to update my own thinking of the autofs expire policy.
So the patch being reverted introduces a regression which should be fixed.
Link: http://lkml.kernel.org/r/151174729420.6162.1832622523537052460.stgit@pluto.…
Fixes: 092a53452b ("autofs: take more care to not update last_used on path walk")
Signed-off-by: Ian Kent <raven(a)themaw.net>
Reviewed-by: NeilBrown <neilb(a)suse.com>
Cc: Al Viro <viro(a)ZenIV.linux.org.uk>
Cc: <stable(a)vger.kernel.org> [4.11+]
Cc: Colin Walters <walters(a)redhat.com>
Cc: David Howells <dhowells(a)redhat.com>
Cc: Ondrej Holy <oholy(a)redhat.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/autofs4/root.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff -puN fs/autofs4/root.c~autofs-revert-take-more-care-to-not-update-last_used-on-path-walk fs/autofs4/root.c
--- a/fs/autofs4/root.c~autofs-revert-take-more-care-to-not-update-last_used-on-path-walk
+++ a/fs/autofs4/root.c
@@ -281,8 +281,8 @@ static int autofs4_mount_wait(const stru
pr_debug("waiting for mount name=%pd\n", path->dentry);
status = autofs4_wait(sbi, path, NFY_MOUNT);
pr_debug("mount wait done status=%d\n", status);
- ino->last_used = jiffies;
}
+ ino->last_used = jiffies;
return status;
}
@@ -321,21 +321,16 @@ static struct dentry *autofs4_mountpoint
*/
if (autofs_type_indirect(sbi->type) && d_unhashed(dentry)) {
struct dentry *parent = dentry->d_parent;
+ struct autofs_info *ino;
struct dentry *new;
new = d_lookup(parent, &dentry->d_name);
if (!new)
return NULL;
- if (new == dentry)
- dput(new);
- else {
- struct autofs_info *ino;
-
- ino = autofs4_dentry_ino(new);
- ino->last_used = jiffies;
- dput(path->dentry);
- path->dentry = new;
- }
+ ino = autofs4_dentry_ino(new);
+ ino->last_used = jiffies;
+ dput(path->dentry);
+ path->dentry = new;
}
return path->dentry;
}
_
Patches currently in -mm which might be from raven(a)themaw.net are
The patch titled
Subject: fs/fat/inode.c: fix sb_rdonly() change
has been removed from the -mm tree. Its filename was
fat-fix-sb_rdonly-change.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp>
Subject: fs/fat/inode.c: fix sb_rdonly() change
bc98a42c1f7d0f ("VFS: Convert sb->s_flags & MS_RDONLY to sb_rdonly(sb)")
converted fat_remount():new_rdonly from a bool to an int. However
fat_remount() depends upon the compiler's conversion of a non-zero integer
into boolean `true'.
Fix it by switching `new_rdonly' back into a bool.
Link: http://lkml.kernel.org/r/87mv3d5x51.fsf@mail.parknet.co.jp
Fixes: bc98a42c1f7d0f8 ("VFS: Convert sb->s_flags & MS_RDONLY to sb_rdonly(sb)")
Signed-off-by: OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp>
Cc: Joe Perches <joe(a)perches.com>
Cc: David Howells <dhowells(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/fat/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN fs/fat/inode.c~fat-fix-sb_rdonly-change fs/fat/inode.c
--- a/fs/fat/inode.c~fat-fix-sb_rdonly-change
+++ a/fs/fat/inode.c
@@ -779,7 +779,7 @@ static void __exit fat_destroy_inodecach
static int fat_remount(struct super_block *sb, int *flags, char *data)
{
- int new_rdonly;
+ bool new_rdonly;
struct msdos_sb_info *sbi = MSDOS_SB(sb);
*flags |= SB_NODIRATIME | (sbi->options.isvfat ? 0 : SB_NOATIME);
_
Patches currently in -mm which might be from hirofumi(a)mail.parknet.co.jp are
The patch titled
Subject: mm, memcg: fix mem_cgroup_swapout() for THPs
has been removed from the -mm tree. Its filename was
mm-memcg-fix-mem_cgroup_swapout-for-thps.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Shakeel Butt <shakeelb(a)google.com>
Subject: mm, memcg: fix mem_cgroup_swapout() for THPs
d6810d730022 ("memcg, THP, swap: make mem_cgroup_swapout() support THP")
changed mem_cgroup_swapout() to support transparent huge page (THP).
However the patch missed one location which should be changed for
correctly handling THPs. The resulting bug will cause the memory cgroups
whose THPs were swapped out to become zombies on deletion.
Link: http://lkml.kernel.org/r/20171128161941.20931-1-shakeelb@google.com
Fixes: d6810d730022 ("memcg, THP, swap: make mem_cgroup_swapout() support THP")
Signed-off-by: Shakeel Butt <shakeelb(a)google.com>
Acked-by: Johannes Weiner <hannes(a)cmpxchg.org>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Huang Ying <ying.huang(a)intel.com>
Cc: Vladimir Davydov <vdavydov.dev(a)gmail.com>
Cc: Greg Thelen <gthelen(a)google.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/memcontrol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/memcontrol.c~mm-memcg-fix-mem_cgroup_swapout-for-thps mm/memcontrol.c
--- a/mm/memcontrol.c~mm-memcg-fix-mem_cgroup_swapout-for-thps
+++ a/mm/memcontrol.c
@@ -6044,7 +6044,7 @@ void mem_cgroup_swapout(struct page *pag
memcg_check_events(memcg, page);
if (!mem_cgroup_is_root(memcg))
- css_put(&memcg->css);
+ css_put_many(&memcg->css, nr_entries);
}
/**
_
Patches currently in -mm which might be from shakeelb(a)google.com are
mm-mlock-vmscan-no-more-skipping-pagevecs.patch
vfs-remove-might_sleep-from-clear_inode.patch
The patch titled
Subject: mm: migrate: fix an incorrect call of prep_transhuge_page()
has been removed from the -mm tree. Its filename was
mm-migrate-fix-an-incorrect-call-of-prep_transhuge_page.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Zi Yan <zi.yan(a)cs.rutgers.edu>
Subject: mm: migrate: fix an incorrect call of prep_transhuge_page()
In https://lkml.org/lkml/2017/11/20/411, Andrea reported that during
memory hotplug/hot remove prep_transhuge_page() is called incorrectly on
non-THP pages for migration, when THP is on but THP migration is not
enabled. This leads to a bad state of target pages for migration.
By inspecting the code, if called on a non-THP, prep_transhuge_page() will
1) change the value of the mapping of (page + 2), since it is used
for THP deferred list;
2) change the lru value of (page + 1), since it is used for THP's
dtor.
Both can lead to data corruption of these two pages.
Andrea said:
: Pragmatically and from the point of view of the memory_hotplug subsys, the
: effect is a kernel crash when pages are being migrated during a memory hot
: remove offline and migration target pages are found in a bad state.
This patch fixes it by only calling prep_transhuge_page() when we are
certain that the target page is THP.
Link: http://lkml.kernel.org/r/20171121021855.50525-1-zi.yan@sent.com
Fixes: 8135d8926c08 ("mm: memory_hotplug: memory hotremove supports thp migration")
Signed-off-by: Zi Yan <zi.yan(a)cs.rutgers.edu>
Reported-by: Andrea Reale <ar(a)linux.vnet.ibm.com>
Cc: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: "Jérôme Glisse" <jglisse(a)redhat.com>
Cc: <stable(a)vger.kernel.org> [4.14]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/migrate.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN include/linux/migrate.h~mm-migrate-fix-an-incorrect-call-of-prep_transhuge_page include/linux/migrate.h
--- a/include/linux/migrate.h~mm-migrate-fix-an-incorrect-call-of-prep_transhuge_page
+++ a/include/linux/migrate.h
@@ -54,7 +54,7 @@ static inline struct page *new_page_node
new_page = __alloc_pages_nodemask(gfp_mask, order,
preferred_nid, nodemask);
- if (new_page && PageTransHuge(page))
+ if (new_page && PageTransHuge(new_page))
prep_transhuge_page(new_page);
return new_page;
_
Patches currently in -mm which might be from zi.yan(a)cs.rutgers.edu are
The patch titled
Subject: mm/madvise.c: fix madvise() infinite loop under special circumstances
has been removed from the -mm tree. Its filename was
mmmadvise-bugfix-of-madvise-systemcall-infinite-loop-under-special-circumstances.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: chenjie <chenjie6(a)huawei.com>
Subject: mm/madvise.c: fix madvise() infinite loop under special circumstances
MADVISE_WILLNEED has always been a noop for DAX (formerly XIP) mappings.
Unfortunately madvise_willneed() doesn't communicate this information
properly to the generic madvise syscall implementation. The calling
convention is quite subtle there. madvise_vma() is supposed to either
return an error or update &prev otherwise the main loop will never advance
to the next vma and it will keep looping for ever without a way to get out
of the kernel.
It seems this has been broken since introduction. Nobody has noticed
because nobody seems to be using MADVISE_WILLNEED on these DAX mappings.
[mhocko(a)suse.com: rewrite changelog]
Link: http://lkml.kernel.org/r/20171127115318.911-1-guoxuenan@huawei.com
Fixes: fe77ba6f4f97 ("[PATCH] xip: madvice/fadvice: execute in place")
Signed-off-by: chenjie <chenjie6(a)huawei.com>
Signed-off-by: guoxuenan <guoxuenan(a)huawei.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Minchan Kim <minchan(a)kernel.org>
Cc: zhangyi (F) <yi.zhang(a)huawei.com>
Cc: Miao Xie <miaoxie(a)huawei.com>
Cc: Mike Rapoport <rppt(a)linux.vnet.ibm.com>
Cc: Shaohua Li <shli(a)fb.com>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Cc: David Rientjes <rientjes(a)google.com>
Cc: Anshuman Khandual <khandual(a)linux.vnet.ibm.com>
Cc: Rik van Riel <riel(a)redhat.com>
Cc: Carsten Otte <cotte(a)de.ibm.com>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/madvise.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff -puN mm/madvise.c~mmmadvise-bugfix-of-madvise-systemcall-infinite-loop-under-special-circumstances mm/madvise.c
--- a/mm/madvise.c~mmmadvise-bugfix-of-madvise-systemcall-infinite-loop-under-special-circumstances
+++ a/mm/madvise.c
@@ -276,15 +276,14 @@ static long madvise_willneed(struct vm_a
{
struct file *file = vma->vm_file;
+ *prev = vma;
#ifdef CONFIG_SWAP
if (!file) {
- *prev = vma;
force_swapin_readahead(vma, start, end);
return 0;
}
if (shmem_mapping(file->f_mapping)) {
- *prev = vma;
force_shm_swapin_readahead(vma, start, end,
file->f_mapping);
return 0;
@@ -299,7 +298,6 @@ static long madvise_willneed(struct vm_a
return 0;
}
- *prev = vma;
start = ((start - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
if (end > vma->vm_end)
end = vma->vm_end;
_
Patches currently in -mm which might be from chenjie6(a)huawei.com are