- 20 Jun, 2013 3 commits
-
-
Jim Schutt authored
commit c420276a upstream. In his review, Alex Elder mentioned that he hadn't checked that num_fcntl_locks and num_flock_locks were properly decoded on the server side, from a le32 over-the-wire type to a cpu type. I checked, and AFAICS it is done; those interested can consult Locker::_do_cap_update() in src/mds/Locker.cc and src/include/encoding.h in the Ceph server code (git://github.com/ceph/ceph). I also checked the server side for flock_len decoding, and I believe that also happens correctly, by virtue of having been declared __le32 in struct ceph_mds_cap_reconnect, in src/include/ceph_fs.h. Signed-off-by:
Jim Schutt <jaschut@sandia.gov> Reviewed-by:
Alex Elder <elder@inktank.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alex Elder authored
commit 14d2f38d upstream. An osd client has a red-black tree describing its osds, and occasionally we would get crashes due to one of these trees tree becoming corrupt somehow. The problem turned out to be that reset_changed_osds() was being called without protection of the osd client request mutex. That function would call __reset_osd() for any osd that had changed, and __reset_osd() would call __remove_osd() for any osd with no outstanding requests, and finally __remove_osd() would remove the corresponding entry from the red-black tree. Thus, the tree was getting modified without having any lock protection, and was vulnerable to problems due to concurrent updates. This appears to be the only osd tree updating path that has this problem. It can be fairly easily fixed by moving the call up a few lines, to just before the request mutex gets dropped in kick_requests(). This resolves: http://tracker.ceph.com/issues/5043Signed-off-by:
Sage Weil <sage@inktank.com> Signed-off-by:
-
Kees Cook authored
commit e0e29b68 upstream. The module parameter "fwpostfix" is userspace controllable, unfiltered, and is used to define the firmware filename. b43_do_request_fw() populates ctx->errors[] on error, containing the firmware filename. b43err() parses its arguments as a format string. For systems with b43 hardware, this could lead to a uid-0 to ring-0 escalation. CVE-2013-2852 Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
- 13 Jun, 2013 33 commits
-
-
Greg Kroah-Hartman authored
-
Steven Rostedt authored
commit 7f49ef69 upstream. As ftrace_filter_lseek is now used with ftrace_pid_fops, it needs to be moved out of the #ifdef CONFIG_DYNAMIC_FTRACE section as the ftrace_pid_fops is defined when DYNAMIC_FTRACE is not. Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Cc: Namhyung Kim <namhyung@kernel.org> [ lizf: adjust context ] Signed-off-by:
Li Zefan <lizefan@huawei.com> Signed-off-by:
-
Namhyung Kim authored
commit 6a76f8c0 upstream. Currently set_ftrace_pid and set_graph_function files use seq_lseek for their fops. However seq_open() is called only for FMODE_READ in the fops->open() so that if an user tries to seek one of those file when she open it for writing, it sees NULL seq_file and then panic. It can be easily reproduced with following command: $ cd /sys/kernel/debug/tracing $ echo 1234 | sudo tee -a set_ftrace_pid In this example, GNU coreutils' tee opens the file with fopen(, "a") and then the fopen() internally calls lseek(). Link: http://lkml.kernel.org/r/1365663302-2170-1-git-send-email-namhyung@kernel.orgSigned-off-by:
Namhyung Kim <namhyung@kernel.org> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Namhyung Kim <namhyung.kim@lge.com> Signed-off-by:
-
Patrik Jakobsson authored
commit cbbd379a upstream. By having a higher max resolution we can now set up a virtual framebuffer that spans several monitors. 4096 should be ok since we're gen 3 or higher and should be enough for most dual head setups. Bugzilla: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-modesetting/+bug/1169147Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by:
-
Ying Xue authored
commit a816e311 upstream. Pointers should not be compared to plain integers. Quiets the sparse warning: warning: Using plain integer as NULL pointer Signed-off-by:
Ying Xue <ying.xue@windriver.com> Cc: Lotfi Manseur <lotfi.manseur@gmail.com> Signed-off-by:
-
Jan Beulich authored
commit 51ac8893 upstream. ... as being guest triggerable (e.g. by invoking XEN_PCI_OP_enable_msi{,x} on a device not being MSI/MSI-X capable). This is CVE-2013-0231 / XSA-43. Also make the two messages uniform in both their wording and severity. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Acked-by:
Ian Campbell <ian.campbell@citrix.com> Reviewed-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [stable tree: Added two extra #include files] Signed-off-by:
-
Ben Mesman authored
commit 45a211d7 upstream. Last year, a patch was made for the "HP t5740e Thin Client" (see http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html). This device reports an lvds panel, but does not really have one. The predecessor of this device is the "hp t5740", which also does not have an lvds panel. This patch will add the same quirk for this device. Signed-off-by:
Ben Mesman <ben@bnc.nl> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Egbert Eich authored
commit 53d3b4d7 upstream. In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used for DDC. Thus the code will always have to rely on a LVDS panel mode supplied by VBT. In most cases this succeeds, so this didn't get detected for quite a while. This regression seems to have been introduced in commit f899fc64 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jul 20 15:44:45 2010 -0700 drm/i915: use GMBUS to manage i2c links Signed-off-by:
Egbert Eich <eich@suse.de> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> [danvet: Add note about which commit likely introduced this issue.] Signed-off-by:
-
Huacai Chen authored
commit b7ea85a4 upstream. When GPU acceleration is disabled, drm_vblank_cleanup() will free the vblank-related data, such as vblank_refcount, vblank_inmodeset, etc. But we found that drm_vblank_post_modeset() may be called after the cleanup, which use vblank_refcount and vblank_inmodeset. And this will cause a kernel panic. Fix this by return immediately if dev->num_crtcs is zero. This is the same thing that drm_vblank_pre_modeset() does. Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup(): [ 62.628906] [<ffffffff804868d0>] drm_vblank_post_modeset+0x34/0xb4 [ 62.628906] [<ffffffff804c7008>] atombios_crtc_dpms+0xb4/0x174 [ 62.628906] [<ffffffff804c70e0>] atombios_crtc_commit+0x18/0x38 [ 62.628906] [<ffffffff8047f038>] drm_crtc_helper_set_mode+0x304/0x3cc [ 62.628906] [<ffffffff8047f92c>] drm_crtc_helper_set_config+0x6d8/0x988 [ 62.628906] [<ffffffff8047dd40>] drm_fb_helper_set_par+0x94/0x104 [ 62.628906] [<ffffffff80439d14>] fbcon_init+0x424/0x57c [ 62.628906] [<ffffffff8046a638>] visual_init+0xb8/0x118 [ 62.628906] [<ffffffff8046b9f8>] take_over_console+0x238/0x384 [ 62.628906] [<ffffffff80436df8>] fbcon_takeover+0x7c/0xdc [ 62.628906] [<ffffffff8024fa20>] notifier_call_chain+0x44/0x94 [ 62.628906] [<ffffffff8024fcbc>] __blocking_notifier_call_chain+0x48/0x68 [ 62.628906] [<ffffffff8042d990>] register_framebuffer+0x228/0x260 [ 62.628906] [<ffffffff8047e010>] drm_fb_helper_single_fb_probe+0x260/0x314 [ 62.628906] [<ffffffff8047e2c4>] drm_fb_helper_initial_config+0x200/0x234 [ 62.628906] [<ffffffff804e5560>] radeon_fbdev_init+0xd4/0xf4 [ 62.628906] [<ffffffff804e0e08>] radeon_modeset_init+0x9bc/0xa18 [ 62.628906] [<ffffffff804bfc14>] radeon_driver_load_kms+0xdc/0x12c [ 62.628906] [<ffffffff8048b548>] drm_get_pci_dev+0x148/0x238 [ 62.628906] [<ffffffff80423564>] local_pci_probe+0x5c/0xd0 [ 62.628906] [<ffffffff80241ac4>] work_for_cpu_fn+0x1c/0x30 [ 62.628906] [<ffffffff802427c8>] process_one_work+0x274/0x3bc [ 62.628906] [<ffffffff80242934>] process_scheduled_works+0x24/0x44 [ 62.628906] [<ffffffff8024515c>] worker_thread+0x31c/0x3f4 [ 62.628906] [<ffffffff802497a8>] kthread+0x88/0x90 [ 62.628906] [<ffffffff80206794>] kernel_thread_helper+0x10/0x18 Signed-off-by:
Huacai Chen <chenhc@lemote.com> Signed-off-by:
Binbin Zhou <zhoubb@lemote.com> Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Acked-by:
Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
-
Guenter Roeck authored
commit 591bfcfc upstream. On a system with both MAX1617 and JC42 sensors, JC42 sensors can be misdetected as LM84. Strengthen detection sufficiently enough to avoid this misdetection. Also improve detection for ADM1021. Modeled after chip detection code in sensors-detect command. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Jean Delvare <khali@linux-fr.org> Acked-by:
-
Alex Deucher authored
commit 1cbcca30 upstream. It's not supported yet. Fixes display issues when users force it on. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Adis Hamzić authored
commit e49f3959 upstream. The current radeon driver initialization routines, when using KMS, are written so that the IRQ installation routine is called before initializing the WB buffer and the CP rings. With some ASICs, though, the IRQ routine tries to access the GFX_INDEX ring causing a call to RREG32 with the value of -1 in radeon_fence_read. This, in turn causes the system to completely hang with some cards, requiring a hard reset. A call stack that can cause such a hang looks like this (using rv515 ASIC for the example here): * rv515_init (rv515.c) * radeon_irq_kms_init (radeon_irq_kms.c) * drm_irq_install (drm_irq.c) * radeon_driver_irq_preinstall_kms (radeon_irq_kms.c) * rs600_irq_process (rs600.c) * radeon_fence_process - due to SW interrupt (radeon_fence.c) * radeon_fence_read (radeon_fence.c) * hang due to RREG32(-1) The patch moves the IRQ installation to the card startup routine, after the ring has been initialized, but before the IRQ has been set. This fixes the issue, but requires a check to see if the IRQ is already installed, as is the case in the system resume codepath. I have tested the patch on three machines using the rv515, the rv770 and the evergreen ASIC. They worked without issues. This seems to be a known issue and has been reported on several bug tracking sites by various distributions (see links below). Most of reports recommend booting the system with KMS disabled and then enabling KMS by reloading the radeon module. For some reason, this was indeed a usable workaround, however, UMS is now deprecated and disabled by default. Bug reports: https://bugzilla.redhat.com/show_bug.cgi?id=845745 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/561789 https://bbs.archlinux.org/viewtopic.php?id=156964Signed-off-by:
Adis Hamzić <adis@hamzadis.com> Signed-off-by:
-
Gavin Shan authored
commit b8b3de22 upstream. RTAS token "ibm,get-config-addr-info" or ibm,get-config-addr-info2" are used to retrieve the PE address according to PCI address, which made up of domain/bus/slot/function. If we don't have those 2 tokens, the domain/bus/slot/function would be used as the address for EEH RTAS operations. Some older f/w might not have those 2 tokens and that blocks the EEH functionality to be initialized. It was introduced by commit e2af155c ("powerpc/eeh: pseries platform EEH initialization"). The patch skips the check on those 2 tokens so we can bring up EEH functionality successfully. And domain/bus/slot/function will be used as address for EEH RTAS operations. Reported-by:
Robert Knight <knight@princeton.edu> Signed-off-by:
Gavin Shan <shangw@linux.vnet.ibm.com> Tested-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Ash Willis authored
commit 780a6ec6 upstream. This patch addresses kernel bug 56661. BIOS reports an incorrect backlight value, causing the driver to switch off the backlight completely during startup. This patch ignores the incorrect value from BIOS. References: https://bugzilla.kernel.org/show_bug.cgi?id=56661Signed-off-by:
Ash Willis <ashwillis@programmer.net> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Alex Hung authored
commit fedbe9bc upstream. On HP m4 lapops, BIOS reports minimum backlight on boot and causes backlight to dim completely. This ignores the initial backlight values and set to max brightness. References: https://bugs.launchpad.net/bugs/1184501Signed-off-by:
Alex Hung <alex.hung@canonical.com> Signed-off-by:
-
Johan Hovold authored
commit a26f009a upstream. The register access to enable hardware flow control depends on the device port number and not the port minor number. Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Johan Hovold authored
commit 849513a7 upstream. The control and bulk-message timeouts are specified in milliseconds and should not depend on HZ. Signed-off-by:
-
Johan Hovold authored
commit 72ea18a5 upstream. The read_mos_reg function is called with stack-allocated buffers, which must not be used for control messages. Signed-off-by:
-
Alan Stern authored
commit fdc03438 upstream. This patch reverts commit 3e619d04 (USB: EHCI: fix bug in scheduling periodic split transfers). The commit was valid -- it fixed a real bug -- but the periodic scheduler in ehci-hcd is in such bad shape (especially the part that handles split transactions) that fixing one bug is very likely to cause another to surface. That's what happened in this case; the result was choppy and noisy playback on certain 24-bit audio devices. The only real fix will be to rewrite this entire section of code. My next project... This fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110. Thanks to Tim Richardson for extra testing and feedback, and to Joseph Salisbury and Tyson Tan for tracking down the original source of the problem. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> CC: Joseph Salisbury <joseph.salisbury@canonical.com> CC: Tim Richardson <tim@tim-richardson.net> Signed-off-by:
-
Johan Hovold authored
commit 5f8e2c07 upstream. The first and second interrupt-in urbs are swapped for some Treo/Kyocera devices, but the urb context was never updated with the new port. Signed-off-by:
-
Johan Hovold authored
commit 9eecf22d upstream. When configuring the port (e.g. set_termios) the port minor number rather than the port number was used in the request (and they only coincide for minor number 0). Signed-off-by:
-
Robert Butora authored
commit 6529591e upstream. The patch adds a new HIDCOM device and does not affect other devices driven by the cypress_M8 module. Changes are: - add VendorID ProductID to device tables - skip unstable speed check because FRWD uses 115200bps - skip reset at probe which is an issue workaround for this particular device. Signed-off-by:
Robert Butora <robert.butora.fi@gmail.com> Signed-off-by:
-
Johan Hovold authored
commit 420021a3 upstream. Fix regression introduced by commit 214916f2 ("USB: visor: reimplement using generic framework") which broke initialisation of Treo/Kyocera devices that re-mapped bulk-in endpoints. Signed-off-by:
-
Johan Hovold authored
commit 63437191 upstream. The control-message timeout is specified in milliseconds and should not depend on HZ. Signed-off-by:
-
Johan Hovold authored
commit a0708809 upstream. The outcont_endpoints array was indexed using the port minor number (which can be greater than the array size) rather than the device port number. Signed-off-by:
-
Johan Hovold authored
commit 6c13ff68 upstream. The bulk-message timeout is specified in milliseconds and should not depend on HZ. Signed-off-by:
-
Takashi Iwai authored
commit 11e7064f upstream. USB audio driver spews an error message when probing Logitech HD webcam c270: ALSA mixer.c:1300 usb_audio: Warning! Unlikely big volume range (=6144), cval->res is probably wrong. ALSA mixer.c:1304 usb_audio: [5] FU [Mic Capture Volume] ch = 1, val = 1536/7680/1 Obviously the device needs a fixed volume resolution (cval->res = 384) like other Logitech devices. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=821735Reported-and-tested-by:
Cristian Rodríguez <crrodriguez@opensuse.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit 8eafc0a1 upstream. ... instead of applying to all interfaces. Reference: http://forums.gentoo.org/viewtopic-p-6886404.htmlSigned-off-by:
-
Clemens Ladisch authored
commit a0c6d309 upstream. Commit 927c9423 (ALSA: usb-audio: add Edirol UM-3G support) used a wrong quirk type, which would make the driver refuse to attach with the error message "MIDIStreaming interface descriptor not found". Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Vladimir Murzin authored
commit 88696ae4 upstream. If for whatever reason we fall into fail path in xhci_mem_init() before bw table gets initialized we may access the uninitialized lists in xhci_mem_cleanup(). Check for bw table before traversing lists in cleanup routine. This patch should be backported to kernels as old as 3.2, that contain the commit 839c817c "xhci: Store information about roothubs and TTs." Reported-by:
Sergey Dyasly <dserrg@gmail.com> Tested-by:
Vladimir Murzin <murzin.v@gmail.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Sergio Aguirre authored
commit 331de00a upstream. It is possible that we fail on xhci_mem_init, just before doing the INIT_LIST_HEAD, and calling xhci_mem_cleanup. Problem is that, the list_for_each_entry_safe macro, assumes list heads are initialized (not NULL), and dereferences their 'next' pointer, causing a kernel panic if this is not yet initialized. Let's protect from that by moving inits to the beginning. This patch should be backported to kernels as old as 3.2, that contain the commit 9574323c "xHCI: test USB2 software LPM". Signed-off-by:
Sergio Aguirre <sergio.a.aguirre.rodriguez@intel.com> Acked-by:
David Cohen <david.a.cohen@intel.com> Signed-off-by:
-
Tony Camuso authored
commit 77df9e0b upstream. Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware) was a workaround for systems using the SN65LVPE502CP, controller, but it introduced a bug in resume from hibernate. The fix created a timer, comp_mode_recovery_timer, which is deleted from a timer list when xhci_suspend() is called. However, the hibernate image, including the timer list containing the comp_mode_recovery_timer, had already been saved before the timer was deleted. Upon resume from hibernate, the list containing the comp_mode_recovery_timer is restored from the image saved to disk, and xhci_resume(), assuming that the timer had been deleted by xhci_suspend(), makes a call to compliance_mode_recoery_timer_init(), which creates a new instance of the comp_mode_recovery_timer and attempts to place it into the same list in which it is already active, thus corrupting the list during the list_add() call. At this point, a call trace is emitted indicating the list corruption. Soon afterward, the system locks up, the watchdog times out, and the ensuing NMI crashes the system. The problem did not occur when resuming from suspend. In suspend, the image in RAM remains exactly as it was when xhci_suspend() deleted the comp_mode_recovery_timer, so there is no problem when xhci_resume() creates a new instance of this timer and places it in the still empty list. This patch avoids the problem by deleting the timer in xhci_resume() when resuming from hibernate. Now xhci_resume() can safely make the call to create a new instance of this timer, whether returning from suspend or hibernate. Thanks to Alan Stern for his help with understanding the problem. [Sarah reworked this patch to cover the case where the xHCI restore register operation fails, and (temp & STS_SRE) is true (and we re-init the host, including re-init for the compliance mode), but hibernate is false. The original patch would have caused list corruption in this case.] This patch should be backported to kernels as old as 3.2, that contain the commit 71c731a2 "usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware" Signed-off-by:
Tony Camuso <tcamuso@redhat.com> Tested-by:
Don Zickus <dzickus@redhat.com> Signed-off-by:
-
Bjørn Mork authored
commit b8a24e62 upstream. The mode used by Windows for the Huawei E1820 will use the same ff/ff/ff class codes for both serial and network functions. Reported-by:
Graham Inggs <graham.inggs@uct.ac.za> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
- 07 Jun, 2013 4 commits
-
-
Greg Kroah-Hartman authored
-
Manoj Iyer authored
commit a4f46bb9 upstream. In the latest V-series bios DMI_PRODUCT_VERSION does not contain the string Lenovo or Thinkpad, but is set to the model number, this causes the thinkpad_acpi module to fail to load. Recognize laptop as Lenovo using DMI_BIOS_VENDOR instead, which is set to Lenovo. Test on V490u ============= == After the patch == [ 1350.295757] thinkpad_acpi: ThinkPad ACPI Extras v0.24 [ 1350.295760] thinkpad_acpi: http://ibm-acpi.sf.net/ [ 1350.295761] thinkpad_acpi: ThinkPad BIOS H7ET21WW (1.00 ), EC unknown [ 1350.295763] thinkpad_acpi: Lenovo LENOVO, model LV5DXXX [ 1350.296086] thinkpad_acpi: detected a 8-level brightness capable ThinkPad [ 1350.296694] thinkpad_acpi: radio switch found; radios are enabled [ 1350.296703] thinkpad_acpi: possible tablet mode switch found; ThinkPad in laptop mode [ 1350.306466] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [ 1350.307082] Registered led device: tpacpi::thinklight [ 1350.307215] Registered led device: tpacpi::power [ 1350.307255] Registered led device: tpacpi::standby [ 1350.307294] Registered led device: tpacpi::thinkvantage [ 1350.308160] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one [ 1350.308333] thinkpad_acpi: Console audio control enabled, mode: monitor (read only) [ 1350.312287] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input14 == Before the patch == sudo modprobe thinkpad_acpi FATAL: Error inserting thinkpad_acpi (/lib/modules/3.2.0-27-generic/kernel/drivers/platform/x86/thinkpad_acpi.ko): No such device Test on B485 ============= This patch was also test in a B485 where the thinkpad_acpi module does not have any issues loading. But, I tested it to make sure this patch does not break on already functioning models of Lenovo products. [13486.746359] thinkpad_acpi: ThinkPad ACPI Extras v0.24 [13486.746364] thinkpad_acpi: http://ibm-acpi.sf.net/ [13486.746368] thinkpad_acpi: ThinkPad BIOS HJET15WW(1.01), EC unknown [13486.746373] thinkpad_acpi: Lenovo Lenovo LB485, model 814TR01 [13486.747300] thinkpad_acpi: detected a 8-level brightness capable ThinkPad [13486.752435] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [13486.752883] Registered led device: tpacpi::thinklight [13486.752915] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one [13486.753216] thinkpad_acpi: Console audio control enabled, mode: monitor (read only) [13486.757147] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input15 Signed-off-by:
Manoj Iyer <manoj.iyer@canonical.com> Signed-off-by:
Matthew Garrett <mjg@redhat.com> Cc: Shuduo Sang <shuduo.sang@canonical.com> Signed-off-by:
-
Johannes Berg authored
commit c8aa22db upstream. Since Eric's commit efe117ab ("Speedup ieee80211_remove_interfaces") there's a bug in mac80211 when it unregisters with AP_VLAN interfaces up. If the AP_VLAN interface was registered after the AP it belongs to (which is the typical case) and then we get into this code path, unregister_netdevice_many() will crash because it isn't prepared to deal with interfaces being closed in the middle of it. Exactly this happens though, because we iterate the list, find the AP master this AP_VLAN belongs to and dev_close() the dependent VLANs. After this, unregister_netdevice_many() won't pick up the fact that the AP_VLAN is already down and will do it again, causing a crash. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
-
Martin Pelikan authored
commit 9271b0b4 upstream. The latest GCC 4.8 does some more checking on type attributes that break the build for ARCH=um -> fill them in. Specifically, the "asmlinkage" attributes is now tested for consistency. Signed-off-by:
Martin Pelikan <pelikan@storkhole.cz> Link: http://lkml.kernel.org/r/1339269731-10772-1-git-send-email-pelikan@storkhole.czAcked-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Cc: Bernhard M. Wiedemann <bwiedemann@suse.de> Signed-off-by:
-
