Re: [PATCH v2 1/3] KVM: X86: append vmx/svm prefix to additional kvm_x86_ops functions

On 1/15/21 4:22 AM, Peter Zijlstra wrote: > > On Thu, Jan 14, 2021 at 10:27:54PM -0500, Jason Baron wrote: > >> -static void update_exception_bitmap(struct kvm_vcpu *vcpu) >> +static void svm_update_exception_bitmap(struct kvm_vcpu *vcpu) > > Just to be a tota

Re: [PATCH v2 2/3] KVM: x86: introduce definitions to support static calls for kvm_x86_ops

On 1/15/21 8:50 AM, Paolo Bonzini wrote: > On 15/01/21 10:26, Peter Zijlstra wrote: >>> +#define KVM_X86_OP(func) \ >>> +    DEFINE_STATIC_CALL_NULL(kvm_x86_##func, \ >>> +    *(((struct kvm_x86_ops *)0)->func)); >>> +#define KVM_X86_OP_NULL

[PATCH v2 1/3] KVM: X86: append vmx/svm prefix to additional kvm_x86_ops functions

(), update_cr8_intercept and enable_smi_window(). Cc: Paolo Bonzini Cc: Sean Christopherson Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Peter Zijlstra Cc: Andrea Arcangeli Signed-off-by: Jason Baron --- arch/x86/kvm/svm/svm.c| 20 ++-- arch/x86/kvm/vmx

[PATCH v2 2/3] KVM: x86: introduce definitions to support static calls for kvm_x86_ops

of a performance impact. Cc: Paolo Bonzini Cc: Sean Christopherson Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Peter Zijlstra Cc: Andrea Arcangeli Signed-off-by: Jason Baron --- arch/x86/include/asm/kvm-x86-ops.h | 127 + arch/x86/include/asm/kvm_host.h

[PATCH v2 3/3] KVM: x86: use static calls to reduce kvm_x86_ops overhead

: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Peter Zijlstra Cc: Andrea Arcangeli Cc: Sean Christopherson Signed-off-by: Jason Baron --- arch/x86/include/asm/kvm_host.h | 8 +- arch/x86/kvm/cpuid.c| 2 +- arch/x86/kvm/hyperv.c | 4 +- arch/x86/kvm

[PATCH v2 0/3] Use static_call for kvm_x86_ops

) -add new patch (1/3), that adds a vmx/svm prefix to help facilitate svm_x86_ops and vmx_x86_ops future conversions. -added amd perf numbres to description of patch 3/3 Jason Baron (3): KVM: X86: append vmx/svm prefix to additional kvm_x86_ops functions KVM: x86: introduce definitions to support

Re: [PATCH 1/2] KVM: x86: introduce definitions to support static calls for kvm_x86_ops

On 1/13/21 11:16 AM, Jason Baron wrote: > > > On 1/13/21 7:53 AM, Paolo Bonzini wrote: >> On 11/01/21 17:57, Jason Baron wrote: >>> +#define DEFINE_KVM_OPS_STATIC_CALL(func)    \ >>> +    DEFINE_STATIC_CALL_NULL(kvm_x86_##func,    \ >>> +   

Re: [PATCH 1/2] KVM: x86: introduce definitions to support static calls for kvm_x86_ops

On 1/13/21 7:53 AM, Paolo Bonzini wrote: > On 11/01/21 17:57, Jason Baron wrote: >> +#define DEFINE_KVM_OPS_STATIC_CALL(func)    \ >> +    DEFINE_STATIC_CALL_NULL(kvm_x86_##func,    \ >> +    *(((struct kvm_x86_ops *)0)->func)) >> +#defi

Re: [PATCH 1/2] KVM: x86: introduce definitions to support static calls for kvm_x86_ops

On 1/12/21 6:04 PM, Sean Christopherson wrote: On Mon, Jan 11, 2021, Jason Baron wrote: Use static calls to improve kvm_x86_ops performance. Introduce the definitions that will be used by a subsequent patch to actualize the savings. Note that all kvm_x86_ops are covered here except

[PATCH 2/2] KVM: x86: use static calls to reduce kvm_x86_ops overhead

|mitigations=off --- vanilla|.671s |.486s static call|.573s(-15%)|.458s(-6%) Cc: Paolo Bonzini Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Peter Zijlstra Cc: Andrea Arcangeli Signed-off-by: Jason Baron --- arch/x86/include/asm/kvm_host.h

[PATCH 1/2] KVM: x86: introduce definitions to support static calls for kvm_x86_ops

, but were omitted from this series to reduce scope and because I don't think they have as large of a performance impact. Cc: Paolo Bonzini Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Peter Zijlstra Cc: Andrea Arcangeli Signed-off-by: Jason Baron --- arch/x86/include/asm

[PATCH 0/2] Use static_call for kvm_x86_ops

Hi, Convert kvm_x86_ops to use static_call. Shows good performance gains for cpuid loop micro-benchmark (resulsts included in patch 2). Thanks, -Jason Jason Baron (2): KVM: x86: introduce definitions to support static calls for kvm_x86_ops KVM: x86: use static calls to reduce kvm_x86_ops

