aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2012-10-24dynamic_debug: Remove unnecessary __usedJoe Perches1-1/+1
The __used attribute prevents gcc from eliminating unnecessary, otherwise optimized away, metadata for debugging logging messages. Remove the __used attribute. Signed-off-by: Joe Perches <[email protected]> Acked-by: Jason Baron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-10-24Drivers: hv: Cleanup error handling in vmbus_open()K. Y. Srinivasan1-11/+13
Fix a memory leak in the error handling path in the function vmbus_open(). Signed-off-by: K. Y. Srinivasan <[email protected]> Reviewed-by: Haiyang Zhang <[email protected]> Reported-by: Jason Wang <[email protected]> Cc: Stable <[email protected]> Acked-by: Jason Wang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-10-24staging: ipack: add missing include (implicit declaration of function 'kfree')Sergei Trofimovich1-0/+1
On ARCH=alpha make allmodconfig: linux-2.6/drivers/staging/ipack/bridges/tpci200.c: In function 'tpci200_free_irq': linux-2.6/drivers/staging/ipack/bridges/tpci200.c:188:2: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration] linux-2.6/drivers/staging/ipack/bridges/tpci200.c: In function 'tpci200_request_irq': linux-2.6/drivers/staging/ipack/bridges/tpci200.c:215:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] Fixed by adding <linux/slab.h> header CC: Greg Kroah-Hartman <[email protected]> CC: Samuel Iglesias Gonsalvez <[email protected]> CC: Jens Taprogge <[email protected]> CC: "Miguel Gómez" <[email protected]> CC: [email protected] Signed-off-by: Sergei Trofimovich <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-10-24usb-storage: add unusual_devs entry for Casio EX-N1 digital cameraMichael Shigorin1-0/+6
This commit sets removable subclass for Casio EX-N1 digital camera. The patch has been tested within an ALT Linux kernel: http://git.altlinux.org/people/led/packages/?p=kernel-image-3.0.git;a=commitdiff;h=c0fd891836e89fe0c93a4d536a59216d90e4e3e7 See also https://bugzilla.kernel.org/show_bug.cgi?id=49221 Signed-off-by: Oleksandr Chumachenko <[email protected]> Signed-off-by: Michael Shigorin <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-10-24x86, mm: Find_early_table_space based on ranges that are actually being mappedJacob Shin1-29/+41
Current logic finds enough space for direct mapping page tables from 0 to end. Instead, we only need to find enough space to cover mr[0].start to mr[nr_range].end -- the range that is actually being mapped by init_memory_mapping() This is needed after 1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a, to address the panic reported here: https://lkml.org/lkml/2012/10/20/160 https://lkml.org/lkml/2012/10/21/157 Signed-off-by: Jacob Shin <[email protected]> Link: http://lkml.kernel.org/r/20121024195311.GB11779@jshin-Toonie Tested-by: Tom Rini <[email protected]> Signed-off-by: H. Peter Anvin <[email protected]>
2012-10-24workqueue: cancel_delayed_work() should return %false if work item is idleDan Magenheimer1-1/+1
57b30ae77b ("workqueue: reimplement cancel_delayed_work() using try_to_grab_pending()") made cancel_delayed_work() always return %true unless someone else is also trying to cancel the work item, which is broken - if the target work item is idle, the return value should be %false. try_to_grab_pending() indicates that the target work item was idle by zero return value. Use it for return. Note that this brings cancel_delayed_work() in line with __cancel_work_timer() in return value handling. Signed-off-by: Dan Magenheimer <[email protected]> Signed-off-by: Tejun Heo <[email protected]> LKML-Reference: <444a6439-b1a4-4740-9e7e-bc37267cfe73@default>
2012-10-24Revert "serial: omap: fix software flow control"Felipe Balbi2-8/+8
This reverts commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6 (serial: omap: fix software flow control). As Russell has pointed out, that commit isn't fixing Software Flow Control at all, and it actually makes it even more broken. It was agreed to revert this commit and use Russell's latest UART patches instead. Cc: Russell King <[email protected]> Signed-off-by: Felipe Balbi <[email protected]> Acked-by: Tony Lindgren <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-10-24x86, mm: Use memblock memory loop instead of e820_RAMYinghai Lu1-7/+8
We need to handle E820_RAM and E820_RESERVED_KERNEL at the same time. Also memblock has page aligned range for ram, so we could avoid mapping partial pages. Signed-off-by: Yinghai Lu <[email protected]> Link: http://lkml.kernel.org/r/CAE9FiQVZirvaBMFYRfXMmWEcHbKSicQEHz4VAwUv0xFCk51ZNw@mail.gmail.com Acked-by: Jacob Shin <[email protected]> Signed-off-by: H. Peter Anvin <[email protected]> Cc: <[email protected]>
2012-10-24x86, mm: Trim memory in memblock to be page alignedYinghai Lu3-0/+28
We will not map partial pages, so need to make sure memblock allocation will not allocate those bytes out. Also we will use for_each_mem_pfn_range() to loop to map memory range to keep them consistent. Signed-off-by: Yinghai Lu <[email protected]> Link: http://lkml.kernel.org/r/CAE9FiQVZirvaBMFYRfXMmWEcHbKSicQEHz4VAwUv0xFCk51ZNw@mail.gmail.com Acked-by: Jacob Shin <[email protected]> Signed-off-by: H. Peter Anvin <[email protected]> Cc: <[email protected]>
2012-10-24USB: serial: Fix memory leak in sierra_release()Lennart Sorensen1-0/+1
I found a memory leak in sierra_release() (well sierra_probe() I guess) that looses 8 bytes each time the driver releases a device. Signed-off-by: Len Sorensen <[email protected]> Acked-by: Johan Hovold <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-10-24b43: Fix oops on unload when firmware not foundLarry Finger1-0/+4
When b43 fails to find firmware when loaded, a subsequent unload will oops due to calling ieee80211_unregister_hw() when the corresponding register call was never made. Commit 2d838bb608e2d1f6cb4280e76748cb812dc822e7 fixed the same problem for b43legacy. Signed-off-by: Larry Finger <[email protected]> Tested-by: Markus Kanet <[email protected]> Cc: Stable <[email protected]> [V3.3.0+ (the patch will need to be refactored)] Cc: Markus Kanet <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2012-10-24mwifiex: clean up scan state on errorBing Zhao1-2/+5
De-reference and deallocate scan state on failure. Signed-off-by: Bing Zhao <[email protected]> Signed-off-by: Paul Stewart <[email protected]> Tested-by: Paul Stewart <[email protected]> Reviewed-by: Ryan Cairns <[email protected]> Signed-off-by: Amitkumar Karwar <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2012-10-24mwifiex: return -EBUSY if specific scan request cannot be honoredBing Zhao1-8/+5
Previous patch "mwifiex: return -EBUSY if scan request cannot.." corrected regular scan request only. There is another case for specific scan that needs the same handling. Also, removed !req_ssid check as it has already been validated by caller. Signed-off-by: Bing Zhao <[email protected]> Signed-off-by: Paul Stewart <[email protected]> Reviewed-by: Ryan Cairns <[email protected]> Signed-off-by: Amitkumar Karwar <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2012-10-24brcmfmac: fix potential NULL dereferenceYuanhan Liu1-1/+1
Fix a samtch warnings catched by Fengguang's 0-DAY system: + drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c:3572 brcmf_cfg80211_sched_scan_start() error: we previously assumed 'request' could be null (see line 3571) Cc: John W. Linville <[email protected]> Signed-off-by: Yuanhan Liu <[email protected]> Acked-by: Franky Lin <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2012-10-24Revert "ath9k_hw: Updated AR9003 tx gain table for 5GHz"Felix Fietkau1-82/+82
This reverts commit a240dc7b3c7463bd60cf0a9b2a90f52f78aae0fd. This commit is reducing tx power by at least 10 db on some devices, e.g. the Buffalo WZR-HP-G450H. Signed-off-by: Felix Fietkau <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: John W. Linville <[email protected]>
2012-10-24ath9k_htc: Add PID/VID for a Ubiquiti WiFiStationMohammed Shafi Shajakhan1-0/+1
Roger says, Ubiquiti produce 2 versions of their WiFiStation USB adapter. One has an internal antenna, the other has an external antenna and name suffix EXT. They have separate USB ids and in distribution openSUSE 12.2 (kernel 3.4.6), file /usr/share/usb.ids shows: 0cf3 Atheros Communications, Inc. ... b002 Ubiquiti WiFiStation 802.11n [Atheros AR9271] b003 Ubiquiti WiFiStationEXT 802.11n [Atheros AR9271] Add b002 Ubiquiti WiFiStation in the PID/VID list. Reported-by: Roger Price <[email protected]> Signed-off-by: Mohammed Shafi Shajakhan <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2012-10-24rt2x00: usb: fix reset resumeStanislaw Gruszka3-0/+3
Patch fixes warnings like below happened on resume: WARNING: at net/mac80211/driver-ops.h:12 check_sdata_in_driver+0x32/0x34() Problem is that in __ieee80211_susped() we remove sdata (i.e wlan0 interface) and then during resume we call usb_unbind_interface() -> ieee80211_unregister_hw() with sdata removed. Patch fixes problem by adding .reset_resume calback, hence we do not unbind usb device on resume. This callback can be the same as normal .resume callback, sice we do all needed initalization during interface start, which is performed on resume [ ieee80211_resume() -> ieee80211_reconfig() -> rt2x00mac_start() -> rt2x00lib_start ]. Resolves: https://bugzilla.kernel.org/show_bug.cgi?id=48041 Reported-by: David Herrmann <[email protected]> Reported-and-tested-by: Stephen Boyd <[email protected]> Cc: [email protected] Signed-off-by: Stanislaw Gruszka <[email protected]> Acked-by: Gertjan van Wingerde <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2012-10-24rtlwifi: pass rx setup error code to callerChristian Lamparter1-1/+1
If _rtl_usb_receive fails, the device is probably not ready. Hence the error code should be passed to the caller, so it can react accordingly and notify the user. Signed-off-by: Christian Lamparter <[email protected]> Acked-by: Larry Finger <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2012-10-24ARM: at91: drop duplicated config SOC_AT91SAM9 entryJean-Christophe PLAGNIOL-VILLARD1-8/+2
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[email protected]> Acked-by: Nicolas Ferre <[email protected]>
2012-10-24ARM: at91/i2c: change id to let i2c-at91 workBo Shen9-11/+11
The i2c core driver will turn the platform device ID to busnum When using platfrom device ID as -1, it means dynamically assigned the busnum. When writing code, we need to make sure the busnum, and call i2c_register_board_info(int busnum, ...) to register device if using -1, we do not know the value of busnum In order to solve this issue, set the platform device ID as a fix number Here using 0 to match the busnum used in i2c_regsiter_board_info() Signed-off-by: Bo Shen <[email protected]> Signed-off-by: Nicolas Ferre <[email protected]> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <[email protected]> Acked-by: Ludovic Desroches <[email protected]>
2012-10-24ARM: at91/i2c: change id to let i2c-gpio workBo Shen5-5/+5
The i2c core driver will turn the platform device ID to busnum When using platfrom device ID as -1, it means dynamically assigned the busnum. When writing code, we need to make sure the busnum, and call i2c_register_board_info(int busnum, ...) to register device if using -1, we do not know the value of busnum In order to solve this issue, set the platform device ID as a fix number Here using 0 to match the busnum used in i2c_regsiter_board_info() Signed-off-by: Bo Shen <[email protected]> Acked-by: Jean Delvare <[email protected]> Signed-off-by: Nicolas Ferre <[email protected]> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <[email protected]> Acked-by: Ludovic Desroches <[email protected]> Cc: stable <[email protected]> [very long time]
2012-10-24ARM: at91/dts: at91sam9g20ek_common: Fix typos in buttons labels.Marek Belisko1-2/+2
Signed-off-by: Marek Belisko <[email protected]> Signed-off-by: Nicolas Ferre <[email protected]> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <[email protected]>
2012-10-24ARM: at91: fix external interrupt specification in board codeNicolas Ferre3-3/+3
Since the switch to sparse irq, we have to add the NR_IRQS_LEGACY offset to static irq numbers. It has been forgotten on these SPI irq definitions in board code. Signed-off-by: Nicolas Ferre <[email protected]> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <[email protected]> Acked-by: Ludovic Desroches <[email protected]> Cc: stable <[email protected]> [v3.6]
2012-10-24ARM: at91: fix external interrupts in non-DT caseNicolas Ferre3-4/+10
Management of external interrupts has changed but the non-DT code has not integrated these changes. Add a mask to pass external irq specification from SoC specific code to the at91_aic_init() function. Signed-off-by: Nicolas Ferre <[email protected]> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <[email protected]> Acked-by: Ludovic Desroches <[email protected]> Cc: stable <[email protected]> [v3.6]
2012-10-24ARM: at91: at91sam9g10: fix SOC type detectionIvan Shugov1-1/+1
Newer at91sam9g10 SoC revision can't be detected, so the kernel can't boot with this kind of kernel panic: "AT91: Impossible to detect the SOC type" CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 CPU: VIVT data cache, VIVT instruction cache Machine: Atmel AT91SAM9G10-EK Ignoring tag cmdline (using the default kernel command line) bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback Kernel panic - not syncing: AT91: Impossible to detect the SOC type [<c00133d4>] (unwind_backtrace+0x0/0xe0) from [<c02366dc>] (panic+0x78/0x1cc) [<c02366dc>] (panic+0x78/0x1cc) from [<c02fa35c>] (at91_map_io+0x90/0xc8) [<c02fa35c>] (at91_map_io+0x90/0xc8) from [<c02f9860>] (paging_init+0x564/0x6d0) [<c02f9860>] (paging_init+0x564/0x6d0) from [<c02f7914>] (setup_arch+0x464/0x704) [<c02f7914>] (setup_arch+0x464/0x704) from [<c02f44f8>] (start_kernel+0x6c/0x2d4) [<c02f44f8>] (start_kernel+0x6c/0x2d4) from [<20008040>] (0x20008040) The reason for this is that the Debug Unit Chip ID Register has changed between Engineering Sample and definitive revision of the SoC. Changing the check of cidr to socid will address the problem. We do not integrate this check to the list just above because we also have to make sure that the extended id is disregarded. Signed-off-by: Ivan Shugov <[email protected]> [[email protected]: change commit message] Signed-off-by: Nicolas Ferre <[email protected]> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <[email protected]> Cc: stable <[email protected]> [v3.1] # since commit 8c3583b6
2012-10-24ARM: at91/tc: fix typo in the DT documentJosh Wu1-1/+1
Signed-off-by: Josh Wu <[email protected]> Signed-off-by: Nicolas Ferre <[email protected]> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <[email protected]> Cc: stable <[email protected]> [v3.4]
2012-10-24drm/radeon: fix ATPX regression in acpi reworkAlex Deucher1-1/+1
Copy and paste typo in the apci rework. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=49351 Signed-off-by: Alex Deucher <[email protected]> Reviewed-by: Jerome Glisse <[email protected]>
2012-10-24drm/radeon: fix ATPX function documentationAlex Deucher1-2/+2
The ATPX code no longer handles ATRM. Signed-off-by: Alex Deucher <[email protected]>
2012-10-24drm/radeon: move the retry to gem_object_createChristian König2-11/+7
When internal users want VRAM we shouldn't return GART memory instead. Signed-off-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2012-10-24drm/radeon: move size limits to gem_object_create.Christian König2-9/+10
Driver internal users shouldn't be limited in their allocation size. Signed-off-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2012-10-24drm/radeon: use vzalloc for gart pagesChristian König1-6/+5
When allocating more than 2GB of GART the array of pages gets to big for kzalloc, use vzalloc instead. Signed-off-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2012-10-24drm/radeon: fix and simplify pot argument checks v3Christian König1-36/+24
GART and VRAM size limits need to be a power of two. Fix values greater than 1GB and simplify those checks a bit. v2: also fix radeon_vram_limit usage, and simplify test even more. v3: agd5f: fix spelling as noticed by Klaus Schnass Signed-off-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2012-10-25apparmor: fix IRQ stack overflow during free_profileJohn Johansen1-1/+23
BugLink: http://bugs.launchpad.net/bugs/1056078 Profile replacement can cause long chains of profiles to build up when the profile being replaced is pinned. When the pinned profile is finally freed, it puts the reference to its replacement, which may in turn nest another call to free_profile on the stack. Because this may happen for each profile in the replacedby chain this can result in a recusion that causes the stack to overflow. Break this nesting by directly walking the chain of replacedby profiles (ie. use iteration instead of recursion to free the list). This results in at most 2 levels of free_profile being called, while freeing a replacedby chain. Signed-off-by: John Johansen <[email protected]> Signed-off-by: James Morris <[email protected]>
2012-10-24iommu/tegra: smmu: Fix deadly typoHiro Sugawara1-1/+1
Fix a deadly typo in macro definition. Cc: [email protected] Signed-off-by: Hiro Sugawara <[email protected]> Signed-off-by: Hiroshi Doyu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2012-10-24LOCKD: Clear ln->nsm_clnt only when ln->nsm_users is zeroTrond Myklebust1-8/+6
The current code is clearing it in all cases _except_ when zero. Reported-by: Stanislav Kinsbursky <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Cc: [email protected]
2012-10-24LOCKD: fix races in nsm_client_getTrond Myklebust1-17/+26
Commit e9406db20fecbfcab646bad157b4cfdc7cadddfb (lockd: per-net NSM client creation and destruction helpers introduced) contains a nasty race on initialisation of the per-net NSM client because it doesn't check whether or not the client is set after grabbing the nsm_create_mutex. Reported-by: Nix <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Cc: [email protected]
2012-10-24SUNRPC: Get rid of the xs_error_report socket callbackTrond Myklebust1-25/+0
Chris Perl reports that we're seeing races between the wakeup call in xs_error_report and the connect attempts. Basically, Chris has shown that in certain circumstances, the call to xs_error_report causes the rpc_task that is responsible for reconnecting to wake up early, thus triggering a disconnect and retry. Since the sk->sk_error_report() calls in the socket layer are always followed by a tcp_done() in the cases where we care about waking up the rpc_tasks, just let the state_change callbacks take responsibility for those wake ups. Reported-by: Chris Perl <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Cc: [email protected] Tested-by: Chris Perl <[email protected]>
2012-10-24SUNRPC: Prevent races in xs_abort_connection()Trond Myklebust1-5/+8
The call to xprt_disconnect_done() that is triggered by a successful connection reset will trigger another automatic wakeup of all tasks on the xprt->pending rpc_wait_queue. In particular it will cause an early wake up of the task that called xprt_connect(). All we really want to do here is clear all the socket-specific state flags, so we split that functionality out of xs_sock_mark_closed() into a helper that can be called by xs_abort_connection() Reported-by: Chris Perl <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Cc: [email protected] Tested-by: Chris Perl <[email protected]>
2012-10-24Revert "SUNRPC: Ensure we close the socket on EPIPE errors too..."Trond Myklebust1-1/+1
This reverts commit 55420c24a0d4d1fce70ca713f84aa00b6b74a70e. Now that we clear the connected flag when entering TCP_CLOSE_WAIT, the deadlock described in this commit is no longer possible. Instead, the resulting call to xs_tcp_shutdown() can interfere with pending reconnection attempts. Reported-by: Chris Perl <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Cc: [email protected] Tested-by: Chris Perl <[email protected]>
2012-10-24SUNRPC: Clear the connect flag when socket state is TCP_CLOSE_WAITTrond Myklebust1-0/+1
This is needed to ensure that we call xprt_connect() upon the next call to call_connect(). Signed-off-by: Trond Myklebust <[email protected]> Cc: [email protected] Tested-by: Chris Perl <[email protected]>
2012-10-24amd64_edac:__amd64_set_scrub_rate(): avoid overindexing scrubrates[]Andrew Morton1-7/+4
If none of the elements in scrubrates[] matches, this loop will cause __amd64_set_scrub_rate() to incorrectly use the n+1th element. As the function is designed to use the final scrubrates[] element in the case of no match, we can fix this bug by simply terminating the array search at the n-1th element. Boris: this code is fragile anyway, see here why: http://marc.info/?l=linux-kernel&m=135102834131236&w=2 It will be rewritten more robustly soonish. Reported-by: Denis Kirjanov <[email protected]> Cc: [email protected] Cc: Doug Thompson <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Borislav Petkov <[email protected]>
2012-10-24ASoC: wm8994: Only enable extra BCLK cycles when requiredMark Brown2-1/+18
Rather than always assuming the maximum possible BCLK rate will be required generate BCLKs for stereo if either one or two channels is enabled. In order to support this we also need to ensure that only the relevant channels are enabled. Signed-off-by: Mark Brown <[email protected]>
2012-10-24dmaengine: sirf: fix a typo in moving running dma_desc to active queueBarry Song1-1/+1
list_move_tail(&schan->queued, &schan->active) makes the list_empty(schan->queued) undefined, we either should change it to: list_move_tail(schan->queued.next, &schan->active) or list_move_tail(&sdesc->node, &schan->active) Signed-off-by: Barry Song <[email protected]> Cc: stable <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
2012-10-24dmaengine: sirf: fix a typo in dma_prep_interleavedBarry Song1-1/+1
either DEV_TO_MEM or MEM_TO_DEV is supported, so change OR to AND. Signed-off-by: Barry Song <[email protected]> Cc: stable <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
2012-10-24x86/irq/ioapic: Check for valid irq_cfg pointer in ↵Dimitri Sivanich1-0/+3
smp_irq_move_cleanup_interrupt Posting this patch to fix an issue concerning sparse irq's that I raised a while back. There was discussion about adding refcounting to sparse irqs (to fix other potential race conditions), but that does not appear to have been addressed yet. This covers the only issue of this type that I've encountered in this area. A NULL pointer dereference can occur in smp_irq_move_cleanup_interrupt() if we haven't yet setup the irq_cfg pointer in the irq_desc.irq_data.chip_data. In create_irq_nr() there is a window where we have set vector_irq in __assign_irq_vector(), but not yet called irq_set_chip_data() to set the irq_cfg pointer. Should an IRQ_MOVE_CLEANUP_VECTOR hit the cpu in question during this time, smp_irq_move_cleanup_interrupt() will attempt to process the aforementioned irq, but panic when accessing irq_cfg. Only continue processing the irq if irq_cfg is non-NULL. Signed-off-by: Dimitri Sivanich <[email protected]> Cc: Suresh Siddha <[email protected]> Cc: Joerg Roedel <[email protected]> Cc: Yinghai Lu <[email protected]> Cc: Alexander Gordeev <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2012-10-24perf/x86: Remove unused variable in nhmex_rbox_alter_er()Wei Yongjun1-2/+0
The variable port is initialized but never used otherwise, so remove the unused variable. dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun <[email protected]> Cc: Yan, Zheng <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/CAPgLHd8NZkYSkZm22FpZxiEh6HcA0q-V%3D29vdnheiDhgrJZ%[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2012-10-24x86/efi: Fix oops caused by incorrect set_memory_uc() usageMatt Fleming3-15/+26
Calling __pa() with an ioremap'd address is invalid. If we encounter an efi_memory_desc_t without EFI_MEMORY_WB set in ->attribute we currently call set_memory_uc(), which in turn calls __pa() on a potentially ioremap'd address. On CONFIG_X86_32 this results in the following oops: BUG: unable to handle kernel paging request at f7f22280 IP: [<c10257b9>] reserve_ram_pages_type+0x89/0x210 *pdpt = 0000000001978001 *pde = 0000000001ffb067 *pte = 0000000000000000 Oops: 0000 [#1] PREEMPT SMP Modules linked in: Pid: 0, comm: swapper Not tainted 3.0.0-acpi-efi-0805 #3 EIP: 0060:[<c10257b9>] EFLAGS: 00010202 CPU: 0 EIP is at reserve_ram_pages_type+0x89/0x210 EAX: 0070e280 EBX: 38714000 ECX: f7814000 EDX: 00000000 ESI: 00000000 EDI: 38715000 EBP: c189fef0 ESP: c189fea8 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Process swapper (pid: 0, ti=c189e000 task=c18bbe60 task.ti=c189e000) Stack: 80000200 ff108000 00000000 c189ff00 00038714 00000000 00000000 c189fed0 c104f8ca 00038714 00000000 00038715 00000000 00000000 00038715 00000000 00000010 38715000 c189ff48 c1025aff 38715000 00000000 00000010 00000000 Call Trace: [<c104f8ca>] ? page_is_ram+0x1a/0x40 [<c1025aff>] reserve_memtype+0xdf/0x2f0 [<c1024dc9>] set_memory_uc+0x49/0xa0 [<c19334d0>] efi_enter_virtual_mode+0x1c2/0x3aa [<c19216d4>] start_kernel+0x291/0x2f2 [<c19211c7>] ? loglevel+0x1b/0x1b [<c19210bf>] i386_start_kernel+0xbf/0xc8 The only time we can call set_memory_uc() for a memory region is when it is part of the direct kernel mapping. For the case where we ioremap a memory region we must leave it alone. This patch reimplements the fix from e8c7106280a3 ("x86, efi: Calling __pa() with an ioremap()ed address is invalid") which was reverted in e1ad783b12ec because it caused a regression on some MacBooks (they hung at boot). The regression was caused because the commit only marked EFI_RUNTIME_SERVICES_DATA as E820_RESERVED_EFI, when it should have marked all regions that have the EFI_MEMORY_RUNTIME attribute. Despite first impressions, it's not possible to use ioremap_cache() to map all cached memory regions on CONFIG_X86_64 because of the way that the memory map might be configured as detailed in the following bug report, https://bugzilla.redhat.com/show_bug.cgi?id=748516 e.g. some of the EFI memory regions *need* to be mapped as part of the direct kernel mapping. Signed-off-by: Matt Fleming <[email protected]> Cc: Matthew Garrett <[email protected]> Cc: Zhang Rui <[email protected]> Cc: Huang Ying <[email protected]> Cc: Keith Packard <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Andrew Morton <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2012-10-24Btrfs: comment for loop in tree_mod_log_insert_moveJan Schmidt1-0/+5
Emphasis the way tree_mod_log_insert_move avoids adding MOD_LOG_KEY_REMOVE_WHILE_MOVING operations, depending on the direction of the move operation. Signed-off-by: Jan Schmidt <[email protected]>
2012-10-24Btrfs: fix extent buffer reference for tree mod log rootsJan Schmidt1-1/+1
In get_old_root we grab a lock on the extent buffer before we obtain a reference on that buffer. That order is changed now. Signed-off-by: Jan Schmidt <[email protected]>
2012-10-24Btrfs: determine level of old rootsJan Schmidt3-3/+19
In btrfs_find_all_roots' termination condition, we compare the level of the old buffer we got from btrfs_search_old_slot to the level of the current root node. We'd better compare it to the level of the rewinded root node. Signed-off-by: Jan Schmidt <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.