Re: [RFC PATCH] mm, oom: introduce vm.sacrifice_hugepage_on_oom

Hi Michal > On Feb 17, 2021, at 21:31, Michal Hocko wrote: > > On Wed 17-02-21 10:42:24, Eiichi Tsukata wrote: >> Hi All, >> >> Firstly, thank you for your careful review and attention to my patch >> (and apologies for top-posting!). Let me first explain why

Re: [RFC PATCH] mm, oom: introduce vm.sacrifice_hugepage_on_oom

Hi All, Firstly, thank you for your careful review and attention to my patch (and apologies for top-posting!). Let me first explain why our use case requires hugetlb over THP and then elaborate on the difficulty we have to maintain the correct number of hugepages in the pool, finally concluding w

[RFC PATCH] mm, oom: introduce vm.sacrifice_hugepage_on_oom

ot to change the current behavior. Signed-off-by: Eiichi Tsukata --- Documentation/admin-guide/sysctl/vm.rst | 12 include/linux/hugetlb.h | 2 ++ include/linux/oom.h | 1 + kernel/sysctl.c | 9 + mm/huge

Re: [PATCH] xfs: Fix UBSAN null-ptr-deref in xfs_sysfs_init

Thanks, I sent it to linux-xfs ML. I had some trouble with gmail server. Eiichi On 2020/08/07 0:13, Darrick J. Wong wrote: > On Fri, Aug 07, 2020 at 12:05:27AM +0900, Eiichi Tsukata wrote: >> If xfs_sysfs_init is called with parent_kobj == NULL, UBSAN >> shows the following war

[PATCH] xfs: Fix UBSAN null-ptr-deref in xfs_sysfs_init

arent_kobj before the code accesses its member. Signed-off-by: Eiichi Tsukata --- fs/xfs/xfs_sysfs.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_sysfs.h b/fs/xfs/xfs_sysfs.h index e9f810fc6731..aad67dc4ab5b 100644 --- a/fs/xfs/xfs_sysfs.h +++ b/fs/xfs/x

[PATCH] xfs: Fix UBSAN null-ptr-deref in xfs_sysfs_init

arent_kobj before the code accesses its member. Signed-off-by: Eiichi Tsukata --- fs/xfs/xfs_sysfs.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_sysfs.h b/fs/xfs/xfs_sysfs.h index e9f810fc6731..aad67dc4ab5b 100644 --- a/fs/xfs/xfs_sysfs.h +++ b/fs/xfs/x

[PATCH] xfs: Fix UBSAN null-ptr-deref in xfs_sysfs_init

arent_kobj before the code accesses its member. Signed-off-by: Eiichi Tsukata --- fs/xfs/xfs_sysfs.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_sysfs.h b/fs/xfs/xfs_sysfs.h index e9f810fc6731..aad67dc4ab5b 100644 --- a/fs/xfs/xfs_sysfs.h +++ b/fs/xfs/x

Re: [RFC PATCH] KVM: x86: Fix APIC page invalidation race

