28 Jul, 2016

1 commit

  • As explained in 1407814240-4275-1-git-send-email-decui@microsoft.com we
    have a hard load dependency between i8042 and atkbd which prevents
    keyboard from working on Gen2 Hyper-V VMs.

    > hyperv_keyboard invokes serio_interrupt(), which needs a valid serio
    > driver like atkbd.c. atkbd.c depends on libps2.c because it invokes
    > ps2_command(). libps2.c depends on i8042.c because it invokes
    > i8042_check_port_owner(). As a result, hyperv_keyboard actually
    > depends on i8042.c.
    >
    > For a Generation 2 Hyper-V VM (meaning no i8042 device emulated), if a
    > Linux VM (like Arch Linux) happens to configure CONFIG_SERIO_I8042=m
    > rather than =y, atkbd.ko can't load because i8042.ko can't load(due to
    > no i8042 device emulated) and finally hyperv_keyboard can't work and
    > the user can't input: https://bugs.archlinux.org/task/39820
    > (Ubuntu/RHEL/SUSE aren't affected since they use CONFIG_SERIO_I8042=y)

    To break the dependency we move away from using i8042_check_port_owner()
    and instead allow serio port owner specify a mutex that clients should use
    to serialize PS/2 command stream.

    Reported-by: Mark Laws
    Tested-by: Mark Laws
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov

    Dmitry Torokhov
     

30 Sep, 2015

1 commit

  • The data race happens on ps2dev->cmdcnt and ps2dev->cmdbuf contents.
    __ps2_command reads that data concurrently with the interrupt handler. As
    the result, for example, if a response arrives just after the timeout,
    __ps2_command can copy out garbage from ps2dev->cmdbuf but then see that
    ps2dev->cmdcnt is 0 and return success.

    Stop the interrupt handler with serio_pause_rx() before reading the
    results.

    The data race was found with KernelThreadSanitizer (KTSAN).

    Signed-off-by: Dmitry Vyukov
    Signed-off-by: Dmitry Torokhov

    Dmitry Vyukov
     

07 Jan, 2014

1 commit


27 Jun, 2011

1 commit


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

12 Oct, 2009

1 commit


18 Sep, 2009

1 commit

  • The serio ports on i8042 are not completely isolated; while we provide
    enough locking to ensure proper serialization when accessing control
    and data registers AUX and KBD ports can still have an effect on each
    other on PS/2 protocol level. The most prominent effect is that
    issuing a command for the device connected to one port may cause
    abort of the command currently executing by the device connected to
    another port.

    Since i8042 nor serio subsystem are not aware of the details of the
    PS/2 protocol (length of the commands and their replies and so on) the
    locking should be done on libps2 level by adding special handling when
    we see that we are dealing with serio port on i8042.

    Signed-off-by: Dmitry Torokhov

    Dmitry Torokhov
     

20 Aug, 2009

1 commit


29 May, 2009

1 commit

  • Sometimes devices send us their responses in time but due to
    unfortunate scheduling decisions the receiving thread does not
    get scheduled till much later and we erroneously decide that
    device timed out. Work around this problem by checking whether we
    received the data we needed instead of checking timeout
    condition.

    Tested-by: Sitsofe Wheeler
    Signed-off-by: Dmitry Torokhov

    Dmitry Torokhov
     

25 Nov, 2008

1 commit


17 May, 2008

1 commit


21 Jan, 2008

1 commit


18 Feb, 2007

1 commit


22 Nov, 2006

1 commit

  • Pass the work_struct pointer to the work function rather than context data.
    The work function can use container_of() to work out the data.

    For the cases where the container of the work_struct may go away the moment the
    pending bit is cleared, it is made possible to defer the release of the
    structure by deferring the clearing of the pending bit.

    To make this work, an extra flag is introduced into the management side of the
    work_struct. This governs auto-release of the structure upon execution.

    Ordinarily, the work queue executor would release the work_struct for further
    scheduling or deallocation by clearing the pending bit prior to jumping to the
    work function. This means that, unless the driver makes some guarantee itself
    that the work_struct won't go away, the work function may not access anything
    else in the work_struct or its container lest they be deallocated.. This is a
    problem if the auxiliary data is taken away (as done by the last patch).

    However, if the pending bit is *not* cleared before jumping to the work
    function, then the work function *may* access the work_struct and its container
    with no problems. But then the work function must itself release the
    work_struct by calling work_release().

    In most cases, automatic release is fine, so this is the default. Special
    initiators exist for the non-auto-release case (ending in _NAR).

    Signed-Off-By: David Howells

    David Howells
     

11 Oct, 2006

1 commit


14 Sep, 2006

2 commits


07 Jul, 2006

1 commit


04 Jul, 2006

1 commit

  • The PS/2 code has a natural device order and there is a one level recursion in
    this device order in terms of the cmd_mutex; annotate this explicit recursion
    as ok.

    Has no effect on non-lockdep kernels.

    Signed-off-by: Arjan van de Ven
    Cc: Dmitry Torokhov
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arjan van de Ven
     

19 Feb, 2006

1 commit


01 Jun, 2005

2 commits


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds