summaryrefslogtreecommitdiff
path: root/arch/x86
diff options
context:
space:
mode:
authorPaul Gortmaker <paul.gortmaker@windriver.com>2014-01-14 21:03:37 (GMT)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2014-02-13 18:41:47 (GMT)
commitf76a1cbed18c86e2d192455f0daebb48458965f3 (patch)
tree6372a788551489c9fc68dfb82627c1970bdde4b1 /arch/x86
parent9be16b38cf43181efc12ee6f467aaf222ad31b03 (diff)
downloadlinux-f76a1cbed18c86e2d192455f0daebb48458965f3.tar.xz
hvc: ensure hvc_init is only ever called once in hvc_console.c
Commit 3e6c6f630a5282df8f3393a59f10eb9c56536d23 ("Delay creation of khcvd thread") moved the call of hvc_init from being a device_initcall into hvc_alloc, and used a non-null hvc_driver as indication of whether hvc_init had already been called. The problem with this is that hvc_driver is only assigned a value at the bottom of hvc_init, and so there is a window where multiple hvc_alloc calls can be in progress at the same time and hence try and call hvc_init multiple times. Previously the use of device_init guaranteed that hvc_init was only called once. This manifests itself as sporadic instances of two hvc_init calls racing each other, and with the loser of the race getting -EBUSY from tty_register_driver() and hence that virtual console fails: Couldn't register hvc console driver virtio-ports vport0p1: error -16 allocating hvc for port Here we add an atomic_t to guarantee we'll never run hvc_init twice. Cc: stable@vger.kernel.org # v2.6.24+ Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Fixes: 3e6c6f630a52 ("Delay creation of khcvd thread") Reported-by: Jim Somerville <Jim.Somerville@windriver.com> Tested-by: Jim Somerville <Jim.Somerville@windriver.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'arch/x86')
0 files changed, 0 insertions, 0 deletions