summaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorNeil Horman <nhorman@tuxdriver.com>2012-05-01 08:18:02 +0000
committerDavid S. Miller <davem@davemloft.net>2012-05-02 21:02:48 -0400
commit4fdcfa12843bca38d0c9deff70c8720e4e8f515f (patch)
tree3ef2a92b1d6d322f9b72185e58b9d35a15564692 /Documentation
parenta4723848d05dd31d298c551fb77ad28481309999 (diff)
downloadlinux-stable-4fdcfa12843bca38d0c9deff70c8720e4e8f515f.tar.gz
linux-stable-4fdcfa12843bca38d0c9deff70c8720e4e8f515f.tar.bz2
linux-stable-4fdcfa12843bca38d0c9deff70c8720e4e8f515f.zip
drop_monitor: prevent init path from scheduling on the wrong cpu
I just noticed after some recent updates, that the init path for the drop monitor protocol has a minor error. drop monitor maintains a per cpu structure, that gets initalized from a single cpu. Normally this is fine, as the protocol isn't in use yet, but I recently made a change that causes a failed skb allocation to reschedule itself . Given the current code, the implication is that this workqueue reschedule will take place on the wrong cpu. If drop monitor is used early during the boot process, its possible that two cpus will access a single per-cpu structure in parallel, possibly leading to data corruption. This patch fixes the situation, by storing the cpu number that a given instance of this per-cpu data should be accessed from. In the case of a need for a reschedule, the cpu stored in the struct is assigned the rescheule, rather than the currently executing cpu Tested successfully by myself. Signed-off-by: Neil Horman <nhorman@tuxdriver.com> CC: David Miller <davem@davemloft.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions