aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2018-05-21libata: blacklist Micron 500IT SSD with MU01 firmwareSudip Mukherjee1-0/+2
While whitelisting Micron M500DC drives, the tweaked blacklist entry enabled queued TRIM from M500IT variants also. But these do not support queued TRIM. And while using those SSDs with the latest kernel we have seen errors and even the partition table getting corrupted. Some part from the dmesg: [ 6.727384] ata1.00: ATA-9: Micron_M500IT_MTFDDAK060MBD, MU01, max UDMA/133 [ 6.727390] ata1.00: 117231408 sectors, multi 16: LBA48 NCQ (depth 31/32), AA [ 6.741026] ata1.00: supports DRM functions and may not be fully accessible [ 6.759887] ata1.00: configured for UDMA/133 [ 6.762256] scsi 0:0:0:0: Direct-Access ATA Micron_M500IT_MT MU01 PQ: 0 ANSI: 5 and then for the error: [ 120.860334] ata1.00: exception Emask 0x1 SAct 0x7ffc0007 SErr 0x0 action 0x6 frozen [ 120.860338] ata1.00: irq_stat 0x40000008 [ 120.860342] ata1.00: failed command: SEND FPDMA QUEUED [ 120.860351] ata1.00: cmd 64/01:00:00:00:00/00:00:00:00:00/a0 tag 0 ncq dma 512 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x5 (timeout) [ 120.860353] ata1.00: status: { DRDY } [ 120.860543] ata1: hard resetting link [ 121.166128] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 121.166376] ata1.00: supports DRM functions and may not be fully accessible [ 121.186238] ata1.00: supports DRM functions and may not be fully accessible [ 121.204445] ata1.00: configured for UDMA/133 [ 121.204454] ata1.00: device reported invalid CHS sector 0 [ 121.204541] sd 0:0:0:0: [sda] tag#18 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 [ 121.204546] sd 0:0:0:0: [sda] tag#18 Sense Key : 0x5 [current] [ 121.204550] sd 0:0:0:0: [sda] tag#18 ASC=0x21 ASCQ=0x4 [ 121.204555] sd 0:0:0:0: [sda] tag#18 CDB: opcode=0x93 93 08 00 00 00 00 00 04 28 80 00 00 00 30 00 00 [ 121.204559] print_req_error: I/O error, dev sda, sector 272512 After few reboots with these errors, and the SSD is corrupted. After blacklisting it, the errors are not seen and the SSD does not get corrupted any more. Fixes: 243918be6393 ("libata: Do not blacklist Micron M500DC") Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: stable@vger.kernel.org Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2018-05-14libata: Apply NOLPM quirk for SAMSUNG PM830 CXM13D1Q.François Cami1-1/+2
Without this patch the drive errors out regularly: [ 1.090154] ata1.00: ATA-8: SAMSUNG SSD PM830 mSATA 256GB, CXM13D1Q, max UDMA/133 (...) [ 345.154996] ata1.00: exception Emask 0x40 SAct 0x0 SErr 0xc0800 action 0x6 [ 345.155006] ata1.00: irq_stat 0x40000001 [ 345.155013] ata1: SError: { HostInt CommWake 10B8B } [ 345.155018] ata1.00: failed command: SET FEATURES [ 345.155032] ata1.00: cmd ef/05:e1:00:00:00/00:00:00:00:00/40 tag 7 res 51/04:e1:00:00:00/00:00:00:00:00/40 Emask 0x41 (internal error) [ 345.155038] ata1.00: status: { DRDY ERR } [ 345.155042] ata1.00: error: { ABRT } [ 345.155051] ata1: hard resetting link [ 345.465661] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 345.466955] ata1.00: configured for UDMA/133 [ 345.467085] ata1: EH complete Signed-off-by: François Cami <fcami@fedoraproject.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2018-05-08libata: Blacklist some Sandisk SSDs for NCQTejun Heo1-0/+4
Sandisk SSDs SD7SN6S256G and SD8SN8U256G are regularly locking up regularly under sustained moderate load with NCQ enabled. Blacklist for now. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Dave Jones <davej@codemonkey.org.uk> Cc: stable@vger.kernel.org
2018-05-07driver core: add __printf verification to __ata_ehi_pushv_descMathieu Malaterre1-2/+2
__printf is useful to verify format and arguments. Remove the following warning (with W=1): drivers/ata/libata-eh.c:183:10: warning: function might be possible candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format] Signed-off-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: Tejun Heo <tj@kernel.org>
2018-05-01ata: fix spelling mistake: "directon" -> "direction"Colin Ian King1-2/+2
Trivial fix to spelling mistake in sil24_cerr_info message text Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2018-04-26libata: Apply NOLPM quirk for SanDisk SD7UB3Q*G1001 SSDsHans de Goede1-0/+3
Richard Jones has reported that using med_power_with_dipm on a T450s with a Sandisk SD7UB3Q256G1001 SSD (firmware version X2180501) is causing the machine to hang. Switching the LPM to max_performance fixes this, so it seems that this Sandisk SSD does not handle LPM well. Note in the past there have been bug-reports about the following Sandisk models not working with min_power, so we may need to extend the quirk list in the future: name - firmware Sandisk SD6SB2M512G1022I - X210400 Sandisk SD6PP4M-256G-1006 - A200906 Cc: stable@vger.kernel.org Cc: Richard W.M. Jones <rjones@redhat.com> Reported-and-tested-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2018-04-26libata: Apply NOLPM quirk for SAMSUNG MZMPC128HBFU-000MV SSDHans de Goede1-0/+3
Kevin Shanahan reports the following repeating errors when using LPM, causing long delays accessing the disk: Apr 23 10:21:43 link kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x50000 action 0x6 frozen Apr 23 10:21:43 link kernel: ata1: SError: { PHYRdyChg CommWake } Apr 23 10:21:43 link kernel: ata1.00: failed command: WRITE DMA Apr 23 10:21:43 link kernel: ata1.00: cmd ca/00:08:60:5d:cd/00:00:00:00:00/e1 tag 9 dma 4096 out res 50/01:01:01:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Apr 23 10:21:43 link kernel: ata1.00: status: { DRDY } Apr 23 10:21:43 link kernel: ata1.00: error: { AMNF } Apr 23 10:21:43 link kernel: ata1: hard resetting link Apr 23 10:21:43 link kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Apr 23 10:21:43 link kernel: ata1.00: configured for UDMA/133 Apr 23 10:21:43 link kernel: ata1: EH complete These go away when switching from med_power_with_dipm to medium_power. This is somewhat weird as the PM830 datasheet explicitly mentions DIPM being supported and the idle power-consumption is specified with DIPM enabled. There are many OEM customized firmware versions for the PM830, so for now lets assume this is firmware version specific and blacklist LPM based on the firmware version. Cc: Kevin Shanahan <kevin@shanahan.id.au> Reported-by: Kevin Shanahan <kevin@shanahan.id.au> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2018-04-26ata: ahci: mvebu: override ahci_stop_engine for mvebu AHCIEvan Wang1-0/+56
There is an issue(Errata Ref#226) that the SATA can not be detected via SATA Port-MultiPlayer(PMP) with following error log: ata1.15: PMP product ID mismatch ata1.15: SATA link up 6.0 Gbps (SStatus 133 SControl 300) ata1.15: Port Multiplier vendor mismatch '0x1b4b'!='0x0' ata1.15: PMP revalidation failed (errno=-19) After debugging, the reason is found that the value Port-x FIS-based Switching Control(PxFBS@0x40) become wrong. According to design, the bits[11:8, 0] of register PxFBS are cleared when Port Command and Status (0x18) bit[0] changes its value from 1 to 0, i.e. falling edge of Port Command and Status bit[0] sends PULSE that resets PxFBS bits[11:8; 0]. So it needs a mvebu SATA WA to save the port PxFBS register before PxCMD ST write and restore it afterwards. This patch implements the WA in a separate function of ahci_mvebu_stop_engine to override ahci_stop_gngine. Signed-off-by: Evan Wang <xswang@marvell.com> Cc: Ofer Heifetz <oferh@marvell.com> Cc: Tejun Heo <tj@kernel.org> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2018-04-26libahci: Allow drivers to override stop_engineEvan Wang6-15/+26
Marvell armada37xx, armada7k and armada8k share the same AHCI sata controller IP, and currently there is an issue (Errata Ref#226)that the SATA can not be detected via SATA Port-MultiPlayer(PMP). After debugging, the reason is found that the value of Port-x FIS-based Switching Control (PxFBS@0x40) became wrong. According to design, the bits[11:8, 0] of register PxFBS are cleared when Port Command and Status (0x18) bit[0] changes its value from 1 to 0, i.e. falling edge of Port Command and Status bit[0] sends PULSE that resets PxFBS bits[11:8; 0]. So it needs save the port PxFBS register before PxCMD ST write and restore the port PxFBS register afterwards in ahci_stop_engine(). This commit allows drivers to override ahci_stop_engine behavior for use by the Marvell AHCI driver(and potentially other drivers in the future). Signed-off-by: Evan Wang <xswang@marvell.com> Cc: Ofer Heifetz <oferh@marvell.com> Cc: Tejun Heo <tj@kernel.org> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2018-04-09Revert "ata: ahci-platform: add reset control support"Kunihiko Hayashi3-23/+3
This reverts commit f0f56716fc3e5d547fd7811eb218a30ed0695605. According to Thierry's view, https://www.spinics.net/lists/linux-ide/msg55357.html some hardware-specific drivers already use their own resets, and the common reset might make a path to occur double controls of resets. For now, revert the commit that adds reset control support to ahci-platform, and hold until the solution is confirmed not be affect all hardware-specific drivers. Fixes: f0f56716fc3e ("ata: ahci-platform: add reset control support") Reported-by: Thierry Reding <thierry.reding@gmail.com> Suggested-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2018-04-09selinux: fix missing dput() before selinuxfs unmountStephen Smalley1-0/+1
Commit 0619f0f5e36f ("selinux: wrap selinuxfs state") triggers a BUG when SELinux is runtime-disabled (i.e. systemd or equivalent disables SELinux before initial policy load via /sys/fs/selinux/disable based on /etc/selinux/config SELINUX=disabled). This does not manifest if SELinux is disabled via kernel command line argument or if SELinux is enabled (permissive or enforcing). Before: SELinux: Disabled at runtime. BUG: Dentry 000000006d77e5c7{i=17,n=null} still in use (1) [unmount of selinuxfs selinuxfs] After: SELinux: Disabled at runtime. Fixes: 0619f0f5e36f ("selinux: wrap selinuxfs state") Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-04-09Fix subtle macro variable shadowing in min_not_zero()Linus Torvalds1-8/+9
Commit 3c8ba0d61d04 ("kernel.h: Retain constant expression output for max()/min()") rewrote our min/max macros to be very clever, but in the meantime resurrected a variable name shadow issue that we had had previously fixed in commit 589a9785ee3a ("min/max: remove sparse warnings when they're nested"). That commit talks about the sparse warnings that this shadowing causes, which we ignored as just a minor annoyance. But it turns out that the sparse warning is the least of our problems. We actually have a real bug due to the shadowing through the interaction with "min_not_zero()", which ends up doing min(__x, __y) internally, and then the new declaration of "__x" and "__y" as new variables in __cmp_once() results in a complete mess of an expression, and "min_not_zero()" doesn't work at all. For some odd reason, this only ever caused (reported) problems on s390, even though it is a generic issue and most of the (obviously successful) testing of the problematic commit had happened on other architectures. Quoting Sebastian Ott: "What happened is that the bio build by the partition detection code was attempted to be split by the block layer because the block queue had a max_sector setting of 0. blk_queue_max_hw_sectors uses min_not_zero." So re-introduce the use of __UNIQUE_ID() to make sure that the min/max macros do not have these kinds of clashes. [ That said, __UNIQUE_ID() itself has several issues that make it less than wonderful. In particular, the "uniqueness" has a fallback on the line number, which means that it's not actually unique in more complex cases if you don't build with gcc or clang (which have working unique counters that aren't tied to line numbers). That historical broken fallback also means that we have that pointless "prefix" argument that doesn't actually make much sense _except_ for the known-broken case. Oh well. ] Fixes: 3c8ba0d61d04 ("kernel.h: Retain constant expression output for max()/min()") Reported-and-tested-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Cc: Kees Cook <keescook@chromium.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-04-08getname_kernel() needs to make sure that ->name != ->iname in long caseAl Viro1-1/+2
missed it in "kill struct filename.separate" several years ago. Cc: stable@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-04-07alpha: io: reorder barriers to guarantee writeX() and iowriteX() orderingSinan Kaya1-7/+7
memory-barriers.txt has been updated with the following requirement. "When using writel(), a prior wmb() is not needed to guarantee that the cache coherent memory writes have completed before writing to the MMIO region." Current writeX() and iowriteX() implementations on alpha are not satisfying this requirement as the barrier is after the register write. Move mb() in writeX() and iowriteX() functions to guarantee that HW observes memory changes before performing register operations. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Matt Turner <mattst88@gmail.com>
2018-04-07alpha: Implement CPU vulnerabilities sysfs functions.Michael Cree3-1/+47
Implement the CPU vulnerabilty show functions for meltdown, spectre_v1 and spectre_v2 on Alpha. Tests on XP1000 (EV67/667MHz) and ES45 (EV68CB/1.25GHz) show them to be vulnerable to Meltdown and Spectre V1. In the case of Meltdown I saw a 1 to 2% success rate in reading bytes on the XP1000 and 50 to 60% success rate on the ES45. (This compares to 99.97% success reported for Intel CPUs.) Report EV6 and later CPUs as vulnerable. Tests on PWS600au (EV56/600MHz) for Spectre V1 attack were unsuccessful (though I did not try particularly hard) so mark EV4 through to EV56 as not vulnerable. Signed-off-by: Michael Cree <mcree@orcon.net.nz> Signed-off-by: Matt Turner <mattst88@gmail.com>
2018-04-07alpha: rtc: stop validating rtc_time in .read_timeAlexandre Belloni1-1/+1
The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it just before returning from the callback. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Matt Turner <mattst88@gmail.com>
2018-04-07alpha: rtc: remove unused set_mmss opsAlexandre Belloni1-99/+0
The .set_mmss and .setmmss64 ops are only called when the RTC is not providing an implementation for the .set_time callback. On alpha, .set_time is provided so .set_mmss64 is never called. Remove the unused code. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Matt Turner <mattst88@gmail.com>
2018-04-07treewide: fix up files incorrectly marked executableLinus Torvalds2-0/+0
Joe Perches noted that we have a few source files that for some inexplicable reason (read: I'm too lazy to even go look at the history) are marked executable: drivers/gpu/drm/amd/amdgpu/vce_v4_0.c drivers/net/ethernet/cadence/macb_ptp.c A simple git command line to show executable C/asm/header files is this: git ls-files -s '*.[chsS]' | grep '^100755' and then you can fix them up with scripting by just feeding that output into: | cut -f2 | xargs chmod -x and commit it. Which is exactly what this commit does. Reported-by: Joe Perches <joe@perches.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-04-07MAINTAINERS: Update LEAKING_ADDRESSESTobin C. Harding1-0/+3
MAINTAINERS is out of date for leaking_addresses.pl. There is now a tree on kernel.org for development of this script. We have a second maintainer now, thanks Tycho. Development of this scripts was started on kernel-hardening mailing list so let's keep it there. Update maintainer details; Add mailing list, kernel.org hosted tree, and second maintainer. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2018-04-07leaking_addresses: check if file name contains addressTobin C. Harding1-0/+12
Sometimes files may be created by using output from printk. As the scan traverses the directory tree we should parse each path name and check if it is leaking an address. Add check for leaking address on each path name. Suggested-by: Tycho Andersen <tycho@tycho.ws> Acked-by: Tycho Andersen <tycho@tycho.ws> Signed-off-by: Tobin C. Harding <me@tobin.cc>
2018-04-07leaking_addresses: explicitly name variable used in regexTobin C. Harding1-1/+1
Currently sub routine may_leak_address() is checking regex against Perl special variable $_ which is _fortunately_ being set correctly in a loop before this sub routine is called. We already have declared a variable to hold this value '$line' we should use it. Use $line in regex match instead of implicit $_ Signed-off-by: Tobin C. Harding <me@tobin.cc>
2018-04-07leaking_addresses: remove version numberTobin C. Harding1-2/+0
We have git now, we don't need a version number. This was originally added because leaking_addresses.pl shamelessly (and mindlessly) copied checkpatch.pl Remove version number from script. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2018-04-07leaking_addresses: skip '/proc/1/syscall'Tobin C. Harding1-0/+1
The pointers listed in /proc/1/syscall are user pointers, and negative syscall args will show up like kernel addresses. For example /proc/31808/syscall: 0 0x3 0x55b107a38180 0x2000 0xffffffffffffffb0 \ 0x55b107a302d0 0x55b107a38180 0x7fffa313b8e8 0x7ff098560d11 Skip parsing /proc/1/syscall Suggested-by: Tycho Andersen <tycho@tycho.ws> Signed-off-by: Tobin C. Harding <me@tobin.cc>
2018-04-07leaking_addresses: skip all /proc/PID except /proc/1Tobin C. Harding1-0/+12
When the system is idle it is likely that most files under /proc/PID will be identical for various processes. Scanning _all_ the PIDs under /proc is unnecessary and implies that we are thoroughly scanning /proc. This is _not_ the case because there may be ways userspace can trigger creation of /proc files that leak addresses but were not present during a scan. For these two reasons we should exclude all PID directories under /proc except '1/' Exclude all /proc/PID except /proc/1. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2018-04-07leaking_addresses: cache architecture nameTobin C. Harding1-3/+5
Currently we are repeatedly calling `uname -m`. This is causing the script to take a long time to run (more than 10 seconds to parse /proc/kallsyms). We can use Perl state variables to cache the result of the first call to `uname -m`. With this change in place the script scans the whole kernel in under a minute. Cache machine architecture in state variable. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2018-04-07leaking_addresses: simplify path skippingTobin C. Harding1-61/+29
Currently script has multiple configuration arrays. This is confusing, evident by the fact that a bunch of the entries are in the wrong place. We can simplify the code by just having a single array for absolute paths to skip and a single array for file names to skip wherever they appear in the scanned directory tree. There are also currently multiple subroutines to handle the different arrays, we can reduce these to a single subroutine also. Simplify the path skipping code. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2018-04-07leaking_addresses: do not parse binary filesTobin C. Harding1-0/+4
Currently script parses binary files. Since we are scanning for readable kernel addresses there is no need to parse binary files. We can use Perl to check if file is binary and skip parsing it if so. Do not parse binary files. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2018-04-07leaking_addresses: add 32-bit supportTobin C. Harding1-11/+82
Currently script only supports x86_64 and ppc64. It would be nice to be able to scan 32-bit machines also. We can add support for 32-bit architectures by modifying how we check for false positives, taking advantage of the page offset used by the kernel, and using the correct regular expression. Support for 32-bit machines is enabled by the observation that the kernel addresses on 32-bit machines are larger [in value] than the page offset. We can use this to filter false positives when scanning the kernel for leaking addresses. Programmatic determination of the running architecture is not immediately obvious (current 32-bit machines return various strings from `uname -m`). We therefore provide a flag to enable scanning of 32-bit kernels. Also we can check the kernel config file for the offset and if not found default to 0xc0000000. A command line option to parse in the page offset is also provided. We do automatically detect architecture if running on ix86. Add support for 32-bit kernels. Add a command line option for page offset. Suggested-by: Kaiwan N Billimoria <kaiwan.billimoria@gmail.com> Signed-off-by: Tobin C. Harding <me@tobin.cc>
2018-04-07leaking_addresses: add is_arch() wrapper subroutineTobin C. Harding1-12/+14
Currently there is duplicate code when checking the architecture type. We can remove the duplication by implementing a wrapper function is_arch(). Implement and use wrapper function is_arch(). Signed-off-by: Tobin C. Harding <me@tobin.cc>
2018-04-07leaking_addresses: use system command to get archTobin C. Harding1-6/+6
Currently script uses Perl to get the machine architecture. This can be erroneous since Perl uses the architecture of the machine that Perl was compiled on not the architecture of the running machine. We should use the systems `uname` command instead. Use `uname -m` instead of Perl to get the machine architecture. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2018-04-07leaking_addresses: add support for 5 page table levelsTobin C. Harding1-7/+25
Currently script only supports 4 page table levels because of the way the kernel address regular expression is crafted. We can do better than this. Using previously added support for kernel configuration options we can get the number of page table levels defined by CONFIG_PGTABLE_LEVELS. Using this value a correct regular expression can be crafted. This only supports 5 page tables on x86_64. Add support for 5 page table levels on x86_64. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2018-04-07leaking_addresses: add support for kernel config fileTobin C. Harding1-1/+65
Features that rely on the ability to get kernel configuration options are ready to be implemented in script. In preparation for this we can add support for kernel config options as a separate patch to ease review. Add support for locating and parsing kernel configuration file. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2018-04-07leaking_addresses: add range check for vsyscall memoryTobin C. Harding1-6/+14
Currently script checks only first and last address in the vsyscall memory range. We can do better than this. When checking for false positives against $match, we can convert $match to a hexadecimal value then check if it lies within the range of vsyscall addresses. Check whole range of vsyscall addresses when checking for false positive. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2018-04-07leaking_addresses: indent dependant optionsTobin C. Harding1-8/+8
A number of the command line options to script are dependant on the option --input-raw being set. If we indent these options it makes explicit this dependency. Indent options dependant on --input-raw. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2018-04-07leaking_addresses: remove command examplesTobin C. Harding1-11/+0
Currently help output includes command examples. These were cute when we first started development of this script but are unnecessary. Remove command examples. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2018-04-07leaking_addresses: remove mention of kptr_restrictTobin C. Harding1-3/+0
leaking_addresses.pl can be run with kptr_restrict==0 now, we don't need the comment about setting kptr_restrict any more. Remove comment suggesting setting kptr_restrict. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2018-04-07leaking_addresses: fix typo function not calledTobin C. Harding1-1/+1
Currently code uses a check against an undefined variable because the variable is a sub routine name and is not evaluated. Evaluate subroutine; add parenthesis to sub routine name. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2018-04-06pstore: fix crypto dependencies without compressionTobias Regnery1-2/+2
Commit 58eb5b670747 ("pstore: fix crypto dependencies") fixed up the crypto dependencies but missed the case when no compression is selected. With CONFIG_PSTORE=y, CONFIG_PSTORE_COMPRESS=n and CONFIG_CRYPTO=m we see the following link error: fs/pstore/platform.o: In function `pstore_register': (.text+0x1b1): undefined reference to `crypto_has_alg' (.text+0x205): undefined reference to `crypto_alloc_base' fs/pstore/platform.o: In function `pstore_unregister': (.text+0x3b0): undefined reference to `crypto_destroy_tfm' Fix this by checking at compile-time if CONFIG_PSTORE_COMPRESS is enabled. Fixes: 58eb5b670747 ("pstore: fix crypto dependencies") Signed-off-by: Tobias Regnery <tobias.regnery@gmail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kees Cook <keescook@chromium.org>
2018-04-06make lookup_one_len() safe to use with directory locked sharedAl Viro1-1/+3
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-04-06new helper: __lookup_slow()Al Viro1-9/+18
lookup_slow() sans locking/unlocking the directory Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-04-06merge common parts of lookup_one_len{,_unlocked} into common helperAl Viro1-56/+34
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-04-06kvm: x86: fix a prototype warningPeng Hao1-1/+1
Make the function static to avoid a warning: no previous prototype for ‘vmx_enable_tdp’ Signed-off-by: Peng Hao <peng.hao2@zte.com.cn> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-04-06ARM: sa1100/simpad: switch simpad CF to use gpiod APIsRussell King2-9/+14
Switch simpad's CF implementation to use the gpiod APIs. The inverted detection is handled using gpiolib's native inversion abilities. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2018-04-06ARM: sa1100/shannon: convert to generic CF socketsRussell King6-109/+40
Convert shannon to use the generic CF socket support. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2018-04-06ARM: sa1100/nanoengine: convert to generic CF socketsRussell King5-138/+23
Convert nanoengine to use the generic CF socket support. Makefile fix from Arnd Bergmann <arnd@arndb.de>. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2018-04-06fscache: Maintain a catalogue of allocated cookiesDavid Howells5-119/+279
Maintain a catalogue of allocated cookies so that cookie collisions can be handled properly. For the moment, this just involves printing a warning and returning a NULL cookie to the caller of fscache_acquire_cookie(), but in future it might make sense to wait for the old cookie to finish being cleaned up. This requires the cookie key to be stored attached to the cookie so that we still have the key available if the netfs relinquishes the cookie. This is done by an earlier patch. The catalogue also renders redundant fscache_netfs_list (used for checking for duplicates), so that can be removed. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Anna Schumaker <anna.schumaker@netapp.com> Tested-by: Steve Dickson <steved@redhat.com>
2018-04-06fscache: Pass object size in rather than calling back for itDavid Howells21-166/+127
Pass the object size in to fscache_acquire_cookie() and fscache_write_page() rather than the netfs providing a callback by which it can be received. This makes it easier to update the size of the object when a new page is written that extends the object. The current object size is also passed by fscache to the check_aux function, obviating the need to store it in the aux data. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Anna Schumaker <anna.schumaker@netapp.com> Tested-by: Steve Dickson <steved@redhat.com>
2018-04-05mm,oom_reaper: check for MMF_OOM_SKIP before complainingTetsuo Handa1-1/+2
I got "oom_reaper: unable to reap pid:" messages when the victim thread was blocked inside free_pgtables() (which occurred after returning from unmap_vmas() and setting MMF_OOM_SKIP). We don't need to complain when exit_mmap() already set MMF_OOM_SKIP. Killed process 7558 (a.out) total-vm:4176kB, anon-rss:84kB, file-rss:0kB, shmem-rss:0kB oom_reaper: unable to reap pid:7558 (a.out) a.out D13272 7558 6931 0x00100084 Call Trace: schedule+0x2d/0x80 rwsem_down_write_failed+0x2bb/0x440 call_rwsem_down_write_failed+0x13/0x20 down_write+0x49/0x60 unlink_file_vma+0x28/0x50 free_pgtables+0x36/0x100 exit_mmap+0xbb/0x180 mmput+0x50/0x110 copy_process.part.41+0xb61/0x1fe0 _do_fork+0xe6/0x560 do_syscall_64+0x74/0x230 entry_SYSCALL_64_after_hwframe+0x42/0xb7 Link: http://lkml.kernel.org/r/201803221946.DHG65638.VFJHFtOSQLOMOF@I-love.SAKURA.ne.jp Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Acked-by: David Rientjes <rientjes@google.com> Acked-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-04-05mm/ksm: fix interaction with THPClaudio Imbrenda1-0/+28
This patch fixes a corner case for KSM. When two pages belong or belonged to the same transparent hugepage, and they should be merged, KSM fails to split the page, and therefore no merging happens. This bug can be reproduced by: * making sure ksm is running (in case disabling ksmtuned) * enabling transparent hugepages * allocating a THP-aligned 1-THP-sized buffer e.g. on amd64: posix_memalign(&p, 1<<21, 1<<21) * filling it with the same values e.g. memset(p, 42, 1<<21) * performing madvise to make it mergeable e.g. madvise(p, 1<<21, MADV_MERGEABLE) * waiting for KSM to perform a few scans The expected outcome is that the all the pages get merged (1 shared and the rest sharing); the actual outcome is that no pages get merged (1 unshared and the rest volatile) The reason of this behaviour is that we increase the reference count once for both pages we want to merge, but if they belong to the same hugepage (or compound page), the reference counter used in both cases is the one of the head of the compound page. This means that split_huge_page will find a value of the reference counter too high and will fail. This patch solves this problem by testing if the two pages to merge belong to the same hugepage when attempting to merge them. If so, the hugepage is split safely. This means that the hugepage is not split if not necessary. Link: http://lkml.kernel.org/r/1521548069-24758-1-git-send-email-imbrenda@linux.vnet.ibm.com Signed-off-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Co-authored-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Hugh Dickins <hughd@google.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-04-05mm/memblock.c: cast constant ULLONG_MAX to phys_addr_tStefan Agner1-2/+2
This fixes a warning shown when phys_addr_t is 32-bit int when compiling with clang: mm/memblock.c:927:15: warning: implicit conversion from 'unsigned long long' to 'phys_addr_t' (aka 'unsigned int') changes value from 18446744073709551615 to 4294967295 [-Wconstant-conversion] r->base : ULLONG_MAX; ^~~~~~~~~~ ./include/linux/kernel.h:30:21: note: expanded from macro 'ULLONG_MAX' #define ULLONG_MAX (~0ULL) ^~~~~ Link: http://lkml.kernel.org/r/20180319005645.29051-1-stefan@agner.ch Signed-off-by: Stefan Agner <stefan@agner.ch> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Pavel Tatashin <pasha.tatashin@oracle.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>