- 28 Nov, 2013 40 commits
-
-
Theodore Ts'o authored
commit 61875f30 upstream. Allow architectures which have a disabled get_cycles() function to provide a random_get_entropy() function which provides a fine-grained, rapidly changing counter that can be used by the /dev/random driver. For example, an architecture might have a rapidly changing register used to control random TLB cache eviction, or DRAM refresh that doesn't meet the requirements of get_cycles(), but which is good enough for the needs of the random driver. Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Mark Cave-Ayland authored
commit 9473ca6e upstream. An error in calculating the offset in an skb causes the driver to read essential device info from the wrong locations. The main effect is that automatic gain calculations are nonsense. Signed-off-by:
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Paul Mackerras authored
commit cfc86025 upstream. 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. Signed-off-by:
Paul Mackerras <paulus@samba.org> Acked-by:
Alexander Graf <agraf@suse.de> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Takashi Iwai authored
commit 638298dc upstream. 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 1c12443a "xhci: Add Lynx Point to list of Intel switchable hosts." Cc: Oliver Neukum <oneukum@suse.de> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Oliver Neukum authored
commit 455f5892 upstream. 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 bba18e33 "xhci: Extend Fresco Logic MSI quirk.") was backported to stable kernels as old as 2.6.36. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Sarah Sharp authored
commit f217c980 upstream. 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 65580b43 "xHCI: set USB2 hardware LPM". That was the first kernel that supported USB 2.0 Link PM. Signed-off-by:
-
wojciech kapuscinski authored
commit 50b8f5ae upstream. They have 4 rather than 8. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=63599Signed-off-by:
wojciech kapuscinski <wojtask9@wp.pl> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Henrik Rydberg authored
commit 25f2bd7f upstream. 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. Tested-by:
Chris Murphy <chris@cmurf.com> Signed-off-by:
Henrik Rydberg <rydberg@euromail.se> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Emmanuel Grumbach authored
commit a754055a upstream. __ieee80211_scan_completed is called from a worker. This means that the following flow is possible. * driver calls ieee80211_scan_completed * mac80211 cancels the scan (that is already complete) * __ieee80211_scan_completed runs When scan_work will finally run, it will see that the scan hasn't been aborted and might even trigger another scan on another band. This leads to a situation where cfg80211's scan is not done and no further scan can be issued. Fix this by setting a new flag when a HW scan is being cancelled so that no other scan will be triggered. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Takashi Iwai authored
commit c6cc3d58 upstream. ASUS N56VZ needs a fixup for the bass speaker pin, which was already provided via model=asus-mode4. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=841645Signed-off-by:
-
Gwendal Grignou authored
commit f13e2201 upstream. libata EH decrements scmd->retries when the command failed for reasons unrelated to the command itself so that, for example, commands aborted due to suspend / resume cycle don't get penalized; however, decrementing scmd->retries isn't enough for ATA passthrough commands. Without this fix, ATA passthrough commands are not resend to the drive, and no error is signalled to the caller because: - allowed retry count is 1 - ata_eh_qc_complete fill the sense data, so result is valid - sense data is filled with untouched ATA registers. Signed-off-by:
Gwendal Grignou <gwendal@google.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Daniel Mack authored
commit a9d14bc0 upstream. The frame check in i_usX2Y_urb_complete() and i_usX2Y_usbpcm_urb_complete() is bogus and produces false positives as described in this LAU thread: http://linuxaudio.org/mailarchive/lau/2013/5/20/200177 This patch removes the check code entirely. Cc: fzu@wemgehoertderstaat.de Reported-by:
Dr Nicholas J Bailey <nicholas.bailey@glasgow.ac.uk> Suggested-by:
Daniel Mack <zonque@gmail.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit 08a5dd38 upstream. Add some new PCI IDs to the table for 6000, 6005 and 6235 series. Signed-off-by:
-
Shuduo Sang authored
commit 20ecf9fd upstream. some new thinkpad laptops use intel chip with new pci id need be added lspci -vnn output: Network controller [0280]: Intel Corporation Centrino Advanced-N 6235 [8086:088f] (rev 24) Subsystem: Intel Corporation Device [8086:5260] Signed-off-by:
Shuduo Sang <sangshuduo@gmail.com> Reviewed-by:
-
Wey-Yi Guy authored
commit 259653d8 upstream. Add new sku to 6x35 series Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
Wey-Yi Guy authored
commit 37891123 upstream. Update the pci subsystem id and product name for 6005 series devices Signed-off-by:
-
Wey-Yi Guy authored
commit b6cb406a upstream. BG only SKUs are no longer supported by 2000 and 1x5 series. Remove it Signed-off-by:
-
Wey-Yi Guy authored
commit 75a56ecc upstream. Add two more SKUs for 6x05 series of device. First SKU has low 5GHz channels actives, the other SKU has high 5GHz channels actives. Signed-off-by:
-
Chris Metcalf authored
commit f862eefe upstream. It turns out the kernel relies on barrier() to force a reload of the percpu offset value. Since we can't easily modify the definition of barrier() to include "tp" as an output register, we instead provide a definition of __my_cpu_offset as extended assembly that includes a fake stack read to hazard against barrier(), forcing gcc to know that it must reread "tp" and recompute anything based on "tp" after a barrier. This fixes observed hangs in the slub allocator when we are looping on a percpu cmpxchg_double. A similar fix for ARMv7 was made in June in change 509eb76e. Signed-off-by:
Chris Metcalf <cmetcalf@tilera.com> Signed-off-by:
-
Felix Fietkau authored
commit 0c5b9329 upstream. When clients are idle for too long, hostapd sends nullfunc frames for probing. When those are acked by the client, the idle time needs to be updated. To make this work (and to avoid unnecessary probing), update sta->last_rx whenever an ACK was received for a tx packet. Only do this if the flag IEEE80211_HW_REPORTS_TX_ACK_STATUS is set. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Felix Fietkau authored
commit 6329b8d9 upstream. If an Ad-Hoc node receives packets with the Cell ID or its own MAC address as source address, it hits a WARN_ON in sta_info_insert_check() With many packets, this can massively spam the logs. One way that this can easily happen is through having Cisco APs in the area with rouge AP detection and countermeasures enabled. Such Cisco APs will regularly send fake beacons, disassoc and deauth packets that trigger these warnings. To fix this issue, drop such spoofed packets early in the rx path. Reported-by:
Thomas Huehn <thomas@net.t-labs.tu-berlin.de> Signed-off-by:
-
Theodore Ts'o authored
commit 47d06e53 upstream. The some platforms (e.g., ARM) initializes their clocks as late_initcalls for some unknown reason. So make sure random_int_secret_init() is run after all of the late_initcalls are run. Signed-off-by:
-
Dave Kleikamp authored
commit 86609986 upstream. If insert_inode_locked() fails, we shouldn't be calling unlock_new_inode(). Signed-off-by:
Dave Kleikamp <dave.kleikamp@oracle.com> Tested-by:
Michael L. Semon <mlsemon35@gmail.com> Signed-off-by:
-
Fan Du authored
commit 74e3d1e1 upstream. Two rt tasks bind to one CPU core. The higher priority rt task A preempts a lower priority rt task B which has already taken the write seq lock, and then the higher priority rt task A try to acquire read seq lock, it's doomed to lockup. rt task A with lower priority: call write i_size_write rt task B with higher priority: call sync, and preempt task A write_seqcount_begin(&inode->i_size_seqcount); i_size_read inode->i_size = i_size; read_seqcount_begin <-- lockup here... So disable preempt when acquiring every i_size_seqcount *write* lock will cure the problem. Signed-off-by:
Fan Du <fan.du@windriver.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Steven Rostedt authored
commit 057db848 upstream. Andrey reported the following report: ERROR: AddressSanitizer: heap-buffer-overflow on address ffff8800359c99f3 ffff8800359c99f3 is located 0 bytes to the right of 243-byte region [ffff8800359c9900, ffff8800359c99f3) Accessed by thread T13003: #0 ffffffff810dd2da (asan_report_error+0x32a/0x440) #1 ffffffff810dc6b0 (asan_check_region+0x30/0x40) #2 ffffffff810dd4d3 (__tsan_write1+0x13/0x20) #3 ffffffff811cd19e (ftrace_regex_release+0x1be/0x260) #4 ffffffff812a1065 (__fput+0x155/0x360) #5 ffffffff812a12de (____fput+0x1e/0x30) #6 ffffffff8111708d (task_work_run+0x10d/0x140) #7 ffffffff810ea043 (do_exit+0x433/0x11f0) #8 ffffffff810eaee4 (do_group_exit+0x84/0x130) #9 ffffffff810eafb1 (SyS_exit_group+0x21/0x30) #10 ffffffff81928782 (system_call_fastpath+0x16/0x1b) Allocated by thread T5167: #0 ffffffff810dc778 (asan_slab_alloc+0x48/0xc0) #1 ffffffff8128337c (__kmalloc+0xbc/0x500) #2 ffffffff811d9d54 (trace_parser_get_init+0x34/0x90) #3 ffffffff811cd7b3 (ftrace_regex_open+0x83/0x2e0) #4 ffffffff811cda7d (ftrace_filter_open+0x2d/0x40) #5 ffffffff8129b4ff (do_dentry_open+0x32f/0x430) #6 ffffffff8129b668 (finish_open+0x68/0xa0) #7 ffffffff812b66ac (do_last+0xb8c/0x1710) #8 ffffffff812b7350 (path_openat+0x120/0xb50) #9 ffffffff812b8884 (do_filp_open+0x54/0xb0) #10 ffffffff8129d36c (do_sys_open+0x1ac/0x2c0) #11 ffffffff8129d4b7 (SyS_open+0x37/0x50) #12 ffffffff81928782 (system_call_fastpath+0x16/0x1b) Shadow bytes around the buggy address: ffff8800359c9700: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ffff8800359c9780: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa ffff8800359c9800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ffff8800359c9880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ffff8800359c9900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>ffff8800359c9980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[03]fb ffff8800359c9a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ffff8800359c9a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ffff8800359c9b00: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 ffff8800359c9b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8800359c9c00: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap redzone: fa Heap kmalloc redzone: fb Freed heap region: fd Shadow gap: fe The out-of-bounds access happens on 'parser->buffer[parser->idx] = 0;' Although the crash happened in ftrace_regex_open() the real bug occurred in trace_get_user() where there's an incrementation to parser->idx without a check against the size. The way it is triggered is if userspace sends in 128 characters (EVENT_BUF_SIZE + 1), the loop that reads the last character stores it and then breaks out because there is no more characters. Then the last character is read to determine what to do next, and the index is incremented without checking size. Then the caller of trace_get_user() usually nulls out the last character with a zero, but since the index is equal to the size, it writes a nul character after the allocated space, which can corrupt memory. Luckily, only root user has write access to this file. Link: http://lkml.kernel.org/r/20131009222323.04fd1a0d@gandalf.local.homeReported-by:
Andrey Konovalov <andreyknvl@google.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Patrick McHardy authored
commit 3a7b21ea upstream. Some Cisco phones create huge messages that are spread over multiple packets. After calculating the offset of the SIP body, it is validated to be within the packet and the packet is dropped otherwise. This breaks operation of these phones. Since connection tracking is supposed to be passive, just let those packets pass unmodified and untracked. Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> [bwh: Backported to 3.2: there is no log message to delete] Signed-off-by:
-
David Woodhouse authored
commit 01ffc0a7 upstream. Recovery doesn't work too well if we leave interrupts disabled... Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Acked-by:
Francois Romieu <romieu@fr.zoreil.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Hannes Frederic Sowa authored
[ This is a simplified -stable version of a set of upstream commits. ] This is a replacement patch only for stable which does fix the problems handled by the following two commits in -net: "ip_output: do skb ufo init for peeked non ufo skb as well" (e93b7d74) "ip6_output: do skb ufo init for peeked non ufo skb as well" (c547dbf5) Three frames are written on a corked udp socket for which the output netdevice has UFO enabled. If the first and third frame are smaller than the mtu and the second one is bigger, we enqueue the second frame with skb_append_datato_frags without initializing the gso fields. This leads to the third frame appended regulary and thus constructing an invalid skb. This fixes the problem by always using skb_append_datato_frags as soon as the first frag got enqueued to the skb without marking the packet as SKB_GSO_UDP. The problem with only two frames for ipv6 was fixed by "ipv6: udp packets following an UFO enqueued packet need also be handled by UFO" (2811ebac). Cc: Jiri Pirko <jiri@resnulli.us> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: David Miller <davem@davemloft.net> Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Markus Trippelsdorf authored
commit 7b78f136 upstream. On a system running glibc trunk perf doesn't build: CC builtin-sched.o builtin-sched.c: In function ‘get_cpu_usage_nsec_parent’: builtin-sched.c:399:16: error: storage size of ‘ru’ isn’t known builtin-sched.c:403:2: error: implicit declaration of function ‘getrusage’ [-Werror=implicit-function-declaration] [...] Fix it by including sys/resource.h. Signed-off-by:
Markus Trippelsdorf <markus@trippelsdorf.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/20120404084527.GA294@x4Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Wei Liu authored
[ Upstream commit 059dfa6a ] time_after_eq() only works if the delta is < MAX_ULONG/2. For a 32bit Dom0, if netfront sends packets at a very low rate, the time between subsequent calls to tx_credit_exceeded() may exceed MAX_ULONG/2 and the test for timer_after_eq() will be incorrect. Credit will not be replenished and the guest may become unable to send packets (e.g., if prior to the long gap, all credit was exhausted). Use jiffies_64 variant to mitigate this problem for 32bit Dom0. Suggested-by:
Jan Beulich <jbeulich@suse.com> Signed-off-by:
Wei Liu <wei.liu2@citrix.com> Reviewed-by:
David Vrabel <david.vrabel@citrix.com> Cc: Ian Campbell <ian.campbell@citrix.com> Cc: Jason Luan <jianhai.luan@oracle.com> Signed-off-by:
-
Peter Zijlstra authored
commit bf378d34 upstream. The PPC64 people noticed a missing memory barrier and crufty old comments in the perf ring buffer code. So update all the comments and add the missing barrier. When the architecture implements local_t using atomic_long_t there will be double barriers issued; but short of introducing more conditional barrier primitives this is the best we can do. Reported-by:
Victor Kaplansky <victork@il.ibm.com> Tested-by:
Peter Zijlstra <peterz@infradead.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Cc: michael@ellerman.id.au Cc: Paul McKenney <paulmck@linux.vnet.ibm.com> Cc: Michael Neuling <mikey@neuling.org> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: anton@samba.org Cc: benh@kernel.crashing.org Link: http://lkml.kernel.org/r/20131025173749.GG19466@laptop.lanSigned-off-by:
-
Sergey Senozhatsky authored
commit 75c7caf5 upstream. Pass valid_io_request() checks if request end coincides with disksize (end equals bound), only fail if we attempt to read beyond the bound. mkfs.ext2 produces numerous errors: [ 2164.632747] quiet_error: 1 callbacks suppressed [ 2164.633260] Buffer I/O error on device zram0, logical block 153599 [ 2164.633265] lost page write due to I/O error on zram0 Signed-off-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by:
-
Eric Sandeen authored
commit d7dab39b upstream. This is based on commit d1f5273e ext4: return 32/64-bit dir name hash according to usage type by Fan Yong <yong.fan@whamcloud.com> Traditionally ext2/3/4 has returned a 32-bit hash value from llseek() to appease NFSv2, which can only handle a 32-bit cookie for seekdir() and telldir(). However, this causes problems if there are 32-bit hash collisions, since the NFSv2 server can get stuck resending the same entries from the directory repeatedly. Allow ext3 to return a full 64-bit hash (both major and minor) for telldir to decrease the chance of hash collisions. This patch does implement a new ext3_dir_llseek op, because with 64-bit hashes, nfs will attempt to seek to a hash "offset" which is much larger than ext3's s_maxbytes. So for dx dirs, we call generic_file_llseek_size() with the appropriate max hash value as the maximum seekable size. Otherwise we just pass through to generic_file_llseek(). Patch-updated-by:
Bernd Schubert <bernd.schubert@itwm.fraunhofer.de> Patch-updated-by:
Eric Sandeen <sandeen@redhat.com> (blame us if something is not correct) Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
-
Bernd Schubert authored
commit 06effdbb upstream. Use 32-bit or 64-bit llseek() hashes for directory offsets depending on the NFS version. NFSv2 gets 32-bit hashes only. NOTE: This patch got rather complex as Christoph asked to set the filp->f_mode flag in the open call or immediatly after dentry_open() in nfsd_open() to avoid races. Personally I still do not see a reason for that and in my opinion FMODE_32BITHASH/FMODE_64BITHASH flags could be set nfsd_readdir(), as it follows directly after nfsd_open() without a chance of races. Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Bernd Schubert authored
commit 999448a8 upstream. Just rename this variable, as the next patch will add a flag and 'access' as variable name would not be correct any more. Signed-off-by:
-
Fan Yong authored
commit d1f5273e upstream. Traditionally ext2/3/4 has returned a 32-bit hash value from llseek() to appease NFSv2, which can only handle a 32-bit cookie for seekdir() and telldir(). However, this causes problems if there are 32-bit hash collisions, since the NFSv2 server can get stuck resending the same entries from the directory repeatedly. Allow ext4 to return a full 64-bit hash (both major and minor) for telldir to decrease the chance of hash collisions. This still needs integration on the NFS side. Patch-updated-by:
Fan Yong <yong.fan@whamcloud.com> Signed-off-by:
Andreas Dilger <adilger@whamcloud.com> Signed-off-by:
-
Bernd Schubert authored
commit 6a8a13e0 upstream. Those flags are supposed to be set by NFS readdir() to tell ext3/ext4 to 32bit (NFSv2) or 64bit hash values (offsets) in seekdir(). Signed-off-by:
-
Nikhil P Rao authored
commit d6776e6d upstream. _pci_assign_resource() took an int "size" argument, which meant that sizes larger than 4GB were truncated. Change type to resource_size_t. [bhelgaas: changelog] Signed-off-by:
Nikhil P Rao <nikhil.rao@intel.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Mariusz Ceier authored
[ Upstream commit d69e0f7e ] When IFF_ALLMULTI flag is set on interface and IFF_PROMISC isn't, emac_dev_mcast_set should only enable RX of multicasts and reset MACHASH registers. It does this, but afterwards it either sets up multicast MACs filtering or disables RX of multicasts and resets MACHASH registers again, rendering IFF_ALLMULTI flag useless. This patch fixes emac_dev_mcast_set, so that multicast MACs filtering and disabling of RX of multicasts are skipped when IFF_ALLMULTI flag is set. Tested with kernel 2.6.37. Signed-off-by:
Mariusz Ceier <mceier+kernel@gmail.com> Acked-by:
Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by:
-
Seif Mazareeb authored
[ Upstream commit f2e5ddcc ] When CONFIG_NETLABEL is disabled, the cipso_v4_validate() function could loop forever in the main loop if opt[opt_iter +1] == 0, this will causing a kernel crash in an SMP system, since the CPU executing this function will stall /not respond to IPIs. This problem can be reproduced by running the IP Stack Integrity Checker (http://isic.sourceforge.net) using the following command on a Linux machine connected to DUT: "icmpsic -s rand -d <DUT IP address> -r 123456" wait (1-2 min) Signed-off-by:
Seif Mazareeb <seif@marvell.com> Acked-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
