summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* rtc: rv3028: add clkout supportParthiban Nallathambi2019-10-191-0/+146
| | | | | | | | | | rv3028 provides clkout (enabled by default). Add clkout to clock framework source and control from device tree for variable frequency with enable and disable functionality. Signed-off-by: Parthiban Nallathambi <pn@denx.de> Link: https://lore.kernel.org/r/20191018100425.1687979-1-pn@denx.de Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1343: cleanup .removeAlexandre Belloni2019-10-191-9/+1
| | | | | | | | | | It is not necessary to call device_init_wakeup(dev, false) in .remove as device_del will take care of that. It is also not necessary to devm_free_irq. Finally, dev_pm_clear_wake_irq can be called unconditionally. Link: https://lore.kernel.org/r/20191019204941.6203-9-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1343: rework interrupt handlingAlexandre Belloni2019-10-191-77/+35
| | | | | | | | | | | | Rework the interrupt handling to avoid caching the values as the core is already doing that. The core also always ensures the rtc_time passed for the alarm is fully populated. The only trick is in read_alarm where status needs to be read before the alarm registers to ensure the potential irq is not cleared. Link: https://lore.kernel.org/r/20191019204941.6203-8-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1343: remove unnecessary mutexAlexandre Belloni2019-10-191-29/+7
| | | | | | | | Use rtc_lock and rtc_unlock to lock the rtc from the interrupt handler. This removes the need for a driver specific lock. Link: https://lore.kernel.org/r/20191019204941.6203-7-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1343: check regmap_read return valueAlexandre Belloni2019-10-191-3/+8
| | | | | | | | Check whether regmap_read fails before continuing in the sysfs .show callbacks. Link: https://lore.kernel.org/r/20191019204941.6203-6-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1343: use regmap_update_bits for glitch filterAlexandre Belloni2019-10-191-10/+8
| | | | | | | | Use regmap_update_bits to update DS1343_CONTROL_REG in a race free manner when setting the glitch filter. Link: https://lore.kernel.org/r/20191019204941.6203-5-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1343: use rtc_add_groupAlexandre Belloni2019-10-191-31/+16
| | | | | | | | Use rtc_add_group to add the sysfs group in a race free manner. This has the side effect of moving the files to their proper location. Link: https://lore.kernel.org/r/20191019204941.6203-4-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1343: use burst write to set timeAlexandre Belloni2019-10-191-40/+12
| | | | | | | | To avoid possible race condition, use regmap_bulk_write to write all the date/time registers at once instead of sequentially. Link: https://lore.kernel.org/r/20191019204941.6203-3-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1343: remove dead codeAlexandre Belloni2019-10-191-21/+0
| | | | | | | RTC_SET_CHARGE doesn't exist, the ioctl code is never used. Link: https://lore.kernel.org/r/20191019204941.6203-2-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1343: set rangeAlexandre Belloni2019-10-191-0/+2
| | | | | | | | This is a standard BCD rtc with a useless century bit (no leap year correction after 2099). Link: https://lore.kernel.org/r/20191019204941.6203-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: introduce lock helpersAlexandre Belloni2019-10-191-0/+3
| | | | | | | | Introduce rtc_lock and rtc_unlock to shorten the code when locking and unlocking ops_lock from drivers. Link: https://lore.kernel.org/r/20191019205034.6382-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: vt8500: let the core handle rtc rangeAlexandre Belloni2019-10-191-6/+2
| | | | | | | Let the rtc core check the date/time against the RTC range. Link: https://lore.kernel.org/r/20191016201626.31309-5-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: vt8500: convert to devm_rtc_allocate_deviceAlexandre Belloni2019-10-191-3/+4
| | | | | | | This allows further improvement of the driver. Link: https://lore.kernel.org/r/20191016201626.31309-4-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: vt8500: remove superfluous error messageAlexandre Belloni2019-10-191-4/+1
| | | | | | | | The RTC core now has error messages in case of registration failure, there is no need to have other messages in the drivers. Link: https://lore.kernel.org/r/20191016201626.31309-3-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: vt8500: remove useless labelAlexandre Belloni2019-10-191-6/+2
| | | | | | | err_return doesn't do anything special, simply return instead of goto. Link: https://lore.kernel.org/r/20191016201626.31309-2-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: add timestamp for end of 2199Alexandre Belloni2019-10-191-0/+1
| | | | | | | Some RTCs handle date up to 2199. Link: https://lore.kernel.org/r/20191016201626.31309-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: s35390a: set rangeAlexandre Belloni2019-10-191-0/+2
| | | | | | | This is a standard BCD RTC that will fail in 2100. Link: https://lore.kernel.org/r/20191016200848.30246-2-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: s35390a: convert to devm_rtc_allocate_deviceAlexandre Belloni2019-10-191-8/+6
| | | | | | | | This allows further improvement of the driver and removes the need to forward declare s35390a_driver. Link: https://lore.kernel.org/r/20191016200848.30246-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: meson-vrtc: move config option to proper locationAlexandre Belloni2019-10-161-11/+11
| | | | | | | | The correct location for this option is under platform driver, not i2c drivers. Link: https://lore.kernel.org/r/20191014155840.22554-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1685: add indirect access method and remove plat_read/plat_writeThomas Bogendoerfer2019-10-163-30/+58
| | | | | | | | | | | | | | | SGI Octane (IP30) doesn't have RTC register directly mapped into CPU address space, but accesses RTC registers with an address and data register. This is now supported by additional access functions, which are selected by a new field in platform data. Removed plat_read/plat_write since there is no user and their usage could introduce lifetime issue, when functions are placed in different modules. Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de> Acked-by: Joshua Kinard <kumba@gentoo.org> Reviewed-by: Joshua Kinard <kumba@gentoo.org> Link: https://lore.kernel.org/r/20191014214621.25257-1-tbogendoerfer@suse.de Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1685: use devm_platform_ioremap_resource helperThomas Bogendoerfer2019-10-142-21/+3
| | | | | | | | | Simplify ioremapping of registers by using devm_platform_ioremap_resource. Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de> Acked-by: Joshua Kinard <kumba@gentoo.org> Link: https://lore.kernel.org/r/20191011150546.9186-2-tbogendoerfer@suse.de Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rts: ds1685: remove not needed fields from private structThomas Bogendoerfer2019-10-142-6/+0
| | | | | | | | | | A few of the fields in struct ds1685_priv aren't needed at all, so we can remove it. Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de> Acked-by: Joshua Kinard <kumba@gentoo.org> Link: https://lore.kernel.org/r/20191011150546.9186-1-tbogendoerfer@suse.de Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: xilinx: Fix calibval variable typeSrinivas Goud2019-10-141-1/+1
| | | | | | | | | | This patch fixes the warnings reported by static code analysis. Updated calibval variable type to unsigned type from signed. Signed-off-by: Srinivas Goud <srinivas.goud@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/20765c4c27aa92c75426b82fd2815ebef6471492.1570544738.git.michal.simek@xilinx.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: wilco-ec: Handle reading invalid timesNick Crews2019-10-141-3/+5
| | | | | | | | | | | | | | If the RTC HW returns an invalid time, the rtc_year_days() call would crash. This patch adds error logging in this situation, and removes the tm_yday and tm_wday calculations. These fields should not be relied upon by userspace according to man rtc, and thus we don't need to calculate them. Signed-off-by: Nick Crews <ncrews@chromium.org> Reviewed-by: Daniel Campello <campello@chromium.org> Link: https://lore.kernel.org/r/20191004142608.170159-1-ncrews@chromium.org Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1347: handle century registerAlexandre Belloni2019-10-071-13/+24
| | | | | | | The DS1347 can handle years from 0 to 9999, add century register support. Link: https://lore.kernel.org/r/20191007134724.15505-10-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1347: use regmap_update_bitsAlexandre Belloni2019-10-071-4/+6
| | | | | | | | Use regmap_update_bits instead of open coding. Also add proper error handling. Link: https://lore.kernel.org/r/20191007134724.15505-9-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1347: properly handle oscillator failuresAlexandre Belloni2019-10-071-7/+23
| | | | | | | | | | | | | The comment in the probe function stating that it disables oscillator stop detection and glitch filtering is incorrect as it sets bits 3 and 4 while it should be setting 5 and 6 to achieve that. Then, it is safe to assume that the oscillator failure detection is actually enabled. Properly handle oscillator failures by returning -EINVAL when the time and date are know to be incorrect and reset the flag when the time is set. Link: https://lore.kernel.org/r/20191007134724.15505-8-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1347: set rangeAlexandre Belloni2019-10-071-0/+2
| | | | | | | | The DS1347 handle dates from year 0000 to 9999. Leap years are claimed to be handled correctly in the datasheet. Link: https://lore.kernel.org/r/20191007134724.15505-7-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1347: convert to devm_rtc_allocate_deviceAlexandre Belloni2019-10-071-4/+4
| | | | | | | This allows further improvement of the driver. Link: https://lore.kernel.org/r/20191007134724.15505-6-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1347: mask ALM OUT when reading timeAlexandre Belloni2019-10-071-1/+1
| | | | | | | | Bit 7 of the minutes registers is ALM OUT. It indicates an alarm fired. Mask it out when reading the time. Link: https://lore.kernel.org/r/20191007134724.15505-5-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1347: simplify getting .driver_dataAlexandre Belloni2019-10-071-8/+2
| | | | | | | | Get 'driver_data' from 'struct device' directly. Going via spi_device is an unnecessary step. Link: https://lore.kernel.org/r/20191007134724.15505-4-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1347: remove useless readAlexandre Belloni2019-10-071-6/+0
| | | | | | | | DS1347_SECONDS_REG is read at probe time but the value is simply discarded. Remove that useless read. Link: https://lore.kernel.org/r/20191007134724.15505-3-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ds1347: remove verbose messagesAlexandre Belloni2019-10-071-7/+0
| | | | | | | | Printing debugging (and opaque) information is not useful and only clutters the boot log. Remove those messages. Link: https://lore.kernel.org/r/20191007134724.15505-2-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: add a timestamp for year 0Alexandre Belloni2019-10-071-0/+1
| | | | | | | | A few RTCs handle dates from year 0 to year 9999. Add a timestamp even if years before 1970 will probably never be used. Link: https://lore.kernel.org/r/20191007134724.15505-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: armada38x: Use of_device_get_match_data()Stephen Boyd2019-10-071-7/+3
| | | | | | | | | | | | | | | | | | | | | Use the more modern API to get the match data out of the of match table. This saves some code, lines, and nicely avoids referencing the match table when it is undefined with configurations where CONFIG_OF=n. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Gregory Clement <gregory.clement@bootlin.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: <linux-rtc@vger.kernel.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20191004214334.149976-4-swboyd@chromium.org Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: da9063: Handle invalid IRQ from platform_get_irq_byname()Krzysztof Kozlowski2019-10-071-0/+3
| | | | | | | | | | platform_get_irq_byname() might return -errno which later would be cast to an unsigned int and used in request_irq(). Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Tested-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/20191004150510.6278-1-krzk@kernel.org Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: m41t80: set rangeAlexandre Belloni2019-10-071-3/+2
| | | | | | | | This is a standard BCD RTC that will fail in 2100. The century bits don't help because 2100 will be considered a leap year while it is not. Link: https://lore.kernel.org/r/20191003213544.5359-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: use devm_platform_ioremap_resource() to simplify codeYueHaibing2019-10-0734-103/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20191006102953.57536-2-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-3-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-4-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-5-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-6-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-7-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-8-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-9-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-10-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-11-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-12-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-13-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-14-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-15-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-16-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-17-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-18-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-19-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-20-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-21-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-22-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-23-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-24-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-25-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-26-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-27-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-28-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-29-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-30-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-31-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-32-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-33-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-34-yuehaibing@huawei.com Link: https://lore.kernel.org/r/20191006102953.57536-35-yuehaibing@huawei.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: Use devm_platform_ioremap_resource()Markus Elfring2019-10-064-30/+5
| | | | | | | | | | | | | | Simplify probe by using a known wrapper function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Link: https://lore.kernel.org/r/4552ef52-f218-93b1-6dfa-668d137676f8@web.de Link: https://lore.kernel.org/r/5ecfcf43-d6b2-1a38-dee8-b8806f30bc83@web.de Link: https://lore.kernel.org/r/25448e11-c43f-9ae0-4c43-6f789accc026@web.de Reviewed-by: Akinobu Mita <akinobu.mita@gmail.com> Link: https://lore.kernel.org/r/8c17a59c-82ff-aa6b-5653-a38d786d3e83@web.de Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: interface: use timeu64_t for range_maxEmmanuel Nicolet2019-10-031-1/+1
| | | | | | | | | | | | | | For rtc drivers where rtc->range_max is set U64_MAX, like the PS3 rtc, rtc_valid_range() always returns -ERANGE. This is because the local variable range_max has type time64_t, so the test if (time < range_min || time > range_max) return -ERANGE; becomes (time < range_min || time > -1), which always evaluates to true. timeu64_t should be used, since it's the type of rtc->range_max. Signed-off-by: Emmanuel Nicolet <emmanuel.nicolet@gmail.com> Link: https://lore.kernel.org/r/20190927110446.GA6289@gmail.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: at91rm9200: use of_device_get_match_data()Claudiu Beznea2019-10-032-18/+2
| | | | | | | | | | Use of_device_get_match_data() since all platforms should now use DT bindings. AVR32 architecture has been removed in commit 26202873bb51 ("avr32: remove support for AVR32 architecture"). Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/1569500132-21164-1-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* Linux 5.4-rc1v5.4-rc1Linus Torvalds2019-09-301-2/+2
|
* Merge tag 'for-5.4-rc1-tag' of ↵Linus Torvalds2019-09-305-18/+58
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: "A bunch of fixes that accumulated in recent weeks, mostly material for stable. Summary: - fix for regression from 5.3 that prevents to use balance convert with single profile - qgroup fixes: rescan race, accounting leak with multiple writers, potential leak after io failure recovery - fix for use after free in relocation (reported by KASAN) - other error handling fixups" * tag 'for-5.4-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: qgroup: Fix reserved data space leak if we have multiple reserve calls btrfs: qgroup: Fix the wrong target io_tree when freeing reserved data space btrfs: Fix a regression which we can't convert to SINGLE profile btrfs: relocation: fix use-after-free on dead relocation roots Btrfs: fix race setting up and completing qgroup rescan workers Btrfs: fix missing error return if writeback for extent buffer never started btrfs: adjust dirty_metadata_bytes after writeback failure of extent buffer Btrfs: fix selftests failure due to uninitialized i_mode in test inodes
| * btrfs: qgroup: Fix reserved data space leak if we have multiple reserve callsQu Wenruo2019-09-271-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [BUG] The following script can cause btrfs qgroup data space leak: mkfs.btrfs -f $dev mount $dev -o nospace_cache $mnt btrfs subv create $mnt/subv btrfs quota en $mnt btrfs quota rescan -w $mnt btrfs qgroup limit 128m $mnt/subv for (( i = 0; i < 3; i++)); do # Create 3 64M holes for latter fallocate to fail truncate -s 192m $mnt/subv/file xfs_io -c "pwrite 64m 4k" $mnt/subv/file > /dev/null xfs_io -c "pwrite 128m 4k" $mnt/subv/file > /dev/null sync # it's supposed to fail, and each failure will leak at least 64M # data space xfs_io -f -c "falloc 0 192m" $mnt/subv/file &> /dev/null rm $mnt/subv/file sync done # Shouldn't fail after we removed the file xfs_io -f -c "falloc 0 64m" $mnt/subv/file [CAUSE] Btrfs qgroup data reserve code allow multiple reservations to happen on a single extent_changeset: E.g: btrfs_qgroup_reserve_data(inode, &data_reserved, 0, SZ_1M); btrfs_qgroup_reserve_data(inode, &data_reserved, SZ_1M, SZ_2M); btrfs_qgroup_reserve_data(inode, &data_reserved, 0, SZ_4M); Btrfs qgroup code has its internal tracking to make sure we don't double-reserve in above example. The only pattern utilizing this feature is in the main while loop of btrfs_fallocate() function. However btrfs_qgroup_reserve_data()'s error handling has a bug in that on error it clears all ranges in the io_tree with EXTENT_QGROUP_RESERVED flag but doesn't free previously reserved bytes. This bug has a two fold effect: - Clearing EXTENT_QGROUP_RESERVED ranges This is the correct behavior, but it prevents btrfs_qgroup_check_reserved_leak() to catch the leakage as the detector is purely EXTENT_QGROUP_RESERVED flag based. - Leak the previously reserved data bytes. The bug manifests when N calls to btrfs_qgroup_reserve_data are made and the last one fails, leaking space reserved in the previous ones. [FIX] Also free previously reserved data bytes when btrfs_qgroup_reserve_data fails. Fixes: 524725537023 ("btrfs: qgroup: Introduce btrfs_qgroup_reserve_data function") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
| * btrfs: qgroup: Fix the wrong target io_tree when freeing reserved data spaceQu Wenruo2019-09-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [BUG] Under the following case with qgroup enabled, if some error happened after we have reserved delalloc space, then in error handling path, we could cause qgroup data space leakage: From btrfs_truncate_block() in inode.c: ret = btrfs_delalloc_reserve_space(inode, &data_reserved, block_start, blocksize); if (ret) goto out; again: page = find_or_create_page(mapping, index, mask); if (!page) { btrfs_delalloc_release_space(inode, data_reserved, block_start, blocksize, true); btrfs_delalloc_release_extents(BTRFS_I(inode), blocksize, true); ret = -ENOMEM; goto out; } [CAUSE] In the above case, btrfs_delalloc_reserve_space() will call btrfs_qgroup_reserve_data() and mark the io_tree range with EXTENT_QGROUP_RESERVED flag. In the error handling path, we have the following call stack: btrfs_delalloc_release_space() |- btrfs_free_reserved_data_space() |- btrsf_qgroup_free_data() |- __btrfs_qgroup_release_data(reserved=@reserved, free=1) |- qgroup_free_reserved_data(reserved=@reserved) |- clear_record_extent_bits(); |- freed += changeset.bytes_changed; However due to a completion bug, qgroup_free_reserved_data() will clear EXTENT_QGROUP_RESERVED flag in BTRFS_I(inode)->io_failure_tree, other than the correct BTRFS_I(inode)->io_tree. Since io_failure_tree is never marked with that flag, btrfs_qgroup_free_data() will not free any data reserved space at all, causing a leakage. This type of error handling can only be triggered by errors outside of qgroup code. So EDQUOT error from qgroup can't trigger it. [FIX] Fix the wrong target io_tree. Reported-by: Josef Bacik <josef@toxicpanda.com> Fixes: bc42bda22345 ("btrfs: qgroup: Fix qgroup reserved space underflow by only freeing reserved ranges") CC: stable@vger.kernel.org # 4.14+ Reviewed-by: Nikolay Borisov <nborisov@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
| * btrfs: Fix a regression which we can't convert to SINGLE profileQu Wenruo2019-09-251-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [BUG] With v5.3 kernel, we can't convert to SINGLE profile: # btrfs balance start -f -dconvert=single $mnt ERROR: error during balancing '/mnt/btrfs': Invalid argument # dmesg -t | tail validate_convert_profile: data profile=0x1000000000000 allowed=0x20 is_valid=1 final=0x1000000000000 ret=1 BTRFS error (device dm-3): balance: invalid convert data profile single [CAUSE] With the extra debug output added, it shows that the @allowed bit is lacking the special in-memory only SINGLE profile bit. Thus we fail at that (profile & ~allowed) check. This regression is caused by commit 081db89b13cb ("btrfs: use raid_attr to get allowed profiles for balance conversion") and the fact that we don't use any bit to indicate SINGLE profile on-disk, but uses special in-memory only bit to help distinguish different profiles. [FIX] Add that BTRFS_AVAIL_ALLOC_BIT_SINGLE to @allowed, so the code should be the same as it was and fix the regression. Reported-by: Chris Murphy <lists@colorremedies.com> Fixes: 081db89b13cb ("btrfs: use raid_attr to get allowed profiles for balance conversion") CC: stable@vger.kernel.org # 5.3+ Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
| * btrfs: relocation: fix use-after-free on dead relocation rootsQu Wenruo2019-09-251-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [BUG] One user reported a reproducible KASAN report about use-after-free: BTRFS info (device sdi1): balance: start -dvrange=1256811659264..1256811659265 BTRFS info (device sdi1): relocating block group 1256811659264 flags data|raid0 ================================================================== BUG: KASAN: use-after-free in btrfs_init_reloc_root+0x2cd/0x340 [btrfs] Write of size 8 at addr ffff88856f671710 by task kworker/u24:10/261579 CPU: 2 PID: 261579 Comm: kworker/u24:10 Tainted: P OE 5.2.11-arch1-1-kasan #4 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X99 Extreme4, BIOS P3.80 04/06/2018 Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs] Call Trace: dump_stack+0x7b/0xba print_address_description+0x6c/0x22e ? btrfs_init_reloc_root+0x2cd/0x340 [btrfs] __kasan_report.cold+0x1b/0x3b ? btrfs_init_reloc_root+0x2cd/0x340 [btrfs] kasan_report+0x12/0x17 __asan_report_store8_noabort+0x17/0x20 btrfs_init_reloc_root+0x2cd/0x340 [btrfs] record_root_in_trans+0x2a0/0x370 [btrfs] btrfs_record_root_in_trans+0xf4/0x140 [btrfs] start_transaction+0x1ab/0xe90 [btrfs] btrfs_join_transaction+0x1d/0x20 [btrfs] btrfs_finish_ordered_io+0x7bf/0x18a0 [btrfs] ? lock_repin_lock+0x400/0x400 ? __kmem_cache_shutdown.cold+0x140/0x1ad ? btrfs_unlink_subvol+0x9b0/0x9b0 [btrfs] finish_ordered_fn+0x15/0x20 [btrfs] normal_work_helper+0x1bd/0xca0 [btrfs] ? process_one_work+0x819/0x1720 ? kasan_check_read+0x11/0x20 btrfs_endio_write_helper+0x12/0x20 [btrfs] process_one_work+0x8c9/0x1720 ? pwq_dec_nr_in_flight+0x2f0/0x2f0 ? worker_thread+0x1d9/0x1030 worker_thread+0x98/0x1030 kthread+0x2bb/0x3b0 ? process_one_work+0x1720/0x1720 ? kthread_park+0x120/0x120 ret_from_fork+0x35/0x40 Allocated by task 369692: __kasan_kmalloc.part.0+0x44/0xc0 __kasan_kmalloc.constprop.0+0xba/0xc0 kasan_kmalloc+0x9/0x10 kmem_cache_alloc_trace+0x138/0x260 btrfs_read_tree_root+0x92/0x360 [btrfs] btrfs_read_fs_root+0x10/0xb0 [btrfs] create_reloc_root+0x47d/0xa10 [btrfs] btrfs_init_reloc_root+0x1e2/0x340 [btrfs] record_root_in_trans+0x2a0/0x370 [btrfs] btrfs_record_root_in_trans+0xf4/0x140 [btrfs] start_transaction+0x1ab/0xe90 [btrfs] btrfs_start_transaction+0x1e/0x20 [btrfs] __btrfs_prealloc_file_range+0x1c2/0xa00 [btrfs] btrfs_prealloc_file_range+0x13/0x20 [btrfs] prealloc_file_extent_cluster+0x29f/0x570 [btrfs] relocate_file_extent_cluster+0x193/0xc30 [btrfs] relocate_data_extent+0x1f8/0x490 [btrfs] relocate_block_group+0x600/0x1060 [btrfs] btrfs_relocate_block_group+0x3a0/0xa00 [btrfs] btrfs_relocate_chunk+0x9e/0x180 [btrfs] btrfs_balance+0x14e4/0x2fc0 [btrfs] btrfs_ioctl_balance+0x47f/0x640 [btrfs] btrfs_ioctl+0x119d/0x8380 [btrfs] do_vfs_ioctl+0x9f5/0x1060 ksys_ioctl+0x67/0x90 __x64_sys_ioctl+0x73/0xb0 do_syscall_64+0xa5/0x370 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 369692: __kasan_slab_free+0x14f/0x210 kasan_slab_free+0xe/0x10 kfree+0xd8/0x270 btrfs_drop_snapshot+0x154c/0x1eb0 [btrfs] clean_dirty_subvols+0x227/0x340 [btrfs] relocate_block_group+0x972/0x1060 [btrfs] btrfs_relocate_block_group+0x3a0/0xa00 [btrfs] btrfs_relocate_chunk+0x9e/0x180 [btrfs] btrfs_balance+0x14e4/0x2fc0 [btrfs] btrfs_ioctl_balance+0x47f/0x640 [btrfs] btrfs_ioctl+0x119d/0x8380 [btrfs] do_vfs_ioctl+0x9f5/0x1060 ksys_ioctl+0x67/0x90 __x64_sys_ioctl+0x73/0xb0 do_syscall_64+0xa5/0x370 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at ffff88856f671100 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 1552 bytes inside of 4096-byte region [ffff88856f671100, ffff88856f672100) The buggy address belongs to the page: page:ffffea0015bd9c00 refcount:1 mapcount:0 mapping:ffff88864400e600 index:0x0 compound_mapcount: 0 flags: 0x2ffff0000010200(slab|head) raw: 02ffff0000010200 dead000000000100 dead000000000200 ffff88864400e600 raw: 0000000000000000 0000000000070007 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88856f671600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88856f671680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff88856f671700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88856f671780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88856f671800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== BTRFS info (device sdi1): 1 enospc errors during balance BTRFS info (device sdi1): balance: ended with status: -28 [CAUSE] The problem happens when finish_ordered_io() get called with balance still running, while the reloc root of that subvolume is already dead. (Tree is swap already done, but tree not yet deleted for possible qgroup usage.) That means root->reloc_root still exists, but that reloc_root can be under btrfs_drop_snapshot(), thus we shouldn't access it. The following race could cause the use-after-free problem: CPU1 | CPU2 -------------------------------------------------------------------------- | relocate_block_group() | |- unset_reloc_control(rc) | |- btrfs_commit_transaction() btrfs_finish_ordered_io() | |- clean_dirty_subvols() |- btrfs_join_transaction() | | |- record_root_in_trans() | | |- btrfs_init_reloc_root() | | |- if (root->reloc_root) | | | | |- root->reloc_root = NULL | | |- btrfs_drop_snapshot(reloc_root); |- reloc_root->last_trans| = trans->transid | ^^^^^^^^^^^^^^^^^^^^^^ Use after free [FIX] Fix it by the following modifications: - Test if the root has dead reloc tree before accessing root->reloc_root If the root has BTRFS_ROOT_DEAD_RELOC_TREE, then we don't need to create or update root->reloc_tree - Clear the BTRFS_ROOT_DEAD_RELOC_TREE flag until we have fully dropped reloc tree To co-operate with above modification, so as long as BTRFS_ROOT_DEAD_RELOC_TREE is still set, we won't try to re-create reloc tree at record_root_in_trans(). Reported-by: Cebtenzzre <cebtenzzre@gmail.com> Fixes: d2311e698578 ("btrfs: relocation: Delay reloc tree deletion after merge_reloc_roots") CC: stable@vger.kernel.org # 5.1+ Reviewed-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
| * Btrfs: fix race setting up and completing qgroup rescan workersFilipe Manana2019-09-241-14/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a race between setting up a qgroup rescan worker and completing a qgroup rescan worker that can lead to callers of the qgroup rescan wait ioctl to either not wait for the rescan worker to complete or to hang forever due to missing wake ups. The following diagram shows a sequence of steps that illustrates the race. CPU 1 CPU 2 CPU 3 btrfs_ioctl_quota_rescan() btrfs_qgroup_rescan() qgroup_rescan_init() mutex_lock(&fs_info->qgroup_rescan_lock) spin_lock(&fs_info->qgroup_lock) fs_info->qgroup_flags |= BTRFS_QGROUP_STATUS_FLAG_RESCAN init_completion( &fs_info->qgroup_rescan_completion) fs_info->qgroup_rescan_running = true mutex_unlock(&fs_info->qgroup_rescan_lock) spin_unlock(&fs_info->qgroup_lock) btrfs_init_work() --> starts the worker btrfs_qgroup_rescan_worker() mutex_lock(&fs_info->qgroup_rescan_lock) fs_info->qgroup_flags &= ~BTRFS_QGROUP_STATUS_FLAG_RESCAN mutex_unlock(&fs_info->qgroup_rescan_lock) starts transaction, updates qgroup status item, etc btrfs_ioctl_quota_rescan() btrfs_qgroup_rescan() qgroup_rescan_init() mutex_lock(&fs_info->qgroup_rescan_lock) spin_lock(&fs_info->qgroup_lock) fs_info->qgroup_flags |= BTRFS_QGROUP_STATUS_FLAG_RESCAN init_completion( &fs_info->qgroup_rescan_completion) fs_info->qgroup_rescan_running = true mutex_unlock(&fs_info->qgroup_rescan_lock) spin_unlock(&fs_info->qgroup_lock) btrfs_init_work() --> starts another worker mutex_lock(&fs_info->qgroup_rescan_lock) fs_info->qgroup_rescan_running = false mutex_unlock(&fs_info->qgroup_rescan_lock) complete_all(&fs_info->qgroup_rescan_completion) Before the rescan worker started by the task at CPU 3 completes, if another task calls btrfs_ioctl_quota_rescan(), it will get -EINPROGRESS because the flag BTRFS_QGROUP_STATUS_FLAG_RESCAN is set at fs_info->qgroup_flags, which is expected and correct behaviour. However if other task calls btrfs_ioctl_quota_rescan_wait() before the rescan worker started by the task at CPU 3 completes, it will return immediately without waiting for the new rescan worker to complete, because fs_info->qgroup_rescan_running is set to false by CPU 2. This race is making test case btrfs/171 (from fstests) to fail often: btrfs/171 9s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//btrfs/171.out.bad) --- tests/btrfs/171.out 2018-09-16 21:30:48.505104287 +0100 +++ /home/fdmanana/git/hub/xfstests/results//btrfs/171.out.bad 2019-09-19 02:01:36.938486039 +0100 @@ -1,2 +1,3 @@ QA output created by 171 +ERROR: quota rescan failed: Operation now in progress Silence is golden ... (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/171.out /home/fdmanana/git/hub/xfstests/results//btrfs/171.out.bad' to see the entire diff) That is because the test calls the btrfs-progs commands "qgroup quota rescan -w", "qgroup assign" and "qgroup remove" in a sequence that makes calls to the rescan start ioctl fail with -EINPROGRESS (note the "btrfs" commands 'qgroup assign' and 'qgroup remove' often call the rescan start ioctl after calling the qgroup assign ioctl, btrfs_ioctl_qgroup_assign()), since previous waits didn't actually wait for a rescan worker to complete. Another problem the race can cause is missing wake ups for waiters, since the call to complete_all() happens outside a critical section and after clearing the flag BTRFS_QGROUP_STATUS_FLAG_RESCAN. In the sequence diagram above, if we have a waiter for the first rescan task (executed by CPU 2), then fs_info->qgroup_rescan_completion.wait is not empty, and if after the rescan worker clears BTRFS_QGROUP_STATUS_FLAG_RESCAN and before it calls complete_all() against fs_info->qgroup_rescan_completion, the task at CPU 3 calls init_completion() against fs_info->qgroup_rescan_completion which re-initilizes its wait queue to an empty queue, therefore causing the rescan worker at CPU 2 to call complete_all() against an empty queue, never waking up the task waiting for that rescan worker. Fix this by clearing BTRFS_QGROUP_STATUS_FLAG_RESCAN and setting fs_info->qgroup_rescan_running to false in the same critical section, delimited by the mutex fs_info->qgroup_rescan_lock, as well as doing the call to complete_all() in that same critical section. This gives the protection needed to avoid rescan wait ioctl callers not waiting for a running rescan worker and the lost wake ups problem, since setting that rescan flag and boolean as well as initializing the wait queue is done already in a critical section delimited by that mutex (at qgroup_rescan_init()). Fixes: 57254b6ebce4ce ("Btrfs: add ioctl to wait for qgroup rescan completion") Fixes: d2c609b834d62f ("btrfs: properly track when rescan worker is running") CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
| * Btrfs: fix missing error return if writeback for extent buffer never startedFilipe Manana2019-09-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If lock_extent_buffer_for_io() fails, it returns a negative value, but its caller btree_write_cache_pages() ignores such error. This means that a call to flush_write_bio(), from lock_extent_buffer_for_io(), might have failed. We should make btree_write_cache_pages() notice such error values and stop immediatelly, making sure filemap_fdatawrite_range() returns an error to the transaction commit path. A failure from flush_write_bio() should also result in the endio callback end_bio_extent_buffer_writepage() being invoked, which sets the BTRFS_FS_*_ERR bits appropriately, so that there's no risk a transaction or log commit doesn't catch a writeback failure. Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
| * btrfs: adjust dirty_metadata_bytes after writeback failure of extent bufferDennis Zhou2019-09-241-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Before, if a eb failed to write out, we would end up triggering a BUG_ON(). As of f4340622e0226 ("btrfs: extent_io: Move the BUG_ON() in flush_write_bio() one level up"), we no longer BUG_ON(), so we should make life consistent and add back the unwritten bytes to dirty_metadata_bytes. Fixes: f4340622e022 ("btrfs: extent_io: Move the BUG_ON() in flush_write_bio() one level up") CC: stable@vger.kernel.org # 5.2+ Reviewed-by: Filipe Manana <fdmanana@kernel.org> Signed-off-by: Dennis Zhou <dennis@kernel.org> Signed-off-by: David Sterba <dsterba@suse.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 22:23:31 +0100