- 26 Aug, 2010 40 commits
-
-
Sven Eckelmann authored
commit f86b9984 upstream. Each net_device in a system will automatically managed as a possible batman_if and holds different informations like a buffer with a prepared originator messages. To reduce the memory usage, the packet_buff will only be allocated when the interface is really added/enabled for batman-adv. The function to update the hw address information inside the packet_buff just assumes that the packet_buff is always initialised and thus the kernel will just oops when we try to change the hw address of a not already fully enabled interface. We must always check if the packet_buff is allocated before we try to change information inside of it. Reported-by:
Tim Glaremin <Tim.Glaremin@web.de> Reported-by:
Kazuki Shimada <zukky@bb.banban.jp> Signed-off-by:
Sven Eckelmann <sven.eckelmann@gmx.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Sven Eckelmann authored
commit 51a00eaf upstream. dev_put allows a device to be freed when all its references are dropped. After that we are not allowed to access that information anymore. Access to the data structure of a net_device must be surrounded a dev_hold and ended using dev_put. batman-adv adds a device to its own management structure in hardif_add_interface and will release it in hardif_remove_interface. Thus it must hold a reference all the time between those functions to prevent any access to the already released net_device structure. Reported-by:
-
Sven Eckelmann authored
commit 1189f130 upstream. We try to get all events for all net_devices to be able to add special sysfs folders for the batman-adv configuration. This also includes such events like NETDEV_POST_INIT which has no valid kobject according to v2.6.32-rc3-13-g7ffbe3fd. This would create an oops in that situation. It is enough to create the batman_if only on NETDEV_REGISTER events because we will also receive those events for devices which already existed when we registered the notifier call. Signed-off-by:
-
Marek Lindner authored
commit 9abc1023 upstream. The orig_hash_lock spinlock always has to be locked with IRQs being disabled to avoid deadlocks between code that is being executed in IRQ context and code that is being executed in non-IRQ context. Reported-by:
Marek Lindner <lindner_marek@yahoo.de> Signed-off-by:
-
Dave Airlie authored
commit b9f0aee8 upstream. non-critical issue, CVE-2010-2803 Userspace controls the amount of memory to be allocate, so it can get the ioctl to allocate more memory than the kernel uses, and get access to kernel stack. This can only be done for processes authenticated to the X server for DRI access, and if the user has DRI access. Fix is to just memset the data to 0 if the user doesn't copy into it in the first place. Reported-by:
Kees Cook <kees@ubuntu.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Jerome Glisse authored
commit 2cbeb4ef upstream. GTT/VRAM overlapping test had a typo which leaded to not detecting case when vram_end > gtt_end. This patch fix the logic and should fix #16574 Signed-off-by:
Jerome Glisse <jglisse@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit 4b80d954 upstream. The meaning of ucMemoryType changed on recent boards, however, ulBootUpSidePortClock should be set properly across all boards. Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
-
Alex Deucher authored
commit 5786e2c5 upstream. The pins for ddc and aux are shared so you need to switch the mode when doing ddc. The ProcessAuxChannel table already sets the pin mode to DP. This should fix unreliable ddc issues on DP ports using non-DP monitors. Signed-off-by:
-
Alex Deucher authored
commit 0537398b upstream. Looks like this got copied from the ddx wrong. Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Alex Deucher authored
commit 4e186b2d upstream. If we aren't changing the power state, no need to take locks and schedule fences, etc. There seem to be lock ordering issues in the CP and fence code in some cases; see bug 29140 below. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=29140 Possibly also: https://bugzilla.kernel.org/show_bug.cgi?id=16581Signed-off-by:
-
Alex Deucher authored
commit da7be684 upstream. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=29327Signed-off-by:
-
Johannes Berg authored
commit 68d6ac6d upstream. Since commit 1dacc76d Author: Johannes Berg <johannes@sipsolutions.net> Date: Wed Jul 1 11:26:02 2009 +0000 net/compat/wext: send different messages to compat tasks we had a race condition when setting and then restoring frag_list. Eric attempted to fix it, but the fix created even worse problems. However, the original motivation I had when I added the code that turned out to be racy is no longer clear to me, since we only copy up to skb->len to userspace, which doesn't include the frag_list length. As a result, not doing any frag_list clearing and restoring avoids the race condition, while not introducing any other problems. Additionally, while preparing this patch I found that since none of the remaining netlink code is really aware of the frag_list, we need to use the original skb's information for packet information and credentials. This fixes, for example, the group information received by compat tasks. Cc: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Acked-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Daniel T Chen authored
commit 9c77b846 upstream. BugLink: https://bugs.launchpad.net/bugs/619439 This ThinkPad model needs External Amplifier muted for audible playback, so set the inv_eapd quirk for it. Reported-and-tested-by:
Dennis Bell <dennis.bell@parkerg.co.uk> Signed-off-by:
Daniel T Chen <crimsun@ubuntu.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Jan Beulich authored
commit 3c955b40 upstream. It doesn't like pattern and explicit rules to be on the same line, and it seems to be more picky when matching file (or really directory) names with different numbers of trailing slashes. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Andrew Benton <b3nton@gmail.com> Signed-off-by:
Michal Marek <mmarek@suse.cz> Signed-off-by:
-
Johannes Berg authored
commit 8b8ab9d5 upstream. Applying the filter flags directly as done since commit 3474ad63 Author: Johannes Berg <johannes.berg@intel.com> Date: Thu Apr 29 04:43:05 2010 -0700 iwlwifi: apply filter flags directly broke 3945 under some unknown circumstances, as reported by Alex. Since I want to keep the direct application of filter flags on iwlagn, duplicate the code into both 3945 and agn and remove committing the RXON that broke things from the 3945 version. Reported-by:
Alex Romosan <romosan@sycorax.lbl.gov> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Bruce Allan authored
commit 1aef70ef upstream. From: Bruce Allan <bruce.w.allan@intel.com> The alternate MAC address feature is only supported by 80003ES2LAN and 82571 LOMs as well as a couple 82571 mezzanine cards. Checking for an alternate MAC address on other parts can fail leading to the driver not able to load. This patch limits the check for an alternate MAC address to be done only for parts that support the feature. This issue has been around since support for the feature was introduced to the e1000e driver in 2.6.34. Signed-off-by:
Bruce Allan <bruce.w.allan@intel.com> Reported-by:
Fabio Varesano <fax8@users.sourceforge.net> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Bruce Allan authored
commit 19833b5d upstream. On the e1000-devel mailing list, Nils Faerber reported latency issues with the 82573 LOM on a ThinkPad X60. It was found to be caused by ASPM L1; disabling it resolves the latency. The issue is present in kernels back to 2.6.34 and possibly 2.6.33. Reported-by:
Nils Faerber <nils.faerber@kernelconcepts.de> Signed-off-by:
-
Kiyoshi Ueda authored
commit 3f77316d upstream. This patch separates the device deletion code from dm_put() to make sure the deletion happens in the process context. By this patch, device deletion always occurs in an ioctl (process) context and dm_put() can be called in interrupt context. As a result, the request-based dm's bad dm_put() usage pointed out by Mikulas below disappears. http://marc.info/?l=dm-devel&m=126699981019735&w=2 Without this patch, I confirmed there is a case to crash the system: dm_put() => dm_table_destroy() => vfree() => BUG_ON(in_interrupt()) Some more backgrounds and details: In request-based dm, a device opener can remove a mapped_device while the last request is still completing, because bios in the last request complete first and then the device opener can close and remove the mapped_device before the last request completes: CPU0 CPU1 ================================================================= <<INTERRUPT>> blk_end_request_all(clone_rq) blk_update_request(clone_rq) bio_endio(clone_bio) == end_clone_bio blk_update_request(orig_rq) bio_endio(orig_bio) <<I/O completed>> dm_blk_close() dev_remove() dm_put(md) <<Free md>> blk_finish_request(clone_rq) .... dm_end_request(clone_rq) free_rq_clone(clone_rq) blk_end_request_all(orig_rq) rq_completed(md) So request-based dm used dm_get()/dm_put() to hold md for each I/O until its request completion handling is fully done. However, the final dm_put() can call the device deletion code which must not be run in interrupt context and may cause kernel panic. To solve the problem, this patch moves the device deletion code, dm_destroy(), to predetermined places that is actually deleting the mapped_device in ioctl (process) context, and changes dm_put() just to decrement the reference count of the mapped_device. By this change, dm_put() can be used in any context and the symmetric model below is introduced: dm_create(): create a mapped_device dm_destroy(): destroy a mapped_device dm_get(): increment the reference count of a mapped_device dm_put(): decrement the reference count of a mapped_device dm_destroy() waits for all references of the mapped_device to disappear, then deletes the mapped_device. dm_destroy() uses active waiting with msleep(1), since deleting the mapped_device isn't performance-critical task. And since at this point, nobody opens the mapped_device and no new reference will be taken, the pending counts are just for racing completing activity and will eventually decrease to zero. For the unlikely case of the forced module unload, dm_destroy_immediate(), which doesn't wait and forcibly deletes the mapped_device, is also introduced and used in dm_hash_remove_all(). Otherwise, "rmmod -f" may be stuck and never return. And now, because the mapped_device is deleted at this point, subsequent accesses to the mapped_device may cause NULL pointer references. Signed-off-by:
Kiyoshi Ueda <k-ueda@ct.jp.nec.com> Signed-off-by:
Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Signed-off-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
-
Johannes Berg authored
This is a backport of mainline commit 94597ab2. I removed the variable renamings from it and made it apply on 2.6.35. It now also incorporates some changes from commit cfecc6b4 since those were required as well. commit 94597ab2 upstream. Currently the driver will try to protect all frames, which leads to a lot of odd things like sending an RTS with a zeroed RA before multicast frames, which is clearly bogus. In order to fix all of this, we need to take a step back and see what we need to achieve: * we need RTS/CTS protection if requested by the AP for the BSS, mac80211 tells us this * in that case, CTS-to-self should only be enabled when mac80211 tells us * additionally, as a hardware workaround, on some devices we have to protect aggregated frames with RTS To achieve the first two items, set up the RXON accordingly and set the protection required flag in the transmit command when mac80211 requests protection for the frame. To achieve the last item, set the rate-control RTS-requested flag for all stations that we have aggregation sessions with, and set the protection required flag when sending aggregated frames (on those devices where this is required). Since otherwise bugs can occur, do not allow the user to override the RTS-for-aggregation setting from sysfs any more. Finally, also clean up the way all these flags get set in the driver and move everything into the device-specific functions. Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
Oliver Hartkopp authored
commit cff0d6e6 upstream. Commit fc6055a5 (net: Introduce skb_orphan_try()) allows an early orphan of the skb and takes care on tx timestamping, which needs the sk-reference in the skb on driver level. So does the can-raw socket, which has not been taken into account here. The patch below adds a 'prevent_sk_orphan' bit in the skb tx shared info, which fixes the problem discovered by Matthias Fuchs here: http://marc.info/?t=128030411900003&r=1&w=2 Even if it's not a primary tx timestamp topic it fits well into some skb shared tx context. Or should be find a different place for the information to protect the sk reference until it reaches the driver level? Signed-off-by:
Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by:
-
John Stultz authored
commit c7dcf87a upstream. Early 4.3 versions of gcc apparently aggressively optimize the raw time accumulation loop, replacing it with a divide. On 32bit systems, this causes the following link errors: undefined reference to `__umoddi3' undefined reference to `__udivdi3' The gcc issue has been fixed in 4.4 and greater. This patch replaces the accumulation loop with a do_div, as suggested by Linus. Signed-off-by:
John Stultz <johnstul@us.ibm.com> CC: Jason Wessel <jason.wessel@windriver.com> CC: Larry Finger <Larry.Finger@lwfinger.net> CC: Ingo Molnar <mingo@elte.hu> CC: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Jason Wessel authored
commit deda2e81 upstream. The tv_nsec is a long and when added to the shifted interval it can wrap and become negative which later causes looping problems in the getrawmonotonic(). The edge case occurs when the system has slept for a short period of time of ~2 seconds. A trace printk of the values in this patch illustrate the problem: ftrace time stamp: log 43.716079: logarithmic_accumulation: raw: 3d0913 tv_nsec d687faa 43.718513: logarithmic_accumulation: raw: 3d0913 tv_nsec da588bd 43.722161: logarithmic_accumulation: raw: 3d0913 tv_nsec de291d0 46.349925: logarithmic_accumulation: raw: 7a122600 tv_nsec e1f9ae3b 46.349930: logarithmic_accumulation: raw: 1e848980 tv_nsec 8831c0e3 The kernel starts looping at 46.349925 in the getrawmonotonic() due to the negative value from adding the raw value to tv_nsec. A simple solution is to accumulate into a u64, and then normalize it to a timespec_t. Signed-off-by:
Jason Wessel <jason.wessel@windriver.com> [ Reworked variable names and simplified some of the code. - John ] Signed-off-by:
-
Jesse Barnes authored
commit d1d6ca73 upstream. Some BIOSes will claim a large chunk of stolen space. Unless we reclaim it, our aperture for remapping buffer objects will be constrained. So clamp the stolen space to 32M and ignore the rest. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15469 among others. Adding the ignored stolen memory back into the general pool using the memory hotplug code is left as an exercise for the reader. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Simon Farnsworth <simon.farnsworth@onelan.com> Tested-by:
Artem S. Tashkinov <t.artem@mailcity.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Josh Hunt authored
commit a7c55cbe upstream. Newer Intel processors identifying themselves as model 30 are not recognized by oprofile. <cpuinfo snippet> model : 30 model name : Intel(R) Xeon(R) CPU X3470 @ 2.93GHz </cpuinfo snippet> Running oprofile on these machines gives the following: + opcontrol --init + opcontrol --list-events oprofile: available events for CPU type "Intel Architectural Perfmon" See Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3B (Document 253669) Chapter 18 for architectural perfmon events This is a limited set of fallback events because oprofile doesn't know your CPU CPU_CLK_UNHALTED: (counter: all) Clock cycles when not halted (min count: 6000) INST_RETIRED: (counter: all) number of instructions retired (min count: 6000) LLC_MISSES: (counter: all) Last level cache demand requests from this core that missed the LLC (min count: 6000) Unit masks (default 0x41) ---------- 0x41: No unit mask LLC_REFS: (counter: all) Last level cache demand requests from this core (min count: 6000) Unit masks (default 0x4f) ---------- 0x4f: No unit mask BR_MISS_PRED_RETIRED: (counter: all) number of mispredicted branches retired (precise) (min count: 500) + opcontrol --shutdown Tested using oprofile 0.9.6. Signed-off-by:
Josh Hunt <johunt@akamai.com> Reviewed-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
Robert Richter <robert.richter@amd.com> Signed-off-by:
-
John Villalovos authored
commit 45c34e05 upstream. Back when the patch was submitted for "Add Xeon 7500 series support to oprofile", Robert Richter had asked for a followon patch that converted all the CPU ID values to hex. I have done that here for the "i386/core_i7" and "i386/atom" class processors in the ppro_init() function and also added some comments on where to find documentation on the Intel processors. Signed-off-by:
John L. Villalovos <john.l.villalovos@intel.com> Signed-off-by:
-
Dan Carpenter authored
commit 7e27a0ae upstream. We should unlock here. This is the only place where we return from the function with the lock held. The caller isn't expecting it. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
Tilman Schmidt <tilman@imap.cc> Signed-off-by:
-
Tilman Schmidt authored
commit 7d060ed2 upstream. Downgrade some error messages which occur frequently during normal operation to debug messages. Impact: logging Signed-off-by:
-
Marek Vasut authored
commit 01cd2aba upstream. Signed-off-by:
Marek Vasut <marek.vasut@gmail.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
-
David Howells authored
commit 31d1d48e upstream. Make /dev/console get initialised before any initialisation routine that invokes modprobe because if modprobe fails, it's going to want to open /dev/console, presumably to write an error message to. The problem with that is that if the /dev/console driver is not yet initialised, the chardev handler will call request_module() to invoke modprobe, which will fail, because we never compile /dev/console as a module. This will lead to a modprobe loop, showing the following in the kernel log: request_module: runaway loop modprobe char-major-5-1 request_module: runaway loop modprobe char-major-5-1 request_module: runaway loop modprobe char-major-5-1 request_module: runaway loop modprobe char-major-5-1 request_module: runaway loop modprobe char-major-5-1 This can happen, for example, when the built in md5 module can't find the built in cryptomgr module (because the latter fails to initialise). The md5 module comes before the call to tty_init(), presumably because 'crypto' comes before 'drivers' alphabetically. Fix this by calling tty_init() from chrdev_init(). Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Changli Gao authored
[ Upstream commit 072d79a3 ] pskb_may_pull() may change skb pointers, so adjust icmph after pskb_may_pull(). Signed-off-by:
Changli Gao <xiaosuo@gmail.com> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Changli Gao authored
[ Upstream commit cece1945 ] Although netif_rx() isn't expected to be called in process context with preemption enabled, it'd better handle this case. And this is why get_cpu() is used in the non-RPS #ifdef branch. If tree RCU is selected, rcu_read_lock() won't disable preemption, so preempt_disable() should be called explictly. Signed-off-by:
-
Jarek Poplawski authored
[ Upstream commit 41065fba ] sch_sfq as a classful qdisc needs the .leaf handler. Otherwise, there is an oops possible in tc_modify_qdisc()/check_loop(). Fixes commit 7d2681a6Signed-off-by:
Jarek Poplawski <jarkao2@gmail.com> Signed-off-by:
-
Jarek Poplawski authored
[ Upstream commit eb4a5527 ] Since there was added ->tcf_chain() method without ->bind_tcf() to sch_sfq class options, there is oops when a filter is added with the classid parameter. Fixes commit 7d2681a6 netdev thread: null pointer at cls_api.c Signed-off-by:
Franchoze Eric <franchoze@yandex.ru> Signed-off-by:
-
Jarek Poplawski authored
[ Upstream commit e5093aec ] >Xin Xiaohui wrote: > I looked into the code dev_gro_receive(), found the code here: > if the frags[0] is pulled to 0, then the page will be released, > and memmove() frags left. > Is that right? I'm not sure if memmove do right or not, but > frags[0].size is never set after memove at least. what I think > a simple way is not to do anything if we found frags[0].size == 0. > The patch is as followed. ... This version of the patch fixes the bug directly in memmove. Reported-by:
"Xin, Xiaohui" <xiaohui.xin@intel.com> Signed-off-by:
-
Jarek Poplawski authored
[ Upstream commit ce9e76c8 ] The netpoll_rx_on() check in __napi_gro_receive() skips part of the "common" GRO_NORMAL path, especially "pull:" in dev_gro_receive(), where at least eth header should be copied for entirely paged skbs. Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 4b030d42 ] The main motivation of this patch changing strcpy() to strlcpy(). We strcpy() to copy a 48 byte buffers into a 49 byte buffers. So at best the last byte has leaked information, or maybe there is an overflow? Anyway, this patch closes the information leaks by zeroing the memory and the calls to strlcpy() prevent overflows. Signed-off-by:
-
Oliver Hartkopp authored
[ Upstream commit 5b75c497 ] This patch adds a limit for nframes as the number of frames in TX_SETUP and RX_SETUP are derived from a single byte multiplex value by default. Use-cases that would require to send/filter more than 256 CAN frames should be implemented in userspace for complexity reasons anyway. Additionally the assignments of unsigned values from userspace to signed values in kernelspace and vice versa are fixed by using unsigned values in kernelspace consistently. Signed-off-by:
Ben Hawkes <hawkes@google.com> Acked-by:
Urs Thuermann <urs.thuermann@volkswagen.de> Signed-off-by:
-
Changli Gao authored
[ Upstream commit 3a3dfb06 ] after updating the value of the ICMP payload, inet_proto_csum_replace4() should be called with zero pseudohdr. Signed-off-by:
-
Herbert Xu authored
[ Upstream commit 6d1d1d39 ] On the bridge TX path we're leaking an skb when br_multicast_rcv returns an error. Reported-by:
David Lamparter <equinox@diac24.net> Signed-off-by:
-
Dmitry Popov authored
[ Upstream commit a3bdb549 ] There is a bug in do_tcp_setsockopt(net/ipv4/tcp.c), TCP_COOKIE_TRANSACTIONS case. In some cases (when tp->cookie_values == NULL) new tcp_cookie_values structure can be allocated (at cvp), but not bound to tp->cookie_values. So a memory leak occurs. Signed-off-by:
Dmitry Popov <dp@highloadlab.com> Signed-off-by:
-
