aboutsummaryrefslogtreecommitdiffstats
path: root/virt/kvm/eventfd.c
diff options
context:
space:
mode:
authorNitin Gupta <ngupta@vflare.org>2010-12-30 04:07:58 -0500
committerLinus Torvalds <torvalds@linux-foundation.org>2010-12-30 12:07:22 -0800
commite983dc2428164698571e1dd1b25c4322181adbac (patch)
tree8daebe3e685971ea0db8ddc0dcda96a1781019b2 /virt/kvm/eventfd.c
parentff20f1779b7f60a9682aa8d62f8ca3b650e4c360 (diff)
downloadkernel_samsung_tuna-e983dc2428164698571e1dd1b25c4322181adbac.zip
kernel_samsung_tuna-e983dc2428164698571e1dd1b25c4322181adbac.tar.gz
kernel_samsung_tuna-e983dc2428164698571e1dd1b25c4322181adbac.tar.bz2
Revert "Staging: zram: work around oops due to startup ordering snafu"
This reverts commit 7e24cce38a99f373450db67bf576fe73e8168d66 because it was never appropriate for mainline. Do not check for init flag before starting I/O - zram module is unusable without this fix. The oops mentioned in the reverted commit message was actually a problem only with the zram version as present in project's own repository where we allocate struct zram_stats_cpu upon device initialization. OTOH, In mainline/staging version of zram, we allocate struct stats upfront, so this oops cannot happen in mainline version. Checking for init_done flag in zram_make_request() results in a *no-op* for any I/O operation since we simply always return success. This flag is actually set when the first write occurs on a zram disk which triggers its initialization. Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=25722 Reported-by: Dennis Jansen <dennis.jansen@web.de> Signed-off-by: Nitin Gupta <ngupta@vflare.org> Cc: Anton Blanchard <anton@samba.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'virt/kvm/eventfd.c')
0 files changed, 0 insertions, 0 deletions