1. 17 2月, 2015 5 次提交
    • J
      rtc: add driver for DS1685 family of real time clocks · aaaf5fbf
      Joshua Kinard 提交于
      This adds a driver for the Dallas/Maxim DS1685-family of RTC chips.  It
      supports the DS1685/DS1687, DS1688/DS1691, DS1689/DS1693, DS17285/DS17287,
      DS17485/DS17487, and DS17885/DS17887 RTC chips.  These chips are commonly
      found in SGI O2 and SGI Octane systems.  It was originally derived from a
      driver patch submitted by Matthias Fuchs many years ago for use in
      EPPC-405-UC modules, which also used these RTCs.  In addition to the
      time-keeping functions, this RTC also handles the shutdown mechanism of
      the O2 and Octane and acts as a partial NVRAM for the boot PROMS in these
      systems.
      
      Verified on both an SGI O2 and an SGI Octane.
      Signed-off-by: NJoshua Kinard <kumba@gentoo.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      aaaf5fbf
    • M
      brd: rename XIP to DAX · a7a97fc9
      Matthew Wilcox 提交于
      Since this is relating to FS_XIP, not KERNEL_XIP, it should be called
      DAX instead of XIP.
      Signed-off-by: NMatthew Wilcox <matthew.r.wilcox@intel.com>
      Cc: Andreas Dilger <andreas.dilger@intel.com>
      Cc: Boaz Harrosh <boaz@plexistor.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a7a97fc9
    • A
      staging: iio: isl29028: deprecate use of isl in compatible string for isil · 37e5157d
      Arnaud Ebalard 提交于
      "isil" and "isl" prefixes are used at various locations inside the kernel
      to reference Intersil corporation.  This patch is part of a series fixing
      those locations were "isl" is used in compatible strings to use the now
      expected "isil" prefix instead (NASDAQ symbol for Intersil and most used
      version).  The old compatible string is kept for backward compatibility.
      Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
      Cc: Kumar Gala <galak@codeaurora.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: Uwe Kleine-Knig <uwe@kleine-koenig.org>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Peter Huewe <peter.huewe@infineon.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Darshana Padmadas <darshanapadmadas@gmail.com>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Rob Landley <rob@landley.net>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Cc: Uwe Kleine-König <uwe@kleine-koenig.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      37e5157d
    • A
      rtc: isl12057: deprecate use of isl in compatible string for isil · 401b3c6a
      Arnaud Ebalard 提交于
      "isil" and "isl" prefixes are used at various locations inside the kernel
      to reference Intersil corporation.  This patch is part of a series fixing
      those locations were "isl" is used in compatible strings to use the now
      expected "isil" prefix instead (NASDAQ symbol for Intersil and most used
      version).  The old compatible string is kept for backward compatibility.
      Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
      Cc: Kumar Gala <galak@codeaurora.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: Uwe Kleine-Knig <uwe@kleine-koenig.org>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Peter Huewe <peter.huewe@infineon.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Darshana Padmadas <darshanapadmadas@gmail.com>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Rob Landley <rob@landley.net>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Cc: Uwe Kleine-König <uwe@kleine-koenig.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      401b3c6a
    • A
      rtc: isl12022: deprecate use of isl in compatible string for isil · c5cd8273
      Arnaud Ebalard 提交于
      "isil" and "isl" prefixes are used at various locations inside the kernel
      to reference Intersil corporation.  This patch is part of a series fixing
      those locations were "isl" is used in compatible strings to use the now
      expected "isil" prefix instead (NASDAQ symbol for Intersil and most used
      version).  The old compatible string is kept for backward compatibility.
      Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
      Cc: Kumar Gala <galak@codeaurora.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: Uwe Kleine-Knig <uwe@kleine-koenig.org>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Peter Huewe <peter.huewe@infineon.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Darshana Padmadas <darshanapadmadas@gmail.com>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Rob Landley <rob@landley.net>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Cc: Uwe Kleine-König <uwe@kleine-koenig.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c5cd8273
  2. 14 2月, 2015 22 次提交
    • G
      drivers/rtc/rtc-armada38x: add a new RTC driver for recent mvebu SoCs · a3a42806
      Gregory CLEMENT 提交于
      The new mvebu SoCs come with a new RTC driver. This patch adds the
      support for this new IP which is currently found in the Armada 38x
      SoCs.
      
      This RTC provides two alarms, but only the first one is used in the
      driver. The RTC also allows using periodic interrupts.
      Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
      Reviewed-by: NArnaud Ebalard <arno@natisbad.org>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
      Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
      Cc: Boris BREZILLON <boris.brezillon@free-electrons.com>
      Cc: Lior Amsalem <alior@marvell.com>
      Cc: Tawfik Bayouk <tawfik@marvell.com>
      Cc: Nadav Haklai <nadavh@marvell.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a3a42806
    • A
      rtc: rtc-ab-b5ze-s3: add sub-minute alarm support · c8a1d8a5
      Arnaud Ebalard 提交于
      Abracon AB-RTCMC-32.768kHz-B5ZE-S3 alarm is only accurate to the minute.
      For that reason, UIE mode is currently not supported by the driver.  But
      the device provides a watchdog timer which can be coupled with the alarm
      mechanism to extend support and provide sub-minute alarm capability.
      
      This patch implements that extension.  More precisely, it makes use of the
      watchdog timer for alarms which are less that four minutes in the future
      (with second accuracy) and use standard alarm mechanism for other alarms
      (with minute accuracy).
      Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Peter Huewe <peter.huewe@infineon.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Thierry Reding <treding@nvidia.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Rob Herring <robherring2@gmail.com>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Rob Landley <rob@landley.net>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Cc: Kumar Gala <galak@codeaurora.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c8a1d8a5
    • A
      rtc: add support for Abracon AB-RTCMC-32.768kHz-B5ZE-S3 I2C RTC chip · 0b2f6228
      Arnaud Ebalard 提交于
      This patch adds support for Abracon AB-RTCMC-32.768kHz-B5ZE-S3
      RTC/Calendar module w/ I2C interface.
      
      This support includes RTC time reading and setting, Alarm (1 minute
      accuracy) reading and setting, and battery low detection.  The device also
      supports frequency adjustment and two timers but those features are
      currently not implemented in this driver.  Due to alarm accuracy
      limitation (and current lack of timer support in the driver), UIE mode is
      not supported.
      Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Peter Huewe <peter.huewe@infineon.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Thierry Reding <treding@nvidia.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Rob Herring <robherring2@gmail.com>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Rob Landley <rob@landley.net>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Cc: Kumar Gala <galak@codeaurora.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0b2f6228
    • C
      drivers/rtc/rtc-rk808.c: fix rtc time reading issue · c412c603
      Chris Zhong 提交于
      After we set the GET_TIME bit, the rtc time can't be read immediately.  We
      should wait up to 31.25 us, about one cycle of 32khz.  Otherwise reading
      RTC time will return a old time.  If we clear the GET_TIME bit after
      setting, the time of i2c transfer is certainly more than 31.25us.
      
      Doug said:
      
      : I think we are safe.  At 400kHz (the max speed of this part) each bit can
      : be transferred no faster than 2.5us.  In order to do a valid i2c
      : transaction we need to _at least_ write the address of the device and the
      : data onto the bus, which is 16 bits.  16 * 2.5us = 40us.  That's above the
      : 31.25us
      
      [akpm@linux-foundation.org: tweak comment per review discussion]
      Signed-off-by: NChris Zhong <zyw@rock-chips.com>
      Reviewed-by: NDoug Anderson <dianders@chromium.org>
      Cc: Sonny Rao <sonnyrao@chromium.org>
      Cc: Heiko Stübner <heiko@sntech.de>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c412c603
    • K
      drivers/rtc/rtc-isl12057.c: constify struct regmap_config · 1ef2816f
      Krzysztof Kozlowski 提交于
      The regmap_config struct may be const because it is not modified by the
      driver and regmap_init() accepts pointer to const.
      Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1ef2816f
    • K
      drivers/rtc/rtc-at91sam9.c: constify struct regmap_config · bddd8ddd
      Krzysztof Kozlowski 提交于
      The regmap_config struct may be const because it is not modified by the
      driver and regmap_init() accepts pointer to const.
      Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bddd8ddd
    • J
      drivers/rtc/rtc-imxdi.c: add more known register bits · 46edeffa
      Juergen Borleis 提交于
      Intended for monitoring and controlling the security features.  These bits
      are required to bring this unit back to live after a security violation
      event was detected.  The code to bring it back to live will follow after a
      vendor clearance.
      Signed-off-by: NJuergen Borleis <jbe@pengutronix.de>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      46edeffa
    • J
      drivers/rtc/rtc-imxdi.c: trivial clean up code · 6df17a65
      Juergen Borleis 提交于
      Signed-off-by: NJuergen Borleis <jbe@pengutronix.de>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6df17a65
    • A
      rtc: rtc-isl12057: add isil,irq2-can-wakeup-machine property for in-tree users · 298ff012
      Arnaud Ebalard 提交于
      Current in-tree users of ISL12057 RTC chip (NETGEAR ReadyNAS 102, 104 and
      2120) do not have the IRQ#2 pin of the chip (associated w/ the Alarm1
      mechanism) connected to their SoC, but to a PMIC (TPS65251 FWIW).  This
      specific hardware configuration allows the NAS to wake up when the alarms
      rings.
      
      Recently introduced alarm support for ISL12057 relies on the provision of
      an "interrupts" property in system .dts file, which previous three users
      will never get.  For that reason, alarm support on those devices is not
      function.  To support this use case, this patch adds a new DT property for
      ISL12057 (isil,irq2-can-wakeup-machine) to indicate that the chip is
      capable of waking up the device using its IRQ#2 pin (even though it does
      not have its IRQ#2 pin connected directly to the SoC).
      
      This specific configuration was tested on a ReadyNAS 102 by setting an
      alarm, powering off the device and see it reboot as expected when the
      alarm rang w/:
      
        # echo `date '+%s' -d '+ 1 minutes'` > /sys/class/rtc/rtc0/wakealarm
        # shutdown -h now
      
      As a side note, the ISL12057 remains in the list of trivial devices,
      because the property is not per se required by the device to work but can
      help handle system w/ specific requirements.  In exchange, the new feature
      is described in details in a specific documentation file.
      Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Peter Huewe <peter.huewe@infineon.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Thierry Reding <treding@nvidia.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Darshana Padmadas <darshanapadmadas@gmail.com>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Rob Landley <rob@landley.net>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Cc: Kumar Gala <galak@codeaurora.org>
      Cc: Uwe Kleine-König <uwe@kleine-koenig.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      298ff012
    • A
      drivers/rtc/rtc-isl12057.c: add alarm support to Intersil ISL12057 RTC driver · fd71493d
      Arnaud Ebalard 提交于
      This patch adds alarm support to Intersil ISL12057 driver.  This allows to
      configure the chip to generate an interrupt when the alarm matches current
      time value.  Alarm can be programmed up to one month in the future and is
      accurate to the second.
      
      The patch was developed to support two different configurations: systems
      w/ and w/o RTC chip IRQ line connected to the main CPU.
      
      The latter is the one found on current 3 kernel users of the chip for
      which support was initially developed (Netgear ReadyNAS 102, 104 and 2120
      NAS).  On those devices, the IRQ#2 pin of the chip is not connected to the
      SoC but to a PMIC.  This allows setting an alarm, powering off the device
      and have it wake up when the alarm rings.  To support that configuration
      the driver does the following:
      
       1. it has alarm_irq_enable() function returns -ENOTTY when no IRQ
          is passed to the driver.
       2. it marks the device as a wakeup source in all cases (whether an
          IRQ is passed to the driver or not) to have 'wakealarm' sysfs
          entry created.
       3. it marks the device has not supporting UIE mode when no IRQ is
          passed to the driver (see the commmit message of c9f5c7e7)
      
      This specific configuration was tested on a ReadyNAS 102 by setting an
      alarm, powering off the device and see it reboot as expected when the
      alarm rang.
      
      The former configuration was tested on a Netgear ReadyNAS 102 after some
      soldering of the IRQ#2 pin of the RTC chip to a MPP line of the SoC (the
      one used usually handles the reset button).  The test was performed using
      a modified .dts file reflecting this change (see below) and rtc-test.c
      program available in Documentation/rtc.txt.  This test program ran as
      expected, which validates alarm supports, including interrupt support.
      
      As a side note, the ISL12057 remains in the list of trivial devices, i.e.
      no specific DT binding being added by this patch: i2c core automatically
      handles extraction of IRQ line info from .dts file.  For instance, if one
      wants to reference the interrupt line for the alarm in its .dts file,
      adding interrupt and interrupt-parent properties works as expected:
      
                isl12057: isl12057@68 {
                        compatible =3D "isil,isl12057";
                        interrupt-parent =3D <&gpio0>;
                        interrupts =3D <6 IRQ_TYPE_EDGE_FALLING>;
                        reg =3D <0x68>;
                };
      
      FWIW, if someone is looking for a way to test alarm support on a system on
      which the chip IRQ line has the ability to boot the system (e.g.  ReadyNAS
      102, 104, etc):
      
          # echo 0 > /sys/class/rtc/rtc0/wakealarm
          # echo `date '+%s' -d '+ 1 minutes'` > /sys/class/rtc/rtc0/wakealarm
          # shutdown -h now
      
      With the commands above, after a minute, the system comes back to life.
      Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Peter Huewe <peter.huewe@infineon.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Thierry Reding <treding@nvidia.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Uwe Kleine-König <uwe@kleine-koenig.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fd71493d
    • J
      drivers/rtc/rtc-pcf2123.c: add support for devicetree · 3fc70077
      Joshua Clayton 提交于
      Add compatible string "nxp,rtc-pcf2123"
      Document the binding
      Signed-off-by: NJoshua Clayton <stillcompiling@gmail.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Grant Likely <grant.likely@linaro.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3fc70077
    • A
      x86_64: kasan: add interceptors for memset/memmove/memcpy functions · 393f203f
      Andrey Ryabinin 提交于
      Recently instrumentation of builtin functions calls was removed from GCC
      5.0.  To check the memory accessed by such functions, userspace asan
      always uses interceptors for them.
      
      So now we should do this as well.  This patch declares
      memset/memmove/memcpy as weak symbols.  In mm/kasan/kasan.c we have our
      own implementation of those functions which checks memory before accessing
      it.
      
      Default memset/memmove/memcpy now now always have aliases with '__'
      prefix.  For files that built without kasan instrumentation (e.g.
      mm/slub.c) original mem* replaced (via #define) with prefixed variants,
      cause we don't want to check memory accesses there.
      Signed-off-by: NAndrey Ryabinin <a.ryabinin@samsung.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Konstantin Serebryany <kcc@google.com>
      Cc: Dmitry Chernenkov <dmitryc@google.com>
      Signed-off-by: NAndrey Konovalov <adech.fo@gmail.com>
      Cc: Yuri Gribov <tetra2005@gmail.com>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      393f203f
    • A
      kasan: add kernel address sanitizer infrastructure · 0b24becc
      Andrey Ryabinin 提交于
      Kernel Address sanitizer (KASan) is a dynamic memory error detector.  It
      provides fast and comprehensive solution for finding use-after-free and
      out-of-bounds bugs.
      
      KASAN uses compile-time instrumentation for checking every memory access,
      therefore GCC > v4.9.2 required.  v4.9.2 almost works, but has issues with
      putting symbol aliases into the wrong section, which breaks kasan
      instrumentation of globals.
      
      This patch only adds infrastructure for kernel address sanitizer.  It's
      not available for use yet.  The idea and some code was borrowed from [1].
      
      Basic idea:
      
      The main idea of KASAN is to use shadow memory to record whether each byte
      of memory is safe to access or not, and use compiler's instrumentation to
      check the shadow memory on each memory access.
      
      Address sanitizer uses 1/8 of the memory addressable in kernel for shadow
      memory and uses direct mapping with a scale and offset to translate a
      memory address to its corresponding shadow address.
      
      Here is function to translate address to corresponding shadow address:
      
           unsigned long kasan_mem_to_shadow(unsigned long addr)
           {
                      return (addr >> KASAN_SHADOW_SCALE_SHIFT) + KASAN_SHADOW_OFFSET;
           }
      
      where KASAN_SHADOW_SCALE_SHIFT = 3.
      
      So for every 8 bytes there is one corresponding byte of shadow memory.
      The following encoding used for each shadow byte: 0 means that all 8 bytes
      of the corresponding memory region are valid for access; k (1 <= k <= 7)
      means that the first k bytes are valid for access, and other (8 - k) bytes
      are not; Any negative value indicates that the entire 8-bytes are
      inaccessible.  Different negative values used to distinguish between
      different kinds of inaccessible memory (redzones, freed memory) (see
      mm/kasan/kasan.h).
      
      To be able to detect accesses to bad memory we need a special compiler.
      Such compiler inserts a specific function calls (__asan_load*(addr),
      __asan_store*(addr)) before each memory access of size 1, 2, 4, 8 or 16.
      
      These functions check whether memory region is valid to access or not by
      checking corresponding shadow memory.  If access is not valid an error
      printed.
      
      Historical background of the address sanitizer from Dmitry Vyukov:
      
      	"We've developed the set of tools, AddressSanitizer (Asan),
      	ThreadSanitizer and MemorySanitizer, for user space. We actively use
      	them for testing inside of Google (continuous testing, fuzzing,
      	running prod services). To date the tools have found more than 10'000
      	scary bugs in Chromium, Google internal codebase and various
      	open-source projects (Firefox, OpenSSL, gcc, clang, ffmpeg, MySQL and
      	lots of others): [2] [3] [4].
      	The tools are part of both gcc and clang compilers.
      
      	We have not yet done massive testing under the Kernel AddressSanitizer
      	(it's kind of chicken and egg problem, you need it to be upstream to
      	start applying it extensively). To date it has found about 50 bugs.
      	Bugs that we've found in upstream kernel are listed in [5].
      	We've also found ~20 bugs in out internal version of the kernel. Also
      	people from Samsung and Oracle have found some.
      
      	[...]
      
      	As others noted, the main feature of AddressSanitizer is its
      	performance due to inline compiler instrumentation and simple linear
      	shadow memory. User-space Asan has ~2x slowdown on computational
      	programs and ~2x memory consumption increase. Taking into account that
      	kernel usually consumes only small fraction of CPU and memory when
      	running real user-space programs, I would expect that kernel Asan will
      	have ~10-30% slowdown and similar memory consumption increase (when we
      	finish all tuning).
      
      	I agree that Asan can well replace kmemcheck. We have plans to start
      	working on Kernel MemorySanitizer that finds uses of unitialized
      	memory. Asan+Msan will provide feature-parity with kmemcheck. As
      	others noted, Asan will unlikely replace debug slab and pagealloc that
      	can be enabled at runtime. Asan uses compiler instrumentation, so even
      	if it is disabled, it still incurs visible overheads.
      
      	Asan technology is easily portable to other architectures. Compiler
      	instrumentation is fully portable. Runtime has some arch-dependent
      	parts like shadow mapping and atomic operation interception. They are
      	relatively easy to port."
      
      Comparison with other debugging features:
      ========================================
      
      KMEMCHECK:
      
        - KASan can do almost everything that kmemcheck can.  KASan uses
          compile-time instrumentation, which makes it significantly faster than
          kmemcheck.  The only advantage of kmemcheck over KASan is detection of
          uninitialized memory reads.
      
          Some brief performance testing showed that kasan could be
          x500-x600 times faster than kmemcheck:
      
      $ netperf -l 30
      		MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost (127.0.0.1) port 0 AF_INET
      		Recv   Send    Send
      		Socket Socket  Message  Elapsed
      		Size   Size    Size     Time     Throughput
      		bytes  bytes   bytes    secs.    10^6bits/sec
      
      no debug:	87380  16384  16384    30.00    41624.72
      
      kasan inline:	87380  16384  16384    30.00    12870.54
      
      kasan outline:	87380  16384  16384    30.00    10586.39
      
      kmemcheck: 	87380  16384  16384    30.03      20.23
      
        - Also kmemcheck couldn't work on several CPUs.  It always sets
          number of CPUs to 1.  KASan doesn't have such limitation.
      
      DEBUG_PAGEALLOC:
      	- KASan is slower than DEBUG_PAGEALLOC, but KASan works on sub-page
      	  granularity level, so it able to find more bugs.
      
      SLUB_DEBUG (poisoning, redzones):
      	- SLUB_DEBUG has lower overhead than KASan.
      
      	- SLUB_DEBUG in most cases are not able to detect bad reads,
      	  KASan able to detect both reads and writes.
      
      	- In some cases (e.g. redzone overwritten) SLUB_DEBUG detect
      	  bugs only on allocation/freeing of object. KASan catch
      	  bugs right before it will happen, so we always know exact
      	  place of first bad read/write.
      
      [1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel
      [2] https://code.google.com/p/address-sanitizer/wiki/FoundBugs
      [3] https://code.google.com/p/thread-sanitizer/wiki/FoundBugs
      [4] https://code.google.com/p/memory-sanitizer/wiki/FoundBugs
      [5] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel#Trophies
      
      Based on work by Andrey Konovalov.
      Signed-off-by: NAndrey Ryabinin <a.ryabinin@samsung.com>
      Acked-by: NMichal Marek <mmarek@suse.cz>
      Signed-off-by: NAndrey Konovalov <adech.fo@gmail.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Konstantin Serebryany <kcc@google.com>
      Cc: Dmitry Chernenkov <dmitryc@google.com>
      Cc: Yuri Gribov <tetra2005@gmail.com>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0b24becc
    • A
      MODULE_DEVICE_TABLE: fix some callsites · 0f989f74
      Andrew Morton 提交于
      The patch "module: fix types of device tables aliases" newly requires that
      invocations of
      
      MODULE_DEVICE_TABLE(type, name);
      
      come *after* the definition of `name'.  That is reasonable, but some
      drivers weren't doing this.  Fix them.
      
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Hans Verkuil <hverkuil@xs4all.nl>
      Acked-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0f989f74
    • T
      drivers/base: use %*pb[l] to print bitmaps including cpumasks and nodemasks · f799b1a7
      Tejun Heo 提交于
      printk and friends can now format bitmaps using '%*pb[l]'.  cpumask
      and nodemask also provide cpumask_pr_args() and nodemask_pr_args()
      respectively which can be used to generate the two printf arguments
      necessary to format the specified cpu/nodemask.
      
      * Line termination only requires one extra space at the end of the
        buffer.  Use PAGE_SIZE - 1 instead of PAGE_SIZE - 2 when formatting.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f799b1a7
    • T
      usb: use %*pb[l] to print bitmaps including cpumasks and nodemasks · 125918db
      Tejun Heo 提交于
      printk and friends can now format bitmaps using '%*pb[l]'.  cpumask
      and nodemask also provide cpumask_pr_args() and nodemask_pr_args()
      respectively which can be used to generate the two printf arguments
      necessary to format the specified cpu/nodemask.
      
      * drivers/uwb/drp.c::uwb_drp_handle_alien_drp() was formatting mas.bm
        into a buffer but never used it.  Removed.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      125918db
    • T
      scsi: use %*pb[l] to print bitmaps including cpumasks and nodemasks · c7badc90
      Tejun Heo 提交于
      printk and friends can now format bitmaps using '%*pb[l]'.  cpumask
      and nodemask also provide cpumask_pr_args() and nodemask_pr_args()
      respectively which can be used to generate the two printf arguments
      necessary to format the specified cpu/nodemask.
      
      * map_show()'s return value is too high by one and the function could
        modify beyond the end of the buffer when the formatted text is long
        enough.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c7badc90
    • T
      input: use %*pb[l] to print bitmaps including cpumasks and nodemasks · 0b480037
      Tejun Heo 提交于
      printk and friends can now format bitmaps using '%*pb[l]'.  cpumask
      and nodemask also provide cpumask_pr_args() and nodemask_pr_args()
      respectively which can be used to generate the two printf arguments
      necessary to format the specified cpu/nodemask.
      
      * Line termination only requires one extra space at the end of the
        buffer.  Use PAGE_SIZE - 1 instead of PAGE_SIZE - 2 when formatting.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0b480037
    • T
      wireless: use %*pb[l] to print bitmaps including cpumasks and nodemasks · 89860038
      Tejun Heo 提交于
      printk and friends can now format bitmaps using '%*pb[l]'.  cpumask
      and nodemask also provide cpumask_pr_args() and nodemask_pr_args()
      respectively which can be used to generate the two printf arguments
      necessary to format the specified cpu/nodemask.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      89860038
    • T
      arm: use %*pb[l] to print bitmaps including cpumasks and nodemasks · 660e5ec0
      Tejun Heo 提交于
      printk and friends can now format bitmaps using '%*pb[l]'.  cpumask
      and nodemask also provide cpumask_pr_args() and nodemask_pr_args()
      respectively which can be used to generate the two printf arguments
      necessary to format the specified cpu/nodemask.
      
      * Line termination only requires one extra space at the end of the
        buffer.  Use PAGE_SIZE - 1 instead of PAGE_SIZE - 2 when formatting.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      660e5ec0
    • T
      tile: use %*pb[l] to print bitmaps including cpumasks and nodemasks · 839b2680
      Tejun Heo 提交于
      printk and friends can now format bitmaps using '%*pb[l]'.  cpumask
      and nodemask also provide cpumask_pr_args() and nodemask_pr_args()
      respectively which can be used to generate the two printf arguments
      necessary to format the specified cpu/nodemask.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      839b2680
    • A
      clk: convert clock name allocations to kstrdup_const · 612936f2
      Andrzej Hajda 提交于
      Clock subsystem frequently performs duplication of strings located in
      read-only memory section.  Replacing kstrdup by kstrdup_const allows to
      avoid such operations.
      Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Mike Turquette <mturquette@linaro.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Greg KH <greg@kroah.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      612936f2
  3. 13 2月, 2015 13 次提交
    • A
      drm/radeon: fix voltage setup on hawaii · 09b6e85f
      Alex Deucher 提交于
      Missing parameter when fetching the real voltage values
      from atom.  Fixes problems with dynamic clocking on
      certain boards.
      
      bug:
      https://bugs.freedesktop.org/show_bug.cgi?id=87457Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      09b6e85f
    • A
      drm/radeon/dp: Set EDP_CONFIGURATION_SET for bridge chips if necessary · 66c2b84b
      Alex Deucher 提交于
      Don't restrict it to just eDP panels.  Some LVDS bridge chips require
      this.  Fixes blank panels on resume on certain laptops.  Noticed
      by mrnuke on IRC.
      
      bug:
      https://bugs.freedesktop.org/show_bug.cgi?id=42960Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      66c2b84b
    • R
      kernel.h: remove ancient __FUNCTION__ hack · 02f1f217
      Rasmus Villemoes 提交于
      __FUNCTION__ hasn't been treated as a string literal since gcc 3.4, so
      this only helps people who only test-compile using 3.3 (compiler-gcc3.h
      barks at anything older than that).  Besides, there are almost no
      occurrences of __FUNCTION__ left in the tree.
      
      [akpm@linux-foundation.org: convert remaining __FUNCTION__ references]
      Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Michal Nazarewicz <mina86@mina86.com>
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      02f1f217
    • G
      mm/zpool: add name argument to create zpool · 3eba0c6a
      Ganesh Mahendran 提交于
      Currently the underlay of zpool: zsmalloc/zbud, do not know who creates
      them.  There is not a method to let zsmalloc/zbud find which caller they
      belong to.
      
      Now we want to add statistics collection in zsmalloc.  We need to name the
      debugfs dir for each pool created.  The way suggested by Minchan Kim is to
      use a name passed by caller(such as zram) to create the zsmalloc pool.
      
          /sys/kernel/debug/zsmalloc/zram0
      
      This patch adds an argument `name' to zs_create_pool() and other related
      functions.
      Signed-off-by: NGanesh Mahendran <opensource.ganesh@gmail.com>
      Acked-by: NMinchan Kim <minchan@kernel.org>
      Cc: Seth Jennings <sjennings@variantweb.net>
      Cc: Nitin Gupta <ngupta@vflare.org>
      Cc: Dan Streetman <ddstreet@ieee.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3eba0c6a
    • S
      zram: remove request_queue from struct zram · ee980160
      Sergey Senozhatsky 提交于
      `struct zram' contains both `struct gendisk' and `struct request_queue'.
      the latter can be deleted, because zram->disk carries ->queue pointer, and
      ->queue carries zram pointer:
      
      create_device()
      	zram->queue->queuedata = zram
      	zram->disk->queue = zram->queue
      	zram->disk->private_data = zram
      
      so zram->queue is not needed, we can access all necessary data anyway.
      Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Jerome Marchand <jmarchan@redhat.com>
      Cc: Nitin Gupta <ngupta@vflare.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ee980160
    • M
      zram: remove init_lock in zram_make_request · 08eee69f
      Minchan Kim 提交于
      Admin could reset zram during I/O operation going on so we have used
      zram->init_lock as read-side lock in I/O path to prevent sudden zram
      meta freeing.
      
      However, the init_lock is really troublesome.  We can't do call
      zram_meta_alloc under init_lock due to lockdep splat because
      zram_rw_page is one of the function under reclaim path and hold it as
      read_lock while other places in process context hold it as write_lock.
      So, we have used allocation out of the lock to avoid lockdep warn but
      it's not good for readability and fainally, I met another lockdep splat
      between init_lock and cpu_hotplug from kmem_cache_destroy during working
      zsmalloc compaction.  :(
      
      Yes, the ideal is to remove horrible init_lock of zram in rw path.  This
      patch removes it in rw path and instead, add atomic refcount for meta
      lifetime management and completion to free meta in process context.
      It's important to free meta in process context because some of resource
      destruction needs mutex lock, which could be held if we releases the
      resource in reclaim context so it's deadlock, again.
      
      As a bonus, we could remove init_done check in rw path because
      zram_meta_get will do a role for it, instead.
      Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: NMinchan Kim <minchan@kernel.org>
      Cc: Nitin Gupta <ngupta@vflare.org>
      Cc: Jerome Marchand <jmarchan@redhat.com>
      Cc: Ganesh Mahendran <opensource.ganesh@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      08eee69f
    • M
      zram: check bd_openers instead of bd_holders · 2b269ce6
      Minchan Kim 提交于
      bd_holders is increased only when user open the device file as FMODE_EXCL
      so if something opens zram0 as !FMODE_EXCL and request I/O while another
      user reset zram0, we can see following warning.
      
        zram0: detected capacity change from 0 to 64424509440
        Buffer I/O error on dev zram0, logical block 180823, lost async page write
        Buffer I/O error on dev zram0, logical block 180824, lost async page write
        Buffer I/O error on dev zram0, logical block 180825, lost async page write
        Buffer I/O error on dev zram0, logical block 180826, lost async page write
        Buffer I/O error on dev zram0, logical block 180827, lost async page write
        Buffer I/O error on dev zram0, logical block 180828, lost async page write
        Buffer I/O error on dev zram0, logical block 180829, lost async page write
        Buffer I/O error on dev zram0, logical block 180830, lost async page write
        Buffer I/O error on dev zram0, logical block 180831, lost async page write
        Buffer I/O error on dev zram0, logical block 180832, lost async page write
        ------------[ cut here ]------------
        WARNING: CPU: 11 PID: 1996 at fs/block_dev.c:57 __blkdev_put+0x1d7/0x210()
        Modules linked in:
        CPU: 11 PID: 1996 Comm: dd Not tainted 3.19.0-rc6-next-20150202+ #1125
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
        Call Trace:
          dump_stack+0x45/0x57
          warn_slowpath_common+0x8a/0xc0
          warn_slowpath_null+0x1a/0x20
          __blkdev_put+0x1d7/0x210
          blkdev_put+0x50/0x130
          blkdev_close+0x25/0x30
          __fput+0xdf/0x1e0
          ____fput+0xe/0x10
          task_work_run+0xa7/0xe0
          do_notify_resume+0x49/0x60
          int_signal+0x12/0x17
        ---[ end trace 274fbbc5664827d2 ]---
      
      The warning comes from bdev_write_node in blkdev_put path.
      
         static void bdev_write_inode(struct inode *inode)
         {
              spin_lock(&inode->i_lock);
              while (inode->i_state & I_DIRTY) {
                      spin_unlock(&inode->i_lock);
                      WARN_ON_ONCE(write_inode_now(inode, true)); <========= here.
                      spin_lock(&inode->i_lock);
              }
              spin_unlock(&inode->i_lock);
         }
      
      The reason is dd process encounters I/O fails due to sudden block device
      disappear so in filemap_check_errors in __writeback_single_inode returns
      -EIO.
      
      If we check bd_openers instead of bd_holders, we could address the
      problem.  When I see the brd, it already have used it rather than
      bd_holders so although I'm not a expert of block layer, it seems to be
      better.
      
      I can make following warning with below simple script.  In addition, I
      added msleep(2000) below set_capacity(zram->disk, 0) after applying your
      patch to make window huge(Kudos to Ganesh!)
      
      script:
      
         echo $((60<<30)) > /sys/block/zram0/disksize
         setsid dd if=/dev/zero of=/dev/zram0 &
         sleep 1
         setsid echo 1 > /sys/block/zram0/reset
      Signed-off-by: NMinchan Kim <minchan@kernel.org>
      Acked-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Nitin Gupta <ngupta@vflare.org>
      Cc: Jerome Marchand <jmarchan@redhat.com>
      Cc: Ganesh Mahendran <opensource.ganesh@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2b269ce6
    • S
      zram: rework reset and destroy path · a096cafc
      Sergey Senozhatsky 提交于
      We need to return set_capacity(disk, 0) from reset_store() back to
      zram_reset_device(), a catch by Ganesh Mahendran.  Potentially, we can
      race set_capacity() calls from init and reset paths.
      
      The problem is that zram_reset_device() is also getting called from
      zram_exit(), which performs operations in misleading reversed order -- we
      first create_device() and then init it, while zram_exit() perform
      destroy_device() first and then does zram_reset_device().  This is done to
      remove sysfs group before we reset device, so we can continue with device
      reset/destruction not being raced by sysfs attr write (f.e.  disksize).
      
      Apart from that, destroy_device() releases zram->disk (but we still have
      ->disk pointer), so we cannot acces zram->disk in later
      zram_reset_device() call, which may cause additional errors in the future.
      
      So, this patch rework and cleanup destroy path.
      
      1) remove several unneeded goto labels in zram_init()
      
      2) factor out zram_init() error path and zram_exit() into
         destroy_devices() function, which takes the number of devices to
         destroy as its argument.
      
      3) remove sysfs group in destroy_devices() first, so we can reorder
         operations -- reset device (as expected) goes before disk destroy and
         queue cleanup.  So we can always access ->disk in zram_reset_device().
      
      4) and, finally, return set_capacity() back under ->init_lock.
      
      [akpm@linux-foundation.org: tweak comment]
      Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Reported-by: NGanesh Mahendran <opensource.ganesh@gmail.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Jerome Marchand <jmarchan@redhat.com>
      Cc: Nitin Gupta <ngupta@vflare.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a096cafc
    • S
      zram: fix umount-reset_store-mount race condition · ba6b17d6
      Sergey Senozhatsky 提交于
      Ganesh Mahendran was the first one who proposed to use bdev->bd_mutex to
      avoid ->bd_holders race condition:
      
              CPU0                            CPU1
      umount /* zram->init_done is true */
      reset_store()
      bdev->bd_holders == 0                   mount
      ...                                     zram_make_request()
      zram_reset_device()
      
      However, his solution required some considerable amount of code movement,
      which we can avoid.
      
      Apart from using bdev->bd_mutex in reset_store(), this patch also
      simplifies zram_reset_device().
      
      zram_reset_device() has a bool parameter reset_capacity which tells it
      whether disk capacity and itself disk should be reset.  There are two
      zram_reset_device() callers:
      
      -- zram_exit() passes reset_capacity=false
      -- reset_store() passes reset_capacity=true
      
      So we can move reset_capacity-sensitive work out of zram_reset_device()
      and perform it unconditionally in reset_store().  This also lets us drop
      reset_capacity parameter from zram_reset_device() and pass zram pointer
      only.
      Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Reported-by: NGanesh Mahendran <opensource.ganesh@gmail.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ba6b17d6
    • G
      zram: free meta table in zram_meta_free · 1fec1172
      Ganesh Mahendran 提交于
      zram_meta_alloc() and zram_meta_free() are a pair.  In
      zram_meta_alloc(), meta table is allocated.  So it it better to free it
      in zram_meta_free().
      Signed-off-by: NGanesh Mahendran <opensource.ganesh@gmail.com>
      Acked-by: NMinchan Kim <minchan@kernel.org>
      Acked-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Nitin Gupta <ngupta@vflare.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1fec1172
    • S
      zram: clean up zram_meta_alloc() · b8179958
      Sergey Senozhatsky 提交于
      A trivial cleanup of zram_meta_alloc() error handling.
      Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Acked-by: NMinchan Kim <minchan@kernel.org>
      Cc: Nitin Gupta <ngupta@vflare.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b8179958
    • D
      UBI: block: Fix checking for NULL instead of IS_ERR() · 8168b9bb
      Dan Carpenter 提交于
      We recently switched from allocating ->rq using blk_init_queue() to
      use blk_mq_init_queue() so we need to update the error handling to
      check for IS_ERR() instead of NULL.
      
      Fixes: ff1f48ee ('UBI: Block: Add blk-mq support')
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      8168b9bb
    • D
      UBI: block: Continue creating ubiblocks after an initialization error · 1440061b
      Dan Ehrenberg 提交于
      If one ubi volume is corrupted but another is not, it should be
      possible to initialize that ubiblock from a kernel commandline which
      includes both of them. This patch changes the error handling behavior
      in initializing ubiblock to ensure that all parameters are attempted
      even if one fails. If there is a failure, it is logged on dmesg.
      It also makes error messages more descriptive by including the
      name of the UBI volume that failed.
      
      Tested: Formatted ubi volume /dev/ubi5_0 in a corrupt way and
      dev/ubi3_0 properly and included "ubi.block=5,0 ubi.block=3,0" on
      the kernel command line. At boot, I see the following in the console:
      [   21.082420] UBI error: ubiblock_create_from_param: block: can't open volume on ubi5_0, err=-19
      [   21.084268] UBI: ubiblock3_0 created from ubi3:0(rootfs)
      Signed-off-by: NDan Ehrenberg <dehrenberg@chromium.org>
      Reviewed-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      1440061b