aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2018-05-11mmap: introduce sane default mmap limitsLinus Torvalds1-0/+32
The internal VM "mmap()" interfaces are based on the mmap target doing everything using page indexes rather than byte offsets, because traditionally (ie 32-bit) we had the situation that the byte offset didn't fit in a register. So while the mmap virtual address was limited by the word size of the architecture, the backing store was not. So we're basically passing "pgoff" around as a page index, in order to be able to describe backing store locations that are much bigger than the word size (think files larger than 4GB etc). But while this all makes a ton of sense conceptually, we've been dogged by various drivers that don't really understand this, and internally work with byte offsets, and then try to work with the page index by turning it into a byte offset with "pgoff << PAGE_SHIFT". Which obviously can overflow. Adding the size of the mapping to it to get the byte offset of the end of the backing store just exacerbates the problem, and if you then use this overflow-prone value to check various limits of your device driver mmap capability, you're just setting yourself up for problems. The correct thing for drivers to do is to do their limit math in page indices, the way the interface is designed. Because the generic mmap code _does_ test that the index doesn't overflow, since that's what the mmap code really cares about. HOWEVER. Finding and fixing various random drivers is a sisyphean task, so let's just see if we can just make the core mmap() code do the limiting for us. Realistically, the only "big" backing stores we need to care about are regular files and block devices, both of which are known to do this properly, and which have nice well-defined limits for how much data they can access. So let's special-case just those two known cases, and then limit other random mmap users to a backing store that still fits in "unsigned long". Realistically, that's not much of a limit at all on 64-bit, and on 32-bit architectures the only worry might be the GPU drivers, which can have big physical address spaces. To make it possible for drivers like that to say that they are 64-bit clean, this patch does repurpose the "FMODE_UNSIGNED_OFFSET" bit in the file flags to allow drivers to mark their file descriptors as safe in the full 64-bit mmap address space. [ The timing for doing this is less than optimal, and this should really go in a merge window. But realistically, this needs wide testing more than it needs anything else, and being main-line is the only way to do that. So the earlier the better, even if it's outside the proper development cycle - Linus ] Cc: Kees Cook <keescook@chromium.org> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Willy Tarreau <w@1wt.eu> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-05-11tracing: Fix regex_match_front() to not over compare the test stringSteven Rostedt (VMware)1-0/+3
The regex match function regex_match_front() in the tracing filter logic, was fixed to test just the pattern length from testing the entire test string. That is, it went from strncmp(str, r->pattern, len) to strcmp(str, r->pattern, r->len). The issue is that str is not guaranteed to be nul terminated, and if r->len is greater than the length of str, it can access more memory than is allocated. The solution is to add a simple test if (len < r->len) return 0. Cc: stable@vger.kernel.org Fixes: 285caad415f45 ("tracing/filters: Fix MATCH_FRONT_ONLY filter matching") Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2018-05-10compat: fix 4-byte infoleak via uninitialized struct fieldJann Horn1-0/+1
Commit 3a4d44b61625 ("ntp: Move adjtimex related compat syscalls to native counterparts") removed the memset() in compat_get_timex(). Since then, the compat adjtimex syscall can invoke do_adjtimex() with an uninitialized ->tai. If do_adjtimex() doesn't write to ->tai (e.g. because the arguments are invalid), compat_put_timex() then copies the uninitialized ->tai field to userspace. Fix it by adding the memset() back. Fixes: 3a4d44b61625 ("ntp: Move adjtimex related compat syscalls to native counterparts") Signed-off-by: Jann Horn <jannh@google.com> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-05-10dm thin: update Documentation to clarify when "read_only" is validMike Snitzer1-1/+4
Due to user confusion, clarify that it doesn't make sense to try to create a thin-pool with "read_only" mode enabled. Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2018-05-10PCI / PM: Check device_may_wakeup() in pci_enable_wake()Rafael J. Wysocki1-6/+23
Commit 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code) went too far and dropped the device_may_wakeup() check from pci_enable_wake() which causes wakeup to be enabled during system suspend, hibernation or shutdown for some PCI devices that are not allowed by user space to wake up the system from sleep (or power off). As a result of this, excessive power is drawn by some of the affected systems while in sleep states or off. Restore the device_may_wakeup() check in pci_enable_wake(), but make sure that the PCI bus type's runtime suspend callback will not call device_may_wakeup() which is about system wakeup from sleep and not about device wakeup from runtime suspend. Fixes: 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code) Reported-by: Joseph Salisbury <joseph.salisbury@canonical.com> Cc: 4.13+ <stable@vger.kernel.org> # 4.13+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2018-05-10drm/amd/pp: Fix performance drop on FijiRex Zhu1-3/+1
The performance drop if the default TDP more than 256 Watt Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-10mtd: rawnand: Make sure we wait tWB before polling the STATUS regBoris Brezillon1-0/+5
NAND chips require a bit of time to take the NAND operation into account and set the BUSY bit in the STATUS reg. Make sure we don't poll the STATUS reg too early in nand_soft_waitrdy(). Fixes: 8878b126df76 ("mtd: nand: add ->exec_op() implementation") Cc: <stable@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
2018-05-10drm/nouveau: Fix deadlock in nv50_mstm_register_connector()Lyude Paul1-4/+3
Currently; we're grabbing all of the modesetting locks before adding MST connectors to fbdev. This isn't actually necessary, and causes a deadlock as well: ====================================================== WARNING: possible circular locking dependency detected 4.17.0-rc3Lyude-Test+ #1 Tainted: G O ------------------------------------------------------ kworker/1:0/18 is trying to acquire lock: 00000000c832f62d (&helper->lock){+.+.}, at: drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper] but task is already holding lock: 00000000942e28e2 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_backoff+0x8e/0x1c0 [drm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (crtc_ww_class_mutex){+.+.}: ww_mutex_lock+0x43/0x80 drm_modeset_lock+0x71/0x130 [drm] drm_helper_probe_single_connector_modes+0x7d/0x6b0 [drm_kms_helper] drm_setup_crtcs+0x15e/0xc90 [drm_kms_helper] __drm_fb_helper_initial_config_and_unlock+0x29/0x480 [drm_kms_helper] nouveau_fbcon_init+0x138/0x1a0 [nouveau] nouveau_drm_load+0x173/0x7e0 [nouveau] drm_dev_register+0x134/0x1c0 [drm] drm_get_pci_dev+0x8e/0x160 [drm] nouveau_drm_probe+0x1a9/0x230 [nouveau] pci_device_probe+0xcd/0x150 driver_probe_device+0x30b/0x480 __driver_attach+0xbc/0xe0 bus_for_each_dev+0x67/0x90 bus_add_driver+0x164/0x260 driver_register+0x57/0xc0 do_one_initcall+0x4d/0x323 do_init_module+0x5b/0x1f8 load_module+0x20e5/0x2ac0 __do_sys_finit_module+0xb7/0xd0 do_syscall_64+0x60/0x1b0 entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #2 (crtc_ww_class_acquire){+.+.}: drm_helper_probe_single_connector_modes+0x58/0x6b0 [drm_kms_helper] drm_setup_crtcs+0x15e/0xc90 [drm_kms_helper] __drm_fb_helper_initial_config_and_unlock+0x29/0x480 [drm_kms_helper] nouveau_fbcon_init+0x138/0x1a0 [nouveau] nouveau_drm_load+0x173/0x7e0 [nouveau] drm_dev_register+0x134/0x1c0 [drm] drm_get_pci_dev+0x8e/0x160 [drm] nouveau_drm_probe+0x1a9/0x230 [nouveau] pci_device_probe+0xcd/0x150 driver_probe_device+0x30b/0x480 __driver_attach+0xbc/0xe0 bus_for_each_dev+0x67/0x90 bus_add_driver+0x164/0x260 driver_register+0x57/0xc0 do_one_initcall+0x4d/0x323 do_init_module+0x5b/0x1f8 load_module+0x20e5/0x2ac0 __do_sys_finit_module+0xb7/0xd0 do_syscall_64+0x60/0x1b0 entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #1 (&dev->mode_config.mutex){+.+.}: drm_setup_crtcs+0x10c/0xc90 [drm_kms_helper] __drm_fb_helper_initial_config_and_unlock+0x29/0x480 [drm_kms_helper] nouveau_fbcon_init+0x138/0x1a0 [nouveau] nouveau_drm_load+0x173/0x7e0 [nouveau] drm_dev_register+0x134/0x1c0 [drm] drm_get_pci_dev+0x8e/0x160 [drm] nouveau_drm_probe+0x1a9/0x230 [nouveau] pci_device_probe+0xcd/0x150 driver_probe_device+0x30b/0x480 __driver_attach+0xbc/0xe0 bus_for_each_dev+0x67/0x90 bus_add_driver+0x164/0x260 driver_register+0x57/0xc0 do_one_initcall+0x4d/0x323 do_init_module+0x5b/0x1f8 load_module+0x20e5/0x2ac0 __do_sys_finit_module+0xb7/0xd0 do_syscall_64+0x60/0x1b0 entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #0 (&helper->lock){+.+.}: __mutex_lock+0x70/0x9d0 drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper] nv50_mstm_register_connector+0x2c/0x50 [nouveau] drm_dp_add_port+0x2f5/0x420 [drm_kms_helper] drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper] drm_dp_add_port+0x33f/0x420 [drm_kms_helper] drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper] drm_dp_check_and_send_link_address+0x87/0xd0 [drm_kms_helper] drm_dp_mst_link_probe_work+0x4d/0x80 [drm_kms_helper] process_one_work+0x20d/0x650 worker_thread+0x3a/0x390 kthread+0x11e/0x140 ret_from_fork+0x3a/0x50 other info that might help us debug this: Chain exists of: &helper->lock --> crtc_ww_class_acquire --> crtc_ww_class_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(crtc_ww_class_mutex); lock(crtc_ww_class_acquire); lock(crtc_ww_class_mutex); lock(&helper->lock); *** DEADLOCK *** 5 locks held by kworker/1:0/18: #0: 000000004a05cd50 ((wq_completion)"events_long"){+.+.}, at: process_one_work+0x187/0x650 #1: 00000000601c11d1 ((work_completion)(&mgr->work)){+.+.}, at: process_one_work+0x187/0x650 #2: 00000000586ca0df (&dev->mode_config.mutex){+.+.}, at: drm_modeset_lock_all+0x3a/0x1b0 [drm] #3: 00000000d3ca0ffa (crtc_ww_class_acquire){+.+.}, at: drm_modeset_lock_all+0x44/0x1b0 [drm] #4: 00000000942e28e2 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_backoff+0x8e/0x1c0 [drm] stack backtrace: CPU: 1 PID: 18 Comm: kworker/1:0 Tainted: G O 4.17.0-rc3Lyude-Test+ #1 Hardware name: Gateway FX6840/FX6840, BIOS P01-A3 05/17/2010 Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] Call Trace: dump_stack+0x85/0xcb print_circular_bug.isra.38+0x1ce/0x1db __lock_acquire+0x128f/0x1350 ? lock_acquire+0x9f/0x200 ? lock_acquire+0x9f/0x200 ? __ww_mutex_lock.constprop.13+0x8f/0x1000 lock_acquire+0x9f/0x200 ? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper] ? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper] __mutex_lock+0x70/0x9d0 ? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper] ? ww_mutex_lock+0x43/0x80 ? _cond_resched+0x15/0x30 ? ww_mutex_lock+0x43/0x80 ? drm_modeset_lock+0xb2/0x130 [drm] ? drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper] drm_fb_helper_add_one_connector+0x2a/0x60 [drm_kms_helper] nv50_mstm_register_connector+0x2c/0x50 [nouveau] drm_dp_add_port+0x2f5/0x420 [drm_kms_helper] ? mark_held_locks+0x50/0x80 ? kfree+0xcf/0x2a0 ? drm_dp_check_mstb_guid+0xd6/0x120 [drm_kms_helper] ? trace_hardirqs_on_caller+0xed/0x180 ? drm_dp_check_mstb_guid+0xd6/0x120 [drm_kms_helper] drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper] drm_dp_add_port+0x33f/0x420 [drm_kms_helper] ? nouveau_connector_aux_xfer+0x7c/0xb0 [nouveau] ? find_held_lock+0x2d/0x90 ? drm_dp_dpcd_access+0xd9/0xf0 [drm_kms_helper] ? __mutex_unlock_slowpath+0x3b/0x280 ? drm_dp_dpcd_access+0xd9/0xf0 [drm_kms_helper] drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper] drm_dp_check_and_send_link_address+0x87/0xd0 [drm_kms_helper] drm_dp_mst_link_probe_work+0x4d/0x80 [drm_kms_helper] process_one_work+0x20d/0x650 worker_thread+0x3a/0x390 ? process_one_work+0x650/0x650 kthread+0x11e/0x140 ? kthread_create_worker_on_cpu+0x50/0x50 ret_from_fork+0x3a/0x50 Taking example from i915, the only time we need to hold any modesetting locks is when changing the port on the mstc, and in that case we only need to hold the connection mutex. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-10drm/nouveau/ttm: don't dereference nvbo::cli, it can outlive clientBen Skeggs3-6/+3
Potentially responsible for some random OOPSes. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org [v4.15+]
2018-05-10agp: uninorth: make two functions staticMathieu Malaterre1-2/+2
Both ‘uninorth_remove_memory’ and ‘null_cache_flush’ can be made static. So make them. Silence the following gcc warning (W=1): drivers/char/agp/uninorth-agp.c:198:5: warning: no previous prototype for ‘uninorth_remove_memory’ [-Wmissing-prototypes] and drivers/char/agp/uninorth-agp.c:473:6: warning: no previous prototype for ‘null_cache_flush’ [-Wmissing-prototypes] Signed-off-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2018-05-09drm/amd/pp: Refine the output of pp_power_profile_mode on VIRex Zhu2-30/+23
In order to keep consist with Vega, the output format of the pp_power_profile_mode would be <integer><mode name string>< “*” for current profile>:"detail settings" and remove the "CURRENT" mode line. for example: NUM MODE_NAME SCLK_UP_HYST SCLK_DOWN_HYST SCLK_ACTIVE_LEVEL MCLK_UP_HYST MCLK_DOWN_HYST MCLK_ACTIVE_LEVEL 0 3D_FULL_SCREEN: 0 100 30 0 100 10 1 POWER_SAVING: 10 0 30 - - - 2 VIDEO: - - - 10 16 31 3 VR: 0 11 50 0 100 10 4 COMPUTE: 0 5 30 - - - 5 CUSTOM *: 0 5 30 0 100 10 NUM MODE_NAME SCLK_UP_HYST SCLK_DOWN_HYST SCLK_ACTIVE_LEVEL MCLK_UP_HYST MCLK_DOWN_HYST MCLK_ACTIVE_LEVEL 0 3D_FULL_SCREEN: 0 100 30 0 100 10 1 POWER_SAVING *: 10 0 30 0 100 10 2 VIDEO: - - - 10 16 31 3 VR: 0 11 50 0 100 10 4 COMPUTE: 0 5 30 - - - 5 CUSTOM: - - - - - - Reviewed-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-09drm/amdgpu: Switch to interruptable wait to recover from ring hang.Andrey Grodzovsky1-2/+4
v2: Use dma_fence_wait instead of dma_fence_wait_timeout(...,MAX_SCHEDULE_TIMEOUT) Avoid printing error message for ERESTARTSYS Originally-by: David Panariti <David.Panariti@amd.com> Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-09drm/ttm: Use GFP_TRANSHUGE_LIGHT for allocating huge pagesMichel Dänzer2-4/+10
GFP_TRANSHUGE tries very hard to allocate huge pages, which can result in long delays with high memory pressure. I have observed firefox freezing for up to around a minute due to this while restic was taking a full system backup. Since we don't really need huge pages, use GFP_TRANSHUGE_LIGHT | __GFP_NORETRY instead, in order to fail quickly when there are no huge pages available. Set __GFP_KSWAPD_RECLAIM as well, in order for huge pages to be freed up in the background if necessary. With these changes, I'm no longer seeing freezes during a restic backup. Cc: stable@vger.kernel.org Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-09drm/amd/display: Use kvzalloc for potentially large allocationsMichel Dänzer2-41/+45
Allocating up to 32 physically contiguous pages can easily fail (and has failed for me), and isn't necessary anyway. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-09drm/amd/display: Don't return ddc result and read_bytes in same return valueHarry Wentland3-13/+22
The two ranges overlap. Signed-off-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-09drm/amd/display: Add get_firmware_info_v3_2 for VG12Harry Wentland1-1/+85
Signed-off-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-09drm/amd: Add BIOS smu_info v3_3 required struct def.Jerry (Fangzhi) Zuo1-2/+168
Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-09drm/amd/display: Add VG12 ASIC IDsHarry Wentland1-2/+7
Signed-off-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-09arm64: capabilities: Add NVIDIA Denver CPU to bp_harden listDavid Gilhooley1-0/+1
The NVIDIA Denver CPU also needs a PSCI call to harden the branch predictor. Signed-off-by: David Gilhooley <dgilhooley@nvidia.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-05-09arm64: Add MIDR encoding for NVIDIA CPUsDavid Gilhooley1-0/+6
This patch adds the MIDR encodings for NVIDIA as well as the Denver and Carmel CPUs used in Tegra SoCs. Signed-off-by: David Gilhooley <dgilhooley@nvidia.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-05-09HID: i2c-hid: Add RESEND_REPORT_DESCR quirk for Toshiba Click Mini L9W-BHans de Goede2-0/+3
The 0457:10fb touchscreen found on the Toshiba Click Mini L9W-B needs to have a report-decriptors command send to it on resume in order for the touchscreen to start generating events again on resume. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2018-05-09PCI / PM: Always check PME wakeup capability for runtime wakeup supportKai Heng Feng1-4/+4
USB controller ASM1042 stops working after commit de3ef1eb1cd0 (PM / core: Drop run_wake flag from struct dev_pm_info). The device in question is not power managed by platform firmware, furthermore, it only supports PME# from D3cold: Capabilities: [78] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot-,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Before commit de3ef1eb1cd0, the device never gets runtime suspended. After that commit, the device gets runtime suspended to D3hot, which can not generate any PME#. usb_hcd_pci_probe() unconditionally calls device_wakeup_enable(), hence device_can_wakeup() in pci_dev_run_wake() always returns true. So pci_dev_run_wake() needs to check PME wakeup capability as its first condition. In addition, change wakeup flag passed to pci_target_state() from false to true, because we want to find the deepest state different from D3cold that the device can still generate PME#. In this case, it's D0 for the device in question. Fixes: de3ef1eb1cd0 (PM / core: Drop run_wake flag from struct dev_pm_info) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: 4.13+ <stable@vger.kernel.org> # 4.13+ Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-09cpufreq: schedutil: Avoid using invalid next_freqRafael J. Wysocki1-1/+2
If the next_freq field of struct sugov_policy is set to UINT_MAX, it shouldn't be used for updating the CPU frequency (this is a special "invalid" value), but after commit b7eaf1aab9f8 (cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely) it may be passed as the new frequency to sugov_update_commit() in sugov_update_single(). Fix that by adding an extra check for the special UINT_MAX value of next_freq to sugov_update_single(). Fixes: b7eaf1aab9f8 (cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely) Reported-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 4.12+ <stable@vger.kernel.org> # 4.12+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-09cpufreq: schedutil: remove stale commentJuri Lelli1-13/+0
After commit 794a56ebd9a57 (sched/cpufreq: Change the worker kthread to SCHED_DEADLINE) schedutil kthreads are "ignored" for a clock frequency selection point of view, so the potential corner case for RT tasks is not possible at all now. Remove the stale comment mentioning it. Signed-off-by: Juri Lelli <juri.lelli@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-09PM: docs: intel_pstate: fix Active Mode w/o HWP paragraphJuri Lelli1-1/+1
P-state selection algorithm (powersave or performance) is selected by echoing the desired choice to scaling_governor sysfs attribute and not to scaling_cur_freq (as currently stated). Fix it. Signed-off-by: Juri Lelli <juri.lelli@redhat.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-09PM: docs: sleep-states: Fix a typo ("includig")Jonathan Neuschäfer1-1/+1
Fix a typo in admin-guide/pm/sleep-states.rst. Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-09drm/vc4: Fix scaling of uni-planar formatsBoris Brezillon1-1/+1
When using uni-planar formats (like RGB), the scaling parameters are stored in plane 0, not plane 1. Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.") Cc: stable@vger.kernel.org Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20180507121303.5610-1-boris.brezillon@bootlin.com
2018-05-09drm/exynos: hdmi: avoid duplicating drm_bridge_attachPeter Rosin1-2/+0
drm_bridge_attach takes care of these assignments, so there is no need to open-code them a second time. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2018-05-08drm/i915: Fix drm:intel_enable_lvds ERROR message in kernel logFlorent Flament1-1/+2
Fix `[drm:intel_enable_lvds] *ERROR* timed out waiting for panel to power on` in kernel log at boot time. Toshiba Satellite Z930 laptops needs between 1 and 2 seconds to power on its screen during Intel i915 DRM initialization. This currently results in a `[drm:intel_enable_lvds] *ERROR* timed out waiting for panel to power on` message appearing in the kernel log during boot time and when stopping the machine. This change increases the timeout of the `intel_enable_lvds` function from 1 to 5 seconds, letting enough time for the Satellite 930 LCD screen to power on, and suppressing the error message from the kernel log. This patch has been successfully tested on Linux 4.14 running on a Toshiba Satellite Z930. [vsyrjala: bump the timeout from 2 to 5 seconds to match the DP code and properly cover the max hw timeout of ~4 seconds, and drop the comment about the specific machine since this is not a particulary surprising issue, nor specific to that one machine] Signed-off-by: Florent Flament <contact@florentflament.com> Cc: stable@vger.kernel.org Cc: Pavel Petrovic <ppetrovic@acm.org> Cc: Sérgio M. Basto <sergio@serjux.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103414 References: https://bugzilla.kernel.org/show_bug.cgi?id=57591 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180419160700.19828-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 280b54ade5914d3b4abe4f0ebe083ddbd4603246) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-05-08drm/i915: Correctly populate user mode h/vdisplay with pipe src size during readoutVille Syrjälä1-0/+2
During state readout we first read out the pipe src size, store that information in the user mode h/vdisplay, but later on we overwrite that with the actual crtc timings. That makes our read out crtc state inconsistent with itself when the BIOS has enabled the panel fitter to scale the pipe contents. Let's preserve the pipe src size based information in the user mode to make things consistent again. This fixes a problem introduced by commit a2936e3d9a9c ("drm/i915: Use drm_mode_get_hv_timing() to populate plane clip rectangle") where the inconsistent state is now leading the plane clipping code to report a failure on account the plane dst coordinates not matching the user mode size. Previously we did the plane clipping based on the pipe src size instead and thus never noticed the inconsistency. The failure manifests as a WARN: [ 0.762117] [drm:intel_dump_pipe_config [i915]] requested mode: [ 0.762142] [drm:drm_mode_debug_printmodeline [drm]] Modeline 0:"1366x768" 60 72143 1366 1414 1446 1526 768 771 777 784 0x40 0xa ... [ 0.762327] [drm:intel_dump_pipe_config [i915]] port clock: 72143, pipe src size: 1024x768, pixel rate 72143 ... [ 0.764666] [drm:drm_atomic_helper_check_plane_state [drm_kms_helper]] Plane must cover entire CRTC [ 0.764690] [drm:drm_rect_debug_print [drm]] dst: 1024x768+0+0 [ 0.764711] [drm:drm_rect_debug_print [drm]] clip: 1366x768+0+0 [ 0.764713] ------------[ cut here ]------------ [ 0.764714] Could not determine valid watermarks for inherited state [ 0.764792] WARNING: CPU: 4 PID: 159 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3ce/0x19d0 [i915] ... Cc: FadeMind <fademind@gmail.com> Cc: Dave Jones <davej@codemonkey.org.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reported-by: FadeMind <fademind@gmail.com> Reported-by: Dave Jones <davej@codemonkey.org.uk> Tested-by: Dave Jones <davej@codemonkey.org.uk> References: https://lists.freedesktop.org/archives/intel-gfx/2018-April/163186.html Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105992 Fixes: a2936e3d9a9c ("drm/i915: Use drm_mode_get_hv_timing() to populate plane clip rectangle") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180426163015.14232-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Tested-by: FadeMind <fademind@gmail.com> (cherry picked from commit bd4cd03c81010dcd4e6f0e02e4c15f44aefe12d1) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-05-08drm/i915: Adjust eDP's logical vco in a reliable place.Rodrigo Vivi2-24/+37
On intel_dp_compute_config() we were calculating the needed vco for eDP on gen9 and we stashing it in intel_atomic_state.cdclk.logical.vco However few moments later on intel_modeset_checks() we fully replace entire intel_atomic_state.cdclk.logical with dev_priv->cdclk.logical fully overwriting the logical desired vco for eDP on gen9. So, with wrong VCO value we end up with wrong desired cdclk, but also it will raise a lot of WARNs: On gen9, when we read CDCLK_CTL to verify if we configured properly the desired frequency the CD Frequency Select bits [27:26] == 10b can mean 337.5 or 308.57 MHz depending on the VCO. So if we have wrong VCO value stashed we will believe the frequency selection didn't stick and start to raise WARNs of cdclk mismatch. [ 42.857519] [drm:intel_dump_cdclk_state [i915]] Changing CDCLK to 308571 kHz, VCO 8640000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0 [ 42.897269] cdclk state doesn't match! [ 42.901052] WARNING: CPU: 5 PID: 1116 at drivers/gpu/drm/i915/intel_cdclk.c:2084 intel_set_cdclk+0x5d/0x110 [i915] [ 42.938004] RIP: 0010:intel_set_cdclk+0x5d/0x110 [i915] [ 43.155253] WARNING: CPU: 5 PID: 1116 at drivers/gpu/drm/i915/intel_cdclk.c:2084 intel_set_cdclk+0x5d/0x110 [i915] [ 43.170277] [drm:intel_dump_cdclk_state [i915]] [hw state] 337500 kHz, VCO 8100000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0 [ 43.182566] [drm:intel_dump_cdclk_state [i915]] [sw state] 308571 kHz, VCO 8640000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0 v2: Move the entire eDP's vco logical adjustment to inside the skl_modeset_calc_cdclk as suggested by Ville. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: bb0f4aab0e76 ("drm/i915: Track full cdclk state for the logical and actual cdclk frequencies") Cc: <stable@vger.kernel.org> # v4.12+ Link: https://patchwork.freedesktop.org/patch/msgid/20180502175255.5344-1-rodrigo.vivi@intel.com (cherry picked from commit 3297234a05ab1e90091b0574db4c397ef0e90d5f) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-05-08powerpc/pseries: Fix CONFIG_NUMA=n buildMichael Ellerman1-8/+5
The build is failing with CONFIG_NUMA=n and some compiler versions: arch/powerpc/platforms/pseries/hotplug-cpu.o: In function `dlpar_online_cpu': hotplug-cpu.c:(.text+0x12c): undefined reference to `timed_topology_update' arch/powerpc/platforms/pseries/hotplug-cpu.o: In function `dlpar_cpu_remove': hotplug-cpu.c:(.text+0x400): undefined reference to `timed_topology_update' Fix it by moving the empty version of timed_topology_update() into the existing #ifdef block, which has the right guard of SPLPAR && NUMA. Fixes: cee5405da402 ("powerpc/hotplug: Improve responsiveness of hotplug change") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-05-07x86/xen: Reset VCPU0 info pointer after shared_info remapvan der Linden, Frank1-0/+13
This patch fixes crashes during boot for HVM guests on older (pre HVM vector callback) Xen versions. Without this, current kernels will always fail to boot on those Xen versions. Sample stack trace: BUG: unable to handle kernel paging request at ffffffffff200000 IP: __xen_evtchn_do_upcall+0x1e/0x80 PGD 1e0e067 P4D 1e0e067 PUD 1e10067 PMD 235c067 PTE 0 Oops: 0002 [#1] SMP PTI Modules linked in: CPU: 0 PID: 512 Comm: kworker/u2:0 Not tainted 4.14.33-52.13.amzn1.x86_64 #1 Hardware name: Xen HVM domU, BIOS 3.4.3.amazon 11/11/2016 task: ffff88002531d700 task.stack: ffffc90000480000 RIP: 0010:__xen_evtchn_do_upcall+0x1e/0x80 RSP: 0000:ffff880025403ef0 EFLAGS: 00010046 RAX: ffffffff813cc760 RBX: ffffffffff200000 RCX: ffffc90000483ef0 RDX: ffff880020540a00 RSI: ffff880023c78000 RDI: 000000000000001c RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff880025403f5c R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880025400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffff200000 CR3: 0000000001e0a000 CR4: 00000000000006f0 Call Trace: <IRQ> do_hvm_evtchn_intr+0xa/0x10 __handle_irq_event_percpu+0x43/0x1a0 handle_irq_event_percpu+0x20/0x50 handle_irq_event+0x39/0x60 handle_fasteoi_irq+0x80/0x140 handle_irq+0xaf/0x120 do_IRQ+0x41/0xd0 common_interrupt+0x7d/0x7d </IRQ> During boot, the HYPERVISOR_shared_info page gets remapped to make it work with KASLR. This means that any pointer derived from it needs to be adjusted. The only value that this applies to is the vcpu_info pointer for VCPU 0. For PV and HVM with the callback vector feature, this gets done via the smp_ops prepare_boot_cpu callback. Older Xen versions do not support the HVM callback vector, so there is no Xen-specific smp_ops set up in that scenario. So, the vcpu_info pointer for VCPU 0 never gets set to the proper value, and the first reference of it will be bad. Fix this by resetting it immediately after the remap. Signed-off-by: Frank van der Linden <fllinden@amazon.com> Reviewed-by: Eduardo Valentin <eduval@amazon.com> Reviewed-by: Alakesh Haloi <alakeshh@amazon.com> Reviewed-by: Vallish Vaidyeshwara <vallish@amazon.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: xen-devel@lists.xenproject.org Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2018-05-07Fix typo in comment.Florian La Roche1-1/+1
CONFIG_PRREMPT -> CONFIG_PREEMPT Signed-off-by: Florian La Roche <Florian.LaRoche@googlemail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.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-07drm/bridge/sii8620: add Kconfig dependency on extconAndrzej Hajda1-0/+1
The driver can work with or without extcon framework, but if extcon is build as module, sii8620 should be build as module as well. Fixes: 688838442147 ("drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180409062708.4326-1-a.hajda@samsung.com Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-05-07drm/omap: handle alloc failures in omap_connectorTomi Valkeinen1-0/+10
Handle memory allocation failures in omap_connector to avoid NULL derefs. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180502091159.7071-5-tomi.valkeinen@ti.com Reviewed-by: Benoit Parrot <bparrot@ti.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-05-07drm/omap: add missing linefeeds to printsTomi Valkeinen1-7/+7
A bunch of debug and error prints are missing linefeeds. Add those. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180502091159.7071-4-tomi.valkeinen@ti.com Reviewed-by: Benoit Parrot <bparrot@ti.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-05-07drm/omap: handle error if scale coefs are not foundTomi Valkeinen1-0/+6
If get_scale_coef functions fail, they return NULL, but we never check the return value and could do a NULL deref. This should not happen as we ought to validate the amount of scaling already earlier, but to be safe, add the necessary check. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180502091159.7071-3-tomi.valkeinen@ti.com Reviewed-by: Benoit Parrot <bparrot@ti.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-05-07drm/omap: check return value from soc_device_matchTomi Valkeinen1-1/+6
soc_device_match() can return NULL, so add a check and fail if soc_device_match() fails. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180502091159.7071-2-tomi.valkeinen@ti.com Reviewed-by: Benoit Parrot <bparrot@ti.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-05-07drm/omap: fix possible NULL ref issue in tiler_reserve_2dTomi Valkeinen1-1/+5
tiler_reserve_2d allocates memory but does not check if it got the memory. Add the check and return ENOMEM on failure. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180329104038.29154-2-tomi.valkeinen@ti.com Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-05-07drm/omap: fix uninitialized ret variableTomi Valkeinen2-2/+2
audio_config function for both HDMI4 and HDMI5 return uninitialized value as the error code if the display is not currently enabled. For some reason this has not caused any issues. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180329104038.29154-1-tomi.valkeinen@ti.com Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-05-07drm/omap: silence unititialized variable warningDan Carpenter1-1/+1
Smatch complains that "area_free" could be used without being initialized. This code is several years old and premusably works fine so this can't be a very serious bug. But it's easy enough to silence the warning. If "area_free" is false at the end of the function then we return -ENOMEM. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180418142937.GA13828@mwanda Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-05-07drm/vc4: Fix oops dereferencing DPI's connector since panel_bridge.Eric Anholt1-3/+22
In the cleanup, I didn't notice that we needed to dereference the connector for the bus_format. Fix the regression by looking up the first (and only) connector attached to us, and assume that its bus_format is what we want. Some day it would be good to have that part of display_info attached to the bridge, instead. v2: Fix stray whitespace change Signed-off-by: Eric Anholt <eric@anholt.net> Fixes: 7b1298e05310 ("drm/vc4: Switch DPI to using the panel-bridge helper.") Link: https://patchwork.freedesktop.org/patch/msgid/20180309233256.1667-1-eric@anholt.net Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-05-07drm/atomic: Clean private obj old_state/new_state in drm_atomic_state_default_clear()Ville Syrjälä1-0/+2
Clear the old_state and new_state pointers for private objects in drm_atomic_state_default_clear(). We don't actually have functions to get the new/old state for private objects so getting access to the potentially stale pointers requires a bit more manual labour than for other object types. But let's clear the pointers for private objects as well, if only to avoid future surprises when someone decides to add the functions to get at them. v2: Split private objs to a separate patch (Daniel) Cc: <stable@vger.kernel.org> # v4.14+ Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Abhay Kumar <abhay.kumar@intel.com> Fixes: a4370c777406 (drm/atomic: Make private objs proper objects) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180502183247.5746-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-05-07drm/atomic: Clean old_state/new_state in drm_atomic_state_default_clear()Ville Syrjälä1-0/+6
Clear the old_state and new_state pointers for every object in drm_atomic_state_default_clear(). Otherwise drm_atomic_get_{new,old}_*_state() will hand out stale pointers to anyone who hasn't first confirmed that the object is in fact part of the current atomic transcation, if they are called after we've done the ww backoff dance while hanging on to the same drm_atomic_state. For example, handle_conflicting_encoders() looks like it could hit this since it iterates the full connector list and just calls drm_atomic_get_new_connector_state() for each. And I believe we have now witnessed this happening at least once in i915 check_digital_port_conflicts(). Commit 8b69449d2663 ("drm/i915: Remove last references to drm_atomic_get_existing* macros") changed the safe drm_atomic_get_existing_connector_state() to the unsafe drm_atomic_get_new_connector_state(), which opened the doors for this particular bug there as well. v2: Split private objs out to a separate patch (Daniel) Cc: stable@vger.kernel.org Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Abhay Kumar <abhay.kumar@intel.com> Fixes: 581e49fe6b41 ("drm/atomic: Add new iterators over all state, v3.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180502183247.5746-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-05-07powerpc/trace/syscalls: Update syscall name matching logic to account for ppc_ prefixNaveen N. Rao1-2/+19
Some syscall entry functions on powerpc are prefixed with ppc_/ppc32_/ppc64_ rather than the usual sys_/__se_sys prefix. fork(), clone(), swapcontext() are some examples of syscalls with such entry points. We need to match against these names when initializing ftrace syscall tracing. Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-05-07powerpc/trace/syscalls: Update syscall name matching logicNaveen N. Rao1-7/+3
On powerpc64 ABIv1, we are enabling syscall tracing for only ~20 syscalls. This is due to commit e145242ea0df6 ("syscalls/core, syscalls/x86: Clean up syscall stub naming convention") which has changed the syscall entry wrapper prefix from "SyS" to "__se_sys". Update the logic for ABIv1 to not just skip the initial dot, but also the "__se_sys" prefix. Fixes: commit e145242ea0df6 ("syscalls/core, syscalls/x86: Clean up syscall stub naming convention") Reported-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-05-07powerpc/64: Remove unused paca->soft_enabledMichael Ellerman1-1/+0
In commit 4e26bc4a4ed6 ("powerpc/64: Rename soft_enabled to irq_soft_mask") we renamed paca->soft_enabled. But then in commit 8e0b634b1327 ("powerpc/64s: Do not allocate lppaca if we are not virtualized") we added it back. Oops. This happened because the two patches were in flight at the same time and rebased vs each other multiple times, and we missed it in review. Fixes: 8e0b634b1327 ("powerpc/64s: Do not allocate lppaca if we are not virtualized") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-05-06Linux 4.17-rc4Linus Torvalds1-2/+2
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.