- 17 Nov, 2012 29 commits
-
-
Jesper Dangaard Brouer authored
[ Upstream commit 8f363b77 ] Reading TCP stats when using TCP Illinois congestion control algorithm can cause a divide by zero kernel oops. The division by zero occur in tcp_illinois_info() at: do_div(t, ca->cnt_rtt); where ca->cnt_rtt can become zero (when rtt_reset is called) Steps to Reproduce: 1. Register tcp_illinois: # sysctl -w net.ipv4.tcp_congestion_control=illinois 2. Monitor internal TCP information via command "ss -i" # watch -d ss -i 3. Establish new TCP conn to machine Either it fails at the initial conn, or else it needs to wait for a loss or a reset. This is only related to reading stats. The function avg_delay() also performs the same divide, but is guarded with a (ca->cnt_rtt > 0) at its calling point in update_params(). Thus, simply fix tcp_illinois_info(). Function tcp_illinois_info() / get_info() is called without socket lock. Thus, eliminate any race condition on ca->cnt_rtt by using a local stack variable. Simply reuse info.tcpv_rttcnt, as its already set to ca->cnt_rtt. Function avg_delay() is not affected by this race condition, as its called with the socket lock. Cc: Petr Matousek <pmatouse@redhat.com> Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Acked-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hemant Kumar authored
[ Upstream commit 39707c2a ] Driver anchors the tx urbs and defers the urb submission if a transmit request comes when the interface is suspended. Anchoring urb increments the urb reference count. These deferred urbs are later accessed by calling usb_get_from_anchor() for submission during interface resume. usb_get_from_anchor() unanchors the urb but urb reference count remains same. This causes the urb reference count to remain non-zero after usb_free_urb() gets called and urb never gets freed. Hence call usb_put_urb() after anchoring the urb to properly balance the reference count for these deferred urbs. Also, unanchor these deferred urbs during disconnect, to free them up. Signed-off-by:
Hemant Kumar <hemantk@codeaurora.org> Acked-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Li RongQing authored
[ Upstream commit 14edd87d ] Commit a02e4b7d(Demark default hoplimit as zero) only changes the hoplimit checking condition and default value in ip6_dst_hoplimit, not zeros all hoplimit default value. Keep the zeroing ip6_template_metrics[RTAX_HOPLIMIT - 1] to force it as const, cause as a37e6e34(net: force dst_default_metrics to const section) Signed-off-by:
Li RongQing <roy.qing.li@gmail.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit a3374c42 ] tcp_ioctl() tries to take into account if tcp socket received a FIN to report correct number bytes in receive queue. But its flaky because if the application ate the last skb, we return 1 instead of 0. Correct way to detect that FIN was received is to test SOCK_DONE. Reported-by:
Elliot Hughes <enh@google.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 6d772ac5 ] On some suspend/resume operations involving wimax device, we have noticed some intermittent memory corruptions in netlink code. Stéphane Marchesin tracked this corruption in netlink_update_listeners() and suggested a patch. It appears netlink_release() should use kfree_rcu() instead of kfree() for the listeners structure as it may be used by other cpus using RCU protection. netlink_release() must set to NULL the listeners pointer when it is about to be freed. Also have to protect netlink_update_listeners() and netlink_has_listeners() if listeners is NULL. Add a nl_deref_protected() lockdep helper to properly document which locks protects us. Reported-by:
Jonathan Kliegman <kliegs@google.com> Signed-off-by:
-
Zijie Pan authored
[ Upstream commit f6e80abe ] Bug introduced by commit edfee033 (sctp: check src addr when processing SACK to update transport state) Signed-off-by:
Zijie Pan <zijie.pan@6wind.com> Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Acked-by:
Vlad Yasevich <vyasevich@gmail.com> Signed-off-by:
-
Takashi Iwai authored
commit 0914f796 upstream. When disconnect callback is called, each component should wake up sleepers and check card->shutdown flag for avoiding the endless sleep blocking the proper resource release. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit a0830dbd upstream. For more strict protection for wild disconnections, a refcount is introduced to the card instance, and let it up/down when an object is referred via snd_lookup_*() in the open ops. The free-after-last-close check is also changed to check this refcount instead of the empty list, too. Reported-by:
Matthieu CASTET <matthieu.castet@parrot.com> Signed-off-by:
-
Takashi Iwai authored
commit 888ea7d5 upstream. Similar like the previous commit, cover with chip->shutdown_rwsem and chip->shutdown checks. Reported-by:
-
Takashi Iwai authored
commit 34f3c89f upstream. Replace mutex with rwsem for codec->shutdown protection so that concurrent accesses are allowed. Also add the protection to snd_usb_autosuspend() and snd_usb_autoresume(), too. Reported-by:
-
Takashi Iwai authored
commit 978520b7 upstream. Close some races at disconnection of a USB audio device by adding the chip->shutdown_mutex and chip->shutdown check at appropriate places. The spots to put bandaids are: - PCM prepare, hw_params and hw_free - where the usb device is accessed for communication or get speed, in mixer.c and others; the device speed is now cached in subs->speed instead of accessing to chip->dev The accesses in PCM open and close don't need the mutex protection because these are already handled in the core PCM disconnection code. The autosuspend/autoresume codes are still uncovered by this patch because of possible mutex deadlocks. They'll be covered by the upcoming change to rwsem. Also the mixer codes are untouched, too. These will be fixed in another patch, too. Reported-by:
-
Takashi Iwai authored
commit 9b0573c0 upstream. Fix races at PCM disconnection: - while a PCM device is being opened or closed - while the PCM state is being changed without lock in prepare, hw_params, hw_free ops Reported-by:
-
Jean Delvare authored
commit 3300fb4f upstream. Don't assume bank 0 is selected at device probe time. This may not be the case. Force bank selection at first register access to guarantee that we read the right registers upon driver loading. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Ilija Hadzic authored
commit 0f1cb1bd upstream. If drm_setup (called at first open) fails, the whole open call has failed, so we should not keep the open_count incremented. Signed-off-by:
Ilija Hadzic <ihadzic@research.bell-labs.com> Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Trond Myklebust authored
[Fixed upstream as part of 0b728e19, but that's a much larger patch, this is only the nfs portion backported as needed.] Fix the following Oops in 3.5.1: BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 IP: [<ffffffffa03789cd>] nfs_lookup_revalidate+0x2d/0x480 [nfs] PGD 337c63067 PUD 0 Oops: 0000 [#1] SMP CPU 5 Modules linked in: nfs fscache nfsd lockd nfs_acl auth_rpcgss sunrpc af_packet binfmt_misc cpufreq_conservative cpufreq_userspace cpufreq_powersave dm_mod acpi_cpufreq mperf coretemp gpio_ich kvm_intel joydev kvm ioatdma hid_generic igb lpc_ich i7core_edac edac_core ptp serio_raw dca pcspkr i2c_i801 mfd_core sg pps_core usbhid crc32c_intel microcode button autofs4 uhci_hcd ttm drm_kms_helper drm i2c_algo_bit sysimgblt sysfillrect syscopyarea ehci_hcd usbcore usb_common scsi_dh_rdac scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh edd fan ata_piix thermal processor thermal_sys Pid: 30431, comm: java Not tainted 3.5.1-2-default #1 Supermicro X8DTT/X8DTT RIP: 0010:[<ffffffffa03789cd>] [<ffffffffa03789cd>] nfs_lookup_revalidate+0x2d/0x480 [nfs] RSP: 0018:ffff8801b418bd38 EFLAGS: 00010292 RAX: 00000000fffffff6 RBX: ffff88032016d800 RCX: 0000000000000020 RDX: ffffffff00000000 RSI: 0000000000000000 RDI: ffff8801824a7b00 RBP: ffff8801b418bdf8 R08: 7fffff0034323030 R09: fffffffff04c03ed R10: ffff8801824a7b00 R11: 0000000000000002 R12: ffff8801824a7b00 R13: ffff8801824a7b00 R14: 0000000000000000 R15: ffff8803201725d0 FS: 00002b53a46cb700(0000) GS:ffff88033fc20000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000038 CR3: 000000020a426000 CR4: 00000000000007e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process java (pid: 30431, threadinfo ffff8801b418a000, task ffff8801b5d20600) Stack: ffff8801b418be44 ffff88032016d800 ffff8801b418bdf8 0000000000000000 ffff8801824a7b00 ffff8801b418bdd7 ffff8803201725d0 ffffffff8116a9c0 ffff8801b5c38dc0 0000000000000007 ffff88032016d800 0000000000000000 Call Trace: [<ffffffff8116a9c0>] lookup_dcache+0x80/0xe0 [<ffffffff8116aa43>] __lookup_hash+0x23/0x90 [<ffffffff8116b4a5>] lookup_one_len+0xc5/0x100 [<ffffffffa03869a3>] nfs_sillyrename+0xe3/0x210 [nfs] [<ffffffff8116cadf>] vfs_unlink.part.25+0x7f/0xe0 [<ffffffff8116f22c>] do_unlinkat+0x1ac/0x1d0 [<ffffffff815717b9>] system_call_fastpath+0x16/0x1b [<00002b5348b5f527>] 0x2b5348b5f526 Code: ec 38 b8 f6 ff ff ff 4c 89 64 24 18 4c 89 74 24 28 49 89 fc 48 89 5c 24 08 48 89 6c 24 10 49 89 f6 4c 89 6c 24 20 4c 89 7c 24 30 <f6> 46 38 40 0f 85 d1 00 00 00 e8 c4 c4 df e0 48 8b 58 30 49 89 RIP [<ffffffffa03789cd>] nfs_lookup_revalidate+0x2d/0x480 [nfs] RSP <ffff8801b418bd38> CR2: 0000000000000038 ---[ end trace 845113ed191985dd ]--- This Oops affects 3.5 kernels and older, and is due to lookup_one_len() calling down to the dentry revalidation code with a NULL pointer to struct nameidata. It is fixed upstream by commit 0b728e19 (stop passing nameidata * to ->d_revalidate()) Reported-by:
Richard Ems <richard.ems@cape-horn-eng.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
NeilBrown authored
commit 8d96b106 upstream. The DNS resolver's use of the sunrpc cache involves a 'ttl' number (relative) rather that a timeout (absolute). This confused me when I wrote commit c5b29f88 "sunrpc: use seconds since boot in expiry cache" and I managed to break it. The effect is that any TTL is interpreted as 0, and nothing useful gets into the cache. This patch removes the use of get_expiry() - which really expects an expiry time - and uses get_uint() instead, treating the int correctly as a ttl. This fixes a regression that has been present since 2.6.37, causing certain NFS accesses in certain environments to incorrectly fail. Reported-by:
Chuck Lever <chuck.lever@oracle.com> Tested-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
J. Bruce Fields authored
commit a007c4c3 upstream. I don't think there's a practical difference for the range of values these interfaces should see, but it would be safer to be unambiguous. Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Cc: Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
-
Trond Myklebust authored
commit 2b1bc308 upstream. If the state recovery machinery is triggered by the call to nfs4_async_handle_error() then we can deadlock. Signed-off-by:
-
Ben Hutchings authored
commit 97a54868 upstream. Since commit c7f404b4 ('vfs: new superblock methods to override /proc/*/mount{s,info}'), nfs_path() is used to generate the mounted device name reported back to userland. nfs_path() always generates a trailing slash when the given dentry is the root of an NFS mount, but userland may expect the original device name to be returned verbatim (as it used to be). Make this canonicalisation optional and change the callers accordingly. [jrnieder@gmail.com: use flag instead of bool argument] Reported-and-tested-by:
Chris Hiestand <chiestand@salk.edu> Reference: http://bugs.debian.org/669314Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
-
Scott Mayhew authored
commit acce94e6 upstream. In very busy v3 environment, rpc.mountd can respond to the NULL procedure but not the MNT procedure in a timely manner causing the MNT procedure to time out. The problem is the mount system call returns EIO which causes the mount to fail, instead of ETIMEDOUT, which would cause the mount to be retried. This patch sets the RPC_TASK_SOFT|RPC_TASK_TIMEOUT flags to the rpc_call_sync() call in nfs_mount() which causes ETIMEDOUT to be returned on timed out connections. Signed-off-by:
Steve Dickson <steved@redhat.com> Signed-off-by:
-
Antonio Quartulli authored
commit badecb00 upstream. The 'ssid' field of the cfg80211_ibss_params is a u8 pointer and its length is likely to be less than IEEE80211_MAX_SSID_LEN most of the time. This patch fixes the ssid copy in ieee80211_ibss_join() by using the SSID length to prevent it from reading beyond the string. Signed-off-by:
Antonio Quartulli <ordex@autistici.org> [rewrapped commit message, small rewording] Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
commit 4a4f1a58 upstream. Due to pskb_may_pull() checking the skb length, all non-management frames are checked on input whether their 802.11 header is fully present. Also add that check for management frames and remove a check that is now duplicate. This prevents accessing skb data beyond the frame end. Signed-off-by:
-
Egbert Eich authored
commit 83325d07 upstream. An uninitialized variable led to broken load detection. Signed-off-by:
Egbert Eich <eich@suse.de> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Javier Cardona authored
commit f7fbf70e upstream. Per IEEE Std. 802.11-2012, Sec 8.2.4.4.1, the sequence Control field is not present in control frames. We noticed this problem when processing Block Ack Requests. Signed-off-by:
Javier Cardona <javier@cozybit.com> Signed-off-by:
Javier Lopez <jlopex@cozybit.com> Signed-off-by:
-
Johannes Berg authored
commit 7dd111e8 upstream. The mesh header can have address extension by a 4th or a 5th and 6th address, but never both. Drop such frames in 802.11 -> 802.3 conversion along with any frames that have the wrong extension. Reviewed-by:
-
Felix Fietkau authored
commit c4a9fafc upstream. No driver initializes chan->max_antenna_gain to something sensible, and the only place where it is being used right now is inside ath9k. This leads to ath9k potentially using less tx power than it can use, which can decrease performance/range in some rare cases. Rather than going through every single driver, this patch initializes chan->orig_mag in wiphy_register(), ignoring whatever value the driver left in there. If a driver for some reason wishes to limit it independent from regulatory rulesets, it can do so internally. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Roland Dreier authored
commit 0d0f9dfb upstream. If the call to core_dev_release_virtual_lun0() fails, then nothing sets ret to anything other than 0, so even though everything is torn down and freed, target_core_init_configfs() will seem to succeed and the module will be loaded. Fix this by passing the return value on up the chain. Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Stanislaw Gruszka authored
commit bf7e1abe upstream. Some hardware has correct (!= 0xff) value of tssi_bounds[4] in the EEPROM, but step is equal to 0xff. This results on ridiculous delta calculations and completely broke TX power settings. Reported-and-tested-by:
Pavel Lucik <pavel.lucik@gmail.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Felix Fietkau authored
commit 8c6e3093 upstream. bf->bf_next is only while buffers are chained as part of an A-MPDU in the tx queue. When a tid queue is flushed (e.g. on tearing down an aggregation session), frames can be enqueued again as normal transmission, without bf_next being cleared. This can lead to the old pointer being dereferenced again later. This patch might fix crashes and "Failed to stop TX DMA!" messages. Signed-off-by:
-
- 05 Nov, 2012 5 commits
-
-
Greg Kroah-Hartman authored
-
Ben Skeggs authored
commit cee59f15 upstream. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Jan Kara authored
commit ef5d437f upstream. On s390 any write to a page (even from kernel itself) sets architecture specific page dirty bit. Thus when a page is written to via buffered write, HW dirty bit gets set and when we later map and unmap the page, page_remove_rmap() finds the dirty bit and calls set_page_dirty(). Dirtying of a page which shouldn't be dirty can cause all sorts of problems to filesystems. The bug we observed in practice is that buffers from the page get freed, so when the page gets later marked as dirty and writeback writes it, XFS crashes due to an assertion BUG_ON(!PagePrivate(page)) in page_buffers() called from xfs_count_page_state(). Similar problem can also happen when zero_user_segment() call from xfs_vm_writepage() (or block_write_full_page() for that matter) set the hardware dirty bit during writeback, later buffers get freed, and then page unmapped. Fix the issue by ignoring s390 HW dirty bit for page cache pages of mappings with mapping_cap_account_dirty(). This is safe because for such mappings when a page gets marked as writeable in PTE it is also marked dirty in do_wp_page() or do_page_fault(). When the dirty bit is cleared by clear_page_dirty_for_io(), the page gets writeprotected in page_mkclean(). So pagecache page is writeable if and only if it is dirty. Thanks to Hugh Dickins for pointing out mapping has to have mapping_cap_account_dirty() for things to work and proposing a cleaned up variant of the patch. The patch has survived about two hours of running fsx-linux on tmpfs while heavily swapping and several days of running on out build machines where the original problem was triggered. Signed-off-by:
Jan Kara <jack@suse.cz> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Hugh Dickins <hughd@google.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Len Brown authored
commit f6365201 upstream. The X86_32-only disable_hlt/enable_hlt mechanism was used by the 32-bit floppy driver. Its effect was to replace the use of the HLT instruction inside default_idle() with cpu_relax() - essentially it turned off the use of HLT. This workaround was commented in the code as: "disable hlt during certain critical i/o operations" "This halt magic was a workaround for ancient floppy DMA wreckage. It should be safe to remove." H. Peter Anvin additionally adds: "To the best of my knowledge, no-hlt only existed because of flaky power distributions on 386/486 systems which were sold to run DOS. Since DOS did no power management of any kind, including HLT, the power draw was fairly uniform; when exposed to the much hhigher noise levels you got when Linux used HLT caused some of these systems to fail. They were by far in the minority even back then." Alan Cox further says: "Also for the Cyrix 5510 which tended to go castors up if a HLT occurred during a DMA cycle and on a few other boxes HLT during DMA tended to go astray. Do we care ? I doubt it. The 5510 was pretty obscure, the 5520 fixed it, the 5530 is probably the oldest still in any kind of use." So, let's finally drop this. Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Josh Boyer <jwboyer@redhat.com> Signed-off-by:
"H. Peter Anvin" <hpa@zytor.com> Acked-by:
Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Stephen Hemminger <shemminger@vyatta.com Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/n/tip-3rhk9bzf0x9rljkv488tloib@git.kernel.org [ If anyone cares then alternative instruction patching could be used to replace HLT with a one-byte NOP instruction. Much simpler. ] Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Herton Ronaldo Krzesinski authored
commit 238ab784 upstream. If blk_init_queue fails, we do not call put_disk on the current dr (dr is decremented first in the error handling loop). Reviewed-by:
Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
- 31 Oct, 2012 6 commits
-
-
Greg Kroah-Hartman authored
-
Sjoerd Simons authored
commit 9756fe38 upstream. This box claims to have an LVDS interface but doesn't actually have one. Signed-off-by:
Sjoerd Simons <sjoerd.simons@collabora.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Ian Abbott authored
commit aaeb61a9 upstream. `pc236_detach()` is called by the comedi core if it attempted to attach a device and failed. `pc236_detach()` calls `pc236_intr_disable()` if the comedi device private data pointer (`devpriv`) is non-null. This test is insufficient as `pc236_intr_disable()` accesses hardware registers and the attach routine may have failed before it has saved their I/O base addresses. Fix it by checking `dev->iobase` is non-zero before calling `pc236_intr_disable()` as that means the I/O base addresses have been saved and the hardware registers can be accessed. It also implies the comedi device private data pointer is valid, so there is no need to check it. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Yinghai Lu authored
commit f82f64dd upstream. Commit 844ab6f9 x86, mm: Find_early_table_space based on ranges that are actually being mapped added back some lines back wrongly that has been removed in commit 7b16bbf9 Revert "x86/mm: Fix the size calculation of mapping tables" remove them again. Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Link: http://lkml.kernel.org/r/CAE9FiQW_vuaYQbmagVnxT2DGsYc=9tNeAbdBq53sYkitPOwxSQ@mail.gmail.comAcked-by:
Jacob Shin <jacob.shin@amd.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Jacob Shin authored
commit 844ab6f9 upstream. 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 1bbbbe77, to address the panic reported here: https://lkml.org/lkml/2012/10/20/160 https://lkml.org/lkml/2012/10/21/157Signed-off-by:
Tom Rini <trini@ti.com> Signed-off-by:
-
Andreas Herrmann authored
commit e4df1cbc upstream. Commit 6889125b (cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU) causes powernow-k8 to trigger a preempt warning, e.g.: BUG: using smp_processor_id() in preemptible [00000000] code: cpufreq/3776 caller is powernowk8_target+0x20/0x49 Pid: 3776, comm: cpufreq Not tainted 3.6.0 #9 Call Trace: [<ffffffff8125b447>] debug_smp_processor_id+0xc7/0xe0 [<ffffffff814877e7>] powernowk8_target+0x20/0x49 [<ffffffff81482b02>] __cpufreq_driver_target+0x82/0x8a [<ffffffff81484fc6>] cpufreq_governor_performance+0x4e/0x54 [<ffffffff81482c50>] __cpufreq_governor+0x8c/0xc9 [<ffffffff81482e6f>] __cpufreq_set_policy+0x1a9/0x21e [<ffffffff814839af>] store_scaling_governor+0x16f/0x19b [<ffffffff81484f16>] ? cpufreq_update_policy+0x124/0x124 [<ffffffff8162b4a5>] ? _raw_spin_unlock_irqrestore+0x2c/0x49 [<ffffffff81483640>] store+0x60/0x88 [<ffffffff811708c0>] sysfs_write_file+0xf4/0x130 [<ffffffff8111243b>] vfs_write+0xb5/0x151 [<ffffffff811126e0>] sys_write+0x4a/0x71 [<ffffffff816319a9>] system_call_fastpath+0x16/0x1b Fix this by by always using work_on_cpu(). Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
