1. 19 Aug, 2019 1 commit
  2. 14 Jun, 2019 1 commit
    • Josh Poimboeuf's avatar
      module: Fix livepatch/ftrace module text permissions race · 9f255b63
      Josh Poimboeuf authored
      It's possible for livepatch and ftrace to be toggling a module's text
      permissions at the same time, resulting in the following panic:
      
        BUG: unable to handle page fault for address: ffffffffc005b1d9
        #PF: supervisor write access in kernel mode
        #PF: error_code(0x0003) - permissions violation
        PGD 3ea0c067 P4D 3ea0c067 PUD 3ea0e067 PMD 3cc13067 PTE 3b8a1061
        Oops: 0003 [#1] PREEMPT SMP PTI
        CPU: 1 PID: 453 Comm: insmod Tainted: G           O  K   5.2.0-rc1-a188339c #1
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-20181126_142135-anatol 04/01/2014
        RIP: 0010:apply_relocate_add+0xbe/0x14c
        Code: fa 0b 74 21 48 83 fa 18 74 38 48 83 fa 0a 75 40 eb 08 48 83 38 00 74 33 eb 53 83 38 00 75 4e 89 08 89 c8 eb 0a 83 38 00 75 43 <89> 08 48 63 c1 48 39 c8 74 2e eb 48 83 38 00 75 32 48 29 c1 89 08
        RSP: 0018:ffffb223c00dbb10 EFLAGS: 00010246
        RAX: ffffffffc005b1d9 RBX: 0000000000000000 RCX: ffffffff8b200060
        RDX: 000000000000000b RSI: 0000004b0000000b RDI: ffff96bdfcd33000
        RBP: ffffb223c00dbb38 R08: ffffffffc005d040 R09: ffffffffc005c1f0
        R10: ffff96bdfcd33c40 R11: ffff96bdfcd33b80 R12: 0000000000000018
        R13: ffffffffc005c1f0 R14: ffffffffc005e708 R15: ffffffff8b2fbc74
        FS:  00007f5f447beba8(0000) GS:ffff96bdff900000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: ffffffffc005b1d9 CR3: 000000003cedc002 CR4: 0000000000360ea0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        Call Trace:
         klp_init_object_loaded+0x10f/0x219
         ? preempt_latency_start+0x21/0x57
         klp_enable_patch+0x662/0x809
         ? virt_to_head_page+0x3a/0x3c
         ? kfree+0x8c/0x126
         patch_init+0x2ed/0x1000 [livepatch_test02]
         ? 0xffffffffc0060000
         do_one_initcall+0x9f/0x1c5
         ? kmem_cache_alloc_trace+0xc4/0xd4
         ? do_init_module+0x27/0x210
         do_init_module+0x5f/0x210
         load_module+0x1c41/0x2290
         ? fsnotify_path+0x3b/0x42
         ? strstarts+0x2b/0x2b
         ? kernel_read+0x58/0x65
         __do_sys_finit_module+0x9f/0xc3
         ? __do_sys_finit_module+0x9f/0xc3
         __x64_sys_finit_module+0x1a/0x1c
         do_syscall_64+0x52/0x61
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      The above panic occurs when loading two modules at the same time with
      ftrace enabled, where at least one of the modules is a livepatch module:
      
      CPU0					CPU1
      klp_enable_patch()
        klp_init_object_loaded()
          module_disable_ro()
          					ftrace_module_enable()
      					  ftrace_arch_code_modify_post_process()
      				    	    set_all_modules_text_ro()
            klp_write_object_relocations()
              apply_relocate_add()
      	  *patches read-only code* - BOOM
      
      A similar race exists when toggling ftrace while loading a livepatch
      module.
      
      Fix it by ensuring that the livepatch and ftrace code patching
      operations -- and their respective permissions changes -- are protected
      by the text_mutex.
      
      Link: http://lkml.kernel.org/r/ab43d56ab909469ac5d2520c5d944ad6d4abd476.1560474114.git.jpoimboe@redhat.com
      
      Reported-by: default avatarJohannes Erdfelt <johannes@erdfelt.com>
      Fixes: 444d13ff
      
       ("modules: add ro_after_init support")
      Acked-by: default avatarJessica Yu <jeyu@kernel.org>
      Reviewed-by: default avatarPetr Mladek <pmladek@suse.com>
      Reviewed-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      9f255b63
  3. 21 May, 2019 1 commit
    • Thomas Gleixner's avatar
      treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 13 · 1ccea77e
      Thomas Gleixner authored
      
      
      Based on 2 normalized pattern(s):
      
        this program is free software you can redistribute it and or modify
        it under the terms of the gnu general public license as published by
        the free software foundation either version 2 of the license or at
        your option any later version this program is distributed in the
        hope that it will be useful but without any warranty without even
        the implied warranty of merchantability or fitness for a particular
        purpose see the gnu general public license for more details you
        should have received a copy of the gnu general public license along
        with this program if not see http www gnu org licenses
      
        this program is free software you can redistribute it and or modify
        it under the terms of the gnu general public license as published by
        the free software foundation either version 2 of the license or at
        your option any later version this program is distributed in the
        hope that it will be useful but without any warranty without even
        the implied warranty of merchantability or fitness for a particular
        purpose see the gnu general public license for more details [based]
        [from] [clk] [highbank] [c] you should have received a copy of the
        gnu general public license along with this program if not see http
        www gnu org licenses
      
      extracted by the scancode license scanner the SPDX license identifier
      
        GPL-2.0-or-later
      
      has been chosen to replace the boilerplate/reference in 355 file(s).
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarJilayne Lovejoy <opensource@jilayne.com>
      Reviewed-by: default avatarSteve Winslow <swinslow@gmail.com>
      Reviewed-by: default avatarAllison Randal <allison@lohutok.net>
      Cc: linux-spdx@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190519154041.837383322@linutronix.de
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ccea77e
  4. 10 May, 2019 1 commit
  5. 03 May, 2019 2 commits
  6. 29 Apr, 2019 1 commit
  7. 25 Apr, 2019 1 commit
  8. 06 Feb, 2019 3 commits
  9. 16 Jan, 2019 1 commit
  10. 11 Jan, 2019 9 commits
    • Petr Mladek's avatar
      livepatch: Remove ordering (stacking) of the livepatches · d67a5372
      Petr Mladek authored
      
      
      The atomic replace and cumulative patches were introduced as a more secure
      way to handle dependent patches. They simplify the logic:
      
        + Any new cumulative patch is supposed to take over shadow variables
          and changes made by callbacks from previous livepatches.
      
        + All replaced patches are discarded and the modules can be unloaded.
          As a result, there is only one scenario when a cumulative livepatch
          gets disabled.
      
      The different handling of "normal" and cumulative patches might cause
      confusion. It would make sense to keep only one mode. On the other hand,
      it would be rude to enforce using the cumulative livepatches even for
      trivial and independent (hot) fixes.
      
      However, the stack of patches is not really necessary any longer.
      The patch ordering was never clearly visible via the sysfs interface.
      Also the "normal" patches need a lot of caution anyway.
      
      Note that the list of enabled patches is still necessary but the ordering
      is not longer enforced.
      
      Otherwise, the code is ready to disable livepatches in an random order.
      Namely, klp_check_stack_func() always looks for the function from
      the livepatch that is being disabled. klp_func structures are just
      removed from the related func_stack. Finally, the ftrace handlers
      is removed only when the func_stack becomes empty.
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      d67a5372
    • Petr Mladek's avatar
      livepatch: Remove Nop structures when unused · d697bad5
      Petr Mladek authored
      
      
      Replaced patches are removed from the stack when the transition is
      finished. It means that Nop structures will never be needed again
      and can be removed. Why should we care?
      
        + Nop structures give the impression that the function is patched
          even though the ftrace handler has no effect.
      
        + Ftrace handlers do not come for free. They cause slowdown that might
          be visible in some workloads. The ftrace-related slowdown might
          actually be the reason why the function is no longer patched in
          the new cumulative patch. One would expect that cumulative patch
          would help solve these problems as well.
      
        + Cumulative patches are supposed to replace any earlier version of
          the patch. The amount of NOPs depends on which version was replaced.
          This multiplies the amount of scenarios that might happen.
      
          One might say that NOPs are innocent. But there are even optimized
          NOP instructions for different processors, for example, see
          arch/x86/kernel/alternative.c. And klp_ftrace_handler() is much
          more complicated.
      
        + It sounds natural to clean up a mess that is no longer needed.
          It could only be worse if we do not do it.
      
      This patch allows to unpatch and free the dynamic structures independently
      when the transition finishes.
      
      The free part is a bit tricky because kobject free callbacks are called
      asynchronously. We could not wait for them easily. Fortunately, we do
      not have to. Any further access can be avoided by removing them from
      the dynamic lists.
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      d697bad5
    • Jason Baron's avatar
      livepatch: Add atomic replace · e1452b60
      Jason Baron authored
      
      
      Sometimes we would like to revert a particular fix. Currently, this
      is not easy because we want to keep all other fixes active and we
      could revert only the last applied patch.
      
      One solution would be to apply new patch that implemented all
      the reverted functions like in the original code. It would work
      as expected but there will be unnecessary redirections. In addition,
      it would also require knowing which functions need to be reverted at
      build time.
      
      Another problem is when there are many patches that touch the same
      functions. There might be dependencies between patches that are
      not enforced on the kernel side. Also it might be pretty hard to
      actually prepare the patch and ensure compatibility with the other
      patches.
      
      Atomic replace && cumulative patches:
      
      A better solution would be to create cumulative patch and say that
      it replaces all older ones.
      
      This patch adds a new "replace" flag to struct klp_patch. When it is
      enabled, a set of 'nop' klp_func will be dynamically created for all
      functions that are already being patched but that will no longer be
      modified by the new patch. They are used as a new target during
      the patch transition.
      
      The idea is to handle Nops' structures like the static ones. When
      the dynamic structures are allocated, we initialize all values that
      are normally statically defined.
      
      The only exception is "new_func" in struct klp_func. It has to point
      to the original function and the address is known only when the object
      (module) is loaded. Note that we really need to set it. The address is
      used, for example, in klp_check_stack_func().
      
      Nevertheless we still need to distinguish the dynamically allocated
      structures in some operations. For this, we add "nop" flag into
      struct klp_func and "dynamic" flag into struct klp_object. They
      need special handling in the following situations:
      
        + The structures are added into the lists of objects and functions
          immediately. In fact, the lists were created for this purpose.
      
        + The address of the original function is known only when the patched
          object (module) is loaded. Therefore it is copied later in
          klp_init_object_loaded().
      
        + The ftrace handler must not set PC to func->new_func. It would cause
          infinite loop because the address points back to the beginning of
          the original function.
      
        + The various free() functions must free the structure itself.
      
      Note that other ways to detect the dynamic structures are not considered
      safe. For example, even the statically defined struct klp_object might
      include empty funcs array. It might be there just to run some callbacks.
      
      Also note that the safe iterator must be used in the free() functions.
      Otherwise already freed structures might get accessed.
      
      Special callbacks handling:
      
      The callbacks from the replaced patches are _not_ called by intention.
      It would be pretty hard to define a reasonable semantic and implement it.
      
      It might even be counter-productive. The new patch is cumulative. It is
      supposed to include most of the changes from older patches. In most cases,
      it will not want to call pre_unpatch() post_unpatch() callbacks from
      the replaced patches. It would disable/break things for no good reasons.
      Also it should be easier to handle various scenarios in a single script
      in the new patch than think about interactions caused by running many
      scripts from older patches. Not to say that the old scripts even would
      not expect to be called in this situation.
      
      Removing replaced patches:
      
      One nice effect of the cumulative patches is that the code from the
      older patches is no longer used. Therefore the replaced patches can
      be removed. It has several advantages:
      
        + Nops' structs will no longer be necessary and might be removed.
          This would save memory, restore performance (no ftrace handler),
          allow clear view on what is really patched.
      
        + Disabling the patch will cause using the original code everywhere.
          Therefore the livepatch callbacks could handle only one scenario.
          Note that the complication is already complex enough when the patch
          gets enabled. It is currently solved by calling callbacks only from
          the new cumulative patch.
      
        + The state is clean in both the sysfs interface and lsmod. The modules
          with the replaced livepatches might even get removed from the system.
      
      Some people actually expected this behavior from the beginning. After all
      a cumulative patch is supposed to "completely" replace an existing one.
      It is like when a new version of an application replaces an older one.
      
      This patch does the first step. It removes the replaced patches from
      the list of patches. It is safe. The consistency model ensures that
      they are no longer used. By other words, each process works only with
      the structures from klp_transition_patch.
      
      The removal is done by a special function. It combines actions done by
      __disable_patch() and klp_complete_transition(). But it is a fast
      track without all the transaction-related stuff.
      Signed-off-by: default avatarJason Baron <jbaron@akamai.com>
      [pmladek@suse.com: Split, reuse existing code, simplified]
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Jessica Yu <jeyu@kernel.org>
      Cc: Jiri Kosina <jikos@kernel.org>
      Cc: Miroslav Benes <mbenes@suse.cz>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      e1452b60
    • Jason Baron's avatar
      livepatch: Use lists to manage patches, objects and functions · 20e55025
      Jason Baron authored
      
      
      Currently klp_patch contains a pointer to a statically allocated array of
      struct klp_object and struct klp_objects contains a pointer to a statically
      allocated array of klp_func. In order to allow for the dynamic allocation
      of objects and functions, link klp_patch, klp_object, and klp_func together
      via linked lists. This allows us to more easily allocate new objects and
      functions, while having the iterator be a simple linked list walk.
      
      The static structures are added to the lists early. It allows to add
      the dynamically allocated objects before klp_init_object() and
      klp_init_func() calls. Therefore it reduces the further changes
      to the code.
      
      This patch does not change the existing behavior.
      Signed-off-by: default avatarJason Baron <jbaron@akamai.com>
      [pmladek@suse.com: Initialize lists before init calls]
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Acked-by: default avatarJoe Lawrence <joe.lawrence@redhat.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Jiri Kosina <jikos@kernel.org>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      20e55025
    • Petr Mladek's avatar
      livepatch: Simplify API by removing registration step · 958ef1e3
      Petr Mladek authored
      
      
      The possibility to re-enable a registered patch was useful for immediate
      patches where the livepatch module had to stay until the system reboot.
      The improved consistency model allows to achieve the same result by
      unloading and loading the livepatch module again.
      
      Also we are going to add a feature called atomic replace. It will allow
      to create a patch that would replace all already registered patches.
      The aim is to handle dependent patches more securely. It will obsolete
      the stack of patches that helped to handle the dependencies so far.
      Then it might be unclear when a cumulative patch re-enabling is safe.
      
      It would be complicated to support the many modes. Instead we could
      actually make the API and code easier to understand.
      
      Therefore, remove the two step public API. All the checks and init calls
      are moved from klp_register_patch() to klp_enabled_patch(). Also the patch
      is automatically freed, including the sysfs interface when the transition
      to the disabled state is completed.
      
      As a result, there is never a disabled patch on the top of the stack.
      Therefore we do not need to check the stack in __klp_enable_patch().
      And we could simplify the check in __klp_disable_patch().
      
      Also the API and logic is much easier. It is enough to call
      klp_enable_patch() in module_init() call. The patch can be disabled
      by writing '0' into /sys/kernel/livepatch/<patch>/enabled. Then the module
      can be removed once the transition finishes and sysfs interface is freed.
      
      The only problem is how to free the structures and kobjects safely.
      The operation is triggered from the sysfs interface. We could not put
      the related kobject from there because it would cause lock inversion
      between klp_mutex and kernfs locks, see kn->count lockdep map.
      
      Therefore, offload the free task to a workqueue. It is perfectly fine:
      
        + The patch can no longer be used in the livepatch operations.
      
        + The module could not be removed until the free operation finishes
          and module_put() is called.
      
        + The operation is asynchronous already when the first
          klp_try_complete_transition() fails and another call
          is queued with a delay.
      Suggested-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      958ef1e3
    • Petr Mladek's avatar
      livepatch: Don't block the removal of patches loaded after a forced transition · 68007289
      Petr Mladek authored
      
      
      module_put() is currently never called in klp_complete_transition() when
      klp_force is set. As a result, we might keep the reference count even when
      klp_enable_patch() fails and klp_cancel_transition() is called.
      
      This might give the impression that a module might get blocked in some
      strange init state. Fortunately, it is not the case. The reference count
      is ignored when mod->init fails and erroneous modules are always removed.
      
      Anyway, this might be confusing. Instead, this patch moves
      the global klp_forced flag into struct klp_patch. As a result,
      we block only modules that might still be in use after a forced
      transition. Newly loaded livepatches might be eventually completely
      removed later.
      
      It is not a big deal. But the code is at least consistent with
      the reality.
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarJoe Lawrence <joe.lawrence@redhat.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      68007289
    • Petr Mladek's avatar
      livepatch: Consolidate klp_free functions · 0430f78b
      Petr Mladek authored
      
      
      The code for freeing livepatch structures is a bit scattered and tricky:
      
        + direct calls to klp_free_*_limited() and kobject_put() are
          used to release partially initialized objects
      
        + klp_free_patch() removes the patch from the public list
          and releases all objects except for patch->kobj
      
        + object_put(&patch->kobj) and the related wait_for_completion()
          are called directly outside klp_mutex; this code is duplicated;
      
      Now, we are going to remove the registration stage to simplify the API
      and the code. This would require handling more situations in
      klp_enable_patch() error paths.
      
      More importantly, we are going to add a feature called atomic replace.
      It will need to dynamically create func and object structures. We will
      want to reuse the existing init() and free() functions. This would
      create even more error path scenarios.
      
      This patch implements more straightforward free functions:
      
        + checks kobj_added flag instead of @limit[*]
      
        + initializes patch->list early so that the check for empty list
          always works
      
        + The action(s) that has to be done outside klp_mutex are done
          in separate klp_free_patch_finish() function. It waits only
          when patch->kobj was really released via the _start() part.
      
      The patch does not change the existing behavior.
      
      [*] We need our own flag to track that the kobject was successfully
          added to the hierarchy.  Note that kobj.state_initialized only
          indicates that kobject has been initialized, not whether is has
          been added (and needs to be removed on cleanup).
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Miroslav Benes <mbenes@suse.cz>
      Cc: Jessica Yu <jeyu@kernel.org>
      Cc: Jiri Kosina <jikos@kernel.org>
      Cc: Jason Baron <jbaron@akamai.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      0430f78b
    • Petr Mladek's avatar
      livepatch: Shuffle klp_enable_patch()/klp_disable_patch() code · 26c3e98e
      Petr Mladek authored
      
      
      We are going to simplify the API and code by removing the registration
      step. This would require calling init/free functions from enable/disable
      ones.
      
      This patch just moves the code to prevent more forward declarations.
      
      This patch does not change the code except for two forward declarations.
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Acked-by: default avatarJoe Lawrence <joe.lawrence@redhat.com>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      26c3e98e
    • Petr Mladek's avatar
      livepatch: Change unsigned long old_addr -> void *old_func in struct klp_func · 19514910
      Petr Mladek authored
      
      
      The address of the to be patched function and new function is stored
      in struct klp_func as:
      
      	void *new_func;
      	unsigned long old_addr;
      
      The different naming scheme and type are derived from the way
      the addresses are set. @old_addr is assigned at runtime using
      kallsyms-based search. @new_func is statically initialized,
      for example:
      
        static struct klp_func funcs[] = {
      	{
      		.old_name = "cmdline_proc_show",
      		.new_func = livepatch_cmdline_proc_show,
      	}, { }
        };
      
      This patch changes unsigned long old_addr -> void *old_func. It removes
      some confusion when these address are later used in the code. It is
      motivated by a followup patch that adds special NOP struct klp_func
      where we want to assign func->new_func = func->old_addr respectively
      func->new_func = func->old_func.
      
      This patch does not modify the existing behavior.
      Suggested-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Acked-by: default avatarJoe Lawrence <joe.lawrence@redhat.com>
      Acked-by: default avatarAlice Ferrazzi <alice.ferrazzi@gmail.com>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      19514910
  11. 23 Jul, 2018 1 commit
    • Kamalesh Babulal's avatar
      livepatch: Validate module/old func name length · 6e9df95b
      Kamalesh Babulal authored
      
      
      livepatch module author can pass module name/old function name with more
      than the defined character limit. With obj->name length greater than
      MODULE_NAME_LEN, the livepatch module gets loaded but waits forever on
      the module specified by obj->name to be loaded. It also populates a /sys
      directory with an untruncated object name.
      
      In the case of funcs->old_name length greater then KSYM_NAME_LEN, it
      would not match against any of the symbol table entries. Instead loop
      through the symbol table comparing them against a nonexisting function,
      which can be avoided.
      
      The same issues apply, to misspelled/incorrect names. At least gatekeep
      the modules with over the limit string length, by checking for their
      length during livepatch module registration.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarKamalesh Babulal <kamalesh@linux.vnet.ibm.com>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      6e9df95b
  12. 11 Jan, 2018 2 commits
    • Miroslav Benes's avatar
      livepatch: add locking to force and signal functions · 8869016d
      Miroslav Benes authored
      klp_send_signals() and klp_force_transition() do not acquire klp_mutex,
      because it seemed to be superfluous. A potential race in
      klp_send_signals() was harmless and there was nothing in
      klp_force_transition() which needed to be synchronized. That changed
      with the addition of klp_forced variable during the review process.
      
      There is a small window now, when klp_complete_transition() does not see
      klp_forced set to true while all tasks have been already transitioned to
      the target state. module_put() is called and the module can be removed.
      
      Acquire klp_mutex in sysfs callback to prevent it. Do the same for the
      signal sending just to be sure. There is no real downside to that.
      
      Fixes: c99a2be7 ("livepatch: force transition to finish")
      Fixes: 43347d56
      
       ("livepatch: send a fake signal to all blocking tasks")
      Reported-by: default avatarJason Baron <jbaron@akamai.com>
      Signed-off-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Reviewed-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      8869016d
    • Miroslav Benes's avatar
      livepatch: Remove immediate feature · d0807da7
      Miroslav Benes authored
      
      
      Immediate flag has been used to disable per-task consistency and patch
      all tasks immediately. It could be useful if the patch doesn't change any
      function or data semantics.
      
      However, it causes problems on its own. The consistency problem is
      currently broken with respect to immediate patches.
      
      func            a
      patches         1i
                      2i
                      3
      
      When the patch 3 is applied, only 2i function is checked (by stack
      checking facility). There might be a task sleeping in 1i though. Such
      task is migrated to 3, because we do not check 1i in
      klp_check_stack_func() at all.
      
      Coming atomic replace feature would be easier to implement and more
      reliable without immediate.
      
      Thus, remove immediate feature completely and save us from the problems.
      
      Note that force feature has the similar problem. However it is
      considered as a last resort. If used, administrator should not apply any
      new live patches and should plan for reboot into an updated kernel.
      
      The architectures would now need to provide HAVE_RELIABLE_STACKTRACE to
      fully support livepatch.
      Signed-off-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      d0807da7
  13. 07 Dec, 2017 1 commit
    • Miroslav Benes's avatar
      livepatch: force transition to finish · c99a2be7
      Miroslav Benes authored
      
      
      If a task sleeps in a set of patched functions uninterruptedly, it could
      block the whole transition indefinitely.  Thus it may be useful to clear
      its TIF_PATCH_PENDING to allow the process to finish.
      
      Admin can do that now by writing to force sysfs attribute in livepatch
      sysfs directory. TIF_PATCH_PENDING is then cleared for all tasks and the
      transition can finish successfully.
      
      Important note! Administrator should not use this feature without a
      clearance from a patch distributor. It must be checked that by doing so
      the consistency model guarantees are not violated. Removal (rmmod) of
      patch modules is permanently disabled when the feature is used. It
      cannot be guaranteed there is no task sleeping in such module.
      Signed-off-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Reviewed-by: default avatarPetr Mladek <pmladek@suse.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      c99a2be7
  14. 04 Dec, 2017 1 commit
    • Miroslav Benes's avatar
      livepatch: send a fake signal to all blocking tasks · 43347d56
      Miroslav Benes authored
      
      
      Live patching consistency model is of LEAVE_PATCHED_SET and
      SWITCH_THREAD. This means that all tasks in the system have to be marked
      one by one as safe to call a new patched function. Safe means when a
      task is not (sleeping) in a set of patched functions. That is, no
      patched function is on the task's stack. Another clearly safe place is
      the boundary between kernel and userspace. The patching waits for all
      tasks to get outside of the patched set or to cross the boundary. The
      transition is completed afterwards.
      
      The problem is that a task can block the transition for quite a long
      time, if not forever. It could sleep in a set of patched functions, for
      example.  Luckily we can force the task to leave the set by sending it a
      fake signal, that is a signal with no data in signal pending structures
      (no handler, no sign of proper signal delivered). Suspend/freezer use
      this to freeze the tasks as well. The task gets TIF_SIGPENDING set and
      is woken up (if it has been sleeping in the kernel before) or kicked by
      rescheduling IPI (if it was running on other CPU). This causes the task
      to go to kernel/userspace boundary where the signal would be handled and
      the task would be marked as safe in terms of live patching.
      
      There are tasks which are not affected by this technique though. The
      fake signal is not sent to kthreads. They should be handled differently.
      They can be woken up so they leave the patched set and their
      TIF_PATCH_PENDING can be cleared thanks to stack checking.
      
      For the sake of completeness, if the task is in TASK_RUNNING state but
      not currently running on some CPU it doesn't get the IPI, but it would
      eventually handle the signal anyway. Second, if the task runs in the
      kernel (in TASK_RUNNING state) it gets the IPI, but the signal is not
      handled on return from the interrupt. It would be handled on return to
      the userspace in the future when the fake signal is sent again. Stack
      checking deals with these cases in a better way.
      
      If the task was sleeping in a syscall it would be woken by our fake
      signal, it would check if TIF_SIGPENDING is set (by calling
      signal_pending() predicate) and return ERESTART* or EINTR. Syscalls with
      ERESTART* return values are restarted in case of the fake signal (see
      do_signal()). EINTR is propagated back to the userspace program. This
      could disturb the program, but...
      
      * each process dealing with signals should react accordingly to EINTR
        return values.
      * syscalls returning EINTR happen to be quite common situation in the
        system even if no fake signal is sent.
      * freezer sends the fake signal and does not deal with EINTR anyhow.
        Thus EINTR values are returned when the system is resumed.
      
      The very safe marking is done in architectures' "entry" on syscall and
      interrupt/exception exit paths, and in a stack checking functions of
      livepatch.  TIF_PATCH_PENDING is cleared and the next
      recalc_sigpending() drops TIF_SIGPENDING. In connection with this, also
      call klp_update_patch_state() before do_signal(), so that
      recalc_sigpending() in dequeue_signal() can clear TIF_PATCH_PENDING
      immediately and thus prevent a double call of do_signal().
      
      Note that the fake signal is not sent to stopped/traced tasks. Such task
      prevents the patching to finish till it continues again (is not traced
      anymore).
      
      Last, sending the fake signal is not automatic. It is done only when
      admin requests it by writing 1 to signal sysfs attribute in livepatch
      sysfs directory.
      Signed-off-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: x86@kernel.org
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      43347d56
  15. 26 Oct, 2017 2 commits
    • Petr Mladek's avatar
      livepatch: __klp_disable_patch() should never be called for disabled patches · 89a9a1c1
      Petr Mladek authored
      
      
      __klp_disable_patch() should never be called when the patch is not
      enabled. Let's add the same warning that we have in __klp_enable_patch().
      
      This allows to remove the check when calling klp_pre_unpatch_callback().
      It was strange anyway because it repeatedly checked per-patch flag
      for each patched object.
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarJoe Lawrence <joe.lawrence@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      89a9a1c1
    • Petr Mladek's avatar
      livepatch: Correctly call klp_post_unpatch_callback() in error paths · 5aaf1ab5
      Petr Mladek authored
      
      
      The post_unpatch_enabled flag in struct klp_callbacks is set when a
      pre-patch callback successfully executes, indicating that we need to
      call a corresponding post-unpatch callback when the patch is reverted.
      This is true for ordinary patch disable as well as the error paths of
      klp_patch_object() callers.
      
      As currently coded, we inadvertently execute the post-patch callback
      twice in klp_module_coming() when klp_patch_object() fails:
      
        - We explicitly call klp_post_unpatch_callback() for the failed object
        - We call it again for the same object (and all the others) via
          klp_cleanup_module_patches_limited()
      
      We should clear the flag in klp_post_unpatch_callback() to make
      sure that the callback is not called twice. It makes the API
      more safe.
      
      (We could have removed the callback from the former error path as it
      would be covered by the latter call, but I think that is is cleaner to
      clear the post_unpatch_enabled after its invoked. For example, someone
      might later decide to call the callback only when obj->patched flag is
      set.)
      
      There is another mistake in the error path of klp_coming_module() in
      which it skips the post-unpatch callback for the klp_transition_patch.
      However, the pre-patch callback was called even for this patch, so be
      sure to make the corresponding callbacks for all patches.
      
      Finally, I used this opportunity to make klp_pre_patch_callback() more
      readable.
      
      [jkosina@suse.cz: incorporate changelog wording changes proposed by Joe Lawrence]
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarJoe Lawrence <joe.lawrence@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      5aaf1ab5
  16. 19 Oct, 2017 1 commit
    • Joe Lawrence's avatar
      livepatch: add (un)patch callbacks · 93862e38
      Joe Lawrence authored
      
      
      Provide livepatch modules a klp_object (un)patching notification
      mechanism.  Pre and post-(un)patch callbacks allow livepatch modules to
      setup or synchronize changes that would be difficult to support in only
      patched-or-unpatched code contexts.
      
      Callbacks can be registered for target module or vmlinux klp_objects,
      but each implementation is klp_object specific.
      
        - Pre-(un)patch callbacks run before any (un)patching transition
          starts.
      
        - Post-(un)patch callbacks run once an object has been (un)patched and
          the klp_patch fully transitioned to its target state.
      
      Example use cases include modification of global data and registration
      of newly available services/handlers.
      
      See Documentation/livepatch/callbacks.txt for details and
      samples/livepatch/ for examples.
      Signed-off-by: default avatarJoe Lawrence <joe.lawrence@redhat.com>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      93862e38
  17. 11 Oct, 2017 1 commit
  18. 16 Apr, 2017 1 commit
  19. 30 Mar, 2017 1 commit
    • Zhou Chengming's avatar
      livepatch: Reduce the time of finding module symbols · 72f04b50
      Zhou Chengming authored
      
      
      It's reported that the time of insmoding a klp.ko for one of our
      out-tree modules is too long.
      
      ~ time sudo insmod klp.ko
      real	0m23.799s
      user	0m0.036s
      sys	0m21.256s
      
      Then we found the reason: our out-tree module used a lot of static local
      variables, so klp.ko has a lot of relocation records which reference the
      module. Then for each such entry klp_find_object_symbol() is called to
      resolve it, but this function uses the interface kallsyms_on_each_symbol()
      even for finding module symbols, so will waste a lot of time on walking
      through vmlinux kallsyms table many times.
      
      This patch changes it to use module_kallsyms_on_each_symbol() for modules
      symbols. After we apply this patch, the sys time reduced dramatically.
      
      ~ time sudo insmod klp.ko
      real	0m1.007s
      user	0m0.032s
      sys	0m0.924s
      Signed-off-by: default avatarZhou Chengming <zhouchengming1@huawei.com>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarJessica Yu <jeyu@redhat.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      72f04b50
  20. 08 Mar, 2017 8 commits
    • Jiri Kosina's avatar
      livepatch: make klp_mutex proper part of API · 10517429
      Jiri Kosina authored
      
      
      klp_mutex is shared between core.c and transition.c, and as such would
      rather be properly located in a header so that we don't have to play
      'extern' games from .c sources.
      
      This also silences sparse warning (wrongly) suggesting that klp_mutex
      should be defined static.
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      10517429
    • Josh Poimboeuf's avatar
      livepatch: allow removal of a disabled patch · 3ec24776
      Josh Poimboeuf authored
      Currently we do not allow patch module to unload since there is no
      method to determine if a task is still running in the patched code.
      
      The consistency model gives us the way because when the unpatching
      finishes we know that all tasks were marked as safe to call an original
      function. Thus every new call to the function calls the original code
      and at the same time no task can be somewhere in the patched code,
      because it had to leave that code to be marked as safe.
      
      We can safely let the patch module go after that.
      
      Completion is used for synchronization between module removal and sysfs
      infrastructure in a similar way to commit 942e4431 ("module: Fix
      mod->mkobj.kobj potentially freed too early").
      
      Note that we still do not allow the removal for immediate model, that is
      no consistency model. The module refcount may increase in this case if
      somebody disables and enables the patch several times. This should not
      cause any harm.
      
      With this change a call to try_module_get() is moved to
      __klp_enable_patch from klp_register_patch to make module reference
      counting symmetric (module_put() is in a patch disable path) and to
      allow to take a new reference to a disabled module when being enabled.
      
      Finally, we need to be very careful about possible races between
      klp_unregister_patch(), kobject_put() functions and operations
      on the related sysfs files.
      
      kobject_put(&patch->kobj) must be called without klp_mutex. Otherwise,
      it might be blocked by enabled_store() that needs the mutex as well.
      In addition, enabled_store() must check if the patch was not
      unregisted in the meantime.
      
      There is no need to do the same for other kobject_put() callsites
      at the moment. Their sysfs operations neither take the lock nor
      they access any data that might be freed in the meantime.
      
      There was an attempt to use kobjects the right way and prevent these
      races by design. But it made the patch definition more complicated
      and opened another can of worms. See
      https://lkml.kernel.org/r/1464018848-4303-1-git-send-email-pmladek@suse.com
      
      
      
      [Thanks to Petr Mladek for improving the commit message.]
      Signed-off-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Reviewed-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      3ec24776
    • Josh Poimboeuf's avatar
      livepatch: change to a per-task consistency model · d83a7cb3
      Josh Poimboeuf authored
      Change livepatch to use a basic per-task consistency model.  This is the
      foundation which will eventually enable us to patch those ~10% of
      security patches which change function or data semantics.  This is the
      biggest remaining piece needed to make livepatch more generally useful.
      
      This code stems from the design proposal made by Vojtech [1] in November
      2014.  It's a hybrid of kGraft and kpatch: it uses kGraft's per-task
      consistency and syscall barrier switching combined with kpatch's stack
      trace switching.  There are also a number of fallback options which make
      it quite flexible.
      
      Patches are applied on a per-task basis, when the task is deemed safe to
      switch over.  When a patch is enabled, livepatch enters into a
      transition state where tasks are converging to the patched state.
      Usually this transition state can complete in a few seconds.  The same
      sequence occurs when a patch is disabled, except the tasks converge from
      the patched state to the unpatched state.
      
      An interrupt handler inherits the patched state of the task it
      interrupts.  The same is true for forked tasks: the child inherits the
      patched state of the parent.
      
      Livepatch uses several complementary approaches to determine when it's
      safe to patch tasks:
      
      1. The first and most effective approach is stack checking of sleeping
         tasks.  If no affected functions are on the stack of a given task,
         the task is patched.  In most cases this will patch most or all of
         the tasks on the first try.  Otherwise it'll keep trying
         periodically.  This option is only available if the architecture has
         reliable stacks (HAVE_RELIABLE_STACKTRACE).
      
      2. The second approach, if needed, is kernel exit switching.  A
         task is switched when it returns to user space from a system call, a
         user space IRQ, or a signal.  It's useful in the following cases:
      
         a) Patching I/O-bound user tasks which are sleeping on an affected
            function.  In this case you have to send SIGSTOP and SIGCONT to
            force it to exit the kernel and be patched.
         b) Patching CPU-bound user tasks.  If the task is highly CPU-bound
            then it will get patched the next time it gets interrupted by an
            IRQ.
         c) In the future it could be useful for applying patches for
            architectures which don't yet have HAVE_RELIABLE_STACKTRACE.  In
            this case you would have to signal most of the tasks on the
            system.  However this isn't supported yet because there's
            currently no way to patch kthreads without
            HAVE_RELIABLE_STACKTRACE.
      
      3. For idle "swapper" tasks, since they don't ever exit the kernel, they
         instead have a klp_update_patch_state() call in the idle loop which
         allows them to be patched before the CPU enters the idle state.
      
         (Note there's not yet such an approach for kthreads.)
      
      All the above approaches may be skipped by setting the 'immediate' flag
      in the 'klp_patch' struct, which will disable per-task consistency and
      patch all tasks immediately.  This can be useful if the patch doesn't
      change any function or data semantics.  Note that, even with this flag
      set, it's possible that some tasks may still be running with an old
      version of the function, until that function returns.
      
      There's also an 'immediate' flag in the 'klp_func' struct which allows
      you to specify that certain functions in the patch can be applied
      without per-task consistency.  This might be useful if you want to patch
      a common function like schedule(), and the function change doesn't need
      consistency but the rest of the patch does.
      
      For architectures which don't have HAVE_RELIABLE_STACKTRACE, the user
      must set patch->immediate which causes all tasks to be patched
      immediately.  This option should be used with care, only when the patch
      doesn't change any function or data semantics.
      
      In the future, architectures which don't have HAVE_RELIABLE_STACKTRACE
      may be allowed to use per-task consistency if we can come up with
      another way to patch kthreads.
      
      The /sys/kernel/livepatch/<patch>/transition file shows whether a patch
      is in transition.  Only a single patch (the topmost patch on the stack)
      can be in transition at a given time.  A patch can remain in transition
      indefinitely, if any of the tasks are stuck in the initial patch state.
      
      A transition can be reversed and effectively canceled by writing the
      opposite value to the /sys/kernel/livepatch/<patch>/enabled file while
      the transition is in progress.  Then all the tasks will attempt to
      converge back to the original patch state.
      
      [1] https://lkml.kernel.org/r/20141107140458.GA21774@suse.cz
      
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Acked-by: Ingo Molnar <mingo@kernel.org>        # for the scheduler changes
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      d83a7cb3
    • Josh Poimboeuf's avatar
      livepatch: store function sizes · f5e547f4
      Josh Poimboeuf authored
      
      
      For the consistency model we'll need to know the sizes of the old and
      new functions to determine if they're on the stacks of any tasks.
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Reviewed-by: default avatarPetr Mladek <pmladek@suse.com>
      Reviewed-by: default avatarKamalesh Babulal <kamalesh@linux.vnet.ibm.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      f5e547f4
    • Josh Poimboeuf's avatar
      livepatch: use kstrtobool() in enabled_store() · 68ae4b2b
      Josh Poimboeuf authored
      
      
      The sysfs enabled value is a boolean, so kstrtobool() is a better fit
      for parsing the input string since it does the range checking for us.
      Suggested-by: default avatarPetr Mladek <pmladek@suse.com>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Reviewed-by: default avatarPetr Mladek <pmladek@suse.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      68ae4b2b
    • Josh Poimboeuf's avatar
      livepatch: move patching functions into patch.c · c349cdca
      Josh Poimboeuf authored
      
      
      Move functions related to the actual patching of functions and objects
      into a new patch.c file.
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Reviewed-by: default avatarPetr Mladek <pmladek@suse.com>
      Reviewed-by: default avatarKamalesh Babulal <kamalesh@linux.vnet.ibm.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      c349cdca
    • Josh Poimboeuf's avatar
      livepatch: remove unnecessary object loaded check · aa82dc3e
      Josh Poimboeuf authored
      
      
      klp_patch_object()'s callers already ensure that the object is loaded,
      so its call to klp_is_object_loaded() is unnecessary.
      
      This will also make it possible to move the patching code into a
      separate file.
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Reviewed-by: default avatarPetr Mladek <pmladek@suse.com>
      Reviewed-by: default avatarKamalesh Babulal <kamalesh@linux.vnet.ibm.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      aa82dc3e
    • Josh Poimboeuf's avatar
      livepatch: separate enabled and patched states · 0dade9f3
      Josh Poimboeuf authored
      
      
      Once we have a consistency model, patches and their objects will be
      enabled and disabled at different times.  For example, when a patch is
      disabled, its loaded objects' funcs can remain registered with ftrace
      indefinitely until the unpatching operation is complete and they're no
      longer in use.
      
      It's less confusing if we give them different names: patches can be
      enabled or disabled; objects (and their funcs) can be patched or
      unpatched:
      
      - Enabled means that a patch is logically enabled (but not necessarily
        fully applied).
      
      - Patched means that an object's funcs are registered with ftrace and
        added to the klp_ops func stack.
      
      Also, since these states are binary, represent them with booleans
      instead of ints.
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Reviewed-by: default avatarPetr Mladek <pmladek@suse.com>
      Reviewed-by: default avatarKamalesh Babulal <kamalesh@linux.vnet.ibm.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      0dade9f3