- 23 Mar, 2012 1 commit
-
-
Ryusuke Konishi authored
commit d7178c79 upstream. According to the report from Slicky Devil, nilfs caused kernel oops at nilfs_load_super_block function during mount after he shrank the partition without resizing the filesystem: BUG: unable to handle kernel NULL pointer dereference at 00000048 IP: [<d0d7a08e>] nilfs_load_super_block+0x17e/0x280 [nilfs2] *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP ... Call Trace: [<d0d7a87b>] init_nilfs+0x4b/0x2e0 [nilfs2] [<d0d6f707>] nilfs_mount+0x447/0x5b0 [nilfs2] [<c0226636>] mount_fs+0x36/0x180 [<c023d961>] vfs_kern_mount+0x51/0xa0 [<c023ddae>] do_kern_mount+0x3e/0xe0 [<c023f189>] do_mount+0x169/0x700 [<c023fa9b>] sys_mount+0x6b/0xa0 [<c04abd1f>] sysenter_do_call+0x12/0x28 Code: 53 18 8b 43 20 89 4b 18 8b 4b 24 89 53 1c 89 43 24 89 4b 20 8b 43 20 c7 43 2c 00 00 00 00 23 75 e8 8b 50 68 89 53 28 8b 54 b3 20 <8b> 72 48 8b 7a 4c 8b 55 08 89 b3 84 00 00 00 89 bb 88 00 00 00 EIP: [<d0d7a08e>] nilfs_load_super_block+0x17e/0x280 [nilfs2] SS:ESP 0068:ca9bbdcc CR2: 0000000000000048 This turned out due to a defect in an error path which runs if the calculated location of the secondary super block was invalid. This patch fixes it and eliminates the reported oops. Reported-by:
Slicky Devil <slicky.dvl@gmail.com> Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Tested-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 19 Mar, 2012 39 commits
-
-
Greg Kroah-Hartman authored
-
Guenter Roeck authored
commit fecfb644 upstream. Intersil reports that all chips supported by the zl6100 driver require an interval between chip accesses, even ZL2004 and ZL6105 which were thought to be safe. Reported-by:
Vivek Gani <vgani@intersil.com> Signed-off-by:
Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by:
-
Nicholas Bellinger authored
commit 087a03b3 upstream. This patch addresses a bug with target_check_scsi2_reservation_conflict() return checking in target_scsi2_reservation_[reserve,release]() that was preventing CRH=1 operation from silently succeeding in the two special cases defined by SPC-3, and not failing with reservation conflict status when dealing with legacy RESERVE/RELEASE + active SPC-3 PR logic. Also explictly set cmd->scsi_status = SAM_STAT_RESERVATION_CONFLICT during the early non reservation holder failure from pr_ops->t10_seq_non_holder() check in transport_generic_cmd_sequencer() for fabrics that already expect it to be set. This bug was originally introduced in mainline commit: commit eacac00c Author: Christoph Hellwig <hch@infradead.org> Date: Thu Nov 3 17:50:40 2011 -0400 target: split core_scsi2_emulate_crh Reported-by:
Martin Svec <martin.svec@zoner.cz> Cc: Martin Svec <martin.svec@zoner.cz> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Nicholas Bellinger authored
commit 00fdc6bb upstream. This patch addresses a iscsi-target specific bug related to reservation conflict handling in iscsit_handle_scsi_cmd() that has been causing reservation conflicts to complete and not fail as expected due to incorrect errno checking. The problem occured with the change to return -EBUSY from transport_generic_cmd_sequencer() -> transport_generic_allocate_tasks() failures, that broke iscsit_handle_scsi_cmd() checking for -EINVAL in order to invoke a non GOOD status response. This was manifesting itself as data corruption with legacy SPC-2 reservations, but also effects iscsi-target LUNs with SPC-3 persistent reservations. This bug was originally introduced in lio-core commit: commit 03e98c9e Author: Nicholas Bellinger <nab@linux-iscsi.org> Date: Fri Nov 4 02:36:16 2011 -0700 target: Address legacy PYX_TRANSPORT_* return code breakage Reported-by:
-
Ville Syrjala authored
commit 8ee161ce upstream. When the system is under heavy load, there can be a significant delay between the getscl() and time_after() calls inside sclhi(). That delay may cause the time_after() check to trigger after SCL has gone high, causing sclhi() to return -ETIMEDOUT. To fix the problem, double check that SCL is still low after the timeout has been reached, before deciding to return -ETIMEDOUT. Signed-off-by:
Ville Syrjala <syrjala@sci.fi> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Alexandre Bounine authored
commit 9bbad7da upstream. Fix indexed register offset definitions that use decimal (wrong) instead of hexadecimal (correct) notation for indexing multipliers. Incorrect definitions do not affect Tsi721 driver in its current default configuration because it uses only IDB queue 0. Loss of inbound doorbell functionality should be observed if queue other than 0 is used. Signed-off-by:
Alexandre Bounine <alexandre.bounine@idt.com> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Chul Kim <chul.kim@idt.com> Signed-off-by:
-
Jean Delvare authored
commit aacb6b00 upstream. Properly set the source of temp2 for the W83627UHG. Also fix a comment right before that, and document the W83627UHG as reporting up to 3 temperatures. Signed-off-by:
-
Guenter Roeck authored
commit 32260d94 upstream. The driver probe function leaked memory if creating the cpu0_vid attribute file failed. Fix by converting the driver to use devm_kzalloc. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
-
Guenter Roeck authored
commit 33fa9b62 upstream. NCT6775F and NCT6776F have their own set of registers for FAN_STOP_TIME. The correct registers were used to read FAN_STOP_TIME, but writes used the wrong registers. Fix it. Signed-off-by:
-
David S. Miller authored
commit e0adb990 upstream. Newer version of binutils are more strict about specifying the correct options to enable certain classes of instructions. The sparc32 build is done for v7 in order to support sun4c systems which lack hardware integer multiply and divide instructions. So we have to pass -Av8 when building the assembler routines that use these instructions and get patched into the kernel when we find out that we have a v8 capable cpu. Reported-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Alan Stern authored
commit 62d3c543 upstream. This patch (as1519) fixes a bug in the block layer's disk-events polling. The polling is done by a work routine queued on the system_nrt_wq workqueue. Since that workqueue isn't freezable, the polling continues even in the middle of a system sleep transition. Obviously, polling a suspended drive for media changes and such isn't a good thing to do; in the case of USB mass-storage devices it can lead to real problems requiring device resets and even re-enumeration. The patch fixes things by creating a new system-wide, non-reentrant, freezable workqueue and using it for disk-events polling. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Acked-by:
Tejun Heo <tj@kernel.org> Acked-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Stanislaw Gruszka authored
commit 9f53d2fe upstream. The following situation might occur: __blkdev_get: add_disk: register_disk() get_gendisk() disk_block_events() disk->ev == NULL disk_add_events() __disk_unblock_events() disk->ev != NULL --ev->block Then we unblock events, when they are suppose to be blocked. This can trigger events related block/genhd.c warnings, but also can crash in sd_check_events() or other places. I'm able to reproduce crashes with the following scripts (with connected usb dongle as sdb disk). <snip> DEV=/dev/sdb ENABLE=/sys/bus/usb/devices/1-2/bConfigurationValue function stop_me() { for i in `jobs -p` ; do kill $i 2> /dev/null ; done exit } trap stop_me SIGHUP SIGINT SIGTERM for ((i = 0; i < 10; i++)) ; do while true; do fdisk -l $DEV 2>&1 > /dev/null ; done & done while true ; do echo 1 > $ENABLE sleep 1 echo 0 > $ENABLE done </snip> I use the script to verify patch fixing oops in sd_revalidate_disk http://marc.info/?l=linux-scsi&m=132935572512352&w=2 Without Jun'ichi Nomura patch titled "Fix NULL pointer dereference in sd_revalidate_disk" or this one, script easily crash kernel within a few seconds. With both patches applied I do not observe crash. Unfortunately after some time (dozen of minutes), script will hung in: [ 1563.906432] [<c08354f5>] schedule_timeout_uninterruptible+0x15/0x20 [ 1563.906437] [<c04532d5>] msleep+0x15/0x20 [ 1563.906443] [<c05d60b2>] blk_drain_queue+0x32/0xd0 [ 1563.906447] [<c05d6e00>] blk_cleanup_queue+0xd0/0x170 [ 1563.906454] [<c06d278f>] scsi_free_queue+0x3f/0x60 [ 1563.906459] [<c06d7e6e>] __scsi_remove_device+0x6e/0xb0 [ 1563.906463] [<c06d4aff>] scsi_forget_host+0x4f/0x60 [ 1563.906468] [<c06cd84a>] scsi_remove_host+0x5a/0xf0 [ 1563.906482] [<f7f030fb>] quiesce_and_remove_host+0x5b/0xa0 [usb_storage] [ 1563.906490] [<f7f03203>] usb_stor_disconnect+0x13/0x20 [usb_storage] Anyway I think this patch is some step forward. As drawback, I do not teardown on sysfs file create error, because I do not know how to nullify disk->ev (since it can be used). However add_disk error handling practically does not exist too, and things will work without this sysfs file, except events will not be exported to user space. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
-
Dan Carpenter authored
commit ea5f4db8 upstream. "mem" is type u8. We need parenthesis here or it screws up the pointer math probably leading to an oops. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Jun'ichi Nomura authored
commit fe316bf2 upstream. Since 2.6.39 (1196f8b8), when a driver returns -ENOMEDIUM for open(), __blkdev_get() calls rescan_partitions() to remove in-kernel partition structures and raise KOBJ_CHANGE uevent. However it ends up calling driver's revalidate_disk without open and could cause oops. In the case of SCSI: process A process B ---------------------------------------------- sys_open __blkdev_get sd_open returns -ENOMEDIUM scsi_remove_device <scsi_device torn down> rescan_partitions sd_revalidate_disk <oops> Oopses are reported here: http://marc.info/?l=linux-scsi&m=132388619710052 This patch separates the partition invalidation from rescan_partitions() and use it for -ENOMEDIUM case. Reported-by:
Huajun Li <huajun.li.lee@gmail.com> Signed-off-by:
Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Acked-by:
-
Axel Lin authored
commit f03570cf upstream. Don't assign the voltage to selector. Signed-off-by:
Axel Lin <axel.lin@gmail.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Joerg Neikes authored
commit 4e503919 upstream. This patch adds support for the Sitecom LN-031 USB adapter with a AX88178 chip. Added USB id to find correct driver for AX88178 1000 Ethernet adapter. Signed-off-by:
Joerg Neikes <j.neikes@midlandgate.de> Signed-off-by:
-
Li Wei authored
[ Upstream commit d6ddef9e ] When forwarding was set and a new net device is register, we need add this device to the all-router mcast group. Signed-off-by:
Li Wei <lw@cn.fujitsu.com> Signed-off-by:
-
Neal Cardwell authored
[ Upstream commit 4648dc97 ] This commit fixes tcp_shift_skb_data() so that it does not shift SACKed data below snd_una. This fixes an issue whose symptoms exactly match reports showing tp->sacked_out going negative since 3.3.0-rc4 (see "WARNING: at net/ipv4/tcp_input.c:3418" thread on netdev). Since 2008 (832d11c5) tcp_shift_skb_data() had been shifting SACKed ranges that were below snd_una. It checked that the *end* of the skb it was about to shift from was above snd_una, but did not check that the end of the actual shifted range was above snd_una; this commit adds that check. Shifting SACKed ranges below snd_una is problematic because for such ranges tcp_sacktag_one() short-circuits: it does not declare anything as SACKed and does not increase sacked_out. Before the fixes in commits cc9a672e and daef52ba, shifting SACKed ranges below snd_una happened to work because tcp_shifted_skb() was always (incorrectly) passing in to tcp_sacktag_one() an skb whose end_seq tcp_shift_skb_data() had already guaranteed was beyond snd_una. Hence tcp_sacktag_one() never short-circuited and always increased tp->sacked_out in this case. After those two fixes, my testing has verified that shifting SACKed ranges below snd_una could cause tp->sacked_out to go negative with the following sequence of events: (1) tcp_shift_skb_data() sees an skb whose end_seq is beyond snd_una, then shifts a prefix of that skb that is below snd_una (2) tcp_shifted_skb() increments the packet count of the already-SACKed prev sk_buff (3) tcp_sacktag_one() sees the end of the new SACKed range is below snd_una, so it short-circuits and doesn't increase tp->sacked_out (5) tcp_clean_rtx_queue() sees the SACKed skb has been ACKed, decrements tp->sacked_out by this "inflated" pcount that was missing a matching increase in tp->sacked_out, and hence tp->sacked_out underflows to a u32 like 0xFFFFFFFF, which casted to s32 is negative. (6) this leads to the warnings seen in the recent "WARNING: at net/ipv4/tcp_input.c:3418" thread on the netdev list; e.g.: tcp_input.c:3418 WARN_ON((int)tp->sacked_out < 0); More generally, I think this bug can be tickled in some cases where two or more ACKs from the receiver are lost and then a DSACK arrives that is immediately above an existing SACKed skb in the write queue. This fix changes tcp_shift_skb_data() to abort this sequence at step (1) in the scenario above by noticing that the bytes are below snd_una and not shifting them. Signed-off-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
-
Ulrich Weber authored
[ Upstream commit d1d81d4c ] otherwise source IPv6 address of ICMPV6_MGM_QUERY packet might be random junk if IPv6 is disabled on interface or link-local address is not yet ready (DAD). Signed-off-by:
Ulrich Weber <ulrich.weber@sophos.com> Signed-off-by:
-
Neal Cardwell authored
[ Upstream commit c0638c24 ] In tcp_mark_head_lost() we should not attempt to fragment a SACKed skb to mark the first portion as lost. This is for two primary reasons: (1) tcp_shifted_skb() coalesces adjacent regions of SACKed skbs. When doing this, it preserves the sum of their packet counts in order to reflect the real-world dynamics on the wire. But given that skbs can have remainders that do not align to MSS boundaries, this packet count preservation means that for SACKed skbs there is not necessarily a direct linear relationship between tcp_skb_pcount(skb) and skb->len. Thus tcp_mark_head_lost()'s previous attempts to fragment off and mark as lost a prefix of length (packets - oldcnt)*mss from SACKed skbs were leading to occasional failures of the WARN_ON(len > skb->len) in tcp_fragment() (which used to be a BUG_ON(); see the recent "crash in tcp_fragment" thread on netdev). (2) there is no real point in fragmenting off part of a SACKed skb and calling tcp_skb_mark_lost() on it, since tcp_skb_mark_lost() is a NOP for SACKed skbs. Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Acked-by:
Yuchung Cheng <ycheng@google.com> Acked-by:
Nandita Dukkipati <nanditad@google.com> Signed-off-by:
-
françois romieu authored
[ Upstream commit 9c5028e9 ] Noticed with the 8168d (-vb-gr, aka RTL_GIGA_MAC_VER_26). ConfigX registers should only be written while the Config9346 lock is held. Signed-off-by:
Francois Romieu <romieu@fr.zoreil.com> Reported-by:
Nick Bowler <nbowler@elliptictech.com> Cc: Hayes Wang <hayeswang@realtek.com> Signed-off-by:
-
stephen hemminger authored
[ Upstream commit 3f2010b2 ] As part of the big network driver reorg, each vendor directory defaults to yes, so that older config's can migrate correctly. Looks like this one got missed. Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
-
Shreyas Bhatewara authored
[ Upstream commit efead871 ] Fix transport header size Fix the transpoert header size for UDP packets. Signed-off-by:
Shreyas N Bhatewara <sbhatewara@vmware.com> Signed-off-by:
-
Neal Cardwell authored
[ Upstream commit 4c90d3b3 ] When tcp_shifted_skb() shifts bytes from the skb that is currently pointed to by 'highest_sack' then the increment of TCP_SKB_CB(skb)->seq implicitly advances tcp_highest_sack_seq(). This implicit advancement, combined with the recent fix to pass the correct SACKed range into tcp_sacktag_one(), caused tcp_sacktag_one() to think that the newly SACKed range was before the tcp_highest_sack_seq(), leading to a call to tcp_update_reordering() with a degree of reordering matching the size of the newly SACKed range (typically just 1 packet, which is a NOP, but potentially larger). This commit fixes this by simply calling tcp_sacktag_one() before the TCP_SKB_CB(skb)->seq advancement that can advance our notion of the highest SACKed sequence. Correspondingly, we can simplify the code a little now that tcp_shifted_skb() should update the lost_cnt_hint in all cases where skb == tp->lost_skb_hint. Signed-off-by:
-
Ben Hutchings authored
[ Upstream commit ff3bc1e7 ] When pre-allocating skbs for received packets, we set ip_summed = CHECKSUM_UNNCESSARY. We used to change it back to CHECKSUM_NONE when the received packet had an incorrect checksum or unhandled protocol. Commit bc8acf2c ('drivers/net: avoid some skb->ip_summed initializations') mistakenly replaced the latter assignment with a DEBUG-only assertion that ip_summed == CHECKSUM_NONE. This assertion is always false, but it seems no-one has exercised this code path in a DEBUG build. Fix this by moving our assignment of CHECKSUM_UNNECESSARY into efx_rx_packet_gro(). Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
-
Ben McKeegan authored
[ Upstream commit 8a49ad6e ] This patch fixes a (mostly cosmetic) bug introduced by the patch 'ppp: Use SKB queue abstraction interfaces in fragment processing' found here: http://www.spinics.net/lists/netdev/msg153312.html The above patch rewrote and moved the code responsible for cleaning up discarded fragments but the new code does not catch every case where this is necessary. This results in some discarded fragments remaining in the queue, and triggering a 'bad seq' error on the subsequent call to ppp_mp_reconstruct. Fragments are discarded whenever other fragments of the same frame have been lost. This can generate a lot of unwanted and misleading log messages. This patch also adds additional detail to the debug logging to make it clearer which fragments were lost and which other fragments were discarded as a result of losses. (Run pppd with 'kdebug 1' option to enable debug logging.) Signed-off-by:
Ben McKeegan <ben@netservers.co.uk> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 03606895 ] Niccolo Belli reported ipsec crashes in case we handle a frame without mac header (atm in his case) Before copying mac header, better make sure it is present. Bugzilla reference: https://bugzilla.kernel.org/show_bug.cgi?id=42809Reported-by:
Niccolò Belli <darkbasic@linuxsystems.it> Tested-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
-
Michel Machado authored
[ Upstream commit 84338a6c ] When the fixed race condition happens: 1. While function neigh_periodic_work scans the neighbor hash table pointed by field tbl->nht, it unlocks and locks tbl->lock between buckets in order to call cond_resched. 2. Assume that function neigh_periodic_work calls cond_resched, that is, the lock tbl->lock is available, and function neigh_hash_grow runs. 3. Once function neigh_hash_grow finishes, and RCU calls neigh_hash_free_rcu, the original struct neigh_hash_table that function neigh_periodic_work was using doesn't exist anymore. 4. Once back at neigh_periodic_work, whenever the old struct neigh_hash_table is accessed, things can go badly. Signed-off-by:
Michel Machado <michel@digirati.com.br> CC: "David S. Miller" <davem@davemloft.net> CC: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 11aad99a ] This driver attempts to use two TX rings but lacks proper support : 1) IRQ handler only takes care of TX completion on first TX ring 2) the stop/start logic uses the legacy functions (for non multiqueue drivers) This means all packets witk skb mark set to 1 are sent through high queue but are never cleaned and queue eventualy fills and block the device, triggering the infamous "NETDEV WATCHDOG" message. Lets use a single TX ring to fix the problem, this driver is not a real multiqueue one yet. Minimal fix for stable kernels. Reported-by:
Thomas Meyer <thomas@m3y3r.de> Tested-by:
-
Ike Panhc authored
commit 461e7437 upstream. We have several reports which says acer-wmi is loaded on ideapads and register rfkill for wifi which can not be unblocked. Since ideapad-laptop also register rfkill for wifi and it works reliably, it will be fine acer-wmi is not going to register rfkill for wifi once VPC2004 is found. Also put IBM0068/LEN0068 in the list. Though thinkpad_acpi has no wifi rfkill capability, there are reports which says acer-wmi also block wireless on Thinkpad E520/E420. Signed-off-by:
Ike Panhc <ike.pan@canonical.com> Signed-off-by:
Matthew Garrett <mjg@redhat.com> Cc: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
-
Miklos Szeredi authored
commit 097b180c upstream. complete_walk() already puts nd->path, no need to do it again at cleanup time. This would result in Oopses if triggered, apparently the codepath is not too well exercised. Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Miklos Szeredi authored
commit 7f6c7e62 upstream. complete_walk() returns either ECHILD or ESTALE. do_last() turns this into ECHILD unconditionally. If not in RCU mode, this error will reach userspace which is complete nonsense. Signed-off-by:
-
Pavel Shilovsky authored
commit d5751469 upstream. Reorganize the code to make the memory already allocated before spinlock'ed loop. Reviewed-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Pavel Shilovsky <piastry@etersoft.ru> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Peter Zijlstra authored
commit 87e24f4b upstream. Verified using the below proglet.. before: [root@westmere ~]# perf stat -e node-stores -e node-store-misses ./numa 0 remote write Performance counter stats for './numa 0': 2,101,554 node-stores 2,096,931 node-store-misses 5.021546079 seconds time elapsed [root@westmere ~]# perf stat -e node-stores -e node-store-misses ./numa 1 local write Performance counter stats for './numa 1': 501,137 node-stores 199 node-store-misses 5.124451068 seconds time elapsed After: [root@westmere ~]# perf stat -e node-stores -e node-store-misses ./numa 0 remote write Performance counter stats for './numa 0': 2,107,516 node-stores 2,097,187 node-store-misses 5.012755149 seconds time elapsed [root@westmere ~]# perf stat -e node-stores -e node-store-misses ./numa 1 local write Performance counter stats for './numa 1': 2,063,355 node-stores 165 node-store-misses 5.082091494 seconds time elapsed #define _GNU_SOURCE #include <sched.h> #include <stdio.h> #include <errno.h> #include <sys/mman.h> #include <sys/types.h> #include <dirent.h> #include <signal.h> #include <unistd.h> #include <numaif.h> #include <stdlib.h> #define SIZE (32*1024*1024) volatile int done; void sig_done(int sig) { done = 1; } int main(int argc, char **argv) { cpu_set_t *mask, *mask2; size_t size; int i, err, t; int nrcpus = 1024; char *mem; unsigned long nodemask = 0x01; /* node 0 */ DIR *node; struct dirent *de; int read = 0; int local = 0; if (argc < 2) { printf("usage: %s [0-3]\n", argv[0]); printf(" bit0 - local/remote\n"); printf(" bit1 - read/write\n"); exit(0); } switch (atoi(argv[1])) { case 0: printf("remote write\n"); break; case 1: printf("local write\n"); local = 1; break; case 2: printf("remote read\n"); read = 1; break; case 3: printf("local read\n"); local = 1; read = 1; break; } mask = CPU_ALLOC(nrcpus); size = CPU_ALLOC_SIZE(nrcpus); CPU_ZERO_S(size, mask); node = opendir("/sys/devices/system/node/node0/"); if (!node) perror("opendir"); while ((de = readdir(node))) { int cpu; if (sscanf(de->d_name, "cpu%d", &cpu) == 1) CPU_SET_S(cpu, size, mask); } closedir(node); mask2 = CPU_ALLOC(nrcpus); CPU_ZERO_S(size, mask2); for (i = 0; i < size; i++) CPU_SET_S(i, size, mask2); CPU_XOR_S(size, mask2, mask2, mask); // invert if (!local) mask = mask2; err = sched_setaffinity(0, size, mask); if (err) perror("sched_setaffinity"); mem = mmap(0, SIZE, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); err = mbind(mem, SIZE, MPOL_BIND, &nodemask, 8*sizeof(nodemask), MPOL_MF_MOVE); if (err) perror("mbind"); signal(SIGALRM, sig_done); alarm(5); if (!read) { while (!done) { for (i = 0; i < SIZE; i++) mem[i] = 0x01; } } else { while (!done) { for (i = 0; i < SIZE; i++) t += *(volatile char *)(mem + i); } } return 0; } Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-tq73sxus35xmqpojf7ootxgs@git.kernel.orgSigned-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Stanislaw Gruszka authored
commit 3780d038 upstream. Is possible that we stop queue and then do not wake up it again, especially when packets are transmitted fast. That can be easily reproduced with modified tx queue entry_num to some small value e.g. 16. If mac80211 already hold local->queue_stop_reason_lock, then we can wait on that lock in both rt2x00queue_pause_queue() and rt2x00queue_unpause_queue(). After drooping ->queue_stop_reason_lock is possible that __ieee80211_wake_queue() will be performed before __ieee80211_stop_queue(), hence we stop queue and newer wake up it again. Another race condition is possible when between rt2x00queue_threshold() check and rt2x00queue_pause_queue() we will process all pending tx buffers on different cpu. This might happen if for example interrupt will be triggered on cpu performing rt2x00mac_tx(). To prevent race conditions serialize pause/unpause by queue->tx_lock. Signed-off-by:
Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Laurent Pinchart authored
commit bd0f2e6d upstream. The HS/VS interrupt handler needs to access the pipeline object. It erronously tries to get it from the CCDC output video node, which isn't necessarily included in the pipeline. This leads to a NULL pointer dereference. Fix the bug by getting the pipeline object from the CCDC subdev entity. Reported-by:
Gary Thomas <gary@mlbassoc.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Sakari Ailus <sakari.ailus@iki.fi> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Matthew Garrett authored
commit 4949be16 upstream. Right now we won't touch ASPM state if ASPM is disabled, except in the case where we find a device that appears to be too old to reliably support ASPM. Right now we'll clear it in that case, which is almost certainly the wrong thing to do. The easiest way around this is just to disable the blacklisting when ASPM is disabled. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Thomas Gleixner authored
commit a7f4255f upstream. Commit f0fbf0ab ("x86: integrate delay functions") converted delay_tsc() into a random delay generator for 64 bit. The reason is that it merged the mostly identical versions of delay_32.c and delay_64.c. Though the subtle difference of the result was: static void delay_tsc(unsigned long loops) { - unsigned bclock, now; + unsigned long bclock, now; Now the function uses rdtscl() which returns the lower 32bit of the TSC. On 32bit that's not problematic as unsigned long is 32bit. On 64 bit this fails when the lower 32bit are close to wrap around when bclock is read, because the following check if ((now - bclock) >= loops) break; evaluated to true on 64bit for e.g. bclock = 0xffffffff and now = 0 because the unsigned long (now - bclock) of these values results in 0xffffffff00000001 which is definitely larger than the loops value. That explains Tvortkos observation: "Because I am seeing udelay(500) (_occasionally_) being short, and that by delaying for some duration between 0us (yep) and 491us." Make those variables explicitely u32 again, so this works for both 32 and 64 bit. Reported-by:
Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Al Viro authored
commit c7b28555 upstream. Current code has put_ioctx() called asynchronously from aio_fput_routine(); that's done *after* we have killed the request that used to pin ioctx, so there's nothing to stop io_destroy() waiting in wait_for_all_aios() from progressing. As the result, we can end up with async call of put_ioctx() being the last one and possibly happening during exit_mmap() or elf_core_dump(), neither of which expects stray munmap() being done to them... We do need to prevent _freeing_ ioctx until aio_fput_routine() is done with that, but that's all we care about - neither io_destroy() nor exit_aio() will progress past wait_for_all_aios() until aio_fput_routine() does really_put_req(), so the ioctx teardown won't be done until then and we don't care about the contents of ioctx past that point. Since actual freeing of these suckers is RCU-delayed, we don't need to bump ioctx refcount when request goes into list for async removal. All we need is rcu_read_lock held just over the ->ctx_lock-protected area in aio_fput_routine(). Signed-off-by:
Jeff Moyer <jmoyer@redhat.com> Acked-by:
Benjamin LaHaise <bcrl@kvack.org> Signed-off-by:
-
