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 total pe
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 KV
(), 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
k they have as large 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/x
olo Bonzini
Cc: 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 +
)
-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
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, \
>>> +
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
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 for
|default|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
simlilar
manner, 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
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
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
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
] 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
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
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 edac d
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:
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_driver
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
l be configured. 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 del
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 editor/brow
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 m
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
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
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 argume
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 parsin
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 editor/brow
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
_ddebug
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
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
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.
>
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_careful(&am
eavail = ep_events_available(ep);
+ write_unlock_irq(&ep->lock);
if (eavail)
break;
if (signal_pending(current)) {
Thanks,
-Jason
> Other than that:
>
> Reviewed-by: Roman Penyaev
>
> --
> R
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
s now scheduled and missed the wakeup.
Fixes: 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 +
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
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
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:
>>>>
>>>>&
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
>>> |
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 the c
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
>>>>
>>
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 depth an
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)
>&
&e, 1, 0) != 1)
> goto out;
>
> if (epoll_wait(efd[0], &e, 1, 0) != 0)
> goto out;
>
> close(efd[0]);
> close(efd[1]);
> close(sfd[0]);
> close(sfd[1]);
>
> return 0;
>
> out:
> retur
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, S
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,
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
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
1)
>> goto out;
>>
>> nfds = epoll_wait(efd[0], &e, 1, 0);
>> if (nfds != 0)
>> goto out;
>>
>> nfds = epoll_wait(efd[1], &e, 1, 0);
>> if (nfds != 1)
>> goto out;
>>
>> n
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
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
truct tcp_fastopen_context *new_ctx;
> void *key = primary_key;
>
Thanks for fixing.
Acked-by: Jason Baron
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 instructi
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
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 (
islav Petkov
> Cc: "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
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 a
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:
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 MA
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 might h
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]
>>>
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
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
hink allowing 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
C
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
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
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
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:
>>>>>
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
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
>> orig
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
ter' epoll fd will no longer show
events and thus you have something resembling edge triggering for the
'outer' epoll 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 match
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 of
to klp_patch, similar to the immediate field
-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
li
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
be re-enabled
by removing 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 ++
together
via linked lists. This allows us to more easily allocate new objects and
functions, while having the iterator be a simple linked list walk.
This patch is intended to be a no-op until atomic replace is introduced by
a subsequent patch.
Signed-off-by: Jason Baron
Cc: Josh Poimboeuf
Cc: Jessica
On 12/20/2017 09:33 AM, Yan Vugenfirer wrote:
>
>> On 20 Dec 2017, at 16:31, Michael S. Tsirkin wrote:
>>
>> On Tue, Dec 19, 2017 at 11:52:39AM -0500, Jason Baron wrote:
>>>
>>>
>>> On 12/19/2017 04:19 AM, Yan Vugenfirer wrote:
>>>>
On 12/20/2017 12:52 PM, Michael S. Tsirkin wrote:
> On Wed, Dec 20, 2017 at 12:07:55PM -0500, Jason Baron wrote:
>>
>>
>> On 12/20/2017 09:57 AM, Michael S. Tsirkin wrote:
>>> On Thu, Dec 14, 2017 at 02:33:53PM -0500, Jason Baron wrote:
>>>> If the hy
On 12/20/2017 09:57 AM, Michael S. Tsirkin wrote:
> On Thu, Dec 14, 2017 at 02:33:53PM -0500, Jason Baron wrote:
>> If the hypervisor exports the link and duplex speed, let's use that instead
>> of the default unknown speed. The user can still overwrite it later if
>>
On 12/19/2017 04:19 AM, Yan Vugenfirer wrote:
>
>> On 18 Dec 2017, at 18:04, Jason Baron via Qemu-devel
>> mailto:qemu-de...@nongnu.org>> wrote:
>>
>>
>>
>> On 12/18/2017 06:34 AM, Yan Vugenfirer wrote:
>>>
>>>> On 14
On 12/18/2017 06:34 AM, Yan Vugenfirer wrote:
>
>> On 14 Dec 2017, at 21:33, Jason Baron via Qemu-devel
>> wrote:
>>
>> Although they can be currently set in linux via 'ethtool -s', this requires
>> guest changes, and thus it would be nice to exten
On 11/22/2017 05:29 AM, Miroslav Benes wrote:
> If a task sleeps in a set of patched functions uninterruptedly, it could
> block the whole transition indefinitely. Thus it may be useful to clear
> its TIF_PATCH_PENDING to allow the process to finish.
>
> Admin can do that now by writing to force
vice virtio-net,speed=1,duplex=full'
where speed is [-1...INT_MAX], and duplex is ["half"|"full"].
Signed-off-by: Jason Baron
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
---
hw/net/virtio-net.c | 29 +
EX feature flag, to
indicate that a linkspeed and duplex setting are present.
Signed-off-by: Jason Baron
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
---
drivers/net/virtio_net.c| 11 ++-
include/uapi/linux/virtio_net.h | 4
2 files changed, 14 insertions(+), 1
meant as a demonstration of how I intend this
to work.
Thanks,
-Jason
Jason Baron (2):
virtio_net: allow hypervisor to indicate linkspeed and duplex setting
qemu: add linkspeed and duplex setting to virtio-net
linux changes:
drivers/net/virtio_net.c| 11 ++-
include/uapi/linux/vi
rt locking invariations in the waitqueue code.
>
> Signed-off-by: Christoph Hellwig
Probably should also fix the locking comments at the top of
fs/eventpoll.c that refer to ep->lock...
The rest looks good.
Reviewed-by: Jason Baron
Thanks,
On 12/01/2017 06:03 PM, Christoph Hellwig wrote:
> On Fri, Dec 01, 2017 at 05:34:50PM -0500, Jason Baron wrote:
>> hmmm...I'm not sure how this suggestion would change the locking rules
>> from what we currently have. Right now, we use ep->lock, if we remove
>> that
On 12/01/2017 05:02 PM, Christoph Hellwig wrote:
> On Fri, Dec 01, 2017 at 02:00:33PM -0500, Jason Baron wrote:
>> You could leave the annotation and do something like:
>> s/ep->lock/ep->wq->lock. And then that would remove the ep->lock saving
>> a bit of space.
&g
On 12/01/2017 12:11 PM, Christoph Hellwig wrote:
> On Thu, Nov 30, 2017 at 05:18:07PM -0500, Jason Baron wrote:
>> Yes, but for those cases it uses the ep->poll_wait waitqueue not the
>> ep->wq, which is guarded by the ep->wq->lock.
>
> True. So it looks
On 11/30/2017 05:11 PM, Christoph Hellwig wrote:
> On Thu, Nov 30, 2017 at 04:38:02PM -0500, Jason Baron wrote:
>> I don't think there is a bug here. The 'wake_up_locked()' calls in epoll
>> are being protected by the ep->lock, not the wait_queue_head lock. S
On 11/30/2017 03:50 PM, Andrew Morton wrote:
> On Thu, 30 Nov 2017 06:20:35 -0800 Christoph Hellwig wrote:
>
>> Hi all,
>>
>> this series adds a strategic lockdep_assert_held to __wake_up_common
>> to ensure callers really do hold the wait_queue_head lock when calling
>> the unlocked wake_up va
Hi,
On 11/29/2017 10:41 PM, Fengguang Wu wrote:
> Hello,
>
> FYI this happens in mainline kernel 4.15.0-rc1.
> It looks a new regression and bisect is on the way.
>
> It occurs in 3 out of 3 boots.
>
> [ 35.704690] init: Failed to create pty - disabling logging for job
> [ 35.706676] init:
Commit-ID: 92ee46efeb505ead3ab06d3c5ce695637ed5f152
Gitweb: https://git.kernel.org/tip/92ee46efeb505ead3ab06d3c5ce695637ed5f152
Author: Jason Baron
AuthorDate: Mon, 13 Nov 2017 16:48:47 -0500
Committer: Ingo Molnar
CommitDate: Tue, 14 Nov 2017 08:41:41 +0100
jump_label: Invoke
Cc: Steven Rostedt
Cc: Ingo Molnar
Signed-off-by: Jason Baron
---
kernel/jump_label.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 0bf2e8f5..7c3774a 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -769,7 +769,7
ddebug_parse_query: last-line:0 < 1st-line:1
> dynamic_debug:ddebug_exec_query: query parse failed
>
> Signed-off-by: Randy Dunlap
> Cc: Jason Baron
> ---
> lib/dynamic_debug.c |4
> 1 file changed, 4 insertions(+)
>
> --- lnx-414-rc8.orig/lib/dynamic_debug.c
> +++ lnx-414
On 11/09/2017 03:56 PM, Paul E. McKenney wrote:
> On Thu, Nov 09, 2017 at 03:13:24PM -0500, Jason Baron wrote:
>> On 11/08/2017 02:01 AM, Fengguang Wu wrote:
>>> On Tue, Nov 07, 2017 at 05:17:38PM -0500, Jason Baron wrote:
>>>>
>>>>
>>>> O
On 11/08/2017 02:01 AM, Fengguang Wu wrote:
> On Tue, Nov 07, 2017 at 05:17:38PM -0500, Jason Baron wrote:
>>
>>
>> On 11/07/2017 04:27 AM, Fengguang Wu wrote:
>>> Hello,
>>>
>>> FYI this happens in v4.14-rc8 -- it's not necessarily a new bug
On 11/08/2017 02:01 AM, Fengguang Wu wrote:
> On Tue, Nov 07, 2017 at 05:17:38PM -0500, Jason Baron wrote:
>>
>>
>> On 11/07/2017 04:27 AM, Fengguang Wu wrote:
>>> Hello,
>>>
>>> FYI this happens in v4.14-rc8 -- it's not necessarily a new bug
1 - 100 of 455 matches
Mail list logo
