4.8.2-stable review
Subsystems (6)
Greg Kroah-Hartman
maintainercover 4.8.2-stable review
This is the start of the stable review cycle for the 4.8.2 release. There are 37 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 Sun Oct 16 12:25:23 UTC 2016. 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.8.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.8.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.8.2-rc1
Jarkko Sakkinen <[email protected]>
tpm_crb: fix crb_req_canceled behavior
Jarkko Sakkinen <[email protected]>
tpm: fix a race condition in tpm2_unseal_trusted()
Miklos Szeredi <[email protected]>
ima: use file_dentry()
Dmitry Tunin <[email protected]>
Bluetooth: Add a new 04ca:3011 QCA_ROME device
Christophe Jaillet <[email protected]>
ARM: cpuidle: Fix error return code
Linus Walleij <[email protected]>
ARM: dts: MSM8660 remove flags from SPMI/MPP IRQs
Linus Walleij <[email protected]>
ARM: dts: MSM8064 remove flags from SPMI/MPP IRQs
Grzegorz Jaszczyk <[email protected]>
ARM: dts: mvebu: armada-390: add missing compatibility string and bracket
Russell King <[email protected]>
ARM: fix delays
Josh Poimboeuf <[email protected]>
x86/dumpstack: Fix x86_32 kernel_stack_pointer() previous stack access
Nicolas Iooss <[email protected]>
x86/mm/pkeys: Do not skip PKRU register if debug registers are not used
Prarit Bhargava <[email protected]>
arch/x86: Handle non enumerated CPU after physical hotplug
Denys Vlasenko <[email protected]>
x86/apic: Get rid of apic_version[] array
Andy Shevchenko <[email protected]>
x86/platform/intel-mid: Keep SRAM powered on at boot
Andy Shevchenko <[email protected]>
x86/platform/intel-mid: Add Intel Penwell to ID table
Andy Shevchenko <[email protected]>
x86/cpu: Rename Merrifield2 to Moorefield
Dave Hansen <[email protected]>
x86/pkeys: Make protection keys an "eager" feature
Mika Westerberg <[email protected]>
x86/irq: Prevent force migration of irqs which are not in the vector domain
Dan Williams <[email protected]>
x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation
Mark Rutland <[email protected]>
arm64: fix dump_backtrace/unwind_frame with NULL tsk
Dan Carpenter <[email protected]>
KVM: PPC: BookE: Fix a sanity check
Christoffer Dall <[email protected]>
KVM: arm/arm64: vgic: Don't flush/sync without a working vgic
Christoffer Dall <[email protected]>
KVM: arm64: Require in-kernel irqchip for PMU support
James Hogan <[email protected]>
KVM: MIPS: Drop other CPU ASIDs on guest MMU changes
Thomas Huth <[email protected]>
KVM: PPC: Book3s PR: Allow access to unprivileged MMCR2 register
Boris Ostrovsky <[email protected]>
xen/x86: Update topology map for PV VCPUs
Uwe Kleine-König <[email protected]>
mfd: wm8350-i2c: Make sure the i2c regmap functions are compiled
Dan Carpenter <[email protected]>
mfd: 88pm80x: Double shifting bug in suspend/resume
Boris Brezillon <[email protected]>
mfd: atmel-hlcdc: Do not sleep in atomic context
Lu Baolu <[email protected]>
mfd: rtsx_usb: Avoid setting ucr->current_sg.status
Takashi Sakamoto <[email protected]>
ALSA: usb-line6: use the same declaration as definition in header for MIDI manufacturer ID
Anssi Hannula <[email protected]>
ALSA: usb-audio: Extend DragonFly dB scale quirk to cover other variants
Takashi Iwai <[email protected]>
ALSA: ali5451: Fix out-of-bound position reporting
Chen-Yu Tsai <[email protected]>
phy: sun4i-usb: Use spinlock to guard phyctl register access
Lu Baolu <[email protected]>
usb: dwc3: fix Clear Stall EP command failure
John Stultz <[email protected]>
timekeeping: Fix __ktime_get_fast_ns() regression
Heiner Kallweit <[email protected]>
usb: storage: fix runtime pm issue in usb_stor_probe2
-------------
Diffstat:
Documentation/virtual/kvm/devices/vcpu.txt | 4 +- Makefile | 4 +- arch/arm/boot/dts/armada-390.dtsi | 3 + arch/arm/boot/dts/qcom-apq8064.dtsi | 76 ++++++++++++++++------ arch/arm/boot/dts/qcom-msm8660.dtsi | 75 ++++++++++++++++----- arch/arm/include/asm/delay.h | 2 +- arch/arm64/kernel/stacktrace.c | 5 +- arch/arm64/kernel/traps.c | 10 +-- arch/mips/kvm/emulate.c | 63 +++++++++++++++--- arch/powerpc/include/asm/reg.h | 1 + arch/powerpc/kvm/book3s_emulate.c | 2 + arch/powerpc/kvm/booke.c | 2 +- arch/x86/include/asm/fpu/xstate.h | 7 +- arch/x86/include/asm/intel-family.h | 4 +- arch/x86/include/asm/mpspec.h | 2 +- arch/x86/kernel/acpi/boot.c | 2 +- arch/x86/kernel/apic/apic.c | 17 ++--- arch/x86/kernel/apic/io_apic.c | 4 +- arch/x86/kernel/apic/probe_32.c | 2 +- arch/x86/kernel/apic/vector.c | 23 ++++++- arch/x86/kernel/e820.c | 14 ++-- arch/x86/kernel/process_64.c | 13 ++-- arch/x86/kernel/ptrace.c | 4 +- arch/x86/kernel/smpboot.c | 28 +++++--- arch/x86/platform/atom/punit_atom_debug.c | 2 +- arch/x86/platform/intel-mid/pwr.c | 46 ++++++++++--- arch/x86/xen/smp.c | 6 ++ drivers/bluetooth/btusb.c | 1 + drivers/char/tpm/tpm-dev.c | 2 +- drivers/char/tpm/tpm-interface.c | 51 ++++++++------- drivers/char/tpm/tpm-sysfs.c | 2 +- drivers/char/tpm/tpm.h | 12 ++-- drivers/char/tpm/tpm2-cmd.c | 101 +++++++++++++++++++---------- drivers/char/tpm/tpm_crb.c | 7 +- drivers/cpuidle/cpuidle-arm.c | 1 + drivers/mfd/Kconfig | 1 + drivers/mfd/atmel-hlcdc.c | 5 +- drivers/mfd/rtsx_usb.c | 10 +-- drivers/pci/pci-mid.c | 7 +- drivers/phy/phy-sun4i-usb.c | 11 ++-- drivers/powercap/intel_rapl.c | 4 +- drivers/usb/dwc3/gadget.c | 3 +- drivers/usb/storage/usb.c | 6 +- include/linux/mfd/88pm80x.h | 4 +- kernel/time/timekeeping.c | 7 +- security/integrity/ima/ima_appraise.c | 4 +- security/integrity/ima/ima_main.c | 2 +- sound/pci/ali5451/ali5451.c | 2 + sound/usb/line6/driver.c | 2 +- sound/usb/mixer_quirks.c | 22 +++++-- virt/kvm/arm/pmu.c | 8 +++ virt/kvm/arm/vgic/vgic.c | 6 ++ 52 files changed, 488 insertions(+), 214 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/37 usb: storage: fix runtime pm issue in usb_stor_probe2
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiner Kallweit <[email protected]>
commit a094760b9a77f81ee3cbeff323ee77c928f41106 upstream.
Since commit 71723f95463d "PM / runtime: print error when activating a child to unactive parent" I see the following error message:
scsi host2: usb-storage 1-3:1.0
scsi host2: runtime PM trying to activate child device host2 but parent
(1-3:1.0) is not active
Digging into it it seems to be related to the problem described in the commit message for cd998ded5c12 "i2c: designware: Prevent runtime suspend during adapter registration" as scsi_add_host also calls device_add and after the call to device_add the parent device is suspended.
Fix this by using the approach from the mentioned commit and getting the runtime pm reference before calling scsi_add_host.
--- drivers/usb/storage/usb.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/usb/storage/usb.c +4 -2
@@ -1070,17 +1070,17 @@ int usb_stor_probe2(struct us_data *us) result =usb_stor_acquire_resources (us);if (result) goto BadDevice; +usb_autopm_get_interface_no_resume (us->pusb_intf);snprintf (us->scsi_name,sizeof (us->scsi_name),"usb-storage %s" ,dev_name (&us->pusb_intf->dev)); result =scsi_add_host (us_to_host (us), dev);if (result) {dev_warn (dev,"Unable to add the scsi host\n" ); - goto BadDevice; + goto HostAddErr; }/* Submit the delayed_work for SCSI-device scanning */ -usb_autopm_get_interface_no_resume (us->pusb_intf);set_bit (US_FLIDX_SCAN_PENDING , &us->dflags);if (delay_use >0 )
@@ -1090,6 +1090,8 @@ int usb_stor_probe2(struct us_data *us)return 0 ;/* We come here if there are any problems */ +HostAddErr: +usb_autopm_put_interface_no_suspend (us->pusb_intf); BadDevice:usb_stor_dbg (us,"storage_probe() failed\n" );release_everything (us);
Greg Kroah-Hartman
maintainerPATCH 2/37 timekeeping: Fix __ktime_get_fast_ns() regression
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Stultz <[email protected]>
commit 58bfea9532552d422bde7afa207e1a0f08dffa7d upstream.
In commit 27727df240c7 ("Avoid taking lock in NMI path with CONFIG_DEBUG_TIMEKEEPING"), I changed the logic to open-code the timekeeping_get_ns() function, but I forgot to include the unit conversion from cycles to nanoseconds, breaking the function's output, which impacts users like perf.
This results in bogus perf timestamps like:
swapper 0 [000] 253.427536: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.426573: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.426687: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.426800: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.426905: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427022: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427127: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427239: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427346: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427463: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 255.426572: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
Instead of more reasonable expected timestamps like:
swapper 0 [000] 39.953768: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.064839: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.175956: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.287103: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.398217: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.509324: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.620437: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.731546: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.842654: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.953772: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 41.064881: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
Add the proper use of timekeeping_delta_to_ns() to convert the cycle delta to nanoseconds as needed.
Thanks to Brendan and Alexei for finding this quickly after the v4.8 release. Unfortunately the problematic commit has landed in some -stable trees so they'll need this fix as well.
Many apologies for this mistake. I'll be looking to add a perf-clock sanity test to the kselftest timers tests soon.
--- kernel/time/timekeeping.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
kernel/time/timekeeping.c +5 -2
@@ -403,8 +403,11 @@ static __always_inline u64 __ktime_get_f tkr = tkf->base + (seq &0x01 ); now =ktime_to_ns (tkr->base); - now +=clocksource_delta (tkr->read (tkr->clock), - tkr->cycle_last, tkr->mask); + now +=timekeeping_delta_to_ns (tkr, +clocksource_delta ( + tkr->read (tkr->clock), + tkr->cycle_last, + tkr->mask)); }while (read_seqcount_retry (&tkf->seq, seq));return now;
Greg Kroah-Hartman
maintainerPATCH 3/37 usb: dwc3: fix Clear Stall EP command failure
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lu Baolu <[email protected]>
commit 5e6c88d28ccbe72bedee1fbf4f9fea4764208598 upstream.
Commit 50c763f8c1bac ("usb: dwc3: Set the ClearPendIN bit on Clear Stall EP command") sets ClearPendIN bit for all IN endpoints of v2.60a+ cores. This causes ClearStall command fails on 2.60+ cores operating in HighSpeed mode.
In page 539 of 2.60a specification:
"When issuing Clear Stall command for IN endpoints in SuperSpeed mode, the software must set the "ClearPendIN" bit to '1' to clear any pending IN transcations, so that the device does not expect any ACK TP from the host for the data sent earlier."
It's obvious that we only need to apply this rule to those IN endpoints that currently operating in SuperSpeed mode.
--- drivers/usb/dwc3/gadget.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/usb/dwc3/gadget.c +2 -1
@@ -348,7 +348,8 @@ static int dwc3_send_clear_stall_ep_cmd(* IN transfers due to a mishandled error condition. Synopsys * STAR 9000614252. */ -if (dep->direction && (dwc->revision >=DWC3_REVISION_260A )) +if (dep->direction && (dwc->revision >=DWC3_REVISION_260A ) && + (dwc->gadget.speed >=USB_SPEED_SUPER )) cmd |=DWC3_DEPCMD_CLEARPENDIN ;memset (¶ms,0 ,sizeof (params));
Greg Kroah-Hartman
maintainerPATCH 4/37 phy: sun4i-usb: Use spinlock to guard phyctl register access
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen-Yu Tsai <[email protected]>
commit 919ab2524c52e5f801d8873f09145ce822cdd43a upstream.
The musb driver calls into this phy driver to disable/enable squelch detection. This function was introduced in 24fe86a617c5 ("phy: sun4i-usb:
Add a sunxi specific function for setting squelch-detect"). This function in turn calls sun4i_usb_phy_write, which uses a mutex to guard the common access register. Unfortunately musb does this in atomic context, which results in the following warning with lock debugging enabled:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97 in_atomic(): 1, irqs_disabled(): 128, pid: 96, name: kworker/0:2 CPU: 0 PID: 96 Comm: kworker/0:2 Not tainted 4.8.0-rc4-00181-gd502f8ad1c3e #13 Hardware name: Allwinner sun8i Family Workqueue: events musb_deassert_reset [<c010bc01>] (unwind_backtrace) from [<c0109237>] (show_stack+0xb/0xc) [<c0109237>] (show_stack) from [<c02a669b>] (dump_stack+0x67/0x74) [<c02a669b>] (dump_stack) from [<c05d68c9>] (mutex_lock+0x15/0x2c) [<c05d68c9>] (mutex_lock) from [<c02c3589>] (sun4i_usb_phy_write+0x39/0xec) [<c02c3589>] (sun4i_usb_phy_write) from [<c03e6327>] (musb_port_reset+0xfb/0x184) [<c03e6327>] (musb_port_reset) from [<c03e4917>] (musb_deassert_reset+0x1f/0x2c) [<c03e4917>] (musb_deassert_reset) from [<c012ecb5>] (process_one_work+0x129/0x2b8) [<c012ecb5>] (process_one_work) from [<c012f5e3>] (worker_thread+0xf3/0x424) [<c012f5e3>] (worker_thread) from [<c0132dbd>] (kthread+0xa1/0xb8) [<c0132dbd>] (kthread) from [<c0105f31>] (ret_from_fork+0x11/0x20)
Since the register access is mmio, we can use a spinlock to guard this specific access, rather than the mutex that guards the entire phy.
--- drivers/phy/phy-sun4i-usb.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
drivers/phy/phy-sun4i-usb.c +7 -4
@@ -40,6 +40,7 @@#include <linux/power_supply.h> #include <linux/regulator/consumer.h> #include <linux/reset.h> +#include <linux/spinlock.h> #include <linux/usb/of.h> #include <linux/workqueue.h>
@@ -112,7 +113,7 @@ struct sun4i_usb_phy_data {void __iomem *base;const struct sun4i_usb_phy_cfg *cfg;enum usb_dr_mode dr_mode; -struct mutex mutex; +spinlock_t reg_lock;/* guard access to phyctl reg */ struct sun4i_usb_phy {struct phy *phy;void __iomem *pmu;
@@ -179,9 +180,10 @@ static void sun4i_usb_phy_write(struct sstruct sun4i_usb_phy_data *phy_data =to_sun4i_usb_phy_data (phy);u32 temp, usbc_bit =BIT (phy->index *2 );void __iomem *phyctl = phy_data->base + phy_data->cfg->phyctl_offset; +unsigned long flags;int i; -mutex_lock (&phy_data->mutex); +spin_lock_irqsave (&phy_data->reg_lock, flags);if (phy_data->cfg->type == sun8i_a33_phy) {/* A33 needs us to set phyctl to 0 explicitly */
@@ -218,7 +220,8 @@ static void sun4i_usb_phy_write(struct s data >>=1 ; } -mutex_unlock (&phy_data->mutex); + +spin_unlock_irqrestore (&phy_data->reg_lock, flags); }static void sun4i_usb_phy_passby (struct sun4i_usb_phy *phy,int enable)
@@ -577,7 +580,7 @@ static int sun4i_usb_phy_probe(struct plif (!data)return -ENOMEM ; -mutex_init (&data->mutex); +spin_lock_init (&data->reg_lock);INIT_DELAYED_WORK (&data->detect, sun4i_usb_phy0_id_vbus_det_scan);dev_set_drvdata (dev, data); data->cfg =of_device_get_match_data (dev);
Greg Kroah-Hartman
maintainerPATCH 5/37 ALSA: ali5451: Fix out-of-bound position reporting
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit db68577966abc1aeae4ec597b3dcfa0d56e92041 upstream.
The pointer callbacks of ali5451 driver may return the value at the boundary occasionally, and it results in the kernel warning like
snd_ali5451 0000:00:06.0: BUG: , pos = 16384, buffer size = 16384, period size = 1024
It seems that folding the position offset is enough for fixing the warning and no ill-effect has been seen by that.
--- sound/pci/ali5451/ali5451.c | 2 ++ 1 file changed, 2 insertions(+)
sound/pci/ali5451/ali5451.c +2 -0
@@ -1408,6 +1408,7 @@ snd_ali_playback_pointer(struct snd_pcm_spin_unlock (&codec->reg_lock);dev_dbg (codec->card->dev,"playback pointer returned cso=%xh.\n" , cso); + cso %= runtime->buffer_size;return cso; }
@@ -1428,6 +1429,7 @@ static snd_pcm_uframes_t snd_ali_pointer cso =inw (ALI_REG (codec,ALI_CSO_ALPHA_FMS +2 ));spin_unlock (&codec->reg_lock); + cso %= runtime->buffer_size;return cso; }
Greg Kroah-Hartman
maintainerPATCH 6/37 ALSA: usb-audio: Extend DragonFly dB scale quirk to cover other variants
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anssi Hannula <[email protected]>
commit eb1a74b7bea17eea31915c4f76385cefe69d9795 upstream.
The DragonFly quirk added in 42e3121d90f4 ("ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly") applies a custom dB map on the volume control when its range is reported as 0..50 (0 .. 0.2dB).
However, there exists at least one other variant (hw v1.0c, as opposed to the tested v1.2) which reports a different non-sensical volume range (0..53) and the custom map is therefore not applied for that device.
This results in all of the volume change appearing close to 100% on mixer UIs that utilize the dB TLV information.
Add a fallback case where no dB TLV is reported at all if the control range is not 0..50 but still 0..N where N <= 1000 (3.9 dB). Also restrict the quirk to only apply to the volume control as there is also a mute control which would match the check otherwise.
--- sound/usb/mixer_quirks.c | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-)
sound/usb/mixer_quirks.c +16 -6
@@ -1831,6 +1831,7 @@ void snd_usb_mixer_rc_memory_change(stru }static void snd_dragonfly_quirk_db_scale (struct usb_mixer_interface *mixer, +struct usb_mixer_elem_info *cval,struct snd_kcontrol *kctl) {/* Approximation using 10 ranges based on output measurement on hw v1.2.
@@ -1848,10 +1849,19 @@ static void snd_dragonfly_quirk_db_scale 41, 50, TLV_DB_MINMAX_ITEM(-441, 0), ); -usb_audio_info (mixer->chip,"applying DragonFly dB scale quirk\n" ); - kctl->tlv.p = scale; - kctl->vd[0 ].access |=SNDRV_CTL_ELEM_ACCESS_TLV_READ ; - kctl->vd[0 ].access &= ~SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK ; +if (cval->min ==0 && cval->max ==50 ) { +usb_audio_info (mixer->chip,"applying DragonFly dB scale quirk (0-50 variant)\n" ); + kctl->tlv.p = scale; + kctl->vd[0 ].access |=SNDRV_CTL_ELEM_ACCESS_TLV_READ ; + kctl->vd[0 ].access &= ~SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK ; + + }else if (cval->min ==0 && cval->max <=1000 ) { +/* Some other clearly broken DragonFly variant. +* At least a 0..53 variant (hw v1.0) exists. +*/ +usb_audio_info (mixer->chip,"ignoring too narrow dB range on a DragonFly device" ); + kctl->vd[0 ].access &= ~SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK ; + } } void snd_usb_mixer_fu_apply_quirk(struct usb_mixer_interface *mixer,
@@ -1860,8 +1870,8 @@ void snd_usb_mixer_fu_apply_quirk(struct {switch (mixer->chip->usb_id) {case USB_ID (0x21b4 ,0x0081 ):/* AudioQuest DragonFly */ -if (unitid ==7 && cval->min ==0 && cval->max ==50 ) -snd_dragonfly_quirk_db_scale (mixer, kctl); +if (unitid ==7 && cval->control ==UAC_FU_VOLUME ) +snd_dragonfly_quirk_db_scale (mixer, cval, kctl);break ; } }
Greg Kroah-Hartman
maintainerPATCH 7/37 ALSA: usb-line6: use the same declaration as definition in header for MIDI manufacturer ID
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Sakamoto <[email protected]>
commit 8da08ca03b73593d5299893bf29fc08569c3fb5f upstream.
Currently, usb-line6 module exports an array of MIDI manufacturer ID and usb-pod module uses it. However, the declaration is not the definition in common header. The difference is explicit length of array. Although compiler calculates it and everything goes well, it's better to use the same representation between definition and declaration.
This commit fills the length of array for usb-line6 module. As a small good sub-effect, this commit suppress below warnings from static analysis by sparse v0.5.0.
sound/usb/line6/driver.c:274:43: error: cannot size expression sound/usb/line6/driver.c:275:16: error: cannot size expression sound/usb/line6/driver.c:276:16: error: cannot size expression sound/usb/line6/driver.c:277:16: error: cannot size expression
--- sound/usb/line6/driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/usb/line6/driver.c +1 -1
@@ -29,7 +29,7 @@/* This is Line 6's MIDI manufacturer ID. */ -const unsigned char line6_midi_id[] = { +const unsigned char line6_midi_id[3 ] = {0x00 ,0x01 ,0x0c };EXPORT_SYMBOL_GPL (line6_midi_id);
Greg Kroah-Hartman
maintainerPATCH 8/37 mfd: rtsx_usb: Avoid setting ucr->current_sg.status
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lu Baolu <[email protected]>
commit 8dcc5ff8fcaf778bb57ab4448fedca9e381d088f upstream.
Member "status" of struct usb_sg_request is managed by usb core. A spin lock is used to serialize the change of it. The driver could check the value of req->status, but should avoid changing it without the hold of the spinlock. Otherwise, it could cause race or error in usb core.
This patch could be backported to stable kernels with version later than v3.14.
--- drivers/mfd/rtsx_usb.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/mfd/rtsx_usb.c +5 -5
@@ -46,9 +46,6 @@ static void rtsx_usb_sg_timed_out(unsigndev_dbg (&ucr->pusb_intf->dev,"%s: sg transfer timed out" , __func__);usb_sg_cancel (&ucr->current_sg); - -/* we know the cancellation is caused by time-out */ - ucr->current_sg.status = -ETIMEDOUT ; } static int rtsx_usb_bulk_transfer_sglist(struct rtsx_ucr *ucr,
@@ -67,12 +64,15 @@ static int rtsx_usb_bulk_transfer_sglist ucr->sg_timer.expires = jiffies +msecs_to_jiffies (timeout);add_timer (&ucr->sg_timer);usb_sg_wait (&ucr->current_sg); -del_timer_sync (&ucr->sg_timer); +if (!del_timer_sync (&ucr->sg_timer)) + ret = -ETIMEDOUT ; +else + ret = ucr->current_sg.status;if (act_len) *act_len = ucr->current_sg.bytes; -return ucr->current_sg.status; +return ret; } int rtsx_usb_transfer_data(struct rtsx_ucr *ucr, unsigned int pipe,
Greg Kroah-Hartman
maintainerPATCH 9/37 mfd: atmel-hlcdc: Do not sleep in atomic context
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boris Brezillon <[email protected]>
commit 2c2469bc03d569c49119db2cccb5cb3f0c6a5b33 upstream.
readl_poll_timeout() calls usleep_range(), but regmap_atmel_hlcdc_reg_write() is called in atomic context (regmap spinlock held).
Replace the readl_poll_timeout() call by readl_poll_timeout_atomic().
--- drivers/mfd/atmel-hlcdc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/mfd/atmel-hlcdc.c +3 -2
@@ -50,8 +50,9 @@ static int regmap_atmel_hlcdc_reg_write(if (reg <=ATMEL_HLCDC_DIS ) {u32 status; -readl_poll_timeout (hregmap->regs +ATMEL_HLCDC_SR , status, - !(status &ATMEL_HLCDC_SIP ),1 ,100 ); +readl_poll_timeout_atomic (hregmap->regs +ATMEL_HLCDC_SR , + status, !(status &ATMEL_HLCDC_SIP ), +1 ,100 ); }writel (val, hregmap->regs + reg);
Greg Kroah-Hartman
maintainerPATCH 10/37 mfd: 88pm80x: Double shifting bug in suspend/resume
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit 9a6dc644512fd083400a96ac4a035ac154fe6b8d upstream.
set_bit() and clear_bit() take the bit number so this code is really doing "1 << (1 << irq)" which is a double shift bug. It's done consistently so it won't cause a problem unless "irq" is more than 4.
--- include/linux/mfd/88pm80x.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
include/linux/mfd/88pm80x.h +2 -2
@@ -350,7 +350,7 @@ static inline int pm80x_dev_suspend(struint irq =platform_get_irq (pdev,0 );if (device_may_wakeup (dev)) -set_bit ((1 << irq), &chip->wu_flag); +set_bit (irq, &chip->wu_flag);return 0 ; }
@@ -362,7 +362,7 @@ static inline int pm80x_dev_resume(strucint irq =platform_get_irq (pdev,0 );if (device_may_wakeup (dev)) -clear_bit ((1 << irq), &chip->wu_flag); +clear_bit (irq, &chip->wu_flag);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 12/37 xen/x86: Update topology map for PV VCPUs
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boris Ostrovsky <[email protected]>
commit a6a198bc60e6c980a56eca24d33dc7f29139f8ea upstream.
Early during boot topology_update_package_map() computes logical_pkg_ids for all present processors.
Later, when processors are brought up, identify_cpu() updates these values based on phys_pkg_id which is a function of initial_apicid. On PV guests the latter may point to a non-existing node, causing logical_pkg_ids to be set to -1.
Intel's RAPL uses logical_pkg_id (as topology_logical_package_id()) to index its arrays and therefore in this case will point to index 65535 (since logical_pkg_id is a u16). This could lead to either a crash or may actually access random memory location.
As a workaround, we recompute topology during CPU bringup to reset logical_pkg_id to a valid value.
(The reason for initial_apicid being bogus is because it is initial_apicid of the processor from which the guest is launched. This value is CPUID(1).EBX[31:24])
--- arch/x86/xen/smp.c | 6 ++++++ 1 file changed, 6 insertions(+)
arch/x86/xen/smp.c +6 -0
@@ -87,6 +87,12 @@ static void cpu_bringup(void)cpu_data (cpu).x86_max_cores =1 ;set_cpu_sibling_map (cpu); +/* +* identify_cpu() may have set logical_pkg_id to -1 due +* to incorrect phys_proc_id. Let's re-comupte it. +*/ +topology_update_package_map (apic->cpu_present_to_apicid (cpu), cpu); +xen_setup_cpu_clockevents ();notify_cpu_starting (cpu);
Greg Kroah-Hartman
maintainerPATCH 13/37 KVM: PPC: Book3s PR: Allow access to unprivileged MMCR2 register
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Huth <[email protected]>
commit fa73c3b25bd8d0d393dc6109a1dba3c2aef0451e upstream.
The MMCR2 register is available twice, one time with number 785 (privileged access), and one time with number 769 (unprivileged, but it can be disabled completely). In former times, the Linux kernel was using the unprivileged register 769 only, but since commit 8dd75ccb571f3c92c ("powerpc: Use privileged SPR number for MMCR2"), it uses the privileged register 785 instead. The KVM-PR code then of course also switched to use the SPR 785, but this is causing older guest kernels to crash, since these kernels still access 769 instead. So to support older kernels with KVM-PR again, we have to support register 769 in KVM-PR, too.
--- arch/powerpc/include/asm/reg.h | 1 + arch/powerpc/kvm/book3s_emulate.c | 2 ++ 2 files changed, 3 insertions(+)
arch/powerpc/include/asm/reg.h +1 -0
@@ -737,6 +737,7 @@#define MMCR0_FCHV 0x00000001UL/* freeze conditions in hypervisor mode */ #define SPRN_MMCR1 798#define SPRN_MMCR2 785 +#define SPRN_UMMCR2 769#define SPRN_MMCRA 0x312#define MMCRA_SDSYNC 0x80000000UL/* SDAR synced with SIAR */ #define MMCRA_SDAR_DCACHE_MISS 0x40000000UL
arch/powerpc/kvm/book3s_emulate.c +2 -0
@@ -498,6 +498,7 @@ int kvmppc_core_emulate_mtspr_pr(structcase SPRN_MMCR0 :case SPRN_MMCR1 :case SPRN_MMCR2 : +case SPRN_UMMCR2 :#endif break ; unprivileged:
@@ -640,6 +641,7 @@ int kvmppc_core_emulate_mfspr_pr(structcase SPRN_MMCR0 :case SPRN_MMCR1 :case SPRN_MMCR2 : +case SPRN_UMMCR2 :case SPRN_TIR :#endif *spr_val =0 ;
Greg Kroah-Hartman
maintainerPATCH 14/37 KVM: MIPS: Drop other CPU ASIDs on guest MMU changes
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <[email protected]>
commit 91e4f1b6073dd680d86cdb7e42d7cccca9db39d8 upstream.
When a guest TLB entry is replaced by TLBWI or TLBWR, we only invalidate TLB entries on the local CPU. This doesn't work correctly on an SMP host when the guest is migrated to a different physical CPU, as it could pick up stale TLB mappings from the last time the vCPU ran on that physical CPU.
Therefore invalidate both user and kernel host ASIDs on other CPUs, which will cause new ASIDs to be generated when it next runs on those CPUs.
We're careful only to do this if the TLB entry was already valid, and only for the kernel ASID where the virtual address it mapped is outside of the guest user address range.
--- arch/mips/kvm/emulate.c | 63 ++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 53 insertions(+), 10 deletions(-)
arch/mips/kvm/emulate.c +53 -10
@@ -846,6 +846,47 @@ enum emulation_result kvm_mips_emul_tlbrreturn EMULATE_FAIL ; } +/** +* kvm_mips_invalidate_guest_tlb() - Indicates a change in guest MMU map. +* @vcpu: VCPU with changed mappings. +* @tlb: TLB entry being removed. +* +* This is called to indicate a single change in guest MMU mappings, so that we +* can arrange TLB flushes on this and other CPUs. +*/ +static void kvm_mips_invalidate_guest_tlb (struct kvm_vcpu *vcpu, +struct kvm_mips_tlb *tlb) +{ +int cpu, i; +bool user; + +/* No need to flush for entries which are already invalid */ +if (!((tlb->tlb_lo[0 ] | tlb->tlb_lo[1 ]) &ENTRYLO_V )) +return ; +/* User address space doesn't need flushing for KSeg2/3 changes */ + user = tlb->tlb_hi <KVM_GUEST_KSEG0 ; + +preempt_disable (); + +/* +* Probe the shadow host TLB for the entry being overwritten, if one +* matches, invalidate it +*/ +kvm_mips_host_tlb_inv (vcpu, tlb->tlb_hi); + +/* Invalidate the whole ASID on other CPUs */ + cpu =smp_processor_id (); +for_each_possible_cpu (i) { +if (i == cpu) +continue ; +if (user) + vcpu->arch.guest_user_asid[i] =0 ; + vcpu->arch.guest_kernel_asid[i] =0 ; + } + +preempt_enable (); +} +/* Write Guest TLB Entry @ Index */ enum emulation_result kvm_mips_emul_tlbwi (struct kvm_vcpu *vcpu) {
@@ -865,11 +906,8 @@ enum emulation_result kvm_mips_emul_tlbw } tlb = &vcpu->arch.guest_tlb[index]; -/* -* Probe the shadow host TLB for the entry being overwritten, if one -* matches, invalidate it -*/ -kvm_mips_host_tlb_inv (vcpu, tlb->tlb_hi); + +kvm_mips_invalidate_guest_tlb (vcpu, tlb); tlb->tlb_mask =kvm_read_c0_guest_pagemask (cop0); tlb->tlb_hi =kvm_read_c0_guest_entryhi (cop0);
@@ -898,11 +936,7 @@ enum emulation_result kvm_mips_emul_tlbw tlb = &vcpu->arch.guest_tlb[index]; -/* -* Probe the shadow host TLB for the entry being overwritten, if one -* matches, invalidate it -*/ -kvm_mips_host_tlb_inv (vcpu, tlb->tlb_hi); +kvm_mips_invalidate_guest_tlb (vcpu, tlb); tlb->tlb_mask =kvm_read_c0_guest_pagemask (cop0); tlb->tlb_hi =kvm_read_c0_guest_entryhi (cop0);
@@ -1026,6 +1060,7 @@ enum emulation_result kvm_mips_emulate_Cenum emulation_result er =EMULATE_DONE ;u32 rt, rd, sel;unsigned long curr_pc; +int cpu, i;/* * Update PC and hold onto current PC in case there is
@@ -1135,8 +1170,16 @@ enum emulation_result kvm_mips_emulate_C &KVM_ENTRYHI_ASID , nasid); +preempt_disable ();/* Blow away the shadow host TLBs */ kvm_mips_flush_host_tlb (1 ); + cpu =smp_processor_id (); +for_each_possible_cpu (i) +if (i != cpu) { + vcpu->arch.guest_user_asid[i] =0 ; + vcpu->arch.guest_kernel_asid[i] =0 ; + } +preempt_enable (); }kvm_write_c0_guest_entryhi (cop0, vcpu->arch.gprs[rt]);
Greg Kroah-Hartman
maintainerPATCH 15/37 KVM: arm64: Require in-kernel irqchip for PMU support
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoffer Dall <[email protected]>
commit 6fe407f2d18a4f94216263f91cb7d1f08fa5887c upstream.
If userspace creates a PMU for the VCPU, but doesn't create an in-kernel irqchip, then we end up in a nasty path where we try to take an uninitialized spinlock, which can lead to all sorts of breakages.
Luckily, QEMU always creates the VGIC before the PMU, so we can establish this as ABI and check for the VGIC in the PMU init stage. This can be relaxed at a later time if we want to support PMU with a userspace irqchip.
--- Documentation/virtual/kvm/devices/vcpu.txt | 4 +++- virt/kvm/arm/pmu.c | 8 ++++++++ 2 files changed, 11 insertions(+), 1 deletion(-)
Documentation/virtual/kvm/devices/vcpu.txt +3 -1
@@ -30,4 +30,6 @@ Returns: -ENODEV: PMUv3 not supported attribute -EBUSY: PMUv3 already initialized -Request the initialization of the PMUv3. +Request the initialization of the PMUv3. This must be done after creating the +in-kernel irqchip. Creating a PMU with a userspace irqchip is currently not +supported.
virt/kvm/arm/pmu.c +8 -0
@@ -423,6 +423,14 @@ static int kvm_arm_pmu_v3_init(struct kvif (!kvm_arm_support_pmu_v3 ())return -ENODEV ; +/* +* We currently require an in-kernel VGIC to use the PMU emulation, +* because we do not support forwarding PMU overflow interrupts to +* userspace yet. +*/ +if (!irqchip_in_kernel (vcpu->kvm) || !vgic_initialized (vcpu->kvm)) +return -ENODEV ; +if (!test_bit (KVM_ARM_VCPU_PMU_V3 , vcpu->arch.features) || !kvm_arm_pmu_irq_initialized (vcpu))return -ENXIO ;
Greg Kroah-Hartman
maintainerPATCH 16/37 KVM: arm/arm64: vgic: Dont flush/sync without a working vgic
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoffer Dall <[email protected]>
commit 0099b7701f5296a758d9e6b945ec96f96847cc2f upstream.
If the vgic hasn't been created and initialized, we shouldn't attempt to look at its data structures or flush/sync anything to the GIC hardware.
This fixes an issue reported by Alexander Graf when using a userspace irqchip.
--- virt/kvm/arm/vgic/vgic.c | 6 ++++++ 1 file changed, 6 insertions(+)
virt/kvm/arm/vgic/vgic.c +6 -0
@@ -645,6 +645,9 @@ next:/* Sync back the hardware VGIC state into our emulation after a guest's run. */ void kvm_vgic_sync_hwstate (struct kvm_vcpu *vcpu) { +if (unlikely (!vgic_initialized (vcpu->kvm))) +return ; +vgic_process_maintenance_interrupt (vcpu);vgic_fold_lr_state (vcpu);vgic_prune_ap_list (vcpu);
@@ -653,6 +656,9 @@ void kvm_vgic_sync_hwstate(struct kvm_vc/* Flush our emulation state into the GIC hardware before entering the guest. */ void kvm_vgic_flush_hwstate (struct kvm_vcpu *vcpu) { +if (unlikely (!vgic_initialized (vcpu->kvm))) +return ; +spin_lock (&vcpu->arch.vgic_cpu.ap_list_lock);vgic_flush_lr_state (vcpu);spin_unlock (&vcpu->arch.vgic_cpu.ap_list_lock);
Greg Kroah-Hartman
maintainerPATCH 17/37 KVM: PPC: BookE: Fix a sanity check
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit ac0e89bb4744d3882ccd275f2416d9ce22f4e1e7 upstream.
We use logical negate where bitwise negate was intended. It means that we never return -EINVAL here.
--- arch/powerpc/kvm/booke.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/kvm/booke.c +1 -1
@@ -2038,7 +2038,7 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(if (type ==KVMPPC_DEBUG_NONE )continue ; -if (type & !(KVMPPC_DEBUG_WATCH_READ | +if (type & ~(KVMPPC_DEBUG_WATCH_READ |KVMPPC_DEBUG_WATCH_WRITE |KVMPPC_DEBUG_BREAKPOINT ))return -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 18/37 arm64: fix dump_backtrace/unwind_frame with NULL tsk
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
commit b5e7307d9d5a340d2c9fabbe1cee137d4c682c71 upstream.
In some places, dump_backtrace() is called with a NULL tsk parameter, e.g. in bug_handler() in arch/arm64, or indirectly via show_stack() in core code. The expectation is that this is treated as if current were passed instead of NULL. Similar is true of unwind_frame().
Commit a80a0eb70c358f8c ("arm64: make irq_stack_ptr more robust") didn't take this into account. In dump_backtrace() it compares tsk against current *before* we check if tsk is NULL, and in unwind_frame() we never set tsk if it is NULL.
Due to this, we won't initialise irq_stack_ptr in either function. In dump_backtrace() this results in calling dump_mem() for memory immediately above the IRQ stack range, rather than for the relevant range on the task stack. In unwind_frame we'll reject unwinding frames on the IRQ stack.
In either case this results in incomplete or misleading backtrace information, but is not otherwise problematic. The initial percpu areas (including the IRQ stacks) are allocated in the linear map, and dump_mem uses __get_user(), so we shouldn't access anything with side-effects, and will handle holes safely.
This patch fixes the issue by having both functions handle the NULL tsk case before doing anything else with tsk.
--- arch/arm64/kernel/stacktrace.c | 5 ++++- arch/arm64/kernel/traps.c | 10 +++++----- 2 files changed, 9 insertions(+), 6 deletions(-)
arch/arm64/kernel/stacktrace.c +4 -1
@@ -43,6 +43,9 @@ int notrace unwind_frame(struct task_strunsigned long fp = frame->fp;unsigned long irq_stack_ptr; +if (!tsk) + tsk = current; +/* * Switching between stacks is valid when tracing current and in * non-preemptible context.
@@ -67,7 +70,7 @@ int notrace unwind_frame(struct task_str frame->pc =READ_ONCE_NOCHECK (*(unsigned long *)(fp +8 ));#ifdef CONFIG_FUNCTION_GRAPH_TRACER -if (tsk && tsk->ret_stack && +if (tsk->ret_stack && (frame->pc == (unsigned long )return_to_handler)) {/* * This is a case where function graph tracer has
arch/arm64/kernel/traps.c +5 -5
@@ -142,6 +142,11 @@ static void dump_backtrace(struct pt_regunsigned long irq_stack_ptr;int skip; +pr_debug ("%s(regs = %p tsk = %p)\n" , __func__, regs, tsk); + +if (!tsk) + tsk = current; +/* * Switching between stacks is valid when tracing current and in * non-preemptible context.
@@ -151,11 +156,6 @@ static void dump_backtrace(struct pt_regelse irq_stack_ptr =0 ; -pr_debug ("%s(regs = %p tsk = %p)\n" , __func__, regs, tsk); - -if (!tsk) - tsk = current; -if (tsk == current) { frame.fp = (unsigned long )__builtin_frame_address (0 ); frame.sp = current_stack_pointer;
Greg Kroah-Hartman
maintainerPATCH 19/37 x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <[email protected]>
commit 917db484dc6a69969d317b3e57add4208a8d9d42 upstream.
In commit:
ec776ef6bbe1 ("x86/mm: Add support for the non-standard protected e820 type")
Christoph references the original patch I wrote implementing pmem support. The intent of the 'max_pfn' changes in that commit were to enable persistent memory ranges to be covered by the struct page memmap by default.
However, that approach was abandoned when Christoph ported the patches [1], and that functionality has since been replaced by devm_memremap_pages().
In the meantime, this max_pfn manipulation is confusing kdump [2] that assumes that everything covered by the max_pfn is "System RAM". This results in kdump hanging or crashing.
[1]: https://lists.01.org/pipermail/linux-nvdimm/2015-March/000348.html
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1351098
So fix it.
--- arch/x86/kernel/e820.c | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-)
arch/x86/kernel/e820.c +5 -9
@@ -348,7 +348,7 @@ int __init sanitize_e820_map(struct e820* continue building up new bios map based on this * information */ -if (current_type != last_type || current_type ==E820_PRAM ) { +if (current_type != last_type) {if (last_type !=0 ) { new_bios[new_bios_entry].size = change_point[chgidx]->addr - last_addr;
@@ -754,7 +754,7 @@ u64 __init early_reserve_e820(u64 size,/* * Find the highest page frame number we have available */ -static unsigned long __init e820_end_pfn (unsigned long limit_pfn) +static unsigned long __init e820_end_pfn (unsigned long limit_pfn,unsigned type) {int i;unsigned long last_pfn =0 ;
@@ -765,11 +765,7 @@ static unsigned long __init e820_end_pfnunsigned long start_pfn;unsigned long end_pfn; -/* -* Persistent memory is accounted as ram for purposes of -* establishing max_pfn and mem_map. -*/ -if (ei->type !=E820_RAM && ei->type !=E820_PRAM ) +if (ei->type != type)continue ; start_pfn = ei->addr >>PAGE_SHIFT ;
@@ -794,12 +790,12 @@ static unsigned long __init e820_end_pfn }unsigned long __init e820_end_of_ram_pfn (void ) { -return e820_end_pfn (MAX_ARCH_PFN ); +return e820_end_pfn (MAX_ARCH_PFN ,E820_RAM ); }unsigned long __init e820_end_of_low_ram_pfn (void ) { -return e820_end_pfn (1UL << (32 -PAGE_SHIFT )); +return e820_end_pfn (1UL << (32 -PAGE_SHIFT ),E820_RAM ); }static void early_panic (char *msg)
Greg Kroah-Hartman
maintainerPATCH 20/37 x86/irq: Prevent force migration of irqs which are not in the vector domain
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mika Westerberg <[email protected]>
commit db91aa793ff984ac048e199ea1c54202543952fe upstream.
When a CPU is about to be offlined we call fixup_irqs() that resets IRQ affinities related to the CPU in question. The same thing is also done when the system is suspended to S-states like S3 (mem).
For each IRQ we try to complete any on-going move regardless whether the IRQ is actually part of x86_vector_domain. For each IRQ descriptor we fetch its chip_data, assume it is of type struct apic_chip_data and manipulate it by clearing old_domain mask etc. For irq_chips that are not part of the x86_vector_domain, like those created by various GPIO drivers, will find their chip_data being changed unexpectly.
Below is an example where GPIO chip owned by pinctrl-sunrisepoint.c gets corrupted after resume:
# cat /sys/kernel/debug/gpio gpiochip0: GPIOs 360-511, parent: platform/INT344B:00, INT344B:00: gpio-511 ( |sysfs ) in hi
# rtcwake -s10 -mmem <10 seconds passes>
# cat /sys/kernel/debug/gpio gpiochip0: GPIOs 360-511, parent: platform/INT344B:00, INT344B:00: gpio-511 ( |sysfs ) in ?
Note '?' in the output. It means the struct gpio_chip ->get function is NULL whereas before suspend it was there.
Fix this by first checking that the IRQ belongs to x86_vector_domain before we try to use the chip_data as struct apic_chip_data.
--- arch/x86/kernel/apic/vector.c | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-)
arch/x86/kernel/apic/vector.c +20 -3
@@ -661,11 +661,28 @@ void irq_complete_move(struct irq_cfg *c*/ void irq_force_complete_move (struct irq_desc *desc) { -struct irq_data *irqdata =irq_desc_get_irq_data (desc); -struct apic_chip_data *data =apic_chip_data (irqdata); -struct irq_cfg *cfg = data ? &data->cfg :NULL ; +struct irq_data *irqdata; +struct apic_chip_data *data; +struct irq_cfg *cfg;unsigned int cpu; +/* +* The function is called for all descriptors regardless of which +* irqdomain they belong to. For example if an IRQ is provided by +* an irq_chip as part of a GPIO driver, the chip data for that +* descriptor is specific to the irq_chip in question. +* +* Check first that the chip_data is what we expect +* (apic_chip_data) before touching it any further. +*/ + irqdata =irq_domain_get_irq_data (x86_vector_domain, +irq_desc_get_irq (desc)); +if (!irqdata) +return ; + + data =apic_chip_data (irqdata); + cfg = data ? &data->cfg :NULL ; +if (!cfg)return ;
Greg Kroah-Hartman
maintainerPATCH 21/37 x86/pkeys: Make protection keys an "eager" feature
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Hansen <[email protected]>
commit d4b05923f579c234137317cdf9a5eb69ddab76d1 upstream.
Our XSAVE features are divided into two categories: those that generate FPU exceptions, and those that do not. MPX and pkeys do not generate FPU exceptions and thus can not be used lazily. We disable them when lazy mode is forced on.
We have a pair of masks to collect these two sets of features, but XFEATURE_MASK_PKRU was added to the wrong mask: XFEATURE_MASK_LAZY. Fix it by moving the feature to XFEATURE_MASK_EAGER.
Note: this only causes problem if you boot with lazy FPU mode (eagerfpu=off) which is *not* the default. It also only affects hardware which is not currently publicly available. It looks like eager mode is going away, but we still need this patch applied to any kernel that has protection keys and lazy mode, which is 4.6 through 4.8 at this point, and 4.9 if the lazy removal isn't sent to Linus for 4.9.
--- arch/x86/include/asm/fpu/xstate.h | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
arch/x86/include/asm/fpu/xstate.h +4 -3
@@ -27,11 +27,12 @@ XFEATURE_MASK_YMM | \ XFEATURE_MASK_OPMASK | \ XFEATURE_MASK_ZMM_Hi256 | \ - XFEATURE_MASK_Hi16_ZMM | \ - XFEATURE_MASK_PKRU) + XFEATURE_MASK_Hi16_ZMM)/* Supported features which require eager state saving */ -#define XFEATURE_MASK_EAGER (XFEATURE_MASK_BNDREGS | XFEATURE_MASK_BNDCSR) +#define XFEATURE_MASK_EAGER (XFEATURE_MASK_BNDREGS | \ + XFEATURE_MASK_BNDCSR | \ + XFEATURE_MASK_PKRU)/* All currently supported features */ #define XCNTXT_MASK (XFEATURE_MASK_LAZY | XFEATURE_MASK_EAGER)
Greg Kroah-Hartman
maintainerPATCH 22/37 x86/cpu: Rename Merrifield2 to Moorefield
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Shevchenko <[email protected]>
commit f5fbf848303c8704d0e1a1e7cabd08fd0a49552f upstream.
Merrifield2 is actually Moorefield.
Rename it accordingly and drop tail digit from Merrifield1.
--- arch/x86/include/asm/intel-family.h | 4 ++-- arch/x86/platform/atom/punit_atom_debug.c | 2 +- drivers/pci/pci-mid.c | 2 +- drivers/powercap/intel_rapl.c | 4 ++-- 4 files changed, 6 insertions(+), 6 deletions(-)
arch/x86/include/asm/intel-family.h +2 -2
@@ -56,8 +56,8 @@#define INTEL_FAM6_ATOM_SILVERMONT1 0x37/* BayTrail/BYT / Valleyview */ #define INTEL_FAM6_ATOM_SILVERMONT2 0x4D/* Avaton/Rangely */ #define INTEL_FAM6_ATOM_AIRMONT 0x4C/* CherryTrail / Braswell */ -#define INTEL_FAM6_ATOM_MERRIFIELD1 0x4A/* Tangier */ -#define INTEL_FAM6_ATOM_MERRIFIELD2 0x5A/* Annidale */ +#define INTEL_FAM6_ATOM_MERRIFIELD 0x4A/* Tangier */ +#define INTEL_FAM6_ATOM_MOOREFIELD 0x5A/* Annidale */ #define INTEL_FAM6_ATOM_GOLDMONT 0x5C#define INTEL_FAM6_ATOM_DENVERTON 0x5F/* Goldmont Microserver */
arch/x86/platform/atom/punit_atom_debug.c +1 -1
@@ -155,7 +155,7 @@ static void punit_dbgfs_unregister(void)static const struct x86_cpu_id intel_punit_cpu_ids[] = {ICPU (INTEL_FAM6_ATOM_SILVERMONT1 , punit_device_byt), -ICPU (INTEL_FAM6_ATOM_MERRIFIELD1 , punit_device_tng), +ICPU (INTEL_FAM6_ATOM_MERRIFIELD , punit_device_tng),ICPU (INTEL_FAM6_ATOM_AIRMONT , punit_device_cht), {} };
drivers/pci/pci-mid.c +1 -1
@@ -61,7 +61,7 @@ static struct pci_platform_pm_ops mid_pc#define ICPU (model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }static const struct x86_cpu_id lpss_cpu_ids[] = { -ICPU (INTEL_FAM6_ATOM_MERRIFIELD1 ), +ICPU (INTEL_FAM6_ATOM_MERRIFIELD ), {} };
drivers/powercap/intel_rapl.c +2 -2
@@ -1154,8 +1154,8 @@ static const struct x86_cpu_id rapl_ids[RAPL_CPU (INTEL_FAM6_ATOM_SILVERMONT1 , rapl_defaults_byt),RAPL_CPU (INTEL_FAM6_ATOM_AIRMONT , rapl_defaults_cht), -RAPL_CPU (INTEL_FAM6_ATOM_MERRIFIELD1 , rapl_defaults_tng), -RAPL_CPU (INTEL_FAM6_ATOM_MERRIFIELD2 , rapl_defaults_ann), +RAPL_CPU (INTEL_FAM6_ATOM_MERRIFIELD , rapl_defaults_tng), +RAPL_CPU (INTEL_FAM6_ATOM_MOOREFIELD , rapl_defaults_ann),RAPL_CPU (INTEL_FAM6_ATOM_GOLDMONT , rapl_defaults_core), RAPL_CPU(INTEL_FAM6_ATOM_DENVERTON, rapl_defaults_core),
Greg Kroah-Hartman
maintainerPATCH 23/37 x86/platform/intel-mid: Add Intel Penwell to ID table
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Shevchenko <[email protected]>
commit 8e522e1d321b12829960c9b26668c92f14c68d7f upstream.
Commit:
ca22312dc840 ("x86/platform/intel-mid: Extend PWRMU to support Penwell")
... enabled the PWRMU driver on platforms based on Intel Penwell, but unfortunately this is not enough.
Add Intel Penwell ID to pci-mid.c driver as well. To avoid confusion in the future add a comment to both drivers.
--- arch/x86/platform/intel-mid/pwr.c | 1 + drivers/pci/pci-mid.c | 5 +++++ 2 files changed, 6 insertions(+)
arch/x86/platform/intel-mid/pwr.c +1 -0
@@ -401,6 +401,7 @@ static const struct mid_pwr_device_info .set_initial_state = mid_set_initial_state, }; +/* This table should be in sync with the one in drivers/pci/pci-mid.c */ static const struct pci_device_id mid_pwr_pci_ids[] = { {PCI_VDEVICE (INTEL ,PCI_DEVICE_ID_PENWELL ), (kernel_ulong_t)&mid_info }, {PCI_VDEVICE (INTEL ,PCI_DEVICE_ID_TANGIER ), (kernel_ulong_t)&mid_info },
drivers/pci/pci-mid.c +5 -0
@@ -60,7 +60,12 @@ static struct pci_platform_pm_ops mid_pc#define ICPU (model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, } +/* +* This table should be in sync with the one in +* arch/x86/platform/intel-mid/pwr.c. +*/ static const struct x86_cpu_id lpss_cpu_ids[] = { +ICPU (INTEL_FAM6_ATOM_PENWELL ),ICPU (INTEL_FAM6_ATOM_MERRIFIELD ), {} };
Greg Kroah-Hartman
maintainerPATCH 24/37 x86/platform/intel-mid: Keep SRAM powered on at boot
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Shevchenko <[email protected]>
commit f43ea76cf310c3be95cb75ae1350cbe76a8f2380 upstream.
On Penwell SRAM has to be powered on, otherwise it prevents booting.
--- arch/x86/platform/intel-mid/pwr.c | 45 ++++++++++++++++++++++++++++++-------- 1 file changed, 36 insertions(+), 9 deletions(-)
arch/x86/platform/intel-mid/pwr.c +36 -9
@@ -354,7 +354,7 @@ static int mid_pwr_probe(struct pci_devreturn 0 ; } -static int mid_set_initial_state (struct mid_pwr *pwr) +static int mid_set_initial_state (struct mid_pwr *pwr,const u32 *states) {unsigned int i, j;int ret;
@@ -379,10 +379,10 @@ static int mid_set_initial_state(struct* NOTE: The actual device mapping is provided by a platform at run * time using vendor capability of PCI configuration space. */ -mid_pwr_set_state (pwr,0 ,0xffffffff ); -mid_pwr_set_state (pwr,1 ,0xffffffff ); -mid_pwr_set_state (pwr,2 ,0xffffffff ); -mid_pwr_set_state (pwr,3 ,0xffffffff ); +mid_pwr_set_state (pwr,0 , states[0 ]); +mid_pwr_set_state (pwr,1 , states[1 ]); +mid_pwr_set_state (pwr,2 , states[2 ]); +mid_pwr_set_state (pwr,3 , states[3 ]);/* Send command to SCU */ ret =mid_pwr_wait_for_cmd (pwr,CMD_SET_CFG );
@@ -397,14 +397,41 @@ static int mid_set_initial_state(structreturn 0 ; } -static const struct mid_pwr_device_info mid_info = { - .set_initial_state = mid_set_initial_state, +static int pnw_set_initial_state (struct mid_pwr *pwr) +{ +/* On Penwell SRAM must stay powered on */ +const u32 states[] = { +0xf00fffff ,/* PM_SSC(0) */ +0xffffffff ,/* PM_SSC(1) */ +0xffffffff ,/* PM_SSC(2) */ +0xffffffff ,/* PM_SSC(3) */ + }; +return mid_set_initial_state (pwr, states); +} + +static int tng_set_initial_state (struct mid_pwr *pwr) +{ +const u32 states[] = { +0xffffffff ,/* PM_SSC(0) */ +0xffffffff ,/* PM_SSC(1) */ +0xffffffff ,/* PM_SSC(2) */ +0xffffffff ,/* PM_SSC(3) */ + }; +return mid_set_initial_state (pwr, states); +} + +static const struct mid_pwr_device_info pnw_info = { + .set_initial_state = pnw_set_initial_state, +}; + +static const struct mid_pwr_device_info tng_info = { + .set_initial_state = tng_set_initial_state, };/* This table should be in sync with the one in drivers/pci/pci-mid.c */ static const struct pci_device_id mid_pwr_pci_ids[] = { - {PCI_VDEVICE (INTEL ,PCI_DEVICE_ID_PENWELL ), (kernel_ulong_t)&mid_info }, - {PCI_VDEVICE (INTEL ,PCI_DEVICE_ID_TANGIER ), (kernel_ulong_t)&mid_info }, + {PCI_VDEVICE (INTEL ,PCI_DEVICE_ID_PENWELL ), (kernel_ulong_t)&pnw_info }, + {PCI_VDEVICE (INTEL ,PCI_DEVICE_ID_TANGIER ), (kernel_ulong_t)&tng_info }, {} };
Greg Kroah-Hartman
maintainerPATCH 25/37 x86/apic: Get rid of apic_version[] array
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Denys Vlasenko <[email protected]>
commit cff9ab2b291e64259d97add48fe073c081afe4e2 upstream.
The array has a size of MAX_LOCAL_APIC, which can be as large as 32k, so it can consume up to 128k.
The array has been there forever and was never used for anything useful other than a version mismatch check which was introduced in 2009.
There is no reason to store the version in an array. The kernel is not prepared to handle different APIC versions anyway, so the real important part is to detect a version mismatch and warn about it, which can be done with a single variable as well.
[ tglx: Massaged changelog ]
--- arch/x86/include/asm/mpspec.h | 2 +- arch/x86/kernel/acpi/boot.c | 2 +- arch/x86/kernel/apic/apic.c | 17 +++++++---------- arch/x86/kernel/apic/io_apic.c | 4 ++-- arch/x86/kernel/apic/probe_32.c | 2 +- arch/x86/kernel/smpboot.c | 10 +++++----- 6 files changed, 17 insertions(+), 20 deletions(-)
arch/x86/include/asm/mpspec.h +1 -1
@@ -6,7 +6,6 @@#include <asm/x86_init.h> #include <asm/apicdef.h> -extern int apic_version[];extern int pic_mode;#ifdef CONFIG_X86_32
@@ -40,6 +39,7 @@ extern int mp_bus_id_to_type[MAX_MP_BUSS extern DECLARE_BITMAP(mp_bus_not_pci, MAX_MP_BUSSES);extern unsigned int boot_cpu_physical_apicid; +extern u8 boot_cpu_apic_version;extern unsigned long mp_lapic_addr;#ifdef CONFIG_X86_LOCAL_APIC
arch/x86/kernel/acpi/boot.c +1 -1
@@ -182,7 +182,7 @@ static int acpi_register_lapic(int id, u }if (boot_cpu_physical_apicid !=-1U ) - ver = apic_version[boot_cpu_physical_apicid]; + ver = boot_cpu_apic_version; cpu =generic_processor_info (id, ver);if (cpu >=0 )
arch/x86/kernel/apic/apic.c +7 -10
@@ -64,6 +64,8 @@ unsigned disabled_cpus;unsigned int boot_cpu_physical_apicid =-1U ;EXPORT_SYMBOL_GPL (boot_cpu_physical_apicid); +u8 boot_cpu_apic_version; +/* * The highest APIC ID seen during enumeration. */
@@ -1816,8 +1818,7 @@ void __init init_apic_mappings(void)* since smp_sanity_check is prepared for such a case * and disable smp mode */ - apic_version[new_apicid] = -GET_APIC_VERSION (apic_read (APIC_LVR )); + boot_cpu_apic_version =GET_APIC_VERSION (apic_read (APIC_LVR )); } }
@@ -1832,13 +1833,10 @@ void __init register_lapic_address(unsig }if (boot_cpu_physical_apicid ==-1U ) { boot_cpu_physical_apicid =read_apic_id (); - apic_version[boot_cpu_physical_apicid] = -GET_APIC_VERSION (apic_read (APIC_LVR )); + boot_cpu_apic_version =GET_APIC_VERSION (apic_read (APIC_LVR )); } } -int apic_version[MAX_LOCAL_APIC ]; -/* * Local APIC interrupts */
@@ -2130,11 +2128,10 @@ int generic_processor_info(int apicid, i cpu, apicid); version =0x10 ; } - apic_version[apicid] = version; -if (version != apic_version[boot_cpu_physical_apicid]) { +if (version != boot_cpu_apic_version) {pr_warning ("BIOS bug: APIC version mismatch, boot CPU: %x, CPU %d: version %x\n" , - apic_version[boot_cpu_physical_apicid], cpu, version); + boot_cpu_apic_version, cpu, version); }physid_set (apicid, phys_cpu_present_map);
@@ -2277,7 +2274,7 @@ int __init APIC_init_uniprocessor(void)* Complain if the BIOS pretends there is one. */ if (!boot_cpu_has (X86_FEATURE_APIC ) && -APIC_INTEGRATED (apic_version[boot_cpu_physical_apicid])) { +APIC_INTEGRATED (boot_cpu_apic_version)) {pr_err ("BIOS bug, local APIC 0x%x not detected!...\n" , boot_cpu_physical_apicid);return -1 ;
arch/x86/kernel/apic/io_apic.c +2 -2
@@ -1593,7 +1593,7 @@ void __init setup_ioapic_ids_from_mpc(vo* no meaning without the serial APIC bus. */ if (!(boot_cpu_data.x86_vendor ==X86_VENDOR_INTEL ) - ||APIC_XAPIC (apic_version[boot_cpu_physical_apicid])) + ||APIC_XAPIC (boot_cpu_apic_version))return ;setup_ioapic_ids_from_mpc_nocheck (); }
@@ -2423,7 +2423,7 @@ static int io_apic_get_unique_id(int ioastatic u8 io_apic_unique_id (int idx,u8 id) {if ((boot_cpu_data.x86_vendor ==X86_VENDOR_INTEL ) && - !APIC_XAPIC (apic_version[boot_cpu_physical_apicid])) + !APIC_XAPIC (boot_cpu_apic_version))return io_apic_get_unique_id (idx, id);else return id;
arch/x86/kernel/apic/probe_32.c +1 -1
@@ -152,7 +152,7 @@ early_param("apic", parse_apic);void __init default_setup_apic_routing (void ) { -int version = apic_version[boot_cpu_physical_apicid]; +int version = boot_cpu_apic_version;if (num_possible_cpus () >8 ) {switch (boot_cpu_data.x86_vendor) {
arch/x86/kernel/smpboot.c +5 -5
@@ -690,7 +690,7 @@ wakeup_secondary_cpu_via_nmi(int apicid,* Give the other CPU some time to accept the IPI. */ udelay (200 ); -if (APIC_INTEGRATED (apic_version[boot_cpu_physical_apicid])) { +if (APIC_INTEGRATED (boot_cpu_apic_version)) { maxlvt =lapic_get_maxlvt ();if (maxlvt >3 )/* Due to the Pentium erratum 3AP. */ apic_write (APIC_ESR ,0 );
@@ -717,7 +717,7 @@ wakeup_secondary_cpu_via_init(int phys_a/* * Be paranoid about clearing APIC errors. */ -if (APIC_INTEGRATED (apic_version[phys_apicid])) { +if (APIC_INTEGRATED (boot_cpu_apic_version)) {if (maxlvt >3 )/* Due to the Pentium erratum 3AP. */ apic_write (APIC_ESR ,0 );apic_read (APIC_ESR );
@@ -756,7 +756,7 @@ wakeup_secondary_cpu_via_init(int phys_a* Determine this based on the APIC version. * If we don't have an integrated APIC, don't send the STARTUP IPIs. */ -if (APIC_INTEGRATED (apic_version[phys_apicid])) +if (APIC_INTEGRATED (boot_cpu_apic_version)) num_starts =2 ;else num_starts =0 ;
@@ -994,7 +994,7 @@ static int do_boot_cpu(int apicid, int c/* * Be paranoid about clearing APIC errors. */ -if (APIC_INTEGRATED (apic_version[boot_cpu_physical_apicid])) { +if (APIC_INTEGRATED (boot_cpu_apic_version)) {apic_write (APIC_ESR ,0 );apic_read (APIC_ESR ); }
@@ -1249,7 +1249,7 @@ static int __init smp_sanity_check(unsig/* * If we couldn't find a local APIC, then get out of here now! */ -if (APIC_INTEGRATED (apic_version[boot_cpu_physical_apicid]) && +if (APIC_INTEGRATED (boot_cpu_apic_version) && !boot_cpu_has (X86_FEATURE_APIC )) {if (!disable_apic) { pr_err("BIOS bug, local APIC #%d not detected!...\n",
Greg Kroah-Hartman
maintainerPATCH 26/37 arch/x86: Handle non enumerated CPU after physical hotplug
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Prarit Bhargava <[email protected]>
commit 2a51fe083eba7f99cbda72f5ef90cdf2f4df882c upstream.
When a CPU is physically added to a system then the MADT table is not updated.
If subsequently a kdump kernel is started on that physically added CPU then the ACPI enumeration fails to provide the information for this CPU which is now the boot CPU of the kdump kernel.
As a consequence, generic_processor_info() is not invoked for that CPU so the number of enumerated processors is 0 and none of the initializations, including the logical package id management, are performed.
We have code which relies on the correctness of the logical package map and other information which is initialized via generic_processor_info(). Executing such code will result in undefined behaviour or kernel crashes.
This problem applies only to the kdump kernel because a normal kexec will switch to the original boot CPU, which is enumerated in MADT, before jumping into the kexec kernel.
The boot code already has a check for num_processors equal 0 in prefill_possible_map(). We can use that check as an indicator that the enumeration of the boot CPU did not happen and invoke generic_processor_info() for it. That initializes the relevant data for the boot CPU and therefore prevents subsequent failure.
[ tglx: Refined the code and rewrote the changelog ]
--- arch/x86/kernel/smpboot.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-)
arch/x86/kernel/smpboot.c +15 -3
@@ -1406,9 +1406,21 @@ __init void prefill_possible_map(void) {int i, possible; -/* no processor from mptable or madt */ -if (!num_processors) - num_processors =1 ; +/* No boot processor was found in mptable or ACPI MADT */ +if (!num_processors) { +int apicid = boot_cpu_physical_apicid; +int cpu =hard_smp_processor_id (); + +pr_warn ("Boot CPU (id %d) not listed by BIOS\n" , cpu); + +/* Make sure boot cpu is enumerated */ +if (apic->cpu_present_to_apicid (0 ) ==BAD_APICID && + apic->apic_id_valid (apicid)) +generic_processor_info (apicid, boot_cpu_apic_version); + +if (!num_processors) + num_processors =1 ; + } i = setup_max_cpus ?:1 ;if (setup_possible_cpus ==-1 ) {
Greg Kroah-Hartman
maintainerPATCH 27/37 x86/mm/pkeys: Do not skip PKRU register if debug registers are not used
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Iooss <[email protected]>
commit ba6d018e3d2f6a0fad58a668cadf66b2d1f80f59 upstream.
__show_regs() fails to dump the PKRU state when the debug registers are in their default state because there is a return statement on the debug register state.
Change the logic to report PKRU value even when debug registers are in their default state.
--- arch/x86/kernel/process_64.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-)
arch/x86/kernel/process_64.c +7 -6
@@ -110,12 +110,13 @@ void __show_regs(struct pt_regs *regs, iget_debugreg (d7,7 );/* Only print out debug registers if they are in their non-default state. */ -if ((d0 ==0 ) && (d1 ==0 ) && (d2 ==0 ) && (d3 ==0 ) && - (d6 ==DR6_RESERVED ) && (d7 ==0x400 )) -return ; - -printk (KERN_DEFAULT "DR0: %016lx DR1: %016lx DR2: %016lx\n" , d0, d1, d2); -printk (KERN_DEFAULT "DR3: %016lx DR6: %016lx DR7: %016lx\n" , d3, d6, d7); +if (!((d0 ==0 ) && (d1 ==0 ) && (d2 ==0 ) && (d3 ==0 ) && + (d6 ==DR6_RESERVED ) && (d7 ==0x400 ))) { +printk (KERN_DEFAULT "DR0: %016lx DR1: %016lx DR2: %016lx\n" , + d0, d1, d2); +printk (KERN_DEFAULT "DR3: %016lx DR6: %016lx DR7: %016lx\n" , + d3, d6, d7); + }if (boot_cpu_has (X86_FEATURE_OSPKE ))printk (KERN_DEFAULT "PKRU: %08x\n" ,read_pkru ());
Greg Kroah-Hartman
maintainerPATCH 28/37 x86/dumpstack: Fix x86_32 kernel_stack_pointer() previous stack access
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josh Poimboeuf <[email protected]>
commit 72b4f6a5e903b071f2a7c4eb1418cbe4eefdc344 upstream.
On x86_32, when an interrupt happens from kernel space, SS and SP aren't pushed and the existing stack is used. So pt_regs is effectively two words shorter, and the previous stack pointer is normally the memory after the shortened pt_regs, aka '®s->sp'.
But in the rare case where the interrupt hits right after the stack pointer has been changed to point to an empty stack, like for example when call_on_stack() is used, the address immediately after the shortened pt_regs is no longer on the stack. In that case, instead of '®s->sp', the previous stack pointer should be retrieved from the beginning of the current stack page.
kernel_stack_pointer() wants to do that, but it forgets to dereference the pointer. So instead of returning a pointer to the previous stack, it returns a pointer to the beginning of the current stack.
Note that it's probably outside of kernel_stack_pointer()'s scope to be switching stacks at all. The x86_64 version of this function doesn't do it, and it would be better for the caller to do it if necessary. But that's a patch for another day. This just fixes the original intent.
--- arch/x86/kernel/ptrace.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/kernel/ptrace.c +2 -2
@@ -173,8 +173,8 @@ unsigned long kernel_stack_pointer(strucreturn sp; prev_esp = (u32 *)(context); -if (prev_esp) -return (unsigned long )prev_esp; +if (*prev_esp) +return (unsigned long )*prev_esp;return (unsigned long )regs; }
Greg Kroah-Hartman
maintainerPATCH 29/37 ARM: fix delays
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell King <[email protected]>
commit fb833b1fbb68461772dbf5e91bddea5e839187e9 upstream.
Commit 215e362dafed ("ARM: 8306/1: loop_udelay: remove bogomips value limitation") tried to increase the bogomips limitation, but in doing so messed up udelay such that it always gives about a 5% error in the delay, even if we use a timer.
The calculation is:
loops = UDELAY_MULT * us_delay * ticks_per_jiffy >> UDELAY_SHIFT
Originally, UDELAY_MULT was ((UL(2199023) * HZ) >> 11) and UDELAY_SHIFT
30. Assuming HZ=100, us_delay of 1000 and ticks_per_jiffy of 1660000 (eg, 166MHz timer, 1ms delay) this would calculate:
((UL(2199023) * HZ) >> 11) * 1000 * 1660000 >> 30 => 165999
With the new values of 2047 * HZ + 483648 * HZ / 1000000 and 31, we get:
(2047 * HZ + 483648 * HZ / 1000000) * 1000 * 1660000 >> 31 => 158269
which is incorrect. This is due to a typo - correcting it gives:
(2147 * HZ + 483648 * HZ / 1000000) * 1000 * 1660000 >> 31 => 165999
i.o.w, the original value.
--- arch/arm/include/asm/delay.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/include/asm/delay.h +1 -1
@@ -10,7 +10,7 @@#include <asm/param.h> /* HZ */ #define MAX_UDELAY_MS 2 -#define UDELAY_MULT UL(2047 * HZ + 483648 * HZ / 1000000) +#define UDELAY_MULT UL(2147 * HZ + 483648 * HZ / 1000000)#define UDELAY_SHIFT 31#ifndef __ASSEMBLY__
Greg Kroah-Hartman
maintainerPATCH 30/37 ARM: dts: mvebu: armada-390: add missing compatibility string and bracket
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Grzegorz Jaszczyk <[email protected]>
commit 061492cfad9f11dbc32df741a7164f307b69b6e6 upstream.
The armada-390.dtsi was broken since the first patch which adds Device Tree files for Armada 39x SoC was introduced.
Fixes 538da83 ("ARM: mvebu: add Device Tree files for Armada 39x SoC and board")
--- arch/arm/boot/dts/armada-390.dtsi | 3 +++ 1 file changed, 3 insertions(+)
arch/arm/boot/dts/armada-390.dtsi +3 -0
@@ -47,6 +47,8 @@ #include "armada-39x.dtsi" / { + compatible = "marvell,armada390"; + soc { internal-regs { pinctrl@18000 {
@@ -54,4 +56,5 @@ reg = <0x18000 0x20>; }; }; + }; };
Greg Kroah-Hartman
maintainerPATCH 33/37 ARM: cpuidle: Fix error return code
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Jaillet <[email protected]>
commit af48d7bc3756a0cd882d65bff14ab39746ba57fe upstream.
We know that 'ret = 0' because it has been tested a few lines above. So, if 'kzalloc' fails, 0 will be returned instead of an error code. Return -ENOMEM instead.
--- drivers/cpuidle/cpuidle-arm.c | 1 + 1 file changed, 1 insertion(+)
drivers/cpuidle/cpuidle-arm.c +1 -0
@@ -121,6 +121,7 @@ static int __init arm_idle_init(void) dev =kzalloc (sizeof (*dev),GFP_KERNEL );if (!dev) {pr_err ("Failed to allocate cpuidle device\n" ); + ret = -ENOMEM ; goto out_fail; } dev->cpu = cpu;
Greg Kroah-Hartman
maintainerPATCH 34/37 Bluetooth: Add a new 04ca:3011 QCA_ROME device
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Tunin <[email protected]>
commit 1144a4eed04b2c3e7d20146d1b76f7669b55971d upstream.
T: Bus=01 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3011 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
--- drivers/bluetooth/btusb.c | 1 + 1 file changed, 1 insertion(+)
drivers/bluetooth/btusb.c +1 -0
@@ -251,6 +251,7 @@ static const struct usb_device_id blackl { USB_DEVICE(0x0cf3, 0xe300), .driver_info = BTUSB_QCA_ROME }, { USB_DEVICE(0x0cf3, 0xe360), .driver_info = BTUSB_QCA_ROME }, { USB_DEVICE(0x0489, 0xe092), .driver_info = BTUSB_QCA_ROME }, + { USB_DEVICE(0x04ca, 0x3011), .driver_info = BTUSB_QCA_ROME }, /* Broadcom BCM2035 */ { USB_DEVICE(0x0a5c, 0x2009), .driver_info = BTUSB_BCM92035 },
Greg Kroah-Hartman
maintainerPATCH 35/37 ima: use file_dentry()
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miklos Szeredi <[email protected]>
commit e71b9dff0634edb127f449e076e883ef24a8c76c upstream.
Ima tries to call ->setxattr() on overlayfs dentry after having locked underlying inode, which results in a deadlock.
--- security/integrity/ima/ima_appraise.c | 4 ++-- security/integrity/ima/ima_main.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
security/integrity/ima/ima_appraise.c +2 -2
@@ -190,7 +190,7 @@ int ima_appraise_measurement(enum ima_ho {static const char op[] ="appraise_data" ;char *cause ="unknown" ; -struct dentry *dentry = file->f_path.dentry; +struct dentry *dentry =file_dentry (file);struct inode *inode =d_backing_inode (dentry);enum integrity_status status =INTEGRITY_UNKNOWN ;int rc = xattr_len, hash_start =0 ;
@@ -295,7 +295,7 @@ out:*/ void ima_update_xattr (struct integrity_iint_cache *iint,struct file *file) { -struct dentry *dentry = file->f_path.dentry; +struct dentry *dentry =file_dentry (file);int rc =0 ;/* do not collect and update hash for digital signatures */
security/integrity/ima/ima_main.c +1 -1
@@ -228,7 +228,7 @@ static int process_measurement(struct fiif ((action &IMA_APPRAISE_SUBMASK ) ||strcmp (template_desc->name,IMA_TEMPLATE_IMA_NAME ) !=0 )/* read 'security.ima' */ - xattr_len =ima_read_xattr (file->f_path.dentry, &xattr_value); + xattr_len =ima_read_xattr (file_dentry (file), &xattr_value); hash_algo =ima_get_hash_algo (xattr_value, xattr_len);
Greg Kroah-Hartman
maintainerPATCH 36/37 tpm: fix a race condition in tpm2_unseal_trusted()
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jarkko Sakkinen <[email protected]>
commit d4816edfe706497a8525480c1685ceb9871bc118 upstream.
Unseal and load operations should be done as an atomic operation. This commit introduces unlocked tpm_transmit() so that tpm2_unseal_trusted() can do the locking by itself.
--- drivers/char/tpm/tpm-dev.c | 2 drivers/char/tpm/tpm-interface.c | 51 ++++++++++--------- drivers/char/tpm/tpm-sysfs.c | 2 drivers/char/tpm/tpm.h | 12 +++- drivers/char/tpm/tpm2-cmd.c | 101 +++++++++++++++++++++++++-------------- 5 files changed, 103 insertions(+), 65 deletions(-)
drivers/char/tpm/tpm-dev.c +1 -1
@@ -145,7 +145,7 @@ static ssize_t tpm_write(struct file *fireturn -EPIPE ; } out_size =tpm_transmit (priv->chip, priv->data_buffer, -sizeof (priv->data_buffer)); +sizeof (priv->data_buffer),0 );tpm_put_ops (priv->chip);if (out_size <0 ) {
drivers/char/tpm/tpm-interface.c +28 -23
162 lines not on this page · raw message
drivers/char/tpm/tpm-sysfs.c +1 -1
@@ -39,7 +39,7 @@ static ssize_t pubek_show(struct devicestruct tpm_chip *chip =to_tpm_chip (dev); tpm_cmd.header.in = tpm_readpubek_header; - err =tpm_transmit_cmd (chip, &tpm_cmd,READ_PUBEK_RESULT_SIZE , + err =tpm_transmit_cmd (chip, &tpm_cmd,READ_PUBEK_RESULT_SIZE ,0 ,"attempting to read the PUBEK" );if (err) goto out;
drivers/char/tpm/tpm.h +8 -4
@@ -476,12 +476,16 @@ extern dev_t tpm_devt;extern const struct file_operations tpm_fops;extern struct idr dev_nums_idr; +enum tpm_transmit_flags { +TPM_TRANSMIT_UNLOCKED =BIT (0 ), +}; + +ssize_t tpm_transmit (struct tpm_chip *chip,const u8 *buf,size_t bufsiz, +unsigned int flags); +ssize_t tpm_transmit_cmd (struct tpm_chip *chip,const void *cmd,int len, +unsigned int flags,const char *desc);ssize_t tpm_getcap (struct tpm_chip *chip,__be32 subcap_id,cap_t *cap,const char *desc); -ssize_t tpm_transmit (struct tpm_chip *chip,const char *buf, -size_t bufsiz); -ssize_t tpm_transmit_cmd (struct tpm_chip *chip,void *cmd,int len, -const char *desc);extern int tpm_get_timeouts (struct tpm_chip *);extern void tpm_gen_interrupt (struct tpm_chip *);int tpm1_auto_startup (struct tpm_chip *chip);
drivers/char/tpm/tpm2-cmd.c +65 -36
221 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 37/37 tpm_crb: fix crb_req_canceled behavior
In reply to Greg Kroah-Hartman4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jarkko Sakkinen <[email protected]>
commit 72fd50e14e46dc0edf360631bdece87c2f066a97 upstream.
The req_canceled() callback is used by tpm_transmit() periodically to check whether the request has been canceled while it is receiving a response from the TPM.
The TPM_CRB_CTRL_CANCEL register was cleared already in the crb_cancel callback, which has two consequences:
* Cancel might not happen.
* req_canceled() always returns zero.
A better place to clear the register is when starting to send a new command. The behavior of TPM_CRB_CTRL_CANCEL is described in the section 5.5.3.6 of the PTP specification.
--- drivers/char/tpm/tpm_crb.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/char/tpm/tpm_crb.c +5 -2
@@ -142,6 +142,11 @@ static int crb_send(struct tpm_chip *chistruct crb_priv *priv =dev_get_drvdata (&chip->dev);int rc =0 ; +/* Zero the cancel register so that the next command will not get +* canceled. +*/ +iowrite32 (0 , &priv->cca->cancel); +if (len >ioread32 (&priv->cca->cmd_size)) { dev_err(&chip->dev, "invalid command count value %x %zx\n",
@@ -175,8 +180,6 @@ static void crb_cancel(struct tpm_chip *if ((priv->flags &CRB_FL_ACPI_START ) &&crb_do_acpi_start (chip))dev_err (&chip->dev,"ACPI Start failed\n" ); - -iowrite32 (0 , &priv->cca->cancel); }static bool crb_req_canceled (struct tpm_chip *chip,u8 status)
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.8.2 release. There are 37 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 Sun Oct 16 12:25:23 UTC 2016. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.8.2-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.8.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Signature · 5 lines
Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America(Silicon Valley) [email protected]
Greg Kroah-Hartman
maintainerQuoted 15 lines · Shuah Khan
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.8.2 release. There are 37 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 Sun Oct 16 12:25:23 UTC 2016. 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.8.2-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.8.y
and the diffstat can be found below.
Quoted 6 lines
Quoted 4 lines
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Thanks for testing all of these and letting me know.
greg k-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.8.2 release. There are 37 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 Sun Oct 16 12:25:23 UTC 2016. Anything received after that time might be too late.
Build results:
total: 149 pass: 149 fail: 0 Qemu test results: total: 110 pass: 110 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
Greg Kroah-Hartman
maintainerQuoted 10 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.8.2 release. There are 37 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 Sun Oct 16 12:25:23 UTC 2016. Anything received after that time might be too late.
Quoted 6 lines
Build results:
total: 149 pass: 149 fail: 0 Qemu test results: total: 110 pass: 110 fail: 0Details are available at http://kerneltests.org/builders.
Thanks for testing all of these and letting me know.
greg k-h
A message that is not in the archive (sent off-list or not yet received): [email protected]
Greg Kroah-Hartman
maintainerQuoted 1 line · kernelci.org bot
stable-rc boot: 8 boots: 0 failed, 4 passed with 4 offline (v4.8.1-38-g9ccca26a1585)
That's not many boots, what went wrong here? What happened to the 100+ that 4.7 was getting?
thanks,
greg k-h
Quoted 5 lines · Greg Kroah-Hartman
Quoted 1 line · kernelci.org bot
stable-rc boot: 8 boots: 0 failed, 4 passed with 4 offline (v4.8.1-38-g9ccca26a1585)
That's not many boots, what went wrong here? What happened to the 100+ that 4.7 was getting?
Hmm, looks like there were no ARM builds, which is what most of the boot platforms are. Not sure yet what went wrong there.
But v4.8.2 itself is looking fine, with three known failures that are under investigation:
https://kernelci.org/job/stable-rc/branch/local:linux-4.8.y/
Kevin