Re: [RFC][PATCH] jump_label/static_call: Add MAINTAINERS

c/starfire* >> >> +STATIC BRANCH/CALL >> +M: Peter Zijlstra >> +M: Josh Poimboeuf >> +M: Jason Baron >> +R: Steven Rostedt >> +R: Ard Biesheuvel >> +S: Supported > > F:arch/*/include/asm/jump_label*.h > F:arch/*/i

Re: [PATCH 7/7] dyndbg: enable 'cache' of active pr_debug callsites

On 11/25/20 2:36 PM, Jim Cromie wrote: > In ddebug_putsite(), dont zs_unmap the callsite if it is enabled for > printing. This means that the next time this pr_debug callsite is > executed, the _getsite() will succeed quickly without remapping the > zrec. > > Once the callsite is disabled via

[PATCH] hwmon: (nct7904) Correct divide by 0

] seq_read+0xd8/0x3e0 [ 1656.548127] vfs_read+0x89/0x130 [ 1656.548234] ksys_read+0x7d/0xb0 [ 1656.548342] do_syscall_64+0x48/0x110 [ 1656.548451] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: Jason Baron --- drivers/hwmon/nct7904.c | 4 ++-- 1 file changed, 2 insertions(+), 2

Re: [PATCH v2] dynamic debug: allow printing to trace event

On 8/14/20 1:15 PM, Steven Rostedt wrote: > On Fri, 14 Aug 2020 15:31:51 +0200 > Vincent Whitchurch wrote: >> index aa9ff9e1c0b3..f599ed21ecc5 100644 >> --- a/include/linux/dynamic_debug.h >> +++ b/include/linux/dynamic_debug.h >> @@ -27,13 +27,16 @@ struct _ddebug { >> * writes commands

Re: [PATCH] EDAC/ie31200: fallback if host bridge device is already initialized

On 7/16/20 4:33 PM, Jason Baron wrote: > > > On 7/16/20 2:52 PM, Luck, Tony wrote: >> On Thu, Jul 16, 2020 at 02:25:11PM -0400, Jason Baron wrote: >>> The Intel uncore driver may claim some of the pci ids from ie31200 which >>> means that the ie31200 eda

Re: [PATCH v5 00/18] dynamic_debug fixes, cleanups, features, export

On 7/19/20 7:10 PM, Jim Cromie wrote: > this is v5, changes from previous: > - moved a chunk from patch 13 to 12, per Jason > - shorten logging prefix to "dyndbg", drop __func__ > - now with more commit-log advocacy > - shuffle EXPORT_GPL(ddebug_exec_queries) last. > - v4+ series Acked-by:

Re: [PATCH] EDAC/ie31200: fallback if host bridge device is already initialized

On 7/16/20 2:52 PM, Luck, Tony wrote: > On Thu, Jul 16, 2020 at 02:25:11PM -0400, Jason Baron wrote: >> The Intel uncore driver may claim some of the pci ids from ie31200 which >> means that the ie31200 edac driver will not initialize them as part of >> pci_register_driv

Re: [PATCH v4 13/17] dyndbg: accept 'file foo.c:func1' and 'file foo.c:10-100'

or as separate patch... >> >> Thanks, >> >> -Jason >> > > ok, I'll split it out, maybe merge with prior. > > Any other tweaks ? > maybe move export last in series ? sure. > how do you feel about changing the pr_fmt > to just mod-name "dynamic_debug" or "dyndbg" > So removing the function name? I'm fine either way. Feel free to add Ack-by: Jason Baron to the series. Thanks, -Jason

[PATCH] EDAC/ie31200: fallback if host bridge device is already initialized

. This is similar in approach to other edac drivers. Signed-off-by: Jason Baron Cc: Borislav Petkov Cc: Mauro Carvalho Chehab Cc: Tony Luck Cc: linux-edac --- drivers/edac/ie31200_edac.c | 50 ++--- 1 file changed, 47 insertions(+), 3 deletions(-) diff

Re: [PATCH v4 13/17] dyndbg: accept 'file foo.c:func1' and 'file foo.c:10-100'

On 6/20/20 2:06 PM, Jim Cromie wrote: > Accept these additional query forms: > >echo "file $filestr +_" > control > >path/to/file.c:100 # as from control, column 1 >path/to/file.c:1-100 # or any legal line-range >path/to/file.c:func_A # as from an

Re: [PATCH v3 20/21] dyndbg: add user-flag, negating-flags, and filtering on flags

On 6/18/20 6:48 PM, jim.cro...@gmail.com wrote: > On Thu, Jun 18, 2020 at 4:34 PM Stanimir Varbanov > wrote: >> >> Hi Jason, Jim, >> > > > >>> I would be curious to see what Stanimir thinks of this proposal >>> and whether it would work for his venus driver, which is what >>> prompted this

Re: [PATCH v3 20/21] dyndbg: add user-flag, negating-flags, and filtering on flags

On 6/18/20 3:11 PM, jim.cro...@gmail.com wrote: > On Thu, Jun 18, 2020 at 12:17 PM Jason Baron wrote: >> >> >> >> On 6/18/20 1:40 PM, Petr Mladek wrote: >>> On Thu 2020-06-18 18:19:12, Petr Mladek wrote: >>>> On Wed 2020-06-17 10:25:35, Jim

Re: [PATCH v3 20/21] dyndbg: add user-flag, negating-flags, and filtering on flags

On 6/18/20 1:40 PM, Petr Mladek wrote: > On Thu 2020-06-18 18:19:12, Petr Mladek wrote: >> On Wed 2020-06-17 10:25:35, Jim Cromie wrote: >>> 1. Add a user-flag [u] which works like the [pfmlt] flags, but has no >>> effect on callsite behavior; it allows incremental marking of >>> arbitrary sets

Re: [PATCH 12/16] dyndbg: add filter parameter to ddebug_parse_flags

On 6/5/20 12:26 PM, Jim Cromie wrote: > Add a new *filter param to ddebug_parse_flags(), allowing it to > communicate optional filter flags back to its caller: ddebug_change() > I think you meant ddebug_exec_query() here? Thanks, -Jason > Also, ddebug_change doesn't alter any of its

Re: [PATCH 00/16] dynamic_debug: cleanups, 2 features

On 6/5/20 12:26 PM, Jim Cromie wrote: > Patchset starts with 7 "cleanups"; > - it changes section name from vague "__verbose" to "__dyndbg" > - cleaner docs, drop obsolete comment & useless debug prints, refine > verbosity, fix a BUG_ON, ram reporting miscounts. > > It adds a few query

Re: [PATCH 09/16] dyndbg: accept 'file foo.c:func1' and 'file foo.c:10-100'

On 6/5/20 12:26 PM, Jim Cromie wrote: > Accept these additional query forms: > >echo "file $filestr +_" > control > >path/to/file.c:100 # as from control, column 1 >path/to/file.c:1-100 # or any legal line-range >path/to/file.c:func_A # as from an

Re: [PATCH v3 6/7] venus: Make debug infrastructure more flexible

On 6/11/20 5:19 PM, jim.cro...@gmail.com wrote: > trimmed.. > Currently I think there not enough "levels" to map something like drm.debug to the new dyn dbg feature. I don't think it is intrinsic but I couldn't find the bit of the code where the 5-bit level in struct

Re: [RFC] Make dynamic debug infrastructure more flexible

On 5/21/20 4:06 PM, Joe Perches wrote: > On Thu, 2020-05-21 at 09:08 -0700, Joe Perches wrote: >> On Thu, 2020-05-21 at 16:28 +0300, Stanimir Varbanov wrote: >>> Here we introduce few debug macros with levels (low, medium and >>> high) and debug macro for firmware. Enabling the particular level

Re: [PATCH 1/1] epoll: call final ep_events_available() check under the lock

fully compliant to what is said in the comment of the patch > where the actual fatal_signal_pending() check was added: > c257a340ede0 ("fs, epoll: short circuit fetching events if thread > has been killed"). > > Signed-off-by: Roman Penyaev > Reported-by: Jason Baron &g

Re: [PATCH] epoll: ensure ep_poll() doesn't miss wakeup events

On 5/4/20 12:29 AM, Jason Baron wrote: > > > On 5/3/20 6:24 AM, Roman Penyaev wrote: >> On 2020-05-02 00:09, Jason Baron wrote: >>> On 5/1/20 5:02 PM, Roman Penyaev wrote: >>>> Hi Jason, >>>> >>>> That is indeed a nice catch.

Re: [PATCH] epoll: ensure ep_poll() doesn't miss wakeup events

On 5/3/20 6:24 AM, Roman Penyaev wrote: > On 2020-05-02 00:09, Jason Baron wrote: >> On 5/1/20 5:02 PM, Roman Penyaev wrote: >>> Hi Jason, >>> >>> That is indeed a nice catch. >>> Seems we need smp_rmb() pair between list_empty_ca

Re: [PATCH] epoll: ensure ep_poll() doesn't miss wakeup events

il = ep_events_available(ep); + write_unlock_irq(>lock); if (eavail) break; if (signal_pending(current)) { Thanks, -Jason > Other than that: > > Reviewed-by: Roman Penyaev > > -- > Roman > > On 2020-05-01 21:15,

Re: [PATCH 2/2] epoll: atomically remove wait entry on wake up

presents event bandwidth, thus higher is > better; number of "run-time ms" represents overall time spent > doing the benchmark, thus lower is better) > > [1] tools/testing/selftests/filesystems/epoll/epoll_wakeup_test.c > [2] https://github.com/rouming/test-tools/bl

[PATCH] epoll: ensure ep_poll() doesn't miss wakeup events

xes: 339ddb53d373 ("fs/epoll: remove unnecessary wakeups of nested epoll") Signed-off-by: Jason Baron Cc: Alexander Viro Cc: Heiher Cc: Roman Penyaev Cc: Khazhismel Kumykov Cc: Andrew Morton Cc: Davidlohr Bueso Cc: --- fs/eventpoll.c | 23 +-- 1 file changed,

Re: [PATCH v2] eventpoll: fix missing wakeup for ovflist in ep_poll_callback

On 4/28/20 2:10 PM, Roman Penyaev wrote: > On 2020-04-27 22:38, Jason Baron wrote: >> On 4/25/20 4:59 PM, Khazhismel Kumykov wrote: >>> On Sat, Apr 25, 2020 at 9:17 AM Jason Baron wrote: >>>> >>>> >>>> >>>> On 4/24/20 3:00 PM, K

Re: [PATCH RESEND v4] fs/epoll: Remove unnecessary wakeups of nested epoll that in ET mode

On 10/7/19 2:30 PM, Roman Penyaev wrote: > On 2019-10-07 18:42, Jason Baron wrote: >> On 10/7/19 6:54 AM, Roman Penyaev wrote: >>> On 2019-10-03 18:13, Jason Baron wrote: >>>> On 9/30/19 7:55 AM, Roman Penyaev wrote: >>>>> On 2019-09-28 04:29, Andre

Re: [PATCH RESEND v4] fs/epoll: Remove unnecessary wakeups of nested epoll that in ET mode

On 10/7/19 6:54 AM, Roman Penyaev wrote: > On 2019-10-03 18:13, Jason Baron wrote: >> On 9/30/19 7:55 AM, Roman Penyaev wrote: >>> On 2019-09-28 04:29, Andrew Morton wrote: >>>> On Wed, 25 Sep 2019 09:56:03 +0800 hev wrote: >>>> >>>>&

Re: [PATCH RESEND v4] fs/epoll: Remove unnecessary wakeups of nested epoll that in ET mode

On 9/30/19 7:55 AM, Roman Penyaev wrote: > On 2019-09-28 04:29, Andrew Morton wrote: >> On Wed, 25 Sep 2019 09:56:03 +0800 hev wrote: >> >>> From: Heiher >>> >>> Take the case where we have: >>> >>>     t0 >>> | (ew) >>>     e0 >>> | (et) >>>     e1 >>>

Re: [PATCH] epoll: simplify ep_poll_safewake() for CONFIG_DEBUG_LOCK_ALLOC

On 9/23/19 3:23 PM, Roman Penyaev wrote: > On 2019-09-23 17:43, Jason Baron wrote: >> On 9/4/19 4:22 PM, Jason Baron wrote: >>> Currently, ep_poll_safewake() in the CONFIG_DEBUG_LOCK_ALLOC case uses >>> ep_call_nested() in order to pass th

Re: [PATCH RESEND v2] fs/epoll: Remove unnecessary wakeups of nested epoll that in ET mode

On 9/24/19 10:06 AM, Heiher wrote: > Hi, > > On Mon, Sep 23, 2019 at 11:34 PM Jason Baron wrote: >> >> >> >> On 9/20/19 12:00 PM, Jason Baron wrote: >>> On 9/19/19 5:24 AM, hev wrote: >>>> From: Heiher >>>> >>

Re: [PATCH] epoll: simplify ep_poll_safewake() for CONFIG_DEBUG_LOCK_ALLOC

On 9/4/19 4:22 PM, Jason Baron wrote: > Currently, ep_poll_safewake() in the CONFIG_DEBUG_LOCK_ALLOC case uses > ep_call_nested() in order to pass the correct subclass argument to > spin_lock_irqsave_nested(). However, ep_call_nested() adds unnecessary > checks for epoll dep

Re: [PATCH RESEND v2] fs/epoll: Remove unnecessary wakeups of nested epoll that in ET mode

On 9/20/19 12:00 PM, Jason Baron wrote: > On 9/19/19 5:24 AM, hev wrote: >> From: Heiher >> >> Take the case where we have: >> >> t0 >> | (ew) >> e0 >> | (et) >> e1 >> | (lt) >&

Re: [PATCH RESEND v2] fs/epoll: Remove unnecessary wakeups of nested epoll that in ET mode

goto out; > > if (epoll_wait(efd[0], , 1, 0) != 0) > goto out; > > close(efd[0]); > close(efd[1]); > close(sfd[0]); > close(sfd[1]); > > return 0; > > out: > return -1; > } > > Mo