> On Jun 9, 2020, at 18:54, Paolo Bonzini wrote: > > > No need to resend, the patch is good. Here is my take on the commit message: Thank you Paolo! Your commit message is much clearer. I really appreciate your great job. Best Eiichi > >Commit b1394e745b94 ("KVM: x86: fix APIC page

Re: [RFC PATCH] KVM: x86: Fix APIC page invalidation race

> On Jun 8, 2020, at 22:13, Paolo Bonzini wrote: > > On 06/06/20 06:26, Eiichi Tsukata wrote: >> Commit b1394e745b94 ("KVM: x86: fix APIC page invalidation") tried to >> fix inappropriate APIC page invalidation by re-introducing arch specific >> kvm_arc

Re: [RFC PATCH] KVM: x86: Fix APIC page invalidation race

return 0; } ``` Steps to Reproduce: - start Windows VM(ex: Windows Server 2016) and watch YouTube video to stimulate VM_ENTER/EXIT - ’stress —vm X —vm-bytes Y’ to make the APIC page swapped out - Windows OS will crash with BugCheck 0x109 Thanks, Eiichi > On Jun 6, 2020, at 13:2

[RFC PATCH] KVM: x86: Fix APIC page invalidation race

date_range() instead of ..._range_start(). Fixes: b1394e745b94 ("KVM: x86: fix APIC page invalidation") Signed-off-by: Eiichi Tsukata --- arch/x86/kvm/x86.c | 7 ++- include/linux/kvm_host.h | 4 ++-- virt/kvm/kvm_main.c | 26 -- 3 files changed,

Re: [PATCH] tracing: Prevent RCU EQS breakage in preemptirq events

Thanks for comments. On 2019/07/30 0:21, Steven Rostedt wrote: > On Mon, 29 Jul 2019 10:07:34 +0900 > Eiichi Tsukata wrote: > >> If context tracking is enabled, causing page fault in preemptirq >> irq_enable or irq_disable events triggers the following RCU EQS warn

Re: [PATCH] tracing: Prevent RCU EQS breakage in preemptirq events

Thanks for comments. On 2019/07/29 19:29, Peter Zijlstra wrote: > On Sun, Jul 28, 2019 at 09:25:58PM -0700, Andy Lutomirski wrote: >> On Sun, Jul 28, 2019 at 6:08 PM Eiichi Tsukata wrote: > >>> diff --git a/kernel/trace/trace_preemptirq.c >>> b/kernel/trac

Re: [PATCH] sched/core: Remove the unused schedule_user() function

On 2019/07/29 17:30, Qais Yousef wrote: > On 07/28/19 01:55, Eiichi Tsukata wrote: >> Since commit 02bc7768fe44 ("x86/asm/entry/64: Migrate error and IRQ exit >> work to C and remove old assembly code"), it's no longer used. > > It seems to me that

[PATCH] tracing: Prevent RCU EQS breakage in preemptirq events

(then we need to tell lockdep that IRQs are off eariler) and calling prepare_exit_to_usermode() after TRACE_IRQS_ON. But this patch will be much simpler and limit the most change to tracing codes. Fixes: 865e63b04e9b ("tracing: Add back in rcu_irq_enter/exit_irqson() for rcuidle tracepoints"

[PATCH] sched/core: Remove the unused schedule_user() function

Since commit 02bc7768fe44 ("x86/asm/entry/64: Migrate error and IRQ exit work to C and remove old assembly code"), it's no longer used. Signed-off-by: Eiichi Tsukata --- kernel/sched/core.c | 19 --- 1 file changed, 19 deletions(-) diff --git a/kernel/sched/

[tip:x86/urgent] x86/stacktrace: Prevent access_ok() warnings in arch_stack_walk_user()

Commit-ID: 2af7c85714d8cafadf925d55441458eae312cd6b Gitweb: https://git.kernel.org/tip/2af7c85714d8cafadf925d55441458eae312cd6b Author: Eiichi Tsukata AuthorDate: Mon, 22 Jul 2019 17:32:16 +0900 Committer: Thomas Gleixner CommitDate: Mon, 22 Jul 2019 10:42:36 +0200 x86/stacktrace

[PATCH 1/1] x86/stacktrace: Fix userstacktrace access_ok() WARNING in irq events

handle_irq+0x34/0x40 do_IRQ+0xa6/0x1f0 common_interrupt+0xf/0xf Fix it by calling __range_not_ok() directly instead of access_ok() as copy_from_user_nmi() does. This is fine here because the actual copy is inside a pagefault disabled region. Reported-by: Juri Lelli Signed-off-by: Ei

[PATCH 0/1] x86/stacktrace: Fix userstacktrace access_ok() WARNING in irq events

trace()@arch/x86/oprofile/backtrace.c So for simplicity, I wrote a patch to fix the warning as other codes do. Ideally, we should merge these similar stacktrace codes(perf, ftrace, oprofile) into one, but this time I made the minimum fix. Eiichi Tsukata (1): x86/stacktrace: Fix userstacktrace acce

workqueue: possible deadlock when setting sysfs "debug_force_rr_cpu"

Hello This is just a report for someone who hit the same problem. When setting 1 to sysfs debug_force_rr_cpu can trigger the following LOCKDEP WARNING. Reproducer: # ssh localhost // to use pty # echo 1 > /sys/module/workqueue/parameters/debug_force_rr_cpu This problem is similar to the on

Re: [PATCH v3 0/6] Tracing vs CR2

On 2019/07/20 21:49, Andy Lutomirski wrote: > On Fri, Jul 19, 2019 at 8:59 PM Eiichi Tsukata wrote: >> ... >> >> >> >> debug() // dr6: 0x4ff0, user_mode: 1 >> TRACE_IRQS_OFF >> arch_stack_user_walk() >> deb

Re: [PATCH v3 0/6] Tracing vs CR2

On 2019/07/19 5:27, Andy Lutomirski wrote: > Hi all- > > I suspect that a bunch of the bugs you're all finding boil down to: > > - Nested debug exceptions could corrupt the outer exception's DR6. > - Nested debug exceptions in which *both* exceptions came from the > kernel were probably all k

Re: [PATCH] tracing: Fix user stack trace "??" output

Hello Steven Would you review the patch? On 2019/06/30 17:54, Eiichi Tsukata wrote: > Commit c5c27a0a5838 ("x86/stacktrace: Remove the pointless ULONG_MAX > marker") removes ULONG_MAX marker from user stack trace entries but > trace_user_stack_print() still uses the ma

Re: [PATCH v3 0/6] Tracing vs CR2

On 2019/07/17 6:51, Vegard Nossum wrote: > ... > > Got a different one: > > WARNING: CPU: 0 PID: 2150 at arch/x86/kernel/traps.c:791 do_debug+0xfe/0x240 > CPU: 0 PID: 2150 Comm: init Not tainted 5.2.0+ #124 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > Ubuntu-1.8.2-1ubuntu1

[tip:x86/urgent] x86/stacktrace: Prevent infinite loop in arch_stack_walk_user()

Commit-ID: cbf5b73d162b22e044fe0b7d51dcaa33be065253 Gitweb: https://git.kernel.org/tip/cbf5b73d162b22e044fe0b7d51dcaa33be065253 Author: Eiichi Tsukata AuthorDate: Thu, 11 Jul 2019 11:35:01 +0900 Committer: Thomas Gleixner CommitDate: Thu, 11 Jul 2019 08:22:03 +0200 x86/stacktrace

[PATCH] x86/stacktrace: Fix infinite loop in arch_stack_walk_user()

add support for userspace stacktraces in tracing/iter_ctrl") Signed-off-by: Eiichi Tsukata --- arch/x86/kernel/stacktrace.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/stacktrace.c b/arch/x86/kernel/stacktrace.c index 2abf27d7df6b..b1a1f4b4c943 1

Re: [PATCH v2 5/7] x86/mm, tracing: Fix CR2 corruption

On 2019/07/08 18:42, Eiichi Tsukata wrote: > > > On 2019/07/08 17:58, Eiichi Tsukata wrote: > >> >> By the way, is there possibility that the WARNING(#GP in execve(2)) which >> Steven >> previously hit? : >> https://lore.kernel.org/lkml/

Re: [PATCH v2 5/7] x86/mm, tracing: Fix CR2 corruption

On 2019/07/08 17:58, Eiichi Tsukata wrote: > > By the way, is there possibility that the WARNING(#GP in execve(2)) which > Steven > previously hit? : > https://lore.kernel.org/lkml/20190321095502.47b51...@gandalf.local.home/ > > Even if there were, it will *Not* be

Re: [PATCH v2 5/7] x86/mm, tracing: Fix CR2 corruption

On 2019/07/08 16:48, Peter Zijlstra wrote: ... > > Or are we going to put the CR2 save/restore on every single tracepoint? > But then we also need it on the mcount/fentry stubs and we again have > multiple places. > > Whereas if we stick it in the entry path, like I proposed, we fix it in > o

Re: [PATCH v2 5/7] x86/mm, tracing: Fix CR2 corruption

On 2019/07/07 7:27, Steven Rostedt wrote: > > We also have to deal with reading vmalloc'd data as that can fault too. > The perf ring buffer IIUC is vmalloc, so if perf records in one of > these locations, then the reading of the vmalloc area has a potential > to fault corrupting the CR2 regis

Re: [PATCH v2 5/7] x86/mm, tracing: Fix CR2 corruption

On 2019/07/05 11:18, Linus Torvalds wrote: > On Fri, Jul 5, 2019 at 5:03 AM Peter Zijlstra wrote: >> >> Despire the current efforts to read CR2 before tracing happens there >> still exist a number of possible holes: > > So this whole series disturbs me for the simple reason that I thought > tr

[PATCH] x86/stacktrace: Do not access user space memory unnecessarily

R13: R14: 0004 R15: 55be7b3d3560 Kernel Offset: 0x2a00 from 0x8100 (relocation range: 0x8000-0xbfff) Fixes: 02b67518e2b1 ("tracing: add support for userspace stacktraces in tracing/iter_ctrl") Signed-off-by

Re: [PATCH] tracing: Fix out-of-range read in trace_stack_print()

before that, a ULONG_MAX was inserted into the buffer. > > -- Steve Thank you for the advice. Now there is no ULONG_MAX marker, so I should have fixed it by just removing `*p != ULONG_MAX` check, right? Thanks Eiichi > >> Signed-off-by: Eiichi Tsukata >> --- >> k

[PATCH] tracing: Fix user stack trace "??" output

entry is detected. Fixes: 4285f2fcef80 ("tracing: Remove the ULONG_MAX stack trace hackery") Signed-off-by: Eiichi Tsukata --- kernel/trace/trace_output.c | 9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.

[PATCH net-next] net/ipv6: Fix misuse of proc_dointvec "flowlabel_reflect"

/proc/sys/net/ipv6/flowlabel_reflect assumes written value to be in the range of 0 to 3. Use proc_dointvec_minmax instead of proc_dointvec. Fixes: 323a53c41292 ("ipv6: tcp: enable flowlabel reflection in some RST packets") Signed-off-by: Eiichi Tsukata --- net/ipv6/sysctl_net_ipv6.c

[tip:smp/urgent] cpu/hotplug: Fix out-of-bounds read when setting fail state

Commit-ID: 33d4a5a7a5b4d02915d765064b2319e90a11cbde Gitweb: https://git.kernel.org/tip/33d4a5a7a5b4d02915d765064b2319e90a11cbde Author: Eiichi Tsukata AuthorDate: Thu, 27 Jun 2019 11:47:32 +0900 Committer: Thomas Gleixner CommitDate: Thu, 27 Jun 2019 09:34:04 +0200 cpu/hotplug: Fix

[PATCH] cpu/hotplug: Fix out-of-bounds read when setting fail state

fa fa ^ 89734480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 89734500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Adds sanity check for given value `fail`. Fixes: 1db49484f21ed ("smp/hotplug: Hotplug state fail injection") Signed-off-by: Eiichi Tsukata -

[PATCH] EDAC: Fix global-out-of-bounds write when setting edac_mc_poll_msec

large enough for edac_mc_poll_msec. Fixes: 9da21b1509d8 ("EDAC: Poll timeout cannot be zero, p2") Signed-off-by: Eiichi Tsukata --- drivers/edac/edac_mc_sysfs.c | 16 drivers/edac/edac_module.h | 2 +- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/driv

Re: [PATCH 1/2] tty: ldisc: Fix misuse of proc_dointvec "ldisc_autoload"

On 2019/06/25 12:32, Greg KH wrote: > On Tue, Jun 25, 2019 at 12:08:00PM +0900, Eiichi Tsukata wrote: >> /proc/sys/dev/tty/ldisc_autoload assumes given value to be 0 or 1. Use >> proc_dointvec_minmax instead of proc_dointvec. >> >> Fixes: 7c0cca7c847e "(t

[PATCH 2/2] net/ipv6: Fix misuse of proc_dointvec "skip_notify_on_dev_down"

/proc/sys/net/ipv6/route/skip_notify_on_dev_down assumes given value to be 0 or 1. Use proc_dointvec_minmax instead of proc_dointvec. Fixes: 7c6bb7d2faaf ("net/ipv6: Add knob to skip DELROUTE message ondevice down") Signed-off-by: Eiichi Tsukata --- net/ipv6/route.c | 2 +- 1 file

[PATCH 1/2] tty: ldisc: Fix misuse of proc_dointvec "ldisc_autoload"

/proc/sys/dev/tty/ldisc_autoload assumes given value to be 0 or 1. Use proc_dointvec_minmax instead of proc_dointvec. Fixes: 7c0cca7c847e "(tty: ldisc: add sysctl to prevent autoloading of ldiscs)" Signed-off-by: Eiichi Tsukata --- drivers/tty/tty_ldisc.c | 2 +- 1 file changed, 1

[PATCH] tracing/snapshot: resize spare buffer if size changed

0x1f/0x390 do_syscall_64+0xc1/0x390 entry_SYSCALL_64_after_hwframe+0x49/0xbe This patch adds resize_buffer_duplicate_size() to check if there is a difference between current/spare buffer sizes and resize a spare buffer if necessary. Signed-off-by: Eiichi Tsukata --- kernel/trace/trace.c | 10

[PATCH 1/2] tracing/uprobe: Fix NULL pointer dereference in trace_uprobe_create()

_command+0xf9/0x1eb ? probes_open+0x80/0x80 __vfs_write+0x43/0x90 vfs_write+0x14a/0x2a0 ksys_write+0xa2/0x170 do_syscall_64+0x7f/0x200 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: 0597c49c69d5 ("tracing/uprobes: Use dyn_event framework for uprobe events") Signed-off-by

[PATCH 2/2] tracing/uprobe: Fix obsolete comment on trace_uprobe_create()

Commit 0597c49c69d5 ("tracing/uprobes: Use dyn_event framework for uprobe events") cleaned up the usage of trace_uprobe_create(), and the function has been no longer used for removing uprobe/uretprobe. Signed-off-by: Eiichi Tsukata --- kernel/trace/trace_uprobe.c | 2 -- 1 file

[PATCH] tracing: Fix out-of-range read in trace_stack_print()

fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb == Fixes: 4a9bd3f134dec ("tracing: Have dynamic size event stack traces") Signed-off-by: Eiichi Tsukata --- kernel/trace/trace_output.c | 2 +- 1 file changed, 1 insertion(+

[RESEND PATCH v3] scsi: Add timeout to avoid infinite command retry

: - check retry timeout in scsi_io_completion() instead of scsi_softirq_done() Signed-off-by: Eiichi Tsukata Cc: "James E.J. Bottomley" Cc: linux-s...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/scsi/scsi_lib.c |7 +++ 1 file changed, 7 insertions(+) di

[PATCH v3] scsi: Add timeout to avoid infinite command retry

: - check retry timeout in scsi_io_completion() instead of scsi_softirq_done() Signed-off-by: Eiichi Tsukata Cc: "James E.J. Bottomley" Cc: linux-s...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/scsi/scsi_lib.c |7 +++ 1 file changed, 7 insertions(+) di

Re: Re: [PATCH v2] scsi: Add 'retry_timeout' to avoid infinite command retry

(2014/02/07 15:15), Libo Chen wrote: On 2014/2/7 13:46, James Bottomley wrote: On Fri, 2014-02-07 at 09:22 +0900, Eiichi Tsukata wrote: Currently, scsi error handling in scsi_io_completion() tries to unconditionally requeue scsi command when device keeps some error state. For example

[PATCH v2] scsi: Add 'retry_timeout' to avoid infinite command retry

s/X:X:X:X/retry_timeout Changes in v2: - check retry timeout in scsi_io_completion() instead of scsi_softirq_done() Signed-off-by: Eiichi Tsukata Cc: "James E.J. Bottomley" Cc: linux-s...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/scsi/scsi_lib.c| 22 ++

Re: [REVIEW PATCH] scsi: Add 'retry_timeout' to avoid infinite command retry

(2014/02/06 1:55), James Bottomley wrote: On Wed, 2014-02-05 at 14:47 +0900, Eiichi Tsukata wrote: Currently, scsi error handling in scsi_decide_disposition() tries to unconditionally requeue scsi command when device keeps some error state. This is because retryable errors are thought to be

[REVIEW PATCH] scsi: Add 'retry_timeout' to avoid infinite command retry

'retry_timeout' sysfs attribute which limits the retry time of each scsi command. Once scsi command retry time is longer than this timeout, the command is treated as failure. 'retry_timeout' is set to '0' by default which means no timeout set. Signed-off-by:

[PATCH] scsi: Add printk to detect retry loop

ace application. Here the allowed count(scmd->allowed) is currently used as finite retry limit count. Once retry count exceeds the allowed count on a device, the message is suppressed on the device to avoid too much messages outputted in dmesg. Signed-off-by: Eiichi Tsukata Cc: "James E.J. Bottomley&

[PATCH] scsi: Add printk to detect retry loop

the allowed count(scmd->allowed) is currently used as finite retry limit count. Once retry count exceeds the allowed count on a device, the message is suppressed on the device to avoid too much messages outputted in dmesg. --- Eiichi Tsukata (1): scsi: Add printk to detect retry loop

Re: [RFC PATCH] scsi: Add failfast mode to avoid infinite retry loop

(2013/08/23 21:26), Ric Wheeler wrote: On 08/23/2013 05:10 AM, Eiichi Tsukata wrote: (2013/08/21 3:09), Ewan Milne wrote: On Tue, 2013-08-20 at 16:13 +0900, Eiichi Tsukata wrote: (2013/08/19 23:30), James Bottomley wrote: On Mon, 2013-08-19 at 18:39 +0900, Eiichi Tsukata wrote: Hello, This

Re: [RFC PATCH] scsi: Add failfast mode to avoid infinite retry loop

(2013/08/24 4:36), Ewan Milne wrote: On Fri, 2013-08-23 at 06:19 -0700, James Bottomley wrote: On Fri, 2013-08-23 at 18:10 +0900, Eiichi Tsukata wrote: Yes, basically the device should be offlined on error detection. Just offlining the disk is enough when an error occurs on "not" os

Re: [RFC PATCH] scsi: Add failfast mode to avoid infinite retry loop

(2013/08/23 22:19), James Bottomley wrote: On Fri, 2013-08-23 at 18:10 +0900, Eiichi Tsukata wrote: (2013/08/21 3:09), Ewan Milne wrote: On Tue, 2013-08-20 at 16:13 +0900, Eiichi Tsukata wrote: (2013/08/19 23:30), James Bottomley wrote: On Mon, 2013-08-19 at 18:39 +0900, Eiichi Tsukata wrote

Re: [RFC PATCH] scsi: Add failfast mode to avoid infinite retry loop

(2013/08/21 3:09), Ewan Milne wrote: On Tue, 2013-08-20 at 16:13 +0900, Eiichi Tsukata wrote: (2013/08/19 23:30), James Bottomley wrote: On Mon, 2013-08-19 at 18:39 +0900, Eiichi Tsukata wrote: Hello, This patch adds scsi device failfast mode to avoid infinite retry loop. Currently, scsi

Re: [RFC PATCH] scsi: Add failfast mode to avoid infinite retry loop

(2013/08/19 23:30), James Bottomley wrote: On Mon, 2013-08-19 at 18:39 +0900, Eiichi Tsukata wrote: Hello, This patch adds scsi device failfast mode to avoid infinite retry loop. Currently, scsi error handling in scsi_decide_disposition() and scsi_io_completion() unconditionally retries on

[RFC PATCH] scsi: Add failfast mode to avoid infinite retry loop

some errors but too few on other errors. Which would be the appropriate implementation? Any comments or suggestions are welcome as usual. Signed-off-by: Eiichi Tsukata Cc: "James E.J. Bottomley" Cc: linux-s...@vger.kernel.org Cc: linux-kernel@vger.kernel.org ---