3.7.6-stable review
Subsystems (47)
Greg Kroah-Hartman
maintainercover 3.7.6-stable review
This is the start of the stable review cycle for the 3.7.6 release. There are 89 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 Feb 3 13:01:49 UTC 2013. 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/v3.0/stable-review/patch-3.7.6-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 3.7.6-rc1
CAI Qian <[email protected]>
slub: assign refcount for kmalloc_caches
Jani Nikula <[email protected]>
drm/i915: fix FORCEWAKE posting reads
Jesper Juhl <[email protected]>
netfilter: ctnetlink: fix leak in error path of ctnetlink_create_expect
Jan Engelhardt <[email protected]>
netfilter: x_tables: print correct hook names for ARP
Pablo Neira Ayuso <[email protected]>
netfilter: nf_conntrack: fix BUG_ON while removing nf_conntrack with netns
Eric Dumazet <[email protected]>
netfilter: xt_recent: avoid high order page allocations
Vitaly E. Lavrov <[email protected]>
netfilter: xt_recent: fix namespace destroy path
Pablo Neira Ayuso <[email protected]>
netfilter: xt_hashlimit: fix race that results in duplicated entries
Vitaly E. Lavrov <[email protected]>
netfilter: xt_hashlimit: fix namespace destroy path
Pablo Neira Ayuso <[email protected]>
netfilter: fix missing dependencies for the NOTRACK target
Pablo Neira Ayuso <[email protected]>
netfilter: xt_CT: recover NOTRACK target support
Pablo Neira Ayuso <[email protected]>
netfilter: nfnetlink_log: fix possible compilation issue due to missing include
Bob Hockney <[email protected]>
netfilter: nfnetlink_log: fix mac address for 6in4 tunnels
Nicholas Bellinger <[email protected]>
target: fix regression with dev_link_magic in target_fabric_port_link
Dave Chinner <[email protected]>
xfs: fix periodic log flushing
H. Peter Anvin <[email protected]>
x86/Sandy Bridge: Sandy Bridge workaround depends on CONFIG_PCI
Haibo Xi <[email protected]>
netfilter: nf_ct_reasm: fix conntrack reassembly expire code
Mukund Jampala <[email protected]>
netfilter: ip[6]t_REJECT: fix wrong transport header pointer in TCP reset
Alex Williamson <[email protected]>
kvm: Fix irqfd resampler list walk
Ilija Hadzic <[email protected]>
drm/radeon: fix a rare case of double kfree
Ilija Hadzic <[email protected]>
drm/radeon: fix error path in kpage allocation
Dave Chinner <[email protected]>
xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end
Matt Fleming <[email protected]>
x86, efi: Set runtime_version to the EFI spec revision
Nathan Zimmer <[email protected]>
efi, x86: Pass a proper identity mapping in efi_call_phys_prelog
David Woodhouse <[email protected]>
x86, efi: Fix 32-bit EFI handover protocol entry point
David Woodhouse <[email protected]>
x86, efi: Fix display detection in EFI boot stub
Matt Fleming <[email protected]>
samsung-laptop: Disable on EFI hardware
Matt Fleming <[email protected]>
efi: Make 'efi_enabled' a function to query EFI facilities
Alan Cox <[email protected]>
x86/msr: Add capabilities check
Wang YanQing <[email protected]>
smp: Fix SMP function call empty cpu mask race
Nicholas Santos <[email protected]>
HID: usbhid: quirk for Formosa IR receiver
Trond Myklebust <[email protected]>
NFSv4.1: Handle NFS4ERR_DELAY when resetting the NFSv4.1 session
Trond Myklebust <[email protected]>
NFSv4.1: Ensure that nfs41_walk_client_list() does start lease recovery
Trond Myklebust <[email protected]>
NFSv4: Fix NFSv4 trunking discovery
Trond Myklebust <[email protected]>
NFSv4: Fix NFSv4 reference counting for trunked sessions
Trond Myklebust <[email protected]>
NFS: Don't silently fail setattr() requests on mountpoints
Trond Myklebust <[email protected]>
NFS: Fix error reporting in nfs_xdev_mount
Daniel Vetter <[email protected]>
iommu/intel: disable DMAR for g4x integrated gfx
Anderson Lizardo <[email protected]>
Bluetooth: Fix incorrect strncpy() in hidp_setup_hid()
Chris Rattray <[email protected]>
ASoC: wm2200: correct mixer values and text
Mark Brown <[email protected]>
ASoC: arizona: Use actual rather than desired BCLK when calculating LRCLK
Dan Carpenter <[email protected]>
EDAC: Test correct variable in ->store function
Takashi Iwai <[email protected]>
ALSA: hda - Fix non-snoop page handling
David Henningsson <[email protected]>
ALSA: hda - fix inverted internal mic on Acer AOA150/ZG5
Takashi Iwai <[email protected]>
ALSA: hda - Add a fixup for Packard-Bell desktop with ALC880
Clemens Ladisch <[email protected]>
ALSA: usb-audio: fix invalid length check for RME and other UAC 2 devices
Felix Fietkau <[email protected]>
ath9k: allow setting arbitrary antenna masks on AR9003+
Felix Fietkau <[email protected]>
ath9k_hw: fix chain swap setting when setting rx chainmask to 5
Felix Fietkau <[email protected]>
ath9k: disable the tasklet before taking the PCU lock
Felix Fietkau <[email protected]>
ath9k: remove sc->rx.rxbuflock to fix a deadlock
Felix Fietkau <[email protected]>
ath9k: fix rx flush handling
Felix Fietkau <[email protected]>
ath9k: add a better fix for the rx tasklet vs rx flush race
Felix Fietkau <[email protected]>
ath9k: remove the WARN_ON that triggers if generating a beacon fails
Felix Fietkau <[email protected]>
ath9k: fix double-free bug on beacon generate failure
Felix Fietkau <[email protected]>
ath9k: do not link receive buffers during flush
Sujith Manoharan <[email protected]>
ath9k_htc: Fix memory leak
Johannes Berg <[email protected]>
mac80211: fix FT roaming
Stanislaw Gruszka <[email protected]>
mac80211: synchronize scan off/on-channel and PS states
Jonathan Brassow <[email protected]>
DM-RAID: Fix RAID10's check for sufficient redundancy
Piotr Haber <[email protected]>
brcmsmac: handle packet drop during transmit correctly
Piotr Haber <[email protected]>
brcmsmac: increase timer reference count for new timers only
Stanislaw Gruszka <[email protected]>
iwlegacy: fix IBSS cleanup
Avinash Patil <[email protected]>
mwifiex: fix typo in PCIe adapter NULL check
Amitkumar Karwar <[email protected]>
mwifiex: update config_bands during infra association
Daniel Vetter <[email protected]>
drm/i915: dump UTS_RELEASE into the error_state
Chris Wilson <[email protected]>
drm/i915: GFX_MODE Flush TLB Invalidate Mode must be '1' for scanline waits
Chris Wilson <[email protected]>
drm/i915: Disable AsyncFlip performance optimisations
Gerald Schaefer <[email protected]>
s390/thp: implement pmdp_set_wrprotect()
Jan Kara <[email protected]>
xfs: Fix possible use-after-free with AIO
Suravee Suthikulpanit <[email protected]>
IOMMU, AMD Family15h Model10-1Fh erratum 746 Workaround
xueminsu <[email protected]>
radeon_display: Use pointer return error codes
Jerome Glisse <[email protected]>
drm/radeon: fix cursor corruption on DCE6 and newer
Szymon Janc <[email protected]>
Bluetooth: Fix sending HCI commands after reset
Linus Walleij <[email protected]>
mfd: tc3589x: Use simple irqdomain
Marc Zyngier <[email protected]>
ARM: virt: simplify __hyp_stub_install epilog
Marc Zyngier <[email protected]>
ARM: virt: boot secondary CPUs through the right entry point
Dave Martin <[email protected]>
ARM: virt: Avoid bx instruction for compatibility with <=ARMv4
Nicolas Pitre <[email protected]>
ARM: 7628/1: head.S: map one extra section for the ATAG/DTB area
Stephen Boyd <[email protected]>
ARM: 7627/1: Predicate preempt logic on PREEMP_COUNT not PREEMPT alone
Dimitris Papastamos <[email protected]>
ARM: S3C64XX: Fix up IRQ mapping for balblair on Cragganmore
Jean-Christophe PLAGNIOL-VILLARD <[email protected]>
ARM: at91: rm9200: remake the BGA as default version
Luciano Coelho <[email protected]>
ARM: OMAP2+: omap4-panda: add UART2 muxing for WiLink shared transport
Russell King <[email protected]>
ARM: DMA: Fix struct page iterator in dma_cache_maint() to work with sparsemem
Tiejun Chen <[email protected]>
powerpc/book3e: Disable interrupt after preempt_schedule_irq
Alexander Graf <[email protected]>
KVM: PPC: Emulate dcbf
Cong Ding <[email protected]>
fs/cifs/cifs_dfs_ref.c: fix potential memory leakage
Olivier Sobrie <[email protected]>
can: pch_can: fix invalid error codes
Olivier Sobrie <[email protected]>
can: ti_hecc: fix invalid error codes
Olivier Sobrie <[email protected]>
can: c_can: fix invalid error codes
-------------
Diffstat:
Documentation/device-mapper/dm-raid.txt | 1 + Makefile | 4 +- arch/arm/kernel/head.S | 5 +- arch/arm/kernel/hyp-stub.S | 18 ++-- arch/arm/mach-at91/setup.c | 2 + arch/arm/mach-omap2/board-omap4panda.c | 6 ++ arch/arm/mach-s3c64xx/mach-crag6410-module.c | 2 +- arch/arm/mm/dma-mapping.c | 18 ++-- arch/arm/vfp/entry.S | 6 +- arch/arm/vfp/vfphw.S | 4 +- arch/powerpc/kernel/entry_64.S | 13 +++ arch/powerpc/kvm/emulate.c | 2 + arch/s390/include/asm/pgtable.h | 12 +++ arch/x86/boot/compressed/eboot.c | 3 +- arch/x86/boot/compressed/head_32.S | 2 + arch/x86/include/asm/efi.h | 1 + arch/x86/kernel/msr.c | 3 + arch/x86/kernel/reboot.c | 2 +- arch/x86/kernel/setup.c | 30 +++--- arch/x86/platform/efi/efi.c | 59 +++++++----- arch/x86/platform/efi/efi_64.c | 22 ++++- drivers/acpi/osl.c | 2 +- drivers/edac/edac_pci_sysfs.c | 2 +- drivers/firmware/dmi_scan.c | 2 +- drivers/firmware/efivars.c | 4 +- drivers/firmware/iscsi_ibft_find.c | 2 +- drivers/gpu/drm/i915/i915_debugfs.c | 2 + drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 15 ++- drivers/gpu/drm/i915/intel_ringbuffer.c | 24 +++-- drivers/gpu/drm/radeon/radeon_cs.c | 6 +- drivers/gpu/drm/radeon/radeon_cursor.c | 3 +- drivers/gpu/drm/radeon/radeon_device.c | 3 +- drivers/gpu/drm/radeon/radeon_display.c | 2 +- drivers/hid/hid-ids.h | 3 + drivers/hid/usbhid/hid-quirks.c | 1 + drivers/iommu/amd_iommu_init.c | 34 +++++++ drivers/iommu/intel-iommu.c | 21 +++-- drivers/md/dm-raid.c | 101 ++++++++------------- drivers/mfd/tc3589x.c | 17 +--- drivers/net/can/c_can/c_can.c | 4 +- drivers/net/can/pch_can.c | 2 +- drivers/net/can/ti_hecc.c | 4 +- drivers/net/wireless/ath/ath9k/ar9003_phy.c | 25 ++--- drivers/net/wireless/ath/ath9k/ath9k.h | 3 - drivers/net/wireless/ath/ath9k/beacon.c | 2 +- drivers/net/wireless/ath/ath9k/debug.c | 1 - drivers/net/wireless/ath/ath9k/debug.h | 2 - drivers/net/wireless/ath/ath9k/htc_hst.c | 2 + drivers/net/wireless/ath/ath9k/main.c | 22 ++--- drivers/net/wireless/ath/ath9k/recv.c | 54 +++-------- .../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 11 ++- drivers/net/wireless/brcm80211/brcmsmac/main.c | 14 ++- drivers/net/wireless/brcm80211/brcmsmac/main.h | 2 +- drivers/net/wireless/brcm80211/brcmsmac/pub.h | 2 +- drivers/net/wireless/iwlegacy/common.c | 35 +++---- drivers/net/wireless/mwifiex/cfg80211.c | 15 +-- drivers/net/wireless/mwifiex/pcie.c | 2 +- drivers/net/wireless/mwifiex/sta_ioctl.c | 14 +++ drivers/platform/x86/ibm_rtl.c | 2 +- drivers/platform/x86/samsung-laptop.c | 4 + drivers/scsi/isci/init.c | 2 +- drivers/target/target_core_fabric_configfs.c | 11 +-- fs/cifs/cifs_dfs_ref.c | 2 + fs/nfs/namespace.c | 20 ++++ fs/nfs/nfs4client.c | 62 ++++++------- fs/nfs/nfs4state.c | 22 +++-- fs/nfs/super.c | 22 ++--- fs/xfs/xfs_aops.c | 2 +- fs/xfs/xfs_buf.c | 18 ++++ fs/xfs/xfs_sync.c | 2 +- include/linux/efi.h | 24 +++-- include/net/netfilter/nf_conntrack_core.h | 2 + include/net/netns/x_tables.h | 1 + init/main.c | 4 +- kernel/smp.c | 13 ++- mm/slub.c | 1 + net/bluetooth/hci_event.c | 2 +- net/bluetooth/hidp/core.c | 2 +- net/ipv4/netfilter/ipt_REJECT.c | 1 + net/ipv6/netfilter/ip6t_REJECT.c | 1 + net/ipv6/netfilter/nf_conntrack_reasm.c | 5 +- net/mac80211/cfg.c | 12 ++- net/mac80211/ieee80211_i.h | 6 +- net/mac80211/offchannel.c | 19 ++-- net/mac80211/scan.c | 15 +-- net/netfilter/Kconfig | 7 ++ net/netfilter/nf_conntrack_core.c | 9 +- net/netfilter/nf_conntrack_netlink.c | 2 +- net/netfilter/nf_conntrack_standalone.c | 1 + net/netfilter/nfnetlink_log.c | 16 +++- net/netfilter/x_tables.c | 28 ++++-- net/netfilter/xt_CT.c | 50 +++++++++- net/netfilter/xt_hashlimit.c | 54 +++++++++-- net/netfilter/xt_recent.c | 43 +++++++-- sound/pci/hda/hda_intel.c | 40 +++++--- sound/pci/hda/patch_realtek.c | 2 + sound/soc/codecs/arizona.c | 2 +- sound/soc/codecs/wm2200.c | 3 - sound/usb/mixer.c | 17 +++- virt/kvm/eventfd.c | 2 +- 101 files changed, 755 insertions(+), 474 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/89 can: c_can: fix invalid error codes
3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Olivier Sobrie <[email protected]>
commit 6ea45886865c1abb01bb861f7f6bdd5d0f398cb3 upstream.
Errors in CAN protocol (location) are reported in data[3] of the can frame instead of data[2].
--- drivers/net/can/c_can/c_can.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/can/c_can/c_can.c +2 -2
@@ -954,7 +954,7 @@ static int c_can_handle_bus_err(struct nbreak ;case LEC_ACK_ERROR :netdev_dbg (dev,"ack error\n" ); - cf->data[2 ] |= (CAN_ERR_PROT_LOC_ACK | + cf->data[3 ] |= (CAN_ERR_PROT_LOC_ACK |CAN_ERR_PROT_LOC_ACK_DEL );break ;case LEC_BIT1_ERROR :
@@ -967,7 +967,7 @@ static int c_can_handle_bus_err(struct nbreak ;case LEC_CRC_ERROR :netdev_dbg (dev,"CRC error\n" ); - cf->data[2 ] |= (CAN_ERR_PROT_LOC_CRC_SEQ | + cf->data[3 ] |= (CAN_ERR_PROT_LOC_CRC_SEQ |CAN_ERR_PROT_LOC_CRC_DEL );break ;default :
Greg Kroah-Hartman
maintainerPATCH 2/89 can: ti_hecc: fix invalid error codes
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Olivier Sobrie <[email protected]>
commit 71088c4bd9b8f8cbffb0e66f2abc14297e4b2ca8 upstream.
Errors in CAN protocol (location) are reported in data[3] of the can frame instead of data[2].
--- drivers/net/can/ti_hecc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/can/ti_hecc.c +2 -2
@@ -746,12 +746,12 @@ static int ti_hecc_error(struct net_devi }if (err_status &HECC_CANES_CRCE ) {hecc_set_bit (priv,HECC_CANES ,HECC_CANES_CRCE ); - cf->data[2 ] |=CAN_ERR_PROT_LOC_CRC_SEQ | + cf->data[3 ] |=CAN_ERR_PROT_LOC_CRC_SEQ |CAN_ERR_PROT_LOC_CRC_DEL ; }if (err_status &HECC_CANES_ACKE ) {hecc_set_bit (priv,HECC_CANES ,HECC_CANES_ACKE ); - cf->data[2 ] |=CAN_ERR_PROT_LOC_ACK | + cf->data[3 ] |=CAN_ERR_PROT_LOC_ACK |CAN_ERR_PROT_LOC_ACK_DEL ; } }
Greg Kroah-Hartman
maintainerPATCH 3/89 can: pch_can: fix invalid error codes
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Olivier Sobrie <[email protected]>
commit ee50e135aeb048b90fab662e661c58b67341830b upstream.
Errors in CAN protocol (location) are reported in data[3] of the can frame instead of data[2].
--- drivers/net/can/pch_can.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/can/pch_can.c +1 -1
@@ -560,7 +560,7 @@ static void pch_can_error(struct net_dev stats->rx_errors++;break ;case PCH_CRC_ERR : - cf->data[2 ] |=CAN_ERR_PROT_LOC_CRC_SEQ | + cf->data[3 ] |=CAN_ERR_PROT_LOC_CRC_SEQ |CAN_ERR_PROT_LOC_CRC_DEL ; priv->can.can_stats.bus_error++; stats->rx_errors++;
Greg Kroah-Hartman
maintainerPATCH 4/89 fs/cifs/cifs_dfs_ref.c: fix potential memory leakage
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cong Ding <[email protected]>
commit 10b8c7dff5d3633b69e77f57d404dab54ead3787 upstream.
When it goes to error through line 144, the memory allocated to *devname is not freed, and the caller doesn't free it either in line 250. So we free the memroy of *devname in function cifs_compose_mount_options() when it goes to error.
--- fs/cifs/cifs_dfs_ref.c | 2 ++ 1 file changed, 2 insertions(+)
fs/cifs/cifs_dfs_ref.c +2 -0
@@ -226,6 +226,8 @@ compose_mount_options_out: compose_mount_options_err:kfree (mountdata); mountdata =ERR_PTR (rc); +kfree (*devname); + *devname =NULL ; goto compose_mount_options_out; }
Greg Kroah-Hartman
maintainerPATCH 5/89 KVM: PPC: Emulate dcbf
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Graf <[email protected]>
commit d3286144c92ec876da9e30320afa875699b7e0f1 upstream.
Guests can trigger MMIO exits using dcbf. Since we don't emulate cache incoherent MMIO, just do nothing and move on.
--- arch/powerpc/kvm/emulate.c | 2 ++ 1 file changed, 2 insertions(+)
arch/powerpc/kvm/emulate.c +2 -0
@@ -39,6 +39,7 @@#define OP_31_XOP_TRAP 4#define OP_31_XOP_LWZX 23#define OP_31_XOP_TRAP_64 68 +#define OP_31_XOP_DCBF 86#define OP_31_XOP_LBZX 87#define OP_31_XOP_STWX 151#define OP_31_XOP_STBX 215
@@ -353,6 +354,7 @@ int kvmppc_emulate_instruction(struct kvkvmppc_set_exit_type (vcpu,EMULATED_MTSPR_EXITS );break ; +case OP_31_XOP_DCBF :case OP_31_XOP_DCBI :/* Do nothing. The guest is performing dcbi because * hardware DMA is not snooped by the dcache, but
Greg Kroah-Hartman
maintainerPATCH 6/89 powerpc/book3e: Disable interrupt after preempt_schedule_irq
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tiejun Chen <[email protected]>
commit 572177d7c77db1981ba2563e01478126482c43bc upstream.
In preempt case current arch_local_irq_restore() from preempt_schedule_irq() may enable hard interrupt but we really should disable interrupts when we return from the interrupt, and so that we don't get interrupted after loading SRR0/1.
--- arch/powerpc/kernel/entry_64.S | 13 +++++++++++++ 1 file changed, 13 insertions(+)
arch/powerpc/kernel/entry_64.S +13 -0
@@ -668,6 +668,19 @@ resume_kernel: ld r4,TI_FLAGS(r9) andi. r0,r4,_TIF_NEED_RESCHED bne 1b + + /* + * arch_local_irq_restore() from preempt_schedule_irq above may + * enable hard interrupt but we really should disable interrupts + * when we return from the interrupt, and so that we don't get + * interrupted after loading SRR0/1. + */ +#ifdef CONFIG_PPC_BOOK3E + wrteei 0 +#else + ld r10,PACAKMSR(r13) /* Get kernel MSR without EE */ + mtmsrd r10,1 /* Update machine state */ +#endif /* CONFIG_PPC_BOOK3E */ #endif /* CONFIG_PREEMPT */ .globl fast_exc_return_irq
Re: [ 06/89] powerpc/book3e: Disable interrupt after preempt_schedule_irq
Quoted 8 lines · Greg Kroah-Hartman
3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tiejun Chen <[email protected]>
commit
572177d7c77db1981ba2563e01478126482c43bcupstream.
Quoted 8 lines
In preempt case current
arch_local_irq_restore()frompreempt_schedule_irq()may enable hard interrupt but we really should disable interrupts when we return from the interrupt, and so that we don't get interrupted after loading SRR0/1.Signed-off-by Tiejun Chen <[email protected]>Signed-off-by Benjamin Herrenschmidt <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>
[...]
Is this needed for any earlier kernel versions?
Ben.
Signature · 3 lines
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
- Albert EinsteinGreg Kroah-Hartman
maintainerPATCH 7/89 ARM: DMA: Fix struct page iterator in dma_cache_maint() to work with sparsemem
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell King <[email protected]>
commit 15653371c67c3fbe359ae37b720639dd4c7b42c5 upstream.
Subhash Jadavani reported this partial backtrace:
Now consider this call stack from MMC block driver (this is on the ARMv7 based board):
[<c001b50c>] (v7_dma_inv_range+0x30/0x48) from [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c) [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c) from [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c) [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c) from [<c0017ff8>] (dma_map_sg+0x3c/0x114)
This is caused by incrementing the struct page pointer, and running off the end of the sparsemem page array. Fix this by incrementing by pfn instead, and convert the pfn to a struct page.
--- arch/arm/mm/dma-mapping.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-)
arch/arm/mm/dma-mapping.c +10 -8
@@ -776,25 +776,27 @@ static void dma_cache_maint_page(struct size_t size, enum dma_data_direction dir, void (*op)(const void *, size_t, int)) { + unsigned long pfn; +size_t left = size; + + pfn =page_to_pfn (page) + offset /PAGE_SIZE ; + offset %=PAGE_SIZE ; +/* * A single sg entry may refer to multiple physically contiguous * pages. But we still need to process highmem pages individually. * If highmem is not configured then the bulk of this loop gets * optimized out. */ -size_t left = size; do { size_t len = left; void *vaddr; + page = pfn_to_page(pfn); + if (PageHighMem(page)) { - if (len + offset > PAGE_SIZE) { - if (offset >= PAGE_SIZE) { - page += offset / PAGE_SIZE; - offset %= PAGE_SIZE; - } + if (len + offset > PAGE_SIZE) len = PAGE_SIZE - offset; - } vaddr = kmap_high_get(page); if (vaddr) { vaddr += offset;
@@ -811,7 +813,7 @@ static void dma_cache_maint_page(structop (vaddr, len, dir); } offset =0 ; - page++; + pfn++; left -= len; }while (left); }
Greg Kroah-Hartman
maintainerPATCH 8/89 ARM: OMAP2+: omap4-panda: add UART2 muxing for WiLink shared transport
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luciano Coelho <[email protected]>
commit 7662a9c60fee25d7234da4be6d8eab2b2ac88448 upstream.
Add the UART2 muxing data to the board file (this used to be, erroneously, done in the bootloader).
--- arch/arm/mach-omap2/board-omap4panda.c | 6 ++++++ 1 file changed, 6 insertions(+)
arch/arm/mach-omap2/board-omap4panda.c +6 -0
@@ -402,6 +402,12 @@ static struct omap_board_mux board_mux[] OMAP_PULL_ENA),OMAP4_MUX (ABE_MCBSP1_FSX ,OMAP_MUX_MODE0 |OMAP_PIN_INPUT ), +/* UART2 - BT/FM/GPS shared transport */ +OMAP4_MUX (UART2_CTS ,OMAP_PIN_INPUT |OMAP_MUX_MODE0 ), +OMAP4_MUX (UART2_RTS ,OMAP_PIN_OUTPUT |OMAP_MUX_MODE0 ), +OMAP4_MUX (UART2_RX ,OMAP_PIN_INPUT |OMAP_MUX_MODE0 ), +OMAP4_MUX (UART2_TX ,OMAP_PIN_OUTPUT |OMAP_MUX_MODE0 ), + { .reg_offset = OMAP_MUX_TERMINATOR }, };
Greg Kroah-Hartman
maintainerPATCH 9/89 ARM: at91: rm9200: remake the BGA as default version
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jean-Christophe PLAGNIOL-VILLARD <[email protected]>
commit 36224d0fe0f34cdde66a381708853ebadeac799c upstream.
Make BGA as the default version as we are supposed to just have to specify when we use the PQFP version.
Issue was existing since commit:
3e90772 (ARM: at91: fix at91rm9200 soc subtype handling).
--- arch/arm/mach-at91/setup.c | 2 ++ 1 file changed, 2 insertions(+)
arch/arm/mach-at91/setup.c +2 -0
@@ -104,6 +104,8 @@ static void __init soc_detect(u32 dbgu_bswitch (socid) {case ARCH_ID_AT91RM9200 : at91_soc_initdata.type =AT91_SOC_RM9200 ; +if (at91_soc_initdata.subtype ==AT91_SOC_SUBTYPE_NONE ) + at91_soc_initdata.subtype =AT91_SOC_RM9200_BGA ; at91_boot_soc = at91rm9200_soc;break ;
Greg Kroah-Hartman
maintainerPATCH 10/89 ARM: S3C64XX: Fix up IRQ mapping for balblair on Cragganmore
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dimitris Papastamos <[email protected]>
commit b86dc0d8c12bbb9fed3f392c284bdc7114ce00c1 upstream.
We are using S3C_EINT(4) instead of S3C_EINT(5).
--- arch/arm/mach-s3c64xx/mach-crag6410-module.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/mach-s3c64xx/mach-crag6410-module.c +1 -1
@@ -39,7 +39,7 @@ static struct spi_board_info wm1253_devs .bus_num = 0, .chip_select = 0, .mode = SPI_MODE_0, - .irq = S3C_EINT(5), + .irq = S3C_EINT(4), .controller_data = &wm0010_spi_csinfo, }, };
Greg Kroah-Hartman
maintainerPATCH 11/89 ARM: 7627/1: Predicate preempt logic on PREEMP_COUNT not PREEMPT alone
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephen Boyd <[email protected]>
commit 568dca15aa2a0f4ddee255894ec393a159f13147 upstream.
Patrik Kluba reports that the preempt count becomes invalid due to the preempt_enable() call being unbalanced with a preempt_disable() call in the vfp assembly routines. This happens because preempt_enable() and preempt_disable() update preempt counts under PREEMPT_COUNT=y but the vfp assembly routines do so under PREEMPT=y. In a configuration where PREEMPT=n and DEBUG_ATOMIC_SLEEP=y, PREEMPT_COUNT=y and so the preempt_enable() call in VFP_bounce() keeps subtracting from the preempt count until it goes negative.
Fix this by always using PREEMPT_COUNT to decided when to update preempt counts in the ARM assembly code.
--- arch/arm/vfp/entry.S | 6 +++--- arch/arm/vfp/vfphw.S | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-)
arch/arm/vfp/entry.S +3 -3
@@ -22,7 +22,7 @@ @ IRQs disabled. @ ENTRY(do_vfp) -#ifdef CONFIG_PREEMPT +#ifdef CONFIG_PREEMPT_COUNT ldr r4, [r10, #TI_PREEMPT] @ get preempt count add r11, r4, #1 @ increment it str r11, [r10, #TI_PREEMPT]
@@ -35,7 +35,7 @@ ENTRY(do_vfp) ENDPROC(do_vfp) ENTRY(vfp_null_entry) -#ifdef CONFIG_PREEMPT +#ifdef CONFIG_PREEMPT_COUNT get_thread_info r10 ldr r4, [r10, #TI_PREEMPT] @ get preempt count sub r11, r4, #1 @ decrement it
@@ -53,7 +53,7 @@ ENDPROC(vfp_null_entry) __INIT ENTRY(vfp_testing_entry) -#ifdef CONFIG_PREEMPT +#ifdef CONFIG_PREEMPT_COUNT get_thread_info r10 ldr r4, [r10, #TI_PREEMPT] @ get preempt count sub r11, r4, #1 @ decrement it
arch/arm/vfp/vfphw.S +2 -2
@@ -168,7 +168,7 @@ vfp_hw_state_valid: @ else it's one 32-bit instruction, so @ always subtract 4 from the following @ instruction address. -#ifdef CONFIG_PREEMPT +#ifdef CONFIG_PREEMPT_COUNT get_thread_info r10 ldr r4, [r10, #TI_PREEMPT] @ get preempt count sub r11, r4, #1 @ decrement it
@@ -192,7 +192,7 @@ look_for_VFP_exceptions: @ not recognised by VFP DBGSTR "not VFP" -#ifdef CONFIG_PREEMPT +#ifdef CONFIG_PREEMPT_COUNT get_thread_info r10 ldr r4, [r10, #TI_PREEMPT] @ get preempt count sub r11, r4, #1 @ decrement it
Greg Kroah-Hartman
maintainerPATCH 12/89 ARM: 7628/1: head.S: map one extra section for the ATAG/DTB area
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Pitre <[email protected]>
commit 6f16f4998f98e42e3f2dedf663cfb691ff0324af upstream.
We currently use a temporary 1MB section aligned to a 1MB boundary for mapping the provided device tree until the final page table is created. However, if the device tree happens to cross that 1MB boundary, the end of it remains unmapped and the kernel crashes when it attempts to access it. Given no restriction on the location of that DTB, it could end up with only a few bytes mapped at the end of a section.
Solve this issue by mapping two consecutive sections.
--- arch/arm/kernel/head.S | 3 +++ 1 file changed, 3 insertions(+)
arch/arm/kernel/head.S +3 -0
@@ -246,6 +246,7 @@ __create_page_tables: /* * Then map boot params address in r2 if specified. + * We map 2 sections in case the ATAGs/DTB crosses a section boundary. */ mov r0, r2, lsr #SECTION_SHIFT movs r0, r0, lsl #SECTION_SHIFT
@@ -253,6 +254,8 @@ __create_page_tables: addne r3, r3, #PAGE_OFFSET addne r3, r4, r3, lsr #(SECTION_SHIFT - PMD_ORDER) orrne r6, r7, r0 + strne r6, [r3], #1 << PMD_ORDER + addne r6, r6, #1 << SECTION_SHIFT strne r6, [r3] #ifdef CONFIG_DEBUG_LL
Greg Kroah-Hartman
maintainerPATCH 13/89 ARM: virt: Avoid bx instruction for compatibility with <=ARMv4
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Martin <[email protected]>
commit a4a12e008e292a81d312659529b71be2026ab355 upstream.
Non-T variants of ARMv4 do not support the bx instruction.
However, __hyp_stub_install is always called from the same instruction set used to build the bulk of the kernel, so bx should not be necessary.
This patch uses the traditional "mov pc" instead of bx.
--- arch/arm/kernel/hyp-stub.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
arch/arm/kernel/hyp-stub.S +3 -3
@@ -99,7 +99,7 @@ ENTRY(__hyp_stub_install_secondary) * immediately. */ compare_cpu_mode_with_primary r4, r5, r6, r7 - bxne lr + movne pc, lr /* * Once we have given up on one CPU, we do not try to install the
@@ -111,7 +111,7 @@ ENTRY(__hyp_stub_install_secondary) */ cmp r4, #HYP_MODE - bxne lr @ give up if the CPU is not in HYP mode + movne pc, lr @ give up if the CPU is not in HYP mode /* * Configure HSCTLR to set correct exception endianness/instruction set
@@ -200,7 +200,7 @@ ENDPROC(__hyp_get_vectors) @ fall through ENTRY(__hyp_set_vectors) __HVC(0) - bx lr + mov pc, lr ENDPROC(__hyp_set_vectors) #ifndef ZIMAGE
Greg Kroah-Hartman
maintainerPATCH 14/89 ARM: virt: boot secondary CPUs through the right entry point
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Zyngier <[email protected]>
commit 6e484be1ccca3ea495db45900fd42aac8d49d754 upstream.
Secondary CPUs should use the __hyp_stub_install_secondary entry point, so boot mode inconsistencies can be detected.
--- arch/arm/kernel/head.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/kernel/head.S +1 -1
@@ -334,7 +334,7 @@ ENTRY(secondary_startup) * as it has already been validated by the primary processor. */ #ifdef CONFIG_ARM_VIRT_EXT - bl __hyp_stub_install + bl __hyp_stub_install_secondary #endif safe_svcmode_maskall r9
Greg Kroah-Hartman
maintainerPATCH 15/89 ARM: virt: simplify __hyp_stub_install epilog
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Zyngier <[email protected]>
commit d01723479e6a6c70c83295f7847477a016d5e14a upstream.
__hyp_stub_install duplicates quite a bit of safe_svcmode_maskall by forcing the CPU back to SVC. This is unnecessary, as safe_svcmode_maskall is called just after.
Furthermore, the way we build SPSR_hyp is buggy as we fail to mask the interrupts, leading to interesting behaviours on TC2 + UEFI.
The fix is to simply remove this code and rely on safe_svcmode_maskall to do the right thing.
--- arch/arm/kernel/hyp-stub.S | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-)
arch/arm/kernel/hyp-stub.S +3 -9
@@ -120,7 +120,8 @@ ENTRY(__hyp_stub_install_secondary) * Eventually, CPU-specific code might be needed -- assume not for now * * This code relies on the "eret" instruction to synchronize the - * various coprocessor accesses. + * various coprocessor accesses. This is done when we switch to SVC + * (see safe_svcmode_maskall). */ @ Now install the hypervisor stub: adr r7, __hyp_stub_vectors
@@ -155,14 +156,7 @@ THUMB( orr r7, #(1 << 30) ) @ HSCTLR.TE 1: #endif - bic r7, r4, #MODE_MASK - orr r7, r7, #SVC_MODE -THUMB( orr r7, r7, #PSR_T_BIT ) - msr spsr_cxsf, r7 @ This is SPSR_hyp. - - __MSR_ELR_HYP(14) @ msr elr_hyp, lr - __ERET @ return, switching to SVC mode - @ The boot CPU mode is left in r4. + bx lr @ The boot CPU mode is left in r4. ENDPROC(__hyp_stub_install_secondary) __hyp_stub_do_trap:
Greg Kroah-Hartman
maintainerPATCH 16/89 mfd: tc3589x: Use simple irqdomain
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Walleij <[email protected]>
commit 1f0529b4d80ad02df637be67ed4f82e93b8db32f upstream.
This fixes a regression in the TC3589x driver introduced in commit 15e27b1088245a2de3b7d09d39cd209212eb16af "mfd: Provide the tc3589x with its own IRQ domain"
If a system with a TC3589x expander is booted and a base IRQ is passed from platform data, a legacy domain will be used. However, since the Ux500 is now switched to use SPARSE_IRQ, no descriptors get allocated on-the-fly, and we get a crash.
Fix this by switching to using the simple irqdomain that will handle this uniformly and also allocates descriptors explicitly.
Also fix two small whitespace errors in the vicinity while we're at it.
--- drivers/mfd/tc3589x.c | 17 +++++------------ 1 file changed, 5 insertions(+), 12 deletions(-)
drivers/mfd/tc3589x.c +5 -12
@@ -219,25 +219,18 @@ static void tc3589x_irq_unmap(struct irq }static struct irq_domain_ops tc3589x_irq_ops = { - .map = tc3589x_irq_map, + .map = tc3589x_irq_map, .unmap = tc3589x_irq_unmap, - .xlate = irq_domain_xlate_twocell, + .xlate = irq_domain_xlate_twocell, };static int tc3589x_irq_init (struct tc3589x *tc3589x,struct device_node *np) {int base = tc3589x->irq_base; -if (base) { - tc3589x->domain =irq_domain_add_legacy ( -NULL , TC3589x_NR_INTERNAL_IRQS, base, -0 , &tc3589x_irq_ops, tc3589x); - } -else { - tc3589x->domain =irq_domain_add_linear ( - np, TC3589x_NR_INTERNAL_IRQS, - &tc3589x_irq_ops, tc3589x); - } + tc3589x->domain =irq_domain_add_simple ( + np, TC3589x_NR_INTERNAL_IRQS, base, + &tc3589x_irq_ops, tc3589x);if (!tc3589x->domain) {dev_err (tc3589x->dev,"Failed to create irqdomain\n" );
Greg Kroah-Hartman
maintainerPATCH 17/89 Bluetooth: Fix sending HCI commands after reset
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Szymon Janc <[email protected]>
commit dbccd791a3fbbdac12c33834b73beff3984988e9 upstream.
After sending reset command wait for its command complete event before sending next command. Some chips sends CC event for command received before reset if reset was send before chip replied with CC.
This is also required by specification that host shall not send additional HCI commands before receiving CC for reset.
< HCI Command: Reset (0x03|0x0003) plen 0 [hci0] 18.404612
Quoted 1 line
HCI Event: Command Complete (
0x0e) plen 4 [hci0] 18.405850
Write Extended Inquiry Response (0x03|0x0052) ncmd 1
Status: Success (0x00)< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0 [hci0] 18.406079
Quoted 1 line
HCI Event: Command Complete (
0x0e) plen 4 [hci0] 18.407864
Reset (0x03|0x0003) ncmd 1
Status: Success (0x00)< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0 [hci0] 18.408062
Quoted 1 line
HCI Event: Command Complete (
0x0e) plen 12 [hci0] 18.408835
--- net/bluetooth/hci_event.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/bluetooth/hci_event.c +1 -1
@@ -2394,7 +2394,7 @@ static void hci_cmd_complete_evt(structif (ev->opcode !=HCI_OP_NOP )del_timer (&hdev->cmd_timer); -if (ev->ncmd) { +if (ev->ncmd && !test_bit (HCI_RESET , &hdev->flags)) {atomic_set (&hdev->cmd_cnt,1 );if (!skb_queue_empty (&hdev->cmd_q))queue_work (hdev->workqueue, &hdev->cmd_work);
Greg Kroah-Hartman
maintainerPATCH 18/89 drm/radeon: fix cursor corruption on DCE6 and newer
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jerome Glisse <[email protected]>
commit e521a29014794d139cca46396d1af8faf1295a26 upstream.
Aruba and newer gpu does not need the avivo cursor work around, quite the opposite this work around lead to corruption.
agd5f: check DCE6 rather than ARUBA since the issue is DCE version specific rather than family specific.
--- drivers/gpu/drm/radeon/radeon_cursor.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/radeon/radeon_cursor.c +2 -1
@@ -240,7 +240,8 @@ int radeon_crtc_cursor_move(struct drm_c y =0 ; } -if (ASIC_IS_AVIVO (rdev)) { +/* fixed on DCE6 and newer */ +if (ASIC_IS_AVIVO (rdev) && !ASIC_IS_DCE6 (rdev)) {int i =0 ;struct drm_crtc *crtc_p;
Greg Kroah-Hartman
maintainerPATCH 19/89 radeon_display: Use pointer return error codes
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: xueminsu <[email protected]>
commit b2f4b03f8a378cd626d2ea67d19e7470c050a098 upstream.
drm_mode_addfb() expects fb_create return error code instead of NULL.
--- drivers/gpu/drm/radeon/radeon_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/radeon/radeon_display.c +1 -1
@@ -1118,7 +1118,7 @@ radeon_user_framebuffer_create(struct drif (ret) {kfree (radeon_fb);drm_gem_object_unreference_unlocked (obj); -return NULL ; +return ERR_PTR (ret); }return &radeon_fb->base;
Greg Kroah-Hartman
maintainerPATCH 20/89 IOMMU, AMD Family15h Model10-1Fh erratum 746 Workaround
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Suravee Suthikulpanit <[email protected]>
commit 318fe782539c4150d1b8e4e6c9dc3a896512cb8a upstream.
The IOMMU may stop processing page translations due to a perceived lack of credits for writing upstream peripheral page service request (PPR) or event logs. If the L2B miscellaneous clock gating feature is enabled the IOMMU does not properly register credits after the log request has completed, leading to a potential system hang.
BIOSes are supposed to disable L2B micellaneous clock gating by setting L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) = 1b. This patch corrects that for those which do not enable this workaround.
--- drivers/iommu/amd_iommu_init.c | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+)
drivers/iommu/amd_iommu_init.c +34 -0
@@ -975,6 +975,38 @@ static void __init free_iommu_all(void) }/* +* Family15h Model 10h-1fh erratum 746 (IOMMU Logging May Stall Translations) +* Workaround: +* BIOS should disable L2B micellaneous clock gating by setting +* L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) = 1b +*/ +static void __init amd_iommu_erratum_746_workaround (struct amd_iommu *iommu) +{ +u32 value; + +if ((boot_cpu_data.x86 !=0x15 ) || + (boot_cpu_data.x86_model <0x10 ) || + (boot_cpu_data.x86_model >0x1f )) +return ; + +pci_write_config_dword (iommu->dev,0xf0 ,0x90 ); +pci_read_config_dword (iommu->dev,0xf4 , &value); + +if (value &BIT (2 )) +return ; + +/* Select NB indirect register 0x90 and enable writing */ +pci_write_config_dword (iommu->dev,0xf0 ,0x90 | (1 <<8 )); + +pci_write_config_dword (iommu->dev,0xf4 , value |0x4 ); +pr_info ("AMD-Vi: Applying erratum 746 workaround for IOMMU at %s\n" , +dev_name (&iommu->dev->dev)); + +/* Clear the enable writing bit */ +pci_write_config_dword (iommu->dev,0xf0 ,0x90 ); +} + +/* * This function clues the initialization function for one IOMMU * together and also allocates the command buffer and programs the * hardware. It does NOT enable the IOMMU. This is done afterwards.
@@ -1172,6 +1204,8 @@ static int iommu_init_pci(struct amd_iom iommu->stored_l2[i] =iommu_read_l2 (iommu, i); } +amd_iommu_erratum_746_workaround (iommu); +return pci_enable_device (iommu->dev); }
Greg Kroah-Hartman
maintainerPATCH 21/89 xfs: Fix possible use-after-free with AIO
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
commit 4b05d09c18d9aa62d2e7fb4b057f54e5a38963f5 upstream.
Running AIO is pinning inode in memory using file reference. Once AIO is completed using aio_complete(), file reference is put and inode can be freed from memory. So we have to be sure that calling aio_complete() is the last thing we do with the inode.
--- fs/xfs/xfs_aops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/xfs/xfs_aops.c +1 -1
@@ -86,11 +86,11 @@ xfs_destroy_ioend( }if (ioend->io_iocb) { +inode_dio_done (ioend->io_inode);if (ioend->io_isasync) {aio_complete (ioend->io_iocb, ioend->io_error ? ioend->io_error : ioend->io_result,0 ); } -inode_dio_done (ioend->io_inode); }mempool_free (ioend, xfs_ioend_pool);
Greg Kroah-Hartman
maintainerPATCH 22/89 s390/thp: implement pmdp_set_wrprotect()
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gerald Schaefer <[email protected]>
commit be3286507dab888d4aad9f91fd6ff5202b24cd5b upstream.
On s390, an architecture-specific implementation of the function pmdp_set_wrprotect() is missing and the generic version is currently being used. The generic version does not flush the tlb as it would be needed on s390 when modifying an active pmd, which can lead to subtle tlb errors on s390 when using transparent hugepages.
This patch adds an s390-specific implementation of pmdp_set_wrprotect() including the missing tlb flush.
--- arch/s390/include/asm/pgtable.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
arch/s390/include/asm/pgtable.h +12 -0
@@ -1365,6 +1365,18 @@ static inline void pmdp_invalidate(struc__pmd_idte (address, pmdp); } +#define __HAVE_ARCH_PMDP_SET_WRPROTECT +static inline void pmdp_set_wrprotect (struct mm_struct *mm, +unsigned long address,pmd_t *pmdp) +{ +pmd_t pmd = *pmdp; + +if (pmd_write (pmd)) { +__pmd_idte (address, pmdp); +set_pmd_at (mm, address, pmdp,pmd_wrprotect (pmd)); + } +} +static inline pmd_t mk_pmd_phys (unsigned long physpage,pgprot_t pgprot) {pmd_t __pmd;
Greg Kroah-Hartman
maintainerPATCH 23/89 drm/i915: Disable AsyncFlip performance optimisations
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Wilson <[email protected]>
commit 1c8c38c588ea91f8deeae21284840459d1bb58e3 upstream.
This is a required workarounds for all products, especially on gen6+ where it causes the command streamer to fail to parse instructions following a WAIT_FOR_EVENT. We use WAIT_FOR_EVENT for synchronising between the GPU and the display engines, and so this bit being unset may cause hangs.
References: https://bugzilla.kernel.org/show_bug.cgi?id=52311
--- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_ringbuffer.c | 19 +++++++++++++------ 2 files changed, 14 insertions(+), 6 deletions(-)
drivers/gpu/drm/i915/i915_reg.h +1 -0
@@ -527,6 +527,7 @@#define MI_MODE 0x0209c# define VS_TIMER_DISPATCH (1 << 6)# define MI_FLUSH_ENABLE (1 << 12) +# define ASYNC_FLIP_PERF_DISABLE (1 << 14)#define GEN6_GT_MODE 0x20d0#define GEN6_GT_MODE_HI (1 << 9)
drivers/gpu/drm/i915/intel_ringbuffer.c +13 -6
@@ -505,13 +505,20 @@ static int init_render_ring(struct intelstruct drm_i915_private *dev_priv = dev->dev_private;int ret =init_ring_common (ring); -if (INTEL_INFO (dev)->gen >3 ) { +if (INTEL_INFO (dev)->gen >3 )I915_WRITE (MI_MODE ,_MASKED_BIT_ENABLE (VS_TIMER_DISPATCH )); -if (IS_GEN7 (dev)) -I915_WRITE (GFX_MODE_GEN7 , -_MASKED_BIT_DISABLE (GFX_TLB_INVALIDATE_ALWAYS ) | -_MASKED_BIT_ENABLE (GFX_REPLAY_MODE )); - } + +/* We need to disable the AsyncFlip performance optimisations in order +* to use MI_WAIT_FOR_EVENT within the CS. It should already be +* programmed to '1' on all products. +*/ +if (INTEL_INFO (dev)->gen >=6 ) +I915_WRITE (MI_MODE ,_MASKED_BIT_ENABLE (ASYNC_FLIP_PERF_DISABLE )); + +if (IS_GEN7 (dev)) +I915_WRITE (GFX_MODE_GEN7 , +_MASKED_BIT_DISABLE (GFX_TLB_INVALIDATE_ALWAYS ) | +_MASKED_BIT_ENABLE (GFX_REPLAY_MODE ));if (INTEL_INFO (dev)->gen >=5 ) { ret =init_pipe_control (ring);
Greg Kroah-Hartman
maintainerPATCH 24/89 drm/i915: GFX_MODE Flush TLB Invalidate Mode must be 1 for scanline waits
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Wilson <[email protected]>
commit f05bb0c7b624252a5e768287e340e8e45df96e42 upstream.
On SNB, if bit 13 of GFX_MODE, Flush TLB Invalidate Mode, is not set to 1, the hardware can not program the scanline values. Those scanline values then control when the signal is sent from the display engine to the render ring for MI_WAIT_FOR_EVENTs. Note setting this bit means that TLB invalidations must be performed explicitly through the appropriate bits being set in PIPE_CONTROL.
References: https://bugzilla.kernel.org/show_bug.cgi?id=52311
--- drivers/gpu/drm/i915/intel_ringbuffer.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/gpu/drm/i915/intel_ringbuffer.c +5 -0
@@ -515,6 +515,11 @@ static int init_render_ring(struct intelif (INTEL_INFO (dev)->gen >=6 )I915_WRITE (MI_MODE ,_MASKED_BIT_ENABLE (ASYNC_FLIP_PERF_DISABLE )); +/* Required for the hardware to program scanline values for waiting */ +if (INTEL_INFO (dev)->gen ==6 ) +I915_WRITE (GFX_MODE , +_MASKED_BIT_ENABLE (GFX_TLB_INVALIDATE_ALWAYS )); +if (IS_GEN7 (dev)) I915_WRITE(GFX_MODE_GEN7, _MASKED_BIT_DISABLE(GFX_TLB_INVALIDATE_ALWAYS) |
Greg Kroah-Hartman
maintainerPATCH 25/89 drm/i915: dump UTS_RELEASE into the error_state
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Vetter <[email protected]>
commit 4518f611ba21ba165ea3714055938a8984a44ff9 upstream.
Useful for statistics or on overflowing bug reports to keep things all lined up.
--- drivers/gpu/drm/i915/i915_debugfs.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/gpu/drm/i915/i915_debugfs.c +2 -0
@@ -30,6 +30,7 @@#include <linux/debugfs.h> #include <linux/slab.h> #include <linux/export.h> +#include <generated/utsrelease.h> #include <drm/drmP.h> #include "intel_drv.h" #include "intel_ringbuffer.h"
@@ -687,6 +688,7 @@ static int i915_error_state(struct seq_fseq_printf (m,"Time: %ld s %ld us\n" , error->time.tv_sec, error->time.tv_usec); +seq_printf (m,"Kernel: " UTS_RELEASE );seq_printf (m,"PCI ID: 0x%04x\n" , dev->pci_device);seq_printf (m,"EIR: 0x%08x\n" , error->eir);seq_printf (m,"IER: 0x%08x\n" , error->ier);
Greg Kroah-Hartman
maintainerPATCH 26/89 mwifiex: update config_bands during infra association
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Amitkumar Karwar <[email protected]>
commit d7b9c5204e9c6810a20d509ee47bc70419096e59 upstream.
Currently "adapter->config_bands" is updated during infra association only if channel is provided by user in "iw connect" command. config_bands is used while preparing association request to calculate supported rates by intersecting our rates with the rates advertised by AP.
There is corner case in which we include zero rates in supported rates TLV based on previous IBSS network history, which leads to association failure.
This patch fixes the problem by correctly updating config_bands.
--- drivers/net/wireless/mwifiex/cfg80211.c | 15 +-------------- drivers/net/wireless/mwifiex/sta_ioctl.c | 14 ++++++++++++++ 2 files changed, 15 insertions(+), 14 deletions(-)
drivers/net/wireless/mwifiex/cfg80211.c +1 -14
@@ -1462,7 +1462,7 @@ mwifiex_cfg80211_assoc(struct mwifiex_prstruct cfg80211_ssid req_ssid;int ret, auth_type =0 ;struct cfg80211_bss *bss =NULL ; -u8 is_scanning_required =0 , config_bands =0 ; +u8 is_scanning_required =0 ;memset (&req_ssid,0 ,sizeof (struct cfg80211_ssid ));
@@ -1481,19 +1481,6 @@ mwifiex_cfg80211_assoc(struct mwifiex_pr/* disconnect before try to associate */ mwifiex_deauthenticate (priv,NULL ); -if (channel) { -if (mode ==NL80211_IFTYPE_STATION ) { -if (channel->band ==IEEE80211_BAND_2GHZ ) - config_bands =BAND_B |BAND_G |BAND_GN ; -else - config_bands =BAND_A |BAND_AN ; - -if (!((config_bands | priv->adapter->fw_bands) & - ~priv->adapter->fw_bands)) - priv->adapter->config_bands = config_bands; - } - } -/* As this is new association, clear locally stored * keys and security related flags */ priv->sec_info.wpa_enabled = false;
drivers/net/wireless/mwifiex/sta_ioctl.c +14 -0
@@ -265,6 +265,20 @@ int mwifiex_bss_start(struct mwifiex_priif (ret) goto done; +if (bss_desc) { +u8 config_bands =0 ; + +if (mwifiex_band_to_radio_type ((u8 ) bss_desc->bss_band) + == HostCmd_SCAN_RADIO_TYPE_BG) + config_bands =BAND_B |BAND_G |BAND_GN ; +else + config_bands =BAND_A |BAND_AN ; + +if (!((config_bands | adapter->fw_bands) & + ~adapter->fw_bands)) + adapter->config_bands = config_bands; + } + ret =mwifiex_check_network_compatibility (priv, bss_desc);if (ret) goto done;
Re: [ 26/89] mwifiex: update config_bands during infra association
Quoted 18 lines · Greg Kroah-Hartman
3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Amitkumar Karwar <[email protected]>
commit
d7b9c5204e9c6810a20d509ee47bc70419096e59upstream.Currently "
adapter->config_bands" is updated during infra association only if channel is provided by user in "iw connect" command.config_bandsis used while preparing association request to calculate supported rates by intersecting our rates with the rates advertised by AP.There is corner case in which we include zero rates in supported rates TLV based on previous IBSS network history, which leads to association failure.
Quoted 6 lines
This patch fixes the problem by correctly updating
config_bands.Signed-off-by Amitkumar Karwar <[email protected]>Signed-off-by Bing Zhao <[email protected]>Signed-off-by John W. Linville <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>
[...]
Is this fix needed for earlier kernel versions (3.0, 3.2, 3.4)? If so, could you provide backports?
Ben.
Signature · 3 lines
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
- Albert EinsteinRE: [ 26/89] mwifiex: update config_bands during infra association
Hi Ben,
Quoted 16 lines
Quoted 16 lines
From: Amitkumar Karwar <[email protected]>
commit
d7b9c5204e9c6810a20d509ee47bc70419096e59upstream.Currently "
adapter->config_bands" is updated during infra association only if channel is provided by user in "iw connect" command.config_bandsis used while preparing association request to calculate supported rates by intersecting our rates with the rates advertised by AP.There is corner case in which we include zero rates in supported rates TLV based on previous IBSS network history, which leads to association failure.
This patch fixes the problem by correctly updating
config_bands.
Quoted 8 lines
Quoted 4 lines
Signed-off-by Amitkumar Karwar <[email protected]>Signed-off-by Bing Zhao <[email protected]>Signed-off-by John W. Linville <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>[...]
Is this fix needed for earlier kernel versions (3.0, 3.2, 3.4)? If so, could you provide backports?
This patch is not needed for earlier kernel 3.0, 3.2, and 3.4.
Thanks,
Bing
Greg Kroah-Hartman
maintainerPATCH 27/89 mwifiex: fix typo in PCIe adapter NULL check
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Avinash Patil <[email protected]>
commit 83f0c6d1f502bd75bb4a9e31e8d64e59c6894ad1 upstream.
Add missing "!" as we are supposed to check "!card->adapter" in PCIe suspend handler.
--- drivers/net/wireless/mwifiex/pcie.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/mwifiex/pcie.c +1 -1
@@ -161,7 +161,7 @@ static int mwifiex_pcie_suspend(struct pif (pdev) { card = (struct pcie_service_card *)pci_get_drvdata (pdev); -if (!card || card->adapter) { +if (!card || !card->adapter) {pr_err ("Card or adapter structure is not valid\n" );return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 28/89 iwlegacy: fix IBSS cleanup
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanislaw Gruszka <[email protected]>
commit fa4cffcba9e13798ed7c6b8526b91b1631ecb53e upstream.
We do not correctly change interface type when switching from IBSS mode to STA mode, that results in microcode errors.
Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=886946
--- drivers/net/wireless/iwlegacy/common.c | 35 +++++++++++++-------------------- 1 file changed, 14 insertions(+), 21 deletions(-)
drivers/net/wireless/iwlegacy/common.c +14 -21
@@ -3957,17 +3957,21 @@ il_connection_init_rx_config(struct il_pmemset (&il->staging,0 ,sizeof (il->staging)); -if (!il->vif) { +switch (il->iw_mode) { +case NL80211_IFTYPE_UNSPECIFIED : il->staging.dev_type =RXON_DEV_TYPE_ESS ; - }else if (il->vif->type ==NL80211_IFTYPE_STATION ) { +break ; +case NL80211_IFTYPE_STATION : il->staging.dev_type =RXON_DEV_TYPE_ESS ; il->staging.filter_flags =RXON_FILTER_ACCEPT_GRP_MSK ; - }else if (il->vif->type ==NL80211_IFTYPE_ADHOC ) { +break ; +case NL80211_IFTYPE_ADHOC : il->staging.dev_type =RXON_DEV_TYPE_IBSS ; il->staging.flags =RXON_FLG_SHORT_PREAMBLE_MSK ; il->staging.filter_flags =RXON_FILTER_BCON_AWARE_MSK |RXON_FILTER_ACCEPT_GRP_MSK ; - }else { +break ; +default :IL_ERR ("Unsupported interface type %d\n" , il->vif->type);return ; }
@@ -4550,8 +4554,7 @@ out:EXPORT_SYMBOL (il_mac_add_interface);static void -il_teardown_interface (struct il_priv *il,struct ieee80211_vif *vif, -bool mode_change) +il_teardown_interface (struct il_priv *il,struct ieee80211_vif *vif) {lockdep_assert_held (&il->mutex);
@@ -4560,9 +4563,7 @@ il_teardown_interface(struct il_priv *ilil_force_scan_end (il); } -if (!mode_change) -il_set_mode (il); - +il_set_mode (il); }void
@@ -4575,8 +4576,8 @@ il_mac_remove_interface(struct ieee80211WARN_ON (il->vif != vif); il->vif =NULL ; - -il_teardown_interface (il, vif, false); + il->iw_mode =NL80211_IFTYPE_UNSPECIFIED ; +il_teardown_interface (il, vif);memset (il->bssid,0 ,ETH_ALEN );D_MAC80211 ("leave\n" );
@@ -4685,18 +4686,10 @@ il_mac_change_interface(struct ieee80211 }/* success */ -il_teardown_interface (il, vif, true); vif->type = newtype; vif->p2p = false; - err =il_set_mode (il); -WARN_ON (err); -/* -* We've switched internally, but submitting to the -* device may have failed for some reason. Mask this -* error, because otherwise mac80211 will not switch -* (and set the interface type back) and we'll be -* out of sync with it. -*/ + il->iw_mode = newtype; +il_teardown_interface (il, vif); err =0 ; out:
Greg Kroah-Hartman
maintainerPATCH 29/89 brcmsmac: increase timer reference count for new timers only
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Piotr Haber <[email protected]>
commit a1fe52801a992e590cdaee2fb47a94bac9b5da90 upstream.
On hardware reintialization reference count of already existing timers would be increased again. This leads to problems on module unloading.
--- drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c +4 -3
@@ -1401,9 +1401,10 @@ void brcms_add_timer(struct brcms_timer#endif t->ms = ms; t->periodic = (bool ) periodic; - t->set = true; - -atomic_inc (&t->wl->callbacks); +if (!t->set) { + t->set = true; +atomic_inc (&t->wl->callbacks); + }ieee80211_queue_delayed_work (hw, &t->dly_wrk,msecs_to_jiffies (ms)); }
Greg Kroah-Hartman
maintainerPATCH 30/89 brcmsmac: handle packet drop during transmit correctly
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Piotr Haber <[email protected]>
commit c4dea35e34f5f46e1701156153a09cce429d1ea9 upstream.
The .tx() callback function can drop packets when there is no space in the DMA fifo. Propagate that information to caller and make sure the freed sk_buff reference is not accessed.
--- drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c | 4 ++-- drivers/net/wireless/brcm80211/brcmsmac/main.c | 14 +++++++++----- drivers/net/wireless/brcm80211/brcmsmac/main.h | 2 +- drivers/net/wireless/brcm80211/brcmsmac/pub.h | 2 +- 4 files changed, 13 insertions(+), 9 deletions(-)
drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c +2 -2
@@ -280,8 +280,8 @@ static void brcms_ops_tx(struct ieee8021kfree_skb (skb); goto done; } -brcms_c_sendpkt_mac80211 (wl->wlc, skb, hw); - tx_info->rate_driver_data[0 ] = control->sta; +if (brcms_c_sendpkt_mac80211 (wl->wlc, skb, hw)) + tx_info->rate_driver_data[0 ] = control->sta; done:spin_unlock_bh (&wl->lock); }
drivers/net/wireless/brcm80211/brcmsmac/main.c +9 -5
@@ -6095,7 +6095,7 @@ static bool brcms_c_prec_enq(struct brcmreturn brcms_c_prec_enq_head (wlc, q, pkt, prec, false); } -void brcms_c_txq_enq (struct brcms_c_info *wlc,struct scb *scb, +bool brcms_c_txq_enq (struct brcms_c_info *wlc,struct scb *scb,struct sk_buff *sdu,uint prec) {struct brcms_txq_info *qi = wlc->pkt_queue;/* Check me */
@@ -6110,7 +6110,9 @@ void brcms_c_txq_enq(struct brcms_c_info* packet flooding from mac80211 stack */ brcmu_pkt_buf_free_skb (sdu); +return false; } +return true; }/*
@@ -7273,7 +7275,7 @@ brcms_c_d11hdrs_mac80211(struct brcms_c_return 0 ; } -void brcms_c_sendpkt_mac80211 (struct brcms_c_info *wlc,struct sk_buff *sdu, +bool brcms_c_sendpkt_mac80211 (struct brcms_c_info *wlc,struct sk_buff *sdu,struct ieee80211_hw *hw) {u8 prio;
@@ -7288,10 +7290,12 @@ void brcms_c_sendpkt_mac80211(struct brc prio =ieee80211_is_data (d11_header->frame_control) ? sdu->priority :MAXPRIO ; fifo = prio2fifo[prio]; -if (brcms_c_d11hdrs_mac80211 (wlc, hw, sdu, scb,0 ,1 , fifo,0 )) -return ; -brcms_c_txq_enq (wlc, scb, sdu,BRCMS_PRIO_TO_PREC (prio)); +brcms_c_d11hdrs_mac80211 (wlc, hw, sdu, scb,0 ,1 , fifo,0 ); +if (!brcms_c_txq_enq (wlc, scb, sdu,BRCMS_PRIO_TO_PREC (prio))) +return false;brcms_c_send_q (wlc); + +return true; }void brcms_c_send_q (struct brcms_c_info *wlc)
drivers/net/wireless/brcm80211/brcmsmac/main.h +1 -1
@@ -642,7 +642,7 @@ extern void brcms_c_txfifo(struct brcms_ bool commit, s8 txpktpend);extern void brcms_c_txfifo_complete (struct brcms_c_info *wlc,uint fifo,s8 txpktpend); -extern void brcms_c_txq_enq (struct brcms_c_info *wlc,struct scb *scb, +extern bool brcms_c_txq_enq (struct brcms_c_info *wlc,struct scb *scb,struct sk_buff *sdu,uint prec);extern void brcms_c_print_txstatus (struct tx_status *txs); extern int brcms_b_xmtfifo_sz_get(struct brcms_hardware *wlc_hw, uint fifo,
drivers/net/wireless/brcm80211/brcmsmac/pub.h +1 -1
@@ -321,7 +321,7 @@ extern void brcms_c_intrsrestore(structextern bool brcms_c_intrsupd (struct brcms_c_info *wlc);extern bool brcms_c_isr (struct brcms_c_info *wlc,bool *wantdpc);extern bool brcms_c_dpc (struct brcms_c_info *wlc,bool bounded); -extern void brcms_c_sendpkt_mac80211 (struct brcms_c_info *wlc, +extern bool brcms_c_sendpkt_mac80211 (struct brcms_c_info *wlc,struct sk_buff *sdu,struct ieee80211_hw *hw);extern bool brcms_c_aggregatable (struct brcms_c_info *wlc,u8 tid);
Greg Kroah-Hartman
maintainerPATCH 31/89 DM-RAID: Fix RAID10s check for sufficient redundancy
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jonathan Brassow <[email protected]>
commit 55ebbb59c1c6eb1b040f62b8c4ae0b724de6e55a upstream.
Before attempting to activate a RAID array, it is checked for sufficient redundancy. That is, we make sure that there are not too many failed devices - or devices specified for rebuild - to undermine our ability to activate the array. The current code performs this check twice - once to ensure there were not too many devices specified for rebuild by the user ('validate_rebuild_devices') and again after possibly experiencing a failure to read the superblock ('analyse_superblocks'). Neither of these checks are sufficient. The first check is done properly but with insufficient information about the possible failure state of the devices to make a good determination if the array can be activated. The second check is simply done wrong in the case of RAID10 because it doesn't account for the independence of the stripes (i.e. mirror sets). The solution is to use the properly written check ('validate_rebuild_devices'), but perform the check after the superblocks have been read and we know which devices have failed. This gives us one check instead of two and performs it in a location where it can be done right.
Only RAID10 was affected and it was affected in the following ways:
- the code did not properly catch the condition where a user specified a device for rebuild that already had a failed device in the same mirror set. (This condition would, however, be caught at a deeper level in MD.)
- the code triggers a false positive and denies activation when devices in independent mirror sets have failed - counting the failures as though they were all in the same set.
The most likely place this error was introduced (or this patch should have been included) is in commit 4ec1e369 - first introduced in v3.7-rc1. Consequently this fix should also go in v3.7.y, however there is a small conflict on the .version in raid_target, so I'll submit a separate patch to -stable.
--- Documentation/device-mapper/dm-raid.txt | 1 drivers/md/dm-raid.c | 101 +++++++++++--------------------- 2 files changed, 38 insertions(+), 64 deletions(-)
Documentation/device-mapper/dm-raid.txt +1 -0
@@ -141,3 +141,4 @@ Version History 1.2.0 Handle creation of arrays that contain failed devices. 1.3.0 Added support for RAID 10 1.3.1 Allow device replacement/rebuild for RAID 10 +1.3.2 Fix/improve redundancy checking for RAID10
drivers/md/dm-raid.c +37 -64
176 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 32/89 mac80211: synchronize scan off/on-channel and PS states
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanislaw Gruszka <[email protected]>
commit aacde9ee45225f7e0b90960f479aef83c66bfdc0 upstream.
Since:
commit b23b025fe246f3acc2988eb6d400df34c27cb8ae
Author: Ben Greear <[email protected]> Date: Fri Feb 4 11:54:17 2011 -0800
mac80211: Optimize scans on current operating channel.
we do not disable PS while going back to operational channel (on ieee80211_scan_state_suspend) and deffer that until scan finish. But since we are allowed to send frames, we can send a frame to AP without PM bit set, so disable PS on AP side. Then when we switch to off-channel (in ieee80211_scan_state_resume) we do not enable PS. Hence we are off-channel with PS disabled, frames are not buffered by AP.
To fix remove offchannel_ps_disable argument and always enable PS when going off-channel and disable it when going on-channel, like it was before.
--- net/mac80211/ieee80211_i.h | 6 ++---- net/mac80211/offchannel.c | 19 +++++++------------ net/mac80211/scan.c | 15 +++++---------- 3 files changed, 14 insertions(+), 26 deletions(-)
net/mac80211/ieee80211_i.h +2 -4
@@ -1279,10 +1279,8 @@ int ieee80211_request_sched_scan_stop(stvoid ieee80211_sched_scan_stopped_work (struct work_struct *work);/* off-channel helpers */ -void ieee80211_offchannel_stop_vifs (struct ieee80211_local *local, -bool offchannel_ps_enable); -void ieee80211_offchannel_return (struct ieee80211_local *local, -bool offchannel_ps_disable); +void ieee80211_offchannel_stop_vifs (struct ieee80211_local *local); +void ieee80211_offchannel_return (struct ieee80211_local *local);void ieee80211_roc_setup (struct ieee80211_local *local);void ieee80211_start_next_roc (struct ieee80211_local *local);void ieee80211_roc_purge (struct ieee80211_sub_if_data *sdata);
net/mac80211/offchannel.c +7 -12
@@ -102,8 +102,7 @@ static void ieee80211_offchannel_ps_disaieee80211_sta_reset_conn_monitor (sdata); } -void ieee80211_offchannel_stop_vifs (struct ieee80211_local *local, -bool offchannel_ps_enable) +void ieee80211_offchannel_stop_vifs (struct ieee80211_local *local) {struct ieee80211_sub_if_data *sdata;
@@ -131,8 +130,7 @@ void ieee80211_offchannel_stop_vifs(struif (sdata->vif.type !=NL80211_IFTYPE_MONITOR ) {netif_tx_stop_all_queues (sdata->dev); -if (offchannel_ps_enable && - (sdata->vif.type ==NL80211_IFTYPE_STATION ) && +if (sdata->vif.type ==NL80211_IFTYPE_STATION && sdata->u.mgd.associated)ieee80211_offchannel_ps_enable (sdata); }
@@ -140,8 +138,7 @@ void ieee80211_offchannel_stop_vifs(strumutex_unlock (&local->iflist_mtx); } -void ieee80211_offchannel_return (struct ieee80211_local *local, -bool offchannel_ps_disable) +void ieee80211_offchannel_return (struct ieee80211_local *local) {struct ieee80211_sub_if_data *sdata;
@@ -157,11 +154,9 @@ void ieee80211_offchannel_return(structcontinue ;/* Tell AP we're back */ -if (offchannel_ps_disable && - sdata->vif.type ==NL80211_IFTYPE_STATION ) { -if (sdata->u.mgd.associated) -ieee80211_offchannel_ps_disable (sdata); - } +if (sdata->vif.type ==NL80211_IFTYPE_STATION && + sdata->u.mgd.associated) +ieee80211_offchannel_ps_disable (sdata);if (sdata->vif.type !=NL80211_IFTYPE_MONITOR ) {/*
@@ -381,7 +376,7 @@ void ieee80211_sw_roc_work(struct work_s local->tmp_channel =NULL ;ieee80211_hw_config (local,0 ); -ieee80211_offchannel_return (local, true); +ieee80211_offchannel_return (local); }ieee80211_recalc_idle (local);
net/mac80211/scan.c +5 -10
@@ -310,7 +310,7 @@ static void __ieee80211_scan_completed(sif (!was_hw_scan) {ieee80211_configure_filter (local);drv_sw_scan_complete (local); -ieee80211_offchannel_return (local, true); +ieee80211_offchannel_return (local); }ieee80211_recalc_idle (local);
@@ -355,7 +355,7 @@ static int ieee80211_start_sw_scan(struc local->next_scan_state =SCAN_DECISION ; local->scan_channel_idx =0 ; -ieee80211_offchannel_stop_vifs (local, true); +ieee80211_offchannel_stop_vifs (local);ieee80211_configure_filter (local);
@@ -680,12 +680,8 @@ static void ieee80211_scan_state_suspend local->scan_channel =NULL ;ieee80211_hw_config (local,IEEE80211_CONF_CHANGE_CHANNEL ); -/* -* Re-enable vifs and beaconing. Leave PS -* in off-channel state..will put that back -* on-channel at the end of scanning. -*/ -ieee80211_offchannel_return (local, false); +/* disable PS */ +ieee80211_offchannel_return (local); *next_delay =HZ /5 ;/* afterwards, resume scan & go to next channel */
@@ -695,8 +691,7 @@ static void ieee80211_scan_state_suspendstatic void ieee80211_scan_state_resume (struct ieee80211_local *local,unsigned long *next_delay) { -/* PS already is in off-channel mode */ -ieee80211_offchannel_stop_vifs (local, false); +ieee80211_offchannel_stop_vifs (local);if (local->ops->flush) {drv_flush (local, false);
Greg Kroah-Hartman
maintainerPATCH 33/89 mac80211: fix FT roaming
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <[email protected]>
commit 1626e0fa740dec8665a973cf2349405cdfeb46dc upstream.
During FT roaming, wpa_supplicant attempts to set the key before association. This used to be rejected, but as a side effect of my commit 66e67e418908442389d3a9e ("mac80211: redesign auth/assoc") the key was accepted causing hardware crypto to not be used for it as the station isn't added to the driver yet.
It would be possible to accept the key and then add it to the driver when the station has been added. However, this may run into issues with drivers using the state- based station adding if they accept the key only after association like it used to be.
For now, revert to the behaviour from before the auth and assoc change.
--- net/mac80211/cfg.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
net/mac80211/cfg.c +11 -1
@@ -164,7 +164,17 @@ static int ieee80211_add_key(struct wiph sta =sta_info_get (sdata, mac_addr); else sta =sta_info_get_bss (sdata, mac_addr); -if (!sta) { +/* +* The ASSOC test makes sure the driver is ready to +* receive the key. When wpa_supplicant has roamed +* using FT, it attempts to set the key before +* association has completed, this rejects that attempt +* so it will set the key again after assocation. +* +* TODO: accept the key if we have a station entry and +* add it to the device after the station. +*/ +if (!sta || !test_sta_flag (sta,WLAN_STA_ASSOC )) {ieee80211_key_free (sdata->local, key); err = -ENOENT ; goto out_unlock;
Greg Kroah-Hartman
maintainerPATCH 34/89 ath9k_htc: Fix memory leak
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sujith Manoharan <[email protected]>
commit 0981c3b24ef664f5611008a6e6d0622fac6d892b upstream.
SKBs that are allocated in the HTC layer do not have callbacks registered and hence ended up not being freed, Fix this by freeing them properly in the TX completion routine.
--- drivers/net/wireless/ath/ath9k/htc_hst.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/wireless/ath/ath9k/htc_hst.c +2 -0
@@ -344,6 +344,8 @@ void ath9k_htc_txcompletion_cb(struct ht endpoint->ep_callbacks.tx (endpoint->ep_callbacks.priv, skb, htc_hdr->endpoint_id, txok); + }else { +kfree_skb (skb); } }
Greg Kroah-Hartman
maintainerPATCH 35/89 ath9k: do not link receive buffers during flush
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
commit a3dc48e82bb146ef11cf75676c8410c1df29b0c4 upstream.
On AR9300 the rx FIFO needs to be empty during reset to ensure that no further DMA activity is generated, otherwise it might lead to memory corruption issues.
--- drivers/net/wireless/ath/ath9k/recv.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/net/wireless/ath/ath9k/recv.c +6 -4
@@ -744,6 +744,7 @@ static struct ath_buf *ath_get_next_rx_breturn NULL ; } +list_del (&bf->list);if (!bf->bf_mpdu)return bf;
@@ -1251,14 +1252,15 @@ requeue_drop_frag: sc->rx.frag =NULL ; } requeue: +list_add_tail (&bf->list, &sc->rx.rxbuf); +if (flush) +continue ; +if (edma) { -list_add_tail (&bf->list, &sc->rx.rxbuf);ath_rx_edma_buf_link (sc, qtype); }else { -list_move_tail (&bf->list, &sc->rx.rxbuf);ath_rx_buf_link (sc, bf); -if (!flush) -ath9k_hw_rxena (ah); +ath9k_hw_rxena (ah); } }while (1 );
Greg Kroah-Hartman
maintainerPATCH 36/89 ath9k: fix double-free bug on beacon generate failure
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
commit 1adb2e2b5f85023d17eb4f95386a57029df27c88 upstream.
When the next beacon is sent, the ath_buf from the previous run is reused. If getting a new beacon from mac80211 fails, bf->bf_mpdu is not reset, yet the skb is freed, leading to a double-free on the next beacon tx attempt, resulting in a system crash.
--- drivers/net/wireless/ath/ath9k/beacon.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/wireless/ath/ath9k/beacon.c +1 -0
@@ -147,6 +147,7 @@ static struct ath_buf *ath9k_beacon_gene skb->len, DMA_TO_DEVICE);dev_kfree_skb_any (skb); bf->bf_buf_addr =0 ; + bf->bf_mpdu =NULL ; } skb =ieee80211_beacon_get (hw, vif);
Greg Kroah-Hartman
maintainerPATCH 37/89 ath9k: remove the WARN_ON that triggers if generating a beacon fails
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
commit 3adcf20afb585993ffee24de36d1975f6b26b120 upstream.
During teardown, mac80211 will not return a new beacon. This is normal and handled properly in the driver, so there's no need to spam the user with a kernel warning here.
--- drivers/net/wireless/ath/ath9k/beacon.c | 1 - 1 file changed, 1 deletion(-)
drivers/net/wireless/ath/ath9k/beacon.c +0 -1
@@ -360,7 +360,6 @@ void ath9k_beacon_tasklet(unsigned longreturn ; bf =ath9k_beacon_generate (sc->hw, vif); -WARN_ON (!bf);if (sc->beacon.bmisscnt !=0 ) { ath_dbg(common, BSTUCK, "resume beacon xmit after %u misses\n",
Greg Kroah-Hartman
maintainerPATCH 38/89 ath9k: add a better fix for the rx tasklet vs rx flush race
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
commit 7fc00a3054b70b1794c2d64db703eb467ad0365c upstream.
Ensure that the rx tasklet is no longer running when entering the reset path. Also remove the distinction between flush and no-flush frame processing. If a frame has been received and ACKed by the hardware, the stack needs to see it, so that the BA receive window does not go out of sync.
--- drivers/net/wireless/ath/ath9k/ath9k.h | 1 - drivers/net/wireless/ath/ath9k/debug.c | 1 - drivers/net/wireless/ath/ath9k/debug.h | 2 -- drivers/net/wireless/ath/ath9k/main.c | 4 ++++ drivers/net/wireless/ath/ath9k/recv.c | 15 --------------- 5 files changed, 4 insertions(+), 19 deletions(-)
drivers/net/wireless/ath/ath9k/ath9k.h +0 -1
@@ -630,7 +630,6 @@ void ath_ant_comb_update(struct ath_softenum sc_op_flags {SC_OP_INVALID ,SC_OP_BEACONS , -SC_OP_RXFLUSH ,SC_OP_ANI_RUN ,SC_OP_PRIM_STA_VIF ,SC_OP_HW_RESET ,
drivers/net/wireless/ath/ath9k/debug.c +0 -1
@@ -973,7 +973,6 @@ static ssize_t read_file_recv(struct filRXS_ERR ("RX-LENGTH-ERR" , rx_len_err);RXS_ERR ("RX-OOM-ERR" , rx_oom_err);RXS_ERR ("RX-RATE-ERR" , rx_rate_err); -RXS_ERR ("RX-DROP-RXFLUSH" , rx_drop_rxflush);RXS_ERR ("RX-TOO-MANY-FRAGS" , rx_too_many_frags_err);PHY_ERR ("UNDERRUN ERR" ,ATH9K_PHYERR_UNDERRUN );
drivers/net/wireless/ath/ath9k/debug.h +0 -2
@@ -200,7 +200,6 @@ struct ath_tx_stats {* @rx_oom_err: No. of frames dropped due to OOM issues. * @rx_rate_err: No. of frames dropped due to rate errors. * @rx_too_many_frags_err: Frames dropped due to too-many-frags received. -* @rx_drop_rxflush: No. of frames dropped due to RX-FLUSH. * @rx_beacons: No. of beacons received. * @rx_frags: No. of rx-fragements received. */
@@ -219,7 +218,6 @@ struct ath_rx_stats {u32 rx_oom_err;u32 rx_rate_err;u32 rx_too_many_frags_err; -u32 rx_drop_rxflush;u32 rx_beacons;u32 rx_frags; };
drivers/net/wireless/ath/ath9k/main.c +4 -0
@@ -195,6 +195,8 @@ static bool ath_prepare_reset(struct athath9k_debug_samp_bb_mac (sc);ath9k_hw_disable_interrupts (ah); +tasklet_disable (&sc->intr_tq); +if (!ath_stoprecv (sc)) ret = false;
@@ -209,6 +211,8 @@ static bool ath_prepare_reset(struct athath_flushrecv (sc); } +tasklet_enable (&sc->intr_tq); +return ret; }
drivers/net/wireless/ath/ath9k/recv.c +0 -15
@@ -286,7 +286,6 @@ int ath_rx_init(struct ath_softc *sc, inspin_lock_init (&sc->sc_pcu_lock);spin_lock_init (&sc->rx.rxbuflock); -clear_bit (SC_OP_RXFLUSH , &sc->sc_flags); common->rx_bufsize =IEEE80211_MAX_MPDU_LEN /2 + sc->sc_ah->caps.rx_status_len;
@@ -501,11 +500,9 @@ bool ath_stoprecv(struct ath_softc *sc)void ath_flushrecv (struct ath_softc *sc) { -set_bit (SC_OP_RXFLUSH , &sc->sc_flags);if (sc->sc_ah->caps.hw_caps &ATH9K_HW_CAP_EDMA )ath_rx_tasklet (sc,1 , true);ath_rx_tasklet (sc,1 , false); -clear_bit (SC_OP_RXFLUSH , &sc->sc_flags); }static bool ath_beacon_dtim_pending_cab (struct sk_buff *skb)
@@ -1067,9 +1064,6 @@ int ath_rx_tasklet(struct ath_softc *sc, do { bool decrypt_error = false; - /* If handling rx interrupt and flush is in progress => exit */ - if (test_bit(SC_OP_RXFLUSH, &sc->sc_flags) && (flush == 0)) - break; memset(&rs, 0, sizeof(rs)); if (edma)
@@ -1109,15 +1103,6 @@ int ath_rx_tasklet(struct ath_softc *sc, sc->rx.num_pkts++;ath_debug_stat_rx (sc, &rs); -/* -* If we're asked to flush receive queue, directly -* chain it back at the queue without processing it. -*/ -if (test_bit (SC_OP_RXFLUSH , &sc->sc_flags)) { -RX_STAT_INC (rx_drop_rxflush); - goto requeue_drop_frag; - } -memset (rxs,0 ,sizeof (struct ieee80211_rx_status )); rxs->mactime = (tsf & ~0xffffffffULL ) | rs.rs_tstamp;
Re: [ 38/89] ath9k: add a better fix for the rx tasklet vs rx flush race
Quoted 8 lines · Greg Kroah-Hartman
3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
commit
7fc00a3054b70b1794c2d64db703eb467ad0365cupstream.
Quoted 8 lines
Ensure that the rx tasklet is no longer running when entering the reset path. Also remove the distinction between flush and no-flush frame processing. If a frame has been received and ACKed by the hardware, the stack needs to see it, so that the BA receive window does not go out of sync.
Signed-off-by Felix Fietkau <[email protected]>Signed-off-by John W. Linville <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>
[...]
Are this and the following 3 fixes required for earlier kernel versions )3.0, 3.2, 3.4)? If so, could you provide backports?
Ben.
Signature · 3 lines
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
- Albert EinsteinGreg Kroah-Hartman
maintainerPATCH 39/89 ath9k: fix rx flush handling
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
commit 4b883f021b9ccf2df3d14425e6e610281fb6a35e upstream.
Right now the rx flush is not doing anything useful on AR9003+, as it only works if the buffers in the rx FIFO have not been purged yet, as is done by ath_stoprecv.
To fix this, always call ath_flushrecv from within ath_stoprecv before the FIFO is emptied, but still after the hw receive path has been stopped.
This ensures that frames received (and ACKed by the hardware) shortly before a reset will be seen by the software, which should improve A-MPDU session stability.
--- drivers/net/wireless/ath/ath9k/ath9k.h | 1 - drivers/net/wireless/ath/ath9k/main.c | 16 +++------------- drivers/net/wireless/ath/ath9k/recv.c | 16 +++++++++------- 3 files changed, 12 insertions(+), 21 deletions(-)
drivers/net/wireless/ath/ath9k/ath9k.h +0 -1
@@ -326,7 +326,6 @@ struct ath_rx {int ath_startrecv (struct ath_softc *sc);bool ath_stoprecv (struct ath_softc *sc); -void ath_flushrecv (struct ath_softc *sc);u32 ath_calcrxfilter (struct ath_softc *sc);int ath_rx_init (struct ath_softc *sc,int nbufs);void ath_rx_cleanup (struct ath_softc *sc);
drivers/net/wireless/ath/ath9k/main.c +3 -13
@@ -181,7 +181,7 @@ static void ath_restart_work(struct ath_ath_start_ani (sc); } -static bool ath_prepare_reset (struct ath_softc *sc,bool retry_tx,bool flush) +static bool ath_prepare_reset (struct ath_softc *sc,bool retry_tx) {struct ath_hw *ah = sc->sc_ah;bool ret = true;
@@ -203,14 +203,6 @@ static bool ath_prepare_reset(struct athif (!ath_drain_all_txq (sc, retry_tx)) ret = false; -if (!flush) { -if (ah->caps.hw_caps &ATH9K_HW_CAP_EDMA ) -ath_rx_tasklet (sc,1 , true); -ath_rx_tasklet (sc,1 , false); - }else { -ath_flushrecv (sc); - } -tasklet_enable (&sc->intr_tq);return ret;
@@ -265,7 +257,6 @@ static int ath_reset_internal(struct athstruct ath_common *common =ath9k_hw_common (ah);struct ath9k_hw_cal_data *caldata =NULL ;bool fastcc = true; -bool flush = false;int r;__ath_cancel_work (sc);
@@ -279,11 +270,10 @@ static int ath_reset_internal(struct athif (!hchan) { fastcc = false; - flush = true; hchan = ah->curchan; } -if (!ath_prepare_reset (sc, retry_tx, flush)) +if (!ath_prepare_reset (sc, retry_tx)) fastcc = false; ath_dbg(common, CONFIG, "Reset to %u MHz, HT40: %d fastcc: %d\n",
@@ -820,7 +810,7 @@ static void ath9k_stop(struct ieee80211_ath9k_hw_cfg_gpio_input (ah, ah->led_pin); } -ath_prepare_reset (sc, false, true); +ath_prepare_reset (sc, false);if (sc->rx.frag) {dev_kfree_skb_any (sc->rx.frag);
drivers/net/wireless/ath/ath9k/recv.c +9 -7
@@ -472,6 +472,13 @@ start_recv:return 0 ; } +static void ath_flushrecv (struct ath_softc *sc) +{ +if (sc->sc_ah->caps.hw_caps &ATH9K_HW_CAP_EDMA ) +ath_rx_tasklet (sc,1 , true); +ath_rx_tasklet (sc,1 , false); +} +bool ath_stoprecv (struct ath_softc *sc) {struct ath_hw *ah = sc->sc_ah;
@@ -482,6 +489,8 @@ bool ath_stoprecv(struct ath_softc *sc)ath9k_hw_setrxfilter (ah,0 ); stopped =ath9k_hw_stopdmarecv (ah, &reset); +ath_flushrecv (sc); +if (sc->sc_ah->caps.hw_caps &ATH9K_HW_CAP_EDMA )ath_edma_stop_recv (sc);else
@@ -498,13 +507,6 @@ bool ath_stoprecv(struct ath_softc *sc)return stopped && !reset; } -void ath_flushrecv (struct ath_softc *sc) -{ -if (sc->sc_ah->caps.hw_caps &ATH9K_HW_CAP_EDMA ) -ath_rx_tasklet (sc,1 , true); -ath_rx_tasklet (sc,1 , false); -} -static bool ath_beacon_dtim_pending_cab (struct sk_buff *skb) {/* Check whether the Beacon frame has DTIM indicating buffered bc/mc */
Greg Kroah-Hartman
maintainerPATCH 40/89 ath9k: remove sc->rx.rxbuflock to fix a deadlock
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
commit 463e3ed3eacc8f47866e5d612bd8ee0bcee5e2f0 upstream.
The commit "ath9k: fix rx flush handling" added a deadlock that happens because ath_rx_tasklet is called in a section that has already taken the rx buffer lock.
It seems that the only purpose of the rxbuflock was a band-aid fix to the reset vs rx tasklet race, which has been properly fixed in the commit "ath9k: add a better fix for the rx tasklet vs rx flush race".
Now that the fix is in, we can safely remove the lock to avoid such issues.
--- drivers/net/wireless/ath/ath9k/ath9k.h | 1 - drivers/net/wireless/ath/ath9k/recv.c | 13 ------------- 2 files changed, 14 deletions(-)
drivers/net/wireless/ath/ath9k/ath9k.h +0 -1
@@ -315,7 +315,6 @@ struct ath_rx {u32 *rxlink;u32 num_pkts;unsigned int rxfilter; -spinlock_t rxbuflock;struct list_head rxbuf;struct ath_descdma rxdma;struct ath_buf *rx_bufptr;
drivers/net/wireless/ath/ath9k/recv.c +0 -13
@@ -254,8 +254,6 @@ rx_init_fail:static void ath_edma_start_recv (struct ath_softc *sc) { -spin_lock_bh (&sc->rx.rxbuflock); -ath9k_hw_rxena (sc->sc_ah); ath_rx_addbuffer_edma(sc, ATH9K_RX_QUEUE_HP,
@@ -267,8 +265,6 @@ static void ath_edma_start_recv(struct aath_opmode_init (sc);ath9k_hw_startpcureceive (sc->sc_ah, !!(sc->hw->conf.flags &IEEE80211_CONF_OFFCHANNEL )); - -spin_unlock_bh (&sc->rx.rxbuflock); }static void ath_edma_stop_recv (struct ath_softc *sc)
@@ -285,7 +281,6 @@ int ath_rx_init(struct ath_softc *sc, inint error =0 ;spin_lock_init (&sc->sc_pcu_lock); -spin_lock_init (&sc->rx.rxbuflock); common->rx_bufsize =IEEE80211_MAX_MPDU_LEN /2 + sc->sc_ah->caps.rx_status_len;
@@ -446,7 +441,6 @@ int ath_startrecv(struct ath_softc *sc)return 0 ; } -spin_lock_bh (&sc->rx.rxbuflock);if (list_empty (&sc->rx.rxbuf)) goto start_recv;
@@ -467,8 +461,6 @@ start_recv:ath_opmode_init (sc);ath9k_hw_startpcureceive (ah, !!(sc->hw->conf.flags &IEEE80211_CONF_OFFCHANNEL )); -spin_unlock_bh (&sc->rx.rxbuflock); -return 0 ; }
@@ -484,7 +476,6 @@ bool ath_stoprecv(struct ath_softc *sc)struct ath_hw *ah = sc->sc_ah;bool stopped, reset = false; -spin_lock_bh (&sc->rx.rxbuflock);ath9k_hw_abortpcurecv (ah);ath9k_hw_setrxfilter (ah,0 ); stopped =ath9k_hw_stopdmarecv (ah, &reset);
@@ -495,7 +486,6 @@ bool ath_stoprecv(struct ath_softc *sc)ath_edma_stop_recv (sc); else sc->rx.rxlink = NULL; -spin_unlock_bh (&sc->rx.rxbuflock);if (!(ah->ah_flags &AH_UNPLUGGED ) &&unlikely (!stopped)) {
@@ -1059,7 +1049,6 @@ int ath_rx_tasklet(struct ath_softc *sc, dma_type =DMA_FROM_DEVICE ; qtype = hp ?ATH9K_RX_QUEUE_HP :ATH9K_RX_QUEUE_LP ; -spin_lock_bh (&sc->rx.rxbuflock); tsf =ath9k_hw_gettsf64 (ah); tsf_lower = tsf &0xffffffff ;
@@ -1251,8 +1240,6 @@ requeue: } }while (1 ); -spin_unlock_bh (&sc->rx.rxbuflock); -if (!(ah->imask &ATH9K_INT_RXEOL )) { ah->imask |= (ATH9K_INT_RXEOL |ATH9K_INT_RXORN );ath9k_hw_set_interrupts (ah);
Greg Kroah-Hartman
maintainerPATCH 41/89 ath9k: disable the tasklet before taking the PCU lock
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
commit 4668cce527acb3bd048c5e6c99b157a14b214671 upstream.
Fixes a reported CPU soft lockup where the tasklet tries to acquire the lock and blocks while ath_prepare_reset (holding the lock) waits for it to complete.
--- drivers/net/wireless/ath/ath9k/main.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
drivers/net/wireless/ath/ath9k/main.c +3 -4
@@ -195,16 +195,12 @@ static bool ath_prepare_reset(struct athath9k_debug_samp_bb_mac (sc);ath9k_hw_disable_interrupts (ah); -tasklet_disable (&sc->intr_tq); -if (!ath_stoprecv (sc)) ret = false;if (!ath_drain_all_txq (sc, retry_tx)) ret = false; -tasklet_enable (&sc->intr_tq); -return ret; }
@@ -261,6 +257,7 @@ static int ath_reset_internal(struct ath__ath_cancel_work (sc); +tasklet_disable (&sc->intr_tq);spin_lock_bh (&sc->sc_pcu_lock);if (!(sc->hw->conf.flags &IEEE80211_CONF_OFFCHANNEL )) {
@@ -291,6 +288,8 @@ static int ath_reset_internal(struct ath out:spin_unlock_bh (&sc->sc_pcu_lock); +tasklet_enable (&sc->intr_tq); +return r; }
Greg Kroah-Hartman
maintainerPATCH 42/89 ath9k_hw: fix chain swap setting when setting rx chainmask to 5
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
commit 24171dd92096fc370b195f3f6bdc0798855dc3f9 upstream.
Chain swapping should only be enabled when the EEPROM chainmask is set to 5, regardless of what the runtime chainmask is.
--- drivers/net/wireless/ath/ath9k/ar9003_phy.c | 25 ++++++------------------- 1 file changed, 6 insertions(+), 19 deletions(-)
drivers/net/wireless/ath/ath9k/ar9003_phy.c +6 -19
@@ -588,30 +588,17 @@ static void ar9003_hw_init_bb(struct athstatic void ar9003_hw_set_chain_masks (struct ath_hw *ah,u8 rx,u8 tx) { -switch (rx) { -case 0x5 : +if (ah->caps.tx_chainmask ==5 || ah->caps.rx_chainmask ==5 )REG_SET_BIT (ah,AR_PHY_ANALOG_SWAP ,AR_PHY_SWAP_ALT_CHAIN ); -case 0x3 : -case 0x1 : -case 0x2 : -case 0x7 : -REG_WRITE (ah,AR_PHY_RX_CHAINMASK , rx); -REG_WRITE (ah,AR_PHY_CAL_CHAINMASK , rx); -break ; -default : -break ; - } + +REG_WRITE (ah,AR_PHY_RX_CHAINMASK , rx); +REG_WRITE (ah,AR_PHY_CAL_CHAINMASK , rx);if ((ah->caps.hw_caps &ATH9K_HW_CAP_APM ) && (tx ==0x7 )) -REG_WRITE (ah,AR_SELFGEN_MASK ,0x3 ); -else -REG_WRITE (ah,AR_SELFGEN_MASK , tx); + tx =3 ; -if (tx ==0x5 ) { -REG_SET_BIT (ah,AR_PHY_ANALOG_SWAP , -AR_PHY_SWAP_ALT_CHAIN ); - } +REG_WRITE (ah,AR_SELFGEN_MASK , tx); }/*
Greg Kroah-Hartman
maintainerPATCH 43/89 ath9k: allow setting arbitrary antenna masks on AR9003+
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
commit fea92cbf0850d788683827990670d3968f893327 upstream.
--- drivers/net/wireless/ath/ath9k/main.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/wireless/ath/ath9k/main.c +3 -0
@@ -1830,6 +1830,9 @@ static u32 fill_chainmask(u32 cap, u32 nstatic bool validate_antenna_mask (struct ath_hw *ah,u32 val) { +if (AR_SREV_9300_20_OR_LATER (ah)) +return true; +switch (val &0x7 ) {case 0x1 :case 0x3 :
Greg Kroah-Hartman
maintainerPATCH 44/89 ALSA: usb-audio: fix invalid length check for RME and other UAC 2 devices
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Clemens Ladisch <[email protected]>
commit d56268fb108c7c21e19933588ca4d94652585183 upstream.
Commit 23caaf19b11e (ALSA: usb-mixer: Add support for Audio Class v2.0) forgot to adjust the length check for UAC 2.0 feature unit descriptors. This would make the code abort on encountering a feature unit without per-channel controls, and thus prevented the driver to work with any device having such a unit, such as the RME Babyface or Fireface UCX.
--- sound/usb/mixer.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-)
sound/usb/mixer.c +12 -5
@@ -1259,16 +1259,23 @@ static int parse_audio_feature_unit(stru } channels = (hdr->bLength -7 ) / csize -1 ; bmaControls = hdr->bmaControls; +if (hdr->bLength <7 + csize) { +snd_printk (KERN_ERR "usbaudio: unit %u: " +"invalid UAC_FEATURE_UNIT descriptor\n" , + unitid); +return -EINVAL ; + } }else {struct uac2_feature_unit_descriptor *ftr = _ftr; csize =4 ; channels = (hdr->bLength -6 ) /4 -1 ; bmaControls = ftr->bmaControls; - } - -if (hdr->bLength <7 || !csize || hdr->bLength <7 + csize) { -snd_printk (KERN_ERR "usbaudio: unit %u: invalid UAC_FEATURE_UNIT descriptor\n" , unitid); -return -EINVAL ; +if (hdr->bLength <6 + csize) { +snd_printk (KERN_ERR "usbaudio: unit %u: " +"invalid UAC_FEATURE_UNIT descriptor\n" , + unitid); +return -EINVAL ; + } }/* parse the source unit */
Greg Kroah-Hartman
maintainerPATCH 45/89 ALSA: hda - Add a fixup for Packard-Bell desktop with ALC880
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 0712eea349d8e2b6d0e44b94a752d999319027fb upstream.
A Packard-Bell desktop machine gives no proper pin configuration from BIOS. It's almost equivalent with the 6stack+fp standard config, just take the existing fixup.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=901846
--- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/patch_realtek.c +1 -0
@@ -4688,6 +4688,7 @@ static const struct snd_pci_quirk alc880SND_PCI_QUIRK (0x1584 ,0x9077 ,"Uniwill P53" ,ALC880_FIXUP_VOL_KNOB ),SND_PCI_QUIRK (0x161f ,0x203d ,"W810" ,ALC880_FIXUP_W810 ),SND_PCI_QUIRK (0x161f ,0x205d ,"Medion Rim 2150" ,ALC880_FIXUP_MEDION_RIM ), +SND_PCI_QUIRK (0x1631 ,0xe011 ,"PB 13201056" ,ALC880_FIXUP_6ST ),SND_PCI_QUIRK (0x1734 ,0x107c ,"FSC F1734" ,ALC880_FIXUP_F1734 ),SND_PCI_QUIRK (0x1734 ,0x1094 ,"FSC Amilo M1451G" ,ALC880_FIXUP_FUJITSU ), SND_PCI_QUIRK(0x1734, 0x10ac, "FSC AMILO Xi 1526", ALC880_FIXUP_F1734),
Greg Kroah-Hartman
maintainerPATCH 46/89 ALSA: hda - fix inverted internal mic on Acer AOA150/ZG5
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Henningsson <[email protected]>
commit fcd8f3b1d43c645e291638bc6c80a1c680722869 upstream.
This patch enables internal mic input on the machine.
--- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/patch_realtek.c +1 -0
@@ -5703,6 +5703,7 @@ static const struct alc_model_fixup alc2 };static const struct snd_pci_quirk alc268_fixup_tbl[] = { +SND_PCI_QUIRK (0x1025 ,0x015b ,"Acer AOA 150 (ZG5)" ,ALC268_FIXUP_INV_DMIC ),/* below is codec SSID since multiple Toshiba laptops have the * same PCI SSID 1179:ff00 */
Greg Kroah-Hartman
maintainerPATCH 47/89 ALSA: hda - Fix non-snoop page handling
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 9ddf1aeb2134e72275c97a2c6ff2e3eb04f2f27a upstream.
For non-snoop mode, we fiddle with the page attributes of CORB/RIRB and the position buffer, but also the ring buffers. The problem is that the current code blindly assumes that the buffer is contiguous. However, the ring buffers may be SG-buffers, thus a wrong vmapped address is passed there, leading to Oops.
This patch fixes the handling for SG-buffers.
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=800701
--- sound/pci/hda/hda_intel.c | 40 ++++++++++++++++++++++++++-------------- 1 file changed, 26 insertions(+), 14 deletions(-)
sound/pci/hda/hda_intel.c +26 -14
@@ -650,29 +650,43 @@ static char *driver_short_names[] DELAYE#define get_azx_dev (substream) (substream->runtime->private_data)#ifdef CONFIG_X86 -static void __mark_pages_wc (struct azx *chip,void *addr,size_t size,bool on) +static void __mark_pages_wc (struct azx *chip,struct snd_dma_buffer *dmab,bool on) { +int pages; +if (azx_snoop (chip))return ; -if (addr && size) { -int pages = (size +PAGE_SIZE -1 ) >>PAGE_SHIFT ; +if (!dmab || !dmab->area || !dmab->bytes) +return ; + +#ifdef CONFIG_SND_DMA_SGBUF +if (dmab->dev.type ==SNDRV_DMA_TYPE_DEV_SG ) { +struct snd_sg_buf *sgbuf = dmab->private_data;if (on) -set_memory_wc ((unsigned long )addr, pages); +set_pages_array_wc (sgbuf->page_table, sgbuf->pages);else -set_memory_wb ((unsigned long )addr, pages); +set_pages_array_wb (sgbuf->page_table, sgbuf->pages); +return ; } +#endif + + pages = (dmab->bytes +PAGE_SIZE -1 ) >>PAGE_SHIFT ; +if (on) +set_memory_wc ((unsigned long )dmab->area, pages); +else +set_memory_wb ((unsigned long )dmab->area, pages); }static inline void mark_pages_wc (struct azx *chip,struct snd_dma_buffer *buf,bool on) { -__mark_pages_wc (chip, buf->area, buf->bytes, on); +__mark_pages_wc (chip, buf, on); }static inline void mark_runtime_wc (struct azx *chip,struct azx_dev *azx_dev, -struct snd_pcm_runtime *runtime,bool on) +struct snd_pcm_substream *substream,bool on) {if (azx_dev->wc_marked != on) { -__mark_pages_wc (chip, runtime->dma_area, runtime->dma_bytes, on); +__mark_pages_wc (chip,snd_pcm_get_dma_buf (substream), on); azx_dev->wc_marked = on; } }
@@ -683,7 +697,7 @@ static inline void mark_pages_wc(struct { }static inline void mark_runtime_wc (struct azx *chip,struct azx_dev *azx_dev, -struct snd_pcm_runtime *runtime,bool on) +struct snd_pcm_substream *substream,bool on) { }#endif
@@ -1860,11 +1874,10 @@ static int azx_pcm_hw_params(struct snd_ {struct azx_pcm *apcm =snd_pcm_substream_chip (substream);struct azx *chip = apcm->chip; -struct snd_pcm_runtime *runtime = substream->runtime;struct azx_dev *azx_dev =get_azx_dev (substream);int ret; -mark_runtime_wc (chip, azx_dev, runtime, false); +mark_runtime_wc (chip, azx_dev, substream, false); azx_dev->bufsize =0 ; azx_dev->period_bytes =0 ; azx_dev->format_val =0 ;
@@ -1872,7 +1885,7 @@ static int azx_pcm_hw_params(struct snd_ params_buffer_bytes(hw_params));if (ret <0 )return ret; -mark_runtime_wc (chip, azx_dev, runtime, true); +mark_runtime_wc (chip, azx_dev, substream, true);return ret; }
@@ -1881,7 +1894,6 @@ static int azx_pcm_hw_free(struct snd_pcstruct azx_pcm *apcm =snd_pcm_substream_chip (substream);struct azx_dev *azx_dev =get_azx_dev (substream);struct azx *chip = apcm->chip; -struct snd_pcm_runtime *runtime = substream->runtime;struct hda_pcm_stream *hinfo = apcm->hinfo[substream->stream];/* reset BDL address */
@@ -1894,7 +1906,7 @@ static int azx_pcm_hw_free(struct snd_pcsnd_hda_codec_cleanup (apcm->codec, hinfo, substream); -mark_runtime_wc (chip, azx_dev, runtime, false); +mark_runtime_wc (chip, azx_dev, substream, false);return snd_pcm_lib_free_pages (substream); }
Greg Kroah-Hartman
maintainerPATCH 48/89 EDAC: Test correct variable in ->store function
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit 8024c4c0b1057d1cd811fc9c3f88f81de9729fcd upstream.
We're testing for ->show but calling ->store().
--- drivers/edac/edac_pci_sysfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/edac/edac_pci_sysfs.c +1 -1
@@ -256,7 +256,7 @@ static ssize_t edac_pci_dev_store(structstruct edac_pci_dev_attribute *edac_pci_dev; edac_pci_dev = (struct edac_pci_dev_attribute *)attr; -if (edac_pci_dev->show) +if (edac_pci_dev->store)return edac_pci_dev->store (edac_pci_dev->value, buffer, count);return -EIO ; }
Greg Kroah-Hartman
maintainerPATCH 49/89 ASoC: arizona: Use actual rather than desired BCLK when calculating LRCLK
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Brown <[email protected]>
commit b59e0f82aa350e380142353fbd30706092ba6312 upstream.
Otherwise we'll get the wrong LRCLK if we need to pick a higher BCLK than is required.
--- sound/soc/codecs/arizona.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/soc/codecs/arizona.c +1 -1
@@ -648,7 +648,7 @@ static int arizona_hw_params(struct snd_ } sr_val = i; - lrclk =snd_soc_params_to_bclk (params) /params_rate (params); + lrclk = rates[bclk] /params_rate (params);arizona_aif_dbg (dai,"BCLK %dHz LRCLK %dHz\n" , rates[bclk], rates[bclk] / lrclk);
Greg Kroah-Hartman
maintainerPATCH 50/89 ASoC: wm2200: correct mixer values and text
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Rattray <[email protected]>
commit a80cc734282805e15b5e023751a4d02f7ffbcc91 upstream.
--- sound/soc/codecs/wm2200.c | 3 --- 1 file changed, 3 deletions(-)
sound/soc/codecs/wm2200.c +0 -3
@@ -897,8 +897,6 @@ static const char *wm2200_mixer_texts[]"EQR" ,"LHPF1" ,"LHPF2" , -"LHPF3" , -"LHPF4" ,"DSP1.1" ,"DSP1.2" , "DSP1.3",
@@ -931,7 +929,6 @@ static int wm2200_mixer_values[] = {0x25 ,0x50 ,/* EQ */ 0x51 , -0x52 ,0x60 ,/* LHPF1 */ 0x61 ,/* LHPF2 */ 0x68, /* DSP1 */
Greg Kroah-Hartman
maintainerPATCH 51/89 Bluetooth: Fix incorrect strncpy() in hidp_setup_hid()
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anderson Lizardo <[email protected]>
commit 0a9ab9bdb3e891762553f667066190c1d22ad62b upstream.
The length parameter should be sizeof(req->name) - 1 because there is no guarantee that string provided by userspace will contain the trailing '\0'.
Can be easily reproduced by manually setting req->name to 128 non-zero bytes prior to ioctl(HIDPCONNADD) and checking the device name setup on input subsystem:
$ cat /sys/devices/pnp0/00\:04/tty/ttyS0/hci0/hci0\:1/input8/name AAAAAA[...]AAAAAAAAf0:af:f0:af:f0:af
("f0:af:f0:af:f0:af" is the device bluetooth address, taken from "phys" field in struct hid_device due to overflow.)
--- net/bluetooth/hidp/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/bluetooth/hidp/core.c +1 -1
@@ -931,7 +931,7 @@ static int hidp_setup_hid(struct hidp_se hid->version = req->version; hid->country = req->country; -strncpy (hid->name, req->name,128 ); +strncpy (hid->name, req->name,sizeof (req->name) -1 );strncpy (hid->phys,batostr (&bt_sk (session->ctrl_sock->sk)->src),64 );strncpy (hid->uniq,batostr (&bt_sk (session->ctrl_sock->sk)->dst),64 );
Greg Kroah-Hartman
maintainerPATCH 52/89 iommu/intel: disable DMAR for g4x integrated gfx
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Vetter <[email protected]>
commit 9452618e7462181ed9755236803b6719298a13ce upstream.
DMAR support on g4x/gm45 integrated gpus seems to be totally busted. So don't bother, but instead disable it by default to allow distros to unconditionally enable DMAR support.
v2: Actually wire up the right quirk entry, spotted by Adam Jackson.
Note that according to intel marketing materials only g45 and gm45 support DMAR/VT-d. So we have reports for all relevant gen4 pci ids by now. Still, keep all the other gen4 ids in the quirk table in case the marketing stuff confused me again, which would not be the first time.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51921
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=538163
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=538163
--- drivers/iommu/intel-iommu.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-)
drivers/iommu/intel-iommu.c +15 -6
@@ -4234,6 +4234,21 @@ static struct iommu_ops intel_iommu_ops .pgsize_bitmap = INTEL_IOMMU_PGSIZES, }; +static void __devinit quirk_iommu_g4x_gfx (struct pci_dev *dev) +{ +/* G4x/GM45 integrated gfx dmar support is totally busted. */ +printk (KERN_INFO "DMAR: Disabling IOMMU for graphics on this chipset\n" ); + dmar_map_gfx =0 ; +} + +DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_INTEL ,0x2a40 , quirk_iommu_g4x_gfx); +DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_INTEL ,0x2e00 , quirk_iommu_g4x_gfx); +DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_INTEL ,0x2e10 , quirk_iommu_g4x_gfx); +DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_INTEL ,0x2e20 , quirk_iommu_g4x_gfx); +DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_INTEL ,0x2e30 , quirk_iommu_g4x_gfx); +DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_INTEL ,0x2e40 , quirk_iommu_g4x_gfx); +DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_INTEL ,0x2e90 , quirk_iommu_g4x_gfx); +static void __devinit quirk_iommu_rwbf (struct pci_dev *dev) {/*
@@ -4242,12 +4257,6 @@ static void __devinit quirk_iommu_rwbf(s*/ printk (KERN_INFO "DMAR: Forcing write-buffer flush capability\n" ); rwbf_quirk =1 ; - -/* https://bugzilla.redhat.com/show_bug.cgi?id=538163 */ -if (dev->revision ==0x07 ) { -printk (KERN_INFO "DMAR: Disabling IOMMU for graphics on this chipset\n" ); - dmar_map_gfx =0 ; - } }DECLARE_PCI_FIXUP_HEADER (PCI_VENDOR_ID_INTEL ,0x2a40 , quirk_iommu_rwbf);
Greg Kroah-Hartman
maintainerPATCH 53/89 NFS: Fix error reporting in nfs_xdev_mount
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
commit dee972b967ae111ad5705733de17a3bfc4632311 upstream.
Currently, nfs_xdev_mount converts all errors from clone_server() to ENOMEM, which can then leak to userspace (for instance to 'mount'). Fix that. Also ensure that if nfs_fs_mount_common() returns an error, we don't dprintk(0)...
The regression originated in commit 3d176e3fe4f6dc379b252bf43e2e146a8f7caf01 (NFS: Use nfs_fs_mount_common() for xdev mounts)
--- fs/nfs/super.c | 24 ++++++++++-------------- 1 file changed, 10 insertions(+), 14 deletions(-)
fs/nfs/super.c +10 -14
@@ -2576,27 +2576,23 @@ nfs_xdev_mount(struct file_system_type *struct nfs_server *server;struct dentry *mntroot =ERR_PTR (-ENOMEM );struct nfs_subversion *nfs_mod =NFS_SB (data->sb)->nfs_client->cl_nfs_mod; -int error; -dprintk ("--> nfs_xdev_mount_common()\n" ); +dprintk ("--> nfs_xdev_mount()\n" ); mount_info.mntfh = mount_info.cloned->fh;/* create a new volume representation */ server = nfs_mod->rpc_ops->clone_server (NFS_SB (data->sb), data->fh, data->fattr, data->authflavor); -if (IS_ERR (server)) { - error =PTR_ERR (server); - goto out_err; - } - - mntroot =nfs_fs_mount_common (server, flags, dev_name, &mount_info, nfs_mod); -dprintk ("<-- nfs_xdev_mount_common() = 0\n" ); -out: -return mntroot; -out_err: -dprintk ("<-- nfs_xdev_mount_common() = %d [error]\n" , error); - goto out; +if (IS_ERR (server)) + mntroot =ERR_CAST (server); +else + mntroot =nfs_fs_mount_common (server, flags, + dev_name, &mount_info, nfs_mod); + +dprintk ("<-- nfs_xdev_mount() = %ld\n" , +IS_ERR (mntroot) ?PTR_ERR (mntroot) :0L ); +return mntroot; }#if IS_ENABLED (CONFIG_NFS_V4 )
Greg Kroah-Hartman
maintainerPATCH 54/89 NFS: Dont silently fail setattr() requests on mountpoints
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
commit ab225417825963b6dc66be7ea80f94ac1378dfdf upstream.
Ensure that any setattr and getattr requests for junctions and/or mountpoints are sent to the server. Ever since commit 0ec26fd0698 (vfs: automount should ignore LOOKUP_FOLLOW), we have silently dropped any setattr requests to a server-side mountpoint. For referrals, we have silently dropped both getattr and setattr requests.
This patch restores the original behaviour for setattr on mountpoints, and tries to do the same for referrals, provided that we have a filehandle...
--- fs/nfs/namespace.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
fs/nfs/namespace.c +20 -0
@@ -177,11 +177,31 @@ out_nofree:return mnt; } +static int +nfs_namespace_getattr (struct vfsmount *mnt,struct dentry *dentry,struct kstat *stat) +{ +if (NFS_FH (dentry->d_inode)->size !=0 ) +return nfs_getattr (mnt, dentry, stat); +generic_fillattr (dentry->d_inode, stat); +return 0 ; +} + +static int +nfs_namespace_setattr (struct dentry *dentry,struct iattr *attr) +{ +if (NFS_FH (dentry->d_inode)->size !=0 ) +return nfs_setattr (dentry, attr); +return -EACCES ; +} +const struct inode_operations nfs_mountpoint_inode_operations = { .getattr = nfs_getattr, + .setattr = nfs_setattr, };const struct inode_operations nfs_referral_inode_operations = { + .getattr = nfs_namespace_getattr, + .setattr = nfs_namespace_setattr, };static void nfs_expire_automounts (struct work_struct *work)
Greg Kroah-Hartman
maintainerPATCH 55/89 NFSv4: Fix NFSv4 reference counting for trunked sessions
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
commit 4ae19c2dd713edb7b8ad3d4ab9d234ed5dcb6b98 upstream.
The reference counting in nfs4_init_client assumes wongly that it is safe for nfs4_discover_server_trunking() to return a pointer to a nfs_client prior to bumping the reference count.
--- fs/nfs/nfs4client.c | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-)
fs/nfs/nfs4client.c +15 -16
@@ -235,11 +235,10 @@ struct nfs_client *nfs4_init_client(stru error =nfs4_discover_server_trunking (clp, &old);if (error <0 ) goto error; +nfs_put_client (clp);if (clp != old) { clp->cl_preserve_clid = true; -nfs_put_client (clp); clp = old; -atomic_inc (&clp->cl_count); }return clp;
@@ -305,7 +304,7 @@ int nfs40_walk_client_list(struct nfs_cl .clientid = new->cl_clientid, .confirm = new->cl_confirm, }; -int status; +int status = -NFS4ERR_STALE_CLIENTID ;spin_lock (&nn->nfs_client_lock);list_for_each_entry_safe (pos, n, &nn->nfs_client_list, cl_share_link) {
@@ -331,28 +330,28 @@ int nfs40_walk_client_list(struct nfs_clif (prev)nfs_put_client (prev); + prev = pos; status =nfs4_proc_setclientid_confirm (pos, &clid, cred); -if (status ==0 ) { +switch (status) { +case -NFS4ERR_STALE_CLIENTID : +break ; +case 0 :nfs4_swap_callback_idents (pos, new); -nfs_put_client (pos); + prev =NULL ; *result = pos;dprintk ("NFS: <-- %s using nfs_client = %p ({%d})\n" , __func__, pos,atomic_read (&pos->cl_count)); -return 0 ; - } -if (status != -NFS4ERR_STALE_CLIENTID ) { -nfs_put_client (pos); -dprintk ("NFS: <-- %s status = %d, no result\n" , - __func__, status); -return status; +default : + goto out; }spin_lock (&nn->nfs_client_lock); - prev = pos; } +spin_unlock (&nn->nfs_client_lock); +out:/* * No matching nfs_client found. This should be impossible, * because the new nfs_client has already been added to
@@ -362,9 +361,8 @@ int nfs40_walk_client_list(struct nfs_cl*/ if (prev)nfs_put_client (prev); -spin_unlock (&nn->nfs_client_lock); -pr_err ("NFS: %s Error: no matching nfs_client found\n" , __func__); -return -NFS4ERR_STALE_CLIENTID ; +dprintk ("NFS: <-- %s status = %d\n" , __func__, status); +return status; }#ifdef CONFIG_NFS_V4_1
@@ -472,6 +470,7 @@ int nfs41_walk_client_list(struct nfs_clif (!nfs4_match_serverowners (pos, new))continue ; +atomic_inc (&pos->cl_count);spin_unlock (&nn->nfs_client_lock);dprintk ("NFS: <-- %s using nfs_client = %p ({%d})\n" , __func__, pos,atomic_read (&pos->cl_count));
Greg Kroah-Hartman
maintainerPATCH 56/89 NFSv4: Fix NFSv4 trunking discovery
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
commit 202c312dba7d95b96493b412c606163a0cd83984 upstream.
If walking the list in nfs4[01]_walk_client_list fails, then the most likely explanation is that the server dropped the clientid before we actually managed to confirm it. As long as our nfs_client is the very last one in the list to be tested, the caller can be assured that this is the case when the final return value is NFS4ERR_STALE_CLIENTID.
--- fs/nfs/nfs4client.c | 26 +++++++------------------- fs/nfs/nfs4state.c | 8 ++------ 2 files changed, 9 insertions(+), 25 deletions(-)
fs/nfs/nfs4client.c +7 -19
@@ -351,14 +351,8 @@ int nfs40_walk_client_list(struct nfs_cl }spin_unlock (&nn->nfs_client_lock); +/* No match found. The server lost our clientid */ out: -/* -* No matching nfs_client found. This should be impossible, -* because the new nfs_client has already been added to -* nfs_client_list by nfs_get_client(). -* -* Don't BUG(), since the caller is holding a mutex. -*/ if (prev)nfs_put_client (prev);dprintk ("NFS: <-- %s status = %d\n" , __func__, status);
@@ -429,7 +423,7 @@ int nfs41_walk_client_list(struct nfs_cl {struct nfs_net *nn =net_generic (new->cl_net, nfs_net_id);struct nfs_client *pos, *n, *prev =NULL ; -int error; +int status = -NFS4ERR_STALE_CLIENTID ;spin_lock (&nn->nfs_client_lock);list_for_each_entry_safe (pos, n, &nn->nfs_client_list, cl_share_link) {
@@ -445,8 +439,8 @@ int nfs41_walk_client_list(struct nfs_clnfs_put_client (prev); prev = pos; - error =nfs_wait_client_init_complete (pos); -if (error <0 ) { + status =nfs_wait_client_init_complete (pos); +if (status <0 ) {nfs_put_client (pos);spin_lock (&nn->nfs_client_lock);continue ;
@@ -479,16 +473,10 @@ int nfs41_walk_client_list(struct nfs_cl return 0; } -/* -* No matching nfs_client found. This should be impossible, -* because the new nfs_client has already been added to -* nfs_client_list by nfs_get_client(). -* -* Don't BUG(), since the caller is holding a mutex. -*/ +/* No matching nfs_client found. */ spin_unlock (&nn->nfs_client_lock); -pr_err ("NFS: %s Error: no matching nfs_client found\n" , __func__); -return -NFS4ERR_STALE_CLIENTID ; +dprintk ("NFS: <-- %s status = %d\n" , __func__, status); +return status; }#endif /* CONFIG_NFS_V4_1 */
fs/nfs/nfs4state.c +2 -6
@@ -136,16 +136,11 @@ int nfs40_discover_server_trunking(struc clp->cl_confirm = clid.confirm; status =nfs40_walk_client_list (clp, result, cred); -switch (status) { -case -NFS4ERR_STALE_CLIENTID : -set_bit (NFS4CLNT_LEASE_CONFIRM , &clp->cl_state); -case 0 : +if (status ==0 ) {/* Sustain the lease, even if it's empty. If the clientid4 * goes stale it's of no use for trunking discovery. */ nfs4_schedule_state_renewal (*result); -break ; } - out:return status; }
@@ -1850,6 +1845,7 @@ again:case -ETIMEDOUT :case -EAGAIN :ssleep (1 ); +case -NFS4ERR_STALE_CLIENTID :dprintk ("NFS: %s after status %d, retrying\n" , __func__, status); goto again;
Greg Kroah-Hartman
maintainerPATCH 57/89 NFSv4.1: Ensure that nfs41_walk_client_list() does start lease recovery
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
commit 65436ec0c8e344d9b23302b686e418f2a7b7cf7b upstream.
We do need to start the lease recovery thread prior to waiting for the client initialisation to complete in NFSv4.1.
--- fs/nfs/nfs4client.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
fs/nfs/nfs4client.c +4 -1
@@ -439,14 +439,17 @@ int nfs41_walk_client_list(struct nfs_clnfs_put_client (prev); prev = pos; +nfs4_schedule_lease_recovery (pos); status =nfs_wait_client_init_complete (pos);if (status <0 ) {nfs_put_client (pos);spin_lock (&nn->nfs_client_lock);continue ; } - + status = pos->cl_cons_state;spin_lock (&nn->nfs_client_lock); +if (status <0 ) +continue ; }if (pos->rpc_ops != new->rpc_ops)
Greg Kroah-Hartman
maintainerPATCH 58/89 NFSv4.1: Handle NFS4ERR_DELAY when resetting the NFSv4.1 session
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
commit c489ee290bdbbace6bb63ebe6ebd4dd605819495 upstream.
NFS4ERR_DELAY is a legal reply when we call DESTROY_SESSION. It usually means that the server is busy handling an unfinished RPC request. Just sleep for a second and then retry.
We also need to be able to handle the NFS4ERR_BACK_CHAN_BUSY return value. If the NFS server has outstanding callbacks, we just want to similarly sleep & retry.
--- fs/nfs/nfs4state.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
fs/nfs/nfs4state.c +12 -2
@@ -1997,8 +1997,18 @@ static int nfs4_reset_session(struct nfsnfs4_begin_drain_session (clp); cred =nfs4_get_exchange_id_cred (clp); status =nfs4_proc_destroy_session (clp->cl_session, cred); -if (status && status != -NFS4ERR_BADSESSION && - status != -NFS4ERR_DEADSESSION ) { +switch (status) { +case 0 : +case -NFS4ERR_BADSESSION : +case -NFS4ERR_DEADSESSION : +break ; +case -NFS4ERR_BACK_CHAN_BUSY : +case -NFS4ERR_DELAY : +set_bit (NFS4CLNT_SESSION_RESET , &clp->cl_state); + status =0 ; +ssleep (1 ); + goto out; +default : status =nfs4_recovery_handle_error (clp, status); goto out; }
Greg Kroah-Hartman
maintainerPATCH 59/89 HID: usbhid: quirk for Formosa IR receiver
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Santos <[email protected]>
commit 320cde19a4e8f122b19d2df7a5c00636e11ca3fb upstream.
Patch to add the Formosa Industrial Computing, Inc. Infrared Receiver [IR605A/Q] to hid-ids.h and hid-quirks.c. This IR receiver causes about a 10 second timeout when the usbhid driver attempts to initialze the device. Adding this device to the quirks list with HID_QUIRK_NO_INIT_REPORTS removes the delay.
--- drivers/hid/hid-ids.h | 3 +++ drivers/hid/usbhid/hid-quirks.c | 1 + 2 files changed, 4 insertions(+)
drivers/hid/hid-ids.h +3 -0
@@ -305,6 +305,9 @@#define USB_VENDOR_ID_EZKEY 0x0518#define USB_DEVICE_ID_BTC_8193 0x0002 +#define USB_VENDOR_ID_FORMOSA 0x147a +#define USB_DEVICE_ID_FORMOSA_IR_RECEIVER 0xe03e +#define USB_VENDOR_ID_FREESCALE 0x15A2#define USB_DEVICE_ID_FREESCALE_MX28 0x004F
drivers/hid/usbhid/hid-quirks.c +1 -0
@@ -70,6 +70,7 @@ static const struct hid_blacklist { { USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_AXIS_295, HID_QUIRK_NOGET }, { USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET }, { USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_TS2700, HID_QUIRK_NOGET }, + { USB_VENDOR_ID_FORMOSA, USB_DEVICE_ID_FORMOSA_IR_RECEIVER, HID_QUIRK_NO_INIT_REPORTS }, { USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28, HID_QUIRK_NOGET }, { USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET }, { USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN, HID_QUIRK_NO_INIT_REPORTS },
Greg Kroah-Hartman
maintainerPATCH 60/89 smp: Fix SMP function call empty cpu mask race
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wang YanQing <[email protected]>
commit f44310b98ddb7f0d06550d73ed67df5865e3eda5 upstream.
I get the following warning every day with v3.7, once or twice a day:
[ 2235.186027] WARNING: at /mnt/sda7/kernel/linux/arch/x86/kernel/apic/ipi.c:109 default_send_IPI_mask_logical+0x2f/0xb8()
As explained by Linus as well:
| | Once we've done the "list_add_rcu()" to add it to the | queue, we can have (another) IPI to the target CPU that can | now see it and clear the mask. | | So by the time we get to actually send the IPI, the mask might | have been cleared by another IPI. |
This patch also fixes a system hang problem, if the data->cpumask gets cleared after passing this point:
if (WARN_ONCE(!mask, "empty IPI mask"))
return;
then the problem in commit 83d349f35e1a ("x86: don't send an IPI to the empty set of CPU's") will happen again.
--- kernel/smp.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
kernel/smp.c +12 -1
@@ -33,6 +33,7 @@ struct call_function_data {struct call_single_data csd;atomic_t refs;cpumask_var_t cpumask; +cpumask_var_t cpumask_ipi; }; static DEFINE_PER_CPU_SHARED_ALIGNED(struct call_function_data, cfd_data);
@@ -56,6 +57,9 @@ hotplug_cfd(struct notifier_block *nfb,if (!zalloc_cpumask_var_node (&cfd->cpumask,GFP_KERNEL ,cpu_to_node (cpu)))return notifier_from_errno (-ENOMEM ); +if (!zalloc_cpumask_var_node (&cfd->cpumask_ipi,GFP_KERNEL , +cpu_to_node (cpu))) +return notifier_from_errno (-ENOMEM );break ;#ifdef CONFIG_HOTPLUG_CPU
@@ -65,6 +69,7 @@ hotplug_cfd(struct notifier_block *nfb,case CPU_DEAD :case CPU_DEAD_FROZEN :free_cpumask_var (cfd->cpumask); +free_cpumask_var (cfd->cpumask_ipi);break ;#endif };
@@ -526,6 +531,12 @@ void smp_call_function_many(const structreturn ; } +/* +* After we put an entry into the list, data->cpumask +* may be cleared again when another CPU sends another IPI for +* a SMP function call, so data->cpumask will be zero. +*/ +cpumask_copy (data->cpumask_ipi, data->cpumask);raw_spin_lock_irqsave (&call_function.lock, flags);/* * Place entry at the _HEAD_ of the list, so that any cpu still
@@ -549,7 +560,7 @@ void smp_call_function_many(const structsmp_mb ();/* Send a message to all CPUs in the map */ -arch_send_call_function_ipi_mask (data->cpumask); +arch_send_call_function_ipi_mask (data->cpumask_ipi);/* Optionally wait for the CPUs to complete */ if (wait)
Greg Kroah-Hartman
maintainerPATCH 61/89 x86/msr: Add capabilities check
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Cox <[email protected]>
commit c903f0456bc69176912dee6dd25c6a66ee1aed00 upstream.
At the moment the MSR driver only relies upon file system checks. This means that anything as root with any capability set can write to MSRs. Historically that wasn't very interesting but on modern processors the MSRs are such that writing to them provides several ways to execute arbitary code in kernel space. Sample code and documentation on doing this is circulating and MSR attacks are used on Windows 64bit rootkits already.
In the Linux case you still need to be able to open the device file so the impact is fairly limited and reduces the security of some capability and security model based systems down towards that of a generic "root owns the box" setup.
Therefore they should require CAP_SYS_RAWIO to prevent an elevation of capabilities. The impact of this is fairly minimal on most setups because they don't have heavy use of capabilities. Those using SELinux, SMACK or AppArmor rules might want to consider if their rulesets on the MSR driver could be tighter.
--- arch/x86/kernel/msr.c | 3 +++ 1 file changed, 3 insertions(+)
arch/x86/kernel/msr.c +3 -0
@@ -174,6 +174,9 @@ static int msr_open(struct inode *inode,unsigned int cpu;struct cpuinfo_x86 *c; +if (!capable (CAP_SYS_RAWIO )) +return -EPERM ; + cpu =iminor (file->f_path.dentry->d_inode);if (cpu >= nr_cpu_ids || !cpu_online (cpu))return -ENXIO ;/* No such CPU */
Greg Kroah-Hartman
maintainerPATCH 62/89 efi: Make efi_enabled a function to query EFI facilities
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matt Fleming <[email protected]>
commit 83e68189745ad931c2afd45d8ee3303929233e7f upstream.
Originally 'efi_enabled' indicated whether a kernel was booted from EFI firmware. Over time its semantics have changed, and it now indicates whether or not we are booted on an EFI machine with bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.
The immediate motivation for this patch is the bug report at,
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
which details how running a platform driver on an EFI machine that is designed to run under BIOS can cause the machine to become bricked. Also, the following report,
https://bugzilla.kernel.org/show_bug.cgi?id=47121
details how running said driver can also cause Machine Check Exceptions. Drivers need a new means of detecting whether they're running on an EFI machine, as sadly the expression,
if (!efi_enabled)
hasn't been a sufficient condition for quite some time.
Users actually want to query 'efi_enabled' for different reasons - what they really want access to is the list of available EFI facilities.
For instance, the x86 reboot code needs to know whether it can invoke the ResetSystem() function provided by the EFI runtime services, while the ACPI OSL code wants to know whether the EFI config tables were mapped successfully. There are also checks in some of the platform driver code to simply see if they're running on an EFI machine (which would make it a bad idea to do BIOS-y things).
This patch is a prereq for the samsung-laptop fix patch.
--- arch/x86/include/asm/efi.h | 1 arch/x86/kernel/reboot.c | 2 - arch/x86/kernel/setup.c | 28 ++++++++-------- arch/x86/platform/efi/efi.c | 57 +++++++++++++++++++-------------- drivers/acpi/osl.c | 2 - drivers/firmware/dmi_scan.c | 2 - drivers/firmware/efivars.c | 4 +- drivers/firmware/iscsi_ibft_find.c | 2 - drivers/gpu/drm/radeon/radeon_device.c | 3 + drivers/platform/x86/ibm_rtl.c | 2 - drivers/scsi/isci/init.c | 2 - include/linux/efi.h | 24 ++++++++++--- init/main.c | 4 +- 13 files changed, 79 insertions(+), 54 deletions(-)
arch/x86/include/asm/efi.h +1 -0
@@ -94,6 +94,7 @@ extern void __iomem *efi_ioremap(unsigne#endif /* CONFIG_X86_32 */ extern int add_efi_memmap; +extern unsigned long x86_efi_facility;extern void efi_set_executable (efi_memory_desc_t *md,bool executable);extern int efi_memblock_x86_reserve_range (void );extern void efi_call_phys_prelog (void );
arch/x86/kernel/reboot.c +1 -1
@@ -584,7 +584,7 @@ static void native_machine_emergency_resbreak ;case BOOT_EFI : -if (efi_enabled) +if (efi_enabled (EFI_RUNTIME_SERVICES )) efi.reset_system(reboot_mode ? EFI_RESET_WARM : EFI_RESET_COLD,
arch/x86/kernel/setup.c +14 -14
@@ -809,15 +809,15 @@ void __init setup_arch(char **cmdline_p)#ifdef CONFIG_EFI if (!strncmp ((char *)&boot_params.efi_info.efi_loader_signature,"EL32" ,4 )) { - efi_enabled =1 ; - efi_64bit = false; +set_bit (EFI_BOOT , &x86_efi_facility); }else if (!strncmp ((char *)&boot_params.efi_info.efi_loader_signature,"EL64" ,4 )) { - efi_enabled =1 ; - efi_64bit = true; +set_bit (EFI_BOOT , &x86_efi_facility); +set_bit (EFI_64BIT , &x86_efi_facility); } -if (efi_enabled &&efi_memblock_x86_reserve_range ()) - efi_enabled =0 ; + +if (efi_enabled (EFI_BOOT )) +efi_memblock_x86_reserve_range ();#endif x86_init.oem.arch_setup ();
@@ -890,7 +890,7 @@ void __init setup_arch(char **cmdline_p)finish_e820_parsing (); -if (efi_enabled) +if (efi_enabled (EFI_BOOT ))efi_init ();dmi_scan_machine ();
@@ -973,7 +973,7 @@ void __init setup_arch(char **cmdline_p)* The EFI specification says that boot service code won't be called * after ExitBootServices(). This is, in fact, a lie. */ -if (efi_enabled) +if (efi_enabled (EFI_MEMMAP ))efi_reserve_boot_services ();/* preallocate 4k for mptable mpc */
@@ -1112,7 +1112,7 @@ void __init setup_arch(char **cmdline_p)#ifdef CONFIG_VT #if defined(CONFIG_VGA_CONSOLE ) -if (!efi_enabled || (efi_mem_type (0xa0000 ) !=EFI_CONVENTIONAL_MEMORY )) +if (!efi_enabled (EFI_BOOT ) || (efi_mem_type (0xa0000 ) !=EFI_CONVENTIONAL_MEMORY )) conswitchp = &vga_con;#elif defined(CONFIG_DUMMY_CONSOLE ) conswitchp = &dummy_con;
@@ -1129,14 +1129,14 @@ void __init setup_arch(char **cmdline_p)register_refined_jiffies (CLOCK_TICK_RATE );#ifdef CONFIG_EFI -/* Once setup is done above, disable efi_enabled on mismatched -* firmware/kernel archtectures since there is no support for -* runtime services. +/* Once setup is done above, unmap the EFI memory map on +* mismatched firmware/kernel archtectures since there is no +* support for runtime services. */ -if (efi_enabled &&IS_ENABLED (CONFIG_X86_64 ) != efi_64bit) { +if (efi_enabled (EFI_BOOT ) && +IS_ENABLED (CONFIG_X86_64 ) !=efi_enabled (EFI_64BIT )) {pr_info ("efi: Setup done, disabling due to 32/64-bit mismatch\n" );efi_unmap_memmap (); - efi_enabled =0 ; }#endif }
arch/x86/platform/efi/efi.c +34 -23
137 lines not on this page · raw message
drivers/acpi/osl.c +1 -1
@@ -250,7 +250,7 @@ acpi_physical_address __init acpi_os_getreturn acpi_rsdp;#endif -if (efi_enabled) { +if (efi_enabled (EFI_CONFIG_TABLES )) {if (efi.acpi20 !=EFI_INVALID_TABLE_ADDR )return efi.acpi20;else if (efi.acpi !=EFI_INVALID_TABLE_ADDR )
drivers/firmware/dmi_scan.c +1 -1
@@ -471,7 +471,7 @@ void __init dmi_scan_machine(void)char __iomem *p, *q;int rc; -if (efi_enabled) { +if (efi_enabled (EFI_CONFIG_TABLES )) {if (efi.smbios ==EFI_INVALID_TABLE_ADDR ) goto error;
drivers/firmware/efivars.c +2 -2
@@ -1224,7 +1224,7 @@ efivars_init(void)printk (KERN_INFO "EFI Variables Facility v%s %s\n" ,EFIVARS_VERSION ,EFIVARS_DATE ); -if (!efi_enabled) +if (!efi_enabled (EFI_RUNTIME_SERVICES ))return 0 ;/* For now we'll register the efi directory at /sys/firmware/efi */
@@ -1262,7 +1262,7 @@ err_put: static void __exitefivars_exit (void ) { -if (efi_enabled) { +if (efi_enabled (EFI_RUNTIME_SERVICES )) {unregister_efivars (&__efivars);kobject_put (efi_kobj); }
drivers/firmware/iscsi_ibft_find.c +1 -1
@@ -99,7 +99,7 @@ unsigned long __init find_ibft_region(un/* iBFT 1.03 section 1.4.3.1 mandates that UEFI machines will * only use ACPI for this */ -if (!efi_enabled) +if (!efi_enabled (EFI_BOOT ))find_ibft_in_mem ();if (ibft_addr) {
drivers/gpu/drm/radeon/radeon_device.c +2 -1
@@ -429,7 +429,8 @@ bool radeon_card_posted(struct radeon_de {uint32_t reg; -if (efi_enabled && rdev->pdev->subsystem_vendor ==PCI_VENDOR_ID_APPLE ) +if (efi_enabled (EFI_BOOT ) && + rdev->pdev->subsystem_vendor ==PCI_VENDOR_ID_APPLE )return false;/* first check CRTCs */
drivers/platform/x86/ibm_rtl.c +1 -1
@@ -244,7 +244,7 @@ static int __init ibm_rtl_init(void) {if (force)pr_warn ("module loaded by force\n" );/* first ensure that we are running on IBM HW */ -else if (efi_enabled || !dmi_check_system (ibm_rtl_dmi_table)) +else if (efi_enabled (EFI_BOOT ) || !dmi_check_system (ibm_rtl_dmi_table))return -ENODEV ;/* Get the address for the Extended BIOS Data Area */
drivers/scsi/isci/init.c +1 -1
@@ -633,7 +633,7 @@ static int __devinit isci_pci_probe(strureturn -ENOMEM ;pci_set_drvdata (pdev, pci_info); -if (efi_enabled) +if (efi_enabled (EFI_RUNTIME_SERVICES )) orom =isci_get_efi_var (pdev);if (!orom)
include/linux/efi.h +18 -6
@@ -542,18 +542,30 @@ extern int __init efi_setup_pcdp_console#endif /* -* We play games with efi_enabled so that the compiler will, if possible, remove -* EFI-related code altogether. +* We play games with efi_enabled so that the compiler will, if +* possible, remove EFI-related code altogether. */ +#define EFI_BOOT 0/* Were we booted from EFI? */ +#define EFI_SYSTEM_TABLES 1/* Can we use EFI system tables? */ +#define EFI_CONFIG_TABLES 2/* Can we use EFI config tables? */ +#define EFI_RUNTIME_SERVICES 3/* Can we use runtime services? */ +#define EFI_MEMMAP 4/* Can we use EFI memory map? */ +#define EFI_64BIT 5/* Is the firmware 64-bit? */ +#ifdef CONFIG_EFI # ifdef CONFIG_X86 -extern int efi_enabled; -extern bool efi_64bit; +extern int efi_enabled (int facility);# else -# define efi_enabled 1 +static inline int efi_enabled (int facility) +{ +return 1 ; +}# endif #else -# define efi_enabled 0 +static inline int efi_enabled (int facility) +{ +return 0 ; +}#endif /*
init/main.c +2 -2
@@ -604,7 +604,7 @@ asmlinkage void __init start_kernel(voidpidmap_init ();anon_vma_init ();#ifdef CONFIG_X86 -if (efi_enabled) +if (efi_enabled (EFI_RUNTIME_SERVICES ))efi_enter_virtual_mode ();#endif thread_info_cache_init ();
@@ -632,7 +632,7 @@ asmlinkage void __init start_kernel(voidacpi_early_init ();/* before LAPIC and SMP init */ sfi_init_late (); -if (efi_enabled) { +if (efi_enabled (EFI_RUNTIME_SERVICES )) {efi_late_init ();efi_free_boot_services (); }
Greg Kroah-Hartman
maintainerPATCH 63/89 samsung-laptop: Disable on EFI hardware
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matt Fleming <[email protected]>
commit e0094244e41c4d0c7ad69920681972fc45d8ce34 upstream.
It has been reported that running this driver on some Samsung laptops with EFI can cause those machines to become bricked as detailed in the following report,
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
There have also been reports of this driver causing Machine Check Exceptions on recent EFI-enabled Samsung laptops,
https://bugzilla.kernel.org/show_bug.cgi?id=47121
So disable it if booting from EFI since this driver relies on grovelling around in the BIOS memory map which isn't going to work.
--- drivers/platform/x86/samsung-laptop.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/platform/x86/samsung-laptop.c +4 -0
@@ -26,6 +26,7 @@#include <linux/seq_file.h> #include <linux/debugfs.h> #include <linux/ctype.h> +#include <linux/efi.h> #include <acpi/video.h> /*
@@ -1544,6 +1545,9 @@ static int __init samsung_init(void)struct samsung_laptop *samsung;int ret; +if (efi_enabled (EFI_BOOT )) +return -ENODEV ; + quirks = &samsung_unknown;if (!force && !dmi_check_system (samsung_dmi_table))return -ENODEV ;
Greg Kroah-Hartman
maintainerPATCH 64/89 x86, efi: Fix display detection in EFI boot stub
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Woodhouse <[email protected]>
commit 70a479cbe80296d3113e65cc2f713a5101061daf upstream.
When booting under OVMF we have precisely one GOP device, and it implements the ConOut protocol.
We break out of the loop when we look at it... and then promptly abort because 'first_gop' never gets set. We should set first_gop *before* breaking out of the loop. Yes, it doesn't really mean "first" any more, but that doesn't matter. It's only a flag to indicate that a suitable GOP was found.
In fact, we'd do just as well to initialise 'width' to zero in this function, then just check *that* instead of first_gop. But I'll do the minimal fix for now (and for stable@).
--- arch/x86/boot/compressed/eboot.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
arch/x86/boot/compressed/eboot.c +1 -2
@@ -316,10 +316,9 @@ static efi_status_t setup_gop(struct scr* Once we've found a GOP supporting ConOut, * don't bother looking any further. */ + first_gop = gop;if (conout_found)break ; - - first_gop = gop; } }
Greg Kroah-Hartman
maintainerPATCH 65/89 x86, efi: Fix 32-bit EFI handover protocol entry point
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Woodhouse <[email protected]>
commit f791620fa7517e1045742c475a7f005db9a634b8 upstream.
If the bootloader calls the EFI handover entry point as a standard function call, then it'll have a return address on the stack. We need to pop that before calling efi_main(), or the arguments will all be out of position on the stack.
--- arch/x86/boot/compressed/head_32.S | 2 ++ 1 file changed, 2 insertions(+)
arch/x86/boot/compressed/head_32.S +2 -0
@@ -50,8 +50,10 @@ ENTRY(startup_32) pushl %eax pushl %esi pushl %ecx + sub $0x4, %esp .org 0x30,0x90 + add $0x4, %esp call efi_main cmpl $0, %eax movl %eax, %esi
Greg Kroah-Hartman
maintainerPATCH 66/89 efi, x86: Pass a proper identity mapping in efi_call_phys_prelog
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Zimmer <[email protected]>
commit b8f2c21db390273c3eaf0e5308faeaeb1e233840 upstream.
Update efi_call_phys_prelog to install an identity mapping of all available memory. This corrects a bug on very large systems with more then 512 GB in which bios would not be able to access addresses above not in the mapping.
The result is a crash that looks much like this.
BUG: unable to handle kernel paging request at 000000effd870020 IP: [<0000000078bce331>] 0x78bce330 PGD 0 Oops: 0000 [#1] SMP Modules linked in: CPU 0 Pid: 0, comm: swapper/0 Tainted: G W 3.8.0-rc1-next-20121224-medusa_ntz+ #2 Intel Corp. Stoutland Platform RIP: 0010:[<0000000078bce331>] [<0000000078bce331>] 0x78bce330 RSP: 0000:ffffffff81601d28 EFLAGS: 00010006 RAX: 0000000078b80e18 RBX: 0000000000000004 RCX: 0000000000000004 RDX: 0000000078bcf958 RSI: 0000000000002400 RDI: 8000000000000000 RBP: 0000000078bcf760 R08: 000000effd870000 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000000000c3 R12: 0000000000000030 R13: 000000effd870000 R14: 0000000000000000 R15: ffff88effd870000 FS: 0000000000000000(0000) GS:ffff88effe400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000effd870020 CR3: 000000000160c000 CR4: 00000000000006b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper/0 (pid: 0, threadinfo ffffffff81600000, task ffffffff81614400) Stack: 0000000078b80d18 0000000000000004 0000000078bced7b ffff880078b81fff 0000000000000000 0000000000000082 0000000078bce3a8 0000000000002400 0000000060000202 0000000078b80da0 0000000078bce45d ffffffff8107cb5a Call Trace: [<ffffffff8107cb5a>] ? on_each_cpu+0x77/0x83 [<ffffffff8102f4eb>] ? change_page_attr_set_clr+0x32f/0x3ed [<ffffffff81035946>] ? efi_call4+0x46/0x80 [<ffffffff816c5abb>] ? efi_enter_virtual_mode+0x1f5/0x305 [<ffffffff816aeb24>] ? start_kernel+0x34a/0x3d2 [<ffffffff816ae5ed>] ? repair_env_string+0x60/0x60 [<ffffffff816ae2be>] ? x86_64_start_reservations+0xba/0xc1 [<ffffffff816ae120>] ? early_idt_handlers+0x120/0x120 [<ffffffff816ae419>] ? x86_64_start_kernel+0x154/0x163 Code: Bad RIP value. RIP [<0000000078bce331>] 0x78bce330 RSP <ffffffff81601d28> CR2: 000000effd870020 ---[ end trace ead828934fef5eab ]---
--- arch/x86/platform/efi/efi_64.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-)
arch/x86/platform/efi/efi_64.c +17 -5
@@ -38,7 +38,7 @@#include <asm/cacheflush.h> #include <asm/fixmap.h> -static pgd_t save_pgd__initdata ; +static pgd_t *save_pgd__initdata ;static unsigned long efi_flags__initdata ;static void __init early_code_mapping_set_exec (int executable)
@@ -61,12 +61,20 @@ static void __init early_code_mapping_sevoid __init efi_call_phys_prelog (void ) {unsigned long vaddress; +int pgd; +int n_pgds;early_code_mapping_set_exec (1 );local_irq_save (efi_flags); - vaddress = (unsigned long )__va (0x0UL ); - save_pgd = *pgd_offset_k (0x0UL ); -set_pgd (pgd_offset_k (0x0UL ), *pgd_offset_k (vaddress)); + + n_pgds =DIV_ROUND_UP ((max_pfn <<PAGE_SHIFT ),PGDIR_SIZE ); + save_pgd =kmalloc (n_pgds *sizeof (pgd_t),GFP_KERNEL ); + +for (pgd =0 ; pgd < n_pgds; pgd++) { + save_pgd[pgd] = *pgd_offset_k (pgd *PGDIR_SIZE ); + vaddress = (unsigned long )__va (pgd *PGDIR_SIZE ); +set_pgd (pgd_offset_k (pgd *PGDIR_SIZE ), *pgd_offset_k (vaddress)); + }__flush_tlb_all (); }
@@ -75,7 +83,11 @@ void __init efi_call_phys_epilog(void)/* * After the lock is released, the original page table is restored. */ -set_pgd (pgd_offset_k (0x0UL ), save_pgd); +int pgd; +int n_pgds =DIV_ROUND_UP ((max_pfn <<PAGE_SHIFT ) ,PGDIR_SIZE ); +for (pgd =0 ; pgd < n_pgds; pgd++) +set_pgd (pgd_offset_k (pgd *PGDIR_SIZE ), save_pgd[pgd]); +kfree (save_pgd);__flush_tlb_all ();local_irq_restore (efi_flags);early_code_mapping_set_exec (0 );
Greg Kroah-Hartman
maintainerPATCH 67/89 x86, efi: Set runtime_version to the EFI spec revision
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matt Fleming <[email protected]>
commit 712ba9e9afc4b3d3d6fa81565ca36fe518915c01 upstream.
efi.runtime_version is erroneously being set to the value of the vendor's firmware revision instead of that of the implemented EFI specification. We can't deduce which EFI functions are available based on the revision of the vendor's firmware since the version scheme is likely to be unique to each vendor.
What we really need to know is the revision of the implemented EFI specification, which is available in the EFI System Table header.
--- arch/x86/platform/efi/efi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/platform/efi/efi.c +1 -1
@@ -949,7 +949,7 @@ void __init efi_enter_virtual_mode(void)* * Call EFI services through wrapper functions. */ - efi.runtime_version = efi_systab.fw_revision; + efi.runtime_version = efi_systab.hdr.revision; efi.get_time = virt_efi_get_time; efi.set_time = virt_efi_set_time; efi.get_wakeup_time = virt_efi_get_wakeup_time;
Greg Kroah-Hartman
maintainerPATCH 68/89 xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Chinner <[email protected]>
commit eb178619f930fa2ba2348de332a1ff1c66a31424 upstream.
When _xfs_buf_find is passed an out of range address, it will fail to find a relevant struct xfs_perag and oops with a null dereference. This can happen when trying to walk a filesystem with a metadata inode that has a partially corrupted extent map (i.e. the block number returned is corrupt, but is otherwise intact) and we try to read from the corrupted block address.
In this case, just fail the lookup. If it is readahead being issued, it will simply not be done, but if it is real read that fails we will get an error being reported. Ideally this case should result in an EFSCORRUPTED error being reported, but we cannot return an error through xfs_buf_read() or xfs_buf_get() so this lookup failure may result in ENOMEM or EIO errors being reported instead.
--- fs/xfs/xfs_buf.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
fs/xfs/xfs_buf.c +18 -0
@@ -487,6 +487,7 @@ _xfs_buf_find(struct rb_node *parent;xfs_buf_t *bp;xfs_daddr_t blkno = map[0 ].bm_bn; +xfs_daddr_t eofs;int numblks =0 ;int i;
@@ -498,6 +499,23 @@ _xfs_buf_find(ASSERT (!(numbytes < (1 << btp->bt_sshift)));ASSERT (!(BBTOB (blkno) & (xfs_off_t )btp->bt_smask)); +/* +* Corrupted block numbers can get through to here, unfortunately, so we +* have to check that the buffer falls within the filesystem bounds. +*/ + eofs =XFS_FSB_TO_BB (btp->bt_mount, btp->bt_mount->m_sb.sb_dblocks); +if (blkno >= eofs) { +/* +* XXX (dgc): we should really be returning EFSCORRUPTED here, +* but none of the higher level infrastructure supports +* returning a specific error on buffer lookup failures. +*/ +xfs_alert (btp->bt_mount, +"%s: Block out of range: block 0x%llx, EOFS 0x%llx " , + __func__, blkno, eofs); +return NULL ; + } +/* get tree root */ pag =xfs_perag_get (btp->bt_mount,xfs_daddr_to_agno (btp->bt_mount, blkno));
Paolo Bonzini
maintainerRe: [ 68/89] xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end
Il 01/02/2013 14:08, Greg Kroah-Hartman ha scritto:
Quoted 15 lines
3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Chinner <[email protected]>
commit
eb178619f930fa2ba2348de332a1ff1c66a31424upstream.When
_xfs_buf_findis passed an out of range address, it will fail to find a relevant structxfs_peragand oops with a null dereference. This can happen when trying to walk a filesystem with a metadata inode that has a partially corrupted extent map (i.e. the block number returned is corrupt, but is otherwise intact) and we try to read from the corrupted block address.
Quoted 6 lines
In this case, just fail the lookup. If it is readahead being issued, it will simply not be done, but if it is real read that fails we will get an error being reported. Ideally this case should result in an EFSCORRUPTED error being reported, but we cannot return an error through
xfs_buf_read()orxfs_buf_get()so this lookup failure may result in ENOMEM or EIO errors being reported instead.
It looks like this breaks xfs_growfs. See
http://bugzilla.redhat.com/show_bug.cgi?id=909602.
Paolo
Quoted 47 lines
Signed-off-by Dave Chinner <[email protected]>Reviewed-by Brian Foster <[email protected]>Reviewed-by Ben Myers <[email protected]>Signed-off-by Ben Myers <[email protected]>Cc CAI Qian <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- fs/xfs/xfs_buf.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)fs/xfs/xfs_buf.c +18
-0@@ -487,6 +487,7 @@ _xfs_buf_find(struct rb_node *parent;xfs_buf_t *bp;xfs_daddr_t blkno = map[0 ].bm_bn; +xfs_daddr_t eofs;int numblks =0 ;int i;@@ -498,6 +499,23 @@ _xfs_buf_find(ASSERT (!(numbytes < (1 << btp->bt_sshift)));ASSERT (!(BBTOB (blkno) & (xfs_off_t )btp->bt_smask)); +/* +* Corrupted block numbers can get through to here, unfortunately, so we +* have to check that the buffer falls within the filesystem bounds. +*/ + eofs =XFS_FSB_TO_BB (btp->bt_mount, btp->bt_mount->m_sb.sb_dblocks); +if (blkno >= eofs) { +/* +* XXX (dgc): we should really be returning EFSCORRUPTED here, +* but none of the higher level infrastructure supports +* returning a specific error on buffer lookup failures. +*/ +xfs_alert (btp->bt_mount, +"%s: Block out of range: block 0x%llx, EOFS 0x%llx " , + __func__, blkno, eofs); +return NULL ; + } +/* get tree root */ pag =xfs_perag_get (btp->bt_mount,xfs_daddr_to_agno (btp->bt_mount, blkno));
Greg Kroah-Hartman
maintainerRe: [ 68/89] xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end
Quoted 23 lines · Paolo Bonzini
Il 01/02/2013 14:08, Greg Kroah-Hartman ha scritto:
Quoted 15 lines
3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Chinner <[email protected]>
commit
eb178619f930fa2ba2348de332a1ff1c66a31424upstream.When
_xfs_buf_findis passed an out of range address, it will fail to find a relevant structxfs_peragand oops with a null dereference. This can happen when trying to walk a filesystem with a metadata inode that has a partially corrupted extent map (i.e. the block number returned is corrupt, but is otherwise intact) and we try to read from the corrupted block address.Quoted 6 lines
In this case, just fail the lookup. If it is readahead being issued, it will simply not be done, but if it is real read that fails we will get an error being reported. Ideally this case should result in an EFSCORRUPTED error being reported, but we cannot return an error through
xfs_buf_read()orxfs_buf_get()so this lookup failure may result in ENOMEM or EIO errors being reported instead.
Quoted 2 lines
It looks like this breaks
xfs_growfs. See
http://bugzilla.redhat.com/show_bug.cgi?id=909602.
Ick, not good.
Dave, any thoughts here? Should I drop this from the 3.7-stable queue?
greg k-h
Re: [ 68/89] xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end
[cc [email protected]]
Quoted 24 lines · Greg Kroah-Hartman
Quoted 23 lines · Paolo Bonzini
Il 01/02/2013 14:08, Greg Kroah-Hartman ha scritto:
Quoted 21 lines
3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Chinner <[email protected]>
commit
eb178619f930fa2ba2348de332a1ff1c66a31424upstream.When
_xfs_buf_findis passed an out of range address, it will fail to find a relevant structxfs_peragand oops with a null dereference. This can happen when trying to walk a filesystem with a metadata inode that has a partially corrupted extent map (i.e. the block number returned is corrupt, but is otherwise intact) and we try to read from the corrupted block address.In this case, just fail the lookup. If it is readahead being issued, it will simply not be done, but if it is real read that fails we will get an error being reported. Ideally this case should result in an EFSCORRUPTED error being reported, but we cannot return an error through
xfs_buf_read()orxfs_buf_get()so this lookup failure may result in ENOMEM or EIO errors being reported instead.
Quoted 2 lines
Quoted 2 lines
It looks like this breaks
xfs_growfs. See
http://bugzilla.redhat.com/show_bug.cgi?id=909602.
Entirely possible, as the filesystem size is not updated until after all the new metadata is written to disk. in 3.8, there's this commit:
commit fd23683c3b1ab905cba61ea2981c156f4bf52845
Author: Dave Chinner <[email protected]> Date: Mon Nov 12 22:53:59 2012 +1100
xfs: growfs: use uncached buffers for new headers
When writing the new AG headers to disk, we can't attach write verifiers because they have a dependency on the struct xfs-perag being attached to the buffer to be fully initialised and growfs can't fully initialise them until later in the process.
The simplest way to avoid this problem is to use uncached buffers for writing the new headers. These buffers don't have the xfs-perag attached to them, so it's simple to detect in the write verifier and be able to skip the checks that need the xfs-perag.
This enables us to attach the appropriate buffer ops to the buffer and henc calculate CRCs on the way to disk. IT also means that the buffer is torn down immediately, and so the first access to the AG headers will re-read the header from disk and perform full verification of the buffer. This way we also can catch corruptions due to problems that went undetected in growfs.
Reviewed-by Rich Johnston <[email protected]>
As part of the metadata verifier feature. It means that growfs no longer uses cached buffers, and hence does not pass through _xfs_buf_find() and hence will not trigger the beyond-EOFS that the above commit adds.
Quoted 3 lines
Ick, not good.
Dave, any thoughts here? Should I drop this from the 3.7-stable queue?
Yeah, drop it.
But what I'm now wondering is how this patch got proposed for 3.7-stable. I don't recall seeing anything about this being proposed.
<trolls email archives>
Oh, it happened while I was at LCA and didn't have any access to Red Hat email and there was a private thread about it. By the time I read it the stable kernel was already released and so it immediately dropped from my attention.
XFS Maintainers: Major process fail. Patches that are being proposed for backports need to be posted to the XFS list, reviewed and tested before saying they are OK to go. We have several growfs tests in xfstests would have failed if this was actually tested.
Stable folk: This is the reason why I, quite frankly, don't want to support stable kernels *at all*. The overhead of backporting and testing a patch to a single kernel target to ensure there are no unintended regressions is significant, and there are so many stable kernels no it's just a waste of developer time to try to support them. And in this case, the process simply wasn't executed and an unintended regression that is >this close< to causing filesystem corruption slipped through to the stable series.....
Red Hat/Fedora folk: please report upstream XFS bugs/regressions to [email protected] or #xfs on freednode so we know about them immediately and can triage problems quickly via email. Sure, point us to the BZ you've raised, but tell us about the problem ASAP. That way when users ask us about a problem, we are not completely clueless...
Cheers,
Dave.
Signature · 2 lines
Dave Chinner [email protected]
Greg Kroah-Hartman
maintainerRe: [ 68/89] xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end
Quoted 87 lines · Dave Chinner
[cc [email protected]]
Quoted 24 lines · Greg Kroah-Hartman
Quoted 23 lines · Paolo Bonzini
Il 01/02/2013 14:08, Greg Kroah-Hartman ha scritto:
Quoted 21 lines
3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Chinner <[email protected]>
commit
eb178619f930fa2ba2348de332a1ff1c66a31424upstream.When
_xfs_buf_findis passed an out of range address, it will fail to find a relevant structxfs_peragand oops with a null dereference. This can happen when trying to walk a filesystem with a metadata inode that has a partially corrupted extent map (i.e. the block number returned is corrupt, but is otherwise intact) and we try to read from the corrupted block address.In this case, just fail the lookup. If it is readahead being issued, it will simply not be done, but if it is real read that fails we will get an error being reported. Ideally this case should result in an EFSCORRUPTED error being reported, but we cannot return an error through
xfs_buf_read()orxfs_buf_get()so this lookup failure may result in ENOMEM or EIO errors being reported instead.Quoted 2 lines
Quoted 2 lines
It looks like this breaks
xfs_growfs. See
http://bugzilla.redhat.com/show_bug.cgi?id=909602.Entirely possible, as the filesystem size is not updated until after all the new metadata is written to disk. in 3.8, there's this commit:
commit
fd23683c3b1ab905cba61ea2981c156f4bf52845Author: Dave Chinner <[email protected]> Date: Mon Nov 12 22:53:59 2012 +1100xfs: growfs: use uncached buffers for new headers
When writing the new AG headers to disk, we can't attach write verifiers because they have a dependency on the struct xfs-perag being attached to the buffer to be fully initialised and growfs can't fully initialise them until later in the process.
The simplest way to avoid this problem is to use uncached buffers for writing the new headers. These buffers don't have the xfs-perag attached to them, so it's simple to detect in the write verifier and be able to skip the checks that need the xfs-perag.
This enables us to attach the appropriate buffer ops to the buffer and henc calculate CRCs on the way to disk. IT also means that the buffer is torn down immediately, and so the first access to the AG headers will re-read the header from disk and perform full verification of the buffer. This way we also can catch corruptions due to problems that went undetected in growfs.
Signed-off-by Dave Chinner <[email protected]>Reviewed-by Rich Johnston <[email protected]>
Signed-off-by Ben Myers <[email protected]>As part of the metadata verifier feature. It means that growfs no longer uses cached buffers, and hence does not pass through
_xfs_buf_find()and hence will not trigger the beyond-EOFS that the above commit adds.Quoted 3 lines
Ick, not good.
Dave, any thoughts here? Should I drop this from the 3.7-stable queue?
Yeah, drop it.
But what I'm now wondering is how this patch got proposed for 3.7-stable. I don't recall seeing anything about this being proposed.
<trolls email archives>
Oh, it happened while I was at LCA and didn't have any access to Red Hat email and there was a private thread about it. By the time I read it the stable kernel was already released and so it immediately dropped from my attention.
XFS Maintainers: Major process fail. Patches that are being proposed for backports need to be posted to the XFS list, reviewed and tested before saying they are OK to go. We have several growfs tests in xfstests would have failed if this was actually tested.
Quoted 8 lines
Stable folk: This is the reason why I, quite frankly, don't want to support stable kernels *at all*. The overhead of backporting and testing a patch to a single kernel target to ensure there are no unintended regressions is significant, and there are so many stable kernels no it's just a waste of developer time to try to support them. And in this case, the process simply wasn't executed and an unintended regression that is >this close< to causing filesystem corruption slipped through to the stable series.....
Ok, how about I never apply any xfs stable kernel patch, unless you send it to [email protected]? I have that rule in place for some other subsystems that don't want me applying stuff that they aren't aware of, and have no problem doing the same thing here.
Just let me know.
I'll go revert this patch for the next 3.7-stable release.
thanks,
greg k-h
Re: [ 68/89] xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end
Greg,
Quoted 97 lines · Greg Kroah-Hartman
Quoted 87 lines · Dave Chinner
[cc [email protected]]
Quoted 24 lines · Greg Kroah-Hartman
Quoted 23 lines · Paolo Bonzini
Il 01/02/2013 14:08, Greg Kroah-Hartman ha scritto:
Quoted 21 lines
3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Chinner <[email protected]>
commit
eb178619f930fa2ba2348de332a1ff1c66a31424upstream.When
_xfs_buf_findis passed an out of range address, it will fail to find a relevant structxfs_peragand oops with a null dereference. This can happen when trying to walk a filesystem with a metadata inode that has a partially corrupted extent map (i.e. the block number returned is corrupt, but is otherwise intact) and we try to read from the corrupted block address.In this case, just fail the lookup. If it is readahead being issued, it will simply not be done, but if it is real read that fails we will get an error being reported. Ideally this case should result in an EFSCORRUPTED error being reported, but we cannot return an error through
xfs_buf_read()orxfs_buf_get()so this lookup failure may result in ENOMEM or EIO errors being reported instead.Quoted 2 lines
Quoted 2 lines
It looks like this breaks
xfs_growfs. See
http://bugzilla.redhat.com/show_bug.cgi?id=909602.Entirely possible, as the filesystem size is not updated until after all the new metadata is written to disk. in 3.8, there's this commit:
commit
fd23683c3b1ab905cba61ea2981c156f4bf52845Author: Dave Chinner <[email protected]> Date: Mon Nov 12 22:53:59 2012 +1100xfs: growfs: use uncached buffers for new headers
When writing the new AG headers to disk, we can't attach write verifiers because they have a dependency on the struct xfs-perag being attached to the buffer to be fully initialised and growfs can't fully initialise them until later in the process.
The simplest way to avoid this problem is to use uncached buffers for writing the new headers. These buffers don't have the xfs-perag attached to them, so it's simple to detect in the write verifier and be able to skip the checks that need the xfs-perag.
This enables us to attach the appropriate buffer ops to the buffer and henc calculate CRCs on the way to disk. IT also means that the buffer is torn down immediately, and so the first access to the AG headers will re-read the header from disk and perform full verification of the buffer. This way we also can catch corruptions due to problems that went undetected in growfs.
Signed-off-by Dave Chinner <[email protected]>Reviewed-by Rich Johnston <[email protected]>
Signed-off-by Ben Myers <[email protected]>As part of the metadata verifier feature. It means that growfs no longer uses cached buffers, and hence does not pass through
_xfs_buf_find()and hence will not trigger the beyond-EOFS that the above commit adds.Quoted 3 lines
Ick, not good.
Dave, any thoughts here? Should I drop this from the 3.7-stable queue?
Yeah, drop it.
But what I'm now wondering is how this patch got proposed for 3.7-stable. I don't recall seeing anything about this being proposed.
<trolls email archives>
Oh, it happened while I was at LCA and didn't have any access to Red Hat email and there was a private thread about it. By the time I read it the stable kernel was already released and so it immediately dropped from my attention.
XFS Maintainers: Major process fail. Patches that are being proposed for backports need to be posted to the XFS list, reviewed and tested before saying they are OK to go. We have several growfs tests in xfstests would have failed if this was actually tested.
Quoted 8 lines
Stable folk: This is the reason why I, quite frankly, don't want to support stable kernels *at all*. The overhead of backporting and testing a patch to a single kernel target to ensure there are no unintended regressions is significant, and there are so many stable kernels no it's just a waste of developer time to try to support them. And in this case, the process simply wasn't executed and an unintended regression that is >this close< to causing filesystem corruption slipped through to the stable series.....
Quoted 2 lines
Ok, how about I never apply any xfs stable kernel patch, unless you send it to [email protected]?
Dave has made it clear that he doesn't want to be involved in maintaining -stable kernels. However, my team at SGI is interested in maintaining -stable kernels. We're not going to use the fact that there is a risk of regression as an excuse to starve -stable of relevant fixes, just as we do not use it as an excuse to starve the upstream branch of feature content.
Quoted 5 lines
I have that rule in place for some other subsystems that don't want me applying stuff that they aren't aware of, and have no problem doing the same thing here.
Just let me know.
Here are the usual suspects:
Ben Myers <[email protected]>
Mark Tinguely <[email protected]>
Dave Chinner <[email protected]>
Eric Sandeen <[email protected]>
Quoted 1 line
I'll go revert this patch for the next 3.7-stable release.
Much appreciated.
Regards,
Ben
Greg Kroah-Hartman
maintainerRe: [ 68/89] xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end
Quoted 113 lines · Ben Myers
Greg,
Quoted 97 lines · Greg Kroah-Hartman
Quoted 87 lines · Dave Chinner
[cc [email protected]]
Quoted 24 lines · Greg Kroah-Hartman
Quoted 23 lines · Paolo Bonzini
Il 01/02/2013 14:08, Greg Kroah-Hartman ha scritto:
Quoted 21 lines
3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Chinner <[email protected]>
commit
eb178619f930fa2ba2348de332a1ff1c66a31424upstream.When
_xfs_buf_findis passed an out of range address, it will fail to find a relevant structxfs_peragand oops with a null dereference. This can happen when trying to walk a filesystem with a metadata inode that has a partially corrupted extent map (i.e. the block number returned is corrupt, but is otherwise intact) and we try to read from the corrupted block address.In this case, just fail the lookup. If it is readahead being issued, it will simply not be done, but if it is real read that fails we will get an error being reported. Ideally this case should result in an EFSCORRUPTED error being reported, but we cannot return an error through
xfs_buf_read()orxfs_buf_get()so this lookup failure may result in ENOMEM or EIO errors being reported instead.Quoted 2 lines
Quoted 2 lines
It looks like this breaks
xfs_growfs. See
http://bugzilla.redhat.com/show_bug.cgi?id=909602.Entirely possible, as the filesystem size is not updated until after all the new metadata is written to disk. in 3.8, there's this commit:
commit
fd23683c3b1ab905cba61ea2981c156f4bf52845Author: Dave Chinner <[email protected]> Date: Mon Nov 12 22:53:59 2012 +1100xfs: growfs: use uncached buffers for new headers
When writing the new AG headers to disk, we can't attach write verifiers because they have a dependency on the struct xfs-perag being attached to the buffer to be fully initialised and growfs can't fully initialise them until later in the process.
The simplest way to avoid this problem is to use uncached buffers for writing the new headers. These buffers don't have the xfs-perag attached to them, so it's simple to detect in the write verifier and be able to skip the checks that need the xfs-perag.
This enables us to attach the appropriate buffer ops to the buffer and henc calculate CRCs on the way to disk. IT also means that the buffer is torn down immediately, and so the first access to the AG headers will re-read the header from disk and perform full verification of the buffer. This way we also can catch corruptions due to problems that went undetected in growfs.
Signed-off-by Dave Chinner <[email protected]>Reviewed-by Rich Johnston <[email protected]>
Signed-off-by Ben Myers <[email protected]>As part of the metadata verifier feature. It means that growfs no longer uses cached buffers, and hence does not pass through
_xfs_buf_find()and hence will not trigger the beyond-EOFS that the above commit adds.Quoted 3 lines
Ick, not good.
Dave, any thoughts here? Should I drop this from the 3.7-stable queue?
Yeah, drop it.
But what I'm now wondering is how this patch got proposed for 3.7-stable. I don't recall seeing anything about this being proposed.
<trolls email archives>
Oh, it happened while I was at LCA and didn't have any access to Red Hat email and there was a private thread about it. By the time I read it the stable kernel was already released and so it immediately dropped from my attention.
XFS Maintainers: Major process fail. Patches that are being proposed for backports need to be posted to the XFS list, reviewed and tested before saying they are OK to go. We have several growfs tests in xfstests would have failed if this was actually tested.
Quoted 8 lines
Stable folk: This is the reason why I, quite frankly, don't want to support stable kernels *at all*. The overhead of backporting and testing a patch to a single kernel target to ensure there are no unintended regressions is significant, and there are so many stable kernels no it's just a waste of developer time to try to support them. And in this case, the process simply wasn't executed and an unintended regression that is >this close< to causing filesystem corruption slipped through to the stable series.....
Quoted 2 lines
Ok, how about I never apply any xfs stable kernel patch, unless you send it to [email protected]?
Dave has made it clear that he doesn't want to be involved in maintaining -stable kernels. However, my team at SGI is interested in maintaining -stable kernels. We're not going to use the fact that there is a risk of regression as an excuse to starve -stable of relevant fixes, just as we do not use it as an excuse to starve the upstream branch of feature content.
Quoted 4 lines
I have that rule in place for some other subsystems that don't want me applying stuff that they aren't aware of, and have no problem doing the same thing here.
Quoted 8 lines
Quoted 1 line
Just let me know.
Here are the usual suspects:
Ben Myers <[email protected]>
Mark Tinguely <[email protected]>
Dave Chinner <[email protected]>
Eric Sandeen <[email protected]>
Ok, but for this specific patch, did I do something wrong in taking it?
I guess I'll just let you send me xfs patches, is that ok with everyone else? Dave can just ignore them, especially given redhat's horrible email system :)
thanks,
greg k-h
Re: [ 68/89] xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end
Hey Greg,
Quoted 116 lines · Greg Kroah-Hartman
Quoted 115 lines · Ben Myers
Greg,
Quoted 97 lines · Greg Kroah-Hartman
Quoted 87 lines · Dave Chinner
[cc [email protected]]
Quoted 24 lines · Greg Kroah-Hartman
Quoted 23 lines · Paolo Bonzini
Il 01/02/2013 14:08, Greg Kroah-Hartman ha scritto:
Quoted 21 lines
3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Chinner <[email protected]>
commit
eb178619f930fa2ba2348de332a1ff1c66a31424upstream.When
_xfs_buf_findis passed an out of range address, it will fail to find a relevant structxfs_peragand oops with a null dereference. This can happen when trying to walk a filesystem with a metadata inode that has a partially corrupted extent map (i.e. the block number returned is corrupt, but is otherwise intact) and we try to read from the corrupted block address.In this case, just fail the lookup. If it is readahead being issued, it will simply not be done, but if it is real read that fails we will get an error being reported. Ideally this case should result in an EFSCORRUPTED error being reported, but we cannot return an error through
xfs_buf_read()orxfs_buf_get()so this lookup failure may result in ENOMEM or EIO errors being reported instead.Quoted 2 lines
Quoted 2 lines
It looks like this breaks
xfs_growfs. See
http://bugzilla.redhat.com/show_bug.cgi?id=909602.Entirely possible, as the filesystem size is not updated until after all the new metadata is written to disk. in 3.8, there's this commit:
commit
fd23683c3b1ab905cba61ea2981c156f4bf52845Author: Dave Chinner <[email protected]> Date: Mon Nov 12 22:53:59 2012 +1100xfs: growfs: use uncached buffers for new headers
When writing the new AG headers to disk, we can't attach write verifiers because they have a dependency on the struct xfs-perag being attached to the buffer to be fully initialised and growfs can't fully initialise them until later in the process.
The simplest way to avoid this problem is to use uncached buffers for writing the new headers. These buffers don't have the xfs-perag attached to them, so it's simple to detect in the write verifier and be able to skip the checks that need the xfs-perag.
This enables us to attach the appropriate buffer ops to the buffer and henc calculate CRCs on the way to disk. IT also means that the buffer is torn down immediately, and so the first access to the AG headers will re-read the header from disk and perform full verification of the buffer. This way we also can catch corruptions due to problems that went undetected in growfs.
Signed-off-by Dave Chinner <[email protected]>Reviewed-by Rich Johnston <[email protected]>
Signed-off-by Ben Myers <[email protected]>As part of the metadata verifier feature. It means that growfs no longer uses cached buffers, and hence does not pass through
_xfs_buf_find()and hence will not trigger the beyond-EOFS that the above commit adds.Quoted 3 lines
Ick, not good.
Dave, any thoughts here? Should I drop this from the 3.7-stable queue?
Yeah, drop it.
But what I'm now wondering is how this patch got proposed for 3.7-stable. I don't recall seeing anything about this being proposed.
<trolls email archives>
Oh, it happened while I was at LCA and didn't have any access to Red Hat email and there was a private thread about it. By the time I read it the stable kernel was already released and so it immediately dropped from my attention.
XFS Maintainers: Major process fail. Patches that are being proposed for backports need to be posted to the XFS list, reviewed and tested before saying they are OK to go. We have several growfs tests in xfstests would have failed if this was actually tested.
Quoted 8 lines
Stable folk: This is the reason why I, quite frankly, don't want to support stable kernels *at all*. The overhead of backporting and testing a patch to a single kernel target to ensure there are no unintended regressions is significant, and there are so many stable kernels no it's just a waste of developer time to try to support them. And in this case, the process simply wasn't executed and an unintended regression that is >this close< to causing filesystem corruption slipped through to the stable series.....
Quoted 2 lines
Ok, how about I never apply any xfs stable kernel patch, unless you send it to [email protected]?
Dave has made it clear that he doesn't want to be involved in maintaining -stable kernels. However, my team at SGI is interested in maintaining -stable kernels. We're not going to use the fact that there is a risk of regression as an excuse to starve -stable of relevant fixes, just as we do not use it as an excuse to starve the upstream branch of feature content.
Quoted 5 lines
I have that rule in place for some other subsystems that don't want me applying stuff that they aren't aware of, and have no problem doing the same thing here.
Just let me know.
Quoted 8 lines
Quoted 6 lines
Here are the usual suspects:
Ben Myers <[email protected]>
Mark Tinguely <[email protected]>
Dave Chinner <[email protected]>
Eric Sandeen <[email protected]>Ok, but for this specific patch, did I do something wrong in taking it?
No, not in my opinion. I was on the CC and had the opportunity to NACK it and failed to do so. So today I'm eating crow.
Quoted 2 lines
I guess I'll just let you send me xfs patches, is that ok with everyone else?
For my part, I trust any of the gentlemen I listed above to do adequate testing before proposing xfs patches for -stable. There are more xfs geeks who fit into that category (and I prefer not to exclude), but that's my suggestion for now.
Quoted 2 lines
Dave can just ignore them, especially given redhat's horrible email system :)
Lol. I think RH will be purchasing a smart phone soon.
Thanks,
Ben
Re: [ 68/89] xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end
In reply to Greg Kroah-HartmanQuoted 6 lines · Greg Kroah-Hartman
Quoted 5 lines · Ben Myers
Quoted 2 lines
Ok, how about I never apply any xfs stable kernel patch, unless you send it to [email protected]?
Dave has made it clear that he doesn't want to be involved in maintaining -stable kernels.
I don't think you quite understand, Ben. It is obvious from the fact that this discussion is taking place that I'm extremely concerned about the quality of -stable kernels and what goes into them. What I think you are missing is that there is a difference between not having the time to do the grunt work of backporting and testing -stable kernels versus wanting to ensure the quality of the maintenance work that does take place remains high.
Why do I say this? Because the responsiblity of maintaining XFS development is not SGI's. It is a community effort, and I am as much responsible as anyone else. Someone else doing a half-arsed job maintaining XFS in -stable kernels reflects badly on *me* as being a senior member of a community that allows it's members to do a half-arsed job on something.
Quoted 2 lines
Quoted 2 lines
However, my team at SGI is interested in maintaining -stable kernels.
Then do the job properly. Being "interested" isn't enough - you need the *commitment* to ensure things are done properly. If you *personally* don't have the the time to ensure that the -stable kernel maintenance is done properly, then don't do it at all.
Quoted 3 lines
Quoted 3 lines
We're not going to use the fact that there is a risk of regression as an excuse to starve -stable of relevant fixes, just as we do not use it as an excuse to starve the upstream branch of feature content.
I'm not complaining because there is a risk of regression in -stable backports, I'm pointing out that our long-standing process used to minimise that risk was not followed.
Besides, -stable backports are all about risk management. The primary consideration for a backport is whether the risk of regressions is higher than the risk of leaving the bug unfixed. We've NACKed lots of proposed patches for -stable simply because the risk of regression outweighes the benefit to users of -stable inclusion.
Yes, there is always a risk of unintended regressions, but you have to do *due diligence* on the backports to -stable trees to minimise the risk factor. Even the most basic "apply the patch, run xfstests" check would have found this regression. So, even if we ignore the risk factors here, a *preventable regression* occurred because due diligence was not performed correctly on the requested patch.
BTW, Ben, I should point out that 6 months ago you said exactly the opposite to this statement - you tried to use "risk of regressions" as an excuse to starve the dev tree of new feature content. i.e. you wanted to apply -stable tree criteria to the -dev tree. Now you are saying that risk of regression is not a reason for rejection for the -stable tree. (i.e. applying -dev tree criteria to the -stable tree). IMO, you are as wrong about the -stable tree now as you were about the -dev tree 6 months ago....
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
I have that rule in place for some other subsystems that don't want me applying stuff that they aren't aware of, and have no problem doing the same thing here.
Just let me know.
Sounds like a fine idea, Greg.
Quoted 6 lines
Quoted 6 lines
Here are the usual suspects:
Ben Myers <[email protected]>
Mark Tinguely <[email protected]>
Dave Chinner <[email protected]>
Eric Sandeen <[email protected]>
I don't think it should be restricted to individuals. The private thread used to request this backport is exactly why I didn't see the request in a timely fashion, and also the reason why we didn't end up with notifications for review going to [email protected].
Hence I'd suggest the only thing that matters is that there is a cc to [email protected], because that means all of the above people (and more) are on that list and hence have the best chance to see and review the backport request.
Quoted 1 line
Ok, but for this specific patch, did I do something wrong in taking it?
No, you didn't do anything wrong, Greg. Stuff went wrong on the XFS side of the fence.
Quoted 2 lines
I guess I'll just let you send me xfs patches, is that ok with everyone else?
Sure, that would work, but only after the patches have been sent to [email protected] for review and testing and been acked. And, of course, the stable submission woul dalso need to have a [email protected] cc on it. ;)
Cheers,
Dave.
Signature · 2 lines
Dave Chinner [email protected]
Re: [ 68/89] xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end
Hey,
Quoted 9 lines · Dave Chinner
Quoted 6 lines · Greg Kroah-Hartman
Quoted 5 lines · Ben Myers
Quoted 2 lines
Ok, how about I never apply any xfs stable kernel patch, unless you send it to [email protected]?
Dave has made it clear that he doesn't want to be involved in maintaining -stable kernels.
I don't think you quite understand, Ben.
...
Quoted 30 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
I have that rule in place for some other subsystems that don't want me applying stuff that they aren't aware of, and have no problem doing the same thing here.
Just let me know.
Sounds like a fine idea, Greg.
Quoted 6 lines
Quoted 6 lines
Here are the usual suspects:
Ben Myers <[email protected]>
Mark Tinguely <[email protected]>
Dave Chinner <[email protected]>
Eric Sandeen <[email protected]>I don't think it should be restricted to individuals. The private thread used to request this backport is exactly why I didn't see the request in a timely fashion, and also the reason why we didn't end up with notifications for review going to [email protected].
Hence I'd suggest the only thing that matters is that there is a cc to [email protected], because that means all of the above people (and more) are on that list and hence have the best chance to see and review the backport request.
Quoted 1 line
Ok, but for this specific patch, did I do something wrong in taking it?
No, you didn't do anything wrong, Greg. Stuff went wrong on the XFS side of the fence.
Quoted 7 lines
Quoted 2 lines
I guess I'll just let you send me xfs patches, is that ok with everyone else?
Sure, that would work, but only after the patches have been sent to [email protected] for review and testing and been acked. And, of course, the stable submission woul dalso need to have a [email protected] cc on it. ;)
Making sure that [email protected] is Cc'd on -stable patches seems reasonable to me. No objection here, Dave.
-Ben
Greg Kroah-Hartman
maintainerPATCH 69/89 drm/radeon: fix error path in kpage allocation
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilija Hadzic <[email protected]>
commit 25d8999780f8c1f53928f4a24a09c01550423109 upstream.
Index into chunks[] array doesn't look right.
--- drivers/gpu/drm/radeon/radeon_cs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/radeon/radeon_cs.c +2 -2
@@ -271,8 +271,8 @@ int radeon_cs_parser_init(struct radeon_ p->chunks[p->chunk_ib_idx].kpage[1 ] =kmalloc (PAGE_SIZE ,GFP_KERNEL );if (p->chunks[p->chunk_ib_idx].kpage[0 ] ==NULL || p->chunks[p->chunk_ib_idx].kpage[1 ] ==NULL ) { -kfree (p->chunks[i].kpage[0 ]); -kfree (p->chunks[i].kpage[1 ]); +kfree (p->chunks[p->chunk_ib_idx].kpage[0 ]); +kfree (p->chunks[p->chunk_ib_idx].kpage[1 ]);return -ENOMEM ; } }
Greg Kroah-Hartman
maintainerPATCH 70/89 drm/radeon: fix a rare case of double kfree
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilija Hadzic <[email protected]>
commit 1da80cfa8727abf404fcee44d04743febea54069 upstream.
If one (but not both) allocations of p->chunks[].kpage[] in radeon_cs_parser_init fail, the error path will free the successfully allocated page, but leave a stale pointer value in the kpage[] field. This will later cause a double-free when radeon_cs_parser_fini is called. This patch fixes the issue by forcing both pointers to NULL after kfree in the error path.
The circumstances under which the problem happens are very rare. The card must be AGP and the system must run out of kmalloc area just at the right time so that one allocation succeeds, while the other fails.
--- drivers/gpu/drm/radeon/radeon_cs.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/gpu/drm/radeon/radeon_cs.c +2 -0
@@ -273,6 +273,8 @@ int radeon_cs_parser_init(struct radeon_ p->chunks[p->chunk_ib_idx].kpage[1] == NULL) {kfree (p->chunks[p->chunk_ib_idx].kpage[0 ]);kfree (p->chunks[p->chunk_ib_idx].kpage[1 ]); + p->chunks[p->chunk_ib_idx].kpage[0 ] =NULL ; + p->chunks[p->chunk_ib_idx].kpage[1 ] =NULL ;return -ENOMEM ; } }
Greg Kroah-Hartman
maintainerPATCH 71/89 kvm: Fix irqfd resampler list walk
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Williamson <[email protected]>
commit 49f8a1a5394d8baee5e56fb71e5cf993c228689a upstream.
Typo for the next pointer means we're walking random data here.
--- virt/kvm/eventfd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
virt/kvm/eventfd.c +1 -1
@@ -332,7 +332,7 @@ kvm_irqfd_assign(struct kvm *kvm, structmutex_lock (&kvm->irqfds.resampler_lock);list_for_each_entry (resampler, - &kvm->irqfds.resampler_list, list) { + &kvm->irqfds.resampler_list, link) {if (resampler->notifier.gsi == irqfd->gsi) { irqfd->resampler = resampler;break ;
Greg Kroah-Hartman
maintainerPATCH 72/89 netfilter: ip[6]t_REJECT: fix wrong transport header pointer in TCP reset
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mukund Jampala <[email protected]>
commit c6f408996c625cb950cad024f90e50519f94713c upstream.
The problem occurs when iptables constructs the tcp reset packet. It doesn't initialize the pointer to the tcp header within the skb. When the skb is passed to the ixgbe driver for transmit, the ixgbe driver attempts to access the tcp header and crashes. Currently, other drivers (such as our 1G e1000e or igb drivers) don't access the tcp header on transmit unless the TSO option is turned on.
<1>BUG: unable to handle kernel NULL pointer dereference at 0000000d <1>IP: [<d081621c>] ixgbe_xmit_frame_ring+0x8cc/0x2260 [ixgbe] <4>*pdpt = 0000000085e5d001 *pde = 0000000000000000
<0>Oops: 0000 [#1] SMP
[...]
<4>Pid: 0, comm: swapper Tainted: P 2.6.35.12 #1 Greencity/Thurley
<4>EIP: 0060:[<d081621c>] EFLAGS: 00010246 CPU: 16
<4>EIP is at ixgbe_xmit_frame_ring+0x8cc/0x2260 [ixgbe]
<4>EAX: c7628820 EBX: 00000007 ECX: 00000000 EDX: 00000000 <4>ESI: 00000008 EDI: c6882180 EBP: dfc6b000 ESP: ced95c48
<4> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
<0>Process swapper (pid: 0, ti=ced94000 task=ced73bd0 task.ti=ced94000) <0>Stack:
<4> cbec7418 c779e0d8 c77cc888 c77cc8a8 0903010a 00000000 c77c0008 00000002 <4><0> cd4997c0 00000010 dfc6b000 00000000 d0d176c9 c77cc8d8 c6882180 cbec7318 <4><0> 00000004 00000004 cbec7230 cbec7110 00000000 cbec70c0 c779e000 00000002 <0>Call Trace:
<4> [<d0d176c9>] ? 0xd0d176c9
<4> [<d0d18a4d>] ? 0xd0d18a4d
<4> [<411e243e>] ? dev_hard_start_xmit+0x218/0x2d7
<4> [<411f03d7>] ? sch_direct_xmit+0x4b/0x114
<4> [<411f056a>] ? __qdisc_run+0xca/0xe0
<4> [<411e28b0>] ? dev_queue_xmit+0x2d1/0x3d0
<4> [<411e8120>] ? neigh_resolve_output+0x1c5/0x20f
<4> [<411e94a1>] ? neigh_update+0x29c/0x330
<4> [<4121cf29>] ? arp_process+0x49c/0x4cd
<4> [<411f80c9>] ? nf_hook_slow+0x3f/0xac
<4> [<4121ca8d>] ? arp_process+0x0/0x4cd
<4> [<4121ca8d>] ? arp_process+0x0/0x4cd
<4> [<4121c6d5>] ? T.901+0x38/0x3b
<4> [<4121c918>] ? arp_rcv+0xa3/0xb4
<4> [<4121ca8d>] ? arp_process+0x0/0x4cd
<4> [<411e1173>] ? __netif_receive_skb+0x32b/0x346
<4> [<411e19e1>] ? netif_receive_skb+0x5a/0x5f
<4> [<411e1ea9>] ? napi_skb_finish+0x1b/0x30
<4> [<d0816eb4>] ? ixgbe_xmit_frame_ring+0x1564/0x2260 [ixgbe] <4> [<41013468>] ? lapic_next_event+0x13/0x16
<4> [<410429b2>] ? clockevents_program_event+0xd2/0xe4
<4> [<411e1b03>] ? net_rx_action+0x55/0x127
<4> [<4102da1a>] ? __do_softirq+0x77/0xeb
<4> [<4102dab1>] ? do_softirq+0x23/0x27
<4> [<41003a67>] ? do_IRQ+0x7d/0x8e
<4> [<41002a69>] ? common_interrupt+0x29/0x30
<4> [<41007bcf>] ? mwait_idle+0x48/0x4d
<4> [<4100193b>] ? cpu_idle+0x37/0x4c
<0>Code: df 09 d7 0f 94 c2 0f b6 d2 e9 e7 fb ff ff 31 db 31 c0 e9 38 ff ff ff 80 78 06 06 0f 85 3e fb ff ff 8b 7c 24 38 8b 8f b8 00 00 00 <0f> b6 51 0d f6 c2 01 0f 85 27 fb ff ff 80 e2 02 75 0d 8b 6c 24 <0>EIP: [<d081621c>] ixgbe_xmit_frame_ring+0x8cc/0x2260 [ixgbe] SS:ESP
--- net/ipv4/netfilter/ipt_REJECT.c | 1 + net/ipv6/netfilter/ip6t_REJECT.c | 1 + 2 files changed, 2 insertions(+)
net/ipv4/netfilter/ipt_REJECT.c +1 -0
@@ -81,6 +81,7 @@ static void send_reset(struct sk_buff *o niph->saddr = oiph->daddr; niph->daddr = oiph->saddr; +skb_reset_transport_header (nskb); tcph = (struct tcphdr *)skb_put (nskb,sizeof (struct tcphdr ));memset (tcph,0 ,sizeof (*tcph)); tcph->source = oth->dest;
net/ipv6/netfilter/ip6t_REJECT.c +1 -0
@@ -132,6 +132,7 @@ static void send_reset(struct net *net, ip6h->saddr = oip6h->daddr; ip6h->daddr = oip6h->saddr; +skb_reset_transport_header (nskb); tcph = (struct tcphdr *)skb_put (nskb,sizeof (struct tcphdr ));/* Truncate to length (no data) */ tcph->doff =sizeof (struct tcphdr )/4 ;
Greg Kroah-Hartman
maintainerPATCH 73/89 netfilter: nf_ct_reasm: fix conntrack reassembly expire code
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haibo Xi <[email protected]>
commit 97cf00e93cc24898493e7a058105e3215257ee04 upstream.
Commit b836c99fd6c9 (ipv6: unify conntrack reassembly expire code with standard one) use the standard IPv6 reassembly code(ip6_expire_frag_queue) to handle conntrack reassembly expire.
In ip6_expire_frag_queue, it invoke dev_get_by_index_rcu to get which device received this expired packet.so we must save ifindex when NF_conntrack get this packet.
With this patch applied, I can see ICMP Time Exceeded sent from the receiver when the sender sent out 1/2 fragmented IPv6 packet.
--- net/ipv6/netfilter/nf_conntrack_reasm.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
net/ipv6/netfilter/nf_conntrack_reasm.c +4 -1
@@ -311,7 +311,10 @@ found:else fq->q.fragments = skb; - skb->dev =NULL ; +if (skb->dev) { + fq->iif = skb->dev->ifindex; + skb->dev =NULL ; + } fq->q.stamp = skb->tstamp; fq->q.meat += skb->len;if (payload_len > fq->q.max_size)
Greg Kroah-Hartman
maintainerPATCH 74/89 x86/Sandy Bridge: Sandy Bridge workaround depends on CONFIG_PCI
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: "H. Peter Anvin" <[email protected]>
commit e43b3cec711a61edf047adf6204d542f3a659ef8 upstream.
early_pci_allowed() and read_pci_config_16() are only available if CONFIG_PCI is defined.
--- arch/x86/kernel/setup.c | 2 ++ 1 file changed, 2 insertions(+)
arch/x86/kernel/setup.c +2 -0
@@ -616,6 +616,7 @@ static unsigned reserve_low = CONFIG_X86static bool __init snb_gfx_workaround_needed (void ) { +#ifdef CONFIG_PCI int i;u16 vendor, devid; static const u16 snb_ids[] = {
@@ -640,6 +641,7 @@ static bool __init snb_gfx_workaround_nefor (i =0 ; i <ARRAY_SIZE (snb_ids); i++)if (devid == snb_ids[i])return true; +#endif return false; }
Greg Kroah-Hartman
maintainerPATCH 75/89 xfs: fix periodic log flushing
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Chinner <[email protected]>
[Please take this patch for -stable in kernels 3.5-3.7. It doesn't have an equivalent upstream commit because the code was removed before the bug was discovered. See f661f1e0bf50 and 7e18530bef6a.]
There is a logic inversion in xfssyncd_worker() which means that the log is not periodically forced or idled correctly. This means that metadata changes aggregated in memory do not get flushed in a timely manner, and hence if filesystem is not cleanly unmounted those changes can be lost. This loss can manifest itself even hours after the changes were made if the filesystem is left to idle without a sync() occurring between the last modification and the crash/shutdown occuring.
--- fs/xfs/xfs_sync.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
If people agree the fix is correct, I'll post it to the -stable list for inclusion...
fs/xfs/xfs_sync.c +1 -1
@@ -400,7 +400,7 @@ xfs_sync_worker(* cancel_delayed_work_sync on this work queue before tearing down * the ail and the log in xfs_log_unmount. */ -if (!(mp->m_super->s_flags &MS_ACTIVE ) && +if ((mp->m_super->s_flags &MS_ACTIVE ) && !(mp->m_flags &XFS_MOUNT_RDONLY )) {/* dgc: errors ignored here */ if (mp->m_super->s_writers.frozen == SB_UNFROZEN &&
Greg Kroah-Hartman
maintainerPATCH 76/89 target: fix regression with dev_link_magic in target_fabric_port_link
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Bellinger <[email protected]>
This is to fix a regression that only affect the stable (not for the mainline) that the stable commit fdf9d86 was incorrectly placed dev->dev_link_magic check before the *dev assignment in target_fabric_port_link() due to fuzzy automatically context adjustment during the back-porting.
--- drivers/target/target_core_fabric_configfs.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-)
drivers/target/target_core_fabric_configfs.c +5 -6
@@ -751,12 +751,6 @@ static int target_fabric_port_link(struct target_fabric_configfs *tf;int ret; -if (dev->dev_link_magic !=SE_DEV_LINK_MAGIC ) { -pr_err ("Bad dev->dev_link_magic, not a valid se_dev_ci pointer:" -" %p to struct se_device: %p\n" , se_dev_ci, dev); -return -EFAULT ; - } - tpg_ci = &lun_ci->ci_parent->ci_group->cg_item; se_tpg =container_of (to_config_group (tpg_ci), struct se_portal_group, tpg_group);
@@ -774,6 +768,11 @@ static int target_fabric_port_link( ret = -ENODEV ; goto out; } +if (dev->dev_link_magic !=SE_DEV_LINK_MAGIC ) { +pr_err ("Bad dev->dev_link_magic, not a valid se_dev_ci pointer:" +" %p to struct se_device: %p\n" , se_dev_ci, dev); +return -EFAULT ; + } lun_p =core_dev_add_lun (se_tpg, dev, lun->unpacked_lun);if (IS_ERR (lun_p)) {
Greg Kroah-Hartman
maintainerPATCH 77/89 netfilter: nfnetlink_log: fix mac address for 6in4 tunnels
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bob Hockney <[email protected]>
commit 0c36b48b36dc84d4215dc9d1cde1bda829214ba6 upstream.
For tunnelled ipv6in4 packets, the LOG target (xt_LOG.c) adjusts the start of the mac field to start at the ethernet header instead of the ipv4 header for the tunnel. This patch conforms what is passed by the NFLOG target through nfnetlink to what the LOG target does. Code borrowed from xt_LOG.c.
--- net/netfilter/nfnetlink_log.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
net/netfilter/nfnetlink_log.c +12 -3
@@ -384,6 +384,7 @@ __build_packet_message(struct nfulnl_insstruct nfgenmsg *nfmsg;sk_buff_data_t old_tail = inst->skb->tail;struct sock *sk; +const unsigned char *hwhdrp; nlh = nlmsg_put(inst->skb, 0, 0, NFNL_SUBSYS_ULOG << 8 | NFULNL_MSG_PACKET,
@@ -485,9 +486,17 @@ __build_packet_message(struct nfulnl_insif (indev &&skb_mac_header_was_set (skb)) {if (nla_put_be16 (inst->skb,NFULA_HWTYPE ,htons (skb->dev->type)) ||nla_put_be16 (inst->skb,NFULA_HWLEN , -htons (skb->dev->hard_header_len)) || -nla_put (inst->skb,NFULA_HWHEADER , skb->dev->hard_header_len, -skb_mac_header (skb))) +htons (skb->dev->hard_header_len))) + goto nla_put_failure; + + hwhdrp =skb_mac_header (skb); + +if (skb->dev->type ==ARPHRD_SIT ) + hwhdrp -=ETH_HLEN ; + +if (hwhdrp >= skb->head && +nla_put (inst->skb,NFULA_HWHEADER , + skb->dev->hard_header_len, hwhdrp)) goto nla_put_failure; }
Greg Kroah-Hartman
maintainerPATCH 78/89 netfilter: nfnetlink_log: fix possible compilation issue due to missing include
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
commit e035edd16ee83498cccc9beedfc215e15cab3a07 upstream.
In (0c36b48 netfilter: nfnetlink_log: fix mac address for 6in4 tunnels) the include file that defines ARPD_SIT was missing. This passed unnoticed during my tests (I did not hit this problem here).
net/netfilter/nfnetlink_log.c: In function '__build_packet_message':net/netfilter/nfnetlink_log.c:494:25: error: 'ARPHRD_SIT' undeclared (first use in this function) net/netfilter/nfnetlink_log.c:494:25: note: each undeclared identifier is reported only once for +each function it appears in
--- net/netfilter/nfnetlink_log.c | 1 + 1 file changed, 1 insertion(+)
net/netfilter/nfnetlink_log.c +1 -0
@@ -13,6 +13,7 @@*/ #include <linux/module.h> #include <linux/skbuff.h> +#include <linux/if_arp.h> #include <linux/init.h> #include <linux/ip.h> #include <linux/ipv6.h>
Greg Kroah-Hartman
maintainerPATCH 79/89 netfilter: xt_CT: recover NOTRACK target support
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
commit 10db9069eb5c60195170a4119bdbcbce69a4945f upstream.
Florian Westphal reported that the removal of the NOTRACK target (9655050 netfilter: remove xt_NOTRACK) is breaking some existing setups.
That removal was scheduled for removal since long time ago as described in Documentation/feature-removal-schedule.txt
What: xt_NOTRACK Files: net/netfilter/xt_NOTRACK.c When: April 2011 Why: Superseded by xt_CT
Still, people may have not notice / may have decided to stick to an old iptables version. I agree with him in that some more conservative approach by spotting some printk to warn users for some time is less agressive.
Current iptables 1.4.16.3 already contains the aliasing support that makes it point to the CT target, so upgrading would fix it. Still, the policy so far has been to avoid pushing our users to upgrade.
As a solution, this patch recovers the NOTRACK target inside the CT target and it now spots a warning.
--- include/net/netns/x_tables.h | 1 net/netfilter/Kconfig | 4 +++ net/netfilter/xt_CT.c | 50 ++++++++++++++++++++++++++++++++++++++++++- 3 files changed, 54 insertions(+), 1 deletion(-)
include/net/netns/x_tables.h +1 -0
@@ -8,6 +8,7 @@ struct ebt_table;struct netns_xt {struct list_head tables[NFPROTO_NUMPROTO ]; +bool notrack_deprecated_warning;#if defined(CONFIG_BRIDGE_NF_EBTABLES ) || \ defined(CONFIG_BRIDGE_NF_EBTABLES_MODULE )struct ebt_table *broute_table;
net/netfilter/Kconfig +4 -0
@@ -680,6 +680,10 @@ config NETFILTER_XT_TARGET_NFQUEUE To compile it as a module, choose M here. If unsure, say N. +config NETFILTER_XT_TARGET_NOTRACK + tristate '"NOTRACK" target support (DEPRECATED)' + select NETFILTER_XT_TARGET_CT + config NETFILTER_XT_TARGET_RATEEST tristate '"RATEEST" target support' depends on NETFILTER_ADVANCED
net/netfilter/xt_CT.c +49 -1
66 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 80/89 netfilter: fix missing dependencies for the NOTRACK target
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
commit 757ae316fb35811cfd8c67de0e0b8680ec4c1f37 upstream.
warning: (NETFILTER_XT_TARGET_NOTRACK) selects NETFILTER_XT_TARGET_CT which has unmet direct +dependencies (NET && INET && NETFILTER && NETFILTER_XTABLES && NF_CONNTRACK && (IP_NF_RAW || +IP6_NF_RAW) && NETFILTER_ADVANCED)
--- net/netfilter/Kconfig | 3 +++ 1 file changed, 3 insertions(+)
net/netfilter/Kconfig +3 -0
@@ -682,6 +682,9 @@ config NETFILTER_XT_TARGET_NFQUEUE config NETFILTER_XT_TARGET_NOTRACK tristate '"NOTRACK" target support (DEPRECATED)' + depends on NF_CONNTRACK + depends on IP_NF_RAW || IP6_NF_RAW + depends on NETFILTER_ADVANCED select NETFILTER_XT_TARGET_CT config NETFILTER_XT_TARGET_RATEEST
Greg Kroah-Hartman
maintainerPATCH 81/89 netfilter: xt_hashlimit: fix namespace destroy path
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Vitaly E. Lavrov" <[email protected]>
commit 32263dd1b43378b4f7d7796ed713f77e95f27e8a upstream.
recent_net_exit() is called before recent_mt_destroy() in the destroy path of network namespaces. Make sure there are no entries in the parent proc entry xt_recent before removing it.
--- net/netfilter/xt_hashlimit.c | 29 +++++++++++++++++++++++++---- 1 file changed, 25 insertions(+), 4 deletions(-)
net/netfilter/xt_hashlimit.c +25 -4
@@ -318,7 +318,10 @@ static void htable_destroy(struct xt_has parent = hashlimit_net->ipt_hashlimit; else parent = hashlimit_net->ip6t_hashlimit; -remove_proc_entry (hinfo->pde->name, parent); + +if (parent !=NULL ) +remove_proc_entry (hinfo->pde->name, parent); +htable_selective_cleanup (hinfo, select_all);vfree (hinfo); }
@@ -856,6 +859,27 @@ static int __net_init hashlimit_proc_net static void __net_exit hashlimit_proc_net_exit(struct net *net) { +struct xt_hashlimit_htable *hinfo; +struct hlist_node *pos; +struct proc_dir_entry *pde; +struct hashlimit_net *hashlimit_net =hashlimit_pernet (net); + +/* recent_net_exit() is called before recent_mt_destroy(). Make sure +* that the parent xt_recent proc entry is is empty before trying to +* remove it. +*/ +mutex_lock (&hashlimit_mutex); + pde = hashlimit_net->ipt_hashlimit; +if (pde ==NULL ) + pde = hashlimit_net->ip6t_hashlimit; + +hlist_for_each_entry (hinfo, pos, &hashlimit_net->htables, node) +remove_proc_entry (hinfo->pde->name, pde); + + hashlimit_net->ipt_hashlimit =NULL ; + hashlimit_net->ip6t_hashlimit =NULL ; +mutex_unlock (&hashlimit_mutex); +proc_net_remove (net,"ipt_hashlimit" );#if IS_ENABLED (CONFIG_IP6_NF_IPTABLES )proc_net_remove (net,"ip6t_hashlimit" );
@@ -872,9 +896,6 @@ static int __net_init hashlimit_net_init static void __net_exit hashlimit_net_exit(struct net *net) { -struct hashlimit_net *hashlimit_net =hashlimit_pernet (net); - -BUG_ON (!hlist_empty (&hashlimit_net->htables));hashlimit_proc_net_exit (net); }
Greg Kroah-Hartman
maintainerPATCH 82/89 netfilter: xt_hashlimit: fix race that results in duplicated entries
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
commit 09181842b000344b1205801df3aa5b726c03cc62 upstream.
Two packets may race to create the same entry in the hashtable, double check if this packet lost race. This double checking only happens in the path of the packet that creates the hashtable for first time.
Note that, with this patch, no packet drops occur if the race happens.
--- net/netfilter/xt_hashlimit.c | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-)
net/netfilter/xt_hashlimit.c +21 -4
@@ -157,11 +157,22 @@ dsthash_find(const struct xt_hashlimit_h/* allocate dsthash_ent, initialize dst, put in htable and lock it */ static struct dsthash_ent *dsthash_alloc_init (struct xt_hashlimit_htable *ht, -const struct dsthash_dst *dst) +const struct dsthash_dst *dst,bool *race) {struct dsthash_ent *ent;spin_lock (&ht->lock); + +/* Two or more packets may race to create the same entry in the +* hashtable, double check if this packet lost race. +*/ + ent =dsthash_find (ht, dst); +if (ent !=NULL ) { +spin_unlock (&ht->lock); + *race = true; +return ent; + } +/* initialize hash with random val at the time we allocate * the first hashtable entry */ if (unlikely (!ht->rnd_initialized)) {
@@ -588,6 +599,7 @@ hashlimit_mt(const struct sk_buff *skb,unsigned long now = jiffies;struct dsthash_ent *dh;struct dsthash_dst dst; +bool race = false;u32 cost;if (hashlimit_init_dst (hinfo, &dst, skb, par->thoff) <0 )
@@ -596,13 +608,18 @@ hashlimit_mt(const struct sk_buff *skb,rcu_read_lock_bh (); dh =dsthash_find (hinfo, &dst);if (dh ==NULL ) { - dh =dsthash_alloc_init (hinfo, &dst); + dh =dsthash_alloc_init (hinfo, &dst, &race);if (dh ==NULL ) {rcu_read_unlock_bh (); goto hotdrop; + }else if (race) { +/* Already got an entry, update expiration timeout */ + dh->expires = now +msecs_to_jiffies (hinfo->cfg.expire); +rateinfo_recalc (dh, now, hinfo->cfg.mode); + }else { + dh->expires = jiffies +msecs_to_jiffies (hinfo->cfg.expire); +rateinfo_init (dh, hinfo); } - dh->expires = jiffies +msecs_to_jiffies (hinfo->cfg.expire); -rateinfo_init (dh, hinfo); }else {/* update expiration timeout */ dh->expires = now +msecs_to_jiffies (hinfo->cfg.expire);
A message that is not in the archive (sent off-list or not yet received): CA+6hz4qjj3wGgo-m50=qRxAN+OGUXKfUfgRp7Pys7NixgwQ3vQ@mail.gmail.com
Greg Kroah-Hartman
maintainerRe: [ 82/89] netfilter: xt_hashlimit: fix race that results in duplicated entries
Quoted 30 lines · Feng Gao
Hi Greg,
I have a question.
There are two duplicated lines now.
dh->expires = now +msecs_to_jiffies(hinfo->cfg.expire);rateinfo_recalc(dh, now, hinfo->cfg.mode); 1# case: Thedsthash_findreturn a valid dh;
2# case: There is a race. The race is true.Why we could not adopt the method I sent before.
dh =
dsthash_find(hinfo, &dst);
if (dh == NULL) {
dh =dsthash_alloc_init(hinfo, &dst, &new_node); if (dh == NULL) {
rcu_read_unlock_bh();
goto hotdrop;
}
}if (
new_node) {
dh->expires= jiffies +msecs_to_jiffies(hinfo->cfg.expire);rateinfo_init(dh, hinfo);
} else {
/* update expiration timeout */
dh->expires= now +msecs_to_jiffies(hinfo->cfg.expire);rateinfo_recalc(dh, now, hinfo->cfg.mode);
}
Quoted 1 line
I think it could avoid the two duplicated lines.
But this patch the same as what is in Linus's tree, right? If not, please let me know. If it is the same, and you want to change it, it needs to be changed in Linus's tree first before I can do anything in the stable kernels.
thanks,
greg k-h
A message that is not in the archive (sent off-list or not yet received): CA+6hz4qjJpaH4HeoQ_NWT5ZX0+1PG-O87kxPK0rKEBG9go37DQ@mail.gmail.com
Greg Kroah-Hartman
maintainerRe: [ 82/89] netfilter: xt_hashlimit: fix race that results in duplicated entries
Quoted 8 lines · Feng Gao
Hi Greg,
Yes. It is same.
But I am sorry that I could not get you about "it needs to be changed in Linus's tree first before i can do anything in the stable kernels".Do you mean the patch need be commited to Linux tree firstly, then I commit the request again?
Yes, please read Documentation/stable_kernel_rules.txt for how it all works.
Quoted 4 lines
By the way, the attachment is the diff file which is similar with the one i sent before.
What's your opnion about it? It is not generated by git. If need, i will generate new one later.
I can't accept any patches for stable kernels that are not already in Linus's tree first, sorry.
thanks,
greg k-h
Pablo Neira Ayuso
maintainerRe: [ 82/89] netfilter: xt_hashlimit: fix race that results in duplicated entries
In reply to a message not in the archiveQuoted 18 lines · Feng Gao
Hi Greg,
I have a question.
There are two duplicated lines now.
dh->expires = now +
msecs_to_jiffies(hinfo->cfg.expire);
rateinfo_recalc(dh, now, hinfo->cfg.mode);
1# case: The dsthash_find return a valid dh;
2# case: There is a race. The race is true.
Why we could not adopt the method I sent before.
dh = dsthash_find(hinfo, &dst);
if (dh == NULL) {
dh = dsthash_alloc_init(hinfo, &dst, &new_node);
if (dh == NULL) {
rcu_read_unlock_bh();
goto hotdrop;
}
}
if (new_node) {Quoted 8 lines
dh->expires = jiffies + msecs_to_jiffies(hinfo->cfg.expire);
rateinfo_init(dh, hinfo);
} else {
/* update expiration timeout */
dh->expires = now + msecs_to_jiffies(hinfo->cfg.expire);
rateinfo_recalc(dh, now, hinfo->cfg.mode);
}
I think it could avoid the two duplicated lines.That's a cleanup, send me a follow up patch for that if you want.
Greg, please, don't back down this patch, it's fixing a real problem.
Gao is proposing some code refactoring to save line a couple of lines of code.
Re: [ 82/89] netfilter: xt_hashlimit: fix race that results in duplicated entries
Thanks Pablo.
I have a question about commiting the patch for kernel.
Because i am the reporter of this issue, and I sent the similar fix to netfilter maillist and the owner of the xt_hashlimit.c before. Now it is that Greg commits the patch for this issue, not me, although the fix is similar with that I sent before.
I am just a little disappointed, not explain.
Because I would be very prond of as the contributor who could commit patch to linux.
So I wonder How could I commit the patch to kernel directly or how to let owner could adopt my fix directly next time?
BTW, I still be prond as this issue reporter.
Best regards.
Feng Gao
Quoted 34 lines · Pablo Neira Ayuso
Quoted 18 lines · Feng Gao
Hi Greg, I have a question. There are two duplicated lines now. dh->expires = now + msecs_to_jiffies(hinfo->cfg.expire); rateinfo_recalc(dh, now, hinfo->cfg.mode); 1# case: The dsthash_find return a valid dh; 2# case: There is a race. The race is true. Why we could not adopt the method I sent before. dh = dsthash_find(hinfo, &dst); if (dh == NULL) { dh = dsthash_alloc_init(hinfo, &dst, &new_node); if (dh == NULL) { rcu_read_unlock_bh(); goto hotdrop; } } if (new_node) {Quoted 8 lines
dh->expires = jiffies + msecs_to_jiffies(hinfo->cfg.expire); rateinfo_init(dh, hinfo); } else { /* update expiration timeout */ dh->expires = now + msecs_to_jiffies(hinfo->cfg.expire); rateinfo_recalc(dh, now, hinfo->cfg.mode); } I think it could avoid the two duplicated lines.That's a cleanup, send me a follow up patch for that if you want.
Greg, please, don't back down this patch, it's fixing a real problem.
Gao is proposing some code refactoring to save line a couple of lines of code.
Pablo Neira Ayuso
maintainerRe: [ 82/89] netfilter: xt_hashlimit: fix race that results in duplicated entries
On Sat, Feb 02, 2013 at 12:56:17AM +0800, Feng Gao wrote:
[...]
Quoted 2 lines
So I wonder How could I commit the patch to kernel directly or how to let owner could adopt my fix directly next time?
There is no "file owners" in the Linux kernel, we have subsystem maintainers that take care of entire source code sub-trees.
You have to send your patches to the corresponding mailing list for that subsystem. In the specific case of Netfilter, you have to send your patches to the netfilter-devel mailing list. Make sure your patch comes with a description and a valid Signed-off-by. If the patch is not complete, you risk that it passes overlook since patchwork [1] does not register it.
If your patch is a fix, you can send it anytime. If it is an enhancement, you have to check if the merge window is open.
The maintainer will get back to you with some ACK/NACK feedback after some time, if you don't get any, you are free to retry. You can CC maintainers to attract their attention. You can check the MAINTAINERS under the linux tree to find the appropriate person.
Regards.
[1] http://patchwork.ozlabs.org/project/netfilter-devel/list/
Greg Kroah-Hartman
maintainerPATCH 83/89 netfilter: xt_recent: fix namespace destroy path
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Vitaly E. Lavrov" <[email protected]>
commit 665e205c16c1f902ac6763b8ce8a0a3a1dcefe59 upstream.
recent_net_exit() is called before recent_mt_destroy() in the destroy path of network namespaces. Make sure there are no entries in the parent proc entry xt_recent before removing it.
--- net/netfilter/xt_recent.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-)
net/netfilter/xt_recent.c +16 -4
@@ -431,7 +431,8 @@ static void recent_mt_destroy(const strulist_del (&t->list);spin_unlock_bh (&recent_lock);#ifdef CONFIG_PROC_FS -remove_proc_entry (t->name, recent_net->xt_recent); +if (recent_net->xt_recent !=NULL ) +remove_proc_entry (t->name, recent_net->xt_recent);#endif recent_table_flush (t);kfree (t);
@@ -615,6 +616,20 @@ static int __net_init recent_proc_net_in static void __net_exit recent_proc_net_exit(struct net *net) { +struct recent_net *recent_net =recent_pernet (net); +struct recent_table *t; + +/* recent_net_exit() is called before recent_mt_destroy(). Make sure +* that the parent xt_recent proc entry is is empty before trying to +* remove it. +*/ +spin_lock_bh (&recent_lock); +list_for_each_entry (t, &recent_net->tables, list) +remove_proc_entry (t->name, recent_net->xt_recent); + + recent_net->xt_recent =NULL ; +spin_unlock_bh (&recent_lock); +proc_net_remove (net,"xt_recent" ); }#else
@@ -638,9 +653,6 @@ static int __net_init recent_net_init(st static void __net_exit recent_net_exit(struct net *net) { -struct recent_net *recent_net =recent_pernet (net); - -BUG_ON (!list_empty (&recent_net->tables));recent_proc_net_exit (net); }
Greg Kroah-Hartman
maintainerPATCH 84/89 netfilter: xt_recent: avoid high order page allocations
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
commit 2727de76041b2064c0b74f00a2a89678fb3efafc upstream.
xt_recent can try high order page allocations and this can fail.
iptables: page allocation failure: order:9, mode:0xc0d0
It also wastes about half the allocated space because of kmalloc() power-of-two roundups and struct recent_table layout.
Use vmalloc() instead to save space and be less prone to allocation errors when memory is fragmented.
--- net/netfilter/xt_recent.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-)
net/netfilter/xt_recent.c +18 -5
@@ -29,6 +29,7 @@#include <linux/skbuff.h> #include <linux/inet.h> #include <linux/slab.h> +#include <linux/vmalloc.h> #include <net/net_namespace.h> #include <net/netns/generic.h>
@@ -310,6 +311,14 @@ out:return ret; } +static void recent_table_free (void *addr) +{ +if (is_vmalloc_addr (addr)) +vfree (addr); +else +kfree (addr); +} +static int recent_mt_check (const struct xt_mtchk_param *par,const struct xt_recent_mtinfo_v1 *info) {
@@ -322,6 +331,7 @@ static int recent_mt_check(const struct#endif unsigned int i;int ret = -EINVAL ; +size_t sz;if (unlikely (!hash_rnd_inited)) {get_random_bytes (&hash_rnd,sizeof (hash_rnd));
@@ -360,8 +370,11 @@ static int recent_mt_check(const struct goto out; } - t =kzalloc (sizeof (*t) +sizeof (t->iphash[0 ]) * ip_list_hash_size, -GFP_KERNEL ); + sz =sizeof (*t) +sizeof (t->iphash[0 ]) * ip_list_hash_size; +if (sz <=PAGE_SIZE ) + t =kzalloc (sz,GFP_KERNEL ); +else + t =vzalloc (sz);if (t ==NULL ) { ret = -ENOMEM ; goto out;
@@ -377,14 +390,14 @@ static int recent_mt_check(const struct uid =make_kuid (&init_user_ns, ip_list_uid); gid =make_kgid (&init_user_ns, ip_list_gid);if (!uid_valid (uid) || !gid_valid (gid)) { -kfree (t); +recent_table_free (t); ret = -EINVAL ; goto out; } pde =proc_create_data (t->name, ip_list_perms, recent_net->xt_recent, &recent_mt_fops, t);if (pde ==NULL ) { -kfree (t); +recent_table_free (t); ret = -ENOMEM ; goto out; }
@@ -435,7 +448,7 @@ static void recent_mt_destroy(const struremove_proc_entry (t->name, recent_net->xt_recent);#endif recent_table_flush (t); -kfree (t); +recent_table_free (t); }mutex_unlock (&recent_mutex); }
Greg Kroah-Hartman
maintainerPATCH 85/89 netfilter: nf_conntrack: fix BUG_ON while removing nf_conntrack with netns
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
commit 1e47ee8367babe6a5e8adf44a714c7086657b87e upstream.
canqun zhang reported that we're hitting BUG_ON in the nf_conntrack_destroy path when calling kfree_skb while rmmod'ing the nf_conntrack module.
Currently, the nf_ct_destroy hook is being set to NULL in the destroy path of conntrack.init_net. However, this is a problem since init_net may be destroyed before any other existing netns (we cannot assume any specific ordering while releasing existing netns according to what I read in recent emails).
Thanks to Gao feng for initial patch to address this issue.
--- include/net/netfilter/nf_conntrack_core.h | 2 ++ net/netfilter/nf_conntrack_core.c | 9 +++++---- net/netfilter/nf_conntrack_standalone.c | 1 + 3 files changed, 8 insertions(+), 4 deletions(-)
include/net/netfilter/nf_conntrack_core.h +2 -0
@@ -31,6 +31,8 @@ extern void nf_conntrack_cleanup(structextern int nf_conntrack_proto_init (struct net *net);extern void nf_conntrack_proto_fini (struct net *net); +extern void nf_conntrack_cleanup_end (void ); + extern bool nf_ct_get_tuple(const struct sk_buff *skb, unsigned int nhoff,
net/netfilter/nf_conntrack_core.c +5 -4
@@ -1383,11 +1383,12 @@ void nf_conntrack_cleanup(struct net *nesynchronize_net ();nf_conntrack_proto_fini (net);nf_conntrack_cleanup_net (net); +} -if (net_eq (net, &init_net)) { -RCU_INIT_POINTER (nf_ct_destroy,NULL ); -nf_conntrack_cleanup_init_net (); - } +void nf_conntrack_cleanup_end (void ) +{ +RCU_INIT_POINTER (nf_ct_destroy,NULL ); +nf_conntrack_cleanup_init_net (); }void *nf_ct_alloc_hashtable (unsigned int *sizep,int nulls)
net/netfilter/nf_conntrack_standalone.c +1 -0
@@ -571,6 +571,7 @@ static int __init nf_conntrack_standalon static void __exit nf_conntrack_standalone_fini(void) {unregister_pernet_subsys (&nf_conntrack_net_ops); +nf_conntrack_cleanup_end (); }module_init (nf_conntrack_standalone_init);
Greg Kroah-Hartman
maintainerPATCH 86/89 netfilter: x_tables: print correct hook names for ARP
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Engelhardt <[email protected]>
commit 5b76c4948fe6977bead2359c2054f3e6a2dcf3d0 upstream.
arptables 0.0.4 (released on 10th Jan 2013) supports calling the CLASSIFY target, but on adding a rule to the wrong chain, the diagnostic is as follows:
# arptables -A INPUT -j CLASSIFY --set-class 0:0 arptables: Invalid argument # dmesg | tail -n1 x_tables: arp_tables: CLASSIFY target: used from hooks PREROUTING, but only usable from INPUT/FORWARD
This is incorrect, since xt_CLASSIFY.c does specify (1 << NF_ARP_OUT) | (1 << NF_ARP_FORWARD).
This patch corrects the x_tables diagnostic message to print the proper hook names for the NFPROTO_ARP case.
Affects all kernels down to and including v2.6.31.
--- net/netfilter/x_tables.c | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-)
net/netfilter/x_tables.c +20 -8
@@ -345,19 +345,27 @@ int xt_find_revision(u8 af, const char * }EXPORT_SYMBOL_GPL (xt_find_revision); -static char *textify_hooks (char *buf,size_t size,unsigned int mask) +static char * +textify_hooks (char *buf,size_t size,unsigned int mask,uint8_t nfproto) { -static const char *const names[] = { +static const char *const inetbr_names[] = {"PREROUTING" ,"INPUT" ,"FORWARD" ,"OUTPUT" ,"POSTROUTING" ,"BROUTING" , }; -unsigned int i; +static const char *const arp_names[] = { +"INPUT" ,"FORWARD" ,"OUTPUT" , + }; +const char *const *names; +unsigned int i, max;char *p = buf;bool np = false;int res; + names = (nfproto ==NFPROTO_ARP ) ? arp_names : inetbr_names; + max = (nfproto ==NFPROTO_ARP ) ?ARRAY_SIZE (arp_names) : +ARRAY_SIZE (inetbr_names); *p ='\0' ; -for (i =0 ; i <ARRAY_SIZE (names); ++i) { +for (i =0 ; i < max; ++i) {if (!(mask & (1 << i)))continue ; res =snprintf (p, size,"%s%s" , np ?"/" :"" , names[i]);
@@ -402,8 +410,10 @@ int xt_check_match(struct xt_mtchk_parampr_err ("%s_tables: %s match: used from hooks %s, but only " "valid from %s\n" , xt_prefix[par->family], par->match->name, -textify_hooks (used,sizeof (used), par->hook_mask), -textify_hooks (allow,sizeof (allow), par->match->hooks)); +textify_hooks (used,sizeof (used), par->hook_mask, + par->family), +textify_hooks (allow,sizeof (allow), par->match->hooks, + par->family));return -EINVAL ; }if (par->match->proto && (par->match->proto != proto || inv_proto)) {
@@ -575,8 +585,10 @@ int xt_check_target(struct xt_tgchk_parapr_err ("%s_tables: %s target: used from hooks %s, but only " "usable from %s\n" , xt_prefix[par->family], par->target->name, -textify_hooks (used,sizeof (used), par->hook_mask), -textify_hooks (allow,sizeof (allow), par->target->hooks)); +textify_hooks (used,sizeof (used), par->hook_mask, + par->family), +textify_hooks (allow,sizeof (allow), par->target->hooks, + par->family));return -EINVAL ; }if (par->target->proto && (par->target->proto != proto || inv_proto)) {
Greg Kroah-Hartman
maintainerPATCH 87/89 netfilter: ctnetlink: fix leak in error path of ctnetlink_create_expect
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jesper Juhl <[email protected]>
commit 1310b955c804975651dca6c674ebfd1cb2b4c7ff upstream.
This patch fixes a leak in one of the error paths of ctnetlink_create_expect if no helper and no timeout is specified.
--- net/netfilter/nf_conntrack_netlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/netfilter/nf_conntrack_netlink.c +1 -1
@@ -2514,7 +2514,7 @@ ctnetlink_create_expect(struct net *net,if (!help) {if (!cda[CTA_EXPECT_TIMEOUT ]) { err = -EINVAL ; - goto out; + goto err_out; } exp->timeout.expires = jiffies +ntohl (nla_get_be32 (cda[CTA_EXPECT_TIMEOUT ])) *HZ ;
Greg Kroah-Hartman
maintainerPATCH 88/89 drm/i915: fix FORCEWAKE posting reads
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jani Nikula <[email protected]>
commit b514407547890686572606c9dfa4b7f832db9958 upstream.
We stopped reading FORCEWAKE for posting reads in
commit 8dee3eea3ccd3b6c00a8d3a08dd715d6adf737dd
Author: Ben Widawsky <[email protected]> Date: Sat Sep 1 22:59:50 2012 -0700
drm/i915: Never read FORCEWAKE
and started using something from the same cacheline instead. On the bug reporter's machine this broke entering rc6 states after a suspend/resume cycle. It turns out reading ECOBUS as posting read worked fine, while GTFIFODBG did not, preventing RC6 states after suspend/resume per the bug report referenced below. It's not entirely clear why, but clearly GTFIFODBG was nowhere near the same cacheline or address range as FORCEWAKE.
Trying out various registers for posting reads showed that all tested registers for which NEEDS_FORCE_WAKE() (in i915_drv.c) returns true work. Conversely, most (but not quite all) registers for which NEEDS_FORCE_WAKE() returns false do not work. Details in the referenced bug.
Based on the above, add posting reads on ECOBUS where GTFIFODBG was previously relied on.
In true cargo cult spirit, add posting reads for FORCEWAKE_VLV writes as well, but instead of ECOBUS, use FORCEWAKE_ACK_VLV which is in the same address range as FORCEWAKE_VLV.
v2: Add more details to the commit message. No functional changes.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52411
[danvet: add cc: stable and make the commit message a bit clearer that this is a regression fix and what exactly broke.]
--- drivers/gpu/drm/i915/intel_pm.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-)
drivers/gpu/drm/i915/intel_pm.c +10 -5
@@ -4018,7 +4018,8 @@ static void __gen6_gt_force_wake_get(strDRM_ERROR ("Timed out waiting for forcewake old ack to clear.\n" );I915_WRITE_NOTRACE (FORCEWAKE ,1 ); -POSTING_READ (ECOBUS );/* something from same cacheline, but !FORCEWAKE */ +/* something from same cacheline, but !FORCEWAKE */ +POSTING_READ (ECOBUS );if (wait_for_atomic ((I915_READ_NOTRACE (forcewake_ack) &1 ),FORCEWAKE_ACK_TIMEOUT_MS ))
@@ -4041,7 +4042,8 @@ static void __gen6_gt_force_wake_mt_get(DRM_ERROR ("Timed out waiting for forcewake old ack to clear.\n" );I915_WRITE_NOTRACE (FORCEWAKE_MT ,_MASKED_BIT_ENABLE (1 )); -POSTING_READ (ECOBUS );/* something from same cacheline, but !FORCEWAKE */ +/* something from same cacheline, but !FORCEWAKE */ +POSTING_READ (ECOBUS );if (wait_for_atomic ((I915_READ_NOTRACE (forcewake_ack) &1 ),FORCEWAKE_ACK_TIMEOUT_MS ))
@@ -4078,14 +4080,16 @@ void gen6_gt_check_fifodbg(struct drm_i9static void __gen6_gt_force_wake_put (struct drm_i915_private *dev_priv) {I915_WRITE_NOTRACE (FORCEWAKE ,0 ); -/* gen6_gt_check_fifodbg doubles as the POSTING_READ */ +/* something from same cacheline, but !FORCEWAKE */ +POSTING_READ (ECOBUS );gen6_gt_check_fifodbg (dev_priv); }static void __gen6_gt_force_wake_mt_put (struct drm_i915_private *dev_priv) {I915_WRITE_NOTRACE (FORCEWAKE_MT ,_MASKED_BIT_DISABLE (1 )); -/* gen6_gt_check_fifodbg doubles as the POSTING_READ */ +/* something from same cacheline, but !FORCEWAKE_MT */ +POSTING_READ (ECOBUS );gen6_gt_check_fifodbg (dev_priv); }
@@ -4140,7 +4144,8 @@ static void vlv_force_wake_get(struct drstatic void vlv_force_wake_put (struct drm_i915_private *dev_priv) {I915_WRITE_NOTRACE (FORCEWAKE_VLV ,_MASKED_BIT_DISABLE (1 )); -/* The below doubles as a POSTING_READ */ +/* something from same cacheline, but !FORCEWAKE_VLV */ +POSTING_READ (FORCEWAKE_ACK_VLV );gen6_gt_check_fifodbg (dev_priv); }
Greg Kroah-Hartman
maintainerPATCH 89/89 slub: assign refcount for kmalloc_caches
In reply to Greg Kroah-Hartman3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: CAI Qian <[email protected]>
This is for stable-3.7.y only and this problem has already been solved in mainline through some slab/slub re-work which isn't suitable to backport here. See create_kmalloc_cache() in mm/slab_common.c there.
commit cce89f4f6911286500cf7be0363f46c9b0a12ce0('Move kmem_cache refcounting to common code') moves some refcount manipulation code to common code. Unfortunately, it also removed refcount assignment for kmalloc_caches. So, kmalloc_caches's refcount is initially 0. This makes erroneous situation.
Paul Hargrove report that when he create a 8-byte kmem_cache and destory it, he encounter below message.
'Objects remaining in kmalloc-8 on kmem_cache_close()'
8-byte kmem_cache merge with 8-byte kmalloc cache and refcount is increased by one. So, resulting refcount is 1. When destroy it, it hit refcount = 0, then kmem_cache_close() is executed and error message is printed.
This patch assign initial refcount 1 to kmalloc_caches, so fix this erroneous situation.
--- mm/slub.c | 1 + 1 file changed, 1 insertion(+)
mm/slub.c +1 -0
@@ -3279,6 +3279,7 @@ static struct kmem_cache *__init create_if (kmem_cache_open (s, flags)) goto panic; + s->refcount =1 ;list_add (&s->list, &slab_caches);return s;
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.7.6 release. There are 89 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 Feb 3 13:01:49 UTC 2013. Anything received after that time might be too late.
Quoted 7 lines
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.7.6-rc1.gzand the diffstat can be found below.
thanks,
greg k-h
Patches applied cleanly to 3.0.61, 3.4.28, and 3.7.5. Compiled and booted on the following systems:
HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics
Cross-compile tests:
alpha: defconfig passed on all
arm: defconfig passed on all
arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.7.y
c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.7.y.
mips: defconfig passed on all
mipsel: defconfig passed on all
powerpc: wii_defconfig passed on all
sh: defconfig passed on all
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all
-- Shuah
At Fri, 1 Feb 2013 14:07:15 +0100,
Quoted 6 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.7.6 release. There are 89 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.
Quoted 6 lines
Responses should be made by Sun Feb 3 13:01:49 UTC 2013. 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/v3.0/stable-review/patch-3.7.6-rc1.gzand the diffstat can be found below.
This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine.
- Build Machine: debian wheezy x86_64
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
memory: 8GB
- Test machine: debian wheezy x86_64(KVM guest on the Build Machine)
vCPU: x2
memory: 2GB
I reviewed the following patches and it looks good to me.
Quoted 11 lines
-------------
Pseudo-Shortlog of commits:Greg Kroah-Hartman <[email protected]>
Linux 3.7.6-rc1CAI Qian <[email protected]>
slub: assign refcount forkmalloc_cachesJani Nikula <[email protected]>
drm/i915: fix FORCEWAKE posting reads
...
Quoted 5 lines
Dave Chinner <[email protected]>
xfs: fix periodic log flushingH. Peter Anvin <[email protected]>
x86/Sandy Bridge: Sandy Bridge workaround depends onCONFIG_PCI
...
Quoted 2 lines
Alex Williamson <[email protected]>
kvm: Fix irqfd resampler list walk
...
Quoted 5 lines
Dave Chinner <[email protected]>
xfs: fix_xfs_buf_findoops on blocks beyond the filesystem endMatt Fleming <[email protected]>
x86, efi: Setruntime_versionto the EFI spec revision
...
Quoted 2 lines
David Woodhouse <[email protected]>
x86, efi: Fix 32-bit EFI handover protocol entry point
...
Quoted 5 lines
Alan Cox <[email protected]>
x86/msr: Add capabilities checkWang YanQing <[email protected]>
smp: Fix SMP function call empty cpu mask race
...
Quoted 2 lines
Jan Kara <[email protected]>
xfs: Fix possible use-after-free with AIO
...
Quoted 2 lines
Cong Ding <[email protected]>
fs/cifs/cifs_dfs_ref.c: fix potential memory leakage
Thanks,
Satoru