- 03 Jan, 2014 40 commits
-
-
Daniel Borkmann authored
[ Upstream commit 51c37a70 ] For properly initialising the Tausworthe generator [1], we have a strict seeding requirement, that is, s1 > 1, s2 > 7, s3 > 15. Commit 697f8d03 ("random32: seeding improvement") introduced a __seed() function that imposes boundary checks proposed by the errata paper [2] to properly ensure above conditions. However, we're off by one, as the function is implemented as: "return (x < m) ? x + m : x;", and called with __seed(X, 1), __seed(X, 7), __seed(X, 15). Thus, an unwanted seed of 1, 7, 15 would be possible, whereas the lower boundary should actually be of at least 2, 8, 16, just as GSL does. Fix this, as otherwise an initialization with an unwanted seed could have the effect that Tausworthe's PRNG properties cannot not be ensured. Note that this PRNG is *not* used for cryptography in the kernel. [1] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme.ps [2] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme2.ps Joint work with Hannes Frederic Sowa. Fixes: 697f8d03 ("random32: seeding improvement") Cc: Stephen Hemminger <stephen@networkplumber.org> Cc: Florian Weimer <fweimer@redhat.com> Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Duan Jiong authored
[ Upstream commit f104a567 ] As the rfc 4191 said, the Router Preference and Lifetime values in a ::/0 Route Information Option should override the preference and lifetime values in the Router Advertisement header. But when the kernel deals with a ::/0 Route Information Option, the rt6_get_route_info() always return NULL, that means that overriding will not happen, because those default routers were added without flag RTF_ROUTEINFO in rt6_add_dflt_router(). In order to deal with that condition, we should call rt6_get_dflt_router when the prefix length is 0. Signed-off-by:
Duan Jiong <duanj.fnst@cn.fujitsu.com> Acked-by:
-
Andreas Henriksson authored
[ Upstream commit 13eb2ab2 ] When trying to delete a table >= 256 using iproute2 the local table will be deleted. The table id is specified as a netlink attribute when it needs more then 8 bits and iproute2 then sets the table field to RT_TABLE_UNSPEC (0). Preconditions to matching the table id in the rule delete code doesn't seem to take the "table id in netlink attribute" into condition so the frh_get_table helper function never gets to do its job when matching against current rule. Use the helper function twice instead of peaking at the table value directly. Originally reported at: http://bugs.debian.org/724783Reported-by:
Nicolas HICHER <nhicher@avencall.com> Signed-off-by:
Andreas Henriksson <andreas@fatal.se> Signed-off-by:
-
Sergei Trofimovich authored
commit fdfa4c95 upstream. arch/um/os-Linux/start_up.c: In function 'check_coredump_limit': arch/um/os-Linux/start_up.c:338:16: error: storage size of 'lim' isn't known arch/um/os-Linux/start_up.c:339:2: error: implicit declaration of function 'getrlimit' [-Werror=implicit-function-declaration] Signed-off-by:
Sergei Trofimovich <slyfox@gentoo.org> CC: Jeff Dike <jdike@addtoit.com> CC: Richard Weinberger <richard@nod.at> CC: Al Viro <viro@zeniv.linux.org.uk> CC: user-mode-linux-devel@lists.sourceforge.net CC: user-mode-linux-user@lists.sourceforge.net CC: linux-kernel@vger.kernel.org Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Ben Segall authored
commit f9f9ffc2 upstream. throttle_cfs_rq() doesn't check to make sure that period_timer is running, and while update_curr/assign_cfs_runtime does, a concurrently running period_timer on another cpu could cancel itself between this cpu's update_curr and throttle_cfs_rq(). If there are no other cfs_rqs running in the tg to restart the timer, this causes the cfs_rq to be stranded forever. Fix this by calling __start_cfs_bandwidth() in throttle if the timer is inactive. (Also add some sched_debug lines for cfs_bandwidth.) Tested: make a run/sleep task in a cgroup, loop switching the cgroup between 1ms/100ms quota and unlimited, checking for timer_active=0 and throttled=1 as a failure. With the throttle_cfs_rq() change commented out this fails, with the full patch it passes. Signed-off-by:
Ben Segall <bsegall@google.com> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Cc: pjt@google.com Link: http://lkml.kernel.org/r/20131016181632.22647.84174.stgit@sword-of-the-dawn.mtv.corp.google.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> [bwh: Backported to 3.2: adjust filenames] Signed-off-by:
-
Linus Pizunski authored
commit eb3c2272 upstream. Update month and day of month to the alarm month/day instead of current day/month when setting the RTC alarm mask. Signed-off-by:
Linus Pizunski <linus@narrativeteam.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Paul Moore authored
commit 446b8024 upstream. In selinux_ip_postroute() we perform access checks based on the packet's security label. For locally generated traffic we get the packet's security label from the associated socket; this works in all cases except for TCP SYN-ACK packets. In the case of SYN-ACK packet's the correct security label is stored in the connection's request_sock, not the server's socket. Unfortunately, at the point in time when selinux_ip_postroute() is called we can't query the request_sock directly, we need to recreate the label using the same logic that originally labeled the associated request_sock. See the inline comments for more explanation. Reported-by:
Janak Desai <Janak.Desai@gtri.gatech.edu> Tested-by:
Paul Moore <pmoore@redhat.com> Signed-off-by:
-
Paul Moore authored
commit 47180068 upstream. In selinux_ip_output() we always label packets based on the parent socket. While this approach works in almost all cases, it doesn't work in the case of TCP SYN-ACK packets when the correct label is not the label of the parent socket, but rather the label of the larval socket represented by the request_sock struct. Unfortunately, since the request_sock isn't queued on the parent socket until *after* the SYN-ACK packet is sent, we can't lookup the request_sock to determine the correct label for the packet; at this point in time the best we can do is simply pass/NF_ACCEPT the packet. It must be said that simply passing the packet without any explicit labeling action, while far from ideal, is not terrible as the SYN-ACK packet will inherit any IP option based labeling from the initial connection request so the label *should* be correct and all our access controls remain in place so we shouldn't have to worry about information leaks. Reported-by:
-
Andy Honig authored
commit b963a22e upstream. Under guest controllable circumstances apic_get_tmcct will execute a divide by zero and cause a crash. If the guest cpuid support tsc deadline timers and performs the following sequence of requests the host will crash. - Set the mode to periodic - Set the TMICT to 0 - Set the mode bits to 11 (neither periodic, nor one shot, nor tsc deadline) - Set the TMICT to non-zero. Then the lapic_timer.period will be 0, but the TMICT will not be. If the guest then reads from the TMCCT then the host will perform a divide by 0. This patch ensures that if the lapic_timer.period is 0, then the division does not occur. Reported-by:
Andrew Honig <ahonig@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> [bwh: Backported to 3.2: s/kvm_apic_get_reg/apic_get_reg/] Signed-off-by:
-
Andy Honig authored
commit 338c7dba upstream. In multiple functions the vcpu_id is used as an offset into a bitfield. Ag malicious user could specify a vcpu_id greater than 255 in order to set or clear bits in kernel memory. This could be used to elevate priveges in the kernel. This patch verifies that the vcpu_id provided is less than 255. The api documentation already specifies that the vcpu_id must be less than max_vcpus, but this is currently not checked. Reported-by:
-
Linus Torvalds authored
commit f12d5bfc upstream. The hugepage code had the exact same bug that regular pages had in commit 7485d0d3 ("futexes: Remove rw parameter from get_futex_key()"). The regular page case was fixed by commit 9ea71503 ("futex: Fix regression with read only mappings"), but the transparent hugepage case (added in a5b338f2: "thp: update futex compound knowledge") case remained broken. Found by Dave Jones and his trinity tool. Reported-and-tested-by:
Dave Jones <davej@fedoraproject.org> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Mel Gorman <mgorman@suse.de> Cc: Darren Hart <dvhart@linux.intel.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Oleg Nesterov <oleg@redhat.com> Signed-off-by:
-
Dan Carpenter authored
commit 3806b45b upstream. The "rpm * div" operations can overflow here, so this patch adds an upper limit to rpm to prevent that. Jean Delvare helped me with this patch. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Roger Lucas <vt8231@hiddenengine.co.uk> Signed-off-by:
Jean Delvare <khali@linux-fr.org> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Jean Delvare authored
commit 33a7ab91 upstream. The W83L786NG stores the fan speed on 4 bits while the sysfs interface uses a 0-255 range. Thus the driver should scale the user input down to map it to the device range, and scale up the value read from the device before presenting it to the user. The reserved register nibble should be left unchanged. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Brian Carnes authored
commit cf7559bc upstream. The wrong mask is used, which causes some fan speed control modes (pwmX_enable) to be incorrectly reported, and some modes to be impossible to set. [JD: add subject and description.] Signed-off-by:
Brian Carnes <bmcarnes@gmail.com> Signed-off-by:
-
Sergei Ianovich authored
commit ff88b472 upstream. Erratum 71 of PXA270M Processor Family Specification Update (April 19, 2010) explains that watchdog reset time is just 8us insead of 10ms in EMTS. If SDRAM is not reset, it causes memory bus congestion and the device hangs. We put SDRAM in selfresh mode before watchdog reset, removing potential freezes. Without this patch PXA270-based ICP DAS LP-8x4x hangs after up to 40 reboots. With this patch it has successfully rebooted 500 times. Signed-off-by:
Sergei Ianovich <ynvich@gmail.com> Tested-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Haojian Zhuang <haojian.zhuang@gmail.com> Signed-off-by:
Olof Johansson <olof@lixom.net> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Dmitry Eremin-Solenikov authored
commit 506cac15 upstream. When converting from tosa-keyboard driver to matrix keyboard, tosa keys received extra 1 column shift. Replace that with correct values to make keyboard work again. Fixes: f69a6548 ('[ARM] pxa/tosa: make use of the matrix keypad driver') Signed-off-by:
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by:
-
Mikulas Patocka authored
commit 4cb57ab4 upstream. Some module parameters in dm-bufio are read-only. These parameters inform the user about memory consumption. They are not supposed to be changed by the user. However, despite being read-only, these parameters can be set on modprobe or insmod command line, for example: modprobe dm-bufio current_allocated_bytes=12345 The kernel doesn't expect that these variables can be non-zero at module initialization and if the user sets them, it results in BUG. This patch initializes the variables in the module init routine, so that user-supplied values are ignored. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Matthew Garrett authored
commit 04bf9ba7 upstream. UEFI time services are often broken once we're in virtual mode. We were already refusing to use them on 64-bit systems, but it turns out that they're also broken on some 32-bit firmware, including the Dell Venue. Disable them for now, we can revisit once we have the 1:1 mappings code incorporated. Signed-off-by:
Matthew Garrett <matthew.garrett@nebula.com> Link: http://lkml.kernel.org/r/1385754283-2464-1-git-send-email-matthew.garrett@nebula.com Cc: Matt Fleming <matt.fleming@intel.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> [bwh: Backported to 3.2: deleted code is slightly different] Signed-off-by:
-
H. Peter Anvin authored
commit 503cf95c upstream. When compiling with icc, <linux/compiler-gcc.h> ends up included because the icc environment defines __GNUC__. Thus, we neither need nor want to have this macro defined in both compiler-gcc.h and compiler-intel.h, and the fact that they are inconsistent just makes the compiler spew warnings. Reported-by:
Sunil K. Pandey <sunil.k.pandey@intel.com> Cc: Kevin B. Smith <kevin.b.smith@intel.com> Signed-off-by:
-
Mikulas Patocka authored
commit 5b2d0657 upstream. The dm_round_up function may overflow to zero. In this case, dm_table_create() must fail rather than go on to allocate an empty array with alloc_targets(). This fixes a possible memory corruption that could be caused by passing too large a number in "param->target_count". Signed-off-by:
-
Mikulas Patocka authored
commit 230c83af upstream. There is a possible leak of snapshot space in case of crash. The reason for space leaking is that chunks in the snapshot device are allocated sequentially, but they are finished (and stored in the metadata) out of order, depending on the order in which copying finished. For example, supposed that the metadata contains the following records SUPERBLOCK METADATA (blocks 0 ... 250) DATA 0 DATA 1 DATA 2 ... DATA 250 Now suppose that you allocate 10 new data blocks 251-260. Suppose that copying of these blocks finish out of order (block 260 finished first and the block 251 finished last). Now, the snapshot device looks like this: SUPERBLOCK METADATA (blocks 0 ... 250, 260, 259, 258, 257, 256) DATA 0 DATA 1 DATA 2 ... DATA 250 DATA 251 DATA 252 DATA 253 DATA 254 DATA 255 METADATA (blocks 255, 254, 253, 252, 251) DATA 256 DATA 257 DATA 258 DATA 259 DATA 260 Now, if the machine crashes after writing the first metadata block but before writing the second metadata block, the space for areas DATA 250-255 is leaked, it contains no valid data and it will never be used in the future. This patch makes dm-snapshot complete exceptions in the same order they were allocated, thus fixing this bug. Note: when backporting this patch to the stable kernel, change the version field in the following way: * if version in the stable kernel is {1, 11, 1}, change it to {1, 12, 0} * if version in the stable kernel is {1, 10, 0} or {1, 10, 1}, change it to {1, 10, 2} Userspace reads the version to determine if the bug was fixed, so the version change is needed. Signed-off-by:
-
Stefano Panella authored
commit 932e9dec upstream. When running a 32bit kernel the hda_intel driver is still reporting a 64bit dma_mask if the HW supports it. From sound/pci/hda/hda_intel.c: /* allow 64bit DMA address if supported by H/W */ if ((gcap & ICH6_GCAP_64OK) && !pci_set_dma_mask(pci, DMA_BIT_MASK(64))) pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(64)); else { pci_set_dma_mask(pci, DMA_BIT_MASK(32)); pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(32)); } which means when there is a call to dma_alloc_coherent from snd_malloc_dev_pages a machine address bigger than 32bit can be returned. This can be true in particular if running the 32bit kernel as a pv dom0 under the Xen Hypervisor or PAE on bare metal. The problem is that when calling setup_bdle to program the BLE the dma_addr_t returned from the dma_alloc_coherent is wrongly truncated from snd_sgbuf_get_addr if running a 32bit kernel: static inline dma_addr_t snd_sgbuf_get_addr(struct snd_dma_buffer *dmab, size_t offset) { struct snd_sg_buf *sgbuf = dmab->private_data; dma_addr_t addr = sgbuf->table[offset >> PAGE_SHIFT].addr; addr &= PAGE_MASK; return addr + offset % PAGE_SIZE; } where PAGE_MASK in a 32bit kernel is zeroing the upper 32bit af addr. Without this patch the HW will fetch the 32bit truncated address, which is not the one obtained from dma_alloc_coherent and will result to a non working audio but can corrupt host memory at a random location. The current patch apply to v3.13-rc3-74-g6c843f5 Signed-off-by:
Stefano Panella <stefano.panella@citrix.com> Reviewed-by:
Frediano Ziglio <frediano.ziglio@citrix.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
H. Peter Anvin authored
commit 8b3b005d upstream. In checkin 5551a34e x86-64, build: Always pass in -mno-sse we unconditionally added -mno-sse to the main build, to keep newer compilers from generating SSE instructions from autovectorization. However, this did not extend to the special environments (arch/x86/boot, arch/x86/boot/compressed, and arch/x86/realmode/rm). Add -mno-sse to the compiler command line for these environments, and add -mno-mmx to all the environments as well, as we don't want a compiler to generate MMX code either. This patch also removes a $(cc-option) call for -m32, since we have long since stopped supporting compilers too old for the -m32 option, and in fact hardcode it in other places in the Makefiles. Reported-by:
Kevin B. Smith <kevin.b.smith@intel.com> Cc: Sunil K. Pandey <sunil.k.pandey@intel.com> Signed-off-by:
-
Konstantin Khlebnikov authored
commit 3abb6671 upstream. This patch fixes corner case when (fp + 4) overflows unsigned long, for example: fp = 0xFFFFFFFF -> fp + 4 == 3. Signed-off-by:
Konstantin Khlebnikov <k.khlebnikov@samsung.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Konstantin Khlebnikov authored
commit 1b15ec7a upstream. get_wchan() is lockless. Task may wakeup at any time and change its own stack, thus each next stack frame may be overwritten and filled with random stuff. /proc/$pid/stack interface had been disabled for non-current tasks, see [1] But 'wchan' still allows to trigger stack frame unwinding on volatile stack. This patch fixes oops in unwind_frame() by adding stack pointer validation on each step (as x86 code do), unwind_frame() already checks frame pointer. Also I've found another report of this oops on stackoverflow (irony). Link: http://www.spinics.net/lists/arm-kernel/msg110589.html [1] Link: http://stackoverflow.com/questions/18479894/unwind-frame-cause-a-kernel-paging-errorSigned-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Tom Lendacky authored
commit 389a5390 upstream. Now that scatterwalk_sg_chain sets the chain pointer bit the sg_page call in scatterwalk_sg_next hits a BUG_ON when CONFIG_DEBUG_SG is enabled. Use sg_chain_ptr instead of sg_page on a chain entry. Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Alan Cox authored
commit 9aa5b018 upstream. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=60772Signed-off-by:
Alan Cox <alan@linux.intel.com> Reported-by:
Leho Kraav <leho@kraav.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Julius Werner authored
commit 2d51f3cd upstream. This patch adds a check for USB_STATE_NOTATTACHED to the hub_port_warm_reset_required() workaround for ports that end up in Compliance Mode in hub_events() when trying to decide which reset function to use. Trying to call usb_reset_device() with a NOTATTACHED device will just fail and leave the port broken. Signed-off-by:
Julius Werner <jwerner@chromium.org> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
David Cluytens authored
commit 3b59d16c upstream. Signed-off-by:
David Cluytens <david.cluytens@gmail.com> Signed-off-by:
-
Bo Shen authored
commit b4af6ef9 upstream. According to WM8731 "PD, Rev 4.9 October 2012" datasheet, when it works in DSP mode A, LRP = 1, while works in DSP mode B, LRP = 0. So, fix LRP for DSP mode as the datesheet specification. Signed-off-by:
Bo Shen <voice.shen@atmel.com> Acked-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Liu Gang authored
commit 1aeef303 upstream. For MPC8572/MPC8536, the status of GPIOs defined as output cannot be determined by reading GPDAT register, so the code use shadow data register instead. But the code may give the wrong status of GPIOs defined as input under some scenarios: 1. If some pins were configured as inputs and were asserted high before booting the kernel, the shadow data has been initialized with those pin values. 2. Some pins have been configured as output first and have been set to the high value, then reconfigured as input. The above cases will make the shadow data for those input pins to be set to high. Then reading the pin status will always return high even if the actual pin status is low. The code should eliminate the effects of the shadow data to the input pins, and the status of those pins should be read directly from GPDAT. Acked-by:
Scott Wood <scottwood@freescale.com> Acked-by:
Anatolij Gustschin <agust@denx.de> Signed-off-by:
Liu Gang <Gang.Liu@freescale.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Colin Leitner authored
commit a3132499 upstream. This patch fixes the CS5 setting on the PL2303 USB-to-serial devices. CS5 has a value of 0 and the CSIZE setting has been skipped altogether by the enclosing if. Tested on 3.11.6 and the scope shows the correct output after the fix has been applied. Tagged to be added to stable, because it fixes a user visible driver bug and is simple enough to backport easily. Signed-off-by:
Colin Leitner <colin.leitner@gmail.com> Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Colin Leitner authored
commit 8704211f upstream. FTDI UARTs support only 7 or 8 data bits. Until now the ftdi_sio driver would only report this limitation for CS6 to dmesg and fail to reflect this fact to tcgetattr. This patch reverts the unsupported CSIZE setting and reports the fact with less severance to dmesg for both CS5 and CS6. To test the patch it's sufficient to call stty -F /dev/ttyUSB0 cs5 which will succeed without the patch and report an error with the patch applied. As an additional fix this patch ensures that the control request will always include a data bit size. Signed-off-by:
-
Colin Leitner authored
commit 78692cc3 upstream. This patch removes an erroneous check of CSIZE, which made it impossible to set CS5. Compiles clean, but couldn't test against hardware. Signed-off-by:
-
Colin Leitner authored
commit 711fbdfb upstream. This patch removes an erroneous check of CSIZE, which made it impossible to set CS5. Compiles clean, but couldn't test against hardware. Signed-off-by:
-
Fangxiaozhi (Franko) authored
commit 2bf308d7 upstream. Add new supporting declarations to option.c, to support Huawei new devices with new bInterfaceProtocol value. Signed-off-by:
fangxiaozhi <huananhu@huawei.com> Signed-off-by:
-
Gustavo Zacarias authored
commit 8f173e22 upstream. Interface 1 on this device isn't for option to bind to otherwise an oops on usb_wwan with log flooding will happen when accessing the port: tty_release: ttyUSB1: read/write wait queue active! It doesn't seem to respond to QMI if it's added to qmi_wwan so don't add it there - it's likely used by the card reader. Signed-off-by:
Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by:
-
James Bottomley authored
commit a1470c7b upstream. Bug report from: wenxiong@linux.vnet.ibm.com The issue is happened in dual controller configuration. We got the sysfs warnings when rmmod the ipr module. enclosure_unregister() in drivers/msic/enclosure.c, call device_unregister() for each componment deivce, device_unregister() ->device_del()->kobject_del() ->sysfs_remove_dir(). In sysfs_remove_dir(), set kobj->sd = NULL. For each componment device, enclosure_component_release()->enclosure_remove_links()->sysfs_remove_link() in which checking kobj->sd again, it has been set as NULL when doing device_unregister. So we saw all these sysfs WARNING. Tested-by: wenxiong@linux.vnet.ibm.com Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Stephen M. Cameron authored
commit 88bf6d62 upstream. A return value of 1 is interpreted as an error. See pci_driver. in local_pci_probe(). If you're wondering how this ever could have worked, it's because it used to be the case that only return values less than zero were interpreted as failure. But even in the current kernel if the driver registers its various entry points with the kernel, and then returns a value which is interpreted as failure, those registrations aren't undone, so the driver still mostly works. However, the driver's remove function wouldn't be called on rmmod, and pci power management functions wouldn't work. In the case of Smart Array, since it has a battery backed cache (or else no cache) even if the driver is not shut down properly as long as there is no outstanding i/o, nothing too bad happens, which is why it took so long to notice. Requesting backport to stable because the change to pci-driver.c which requires driver probe functions to return 0 occurred between 2.6.35 and 2.6.36 (the pci power management breakage) and again between 3.7 and 3.8 (pci_dev->driver getting set to NULL in local_pci_probe() preventing driver remove function from being called on rmmod.) Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
-
Stephen M. Cameron authored
commit 2e311fba upstream. We inadvertantly discarded the scsi status for aborted commands. For some commands (e.g. reads from tape drives) these can't be retried, and if we discarded the scsi status, the scsi mid layer couldn't notice anything was wrong and the error was not reported. Signed-off-by:
-
