Cm 11.0 #18
Open
Cm 11.0 #18
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
msm: cpufreq: Add msm_cpufreq debugfs file to show CPU -> L2/BW mapping
Example output:
cat /sys/kernel/debug/clk/msm_cpufreq
CPU (KHz) L2 (KHz) Mem (MBps)
300000 300000 600
422400 422400 1200
652800 499200 1600
729600 576000 2456
883200 576000 2456
960000 960000 3680
1036800 1036800 3680
1190400 1036800 3680
1267200 1267200 6400
1497600 1497600 6400
1574400 1574400 6400
1728000 1651200 6400
1958400 1728000 7448
2265600 1728000 7448
Change-Id: I20df8c3778c0fcd0ef1f369acb1cb72cf5334812
Signed-off-by: Xiaogang Cui <[email protected]>
msm: cpufreq: Remove unused msm_cpufreq_set_freq_limits() API
The msm_cpufreq_set_freq_limits() is a mach specific way to set CPU freq
limits. The thermal code no longer uses this API and instead uses the
standard INCOMPATIBLE notifiers provided by the common CPUfreq framework.
Since this API is no longer needed, delete it.
Change-Id: I5c07b17195d4e4b75cdd4d82f8e7cb6cb6f3e199
Signed-off-by: Saravana Kannan <[email protected]>
Conflicts:
drivers/thermal/msm_thermal.c
msm: cpufreq: Avoid NULL clock pointer references
The MSM CPUfreq driver defines a mapping from cpu number to clock
pointer. On SOCs with synchronous cpus, only the mapping for cpu#0
is defined, even though there may be more than 1 cpu. Handle this
case by skipping certain unnecessary initialization steps for SOCs
with synchronous cpus.
Conflicts:
arch/arm/mach-msm/cpufreq.c
Change-Id: Iaeba7a8615e3cb7da2c725250db92595450bfa46
Signed-off-by: Patrick Daly <[email protected]>
msm: cpufreq: Correct synchronous cpu logic
Fix an incorrect patch conflict resolution which results in failing to
initialize the cpufreq policy correctly when using an old acpuclock driver
version.
Change-Id: If8743a2608e720258ebc710718c3041144c00f10
CRs-fixed: 612226
Signed-off-by: Patrick Daly <[email protected]>
msm: cpufreq: Fix msm_cpufreq_get_freq() for sync CPUs
When CPUs are in sync, only CPU0 has a non-NULL cpu_clk. clk_get_rate()
on other cpu_clk will return 0. msm_cpufreq_get_freq() is used in multiple
places in cpufreq framework to determine current hardware frequency.
Fix msm_cpufreq_get_freq() to return the right hardware frequency for
systems with synchronous CPUs.
Change-Id: I6a880764ad51fa9a257a328798b38d574750686a
Signed-off-by: Junjie Wu <[email protected]>
msm: cpufreq: Move the enabling of the CPU/L2 clocks to CPU_STARTING
It is a requirement of PLLs in MSM SoCs that the PLL power
supplies be enabled while the PLL is running. If the PLL is
locked and outputs enabled, turning off the regulator(s)
supplying the PLL will cause the PLL to enter an unpredictable
state.
Now in the CPU_UP_PREPARE notifier, the CPU clocks are prepared
and enabled, causing the source HFPLLs to also turn on. Note
that the CPU isn't clocked yet. It is possible that execution is
pre-empted and the CPU running the notifier enters power
collapse. If all other CPUs also enter power collapse, then it
is possible for an RPM notification to go out, allowing the RPM
to transition the Apps processor to its sleep set. This can
result in the HFPLL supplies being turned off while the HFPLL is
running, violating the requirement mentioned above. Once the CPU
is unclamped, the CPU is effectively unclocked, due to the HFPLL
being in an unknown state.
There is a check that is enabled in the PM code's CPU_UP_PREPARE
notifier callback. This check ensures that the problematic RPM
notification cannot occur until the core that is being brought
online also enters power collapse. However, there is no ordering
guarantee between that PM's hotplug notifier callback's execution
and the cpufreq hotplug notifier callback's execution. This
ordering depends on program link order, which is unreliable.
It is necessary to ensure that once the HFPLL is enabled, the
RPM cannot transition apps to its sleep set. Move the enabling
of the CPU clocks to the CPU_STARTING notifier, which runs on
the CPU bring brought online. The CPU_STARTING notifier is
guaranteed to run after the CPU_UP_PREPARE notifier, which
implies that the aforementioned do-not-notify-rpm check is
executed *before* the HFPLL is enabled. Therefore even if all
cores enter power collapse after the HFPLL is enabled, the
HFPLL supplies are guaranteed to stay on, or the CPU clock
is switched to the safe source and the HFPLL is turned off.
CRs-Fixed: 622738
Change-Id: I136841405806c07e755919859e649ded0c719abb
Signed-off-by: Vikram Mulukutla <[email protected]>
Conflicts:
arch/arm/mach-msm/cpufreq.c
msm: acpuclock: Add a null check for acpuclk_data
If acpuclock fails to probe before a client calls acpuclk_get_rate,
a null dereference will occur. Fix this by adding the appropriate
checks.
Change-Id: If873a64711e9cc807b1734996f7c9358bb08161a
Signed-off-by: Vikram Mulukutla <[email protected]>
msm: acpuclock: Fix acpuclk_data null pointer dereference
If acpuclk_data is null, dereferencing it in acpuclk_get_switch_time
causes a kernel panic. Add pointer check to fix that.
Change-Id: I69b92671c8cf26cb45ec8f1193c147be2ebe4c16
Signed-off-by: Junjie Wu <[email protected]>
devfreq: Add MSM CPUfreq governor
The MSM CPUfreq devfreq governor determines the CPU to DDR bandwidth vote
based on the current CPU frequency of all the active CPUs.
This functionality used to be a part of the MSM CPUfreq driver that
directly voted for the CPU to DDR bandwidth using MSM bus scaling APIs.
This refactor decouples CPU to DDR BW scaling from CPU frequency and allows
switch between various CPU BW governors.
The bandwidth values in the msm-cpufreq table have to be updated since the
new CPU BW driver does the MBps to Bps conversion correctly. The MSM
CPUfreq driver used to do * 1000 * 1000 to convert from MBps to Bps instead
of doing * 1024 * 1024.
Change-Id: I184f09d628a1b27d52506d2f760d65831f1a1110
Signed-off-by: Saravana Kannan <[email protected]>
Conflicts:
arch/arm/boot/dts/msm8226.dtsi
arch/arm/boot/dts/msm8974.dtsi
arch/arm/boot/dts/msm8974pro.dtsi
arch/arm/mach-msm/Kconfig
arch/arm/mach-msm/devfreq_cpubw.c
drivers/devfreq/Kconfig
drivers/devfreq/Makefile
Bluetooth power driver for providing power to Bluetooth AR3002 SOC Change-Id: I3f4b23d59ce860393a7a481d7ac6d298bc89925e Signed-off-by: Pradeep Panigrahi <[email protected]>
Update bluetooth power driver to support both device tree and board specific platform data to power on bluetooth chipset. Current driver supports only gpio data from the device node. Now the driver first checks for device tree node and if it does not exist then checks for the platform data from the board file. Updated the platform data for the driver to provide all the required vregs and gpio data to power on the bluetooth chipset. Change-Id: Ie71115ad7173fc527e46b334a8b548762b40aa46 Signed-off-by: Ram Mohan Korukonda <[email protected]>
Add change in bluetooth power module to specify load current requirement for regulator vdd la during Bluetooth turn on. Change-Id: Iddd602b2ea45be62cb3786cc482e3ce12ae6302b Signed-off-by: Pradeep Panigrahi <[email protected]>
When there is no communication between the BTHOST and BTSOC, UART clock should be vote off, otherwise Uart module will not unlock wake lock which doesn't allow system to go sleep. CRs-fixed: 413053 Change-Id: I8067132d5c376551bf104e69ac916addbbda3d1d Signed-off-by: Ram Mohan Korukonda <[email protected]>
HCI Atheros driver first checks for device tree node and if it does not exists then checks for the platform data from the board file. Change-Id: I92e1cfce0d0bf074eb3baab921674e291bb462e6 Signed-off-by: Ram Mohan Korukonda <[email protected]>
Added module params to allow userspace to control the sleep mechanism of atheros chipset. Change-Id: I1cf563d54fa56159d227380ada784cca0c93ed23 Signed-off-by: Ram Mohan Korukonda <[email protected]>
Added module params to allow userspace to control the sleep mechanism of atheros chipset. Change-Id: Ie7a9a6c0d73d8df694c805f59a22ad9c52ea8c87 Signed-off-by: Pradeep Panigrahi <[email protected]>
Deadlock is observed while performing bluetooth stress and stability tests. Since same lock is getting acquired from both irq and non-irq context, irqs should be disable while acquiring the spinlock always. Otherwise there is chance of deadlock observing while performing stability tests. CRs-fixed: 406705 Change-Id: I4c79e3f7edb5312d02e6819fb62384f58c2e1d32 Signed-off-by: Ram Mohan Korukonda <[email protected]>
Incase of SSR scenarios there is chance that user may request for power_on/off while the ssr is going on, this need to be avoided if the initial set up is not complete. Change-Id: I2568a32e0ff18dba9faafe3d153852339b63841a CRs-fixed: 432178 Signed-off-by: Bhasker Neti <[email protected]>
Check if the HCI device handle is available prior to updating the scan state. Change-Id: Ifc278afecbcf2bc7a95bb6595028dd890a8b60f5 CRs-Fixed: 436733 Signed-off-by: Anantha Krishnan <[email protected]>
Wakelocks were used to address the issue related to timer which was not triggered when device was put into suspend mode.This does not impact the usecases as the link would be put into sniff mode immediately after the device comes out of suspend mode. Change-Id: I648acf32c6ce9bd0d3415ac0e9dcd2250d3fb68d Signed-off-by: Sumit Bajpai <[email protected]>
If Hardware Error event is received from the SOC, then BT SOC is in bad state. As per spec, Hardware Error event is handled in HCI. Upper layer gets informed by HCI to reset everything. & recover BT state machine & BT SOC. Change-Id: Iefdf8511ad51f88ff8a24ab9e075eb8dbc0a0a67 Signed-off-by: Nitin Shivpure <[email protected]>
xhci: correct burst count field for isoc transfers on 1.0 xhci hosts commit 3213b15 upstream. The transfer burst count (TBC) field in xhci 1.0 hosts should be set to the number of bursts needed to transfer all packets in a isoc TD. Supported values are 0-2 (1 to 3 bursts per service interval). Formula for TBC calculation is given in xhci spec section 4.11.2.3: TBC = roundup( Transfer Descriptor Packet Count / Max Burst Size +1 ) - 1 This patch should be applied to stable kernels since 3.0 that contain the commit 5cd43e3 "xhci 1.0: Set transfer burst count field." Suggested-by: ShiChun Ma <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> xhci: Fix runtime suspended xhci from blocking system suspend. commit d6236f6 upstream. The system suspend flow as following: 1, Freeze all user processes and kenrel threads. 2, Try to suspend all devices. 2.1, If pci device is in RPM suspended state, then pci driver will try to resume it to RPM active state in the prepare stage. 2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two workqueue items to resume usb2&usb3 roothub devices. 2.3, Call suspend callbacks of devices. 2.3.1, All suspend callbacks of all hcd's children, including roothub devices are called. 2.3.2, Finally, hcd_pci_suspend callback is called. Due to workqueue threads were already frozen in step 1, the workqueue items can't be scheduled, and the roothub devices can't be resumed in this flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in usb_hcd_resume_root_hub won't be cleared. Finally, hcd_pci_suspend will return -EBUSY, and system suspend fails. The reason why this issue doesn't show up very often is due to that choose_wakeup will be called in step 2.3.1. In step 2.3.1, if udev->do_remote_wakeup is not equal to device_may_wakeup(&udev->dev), then udev will resume to RPM active for changing the wakeup settings. This has been a lucky hit which hides this issue. For some special xHCI controllers which have no USB2 port, then roothub will not match hub driver due to probe failed. Then its do_remote_wakeup will be set to zero, and we won't be as lucky. xhci driver doesn't need to resume roothub devices everytime like in the above case. It's only needed when there are pending event TRBs. This patch should be back-ported to kernels as old as 3.2, that contains the commit f69e312 "USB: XHCI: resume root hubs when the controller resumes" Signed-off-by: Wang, Yu <[email protected]> Acked-by: Alan Stern <[email protected]> [use readl() instead of removed xhci_readl(), reword commit message -Mathias] Signed-off-by: Mathias Nyman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> USB: add USB_DEVICE_INTERFACE_CLASS macro commit 17b72fe upstream. Matching on device and interface class with with unspecified subclass and protocol is sometimes useful. This is slightly different from USB_DEVICE_AND_INTERFACE_INFO which requires the full interface class/subclass/protocol triplet. Signed-off-by: Bjørn Mork <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> USB: option: add device ID for SpeedUp SU9800 usb 3g modem commit 1cab4c6 upstream. Reported by Alif Mubarak Ahmad: This device vendor and product id is 1c9e:9800 It is working as serial interface with generic usbserial driver. I thought it is more suitable to use usbserial option driver, which has better capability distinguishing between modem serial interface and micro sd storage interface. [ johan: style changes ] Signed-off-by: Oliver Neukum <[email protected]> Tested-by: Alif Mubarak Ahmad <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> usb: option: add/modify Olivetti Olicard modems commit b0ebef3 upstream. Adding a couple of Olivetti modems and blacklisting the net function on a couple which are already supported. Reported-by: Lars Melin <[email protected]> Signed-off-by: Bjørn Mork <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> USB: ftdi_sio: fix null deref at port probe commit aea1ae8 upstream. Fix NULL-pointer dereference when probing an interface with no endpoints. These devices have two bulk endpoints per interface, but this avoids crashing the kernel if a user forces a non-FTDI device to be probed. Note that the iterator variable was made unsigned in order to avoid a maybe-uninitialized compiler warning for ep_desc after the loop. Fixes: 895f28b ("USB: ftdi_sio: fix hi-speed device packet size calculation") Reported-by: Mike Remski <[email protected]> Tested-by: Mike Remski <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> usb: gadget: f_fs: fix NULL pointer dereference when there are no strings commit f0688c8 upstream. If the descriptors do not need any strings and user space sends empty set of strings, the ffs->stringtabs field remains NULL. Thus *ffs->stringtabs in functionfs_bind leads to a NULL pointer dereferenece. The bug was introduced by commit [fd7c9a0: “use usb_string_ids_n()”]. While at it, remove double initialisation of lang local variable in that function. ffs->strings_count does not need to be checked in any way since in the above scenario it will remain zero and usb_string_ids_n() is a no-operation when colled with 0 argument. Signed-off-by: Michal Nazarewicz <[email protected]> Signed-off-by: Felipe Balbi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> rt2x00: disable TKIP on USB commit 8edcb0b upstream. On USB we can not get atomically TKIP key. We have to disable support for TKIP acceleration on USB hardware to avoid bug as showed bellow. [ 860.827243] BUG: scheduling while atomic: hostapd/3397/0x00000002 <snip> [ 860.827280] Call Trace: [ 860.827282] [<ffffffff81682ea6>] dump_stack+0x4d/0x66 [ 860.827284] [<ffffffff8167eb9b>] __schedule_bug+0x47/0x55 [ 860.827285] [<ffffffff81685bb3>] __schedule+0x733/0x7b0 [ 860.827287] [<ffffffff81685c59>] schedule+0x29/0x70 [ 860.827289] [<ffffffff81684f8a>] schedule_timeout+0x15a/0x2b0 [ 860.827291] [<ffffffff8105ac50>] ? ftrace_raw_event_tick_stop+0xc0/0xc0 [ 860.827294] [<ffffffff810c13c2>] ? __module_text_address+0x12/0x70 [ 860.827296] [<ffffffff81686823>] wait_for_completion_timeout+0xb3/0x140 [ 860.827298] [<ffffffff81080fc0>] ? wake_up_state+0x20/0x20 [ 860.827301] [<ffffffff814d5b3d>] usb_start_wait_urb+0x7d/0x150 [ 860.827303] [<ffffffff814d5cd5>] usb_control_msg+0xc5/0x110 [ 860.827305] [<ffffffffa02fb0c6>] rt2x00usb_vendor_request+0xc6/0x160 [rt2x00usb] [ 860.827307] [<ffffffffa02fb215>] rt2x00usb_vendor_req_buff_lock+0x75/0x150 [rt2x00usb] [ 860.827309] [<ffffffffa02fb393>] rt2x00usb_vendor_request_buff+0xa3/0xe0 [rt2x00usb] [ 860.827311] [<ffffffffa023d1a3>] rt2x00usb_register_multiread+0x33/0x40 [rt2800usb] [ 860.827314] [<ffffffffa05805f9>] rt2800_get_tkip_seq+0x39/0x50 [rt2800lib] [ 860.827321] [<ffffffffa0480f88>] ieee80211_get_key+0x218/0x2a0 [mac80211] [ 860.827322] [<ffffffff815cc68c>] ? __nlmsg_put+0x6c/0x80 [ 860.827329] [<ffffffffa051b02e>] nl80211_get_key+0x22e/0x360 [cfg80211] Reported-and-tested-by: Peter Wu <[email protected]> Reported-and-tested-by: Pontus Fuchs <[email protected]> Signed-off-by: Stanislaw Gruszka <[email protected]> Signed-off-by: John W. Linville <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> rt2x00: fix rfkill regression on rt2500pci commit 616a839 upstream. As reported by Niels, starting rfkill polling during device probe (commit e2bc7c5, generally sane change) broke rfkill on rt2500pci device. I considered that bug as some initalization issue, which should be fixed on rt2500pci specific code. But after several attempts (see bug report for details) we fail to find working solution. Hence I decided to revert to old behaviour on rt2500pci to fix regression. Additionally patch also unregister rfkill on device remove instead of ifconfig down, what was another issue introduced by bad commit. Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=73821 Fixes: e2bc7c5 ("rt2x00: Fix rfkill_polling register function.") Bisected-by: Niels <[email protected]> Reported-and-tested-by: Niels <[email protected]> Signed-off-by: Stanislaw Gruszka <[email protected]> Signed-off-by: John W. Linville <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> mtd: pxa3xx_nand: make the driver work on big-endian systems commit b7e4606 upstream. The pxa3xx_nand driver currently uses __raw_writel() and __raw_readl() to access I/O registers. However, those functions do not do any endianness swapping, which means that they won't work when the CPU runs in big-endian but the I/O registers are little endian, which is the common situation for ARM systems running big endian. Since __raw_writel() and __raw_readl() do not include any memory barriers and the pxa3xx_nand driver can only be compiled for ARM platforms, the closest I/o accessors functions that do endianess swapping are writel_relaxed() and readl_relaxed(). This patch has been verified to work on Armada XP GP: without the patch, the NAND is not detected when the kernel runs big endian while it is properly detected when the kernel runs little endian. With the patch applied, the NAND is properly detected in both situations (little and big endian). Signed-off-by: Thomas Petazzoni <[email protected]> Signed-off-by: Brian Norris <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> drm/radeon: only apply hdmi bpc pll flags when encoder mode is hdmi commit 7d5ab30 upstream. May fix display issues with non-HDMI displays. Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> drm/radeon: fix typo in radeon_connector_is_dp12_capable() commit af5d365 upstream. We were checking the ext clock rather than the display clock. Noticed by ArtForz on IRC. Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> drm/radeon/atom: fix dithering on certain panels commit 6425283 upstream. We need to specify the encoder mode as LVDS for eDP when using the Crtc_Source atom table in order to properly set up the FMT hardware. bug: https://bugs.freedesktop.org/show_bug.cgi?id=73911 Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> drm/vmwgfx: Fix incorrect write to read-only register v2: commit 4e57808 upstream. Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register: SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to SVGA_REG_PITCHLOCK. This patch is Cc'd stable because of the unknown effects writing to this register might have, particularly on older device versions. v2: Updated log message. Cc: Christopher Friedt <[email protected]> Tested-by: Christopher Friedt <[email protected]> Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Jakob Bornecrantz <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Bluetooth: Remove unused hci_le_ltk_reply() commit e10b996 upstream. In this API, we were using sizeof operator for an array given as function argument, which is invalid. However this API is not used anywhere. Signed-off-by: Syam Sidhardhan <[email protected]> Signed-off-by: Gustavo Padovan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> mac80211: don't check netdev state for debugfs read/write commit 923eaf3 upstream. Doing so will lead to an oops for a p2p-dev interface, since it has no netdev. Signed-off-by: Arik Nemtsov <[email protected]> Signed-off-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> ARM: OMAP2+: Fix parser-bug in platform muxing code commit c021f24 upstream. Fix a parser-bug in the omap2 muxing code where muxtable-entries will be wrongly selected if the requested muxname is a *prefix* of their m0-entry and they have a matching mN-entry. Fix by additionally checking that the length of the m0_entry is equal. For example muxing of "dss_data2.dss_data2" on omap32xx will fail because the prefix "dss_data2" will match the mux-entries "dss_data2" as well as "dss_data20", with the suffix "dss_data2" matching m0 (for dss_data2) and m4 (for dss_data20). Thus both are recognized as signal path candidates: Relevant muxentries from mux34xx.c: _OMAP3_MUXENTRY(DSS_DATA20, 90, "dss_data20", NULL, "mcspi3_somi", "dss_data2", "gpio_90", NULL, NULL, "safe_mode"), _OMAP3_MUXENTRY(DSS_DATA2, 72, "dss_data2", NULL, NULL, NULL, "gpio_72", NULL, NULL, "safe_mode"), This will result in a failure to mux the pin at all: _omap_mux_get_by_name: Multiple signal paths (2) for dss_data2.dss_data2 Patch should apply to linus' latest master down to rather old linux-2.6 trees. Signed-off-by: David R. Piegdon <[email protected]> Cc: [email protected] [[email protected]: updated description to include full description] Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> b43: fix frequency reported on G-PHY with /new/ firmware commit 2fc68eb upstream. Support for firmware rev 508+ was added years ago, but we never noticed it reports channel in a different way for G-PHY devices. Instead of offset from 2400 MHz it simply passes channel id (AKA hw_value). So far it was (most probably) affecting monitor mode users only, but the following recent commit made it noticeable for quite everybody: commit 3afc216 Author: Emmanuel Grumbach <[email protected]> Date: Tue Mar 4 16:50:13 2014 +0200 cfg80211/mac80211: ignore signal if the frame was heard on wrong channel Reported-by: Aaro Koskinen <[email protected]> Signed-off-by: Rafał Miłecki <[email protected]> Tested-by: Aaro Koskinen <[email protected]> Signed-off-by: John W. Linville <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> CIFS: fix mount failure with broken pathnames when smb3 mount with mapchars option commit ce36d9a upstream. When we SMB3 mounted with mapchars (to allow reserved characters : \ / > < * ? via the Unicode Windows to POSIX remap range) empty paths (eg when we open "" to query the root of the SMB3 directory on mount) were not null terminated so we sent garbarge as a path name on empty paths which caused SMB2/SMB2.1/SMB3 mounts to fail when mapchars was specified. mapchars is particularly important since Unix Extensions for SMB3 are not supported (yet) Signed-off-by: Steve French <[email protected]> Reviewed-by: David Disseldorp <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> KVM: x86: Increase the number of fixed MTRR regs to 10 commit 682367c upstream. Recent Intel CPUs have 10 variable range MTRRs. Since operating systems sometime make assumptions on CPUs while they ignore capability MSRs, it is better for KVM to be consistent with recent CPUs. Reporting more MTRRs than actually supported has no functional implications. Signed-off-by: Nadav Amit <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> KVM: x86: preserve the high 32-bits of the PAT register commit 7cb060a upstream. KVM does not really do much with the PAT, so this went unnoticed for a long time. It is exposed however if you try to do rdmsr on the PAT register. Reported-by: Valentine Sinitsyn <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> nfsd: fix rare symlink decoding bug commit 76f4712 upstream. An NFS operation that creates a new symlink includes the symlink data, which is xdr-encoded as a length followed by the data plus 0 to 3 bytes of zero-padding as required to reach a 4-byte boundary. The vfs, on the other hand, wants null-terminated data. The simple way to handle this would be by copying the data into a newly allocated buffer with space for the final null. The current nfsd_symlink code tries to be more clever by skipping that step in the (likely) case where the byte following the string is already 0. But that assumes that the byte following the string is ours to look at. In fact, it might be the first byte of a page that we can't read, or of some object that another task might modify. Worse, the NFSv4 code tries to fix the problem by actually writing to that byte. In the NFSv2/v3 cases this actually appears to be safe: - nfs3svc_decode_symlinkargs explicitly null-terminates the data (after first checking its length and copying it to a new page). - NFSv2 limits symlinks to 1k. The buffer holding the rpc request is always at least a page, and the link data (and previous fields) have maximum lengths that prevent the request from reaching the end of a page. In the NFSv4 case the CREATE op is potentially just one part of a long compound so can end up on the end of a page if you're unlucky. The minimal fix here is to copy and null-terminate in the NFSv4 case. The nfsd_symlink() interface here seems too fragile, though. It should really either do the copy itself every time or just require a null-terminated string. Reported-by: Jeff Layton <[email protected]> Signed-off-by: J. Bruce Fields <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> tools: ffs-test: fix header values endianess commit f35f712 upstream. It appears that no one ever run ffs-test on a big-endian machine, since it used cpu-endianess for fs_count and hs_count fields which should be in little-endian format. Fix by wrapping the numbers in cpu_to_le32. Signed-off-by: Michal Nazarewicz <[email protected]> Signed-off-by: Felipe Balbi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> md: flush writes before starting a recovery. commit 133d452 upstream. When we write to a degraded array which has a bitmap, we make sure the relevant bit in the bitmap remains set when the write completes (so a 're-add' can quickly rebuilt a temporarily-missing device). If, immediately after such a write starts, we incorporate a spare, commence recovery, and skip over the region where the write is happening (because the 'needs recovery' flag isn't set yet), then that write will not get to the new device. Once the recovery finishes the new device will be trusted, but will have incorrect data, leading to possible corruption. We cannot set the 'needs recovery' flag when we start the write as we do not know easily if the write will be "degraded" or not. That depends on details of the particular raid level and particular write request. This patch fixes a corruption issue of long standing and so it suitable for any -stable kernel. It applied correctly to 3.0 at least and will minor editing to earlier kernels. Reported-by: Bill <[email protected]> Tested-by: Bill <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: NeilBrown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> sym53c8xx_2: Set DID_REQUEUE return code when aborting squeue commit fd1232b upstream. This patch fixes I/O errors with the sym53c8xx_2 driver when the disk returns QUEUE FULL status. When the controller encounters an error (including QUEUE FULL or BUSY status), it aborts all not yet submitted requests in the function sym_dequeue_from_squeue. This function aborts them with DID_SOFT_ERROR. If the disk has full tag queue, the request that caused the overflow is aborted with QUEUE FULL status (and the scsi midlayer properly retries it until it is accepted by the disk), but the sym53c8xx_2 driver aborts the following requests with DID_SOFT_ERROR --- for them, the midlayer does just a few retries and then signals the error up to sd. The result is that disk returning QUEUE FULL causes request failures. The error was reproduced on 53c895 with COMPAQ BD03685A24 disk (rebranded ST336607LC) with command queue 48 or 64 tags. The disk has 64 tags, but under some access patterns it return QUEUE FULL when there are less than 64 pending tags. The SCSI specification allows returning QUEUE FULL anytime and it is up to the host to retry. Signed-off-by: Mikulas Patocka <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: James Bottomley <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> acpi/video_detect: blacklist samsung x360 commit 084940d upstream. On Samsung X360, the BIOS will set a flag (VDRV) if the generic ACPI backlight device is used. This flag will definitively break the backlight interface (even the vendor interface) untill next reboot. It's why we should prevent video.ko from being used here and we can't rely on a later call to acpi_video_unregister(). Signed-off-by: Corentin Chary <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Signed-off-by: Ben Hutchings <[email protected]> Cc: Yijing Wang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> ACPI / video: Add "Asus UL30VT" to ACPI video detect blacklist commit d0c2ce1 upstream. The ACPI video driver can't control backlight correctly on Asus UL30VT. Vendor driver (asus-laptop) can work. This patch is to add "Asus UL30VT" to ACPI video detect blacklist in order to use asus-laptop for video control on the "Asus UL30VT" rather than ACPI video driver. References: https://bugzilla.kernel.org/show_bug.cgi?id=32592 Reported-by: Alex Williamson <[email protected]> Signed-off-by: Lan Tianyu <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Ben Hutchings <[email protected]> Cc: Yijing Wang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> ACPI / video: Add "Asus UL30A" to ACPI video detect blacklist commit c8f6d83 upstream. Like on UL30VT, the ACPI video driver can't control backlight correctly on Asus UL30A. Vendor driver (asus-laptop) can work. This patch is to add "Asus UL30A" to ACPI video detect blacklist in order to use asus-laptop for video control on the "Asus UL30A" rather than ACPI video driver. Signed-off-by: Bastian Triller <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Ben Hutchings <[email protected]> Cc: Yijing Wang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> ACPI video: ignore BIOS initial backlight value for HP 1000 commit 4ef366c upstream. On HP 1000 lapops, BIOS reports minimum backlight on boot and causes backlight to dim completely. This ignores the initial backlight values and set to max brightness. References:: https://bugs.launchpad.net/bugs/1167760 Signed-off-by: Alex Hung <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Ben Hutchings <[email protected]> Cc: Yijing Wang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> staging: comedi: das08: Correct AI encoding for das08jr-16-ao commit e6391a1 upstream. The element of `das08_boards[]` for the 'das08jr-16-ao' board has the `ai_encoding` member set to `das08_encode12`. It should be set to `das08_encode16` same as the 'das08jr/16' board. After all, this board has 16-bit AI resolution. The description of the A/D LSB register at offset 0 seems incorrect in the user manual "cio-das08jr-16-ao.pdf" as it implies that the AI resolution is only 12 bits. The diagrams of the A/D LSB and MSB registers show 15 data bits and a sign bit, which matches what the software expects for the `das08_encode16` AI encoding method. Signed-off-by: Ian Abbott <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> [bwh: Backported to 3.2: adjust indentation] Signed-off-by: Ben Hutchings <[email protected]> Cc: Yijing Wang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> staging: comedi: fix a race between do_cmd_ioctl() and read/write commit 4b18f08 upstream. `do_cmd_ioctl()` is called with the comedi device's mutex locked to process the `COMEDI_CMD` ioctl to set up comedi's asynchronous command handling on a comedi subdevice. `comedi_read()` and `comedi_write()` are the `read` and `write` handlers for the comedi device, but do not lock the mutex (for performance reasons, as some things can hold the mutex for quite a long time). There is a race condition if `comedi_read()` or `comedi_write()` is running at the same time and for the same file object and comedi subdevice as `do_cmd_ioctl()`. `do_cmd_ioctl()` sets the subdevice's `busy` pointer to the file object way before it sets the `SRF_RUNNING` flag in the subdevice's `runflags` member. `comedi_read() and `comedi_write()` check the subdevice's `busy` pointer is pointing to the current file object, then if the `SRF_RUNNING` flag is not set, will call `do_become_nonbusy()` to shut down the asyncronous command. Bad things can happen if the asynchronous command is being shutdown and set up at the same time. To prevent the race, don't set the `busy` pointer until after the `SRF_RUNNING` flag has been set. Also, make sure the mutex is held in `comedi_read()` and `comedi_write()` while calling `do_become_nonbusy()` in order to avoid moving the race condition to a point within that function. Change some error handling `goto cleanup` statements in `do_cmd_ioctl()` to simple `return -ERRFOO` statements as a result of changing when the `busy` pointer is set. Signed-off-by: Ian Abbott <[email protected]> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <[email protected]> Cc: Yijing Wang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> staging: wlags49_h2: buffer overflow setting station name commit b5e2f33 upstream. We need to check the length parameter before doing the memcpy(). I've actually changed it to strlcpy() as well so that it's NUL terminated. You need CAP_NET_ADMIN to trigger these so it's not the end of the world. Reported-by: Nico Golde <[email protected]> Reported-by: Fabian Yamaguchi <[email protected]> Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <[email protected]> Cc: Yijing Wang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Staging: bcm: Create and initialize new device id in InterfaceInit commit e66fc1f upstream. This patch create and initalizes a new device id of 0x172 as reported by Rinat Camalov <[email protected]>. In addition, a comment is added to the potential invalid existing device id. Reported-by: Rinat Camalov <[email protected]> Signed-off-by: Kevin McKinney <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <[email protected]> Cc: Yijing Wang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Staging: bcm: Add two products and remove an existing product. commit 4f29ef0 upstream. This patch adds two new products and modifies the device id table to include them. In addition, product of 0xbccd - BCM_USB_PRODUCT_ID_SM250 is removed because Beceem, ZTE, Sprint use this id for block devices. Reported-by: Muhammad Minhazul Haque <[email protected]> Signed-off-by: Kevin McKinney <[email protected]> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <[email protected]> Cc: Yijing Wang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> powerpc: Fix emulation of illegal instructions on PowerNV platform commit bf59390 upstream. Normally, the kernel emulates a few instructions that are unimplemented on some processors (e.g. the old dcba instruction), or privileged (e.g. mfpvr). The emulation of unimplemented instructions is currently not working on the PowerNV platform. The reason is that on these machines, unimplemented and illegal instructions cause a hypervisor emulation assist interrupt, rather than a program interrupt as on older CPUs. Our vector for the emulation assist interrupt just calls program_check_exception() directly, without setting the bit in SRR1 that indicates an illegal instruction interrupt. This fixes it by making the emulation assist interrupt set that bit before calling program_check_interrupt(). With this, old programs that use no-longer implemented instructions such as dcba now work again. Signed-off-by: Paul Mackerras <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <[email protected]> Cc: Yijing Wang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> powerpc/smp: Section mismatch from smp_release_cpus to __initdata spinning_secondaries commit 8246aca upstream. the smp_release_cpus is a normal funciton and called in normal environments, but it calls the __initdata spinning_secondaries. need modify spinning_secondaries to match smp_release_cpus. the related warning: (the linker report boot_paca.33377, but it should be spinning_secondaries) ----------------------------------------------------------------------------- WARNING: arch/powerpc/kernel/built-in.o(.text+0x23176): Section mismatch in reference from the function .smp_release_cpus() to the variable .init.data:boot_paca.33377 The function .smp_release_cpus() references the variable __initdata boot_paca.33377. This is often because .smp_release_cpus lacks a __initdata annotation or the annotation of boot_paca.33377 is wrong. WARNING: arch/powerpc/kernel/built-in.o(.text+0x231fe): Section mismatch in reference from the function .smp_release_cpus() to the variable .init.data:boot_paca.33377 The function .smp_release_cpus() references the variable __initdata boot_paca.33377. This is often because .smp_release_cpus lacks a __initdata annotation or the annotation of boot_paca.33377 is wrong. ----------------------------------------------------------------------------- Signed-off-by: Chen Gang <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]> Signed-off-by: Ben Hutchings <[email protected]> Cc: Yijing Wang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> powerpc: Don't Oops when accessing /proc/powerpc/lparcfg without hypervisor commit f5f6cbb upstream. /proc/powerpc/lparcfg is an ancient facility (though still actively used) which allows access to some informations relative to the partition when running underneath a PAPR compliant hypervisor. It makes no sense on non-pseries machines. However, currently, not only can it be created on these if the kernel has pseries support, but accessing it on such a machine will crash due to trying to do hypervisor calls. In fact, it should also not do HV calls on older pseries that didn't have an hypervisor either. Finally, it has the plumbing to be a module but is a "bool" Kconfig option. This fixes the whole lot by turning it into a machine_device_initcall that is only created on pseries, and adding the necessary hypervisor check before calling the H_GET_EM_PARMS hypercall Signed-off-by: Benjamin Herrenschmidt <[email protected]> [bwh: Backported to 3.2: lparcfg_cleanup() was a bit different] Signed-off-by: Ben Hutchings <[email protected]> Cc: Yijing Wang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> powerpc: Restore registers on error exit from csum_partial_copy_generic() commit 8f21bd0 upstream. The csum_partial_copy_generic() function saves the PowerPC non-volatile r14, r15, and r16 registers for the main checksum-and-copy loop. Unfortunately, it fails to restore them upon error exit from this loop, which results in silent corruption of these registers in the presumably rare event of an access exception within that loop. This commit therefore restores these register on error exit from the loop. Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Anton Blanchard <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]> [bwh: Backported to 3.2: register name macros use lower-case 'r'] Signed-off-by: Ben Hutchings <[email protected]> Cc: Yijing Wang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> powerpc/pseries/lparcfg: Fix possible overflow are more than 1026 commit 5676005 upstream. need set '\0' for 'local_buffer'. SPLPAR_MAXLENGTH is 1026, RTAS_DATA_BUF_SIZE is 4096. so the contents of rtas_data_buf may truncated in memcpy. if contents are really truncated. the splpar_strlen is more than 1026. the next while loop checking will not find the end of buffer. that will cause memory access violation. Signed-off-by: Chen Gang <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]> Signed-off-by: Ben Hutchings <[email protected]> Cc: Yijing Wang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> powerpc/pseries: Duplicate dtl entries sometimes sent to userspace commit 84b0738 upstream. When reading from the dispatch trace log (dtl) userspace interface, I sometimes see duplicate entries. One example: 00000000 07 04 00 0c 00 00 48 44 00 00 00 00 00 00 00 00 00000010 00 0c a0 b4 16 83 6d 68 00 00 00 00 00 00 00 00 00000020 00 00 00 00 10 00 13 50 80 00 00 00 00 00 d0 32 00000030 07 04 00 0c 00 00 48 44 00 00 00 00 00 00 00 00 00000040 00 0c a0 b4 16 83 6d 68 00 00 00 00 00 00 00 00 00000050 00 00 00 00 10 00 13 50 80 00 00 00 00 00 d0 32 The problem is in scan_dispatch_log() where we call dtl_consumer() but bail out before incrementing the index. To fix this I moved dtl_consumer() after the timebase comparison. Signed-off-by: Anton Blanchard <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <[email protected]> Cc: Yijing Wang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> ACPI video: ignore BIOS backlight value for HP dm4 commit 771d09b upstream. On a HP Pavilion dm4 laptop the BIOS sets minimum backlight on boot, completely dimming the screen. Ignore this initial value for this machine. Signed-off-by: Gustavo Maciel Dias Vieira <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Ben Hutchings <[email protected]> [wyj: Backported to 3.4: adjust context] Signed-off-by: Yijing Wang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> powerpc/sysfs: Disable writing to PURR in guest mode commit d1211af upstream. arch/powerpc/kernel/sysfs.c exports PURR with write permission. This may be valid for kernel in phyp mode. But writing to the file in guest mode causes crash due to a priviledge violation Signed-off-by: Madhavan Srinivasan <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]> [Backported to 3.4: adjust context] Signed-off-by: Yijing Wang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> hugetlb: fix copy_hugetlb_page_range() to handle migration/hwpoisoned entry commit 4a705fe upstream. There's a race between fork() and hugepage migration, as a result we try to "dereference" a swap entry as a normal pte, causing kernel panic. The cause of the problem is that copy_hugetlb_page_range() can't handle "swap entry" family (migration entry and hwpoisoned entry) so let's fix it. [[email protected]: coding-style fixes] Signed-off-by: Naoya Horiguchi <[email protected]> Acked-by: Hugh Dickins <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: <[email protected]> [2.6.37+] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> mm: fix crashes from mbind() merging vmas commit d05f0cd upstream. In v2.6.34 commit 9d8cebd ("mm: fix mbind vma merge problem") introduced vma merging to mbind(), but it should have also changed the convention of passing start vma from queue_pages_range() (formerly check_range()) to new_vma_page(): vma merging may have already freed that structure, resulting in BUG at mm/mempolicy.c:1738 and probably worse crashes. Fixes: 9d8cebd ("mm: fix mbind vma merge problem") Reported-by: Naoya Horiguchi <[email protected]> Tested-by: Naoya Horiguchi <[email protected]> Signed-off-by: Hugh Dickins <[email protected]> Acked-by: Christoph Lameter <[email protected]> Cc: KOSAKI Motohiro <[email protected]> Cc: Minchan Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
HTC kernel version: m7stock_3.4.10-g1a25406 Change-Id: I2707390c287a6d2a9f05814aea25362347240048
* Set the correct behavior for HTC's driver, and turn these options off for 8960s. They cause some nasty side effects on XHCI systems. Change-Id: I5d0e8ceaadd2cf4d90bfef420a144e07eae39f76
This reverts commit b058009. Change-Id: Id1869a455e9cc77d0e9735cd9290f0204c50dcb1
PCM driver was configured for fixed buffer size on the playback path. With this, varying the buffer sizes on the playback path was not possible. To fix this, support for flexible period sizes is added by setting different values for min and max buffer sizes Change-Id: I7f69db4940f67e5e3a795101af1b1682afbdb530 Signed-off-by: Alexy Joseph <[email protected]> Signed-off-by: Mekala Natarajan <[email protected]>
Change-Id: I7c12a1fbae39ebee86f526549afe82451f87fd1b
Change-Id: Ic9db1ec35255643c3cca7a351be0f1481c60f086
Change-Id: I36fe217fa047d68ea90e78b12c7db4537ea8010b Signed-off-by: Ruchi Kandoi <[email protected]>
Cpufreq time_in_state data for all CPUs is made persistent across hotplug and exposed to userspace via sysfs file /sys/devices/system/cpu/cpufreq/all_time_in_state Change-Id: I97cb5de24b6de16189bf8b5df9592d0a6e6ddf32 Signed-off-by: Ruchi Kandoi <[email protected]>
…ll_time_in_state Commit 40cf2f8 (cpufreq: Persist cpufreq time in state data across hotplug) causes the following call trace to be spit on boot: BUG: sleeping function called from invalid context at mm/slub.c:936 in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0 CPU: 6 PID: 1 Comm: swapper/0 Not tainted 3.10.9-20140624.172707-eng-gd6c0f69-dirty #50 Backtrace: [<c0012270>] (dump_backtrace+0x0/0x10c) from [<c001256c>] (show_stack+0x18/0x1c) r6:ffff1788 r5:c0c020c0 r4:e609c000 r3:00000000 [<c0012554>] (show_stack+0x0/0x1c) from [<c07a2970>] (dump_stack+0x20/0x28) [<c07a2950>] (dump_stack+0x0/0x28) from [<c0057678>] (__might_sleep+0x104/0x120) [<c0057574>] (__might_sleep+0x0/0x120) from [<c00ff000>] (__kmalloc_track_caller+0x144/0x274) r6:00000000 r5:e609c000 r4:e6802140 [<c00feebc>] (__kmalloc_track_caller+0x0/0x274) from [<c00da098>] (krealloc+0x58/0xb0) [<c00da040>] (krealloc+0x0/0xb0) from [<c050266c>] (cpufreq_allstats_create+0x120/0x204) r8:e4c4ff00 r7:c0d266b8 r6:0013d620 r5:e4c4e600 r4:00000001 r3:e535d6d0 [<c050254c>] (cpufreq_allstats_create+0x0/0x204) from [<c0502e38>] (cpufreq_stat_notifier_policy+0xb8/0xd0) [<c0502d80>] (cpufreq_stat_notifier_policy+0x0/0xd0) from [<c00517cc>] (notifier_call_chain+0x4c/0x8c) r5:00000000 r4:fffffffe [<c0051780>] (notifier_call_chain+0x0/0x8c) from [<c00519fc>] (__blocking_notifier_call_chain+0x50/0x68) r8:c0cd4d00 r7:00000002 r6:e609dd7c r5:ffffffff r4:c0d25a4c r3:ffffffff [<c00519ac>] (__blocking_notifier_call_chain+0x0/0x68) from [<c0051a34>] (blocking_notifier_call_chain+0x20/0x28) r7:c0e24f30 r6:00000000 r5:e53e1e00 r4:e609dd7c [<c0051a14>] (blocking_notifier_call_chain+0x0/0x28) from [<c0500fec>] (__cpufreq_set_policy+0xc0/0x1d0) [<c0500f2c>] (__cpufreq_set_policy+0x0/0x1d0) from [<c0501308>] (cpufreq_add_dev_interface+0x20c/0x270) r7:00000008 r6:00000000 r5:e53e1e00 r4:e53e1e58 [<c05010fc>] (cpufreq_add_dev_interface+0x0/0x270) from [<c05016a8>] (cpufreq_add_dev+0x33c/0x420) [<c050136c>] (cpufreq_add_dev+0x0/0x420) from [<c03604a4>] (subsys_interface_register+0x80/0xbc) [<c0360424>] (subsys_interface_register+0x0/0xbc) from [<c050035c>] (cpufreq_register_driver+0x8c/0x194) Change-Id: If77a656d0ea60a8fc4083283d104509fa6c07f8f Signed-off-by: Minsung Kim <[email protected]>
Cpufreq no longer calls governor callback for offlined cpus. i.e. All policy->cpus are guaranteed to be online. Hence we don't need explicit check to see if cpu is online or not. Change-Id: I9ad85ea4addd5b4a40952e59ed730dd15e328690 Signed-off-by: Viresh Kumar <[email protected]>
Using a single set of target loads causes an excessive number of frequency changes. Reduce by having a mode that allows for separate load factos for "up" frequency selection and "down" frequency selection. If user-space specifies target_loads_down then the new duel mode frequency selection will be used and frequencies will be scaled up to meet the load requirements but they will only be scaled down if the can be scaled down without violating the down target loads. If user-space does not store a value in target_loads_down then this change makes no functional difference in the governor. Conflicts: drivers/cpufreq/cpufreq_interactive.c Change-Id: If19cd1d2b48e18ab4f0baf0576f89b765b96a3ee Conflicts: drivers/cpufreq/cpufreq_interactive.c
This reverts commit ffed688.
Create a generic version of ablk_helper so it can be reused by other architectures. Acked-by: Jussi Kivilinna <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Conflicts: crypto/Kconfig crypto/Makefile Change-Id: I01a0d1192383c9a0287590a2cef1424e4675c531
tree: git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master head: 48e6dc1 commit: a62b01c [20/24] crypto: create generic version of ablk_helper coccinelle warnings: (new ones prefixed by >>) >> crypto/ablk_helper.c:97:2-8: Replace memcpy with struct assignment >> crypto/ablk_helper.c:78:2-8: Replace memcpy with struct assignment Please consider folding the attached diff :-) Signed-off-by: Herbert Xu <[email protected]>
Add assembler versions of AES and SHA1 for ARM platforms. This has provided up to a 50% improvement in IPsec/TCP throughout for tunnels using AES128/SHA1. Platform CPU SPeed Endian Before (bps) After (bps) Improvement IXP425 533 MHz big 11217042 15566294 ~38% KS8695 166 MHz little 3828549 5795373 ~51% Signed-off-by: David McCullough <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
Put the struct definitions for AES keys and the asm function prototypes in a separate header and export the asm functions from the module. This allows other drivers to use them directly. Signed-off-by: Ard Biesheuvel <[email protected]>
Bit sliced AES gives around 45% speedup on Cortex-A15 for encryption
and around 25% for decryption. This implementation of the AES algorithm
does not rely on any lookup tables so it is believed to be invulnerable
to cache timing attacks.
This algorithm processes up to 8 blocks in parallel in constant time. This
means that it is not usable by chaining modes that are strictly sequential
in nature, such as CBC encryption. CBC decryption, however, can benefit from
this implementation and runs about 25% faster. The other chaining modes
implemented in this module, XTS and CTR, can execute fully in parallel in
both directions.
The core code has been adopted from the OpenSSL project (in collaboration
with the original author, on cc). For ease of maintenance, this version is
identical to the upstream OpenSSL code, i.e., all modifications that were
required to make it suitable for inclusion into the kernel have been made
upstream. The original can be found here:
http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=6f6a6130
Note to integrators:
While this implementation is significantly faster than the existing table
based ones (generic or ARM asm), especially in CTR mode, the effects on
power efficiency are unclear as of yet. This code does fundamentally more
work, by calculating values that the table based code obtains by a simple
lookup; only by doing all of that work in a SIMD fashion, it manages to
perform better.
Cc: Andy Polyakov <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>
This avoids this file being incorrectly added to git. Signed-off-by: Russell King <[email protected]>
Building a multi-arch kernel results in: arch/arm/crypto/built-in.o: In function `aesbs_xts_decrypt': sha1_glue.c:(.text+0x15c8): undefined reference to `bsaes_xts_decrypt' arch/arm/crypto/built-in.o: In function `aesbs_xts_encrypt': sha1_glue.c:(.text+0x1664): undefined reference to `bsaes_xts_encrypt' arch/arm/crypto/built-in.o: In function `aesbs_ctr_encrypt': sha1_glue.c:(.text+0x184c): undefined reference to `bsaes_ctr32_encrypt_blocks' arch/arm/crypto/built-in.o: In function `aesbs_cbc_decrypt': sha1_glue.c:(.text+0x19b4): undefined reference to `bsaes_cbc_encrypt' This code is already runtime-conditional on NEON being supported, so there's no point compiling it out depending on the minimum build architecture. Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Russell King <[email protected]>
Fix the same alignment bug as in arm64 - we need to pass residue unprocessed bytes as the last argument to blkcipher_walk_done. Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] # 3.13+ Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
Common SHA-1 structures are defined in <crypto/sha.h> for code sharing. This patch changes SHA-1/ARM glue code to use these structures. Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Jussi Kivilinna <[email protected]> Signed-off-by: Russell King <[email protected]>
This patch adds ARM NEON assembly implementation of SHA-1 algorithm. tcrypt benchmark results on Cortex-A8, sha1-arm-asm vs sha1-neon-asm: block-size bytes/update old-vs-new 16 16 1.04x 64 16 1.02x 64 64 1.05x 256 16 1.03x 256 64 1.04x 256 256 1.30x 1024 16 1.03x 1024 256 1.36x 1024 1024 1.52x 2048 16 1.03x 2048 256 1.39x 2048 1024 1.55x 2048 2048 1.59x 4096 16 1.03x 4096 256 1.40x 4096 1024 1.57x 4096 4096 1.62x 8192 16 1.03x 8192 256 1.40x 8192 1024 1.58x 8192 4096 1.63x 8192 8192 1.63x Acked-by: Ard Biesheuvel <[email protected]> Tested-by: Ard Biesheuvel <[email protected]> Signed-off-by: Jussi Kivilinna <[email protected]> Signed-off-by: Russell King <[email protected]> Conflicts: crypto/Kconfig Change-Id: I4e40ca3e67b85b15ef21c28d91946d6b64d820c8
This patch adds ARM NEON assembly implementation of SHA-512 and SHA-384 algorithms. tcrypt benchmark results on Cortex-A8, sha512-generic vs sha512-neon-asm: block-size bytes/update old-vs-new 16 16 2.99x 64 16 2.67x 64 64 3.00x 256 16 2.64x 256 64 3.06x 256 256 3.33x 1024 16 2.53x 1024 256 3.39x 1024 1024 3.52x 2048 16 2.50x 2048 256 3.41x 2048 1024 3.54x 2048 2048 3.57x 4096 16 2.49x 4096 256 3.42x 4096 1024 3.56x 4096 4096 3.59x 8192 16 2.48x 8192 256 3.42x 8192 1024 3.56x 8192 4096 3.60x 8192 8192 3.60x Acked-by: Ard Biesheuvel <[email protected]> Tested-by: Ard Biesheuvel <[email protected]> Signed-off-by: Jussi Kivilinna <[email protected]> Signed-off-by: Russell King <[email protected]> Conflicts: crypto/Kconfig Change-Id: I949f87031d2c49cb7a0474aae4cf83da2154749a
The support code in vfp_support_entry does not care whether the exception that caused it to be invoked occurred in kernel mode or in user mode. However, neither condition that could trigger this exception (lazy restore and VFP bounce to support code) is currently allowable in kernel mode. In either case, print a message describing the condition before letting the undefined instruction handler run its course and trigger an oops. Change-Id: I1a9508f3adfb0264cac1984d6080d117bfcb39f6 Signed-off-by: Ard Biesheuvel <[email protected]> Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>
…lly. Other SHA256 routine may need to use the generic routine when FPU is not available. Signed-off-by: Tim Chen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
…her modules Other SHA512 routines may need to use the generic routine when FPU is not available. Signed-off-by: Tim Chen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
…shash entries at once Add crypto_[un]register_shashes() to allow simplifying init/exit code of shash crypto modules that register multiple algorithms. Signed-off-by: Jussi Kivilinna <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
In order to safely support the use of NEON instructions in kernel mode, some precautions need to be taken: - the userland context that may be present in the registers (even if the NEON/VFP is currently disabled) must be stored under the correct task (which may not be 'current' in the UP case), - to avoid having to keep track of additional vfpstates for the kernel side, disallow the use of NEON in interrupt context and run with preemption disabled, - after use, re-enable preemption and re-enable the lazy restore machinery by disabling the NEON/VFP unit. This patch adds the functions kernel_neon_begin() and kernel_neon_end() which take care of the above. It also adds the Kconfig symbol KERNEL_MODE_NEON to enable it. Change-Id: Iddde22ad8684e92e5f0aa4999962ad743eff8f7c Signed-off-by: Ard Biesheuvel <[email protected]> Acked-by: Nicolas Pitre <[email protected]>
In order to use the NEON unit in the kernel, we should initialize it a bit earlier in the boot process so NEON users that like to do a quick benchmark at load time (like the xor_blocks or RAID-6 code) find the NEON/VFP unit already enabled. Replaced late_initcall() with core_initcall(). Change-Id: I89b7a5a79dddf6083766a87f9d082c7ee61a54e0 Signed-off-by: Ard Biesheuvel <[email protected]> Acked-by: Nicolas Pitre <[email protected]>
Add a source file xor-neon.c (which is really just the reference C implementation passed through the GCC vectorizer) and hook it up to the XOR framework. Change-Id: If251e5a16d628ddfdd8d6ce40b78014cd2962d7e Signed-off-by: Ard Biesheuvel <[email protected]> Acked-by: Nicolas Pitre <[email protected]>
Macro __INIT is used to place various code in head-common.S into the init section. This should be matched by a closing __FINIT. Also, add an explicit ".text" to ensure subsequent code is placed into the correct section; __FINIT is simply a closing marker to match __INIT and doesn't guarantee to revert to .text. This historically caused no problem, because macro __CPUINIT was used at the exact location where __FINIT was missing, which then placed following code into the cpuinit section. However, with commit 22f0a27 "init.h: remove __cpuinit sections from the kernel" applied, __CPUINIT becomes a no-op, thus leaving all this code in the init section, rather than the regular text section. This caused issues such as secondary CPU boot failures or crashes. Change-Id: I2c346b58c4c4d50a162b19e9967d44ec5e97c7d4 Signed-off-by: Stephen Warren <[email protected]> Acked-by: Paul Gortmaker <[email protected]> Signed-off-by: Russell King <[email protected]>
imx_v6_v7_defconfig handles both multi-core and single-core SoCs, and it has CONFIG_SMP=y selected by default. With such config we cannot select ARM_ERRATA_364296, as it depends on !SMP. Let ARM_ERRATA_364296 be undependent on CONFIG_SMP, so that we can select this erratum for the ARM1136 SoCs, even if CONFIG_SMP=y is enabled. Change-Id: Ia96ea3d8e9468884962793cc4a6b19f62e1adc59 Reviewed-by: Dave Martin <[email protected]> Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Russell King <[email protected]>
Creation of procfs cpu/vfp_bounce fails because we're initialized too early. Fix this by creating it on rootfs_initcall as before the NEON patches. <6>[ 0.130770] VFP support v0.3: implementor 51 architecture 64 part 6f varia nt 2 rev 0 <4>[ 0.130795] ------------[ cut here ]------------ <4>[ 0.130813] WARNING: at fs/proc/generic.c:323 __xlate_proc_name+0xac/0xcc( ) <4>[ 0.130822] name 'cpu/vfp_bounce' <4>[ 0.130855] [<c010e26c>] (unwind_backtrace+0x0/0x144) from [<c0a20f58>] (d ump_stack+0x20/0x24) <4>[ 0.130879] [<c0a20f58>] (dump_stack+0x20/0x24) from [<c019b670>] (warn_sl owpath_common+0x58/0x70) <4>[ 0.130899] [<c019b670>] (warn_slowpath_common+0x58/0x70) from [<c019b704> ] (warn_slowpath_fmt+0x40/0x48) <4>[ 0.130919] [<c019b704>] (warn_slowpath_fmt+0x40/0x48) from [<c02c2ad8>] ( __xlate_proc_name+0xac/0xcc) <4>[ 0.130938] [<c02c2ad8>] (__xlate_proc_name+0xac/0xcc) from [<c02c2b50>] ( __proc_create+0x58/0x100) <4>[ 0.130956] [<c02c2b50>] (__proc_create+0x58/0x100) from [<c02c2ed0>] (pro c_create_data+0x5c/0xc0) <4>[ 0.130979] [<c02c2ed0>] (proc_create_data+0x5c/0xc0) from [<c0f03484>] (v fp_init+0x19c/0x200) <4>[ 0.131000] [<c0f03484>] (vfp_init+0x19c/0x200) from [<c0f00c98>] (do_one_ initcall+0x98/0x168) <4>[ 0.131020] [<c0f00c98>] (do_one_initcall+0x98/0x168) from [<c0f00e60>] (k ernel_init+0xf8/0x1b4) <4>[ 0.131043] [<c0f00e60>] (kernel_init+0xf8/0x1b4) from [<c01081a0>] (kerne l_thread_exit+0x0/0x8) <4>[ 0.131076] ---[ end trace ea6d9a9b5e947151 ]--- <3>[ 0.131086] Failed to create procfs node for VFP bounce reporting Change-Id: Ic9bbe46ee026df0af76df70fd95275f284c8dd63 Signed-off-by: Paul Reioux <[email protected]>
Commit 722b3c7 modified x86 ftrace to avoid tracing all functions called from irqs when function graph was used with a filter. Port the same fix to ARM. Change-Id: I3facbb85447effe54ff92db206068087c892fc28 Signed-off-by: Colin Cross <[email protected]>
* HTC kernel version: m7stockui-3.4.0-g3a7d36e Change-Id: I409a5de1f3abccc437e75f6eb5ba293b20094aed
* HTC kernel version: m7stockui-3.4.0-g3a7d36e Change-Id: I4685f9378fcb1789e232c95771d0eb5e946572a0
ivanich
pushed a commit
to ivanich/android_kernel_htc_pyramid
that referenced
this pull request
Oct 18, 2015
While testing the pid namespace code I hit this nasty warning. [ 176.262617] ------------[ cut here ]------------ [ 176.263388] WARNING: at /home/eric/projects/linux/linux-userns-devel/kernel/softirq.c:160 local_bh_enable_ip+0x7a/0xa0() [ 176.265145] Hardware name: Bochs [ 176.265677] Modules linked in: [ 176.266341] Pid: 742, comm: bash Not tainted 3.7.0userns+ Flemmard#18 [ 176.266564] Call Trace: [ 176.266564] [<ffffffff810a539f>] warn_slowpath_common+0x7f/0xc0 [ 176.266564] [<ffffffff810a53fa>] warn_slowpath_null+0x1a/0x20 [ 176.266564] [<ffffffff810ad9ea>] local_bh_enable_ip+0x7a/0xa0 [ 176.266564] [<ffffffff819308c9>] _raw_spin_unlock_bh+0x19/0x20 [ 176.266564] [<ffffffff8123dbda>] proc_free_inum+0x3a/0x50 [ 176.266564] [<ffffffff8111d0dc>] free_pid_ns+0x1c/0x80 [ 176.266564] [<ffffffff8111d195>] put_pid_ns+0x35/0x50 [ 176.266564] [<ffffffff810c608a>] put_pid+0x4a/0x60 [ 176.266564] [<ffffffff8146b177>] tty_ioctl+0x717/0xc10 [ 176.266564] [<ffffffff810aa4d5>] ? wait_consider_task+0x855/0xb90 [ 176.266564] [<ffffffff81086bf9>] ? default_spin_lock_flags+0x9/0x10 [ 176.266564] [<ffffffff810cab0a>] ? remove_wait_queue+0x5a/0x70 [ 176.266564] [<ffffffff811e37e8>] do_vfs_ioctl+0x98/0x550 [ 176.266564] [<ffffffff810b8a0f>] ? recalc_sigpending+0x1f/0x60 [ 176.266564] [<ffffffff810b9127>] ? __set_task_blocked+0x37/0x80 [ 176.266564] [<ffffffff810ab95b>] ? sys_wait4+0xab/0xf0 [ 176.266564] [<ffffffff811e3d31>] sys_ioctl+0x91/0xb0 [ 176.266564] [<ffffffff810a95f0>] ? task_stopped_code+0x50/0x50 [ 176.266564] [<ffffffff81939199>] system_call_fastpath+0x16/0x1b [ 176.266564] ---[ end trace 387af88219ad6143 ]--- It turns out that spin_unlock_bh(proc_inum_lock) is not safe when put_pid is called with another spinlock held and irqs disabled. For now take the easy path and use spin_lock_irqsave(proc_inum_lock) in proc_free_inum and spin_loc_irq in proc_alloc_inum(proc_inum_lock). Signed-off-by: "Eric W. Biederman" <[email protected]> Bug: 22173056 Backport: commits 0f7aa3c to this one are backport of mnt namespace Signed-off-by: Thierry Strudel <[email protected]> (cherry picked from commit dfb2ea4)
shantur
pushed a commit
to UnORoms/akh8960_cm
that referenced
this pull request
Oct 25, 2015
While testing the pid namespace code I hit this nasty warning. [ 176.262617] ------------[ cut here ]------------ [ 176.263388] WARNING: at /home/eric/projects/linux/linux-userns-devel/kernel/softirq.c:160 local_bh_enable_ip+0x7a/0xa0() [ 176.265145] Hardware name: Bochs [ 176.265677] Modules linked in: [ 176.266341] Pid: 742, comm: bash Not tainted 3.7.0userns+ Flemmard#18 [ 176.266564] Call Trace: [ 176.266564] [<ffffffff810a539f>] warn_slowpath_common+0x7f/0xc0 [ 176.266564] [<ffffffff810a53fa>] warn_slowpath_null+0x1a/0x20 [ 176.266564] [<ffffffff810ad9ea>] local_bh_enable_ip+0x7a/0xa0 [ 176.266564] [<ffffffff819308c9>] _raw_spin_unlock_bh+0x19/0x20 [ 176.266564] [<ffffffff8123dbda>] proc_free_inum+0x3a/0x50 [ 176.266564] [<ffffffff8111d0dc>] free_pid_ns+0x1c/0x80 [ 176.266564] [<ffffffff8111d195>] put_pid_ns+0x35/0x50 [ 176.266564] [<ffffffff810c608a>] put_pid+0x4a/0x60 [ 176.266564] [<ffffffff8146b177>] tty_ioctl+0x717/0xc10 [ 176.266564] [<ffffffff810aa4d5>] ? wait_consider_task+0x855/0xb90 [ 176.266564] [<ffffffff81086bf9>] ? default_spin_lock_flags+0x9/0x10 [ 176.266564] [<ffffffff810cab0a>] ? remove_wait_queue+0x5a/0x70 [ 176.266564] [<ffffffff811e37e8>] do_vfs_ioctl+0x98/0x550 [ 176.266564] [<ffffffff810b8a0f>] ? recalc_sigpending+0x1f/0x60 [ 176.266564] [<ffffffff810b9127>] ? __set_task_blocked+0x37/0x80 [ 176.266564] [<ffffffff810ab95b>] ? sys_wait4+0xab/0xf0 [ 176.266564] [<ffffffff811e3d31>] sys_ioctl+0x91/0xb0 [ 176.266564] [<ffffffff810a95f0>] ? task_stopped_code+0x50/0x50 [ 176.266564] [<ffffffff81939199>] system_call_fastpath+0x16/0x1b [ 176.266564] ---[ end trace 387af88219ad6143 ]--- It turns out that spin_unlock_bh(proc_inum_lock) is not safe when put_pid is called with another spinlock held and irqs disabled. For now take the easy path and use spin_lock_irqsave(proc_inum_lock) in proc_free_inum and spin_loc_irq in proc_alloc_inum(proc_inum_lock). Signed-off-by: "Eric W. Biederman" <[email protected]> Bug: 22173056 Backport: commits 0f7aa3c to this one are backport of mnt namespace Signed-off-by: Thierry Strudel <[email protected]> (cherry picked from commit dfb2ea4)
ivanich
pushed a commit
to ivanich/android_kernel_htc_pyramid
that referenced
this pull request
Jun 4, 2016
While testing the pid namespace code I hit this nasty warning. [ 176.262617] ------------[ cut here ]------------ [ 176.263388] WARNING: at /home/eric/projects/linux/linux-userns-devel/kernel/softirq.c:160 local_bh_enable_ip+0x7a/0xa0() [ 176.265145] Hardware name: Bochs [ 176.265677] Modules linked in: [ 176.266341] Pid: 742, comm: bash Not tainted 3.7.0userns+ Flemmard#18 [ 176.266564] Call Trace: [ 176.266564] [<ffffffff810a539f>] warn_slowpath_common+0x7f/0xc0 [ 176.266564] [<ffffffff810a53fa>] warn_slowpath_null+0x1a/0x20 [ 176.266564] [<ffffffff810ad9ea>] local_bh_enable_ip+0x7a/0xa0 [ 176.266564] [<ffffffff819308c9>] _raw_spin_unlock_bh+0x19/0x20 [ 176.266564] [<ffffffff8123dbda>] proc_free_inum+0x3a/0x50 [ 176.266564] [<ffffffff8111d0dc>] free_pid_ns+0x1c/0x80 [ 176.266564] [<ffffffff8111d195>] put_pid_ns+0x35/0x50 [ 176.266564] [<ffffffff810c608a>] put_pid+0x4a/0x60 [ 176.266564] [<ffffffff8146b177>] tty_ioctl+0x717/0xc10 [ 176.266564] [<ffffffff810aa4d5>] ? wait_consider_task+0x855/0xb90 [ 176.266564] [<ffffffff81086bf9>] ? default_spin_lock_flags+0x9/0x10 [ 176.266564] [<ffffffff810cab0a>] ? remove_wait_queue+0x5a/0x70 [ 176.266564] [<ffffffff811e37e8>] do_vfs_ioctl+0x98/0x550 [ 176.266564] [<ffffffff810b8a0f>] ? recalc_sigpending+0x1f/0x60 [ 176.266564] [<ffffffff810b9127>] ? __set_task_blocked+0x37/0x80 [ 176.266564] [<ffffffff810ab95b>] ? sys_wait4+0xab/0xf0 [ 176.266564] [<ffffffff811e3d31>] sys_ioctl+0x91/0xb0 [ 176.266564] [<ffffffff810a95f0>] ? task_stopped_code+0x50/0x50 [ 176.266564] [<ffffffff81939199>] system_call_fastpath+0x16/0x1b [ 176.266564] ---[ end trace 387af88219ad6143 ]--- It turns out that spin_unlock_bh(proc_inum_lock) is not safe when put_pid is called with another spinlock held and irqs disabled. For now take the easy path and use spin_lock_irqsave(proc_inum_lock) in proc_free_inum and spin_loc_irq in proc_alloc_inum(proc_inum_lock). Signed-off-by: "Eric W. Biederman" <[email protected]> Bug: 22173056 Backport: commits 0f7aa3c to this one are backport of mnt namespace Signed-off-by: Thierry Strudel <[email protected]> (cherry picked from commit dfb2ea4)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.