Currently task hung checking period is equal to timeout, as the result hung is detected anywhere between timeout and 2*timeout. This is fine for most interactive environments, but this hurts automated testing setups (syzbot). In an automated setup we need to strictly order CPU lockup < RCU stall < workqueue lockup < task hung < silent loss, so that RCU stall is not detected as task hung and task h

From: Greg Thelen <gthelen@google.com> The dquots in the free_dquots list are not reclaimed in LRU way. put_dquot_last() puts entries to the tail and dqcache_shrink_scan() frees from the tail. Free unreferenced dquots in LRU order because it seems more reasonable than freeing most recently used. Signed-off-by: Greg Thelen <gthelen@google.com> Signed-off-by: Shakeel Butt <shakeelb@google.com> --- f

During the reclaiming slab of a memcg, shrink_slab iterates over all registered shrinkers in the system, and tries to count and consume objects related to the cgroup. In case of memory pressure, this behaves bad: I observe high system time and time spent in list_lru_count_one() for many processes on RHEL7 kernel. This patch makes list_lru_node::memcg_lrus rcu protected, that allows to skip taking

Prevent a task from opening, in "write" mode, any /proc/*/mem file that operates on the task's mm. /proc/*/mem is mainly a debugging means and, as such, it shouldn't be used by the inspected process itself. Current implementation always allow a task to access its own /proc/*/mem file. A process can use it to overwrite read-only memory, making pointless the use of security_file_mprotect() or other

From: Kirill Tkhai <ktkhai@virtuozzo.com> In case of memory deficit and low percpu memory pages, pcpu_balance_workfn() takes pcpu_alloc_mutex for a long time (as it makes memory allocations itself and waits for memory reclaim). If tasks doing pcpu_alloc() are choosen by OOM killer, they can't exit, because they are waiting for the mutex. The patch makes pcpu_alloc() to care about killing signal an

Every current KDE system has process named ksysguardd polling files below once in several seconds: $ strace -e trace=open -p $(pidof ksysguardd) Process 1812 attached open("/etc/mtab", O_RDONLY|O_CLOEXEC) = 8 open("/etc/mtab", O_RDONLY|O_CLOEXEC) = 8 open("/proc/net/dev", O_RDONLY) = 8 open("/proc/net/wireless", O_RDONLY) = -1 ENOENT (No such file or directory) open("/proc/stat", O_RDONLY) = 8 ope

Commit-ID: 5c4991e24c69737bd41fc2737b1e3980abbf73f9 Gitweb: https://git.kernel.org/tip/5c4991e24c69737bd41fc2737b1e3980abbf73f9 Author: Frederic Weisbecker <frederic@kernel.org> AuthorDate: Fri, 27 Oct 2017 04:42:34 +0200 Committer: Ingo Molnar <mingo@kernel.org> CommitDate: Fri, 27 Oct 2017 09:55:28 +0200 sched/isolation: Split out new CONFIG_CPU_ISOLATION=y config from CONFIG_NO_HZ_FULL Split th

From: Darrick J. Wong <darrick.wong@oracle.com> Create an ioctl that can be used to scrub internal filesystem metadata. The new ioctl takes the metadata type, an (optional) AG number, an (optional) inode number and generation, and a flags argument. This will be used by the upcoming XFS online scrub tool. Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> --- fs/xfs/Kconfig | 17 +++++++++++++

Workqueues don't use signals, it (ab)uses TASK_INTERRUPTIBLE to avoid increasing the loadavg numbers. We've 'recently' introduced TASK_IDLE for this case: 80ed87c8a9ca ("sched/wait: Introduce TASK_NOLOAD and TASK_IDLE") use it. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> --- On Wed, Aug 23, 2017 at 01:58:44PM +0200, Peter Zijlstra wrote: > Workqueues don't use signals, it (ab)uses

