aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2019-10-19rtc: ds1343: use rtc_add_groupAlexandre Belloni1-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>
2019-10-19rtc: ds1343: use burst write to set timeAlexandre Belloni1-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>
2019-10-19rtc: ds1343: remove dead codeAlexandre Belloni1-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>
2019-10-19rtc: ds1343: set rangeAlexandre Belloni1-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>
2019-10-19rtc: introduce lock helpersAlexandre Belloni1-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>
2019-10-19rtc: vt8500: let the core handle rtc rangeAlexandre Belloni1-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>
2019-10-19rtc: vt8500: convert to devm_rtc_allocate_deviceAlexandre Belloni1-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>
2019-10-19rtc: vt8500: remove superfluous error messageAlexandre Belloni1-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>
2019-10-19rtc: vt8500: remove useless labelAlexandre Belloni1-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>
2019-10-19rtc: add timestamp for end of 2199Alexandre Belloni1-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>
2019-10-19rtc: s35390a: set rangeAlexandre Belloni1-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>
2019-10-19rtc: s35390a: convert to devm_rtc_allocate_deviceAlexandre Belloni1-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>
2019-10-16rtc: meson-vrtc: move config option to proper locationAlexandre Belloni1-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>
2019-10-16rtc: ds1685: add indirect access method and remove plat_read/plat_writeThomas Bogendoerfer3-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>
2019-10-14rtc: ds1685: use devm_platform_ioremap_resource helperThomas Bogendoerfer2-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>
2019-10-14rts: ds1685: remove not needed fields from private structThomas Bogendoerfer2-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>
2019-10-14rtc: xilinx: Fix calibval variable typeSrinivas Goud1-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>
2019-10-14rtc: wilco-ec: Handle reading invalid timesNick Crews1-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>
2019-10-07rtc: ds1347: handle century registerAlexandre Belloni1-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>
2019-10-07rtc: ds1347: use regmap_update_bitsAlexandre Belloni1-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>
2019-10-07rtc: ds1347: properly handle oscillator failuresAlexandre Belloni1-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>
2019-10-07rtc: ds1347: set rangeAlexandre Belloni1-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>
2019-10-07rtc: ds1347: convert to devm_rtc_allocate_deviceAlexandre Belloni1-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>
2019-10-07rtc: ds1347: mask ALM OUT when reading timeAlexandre Belloni1-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>
2019-10-07rtc: ds1347: simplify getting .driver_dataAlexandre Belloni1-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>
2019-10-07rtc: ds1347: remove useless readAlexandre Belloni1-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>
2019-10-07rtc: ds1347: remove verbose messagesAlexandre Belloni1-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>
2019-10-07rtc: add a timestamp for year 0Alexandre Belloni1-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>
2019-10-07rtc: armada38x: Use of_device_get_match_data()Stephen Boyd1-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>
2019-10-07rtc: da9063: Handle invalid IRQ from platform_get_irq_byname()Krzysztof Kozlowski1-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>
2019-10-07rtc: m41t80: set rangeAlexandre Belloni1-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>
2019-10-07rtc: use devm_platform_ioremap_resource() to simplify codeYueHaibing34-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>
2019-10-06rtc: Use devm_platform_ioremap_resource()Markus Elfring4-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>
2019-10-03rtc: interface: use timeu64_t for range_maxEmmanuel Nicolet1-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>
2019-10-03rtc: at91rm9200: use of_device_get_match_data()Claudiu Beznea2-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>
2019-09-30Linux 5.4-rc1Linus Torvalds1-2/+2
2019-09-30csky: Move static keyword to the front of declarationKrzysztof Wilczynski1-1/+1
Move the static keyword to the front of declaration of csky_pmu_of_device_ids, and resolve the following compiler warning that can be seen when building with warnings enabled (W=1): arch/csky/kernel/perf_event.c:1340:1: warning: ‘static’ is not at beginning of declaration [-Wold-style-declaration] Signed-off-by: Krzysztof Wilczynski <kw@linux.com> Signed-off-by: Guo Ren <guoren@kernel.org>
2019-09-30csky: entry: Remove unneeded need_resched() loopValentin Schneider1-4/+0
Since the enabling and disabling of IRQs within preempt_schedule_irq() is contained in a need_resched() loop, we don't need the outer arch code loop. Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Guo Ren <guoren@kernel.org>
2019-09-30csky: Fixup csky_pmu.max_period assignmentMao Han1-1/+1
The csky_pmu.max_period has type u64, and BIT() can only return 32 bits unsigned long on C-SKY. The initialization for max_period will be incorrect when count_width is bigger than 32. Use BIT_ULL() Signed-off-by: Mao Han <han_mao@c-sky.com> Signed-off-by: Guo Ren <ren_guo@c-sky.com>
2019-09-30csky: Fixup add zero_fp fixup perf backtrace panicGuo Ren2-21/+31
We need set fp zero to let backtrace know the end. The patch fixup perf callchain panic problem, because backtrace didn't know what is the end of fp. Signed-off-by: Guo Ren <ren_guo@c-sky.com> Reported-by: Mao Han <han_mao@c-sky.com>
2019-09-30csky: Use generic free_initrd_mem()Mike Rapoport1-16/+0
The csky implementation of free_initrd_mem() is an open-coded version of free_reserved_area() without poisoning. Remove it and make csky use the generic version of free_initrd_mem(). Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Guo Ren <guoren@kernel.org>
2019-09-29Revert "Revert "ext4: make __ext4_get_inode_loc plug""Linus Torvalds1-0/+3
This reverts commit 72dbcf72156641fde4d8ea401e977341bfd35a05. Instead of waiting forever for entropy that may just not happen, we now try to actively generate entropy when required, and are thus hopefully avoiding the problem that caused the nice ext4 IO pattern fix to be reverted. So revert the revert. Cc: Ahmed S. Darwish <darwish.07@gmail.com> Cc: Ted Ts'o <tytso@mit.edu> Cc: Willy Tarreau <w@1wt.eu> Cc: Alexander E. Patrakov <patrakov@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-09-29random: try to actively add entropy rather than passively wait for itLinus Torvalds1-1/+61
For 5.3 we had to revert a nice ext4 IO pattern improvement, because it caused a bootup regression due to lack of entropy at bootup together with arguably broken user space that was asking for secure random numbers when it really didn't need to. See commit 72dbcf721566 (Revert "ext4: make __ext4_get_inode_loc plug"). This aims to solve the issue by actively generating entropy noise using the CPU cycle counter when waiting for the random number generator to initialize. This only works when you have a high-frequency time stamp counter available, but that's the case on all modern x86 CPU's, and on most other modern CPU's too. What we do is to generate jitter entropy from the CPU cycle counter under a somewhat complex load: calling the scheduler while also guaranteeing a certain amount of timing noise by also triggering a timer. I'm sure we can tweak this, and that people will want to look at other alternatives, but there's been a number of papers written on jitter entropy, and this should really be fairly conservative by crediting one bit of entropy for every timer-induced jump in the cycle counter. Not because the timer itself would be all that unpredictable, but because the interaction between the timer and the loop is going to be. Even if (and perhaps particularly if) the timer actually happens on another CPU, the cacheline interaction between the loop that reads the cycle counter and the timer itself firing is going to add perturbations to the cycle counter values that get mixed into the entropy pool. As Thomas pointed out, with a modern out-of-order CPU, even quite simple loops show a fair amount of hard-to-predict timing variability even in the absense of external interrupts. But this tries to take that further by actually having a fairly complex interaction. This is not going to solve the entropy issue for architectures that have no CPU cycle counter, but it's not clear how (and if) that is solvable, and the hardware in question is largely starting to be irrelevant. And by doing this we can at least avoid some of the even more contentious approaches (like making the entropy waiting time out in order to avoid the possibly unbounded waiting). Cc: Ahmed Darwish <darwish.07@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Theodore Ts'o <tytso@mit.edu> Cc: Nicholas Mc Guire <hofrat@opentech.at> Cc: Andy Lutomirski <luto@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Willy Tarreau <w@1wt.eu> Cc: Alexander E. Patrakov <patrakov@gmail.com> Cc: Lennart Poettering <mzxreary@0pointer.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-09-29Documentation/process: Clarify disclosure rulesThomas Gleixner1-7/+33
The role of the contact list provided by the disclosing party and how it affects the disclosure process and the ability to include experts into the development process is not really well explained. Neither is it entirely clear when the disclosing party will be informed about the fact that a developer who is not covered by an employer NDA needs to be brought in and disclosed. Explain the role of the contact list and the information policy along with an eventual conflict resolution better. Reported-by: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://lore.kernel.org/r/alpine.DEB.2.21.1909251028390.10825@nanos.tec.linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-28selftests/ftrace: Fix same probe error testSteven Rostedt (VMware)1-1/+1
The "same probe" selftest that tests that adding the same probe fails doesn't add the same probe and passes, which fails the test. Fixes: b78b94b82122 ("selftests/ftrace: Update kprobe event error testcase") Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2019-09-28mm, tracing: Print symbol name for call_site in trace eventsChangbin Du1-3/+4
To improve the readability of raw slab trace points, print the call_site ip using '%pS'. Then we can grep events with function names. [002] .... 808.188897: kmem_cache_free: call_site=putname+0x47/0x50 ptr=00000000cef40c80 [002] .... 808.188898: kfree: call_site=security_cred_free+0x42/0x50 ptr=0000000062400820 [002] .... 808.188904: kmem_cache_free: call_site=put_cred_rcu+0x88/0xa0 ptr=0000000058d74ef8 [002] .... 808.188913: kmem_cache_alloc: call_site=prepare_creds+0x26/0x100 ptr=0000000058d74ef8 bytes_req=168 bytes_alloc=576 gfp_flags=GFP_KERNEL [002] .... 808.188917: kmalloc: call_site=security_prepare_creds+0x77/0xa0 ptr=0000000062400820 bytes_req=8 bytes_alloc=336 gfp_flags=GFP_KERNEL|__GFP_ZERO [002] .... 808.188920: kmem_cache_alloc: call_site=getname_flags+0x4f/0x1e0 ptr=00000000cef40c80 bytes_req=4096 bytes_alloc=4480 gfp_flags=GFP_KERNEL [002] .... 808.188925: kmem_cache_free: call_site=putname+0x47/0x50 ptr=00000000cef40c80 [002] .... 808.188926: kfree: call_site=security_cred_free+0x42/0x50 ptr=0000000062400820 [002] .... 808.188931: kmem_cache_free: call_site=put_cred_rcu+0x88/0xa0 ptr=0000000058d74ef8 Link: http://lkml.kernel.org/r/20190914103215.23301-1-changbin.du@gmail.com Signed-off-by: Changbin Du <changbin.du@gmail.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2019-09-28tracing: Have error path in predicate_parse() free its allocated memoryNavid Emamdoost1-2/+4
In predicate_parse, there is an error path that is not going to out_free instead it returns directly which leads to a memory leak. Link: http://lkml.kernel.org/r/20190920225800.3870-1-navid.emamdoost@gmail.com Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2019-09-28tracing: Fix clang -Wint-in-bool-context warnings in IF_ASSIGN macroNathan Chancellor1-5/+5
After r372664 in clang, the IF_ASSIGN macro causes a couple hundred warnings along the lines of: kernel/trace/trace_output.c:1331:2: warning: converting the enum constant to a boolean [-Wint-in-bool-context] kernel/trace/trace.h:409:3: note: expanded from macro 'trace_assign_type' IF_ASSIGN(var, ent, struct ftrace_graph_ret_entry, ^ kernel/trace/trace.h:371:14: note: expanded from macro 'IF_ASSIGN' WARN_ON(id && (entry)->type != id); \ ^ 264 warnings generated. This warning can catch issues with constructs like: if (state == A || B) where the developer really meant: if (state == A || state == B) This is currently the only occurrence of the warning in the kernel tree across defconfig, allyesconfig, allmodconfig for arm32, arm64, and x86_64. Add the implicit '!= 0' to the WARN_ON statement to fix the warnings and find potential issues in the future. Link: https://github.com/llvm/llvm-project/commit/28b38c277a2941e9e891b2db30652cfd962f070b Link: https://github.com/ClangBuiltLinux/linux/issues/686 Link: http://lkml.kernel.org/r/20190926162258.466321-1-natechancellor@gmail.com Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2019-09-28tracing/probe: Fix to check the difference of nr_args before adding probeMasami Hiramatsu1-0/+16
Steven reported that a test triggered: ================================================================== BUG: KASAN: slab-out-of-bounds in trace_kprobe_create+0xa9e/0xe40 Read of size 8 at addr ffff8880c4f25a48 by task ftracetest/4798 CPU: 2 PID: 4798 Comm: ftracetest Not tainted 5.3.0-rc6-test+ #30 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 Call Trace: dump_stack+0x7c/0xc0 ? trace_kprobe_create+0xa9e/0xe40 print_address_description+0x6c/0x332 ? trace_kprobe_create+0xa9e/0xe40 ? trace_kprobe_create+0xa9e/0xe40 __kasan_report.cold.6+0x1a/0x3b ? trace_kprobe_create+0xa9e/0xe40 kasan_report+0xe/0x12 trace_kprobe_create+0xa9e/0xe40 ? print_kprobe_event+0x280/0x280 ? match_held_lock+0x1b/0x240 ? find_held_lock+0xac/0xd0 ? fs_reclaim_release.part.112+0x5/0x20 ? lock_downgrade+0x350/0x350 ? kasan_unpoison_shadow+0x30/0x40 ? __kasan_kmalloc.constprop.6+0xc1/0xd0 ? trace_kprobe_create+0xe40/0xe40 ? trace_kprobe_create+0xe40/0xe40 create_or_delete_trace_kprobe+0x2e/0x60 trace_run_command+0xc3/0xe0 ? trace_panic_handler+0x20/0x20 ? kasan_unpoison_shadow+0x30/0x40 trace_parse_run_command+0xdc/0x163 vfs_write+0xe1/0x240 ksys_write+0xba/0x150 ? __ia32_sys_read+0x50/0x50 ? tracer_hardirqs_on+0x61/0x180 ? trace_hardirqs_off_caller+0x43/0x110 ? mark_held_locks+0x29/0xa0 ? do_syscall_64+0x14/0x260 do_syscall_64+0x68/0x260 Fix to check the difference of nr_args before adding probe on existing probes. This also may set the error log index bigger than the number of command parameters. In that case it sets the error position is next to the last parameter. Link: http://lkml.kernel.org/r/156966474783.3478.13217501608215769150.stgit@devnote2 Fixes: ca89bc071d5e ("tracing/kprobe: Add multi-probe per event support") Reported-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2019-09-28mm, page_alloc: allow hugepage fallback to remote nodes when madvisedDavid Rientjes1-0/+11
For systems configured to always try hard to allocate transparent hugepages (thp defrag setting of "always") or for memory that has been explicitly madvised to MADV_HUGEPAGE, it is often better to fallback to remote memory to allocate the hugepage if the local allocation fails first. The point is to allow the initial call to __alloc_pages_node() to attempt to defragment local memory to make a hugepage available, if possible, rather than immediately fallback to remote memory. Local hugepages will always have a better access latency than remote (huge)pages, so an attempt to make a hugepage available locally is always preferred. If memory compaction cannot be successful locally, however, it is likely better to fallback to remote memory. This could take on two forms: either allow immediate fallback to remote memory or do per-zone watermark checks. It would be possible to fallback only when per-zone watermarks fail for order-0 memory, since that would require local reclaim for all subsequent faults so remote huge allocation is likely better than thrashing the local zone for large workloads. In this case, it is assumed that because the system is configured to try hard to allocate hugepages or the vma is advised to explicitly want to try hard for hugepages that remote allocation is better when local allocation and memory compaction have both failed. Signed-off-by: David Rientjes <rientjes@google.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Stefan Priebe - Profihost AG <s.priebe@profihost.ag> Cc: "Kirill A. Shutemov" <kirill@shutemov.name> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.