Re: [PATCH RESEND] fs/epoll: fix the edge-triggered mode for nested epoll

On 9/11/19 4:19 AM, Heiher wrote: > Hi, > > On Fri, Sep 6, 2019 at 1:48 AM Jason Baron wrote: >> >> >> >> On 9/5/19 1:27 PM, Roman Penyaev wrote: >>> On 2019-09-05 11:56, Heiher wrote: >>>> Hi, >>>> >>>> On Thu

Re: [PATCH RESEND] fs/epoll: fix the edge-triggered mode for nested epoll

t;> and any other corner cases needs to be added? >>> >>> https://github.com/heiher/epoll-wakeup/blob/master/README.md >>> >>> On Wed, Sep 4, 2019 at 10:02 PM Heiher wrote: >>> > >>> > Hi, >>> > >>> > On Wed, Sep 4,

[PATCH] epoll: simplify ep_poll_safewake() for CONFIG_DEBUG_LOCK_ALLOC

. This mirrors a conversion that was done for !CONFIG_DEBUG_LOCK_ALLOC in: commit 37b5e5212a44 ("epoll: remove ep_call_nested() from ep_eventpoll_poll()") Signed-off-by: Jason Baron Cc: Davidlohr Bueso Cc: Roman Penyaev Cc: Al Viro Cc: Eric Wong Cc: Andrew Morton --- fs/eventp