sometimes, on my server, there were lots of files creating and removing, and I found that memory usage were high, and I checked, almost all the memory was occupied by slab recliamable, the slab struct was dentry, and I checked the code of dcache, and found that when a file was deleted the dentry never free, unless a memory recliam was triggerd. I made this patch to mark the dentry as a remove stat

On Sun, Oct 16, 2016 at 05:56:08PM +0200, Vegard Nossum wrote: > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Ingo Molnar <mingo@redhat.com> > Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> NAK, -ENOCHANGELOG diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index 1ec0f48..22ff6da 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -10,6 +10,7 @@ * *

This config option was apparently disallowed on x86_64 because of problems with the stack unwinder: commit 6d690dcac92a84f98fd774862628ff871b713660 Author: Akinobu Mita <akinobu.mita@gmail.com> Date: Sat May 12 10:36:53 2007 -0700 fault injection: disable stacktrace filter for x86-64 However, I observe no problems whatsoever with this today and in fact it's been very useful for debugging. Let's al

From: Jerome Marchand <jmarchan@redhat.com> It's currently inconvenient to retrieve MM_ANONPAGES value from status and statm files and there is no way to separate MM_FILEPAGES and MM_SHMEMPAGES. Add RssAnon, RssFile and RssShm lines in /proc/<pid>/status to solve these issues. Signed-off-by: Jerome Marchand <jmarchan@redhat.com> Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Konstantin

Commit 4751832da990 ("btrfs: fiemap: Cache and merge fiemap extent before submit it to user") introduced a warning to catch unemitted cached fiemap extent. However such warning doesn't take the following case into consideration: 0 4K 8K |<---- fiemap range --->| |<----------- On-disk extent ------------------>| In this case, the whole 0~8K is cached, and since it's larger than fiemap range, it bre

This is actually inspired by Filipe's patch(55e3bd2e0c2e1). When submit_extent_page() in __extent_writepage_io() fails, Btrfs misses clearing a writeback bit of the failed page. This causes the false under-writeback page. Then, another sync task hangs in filemap_fdatawait_range(), because it waits the false under-writeback page. CPU0 CPU1 __extent_writepage_io() ret = submit_extent_page() // fail

Show patches with: State = Action Required | Archived = No |   478 patches Series Submitter State Search Archived No Yes Both Delegate Apply « 1 2 3 4 … 4 5 » Patch Series A/R/T S/W/F Date Submitter Delegate State [PULL] drm-intel-fixes [PULL] drm-intel-fixes - - - --- 2023-11-30 Jani Nikula New [v8,4/4] drm/i915/display: Split i915 specific code away from intel_fb.c Prepare intel_fb for Xe - - -

This change adds some symbolic constants for VM Exit Qualifications related to EPT Violations and updates handle_ept_violation() to use these constants instead of hard-coded numbers. Signed-off-by: Junaid Shahid <junaids@google.com> --- arch/x86/include/asm/vmx.h | 16 ++++++++++++++++ arch/x86/kvm/vmx.c | 22 ++++++++++++++-------- 2 files changed, 30 insertions(+), 8 deletions(-) On 09/11/2016 00:

[dropped stable ML and add a few other relevant people to Cc] On Thu, 04 Aug 2016 20:05:27 +0200, Takashi Iwai wrote: > > On Thu, 04 Aug 2016 18:44:11 +0200, > Daniel Vetter wrote: > > > > On Wed, Aug 03, 2016 at 05:09:00PM +0100, Chris Wilson wrote: > > > On Haswell/Broadwell, the HD-Audio block is inside the HDMI/display > > > power well and so the sna-hda audio codec acquires the display power

Since accumulate_steal_time is now only called in record_steal_time, it doesn't quite make sense to put the delta calculation in a separate function. The function could be called thousands of times before guest enables the steal time MSR (though the compiler may optimize out this function call). And after it's enabled, the MSR enable bit is tested twice every time. Removing the accumulate_steal_ti