- 22 Feb, 2014 40 commits
-
-
NeilBrown authored
commit 1877db75 upstream. commit 30bc9b53 md/raid1: fix bio handling problems in process_checks() Move the bio_reset() to a point before where BIO_UPTODATE is checked, so that check now always report that the bio is uptodate, even if it is not. This causes process_check() to sometimes treat read-errors as successful matches so the good data isn't written out. This patch preserves the flag until it is needed. Bug was introduced in 3.11, but backported to 3.10-stable (as it fixed an even worse bug). So suitable for any -stable since 3.10. Reported-and-tested-by:
Michael Tokarev <mjt@tls.msk.ru> Fixed: 30bc9b53Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Thomas Gleixner authored
commit dd5fd9b9 upstream. AMD systems which use the C1E workaround in the amd_e400_idle routine trigger the WARN_ON_ONCE in the broadcast code when onlining a CPU. The reason is that the idle routine of those AMD systems switches the cpu into forced broadcast mode early on before the newly brought up CPU can switch over to high resolution / NOHZ mode. The timer related CPU1 bringup looks like this: clockevent_register_device(local_apic); tick_setup(local_apic); ... idle() tick_broadcast_on_off(FORCE); tick_broadcast_oneshot_control(ENTER) cpumask_set(cpu, broadcast_oneshot_mask); halt(); Now the broadcast interrupt on CPU0 sets CPU1 in the broadcast_pending_mask and wakes CPU1. So CPU1 continues: local_apic_timer_interrupt() tick_handle_periodic(); softirq() tick_init_highres(); cpumask_clr(cpu, broadcast_oneshot_mask); tick_broadcast_oneshot_control(ENTER) WARN_ON(cpumask_test(cpu, broadcast_pending_mask); So while we remove CPU1 from the broadcast_oneshot_mask when we switch over to highres mode, we do not clear the pending bit, which then triggers the warning when we go back to idle. The reason why this is only visible on C1E affected AMD systems is that the other machines enter the deep sleep states via acpi_idle/intel_idle and exit the broadcast mode before executing the remote triggered local_apic_timer_interrupt. So the pending bit is already cleared when the switch over to highres mode is clearing the oneshot mask. The solution is simple: Clear the pending bit together with the mask bit when we switch over to highres mode. Stanislaw came up independently with the same patch by enforcing the C1E workaround and debugging the fallout. I picked mine, because mine has a changelog :) Reported-by:
poma <pomidorabelisima@gmail.com> Debugged-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Olaf Hering <olaf@aepfle.de> Cc: Dave Jones <davej@redhat.com> Cc: Justin M. Forbes <jforbes@redhat.com> Cc: Josh Boyer <jwboyer@redhat.com> Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1402111434180.21991@ionos.tec.linutronix.deSigned-off-by:
-
Dan Carpenter authored
commit aac5c422 upstream. If kvm_io_bus_register_dev() fails then it returns success but it should return an error code. I also did a little cleanup like removing an impossible NULL test. Fixes: 2b3c246a ('KVM: Make coalesced mmio use a device per zone') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Mike Marciniszyn authored
commit 2f75e12c upstream. Research has shown that commit a77fcf89 ("IB/qib: Use a single txselect module parameter for serdes tuning") missed a key serdes init sequence. This patch add that sequence. Reviewed-by:
Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by:
Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Steven Noonan authored
commit a9f18034 upstream. I started noticing problems with KVM guest destruction on Linux 3.12+, where guest memory wasn't being cleaned up. I bisected it down to the commit introducing the new 'asm goto'-based atomics, and found this quirk was later applied to those. Unfortunately, even with GCC 4.8.2 (which ostensibly fixed the known 'asm goto' bug) I am still getting some kind of miscompilation. If I enable the asm_volatile_goto quirk for my compiler, KVM guests are destroyed correctly and the memory is cleaned up. So make the quirk unconditional for now, until bug is found and fixed. Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Steven Noonan <steven@uplinklabs.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Jakub Jelinek <jakub@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Oleg Nesterov <oleg@redhat.com> Link: http://lkml.kernel.org/r/1392274867-15236-1-git-send-email-steven@uplinklabs.net Link: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Jens Axboe authored
commit c8123f8c upstream. When mkfs issues a full device discard and the device only supports discards of a smallish size, we can loop in blkdev_issue_discard() for a long time. If preempt isn't enabled, this can turn into a softlock situation and the kernel will start complaining. Add an explicit cond_resched() at the end of the loop to avoid that. Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Martin K. Petersen authored
commit 08778795 upstream. Commit 9f060e22 changed the way we handle allocations for the integrity vectors. When the vectors are inline there is no associated slab and consequently bvec_nr_vecs() returns 0. Ensure that we check against BIP_INLINE_VECS in that case. Reported-by:
David Milburn <dmilburn@redhat.com> Tested-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Tejun Heo authored
commit 556ee818 upstream. request_queue bypassing is used to suppress higher-level function of a request_queue so that they can be switched, reconfigured and shut down. A request_queue does the followings while bypassing. * bypasses elevator and io_cq association and queues requests directly to the FIFO dispatch queue. * bypasses block cgroup request_list lookup and always uses the root request_list. Once confirmed to be bypassing, specific elevator and block cgroup policy implementations can assume that nothing is in flight for them and perform various operations which would be dangerous otherwise. Such confirmation is acheived by short-circuiting all new requests directly to the dispatch queue and waiting for all the requests which were issued before to finish. Unfortunately, while the request allocating and draining sides were properly handled, we forgot to actually plug the request dispatch path. Even after bypassing mode is confirmed, if the attached driver tries to fetch a request and the dispatch queue is empty, __elv_next_request() would invoke the current elevator's elevator_dispatch_fn() callback. As all in-flight requests were drained, the elevator wouldn't contain any request but once bypass is confirmed we don't even know whether the elevator is even there. It might be in the process of being switched and half torn down. Frank Mayhar reports that this actually happened while switching elevators, leading to an oops. Let's fix it by making __elv_next_request() avoid invoking the elevator_dispatch_fn() callback if the queue is bypassing. It already avoids invoking the callback if the queue is dying. As a dying queue is guaranteed to be bypassing, we can simply replace blk_queue_dying() check with blk_queue_bypass(). Reported-by:
Frank Mayhar <fmayhar@google.com> References: http://lkml.kernel.org/g/1390319905.20232.38.camel@bobble.lax.corp.google.comTested-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Jan Moskyto Matejka authored
commit 03b56329 upstream. Commit afe2dab4 ("USB: add hex/bcd detection to usb modalias generation") changed the routine that generates alias ranges. Before that change, only digits 0-9 were supported; the commit tried to fix the case when the range includes higher values than 0x9. Unfortunately, the commit didn't fix the case when the range includes both 0x9 and 0xA, meaning that the final range must look like [x-9A-y] where x <= 0x9 and y >= 0xA -- instead the [x-9A-x] range was produced. Modprobe doesn't complain as it sees no difference between no-match and bad-pattern results of fnmatch(). Fixing this simple bug to fix the aliases. Also changing the hardcoded beginning of the range to uppercase as all the other letters are also uppercase in the device version numbers. Fortunately, this affects only the dvb-usb-dib0700 module, AFAIK. Signed-off-by:
Jan Moskyto Matejka <mq@suse.cz> Signed-off-by:
-
Sarah Sharp authored
commit 140e3026 upstream. Commit 9df89d85 "usbcore: set lpm_capable field for LPM capable root hubs" was created under the assumption that all USB host controllers should have USB 3.0 Link PM enabled for all devices under the hosts. Unfortunately, that's not the case. The xHCI driver relies on knowledge of the host hardware scheduler to calculate the LPM U1/U2 timeout values, and it only sets lpm_capable to one for Intel host controllers (that have the XHCI_LPM_SUPPORT quirk set). When LPM is enabled for some Fresco Logic hosts, it causes failures with a AgeStar 3UBT USB 3.0 hard drive dock: Jan 11 13:59:03 sg-laptop kernel: usb 3-1: new SuperSpeed USB device number 2 using xhci_hcd Jan 11 13:59:03 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U1 failed. Jan 11 13:59:08 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U2 failed. Jan 11 13:59:08 sg-laptop kernel: usb-storage 3-1:1.0: USB Mass Storage device detected Jan 11 13:59:08 sg-laptop mtp-probe[613]: checking bus 3, device 2: "/sys/devices/pci0000:00/0000:00:1c.3/0000:04:00.0/usb3/3-1" Jan 11 13:59:08 sg-laptop mtp-probe[613]: bus: 3, device: 2 was not an MTP device Jan 11 13:59:08 sg-laptop kernel: scsi6 : usb-storage 3-1:1.0 Jan 11 13:59:13 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U1 failed. Jan 11 13:59:18 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U2 failed. Jan 11 13:59:18 sg-laptop kernel: usbcore: registered new interface driver usb-storage Jan 11 13:59:40 sg-laptop kernel: usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd Jan 11 13:59:41 sg-laptop kernel: usb 3-1: device descriptor read/8, error -71 Jan 11 13:59:41 sg-laptop kernel: usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd Jan 11 13:59:46 sg-laptop kernel: usb 3-1: device descriptor read/8, error -110 Jan 11 13:59:46 sg-laptop kernel: scsi 6:0:0:0: Device offlined - not ready after error recovery Jan 11 13:59:46 sg-laptop kernel: usb 3-1: USB disconnect, device number 2 lspci for the affected host: 04:00.0 0c03: 1b73:1000 (rev 04) (prog-if 30 [XHCI]) Subsystem: 1043:1039 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 19 Region 0: Memory at dd200000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [80] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <2us, L1 <32us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Kernel driver in use: xhci_hcd Kernel modules: xhci_hcd The commit was backported to stable kernels, and will need to be reverted there as well. Signed-off-by:
Sarah Sharp <sarah.a.sharp@intel.com> Reported-by:
Sergey Galanov <sergey.e.galanov@gmail.com> Signed-off-by:
-
Raymond Wanyoike authored
commit 3635c7e2 upstream. Interface #5 of 19d2:1270 is a net interface which has been submitted to the qmi_wwan driver so consequently remove it from the option driver. Signed-off-by:
Raymond Wanyoike <raymond.wanyoike@gmail.com> Signed-off-by:
-
Alan Stern authored
commit 823d12c9 upstream. People sometimes create their own custom-configured kernels and forget to enable CONFIG_SCSI_MULTI_LUN. This causes problems when they plug in a USB storage device (such as a card reader) with more than one LUN. Fortunately, we can tell fairly easily when a storage device claims to have more than one LUN. When that happens, this patch asks the SCSI layer to probe all the LUNs automatically, regardless of the config setting. The patch also updates the Kconfig help text for usb-storage, explaining that CONFIG_SCSI_MULTI_LUN may be necessary. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Thomas Raschbacher <lordvan@lordvan.com> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> CC: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
-
Alan Stern authored
commit a9c143c8 upstream. The Cypress ATACB unusual-devs entry for the Super Top SATA bridge causes problems. Although it was originally reported only for bcdDevice = 0x160, its range was much larger. This resulted in a bug report for bcdDevice 0x220, so the range was capped at 0x219. Now Milan reports errors with bcdDevice 0x150. Therefore this patch restricts the range to just 0x160. Signed-off-by:
Milan Svoboda <milan.svoboda@centrum.cz> Signed-off-by:
-
Alan Stern authored
commit c5637e51 upstream. This patch adds an unusual-devs entry for the BlackBerry 9000. This fixes Bugzilla #22442. Signed-off-by:
Moritz Moeller-Herrmann <moritz-kernel@moeller-herrmann.de> Tested-by:
-
Ulrich Hahn authored
commit 76f24e3f upstream. Adding two more IDs to the ftdi_sio usb serial driver. It now connects Tagsys RFID readers. There might be more IDs out there for other Tagsys models. Signed-off-by:
Ulrich Hahn <uhahn@eanco.de> Cc: Johan Hovold <johan@hovold.com> Signed-off-by:
-
Bjørn Mork authored
commit 67847bae upstream. Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
K. Y. Srinivasan authored
commit 269f9794 upstream. When the guest attempts to connect with the host when there may already be a connection with the host (as would be the case during the kdump/kexec path), it is difficult to guarantee timely response from the host. Starting with WS2012 R2, the host supports this ability to re-connect with the host (explicitly to support kexec). Prior to responding to the guest, the host needs to ensure that device states based on the previous connection to the host have been properly torn down. This may introduce unbounded delays. To deal with this issue, don't do a timed wait during the initial connect with the host. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Martyn Welch authored
commit f0342e66 upstream. In order to ensure the correct width cycles on the VME bus, the VME bridge drivers implement an algorithm to utilise the largest possible width reads and writes whilst maintaining natural alignment constraints. The algorithm currently looks at the start address rather than the current read/write address when determining whether a 16-bit width cycle is required to get to 32-bit alignment. This results in incorrect alignment, Reported-by:
Jim Strouth <james.strouth@ge.com> Tested-by:
Martyn Welch <martyn.welch@ge.com> Signed-off-by:
-
Alexander Usyskin authored
commit 5cb906c7 upstream. Don't set read callback to NULL during reset as this leads to memory leak of both cb and its buffer. The memory is correctly freed during mei_release. The memory leak is detectable by kmemleak if application has open read call while system is going through suspend/resume. unreferenced object 0xecead780 (size 64): comm "AsyncTask #1", pid 1018, jiffies 4294949621 (age 152.440s) hex dump (first 32 bytes): 00 01 10 00 00 02 20 00 00 bf 30 f1 00 00 00 00 ...... ...0..... 00 00 00 00 00 00 00 00 36 01 00 00 00 70 da e2 ........6....p.. backtrace: [<c1a60aec>] kmemleak_alloc+0x3c/0xa0 [<c131ed56>] kmem_cache_alloc_trace+0xc6/0x190 [<c16243c9>] mei_io_cb_init+0x29/0x50 [<c1625722>] mei_cl_read_start+0x102/0x360 [<c16268f3>] mei_read+0x103/0x4e0 [<c1324b09>] vfs_read+0x89/0x160 [<c1324d5f>] SyS_read+0x4f/0x80 [<c1a7b318>] syscall_call+0x7/0xb [<ffffffff>] 0xffffffff unreferenced object 0xe2da7000 (size 512): comm "AsyncTask #1", pid 1018, jiffies 4294949621 (age 152.440s) hex dump (first 32 bytes): 00 6c da e2 7c 00 00 00 00 00 00 00 c0 eb 0c 59 .l..|..........Y 1b 00 00 00 01 00 00 00 02 10 00 00 01 00 00 00 ................ backtrace: [<c1a60aec>] kmemleak_alloc+0x3c/0xa0 [<c131f127>] __kmalloc+0xe7/0x1d0 [<c162447e>] mei_io_cb_alloc_resp_buf+0x2e/0x60 [<c162574c>] mei_cl_read_start+0x12c/0x360 [<c16268f3>] mei_read+0x103/0x4e0 [<c1324b09>] vfs_read+0x89/0x160 [<c1324d5f>] SyS_read+0x4f/0x80 [<c1a7b318>] syscall_call+0x7/0xb [<ffffffff>] 0xffffffff Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Alexander Usyskin authored
commit 30c54df7 upstream. Clear write callbacks sitting in write_waiting list on reset. Otherwise these callbacks are left dangling and cause memory leak. Signed-off-by:
-
Takashi Iwai authored
commit f88abaa0 upstream. The very same fixup is needed to make the mic on Sony VAIO Pro 11 working as well as VAIO Pro 13 model. Reported-and-tested-by:
Hendrik-Jan Heins <hjheins@gmail.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit 87fbb2ac upstream. When the conversion was made to remove stop machine and use the breakpoint logic instead, the modification of the function graph caller is still done directly as though it was being done under stop machine. As it is not converted via stop machine anymore, there is a possibility that the code could be layed across cache lines and if another CPU is accessing that function graph call when it is being updated, it could cause a General Protection Fault. Convert the update of the function graph caller to use the breakpoint method as well. Cc: H. Peter Anvin <hpa@zytor.com> Fixes: 08d636b6 "ftrace/x86: Have arch x86_64 use breakpoints instead of stop machine" Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
H. Peter Anvin authored
commit 4640c7ee upstream. If CONFIG_X86_SMAP is disabled, smap_violation() tests for conditions which are incorrect (as the AC flag doesn't matter), causing spurious faults. The dynamic disabling of SMAP (nosmap on the command line) is fine because it disables X86_FEATURE_SMAP, therefore causing the static_cpu_has() to return false. Found by Fengguang Wu's test system. [ v3: move all predicates into smap_violation() ] [ v2: use IS_ENABLED() instead of #ifdef ] Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Link: http://lkml.kernel.org/r/20140213124550.GA30497@localhostSigned-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
H. Peter Anvin authored
commit 03bbd596 upstream. If SMAP support is not compiled into the kernel, don't enable SMAP in CR4 -- in fact, we should clear it, because the kernel doesn't contain the proper STAC/CLAC instructions for SMAP support. Found by Fengguang Wu's test system. Reported-by:
-
Marcus Folkesson authored
commit c76782d1 upstream. This is necessary since timestamp is calculated as the last element in iio_compute_scan_bytes(). Without this fix any userspace code reading the layout of the buffer via sysfs will incorrectly interpret the data leading some nasty corruption. Signed-off-by:
Marcus Folkesson <marcus.folkesson@gmail.com> Acked-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Hartmut Knaack authored
commit 38408d05 upstream. Only free an IRQ in error_free_irq, if it has been requested previously. Signed-off-by:
Hartmut Knaack <knaack.h@gmx.de> Acked-by:
-
H Hartley Sweeten authored
commit 1e85c1ea upstream. The last value written to a analog output channel is cached in the private data of this driver for readback. Currently, the wrong value is cached in the (*insn_write) functions. The current code stores the data[n] value for readback afer the loop has written all the values. At this time 'n' points past the end of the data array. Fix the functions by using a local variable to hold the data being written to the analog output channel. This variable is then used after the loop is complete to store the readback value. The current value is retrieved before the loop in case no values are actually written.. Signed-off-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Reviewed-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Bjørn Mork authored
commit f948dcf9 upstream. This device was mentioned in an OpenWRT forum. Seems to have a "standard" Sierra Wireless ifnumber to function layout: 0: qcdm 2: nmea 3: modem 8: qmi 9: storage Signed-off-by:
-
Petr Písař authored
commit 0930b095 upstream. \E[3J console code (secure clear screen) needs to update_screen(vc) in order to write-through blanks into off-screen video memory. This has been removed accidentally in 3.6 by: commit 81732c3b Author: Jean-François Moine <moinejf@free.fr> Date: Thu Sep 6 19:24:13 2012 +0200 tty vt: Fix line garbage in virtual console on command line edition Signed-off-by:
Petr Písař <petr.pisar@atlas.cz> Signed-off-by:
-
Christian König authored
commit b927e1c2 upstream. Otherwise decoding isn't really useable. bug: https://bugs.freedesktop.org/show_bug.cgi?id=71448Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 858a41c8 upstream. Otherwise decoding isn't really useable. Signed-off-by:
-
Lars Poeschel authored
commit 3ac06b90 upstream. 3GPP TS 07.10 states in section 5.4.6.3.7: "The length byte contains the value 2 or 3 ... depending on the break signal." The break byte is optional and if it is sent, the length is 3. In fact the driver was not able to work with modems that send this break byte in their modem status control message. If the modem just sends the break byte if it is really set, then weird things might happen. The code for deconding the modem status to the internal linux presentation in gsm_process_modem has already a big comment about this 2 or 3 byte length thing and it is already able to decode the brk, but the code calling the gsm_process_modem function in gsm_control_modem does not encode it and hand it over the right way. This patch fixes this. Without this fix if the modem sends the brk byte in it's modem status control message the driver will hang when opening a muxed channel. Signed-off-by:
Lars Poeschel <poeschel@lemonage.de> Signed-off-by:
-
NeilBrown authored
commit 2ec197db upstream. If an NFS client attempts to get a lock (using NLM) and the lock is not available, the server will remember the request and when the lock becomes available it will send a GRANT request to the client to provide the lock. If the client already held an adjacent lock, the GRANT callback will report the union of the existing and new locks, which can confuse the client. This happens because __posix_lock_file (called by vfs_lock_file) updates the passed-in file_lock structure when adjacent or over-lapping locks are found. To avoid this problem we take a copy of the two fields that can be changed (fl_start and fl_end) before the call and restore them afterwards. An alternate would be to allocate a 'struct file_lock', initialise it, use locks_copy_lock() to take a copy, then locks_release_private() after the vfs_lock_file() call. But that is a lot more work. Reported-by:
Olaf Kirch <okir@suse.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Doug Anderson authored
commit d3d89c46 upstream. The ntc thermistor code was doing math whose temporary result might have overflowed 32-bits. We need some casts in there to make it safe. In one example I found: - pullup_uV: 1800000 - result of iio_read_channel_raw: 3226 - 1800000 * 3226 => 0x15a1cbc80 Signed-off-by:
Doug Anderson <dianders@chromium.org> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Paul Bolle authored
commit 5bbb2ae3 upstream. bind_get() checks the device number it is called with. It uses MAX_RAW_MINORS for the upper bound. But MAX_RAW_MINORS is set at compile time while the actual number of raw devices can be set at runtime. This means the test can either be too strict or too lenient. And if the test ends up being too lenient bind_get() might try to access memory beyond what was allocated for "raw_devices". So check against the runtime value (max_raw_minors) in this function. Signed-off-by:
Paul Bolle <pebolle@tiscali.nl> Acked-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Kleber Sacilotto de Souza authored
commit 14e2abb7 upstream. On IBM pseries systems the device_type device-tree property of a PCIe bridge contains the string "pciex". The of_bus_pci_match() function was looking only for "pci" on this property, so in such cases the bus matching code was falling back to the default bus, causing problems on functions that should be using "assigned-addresses" for region address translation. This patch fixes the problem by also looking for "pciex" on the PCI bus match function. v2: added comment Signed-off-by:
Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com> Acked-by:
Grant Likely <grant.likely@linaro.org> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Emmanuel Grumbach authored
commit 8e2a866e upstream. Not doing so will let BT kill our probe requests leading to failures in scan. Reviewed-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit b900a87b upstream. This can be useful to be able to spot the firmware version from the error reports without needing to fetch it from another place. Signed-off-by:
-
Emmanuel Grumbach authored
commit c5128654 upstream. The driver wasn't reading the NVM properly. While this didn't lead to any issue until now, it seems that there is an old version of the NVM in the wild. In this version, the A band channels appear to be valid but the SKU capabilities (another field of the NVM) says that A band isn't supported at all. With this specific version of the NVM, the driver would think that A band is supported while the HW / firmware don't. This leads to asserts. Reviewed-by:
-
Geert Uytterhoeven authored
commit 1f802f82 upstream. This reverts commit e120cc0d. It causes a NULL pointer dereference with drivers using the generic spi_transfer_one_message(), which always calls spi_finalize_current_message(), which zeroes master->cur_msg. Drivers implementing transfer_one_message() theirselves must always call spi_finalize_current_message(), even if the transfer failed: * @transfer_one_message: the subsystem calls the driver to transfer a single * message while queuing transfers that arrive in the meantime. When the * driver is finished with this message, it must call * spi_finalize_current_message() so the subsystem can issue the next * transfer Signed-off-by:
Geert Uytterhoeven <geert+renesas@linux-m68k.org> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