Re: [PATCH RESEND] fs/epoll: fix the edge-triggered mode for nested epoll

On 9/4/19 5:57 AM, Roman Penyaev wrote: > On 2019-09-03 23:08, Jason Baron wrote: >> On 9/2/19 11:36 AM, Roman Penyaev wrote: >>> Hi, >>> >>> This is indeed a bug. (quick side note: could you please remove efd[1] >>> from your test, because it is not

Re: [PATCH RESEND] fs/epoll: fix the edge-triggered mode for nested epoll

"w", 1) != 1) >> goto out; >> >> nfds = epoll_wait(efd[0], , 1, 0); >> if (nfds != 1) >> goto out; >> >> nfds = epoll_wait(efd[0], , 1, 0); >> if (nfds != 0) >>      goto out; >> >> nfds

Re: [PATCH] lib: dynamic_debug: no need to check return value of debugfs_create functions

On 6/13/19 11:59 AM, Greg Kroah-Hartman wrote: > On Thu, Jun 13, 2019 at 10:33:23AM -0400, Jason Baron wrote: >> On 6/12/19 11:35 AM, Greg Kroah-Hartman wrote: >>> When calling debugfs functions, there is no need to ever check the >>> return value. The function ca

Re: [PATCH] lib: dynamic_debug: no need to check return value of debugfs_create functions

On 6/12/19 11:35 AM, Greg Kroah-Hartman wrote: > When calling debugfs functions, there is no need to ever check the > return value. The function can work or not, but the code logic should > never do something different based on this. > > Cc: Jason Baron > Cc: linux-kern

Re: [PATCH net-next] tcp: Make tcp_fastopen_alloc_ctx static

open_context *new_ctx; > void *key = primary_key; > Thanks for fixing. Acked-by: Jason Baron

Re: [PATCH v3 5/6] x86/alternative: Use a single access in text_poke() where possible

On 1/11/19 11:57 AM, Josh Poimboeuf wrote: > On Fri, Jan 11, 2019 at 05:46:36PM +0100, Alexandre Chartre wrote: >> >> >> On 01/11/2019 04:28 PM, Josh Poimboeuf wrote: >>> On Fri, Jan 11, 2019 at 01:10:52PM +0100, Alexandre Chartre wrote: To avoid any issue with live patching the call

Re: [RFC PATCH 1/1] epoll: use rwlock in order to reduce ep_poll_callback() contention

On 12/5/18 6:16 AM, Roman Penyaev wrote: > On 2018-12-04 18:23, Jason Baron wrote: >> On 12/3/18 6:02 AM, Roman Penyaev wrote: > > [...] > >>> >>> ep_set_busy_poll_napi_id(epi); >>> >>> @@ -1156,8 +1187,8 @@ static int ep_poll_call

Re: [RFC PATCH 1/1] epoll: use rwlock in order to reduce ep_poll_callback() contention

On 12/5/18 6:16 AM, Roman Penyaev wrote: > On 2018-12-04 18:23, Jason Baron wrote: >> On 12/3/18 6:02 AM, Roman Penyaev wrote: > > [...] > >>> >>> ep_set_busy_poll_napi_id(epi); >>> >>> @@ -1156,8 +1187,8 @@ static int ep_poll_call

Re: [RFC PATCH 1/1] epoll: use rwlock in order to reduce ep_poll_callback() contention

On 12/3/18 6:02 AM, Roman Penyaev wrote: > Hi all, > > The goal of this patch is to reduce contention of ep_poll_callback() which > can be called concurrently from different CPUs in case of high events > rates and many fds per epoll. Problem can be very well reproduced by > generating events

Re: [RFC PATCH 1/1] epoll: use rwlock in order to reduce ep_poll_callback() contention

On 12/3/18 6:02 AM, Roman Penyaev wrote: > Hi all, > > The goal of this patch is to reduce contention of ep_poll_callback() which > can be called concurrently from different CPUs in case of high events > rates and many fds per epoll. Problem can be very well reproduced by > generating events

Re: [RFC PATCH 6/6] x86/jump_label,x86/alternatives: Batch jump label transformations

uot;H. Peter Anvin" > Cc: Greg Kroah-Hartman > Cc: Pavel Tatashin > Cc: Masami Hiramatsu > Cc: "Steven Rostedt (VMware)" > Cc: Zhou Chengming > Cc: Jiri Kosina > Cc: Josh Poimboeuf > Cc: "Peter Zijlstra (Intel)" > Cc: Chris von Recklinghause

Re: [RFC PATCH 6/6] x86/jump_label,x86/alternatives: Batch jump label transformations

uot;H. Peter Anvin" > Cc: Greg Kroah-Hartman > Cc: Pavel Tatashin > Cc: Masami Hiramatsu > Cc: "Steven Rostedt (VMware)" > Cc: Zhou Chengming > Cc: Jiri Kosina > Cc: Josh Poimboeuf > Cc: "Peter Zijlstra (Intel)" > Cc: Chris von Recklinghause

Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT

On 06/20/2018 07:00 AM, Michal Hocko wrote: > On Fri 15-06-18 15:36:07, Jason Baron wrote: >> >> >> On 06/13/2018 03:15 AM, Michal Hocko wrote: >>> On Wed 13-06-18 08:32:19, Vlastimil Babka wrote: > [...] >>>> BTW I didn't get why we should allow

Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT

On 06/20/2018 07:00 AM, Michal Hocko wrote: > On Fri 15-06-18 15:36:07, Jason Baron wrote: >> >> >> On 06/13/2018 03:15 AM, Michal Hocko wrote: >>> On Wed 13-06-18 08:32:19, Vlastimil Babka wrote: > [...] >>>> BTW I didn't get why we should allow

Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT

On 06/13/2018 03:15 AM, Michal Hocko wrote: > On Wed 13-06-18 08:32:19, Vlastimil Babka wrote: >> On 06/12/2018 04:11 PM, Jason Baron wrote: >>> >>> >>> On 06/12/2018 03:46 AM, Michal Hocko wrote: >>>> On Mon 11-06-18 12:23:58, Jason Baron wrote:

Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT

On 06/13/2018 03:15 AM, Michal Hocko wrote: > On Wed 13-06-18 08:32:19, Vlastimil Babka wrote: >> On 06/12/2018 04:11 PM, Jason Baron wrote: >>> >>> >>> On 06/12/2018 03:46 AM, Michal Hocko wrote: >>>> On Mon 11-06-18 12:23:58, Jason Baron wrote:

Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT

On 06/13/2018 05:13 AM, Michal Hocko wrote: > On Tue 12-06-18 10:11:33, Jason Baron wrote: > [...] >> Ok, I share the concern that there is a chance that userspace is relying >> on MADV_DONTNEED not free'ing locked memory. In that case, what if we >> introduce a MADV_DO

Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT

On 06/13/2018 05:13 AM, Michal Hocko wrote: > On Tue 12-06-18 10:11:33, Jason Baron wrote: > [...] >> Ok, I share the concern that there is a chance that userspace is relying >> on MADV_DONTNEED not free'ing locked memory. In that case, what if we >> introduce a MADV_DO

Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT

On 06/12/2018 03:46 AM, Michal Hocko wrote: > On Mon 11-06-18 12:23:58, Jason Baron wrote: >> On 06/11/2018 11:03 AM, Michal Hocko wrote: >>> So can we start discussing whether we want to allow MADV_DONTNEED on >>> mlocked areas and what downsides it mig

Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT

On 06/12/2018 03:46 AM, Michal Hocko wrote: > On Mon 11-06-18 12:23:58, Jason Baron wrote: >> On 06/11/2018 11:03 AM, Michal Hocko wrote: >>> So can we start discussing whether we want to allow MADV_DONTNEED on >>> mlocked areas and what downsides it mig

Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT

On 06/11/2018 11:03 AM, Michal Hocko wrote: > On Mon 11-06-18 10:51:44, Jason Baron wrote: >> On 06/11/2018 03:20 AM, Michal Hocko wrote: >>> [CCing linux-api - please make sure to CC this mailing list anytime you >>> are touching user visible apis] >>>

Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT

On 06/11/2018 11:03 AM, Michal Hocko wrote: > On Mon 11-06-18 10:51:44, Jason Baron wrote: >> On 06/11/2018 03:20 AM, Michal Hocko wrote: >>> [CCing linux-api - please make sure to CC this mailing list anytime you >>> are touching user visible apis] >>>

Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT

On 06/11/2018 03:20 AM, Michal Hocko wrote: > [CCing linux-api - please make sure to CC this mailing list anytime you > are touching user visible apis] > > On Fri 08-06-18 14:56:52, Jason Baron wrote: >> In order to free memory that is marked MLOCK_ONFAULT, the memory region &g

Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT

On 06/11/2018 03:20 AM, Michal Hocko wrote: > [CCing linux-api - please make sure to CC this mailing list anytime you > are touching user visible apis] > > On Fri 08-06-18 14:56:52, Jason Baron wrote: >> In order to free memory that is marked MLOCK_ONFAULT, the memory region &g

Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT

On 06/08/2018 03:57 PM, Andrew Morton wrote: > On Fri, 8 Jun 2018 14:56:52 -0400 Jason Baron wrote: > >> In order to free memory that is marked MLOCK_ONFAULT, the memory region >> needs to be first unlocked, before calling MADV_DONTNEED. And if the region >> is to be reu

Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT

On 06/08/2018 03:57 PM, Andrew Morton wrote: > On Fri, 8 Jun 2018 14:56:52 -0400 Jason Baron wrote: > >> In order to free memory that is marked MLOCK_ONFAULT, the memory region >> needs to be first unlocked, before calling MADV_DONTNEED. And if the region >> is to be reu

[PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT

ing MADV_FREE for MLOCK_ONFAULT regions makes sense, since the point of MLOCK_ONFAULT is for userspace to know when pages are locked in memory and thus to know when page faults will occur. Signed-off-by: Jason Baron Cc: Andrew Morton Cc: Michal Hocko Cc: Vlastimil Babka Cc: Joonsoo Kim Cc: Mel Gor

[PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT

ing MADV_FREE for MLOCK_ONFAULT regions makes sense, since the point of MLOCK_ONFAULT is for userspace to know when pages are locked in memory and thus to know when page faults will occur. Signed-off-by: Jason Baron Cc: Andrew Morton Cc: Michal Hocko Cc: Vlastimil Babka Cc: Joonsoo Kim Cc: Mel Gor

Re: [PATCH v2 1/2] jump_label: Explicitly disable jump labels in __init code

On 02/16/2018 11:31 AM, Josh Poimboeuf wrote: > After initmem has been freed, any jump label entries in __init code are > prevented from being written to by the kernel_text_address() check in > __jump_label_update(). However, this check is quite broad. If > kernel_text_address() were to return

Re: [PATCH v2 1/2] jump_label: Explicitly disable jump labels in __init code

On 02/16/2018 11:31 AM, Josh Poimboeuf wrote: > After initmem has been freed, any jump label entries in __init code are > prevented from being written to by the kernel_text_address() check in > __jump_label_update(). However, this check is quite broad. If > kernel_text_address() were to return

Re: [PATCH 1/3] jump_label: Warn on failed jump_label patch

On 02/14/2018 12:01 PM, Steven Rostedt wrote: > On Wed, 14 Feb 2018 10:40:41 -0600 > Josh Poimboeuf wrote: > >> When the jump label code encounters an address which isn't recognized by >> kernel_text_address(), it just silently fails. >> >> This can be dangerous because

Re: [PATCH 1/3] jump_label: Warn on failed jump_label patch

On 02/14/2018 12:01 PM, Steven Rostedt wrote: > On Wed, 14 Feb 2018 10:40:41 -0600 > Josh Poimboeuf wrote: > >> When the jump label code encounters an address which isn't recognized by >> kernel_text_address(), it just silently fails. >> >> This can be dangerous because jump labels are used in

Re: [PATCH v5 0/3] livepatch: introduce atomic replace

On 01/30/2018 02:24 PM, Joe Lawrence wrote: > On 01/30/2018 01:19 PM, Jason Baron wrote: >> [ ... snip ... ] >> >> Our main interest in 'atomic replace' is simply to make sure that >> cumulative patches work as expected in that they 'replace' any prior >> patch

Re: [PATCH v5 0/3] livepatch: introduce atomic replace

On 01/30/2018 02:24 PM, Joe Lawrence wrote: > On 01/30/2018 01:19 PM, Jason Baron wrote: >> [ ... snip ... ] >> >> Our main interest in 'atomic replace' is simply to make sure that >> cumulative patches work as expected in that they 'replace' any prior >> patch

Re: [PATCH v5 0/3] livepatch: introduce atomic replace

On 01/30/2018 10:06 AM, Evgenii Shatokhin wrote: > On 30.01.2018 17:03, Petr Mladek wrote: >> On Fri 2018-01-26 14:29:36, Evgenii Shatokhin wrote: >>> On 26.01.2018 13:23, Petr Mladek wrote: >>>> On Fri 2018-01-19 16:10:42, Jason Baron wrote: >>>>>

Re: [PATCH v5 0/3] livepatch: introduce atomic replace

On 01/30/2018 10:06 AM, Evgenii Shatokhin wrote: > On 30.01.2018 17:03, Petr Mladek wrote: >> On Fri 2018-01-26 14:29:36, Evgenii Shatokhin wrote: >>> On 26.01.2018 13:23, Petr Mladek wrote: >>>> On Fri 2018-01-19 16:10:42, Jason Baron wrote: >>>>>

Re: PATCH v6 6/6] livepatch: Add atomic replace

On 01/25/2018 11:02 AM, Petr Mladek wrote: > From: Jason Baron <jba...@akamai.com> > > Sometimes we would like to revert a particular fix. Currently, this > is not easy because we want to keep all other fixes active and we > could revert only the last applied patch. &g

Re: PATCH v6 6/6] livepatch: Add atomic replace

On 01/25/2018 11:02 AM, Petr Mladek wrote: > From: Jason Baron > > Sometimes we would like to revert a particular fix. Currently, this > is not easy because we want to keep all other fixes active and we > could revert only the last applied patch. > > One solution would

Re: [PATCH v5 0/3] livepatch: introduce atomic replace

