1. 19 3月, 2015 3 次提交
  2. 18 3月, 2015 8 次提交
  3. 17 3月, 2015 3 次提交
    • P
      livepatch: Fix subtle race with coming and going modules · 8cb2c2dc
      Petr Mladek 提交于
      There is a notifier that handles live patches for coming and going modules.
      It takes klp_mutex lock to avoid races with coming and going patches but
      it does not keep the lock all the time. Therefore the following races are
      possible:
      
        1. The notifier is called sometime in STATE_MODULE_COMING. The module
           is visible by find_module() in this state all the time. It means that
           new patch can be registered and enabled even before the notifier is
           called. It might create wrong order of stacked patches, see below
           for an example.
      
         2. New patch could still see the module in the GOING state even after
            the notifier has been called. It will try to initialize the related
            object structures but the module could disappear at any time. There
            will stay mess in the structures. It might even cause an invalid
            memory access.
      
      This patch solves the problem by adding a boolean variable into struct module.
      The value is true after the coming and before the going handler is called.
      New patches need to be applied when the value is true and they need to ignore
      the module when the value is false.
      
      Note that we need to know state of all modules on the system. The races are
      related to new patches. Therefore we do not know what modules will get
      patched.
      
      Also note that we could not simply ignore going modules. The code from the
      module could be called even in the GOING state until mod->exit() finishes.
      If we start supporting patches with semantic changes between function
      calls, we need to apply new patches to any still usable code.
      See below for an example.
      
      Finally note that the patch solves only the situation when a new patch is
      registered. There are no such problems when the patch is being removed.
      It does not matter who disable the patch first, whether the normal
      disable_patch() or the module notifier. There is nothing to do
      once the patch is disabled.
      
      Alternative solutions:
      ======================
      
      + reject new patches when a patched module is coming or going; this is ugly
      
      + wait with adding new patch until the module leaves the COMING and GOING
        states; this might be dangerous and complicated; we would need to release
        kgr_lock in the middle of the patch registration to avoid a deadlock
        with the coming and going handlers; also we might need a waitqueue for
        each module which seems to be even bigger overhead than the boolean
      
      + stop modules from entering COMING and GOING states; wait until modules
        leave these states when they are already there; looks complicated; we would
        need to ignore the module that asked to stop the others to avoid a deadlock;
        also it is unclear what to do when two modules asked to stop others and
        both are in COMING state (situation when two new patches are applied)
      
      + always register/enable new patches and fix up the potential mess (registered
        patches order) in klp_module_init(); this is nasty and prone to regressions
        in the future development
      
      + add another MODULE_STATE where the kallsyms are visible but the module is not
        used yet; this looks too complex; the module states are checked on "many"
        locations
      
      Example of patch stacking breakage:
      ===================================
      
      The notifier could _not_ _simply_ ignore already initialized module objects.
      For example, let's have three patches (P1, P2, P3) for functions a() and b()
      where a() is from vmcore and b() is from a module M. Something like:
      
      	a()	b()
      P1	a1()	b1()
      P2	a2()	b2()
      P3	a3()	b3(3)
      
      If you load the module M after all patches are registered and enabled.
      The ftrace ops for function a() and b() has listed the functions in this
      order:
      
      	ops_a->func_stack -> list(a3,a2,a1)
      	ops_b->func_stack -> list(b3,b2,b1)
      
      , so the pointer to b3() is the first and will be used.
      
      Then you might have the following scenario. Let's start with state when patches
      P1 and P2 are registered and enabled but the module M is not loaded. Then ftrace
      ops for b() does not exist. Then we get into the following race:
      
      CPU0					CPU1
      
      load_module(M)
      
        complete_formation()
      
        mod->state = MODULE_STATE_COMING;
        mutex_unlock(&module_mutex);
      
      					klp_register_patch(P3);
      					klp_enable_patch(P3);
      
      					# STATE 1
      
        klp_module_notify(M)
          klp_module_notify_coming(P1);
          klp_module_notify_coming(P2);
          klp_module_notify_coming(P3);
      
      					# STATE 2
      
      The ftrace ops for a() and b() then looks:
      
        STATE1:
      
      	ops_a->func_stack -> list(a3,a2,a1);
      	ops_b->func_stack -> list(b3);
      
        STATE2:
      	ops_a->func_stack -> list(a3,a2,a1);
      	ops_b->func_stack -> list(b2,b1,b3);
      
      therefore, b2() is used for the module but a3() is used for vmcore
      because they were the last added.
      
      Example of the race with going modules:
      =======================================
      
      CPU0					CPU1
      
      delete_module()  #SYSCALL
      
         try_stop_module()
           mod->state = MODULE_STATE_GOING;
      
         mutex_unlock(&module_mutex);
      
      					klp_register_patch()
      					klp_enable_patch()
      
      					#save place to switch universe
      
      					b()     # from module that is going
      					  a()   # from core (patched)
      
         mod->exit();
      
      Note that the function b() can be called until we call mod->exit().
      
      If we do not apply patch against b() because it is in MODULE_STATE_GOING,
      it will call patched a() with modified semantic and things might get wrong.
      
      [jpoimboe@redhat.com: use one boolean instead of two]
      Signed-off-by: NPetr Mladek <pmladek@suse.cz>
      Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      8cb2c2dc
    • M
      virtio_mmio: fix access width for mmio · 704a0b5f
      Michael S. Tsirkin 提交于
      Going over the virtio mmio code, I noticed that it doesn't correctly
      access modern device config values using "natural" accessors: it uses
      readb to get/set them byte by byte, while the virtio 1.0 spec explicitly states:
      
      	4.2.2.2 Driver Requirements: MMIO Device Register Layout
      
      	...
      
      	The driver MUST only use 32 bit wide and aligned reads and writes to
      	access the control registers described in table 4.1.
      	For the device-specific configuration space, the driver MUST use
      	8 bit wide accesses for 8 bit wide fields, 16 bit wide and aligned
      	accesses for 16 bit wide fields and 32 bit wide and aligned accesses for
      	32 and 64 bit wide fields.
      
      Borrow code from virtio_pci_modern to do this correctly.
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      704a0b5f
    • M
      Merge tag 'kvm-arm-fixes-4.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm · f710a12d
      Marcelo Tosatti 提交于
      Fixes for KVM/ARM for 4.0-rc5.
      
      Fixes page refcounting issues in our Stage-2 page table management code,
      fixes a missing unlock in a gicv3 error path, and fixes a race that can
      cause lost interrupts if signals are pending just prior to entering the
      guest.
      f710a12d
  4. 16 3月, 2015 9 次提交
    • M
      Merge remote-tracking branches 'regulator/fix/gpio-enable' and... · 8ca8f326
      Mark Brown 提交于
      Merge remote-tracking branches 'regulator/fix/gpio-enable' and 'regulator/fix/tps65910' into regulator-linus
      8ca8f326
    • G
      regulator: tps65910: Add missing #include <linux/of.h> · d16da513
      Geert Uytterhoeven 提交于
      drivers/regulator/tps65910-regulator.c: In function ‘tps65910_parse_dt_reg_data’:
      drivers/regulator/tps65910-regulator.c:1018: error: implicit declaration of function ‘of_get_child_by_name’
      drivers/regulator/tps65910-regulator.c:1018: warning: assignment makes pointer from integer without a cast
      drivers/regulator/tps65910-regulator.c:1034: error: implicit declaration of function ‘of_node_put’
      drivers/regulator/tps65910-regulator.c:1056: error: implicit declaration of function ‘of_property_read_u32’
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      d16da513
    • B
      Revert "x86/mm/ASLR: Propagate base load address calculation" · 69797daf
      Borislav Petkov 提交于
      This reverts commit:
      
        f47233c2 ("x86/mm/ASLR: Propagate base load address calculation")
      
      The main reason for the revert is that the new boot flag does not work
      at all currently, and in order to make this work, we need non-trivial
      changes to the x86 boot code which we didn't manage to get done in
      time for merging.
      
      And even if we did, they would've been too risky so instead of
      rushing things and break booting 4.1 on boxes left and right, we
      will be very strict and conservative and will take our time with
      this to fix and test it properly.
      Reported-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: H. Peter Anvin <hpa@linux.intel.com
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Junjie Mao <eternal.n08@gmail.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt.fleming@intel.com>
      Link: http://lkml.kernel.org/r/20150316100628.GD22995@pd.tnicSigned-off-by: NIngo Molnar <mingo@kernel.org>
      69797daf
    • L
      Linux 4.0-rc4 · 06e5801b
      Linus Torvalds 提交于
      06e5801b
    • L
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · 08352086
      Linus Torvalds 提交于
      Pull drm fix from Dave Airlie:
       "An oops snuck in in an -rc3 patch, this fixes it"
      
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        [PATCH] drm/mm: Fix support 4 GiB and larger ranges
      08352086
    • L
      Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux · 1ee89c51
      Linus Torvalds 提交于
      Pull clock framework fixes from Michael Turquette:
       "The clk fixes for 4.0-rc4 comprise three themes.
      
        First are the usual driver fixes for new regressions since v3.19.
      
        Second are fixes to the common clock divider type caused by recent
        changes to how we round clock rates.  This affects many clock drivers
        that use this common code.
      
        Finally there are fixes for drivers that improperly compared struct
        clk pointers (drivers must not deref these pointers).  While some of
        these drivers have done this for a long time, this did not cause a
        problem until we started generating unique struct clk pointers for
        every consumer.  A new function, clk_is_match was introduced to get
        these drivers working again and they are fixed up to no longer deref
        the pointers themselves"
      
      * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
        ASoC: kirkwood: fix struct clk pointer comparing
        ASoC: fsl_spdif: fix struct clk pointer comparing
        ARM: imx: fix struct clk pointer comparing
        clk: introduce clk_is_match
        clk: don't export static symbol
        clk: divider: fix calculation of initial best divider when rounding to closest
        clk: divider: fix selection of divider when rounding to closest
        clk: divider: fix calculation of maximal parent rate for a given divider
        clk: divider: return real rate instead of divider value
        clk: qcom: fix platform_no_drv_owner.cocci warnings
        clk: qcom: fix platform_no_drv_owner.cocci warnings
        clk: qcom: Add PLL4 vote clock
        clk: qcom: lcc-msm8960: Fix PLL rate detection
        clk: qcom: Fix slimbus n and m val offsets
        clk: ti: Fix FAPLL parent enable bit handling
      1ee89c51
    • K
      [PATCH] drm/mm: Fix support 4 GiB and larger ranges · 046d669c
      Krzysztof Kolasa 提交于
      bad argument if(tmp)... in check_free_hole
      
      fix oops: kernel BUG at drivers/gpu/drm/drm_mm.c:305!
      
      [airlied: excellent, this was my task for today].
      Signed-off-by: NKrzysztof Kolasa <kkolasa@winsoft.pl>
      Reviewed-by: NChris wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      046d669c
    • L
      Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 6981e2af
      Linus Torvalds 提交于
      Pull ARM SoC fixes from Arnd Bergmann:
       "This is a rather unpleasantly large set of bug fixes for arm-soc, Most
        of them because of cross-tree dependencies for Exynos where we should
        have figured out the right path to merge things before the merge
        window, and then the maintainer being unable to sort things out in
        time during a business trip.
      
        The other changes contained here are the usual collection:
      
        MAINTAINERS file updates
         - Gregory Clement is now a co-maintainer for the legacy Marvell EBU
           platforms
         - A MAINTAINERS entry for the Freescale Vybrid platform that was
           added last year
         - Matt Porter no longer works as a maintainer on Broadcom SoCs
      
        Build-time issues
         - A compile-time error for at91
         - Several minor DT fixes on at91, imx, exynos, socfpga, and omap
         - The new digicolor platform was not correctly enabled at all
      
        Configuration issues
         - Two defconfig fix for regressions using USB on versatile express
           and on OMAP3
         - Enabling all 8 CPUs on Allwinner/SUNxi
         - Enabling the new STiH410 platform to be usable
      
        Bug fixes in platform code
         - A missing barrier for socfpga
         - Fixing LPDDR1 self-refresh mode on at91
         - Fixing RTC interrupt numbers on Exynos3250
         - Fixing a cache-coherency issues in CPU power-down on Exynos5
         - Multiple small OMAP power management fixes"
      
      * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (69 commits)
        MAINTAINERS: Add myself as co-maintainer to the legacy support of the mvebu SoCs
        ARM: at91: pm_slowclock: fix the compilation error
        ARM: at91/dt: fix USB high-speed clock to select UTMI
        ARM: at91/dt: fix at91 udc compatible strings
        ARM: at91/dt: declare matrix node as a syscon device
        ARM: vexpress: update CONFIG_USB_ISP1760 option
        ARM: digicolor: add the machine directory to Makefile
        ARM: STi: Add STiH410 SoC support
        MAINTAINERS: add Freescale Vybrid SoC
        MAINTAINERS: Remove self as ARM mach-bcm co-maintainer
        ARM: imx6sl-evk: set swbst_reg as vbus's parent reg
        ARM: imx6qdl-sabresd: set swbst_reg as vbus's parent reg
        ARM: at91/dt: at91sam9261: fix clocks and clock-names in udc definition
        ARM: OMAP2+: Fix wl12xx on dm3730-evm with mainline u-boot
        ARM: OMAP: enable TWL4030_USB in omap2plus_defconfig
        ARM: dts: dra7x-evm: avoid possible contention while muxing on CAN lines
        ARM: dts: dra7x-evm: Don't use dcan1_rx.gpio1_15 in DCAN pinctrl
        ARM: dts: am43xx: fix SLEWCTRL_FAST pinctrl binding
        ARM: dts: am33xx: fix SLEWCTRL_FAST pinctrl binding
        ARM: dts: OMAP5: fix polling intervals for thermal zones
        ...
      6981e2af
    • L
      Merge tag 'irqchip-fixes-4.0' of git://git.infradead.org/users/jcooper/linux · 71c87bd0
      Linus Torvalds 提交于
      Pull irqchip fixes from Jason Cooper:
       "armada-370-xp:
         - Chained per-cpu interrupts
      
        gic{,-v3,v3-its}"
         - Various fixes for safer operation"
      
      * tag 'irqchip-fixes-4.0' of git://git.infradead.org/users/jcooper/linux:
        irqchip: gicv3-its: Support safe initialization
        irqchip: gicv3-its: Define macros for GITS_CTLR fields
        irqchip: gicv3-its: Add limitation to page order
        irqchip: gicv3-its: Use 64KB page as default granule
        irqchip: gicv3-its: Zero itt before handling to hardware
        irqchip: gic-v3: Fix out of bounds access to cpu_logical_map
        irqchip: gic: Fix unsafe locking reported by lockdep
        irqchip: gicv3-its: Fix unsafe locking reported by lockdep
        irqchip: gicv3-its: Iterate over PCI aliases to generate ITS configuration
        irqchip: gicv3-its: Allocate enough memory for the full range of DeviceID
        irqchip: gicv3-its: Fix ITS CPU init
        irqchip: armada-370-xp: Fix chained per-cpu interrupts
      71c87bd0
  5. 15 3月, 2015 8 次提交
  6. 14 3月, 2015 9 次提交