IB/mlx5: Flush cache workqueue before destroying it
Destroying the workqueue without flushing it first can lead to a case
in which the kernel tries to push a delayed work to the workqueue
which does not exist anymore.
Eli Cohen [Wed, 11 Sep 2013 13:35:22 +0000 (16:35 +0300)]
IB/mlx5: Fix send work queue size calculation
1. Make sure wqe_cnt does not exceed the limit published by firmware.
2. There is no requirement that the number of outstanding work
requests will be a power of two. Remove the ilog2 in the
calculation of sq.max_post to fix that.
3. Add case for IB_QPT_XRC_TGT in sq_overhead and return 0 as XRC
target QPs do not have a send queue.
usb: gadget: acm_ms: convert to new interface of f_mass_storage
Convert the legacy acm_ms gadget to use the new function interface
of f_mass_storage, so that later the compatibility layer in
f_mass_storage can be removed.
usb: gadget: storage_common: make attribute operations more generic
Show/store methods for sysfs attributes contain code which can be used
also by configfs. Make them abstract the source the lun and rw_semaphore
are taken from.
usb: gadget: f_mass_storage: convert to new function interface with backward compatibility
Converting mass storage to the new function interface requires converting
the USB mass storage's function code and its users.
This patch converts the f_mass_storage.c to the new function interface.
The file is now compiled into a separate usb_f_mass_storage.ko module.
The old function interface is provided by means of a preprocessor conditional
directives. After all users are converted, the old interface can be removed.
usb: gadget: f_mass_storage: make sysfs interface optional
When configfs is in place, the luns will not be represented in sysfs,
so there will be no struct device associated with a lun.
In order to maintain compatibility and allow configfs adoption
sysfs is made optional in this patch.
As a consequence some debug macros need to be adjusted. Two new
fields are added to struct fsg_lun: name and name_pfx.
The "name" is for storing a string which is presented to the user
instead of the dev_name. The "name_pfx", if non-NULL, is prepended
to the "name" at printing time.
The name_pfx is for a future lun.0, which will be a default group in
mass_storage.<name>. By design at USB function configfs group's creation
time its name is not known (but instead set a bit later in
drivers/usb/gadget/configfs.c:function_make) and it is this name that
serves the purpose of the said name prefix. So instead of copying
a yet-unknown string a pointer to it is stored in struct fsg_lun.
Robert Baldyga [Wed, 9 Oct 2013 06:20:02 +0000 (08:20 +0200)]
usb: gadget: s3c-hsotg: fix set_ep_maxpacket function
This patch fixes max packet size check in s3c_hsotg_set_ep_maxpacket()
function. According USB specification, bits 10..0 of mps specifies maximum
packet size, so there is bitwise AND between mps and 0x7ff value. Also added
check if maxpacket isn't grater than 1024 which is maximum size od single USB
transaction.
In s3c_hsotg_ep_enable() function added s3c_hsotg_set_ep_maxpacket() call
instead of setting ep.maxpacket value directly.
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day. Signed-off-by: Michael Opdenacker <[email protected]> Signed-off-by: Felipe Balbi <[email protected]>
David Cohen [Fri, 4 Oct 2013 22:30:21 +0000 (15:30 -0700)]
usb: g_ffs: fix compilation warning
If USB_FUNCTIONFS is selected without USB_FUNCTIONFS_ETH and
USB_FUNCTIONFS_RNIS, u_ether.h won't be included and then
USB_ETHERNET_MODULE_PARAMAETERS macro won't be available causing the
following warning compilation:
drivers/usb/gadget/g_ffs.c:81:1: warning: data definition has no type or
storage class [enabled by default]
drivers/usb/gadget/g_ffs.c:81:1: warning: type defaults to ‘int’ in
declaration of ‘USB_ETHERNET_MODULE_PARAMETERS’ [-Wimplicit-int]
drivers/usb/gadget/g_ffs.c:81:1: warning: function declaration isn’t a
prototype [-Wstrict-prototypes]
This patch fixes the warning by making USB_ETHERNET_MODULE_PARAMETERS to
be used iff u_ether.h is included, otherwise it is not needed.
Frediano Ziglio [Thu, 10 Oct 2013 14:39:37 +0000 (14:39 +0000)]
xen: Fix possible user space selector corruption
Due to the way kernel is initialized under Xen is possible that the
ring1 selector used by the kernel for the boot cpu end up to be copied
to userspace leading to segmentation fault in the userspace.
Xen code in the kernel initialize no-boot cpus with correct selectors (ds
and es set to __USER_DS) but the boot one keep the ring1 (passed by Xen).
On task context switch (switch_to) we assume that ds, es and cs already
point to __USER_DS and __KERNEL_CSso these selector are not changed.
If processor is an Intel that support sysenter instruction sysenter/sysexit
is used so ds and es are not restored switching back from kernel to
userspace. In the case the selectors point to a ring1 instead of __USER_DS
the userspace code will crash on first memory access attempt (to be
precise Xen on the emulated iret used to do sysexit will detect and set ds
and es to zero which lead to GPF anyway).
Now if an userspace process call kernel using sysenter and get rescheduled
(for me it happen on a specific init calling wait4) could happen that the
ring1 selector is set to ds and es.
This is quite hard to detect cause after a while these selectors are fixed
(__USER_DS seems sticky).
Rob Herring [Thu, 10 Oct 2013 14:38:27 +0000 (14:38 +0000)]
tpm: xen-tpmfront: fix missing declaration of xen_domain
xen-tpmfront fails to build on arm64 with the following error:
drivers/char/tpm/xen-tpmfront.c: In function ‘xen_tpmfront_init’:
drivers/char/tpm/xen-tpmfront.c:422:2: error: implicit declaration of function ‘xen_domain’ [-Werror=implicit-function-declaration]
Bharat Bhushan [Wed, 7 Aug 2013 10:03:46 +0000 (15:33 +0530)]
kvm: ppc: booke: check range page invalidation progress on page setup
When the MM code is invalidating a range of pages, it calls the KVM
kvm_mmu_notifier_invalidate_range_start() notifier function, which calls
kvm_unmap_hva_range(), which arranges to flush all the TLBs for guest pages.
However, the Linux PTEs for the range being flushed are still valid at
that point. We are not supposed to establish any new references to pages
in the range until the ...range_end() notifier gets called.
The PPC-specific KVM code doesn't get any explicit notification of that;
instead, we are supposed to use mmu_notifier_retry() to test whether we
are or have been inside a range flush notifier pair while we have been
referencing a page.
This patch calls the mmu_notifier_retry() while mapping the guest
page to ensure we are not referencing a page when in range invalidation.
This call is inside a region locked with kvm->mmu_lock, which is the
same lock that is called by the KVM MMU notifier functions, thus
ensuring that no new notification can proceed while we are in the
locked region.
Paul Mackerras [Fri, 20 Sep 2013 23:53:28 +0000 (09:53 +1000)]
KVM: PPC: Book3S HV: Fix typo in saving DSCR
This fixes a typo in the code that saves the guest DSCR (Data Stream
Control Register) into the kvm_vcpu_arch struct on guest exit. The
effect of the typo was that the DSCR value was saved in the wrong place,
so changes to the DSCR by the guest didn't persist across guest exit
and entry, and some host kernel memory got corrupted.
Gleb Natapov [Wed, 9 Oct 2013 16:13:19 +0000 (19:13 +0300)]
KVM: nVMX: fix shadow on EPT
72f857950f6f19 broke shadow on EPT. This patch reverts it and fixes PAE
on nEPT (which reverted commit fixed) in other way.
Shadow on EPT is now broken because while L1 builds shadow page table
for L2 (which is PAE while L2 is in real mode) it never loads L2's
GUEST_PDPTR[0-3]. They do not need to be loaded because without nested
virtualization HW does this during guest entry if EPT is disabled,
but in our case L0 emulates L2's vmentry while EPT is enables, so we
cannot rely on vmcs12->guest_pdptr[0-3] to contain up-to-date values
and need to re-read PDPTEs from L2 memory. This is what kvm_set_cr3()
is doing, but by clearing cache bits during L2 vmentry we drop values
that kvm_set_cr3() read from memory.
So why the same code does not work for PAE on nEPT? kvm_set_cr3()
reads pdptes into vcpu->arch.walk_mmu->pdptrs[]. walk_mmu points to
vcpu->arch.nested_mmu while nested guest is running, but ept_load_pdptrs()
uses vcpu->arch.mmu which contain incorrect values. Fix that by using
walk_mmu in ept_(load|save)_pdptrs.
Initially commit cb527ede1bf6ff2008a025606f25344b8ed7b4ac
"i2c-omap: Double clear of ARDY status in IRQ handler"
added a workaround for undocumented errata ProDB0017052.
But then commit 1d7afc95946487945cc7f5019b41255b72224b70
"i2c: omap: ack IRQ in parts" refactored code and missed
one of ARDY clearings. So current code violates errata.
It causes often i2c bus timeouts on my Pandaboard.
Jean Delvare [Thu, 10 Oct 2013 06:04:06 +0000 (08:04 +0200)]
i2c: Not all adapters have a parent
The code in acpi_i2c_register_devices() assumes that all i2c adapters
have a parent. This is not necessarily the case, for example the
i2c-stub driver instantiate a virtual i2c adapter without a parent.
Check for this to avoid a NULL pointer deference.
Wolfram Sang [Tue, 8 Oct 2013 20:35:36 +0000 (22:35 +0200)]
i2c: i2c-stu300: replace platform_driver_probe to support deferred probing
Subsystems like pinctrl and gpio rightfully make use of deferred probing at
core level. Now, deferred drivers won't be retried if they don't have a .probe
function specified in the driver struct. Fix this driver to have that, so the
devices it supports won't get lost in a deferred probe.
Wolfram Sang [Tue, 8 Oct 2013 20:35:35 +0000 (22:35 +0200)]
i2c: i2c-mxs: replace platform_driver_probe to support deferred probing
Subsystems like pinctrl and gpio rightfully make use of deferred probing at
core level. Now, deferred drivers won't be retried if they don't have a .probe
function specified in the driver struct. Fix this driver to have that, so the
devices it supports won't get lost in a deferred probe.
Wolfram Sang [Tue, 8 Oct 2013 20:35:34 +0000 (22:35 +0200)]
i2c: i2c-imx: replace platform_driver_probe to support deferred probing
Subsystems like pinctrl and gpio rightfully make use of deferred probing at
core level. Now, deferred drivers won't be retried if they don't have a .probe
function specified in the driver struct. Fix this driver to have that, so the
devices it supports won't get lost in a deferred probe.
Wolfram Sang [Tue, 8 Oct 2013 20:35:33 +0000 (22:35 +0200)]
i2c: i2c-designware-platdrv: replace platform_driver_probe to support deferred probing
Subsystems like pinctrl and gpio rightfully make use of deferred probing at
core level. Now, deferred drivers won't be retried if they don't have a .probe
function specified in the driver struct. Fix this driver to have that, so the
devices it supports won't get lost in a deferred probe.
Haswell LynxPoint and LynxPoint-LP with the recent Intel BIOS show
mysterious wakeups after shutdown occasionally. After discussing with
BIOS engineers, they explained that the new BIOS expects that the
wakeup sources are cleared and set to D3 for all wakeup devices when
the system is going to sleep or power off, but the current xhci driver
doesn't do this properly (partly intentionally).
This patch introduces a new quirk, XHCI_SPURIOUS_WAKEUP, for
fixing the spurious wakeups at S5 by calling xhci_reset() in the xhci
shutdown ops as done in xhci_stop(), and setting the device to PCI D3
at shutdown and remove ops.
The PCI D3 call is based on the initial fix patch by Oliver Neukum.
[Note: Sarah changed the quirk name from XHCI_HSW_SPURIOUS_WAKEUP to
XHCI_SPURIOUS_WAKEUP, since none of the other quirks have system names
in them. Sarah also fixed a collision with a quirk submitted around the
same time, by changing the xhci->quirks bit from 17 to 18.]
This patch should be backported to kernels as old as 3.0, that
contain the commit 1c12443ab8eba71a658fae4572147e56d1f84f66 "xhci: Add
Lynx Point to list of Intel switchable hosts."
xhci: fix write to USB3_PSSEN and XUSB2PRM pci config registers
The function pci_write_config_dword() sets the appropriate byteordering
internally so the value argument should not be converted to little-endian.
This bug was found by sparse.
This patch is not suitable for stable. Since cpu_to_lei32 is a no-op on
little endian systems, this bug would only affect big endian Intel
systems with the EHCI to xHCI port switchover, which are non-existent,
AFAIK.
Oliver Neukum [Mon, 30 Sep 2013 13:50:54 +0000 (15:50 +0200)]
xhci: quirk for extra long delay for S4
It has been reported that this chipset really cannot
sleep without this extraordinary delay.
This patch should be backported, in order to ensure this host functions
under stable kernels. The last quirk for Fresco Logic hosts (commit bba18e33f25072ebf70fd8f7f0cdbf8cdb59a746 "xhci: Extend Fresco Logic MSI
quirk.") was backported to stable kernels as old as 2.6.36.
Sarah Sharp [Mon, 5 Aug 2013 20:36:00 +0000 (13:36 -0700)]
xhci: Don't enable/disable RWE on bus suspend/resume.
The RWE bit of the USB 2.0 PORTPMSC register is supposed to enable
remote wakeup for devices in the lower power link state L1. It has
nothing to do with the device suspend remote wakeup from L2. The RWE
bit is designed to be set once (when USB 2.0 LPM is enabled for the
port) and cleared only when USB 2.0 LPM is disabled for the port.
The xHCI bus suspend method was setting the RWE bit erroneously, and the
bus resume method was clearing it. The xHCI 1.0 specification with
errata up to Aug 12, 2012 says in section 4.23.5.1.1.1 "Hardware
Controlled LPM":
"While Hardware USB2 LPM is enabled, software shall not modify the
HIRDBESL or RWE fields of the USB2 PORTPMSC register..."
If we have previously enabled USB 2.0 LPM for a device, that means when
the USB 2.0 bus is resumed, we violate the xHCI specification by
clearing RWE. It also means that after a bus resume, the host would
think remote wakeup is disabled from L1 for ports with USB 2.0 Link PM
enabled, which is not what we want.
This patch should be backported to kernels as old as 3.2, that
contain the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set
USB2 hardware LPM". That was the first kernel that supported USB 2.0
Link PM.
Dan Carpenter [Sat, 28 Sep 2013 09:35:31 +0000 (12:35 +0300)]
drm/radeon/dpm: off by one in si_set_mc_special_registers()
These checks should be ">=" instead of ">". j is used as an offset into
the table->mc_reg_address[] array and that has
SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE (16) elements.
Alex Deucher [Fri, 27 Sep 2013 22:22:15 +0000 (18:22 -0400)]
drm/radeon: use hw generated CTS/N values for audio
Use the hw generated values rather than calculating
them in the driver. There may be some older r6xx
asics where this doesn't work correctly. This remains
to be seen.
See bug:
https://bugs.freedesktop.org/show_bug.cgi?id=69675
Henrik Rydberg [Wed, 2 Oct 2013 17:15:03 +0000 (19:15 +0200)]
hwmon: (applesmc) Always read until end of data
The crash reported and investigated in commit 5f4513 turned out to be
caused by a change to the read interface on newer (2012) SMCs.
Tests by Chris show that simply reading the data valid line is enough
for the problem to go away. Additional tests show that the newer SMCs
no longer wait for the number of requested bytes, but start sending
data right away. Apparently the number of bytes to read is no longer
specified as before, but instead found out by reading until end of
data. Failure to read until end of data confuses the state machine,
which eventually causes the crash.
As a remedy, assuming bit0 is the read valid line, make sure there is
nothing more to read before leaving the read function.
Tested to resolve the original problem, and runtested on MBA3,1,
MBP4,1, MBP8,2, MBP10,1, MBP10,2. The patch seems to have no effect on
machines before 2012.
The e-mail address [email protected] that I have been using for quite some
time is going to expire at one point, so replace it with a new one, [email protected], everywhere in MAINTAINERS and Documentation/ABI.
ARM: OMAP2: RX-51: Add missing max_current to rx51_lp5523_led_config
File drivers/leds/leds-lp55xx-common.c refuse to change led_current sysfs
attribute if value is higher than max_current specified in board file. By default
global C variables are zero, so changing always failed. This patch adding missing
max_current and setting it to max safe value 100 (10 mA).
It is unclear which commit exactly caused this regression as the lp5523
driver was broken and was hiding the platform data breakage. Now
the driver is fixed so this should be fixed as well.
Simon Barth [Tue, 8 Oct 2013 08:50:33 +0000 (10:50 +0200)]
ARM: mach-omap2: board-generic: fix undefined symbol
Since dra7 reuses the function 'omap5_realtime_timer_init' in
arch/arm/mach-omap2/board-generic.c as timer init function, it has to be
built for this SoC as well.
Tony Lindgren [Mon, 7 Oct 2013 17:22:01 +0000 (10:22 -0700)]
ARM: dts: Fix pinctrl mask for omap3
The wake-up interrupt bit is available on omap3/4/5 processors
unlike what we claim. Without fixing it we cannot use it on
omap3 and the system configured for wake-up events will just
hang on wake-up.
Nishanth Menon [Mon, 7 Oct 2013 20:43:49 +0000 (15:43 -0500)]
ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
SoC family definitions at the moment are reactive to board needs
as a result, beagle-xm would matchup with ti,omap3 which invokes
omap3430_init_early instead of omap3630_init_early. Obviously, this is
the wrong behavior.
With clock node dts conversion, we get the following warnings before
system hangs as a result and 3630 based platforms fails to boot
(uart4 clocks are only present in OMAP3630 and not present in
OMAP3430):
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: timer12: enabled state can only be entered from
initialized, idle, or disabled state
...
WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224
_idle+0xd4/0xf8()
omap_hwmod: timer12: idle state can only be entered from enabled state
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: uart4: enabled state can only be entered from
initialized, idle, or disabled state
So, add specific compatiblity for 3630 to allow match for Beagle-XM
platform.
Linus Torvalds [Tue, 8 Oct 2013 16:23:12 +0000 (09:23 -0700)]
Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf fixes from Ingo Molnar:
"Various fixlets:
On the kernel side:
- fix a race
- fix a bug in the handling of the perf ring-buffer data page
On the tooling side:
- fix the handling of certain corrupted perf.data files
- fix a bug in 'perf probe'
- fix a bug in 'perf record + perf sched'
- fix a bug in 'make install'
- fix a bug in libaudit feature-detection on certain distros"
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf session: Fix infinite loop on invalid perf.data file
perf tools: Fix installation of libexec components
perf probe: Fix to find line information for probe list
perf tools: Fix libaudit test
perf stat: Set child_pid after perf_evlist__prepare_workload()
perf tools: Add default handler for mmap2 events
perf/x86: Clean up cap_user_time* setting
perf: Fix perf_pmu_migrate_context
Currently hdmi_setup_audio_infoframe() reprograms the HDA channel
mapping only when the infoframe is not up-to-date or the non-PCM flag
has changed.
However, when just the channel map has been changed, the infoframe may
still be up-to-date and non-PCM flag may not have changed, so the new
channel map is not actually programmed into the HDA codec.
Notably, this failing case is also always triggered when the device is
already in a prepared state and a new channel map is configured while
changing only the channel positions (for example, plain
"speaker-test -c2 -m FR,FL").
Fix that by always programming the channel map in
hdmi_setup_audio_infoframe(). Tested on Intel HDMI.
powerpc/irq: Don't switch to irq stack from softirq stack
irq_exit() is now called on the irq stack, which can trigger a switch to
the softirq stack from the irq stack. If an interrupt happens at that
point, we will not properly detect the re-entrancy and clobber the
original return context on the irq stack.
This fixes it. The side effect is to prevent all nesting from softirq
stack to irq stack even in the "safe" case but it's simpler that way and
matches what x86_64 does.
Linus Torvalds [Mon, 7 Oct 2013 16:30:36 +0000 (09:30 -0700)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid
Pull HID fixes from Jiri Kosina:
- fix for hidraw reference counting regression, by Manoj Chourasia
- fix for minor number allocation for uhid, by David Herrmann
- other small unsorted fixes / device ID additions
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: wiimote: fix FF deadlock
HID: add Holtek USB ID 04d9:a081 SHARKOON DarkGlider
HID: hidraw: close underlying device at removal of last reader
HID: roccat: Fix "cannot create duplicate filename" problems
HID: uhid: allocate static minor
Linus Torvalds [Mon, 7 Oct 2013 16:30:02 +0000 (09:30 -0700)]
Merge branch 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile
Pull Tile bugfixes from Chris Metcalf:
"This fixes some serious issues with PREEMPT support, and a couple of
smaller corner-case issues fixed in the last couple of weeks"
* 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
arch: tile: re-use kbasename() helper
tile: use a more conservative __my_cpu_offset in CONFIG_PREEMPT
tile: ensure interrupts disabled for preempt_schedule_irq()
tile: change lock initalization in hardwall
tile: include: asm: use 'long long' instead of 'u64' for atomic64_t and its related functions
David Herrmann [Wed, 2 Oct 2013 11:47:28 +0000 (13:47 +0200)]
HID: wiimote: fix FF deadlock
The input core has an internal spinlock that is acquired during event
injection via input_event() and friends but also held during FF callbacks.
That means, there is no way to share a lock between event-injection and FF
handling. Unfortunately, this is what is required for wiimote state
tracking and what we do with state.lock and input->lock.
This deadlock can be triggered when using continuous data reporting and FF
on a wiimote device at the same time. I takes me at least 30m of
stress-testing to trigger it but users reported considerably shorter
times (http://bpaste.net/show/132504/) when using some gaming-console
emulators.
The real problem is that we have two copies of internal state, one in the
wiimote objects and the other in the input device. As the input-lock is
not supposed to be accessed from outside of input-core, we have no other
chance than offloading FF handling into a worker. This actually works
pretty nice and also allows to implictly merge fast rumble changes into a
single request.
Due to the 3-layered workers (rumble+queue+l2cap) this might reduce FF
responsiveness. Initial tests were fine so lets fix the race first and if
it turns out to be too slow we can always handle FF out-of-band and skip
the queue-worker.
This allows users to use LANMAN authentication on servers which support
unencapsulated authentication.
The patch fixes a regression where users using plaintext authentication
were no longer able to do so because of changed bought in by patch 3f618223dc0bdcbc8d510350e78ee2195ff93768
Jan Klos [Sun, 6 Oct 2013 19:08:20 +0000 (21:08 +0200)]
cifs: Fix inability to write files >2GB to SMB2/3 shares
When connecting to SMB2/3 shares, maximum file size is set to non-LFS maximum in superblock. This is due to cap_large_files bit being different for SMB1 and SMB2/3 (where it is just an internal flag that is not negotiated and the SMB1 one corresponds to multichannel capability, so maybe LFS works correctly if server sends 0x08 flag) while capabilities are checked always for the SMB1 bit in cifs_read_super().
The patch fixes this by checking for the correct bit according to the protocol version.
James Hogan [Mon, 7 Oct 2013 11:14:26 +0000 (12:14 +0100)]
MIPS: stack protector: Fix per-task canary switch
Commit 1400eb6 (MIPS: r4k,octeon,r2300: stack protector: change canary
per task) was merged in v3.11 and introduced assembly in the MIPS resume
functions to update the value of the current canary in
__stack_chk_guard. However it used PTR_L resulting in a load of the
canary value, instead of PTR_LA to construct its address. The value is
intended to be random but is then treated as an address in the
subsequent LONG_S (store).
This can also be forced by modifying
arch/mips/include/asm/stackprotector.h so that the default
__stack_chk_guard value is more likely to be a bad (or unaligned)
pointer.
Fix it to use PTR_LA instead, to load the address of the canary value,
which the LONG_S can then use to write into it.
Linus Torvalds [Mon, 7 Oct 2013 08:13:26 +0000 (01:13 -0700)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 fixes from Martin Schwidefsky:
"A couple of bux fixes, notable are the regression with ptrace vs
restarting system calls and the patch for kdump to be able to copy
from virtual memory"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390: fix system call restart after inferior call
s390: Allow vmalloc target buffers for copy_from_oldmem()
s390/sclp: properly detect line mode console
s390/kprobes: add exrl to list of prohibited opcodes
s390/3270: fix return value check in tty3270_resize_work()
w1 - call request_module with w1 master mutex unlocked
request_module for w1 slave modules needs to be called with the w1
master mutex unlocked. Because w1_attach_slave_device gets always(?)
called with mutex locked, we need to temporarily unlock the w1 master
mutex for the loading of the w1 slave module.
Deng-Cheng Zhu [Sun, 6 Oct 2013 06:08:17 +0000 (23:08 -0700)]
USB/host: Bugfix: Return length of copied buffer in uhci_hub_control()
In addition to the error statuses -ETIMEDOUT and -EPIPE, uhci_hub_control()
needs to return the length of copied buffer when appropriate, so that the
returned status of ->hub_control() in rh_call_control() in the USB core
HCD can be properly handled.
This patch also removes the OK() macro to make the code more readable.
projects / linux.git / log