On 01/19/2018 02:20 PM, Evgenii Shatokhin wrote: > On 12.01.2018 22:55, Jason Baron wrote: >> Hi, >>   While using livepatch, I found that when doing cumulative patches, >> if a patched >> function is completed reverted by a subsequent patch (back to its >>

Re: [PATCH v5 0/3] livepatch: introduce atomic replace

On 01/19/2018 02:20 PM, Evgenii Shatokhin wrote: > On 12.01.2018 22:55, Jason Baron wrote: >> Hi, >>   While using livepatch, I found that when doing cumulative patches, >> if a patched >> function is completed reverted by a subsequent patch (back to its >>

Re: [PATCH] epoll: avoid calling ep_call_nested() from ep_poll_safewake()

On 01/18/2018 06:00 AM, Hou Tao wrote: > Hi Jason, > > On 2017/10/18 22:03, Jason Baron wrote: >> >> >> On 10/17/2017 11:37 AM, Davidlohr Bueso wrote: >>> On Fri, 13 Oct 2017, Jason Baron wrote: >>> >>>> The ep_poll_safewake() function

Re: [PATCH] epoll: avoid calling ep_call_nested() from ep_poll_safewake()

On 01/18/2018 06:00 AM, Hou Tao wrote: > Hi Jason, > > On 2017/10/18 22:03, Jason Baron wrote: >> >> >> On 10/17/2017 11:37 AM, Davidlohr Bueso wrote: >>> On Fri, 13 Oct 2017, Jason Baron wrote: >>> >>>> The ep_poll_safewake() function

Re: PROBLEM: epoll_wait does not obey edge triggering semantics for hierarchically constructed epoll sets

l fd in the current code. If that's not sufficient for what you are trying to do, you could try the patch I attached in the previous mail, and see if it matches what you are expecting Thanks, -Jason > > On Wed, Jan 17, 2018 at 9:21 AM, Jason Baron <jba...@akamai.com> wrote: >&g

Re: PROBLEM: epoll_wait does not obey edge triggering semantics for hierarchically constructed epoll sets

l fd in the current code. If that's not sufficient for what you are trying to do, you could try the patch I attached in the previous mail, and see if it matches what you are expecting Thanks, -Jason > > On Wed, Jan 17, 2018 at 9:21 AM, Jason Baron wrote: >> >> &g

Re: PROBLEM: epoll_wait does not obey edge triggering semantics for hierarchically constructed epoll sets

On 01/12/2018 07:06 PM, Nick Murphy wrote: > [1.] One line summary of the problem: > epoll_wait does not obey edge triggering semantics for file > descriptors which are themselves epoll file descriptors (i.e., epoll > fd's added to an epoll set with the EPOLLET flag) > > [2.] Full description

Re: PROBLEM: epoll_wait does not obey edge triggering semantics for hierarchically constructed epoll sets

On 01/12/2018 07:06 PM, Nick Murphy wrote: > [1.] One line summary of the problem: > epoll_wait does not obey edge triggering semantics for file > descriptors which are themselves epoll file descriptors (i.e., epoll > fd's added to an epoll set with the EPOLLET flag) > > [2.] Full description

[PATCH v5 0/3] livepatch: introduce atomic replace

-a 'replace' patch now disables all previous patches -tried to shorten klp_init_patch_no_ops()... -Simplified logic klp_complete_transition (Petr Mladek) Jason Baron (3): livepatch: use lists to manage patches, objects and functions livepatch: shuffle core.c function order livepatch: add

[PATCH v5 0/3] livepatch: introduce atomic replace

-a 'replace' patch now disables all previous patches -tried to shorten klp_init_patch_no_ops()... -Simplified logic klp_complete_transition (Petr Mladek) Jason Baron (3): livepatch: use lists to manage patches, objects and functions livepatch: shuffle core.c function order livepatch: add

[PATCH v5 2/3] livepatch: shuffle core.c function order

In preparation for __klp_enable_patch() to call a number of 'static' functions, in a subsequent patch, move them earlier in core.c. This patch should be a nop from a functional pov. Signed-off-by: Jason Baron <jba...@akamai.com> Cc: Josh Poimboeuf <jpoim...@redhat.com> Cc: J

[PATCH v5 2/3] livepatch: shuffle core.c function order

In preparation for __klp_enable_patch() to call a number of 'static' functions, in a subsequent patch, move them earlier in core.c. This patch should be a nop from a functional pov. Signed-off-by: Jason Baron Cc: Josh Poimboeuf Cc: Jessica Yu Cc: Jiri Kosina Cc: Miroslav Benes Cc: Petr

[PATCH v5 3/3] livepatch: add atomic replace

oving them (rmmod) and then re-inserting them (insmod). Signed-off-by: Jason Baron <jba...@akamai.com> Cc: Josh Poimboeuf <jpoim...@redhat.com> Cc: Jessica Yu <j...@kernel.org> Cc: Jiri Kosina <ji...@kernel.org> Cc: Miroslav Benes <mbe...@suse.cz> Cc: Petr Mladek <pmla.

[PATCH v5 3/3] livepatch: add atomic replace

oving them (rmmod) and then re-inserting them (insmod). Signed-off-by: Jason Baron Cc: Josh Poimboeuf Cc: Jessica Yu Cc: Jiri Kosina Cc: Miroslav Benes Cc: Petr Mladek --- include/linux/livepatch.h | 6 +- kernel/livepatch/core.c | 280 -- kernel

  1   2   3   4   5   6   7   8   9   >