On Tue, Dec 08 2020 at 18:25, Maxim Levitsky wrote:
> On Tue, 2020-12-08 at 17:02 +0100, Thomas Gleixner wrote:
>> For one I have no idea which bug you are talking about and if the bug is
>> caused by the VMM then why would you "fix" it in the guest kernel.
>
>
On Tue, Dec 08 2020 at 09:43, Andy Lutomirski wrote:
> On Tue, Dec 8, 2020 at 6:23 AM Marcelo Tosatti wrote:
> It looks like it tries to accomplish the right goal, but in a rather
> roundabout way. The host knows how to convert from TSC to
> CLOCK_REALTIME, and ptp_kvm.c exposes this data to the
On Tue, Dec 08 2020 at 13:13, Maxim Levitsky wrote:
> On Mon, 2020-12-07 at 11:29 -0600, Oliver Upton wrote:
>>
>> How would a VMM maintain the phase relationship between guest TSCs
>> using these ioctls?
>
> By using the nanosecond timestamp.
>
> While I did made it optional in the V2 it was
On Tue, Dec 08 2020 at 16:50, Maxim Levitsky wrote:
> On Mon, 2020-12-07 at 20:29 -0300, Marcelo Tosatti wrote:
>> > +This ioctl allows to reconstruct the guest's IA32_TSC and TSC_ADJUST value
>> > +from the state obtained in the past by KVM_GET_TSC_STATE on the same vCPU.
>> > +
>> > +If
Ira,
On Mon, Dec 07 2020 at 14:14, Ira Weiny wrote:
> Is there any chance of this landing before the kmap stuff gets sorted out?
I have marked this as needs an update because the change log of 5/10
sucks. https://lore.kernel.org/r/87lff1xcmv@nanos.tec.linutronix.de
> It would be nice to
On Mon, Dec 07 2020 at 14:38, Paul E. McKenney wrote:
> On Mon, Dec 07, 2020 at 10:46:33PM +0100, Thomas Gleixner wrote:
>> On Mon, Dec 07 2020 at 11:44, Paul E. McKenney wrote:
>> > On Mon, Dec 07, 2020 at 07:19:51PM +0100, Marco Elver wrote:
>> >> On Mon, 7 Dec
On Mon, Dec 07 2020 at 11:44, Paul E. McKenney wrote:
> On Mon, Dec 07, 2020 at 07:19:51PM +0100, Marco Elver wrote:
>> On Mon, 7 Dec 2020 at 18:46, Thomas Gleixner wrote:
>> I currently don't know what the rule for Peter's preferred variant
>> would be, without run
On Mon, Dec 07 2020 at 19:19, Marco Elver wrote:
> On Mon, 7 Dec 2020 at 18:46, Thomas Gleixner wrote:
>> On Mon, Dec 07 2020 at 13:09, Peter Zijlstra wrote:
>> > I prefer the form:
>> >
>> > if (data_race(tick_do_timer_cpu == TICK_DO_TIMER_BOOT)) {
On Mon, Dec 07 2020 at 15:27, Peter Zijlstra wrote:
> On Mon, Dec 07, 2020 at 03:00:40PM +0100, Sebastian Andrzej Siewior wrote:
>> On 2020-12-07 12:47:43 [+0100], Peter Zijlstra wrote:
>> > On Fri, Dec 04, 2020 at 06:02:00PM +0100, Thomas Gleixner wrote:
>> >
On Mon, Dec 07 2020 at 18:49, Thomas Gleixner wrote:
> On Mon, Dec 07 2020 at 16:39, Sebastian Andrzej Siewior wrote:
>> On 2020-12-07 16:22:07 [+0100], Thomas Gleixner wrote:
>>> On Mon, Dec 07 2020 at 15:00, Sebastian Andrzej Siewior wrote:
>>> > So we keep the RT
On Mon, Dec 07 2020 at 16:39, Sebastian Andrzej Siewior wrote:
> On 2020-12-07 16:22:07 [+0100], Thomas Gleixner wrote:
>> On Mon, Dec 07 2020 at 15:00, Sebastian Andrzej Siewior wrote:
>> > So we keep the RT part as-is and replace the non-RT bits with this?
>>
>&
On Mon, Dec 07 2020 at 13:09, Peter Zijlstra wrote:
> On Sun, Dec 06, 2020 at 10:12:56PM +0100, Thomas Gleixner wrote:
>> +if (data_race(tick_do_timer_cpu) == TICK_DO_TIMER_BOOT) {
>
> I prefer the form:
>
> if (data_race(tick_do_timer_cpu
On Mon, Dec 07 2020 at 12:59, Peter Zijlstra wrote:
> On Sun, Dec 06, 2020 at 10:12:54PM +0100, Thomas Gleixner wrote:
>
>> void tick_handover_do_timer(void)
>> {
>> +if (tick_do_timer_cpu == smp_processor_id())
>> +tick_do_timer_cpu =
On Mon, Dec 07 2020 at 14:16, Vitaly Kuznetsov wrote:
> Maxim Levitsky writes:
>> But other than that I don't mind making TSC offset global per VM thing.
>> Paulo, what do you think about this?
>>
>
> Not Paolo here but personally I'd very much prefer we go this route but
> unsynchronized TSCs
On Mon, Dec 07 2020 at 14:16, Maxim Levitsky wrote:
> On Sun, 2020-12-06 at 17:19 +0100, Thomas Gleixner wrote:
>> From a timekeeping POV and the guests expectation of TSC this is
>> fundamentally wrong:
>>
>> tscguest = scaled(hosttsc) + offset
>>
>&
On Sun, Dec 06 2020 at 22:46, Ira Weiny wrote:
> On Fri, Dec 04, 2020 at 11:33:08PM +0100, Thomas Gleixner wrote:
>> On Fri, Dec 04 2020 at 08:05, Ira Weiny wrote:
>> > So I think I'm going to submit the base patch to Andrew today (with some
>> > cleanups per
On Mon, Dec 07 2020 at 13:18, Corentin Labbe wrote:
> On Mon, Dec 07, 2020 at 01:15:49AM +0100, Thomas Gleixner wrote:
> So if I understand correctly, basicly I cannot have two atomic kmap at
> the same time since it made unmapping them in the right order complex.
You can, but the ord
On Mon, Dec 07 2020 at 15:00, Sebastian Andrzej Siewior wrote:
> On 2020-12-07 12:47:43 [+0100], Peter Zijlstra wrote:
>> On Fri, Dec 04, 2020 at 06:02:00PM +0100, Thomas Gleixner wrote:
>> > @@ -825,7 +848,20 @@ void tasklet_kill(struct tasklet_struct
>> >
>
On Mon, Dec 07 2020 at 12:39, Peter Zijlstra wrote:
> On Fri, Dec 04, 2020 at 06:01:58PM +0100, Thomas Gleixner wrote:
>> static inline void tasklet_unlock_wait(struct tasklet_struct *t)
>> {
>> -while (test_bit(TASKLET_STATE_RUN, &(t)->state)) { barrier(
On Mon, Dec 07 2020 at 15:16, Frederic Weisbecker wrote:
> On Fri, Dec 04, 2020 at 06:01:55PM +0100, Thomas Gleixner wrote:
>> +void __local_bh_disable_ip(unsigned long ip, unsigned int cnt)
>> +{
>> +unsigned long flags;
>> +int newcnt;
>>
On Mon, Dec 07 2020 at 14:27, Frederic Weisbecker wrote:
> On Fri, Dec 04, 2020 at 06:01:53PM +0100, Thomas Gleixner wrote:
>> vtime_account_irq and irqtime_account_irq() base checks on preempt_count()
>> which fails on RT because preempt_count() does not contain the softirq
>
On Mon, Dec 07 2020 at 10:59, Peter Zijlstra wrote:
>> +if (IS_ENABLED(CONFIG_64BIT)) {
>> +if (ktime_before(now, smp_load_acquire(_next_period)))
>> +return;
>
> Explicit ACQUIRE
>
>> +} else {
>> +unsigned int seq;
>> +
>> +/*
>> +
On Mon, Dec 07 2020 at 14:07, Sebastian Andrzej Siewior wrote:
> On 2020-12-06 22:40:07 [+0100], Thomas Gleixner wrote:
>> syzbot reported KCSAN data races vs. timer_base::timer_running being set to
>> NULL without holding base::lock in expire_timers().
>>
>> This lo
On Mon, Dec 07 2020 at 01:23, Frederic Weisbecker wrote:
>> --- a/kernel/sched/cputime.c
>> +++ b/kernel/sched/cputime.c
>> @@ -60,7 +60,7 @@ void irqtime_account_irq(struct task_str
>> cpu = smp_processor_id();
>> delta = sched_clock_cpu(cpu) - irqtime->irq_start_time;
>>
On Sun, Dec 06 2020 at 22:40, Corentin Labbe wrote:
> On Sat, Dec 05, 2020 at 08:48:15PM +0100, Thomas Gleixner wrote:
>> So this maps two pages and unmaps the first one. That's all called from
>> sun4i_ss_opti_poll() and the bug is clearly visible there:
>>
On Sun, Dec 06 2020 at 14:47, Jerry Snitselaar wrote:
> Thomas Gleixner @ 2020-12-06 09:38 MST:
>
> I don't know the history behind this bit. I stumbled across it in cscope
> when looking for places using kstat_irqs.
I'm not ranting at you. The i915 people are on Cc.
hrtimer is queued on entry to the work function and avoids an extra
update attempt of the RTC that way.
Reported-by: Miroslav Lichvar
Signed-off-by: Thomas Gleixner
Cc: John Stultz
Cc: Prarit Bhargava
Cc: Jason Gunthorpe
---
include/linux/timex.h |1
kernel/time/ntp
update comments accordingly.
Signed-off-by: Thomas Gleixner
---
drivers/rtc/class.c|9 +++--
drivers/rtc/rtc-cmos.c |2 +-
include/linux/rtc.h| 35 +--
kernel/time/ntp.c | 49 +
4 files c
not the case for the first
invocation. If it's not the same it stores the correct offset and lets the
caller try again. That's not much different from the previous approach
where the first invocation had a pretty low probability to actually hit the
allowed window.
Signed-off-by: Thomas Gleixner
rtc_set_ntp_time() is not really RTC functionality as the code is just a
user of RTC. Move it into the NTP code which allows further cleanups.
Requested-by: Alexandre Belloni
Signed-off-by: Thomas Gleixner
---
drivers/rtc/Makefile |1
drivers/rtc/systohc.c | 61
s actually correct and
the generic implementation of the MC146818 driver got it wrong in 2002 and
it stayed that way until today.
Signed-off-by: Thomas Gleixner
---
drivers/rtc/rtc-mc146818-lib.c | 64 -
1 file changed, 39 insertions(+), 25 deletions(-)
--- a/driver
No need to hold the lock and disable interrupts for doing math.
Signed-off-by: Thomas Gleixner
---
drivers/rtc/rtc-mc146818-lib.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/rtc/rtc-mc146818-lib.c
+++ b/drivers/rtc/rtc-mc146818-lib.c
@@ -135,7 +135,6 @@ int
by a second for this device.
Make the offset -500ms so it works correct.
Signed-off-by: Thomas Gleixner
---
drivers/rtc/rtc-cmos.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -868,6 +868,9 @@ cmos_do_probe(struct device *dev, struct
is an orthogonal problem.
Signed-off-by: Thomas Gleixner
---
drivers/rtc/class.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@ -201,7 +201,7 @@ static struct rtc_device *rtc_allocate_d
device_initialize(>dev);
/* Drivers
Miroslav ran into a situation where the periodic RTC synchronization almost
never was able to hit the time window for the update. That happens due the
usage of delayed_work and the properties of the timer wheel.
While that particular problem is halfways simple to fix this started to
unearth other
...
Reported-by: syzbot+aa7c2385d46c5eba0...@syzkaller.appspotmail.com
Reported-by: syzbot+abea4558531bae1ba...@syzkaller.appspotmail.com
Signed-off-by: Thomas Gleixner
---
kernel/time/timer.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
On Sun, Dec 06 2020 at 17:38, Thomas Gleixner wrote:
> On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote:
>> Now that kstat_irqs is exported, get rid of count_interrupts in
>> i915_pmu.c
>
> May I ask why this has been merged in the first place?
>
> Nothing in
places
which are affected.
Reported-by: syzbot+23a256029191772c2...@syzkaller.appspotmail.com
Reported-by: syzbot+56078ac0b9071335a...@syzkaller.appspotmail.com
Reported-by: syzbot+867130cb240c41f15...@syzkaller.appspotmail.com
Reported-by: Naresh Kamboju
Signed-off-by: Thomas Gleixner
---
kernel
be the last CPU in the
system going offline, which is impossible. There is always at least one CPU
remaining. If online mask would be really empty then the timer duty would
be the least of the resulting problems.
Remove the well meant check simply because it is pointless and confusing.
Signed-off-by: Thomas
on the current CPU can be stopped
or not is moot. In that case the current CPU would have no clockevent
either, so there would be nothing to keep ticking.
Remove it.
Signed-off-by: Thomas Gleixner
---
kernel/time/tick-sched.c |7 ---
1 file changed, 7 deletions(-)
--- a/kernel/time/tick
There have been several reports about KCSAN complaints vs. the racy access
to tick_do_timer_cpu. The syzbot moderation queue has three different
patterns all related to this. There are a few more...
As I know that this is intentional and safe, I did not pay much attention
to it, but Marco
On Sun, Dec 06 2020 at 09:40, James Bottomley wrote:
> On Sun, 2020-12-06 at 17:40 +0100, Thomas Gleixner wrote:
>> On Sat, Dec 05 2020 at 12:39, Jarkko Sakkinen wrote:
>> > On Fri, Dec 04, 2020 at 06:43:37PM -0700, Jerry Snitselaar wrote:
>> > > To try and det
Jerry,
On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote:
> @@ -715,9 +717,23 @@ static irqreturn_t tis_int_handler(int dummy, void
> *dev_id)
> {
> struct tpm_chip *chip = dev_id;
> struct tpm_tis_data *priv = dev_get_drvdata(>dev);
> + static bool check_storm = true;
> +
Jerry,
On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote:
The proper prefix is 'genirq:' git log kernel/irq/irqdesc.c would have
told you.
> To try and detect potential interrupt storms that
> have been occurring with tpm_tis devices it was suggested
> to use kstat_irqs() to get the number
On Sat, Dec 05 2020 at 12:39, Jarkko Sakkinen wrote:
> On Fri, Dec 04, 2020 at 06:43:37PM -0700, Jerry Snitselaar wrote:
>> To try and detect potential interrupt storms that
>> have been occurring with tpm_tis devices it was suggested
>> to use kstat_irqs() to get the number of interrupts.
>>
On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote:
> Now that kstat_irqs is exported, get rid of count_interrupts in
> i915_pmu.c
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -423,22 +423,6 @@ static enum hrtimer_restart i915_sample(struct hrtimer
>
On Thu, Dec 03 2020 at 19:11, Maxim Levitsky wrote:
> + case KVM_SET_TSC_STATE: {
> + struct kvm_tsc_state __user *user_tsc_state = argp;
> + struct kvm_tsc_state tsc_state;
> + u64 host_tsc, wall_nsec;
> +
> + u64 new_guest_tsc,
Linus,
please pull the latest locking/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-urgent-2020-12-06
up to: 4d916140bf28: intel_idle: Build fix
A tiny build fix for a recent change in the intel_idle driver which missed
a CONFIG dependency and
Linus,
please pull the latest x86/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-2020-12-06
up to: 84da009f06e6: x86/sev-es: Use new for_each_insn_prefix() macro to loop
over prefixes bytes
A set of fixes for x86:
- Make the AMD L3 QoS code and
ian Hesselbarth
@@ -9248,7 +9246,6 @@ F:kernel/irq/
IRQCHIP DRIVERS
M: Thomas Gleixner
-M: Jason Cooper
M: Marc Zyngier
L: linux-kernel@vger.kernel.org
S: Maintained
@@ -13394,7 +13391,6 @@ F: drivers/pci/controller/mobiveil/pcie-mobiveil*
PCI DRIVER FOR MV
Linus,
please pull the latest perf/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-2020-12-06
up to: fc17db8aa4c5: perf/x86/intel: Check PEBS status correctly
Two fixes for performance monitoring on X86:
- Add recursion protection to another
On Sat, Dec 05 2020 at 19:18, Thomas Gleixner wrote:
> On Fri, Dec 04 2020 at 20:53, Marco Elver wrote:
> It might be useful to find the actual variable, data member or whatever
> which is involved in the various reports and if there is a match then
> the reports could be aggre
Pavel,
On Sat, Dec 05 2020 at 21:40, Pavel Machek wrote:
> So... what kind of guarantees does this aim to provide / what tasks it
> is useful for?
>
> For real time response, we have other approaches.
Depends on your requirements. Some problems are actually better solved
with busy polling. See
Corentin,
On Sat, Dec 05 2020 at 19:43, Corentin Labbe wrote:
> On Fri, Dec 04, 2020 at 09:58:21PM +0100, Thomas Gleixner wrote:
>> Can you please replace the debug patch with the one below and try again?
>> That stops the trace right on the condition.
>
> Hello, the result c
On Sat, Dec 05 2020 at 17:24, Oleksandr Natalenko wrote:
> On Sat, Dec 05, 2020 at 05:19:18PM +0100, Thomas Gleixner wrote:
>> +/**
>> + * generic_dispatch_irq - Dispatch an interrupt from an interrupt handler
>> + * @irq:The irq number to handle
>>
least work for now.
Thanks,
tglx
---
Subject: genirq, i2c: Provide and use generic_dispatch_irq()
From: Thomas Gleixner
Date: Thu, 03 Dec 2020 19:12:24 +0100
Carlos reported that on his system booting with 'threadirqs' on the command
line result in the following warning:
irq 31 handler irq_defau
On Fri, Dec 04 2020 at 20:53, Marco Elver wrote:
> On Fri, 4 Dec 2020 at 20:04, Naresh Kamboju wrote:
>> LKFT started testing KCSAN enabled kernel from the linux next tree.
>> Here we have found BUG: KCSAN: data-race in tick_nohz_next_event /
>> tick_nohz_stop_tick
>
> Thank you for looking into
On Fri, Dec 04 2020 at 16:41, Bjorn Helgaas wrote:
>
> Applied to for-linus for v5.10 since there's no risk and the bounces
> are annoying.
It's queued in tip irq/urgent already and going to Linus for rc7 :)
On Fri, Dec 04 2020 at 08:05, Ira Weiny wrote:
> So I think I'm going to submit the base patch to Andrew today (with some
> cleanups per the comments in this thread).
Could you please base that on tip core/mm where the kmap_local() muck is
and use kmap_local() right away?
Thanks,
tglx
Balbir,
On Fri, Nov 27 2020 at 17:59, Balbir Singh wrote:
> +enum l1d_flush_out_mitigations {
> + L1D_FLUSH_OUT_OFF,
> + L1D_FLUSH_OUT_ON,
> +};
> +
> +static enum l1d_flush_out_mitigations l1d_flush_out_mitigation
> __ro_after_init = L1D_FLUSH_OUT_ON;
Why default on and why stays it on
On Fri, Nov 27 2020 at 17:59, Balbir Singh wrote:
>
> + /*
> + * Flush only if SMT is disabled as per the contract, which is checked
> + * when the feature is enabled.
> + */
> + if (sched_smt_active() && !this_cpu_read(cpu_info.smt_active) &&
> + (prev_mm &
On Fri, Nov 27 2020 at 17:59, Balbir Singh wrote:
> Detection of task affinities at API opt-in time is not the best
> approach, the approach is to kill the task if it runs on a
> SMT enable core. This is better than not flushing the L1D cache
> when the task switches from a non-SMT core to an SMT
On Fri, Dec 04 2020 at 20:27, Corentin Labbe wrote:
> On Fri, Dec 04, 2020 at 04:08:27PM +0100, Thomas Gleixner wrote:
>> On Fri, Dec 04 2020 at 14:26, Corentin Labbe wrote:
>> > On Fri, Dec 04, 2020 at 12:34:05AM +0100, Thomas Gleixner wrote:
>> >> The unmap comes fr
From: Thomas Gleixner
A barrier() in a tight loop which waits for something to happen on a remote
CPU is a pointless exercise. Replace it with cpu_relax() which allows HT
siblings to make progress.
Signed-off-by: Thomas Gleixner
---
include/linux/interrupt.h |3 ++-
1 file changed, 2
To allow reuse of the bulk of softirq processing code for RT and to avoid
#ifdeffery all over the place, split protections for various code sections
out into inline helpers so the RT variant can just replace them in one go.
Signed-off-by: Thomas Gleixner
---
V2: Adapt to Frederics rework
From: Thomas Gleixner
Provide a local lock based serialization for soft interrupts on RT which
allows the local_bh_disabled() sections and servicing soft interrupts to be
preemptible.
Provide the necessary inline helpers which allow to reuse the bulk of the
softirq processing code.
Signed-off
From: Thomas Gleixner
tasklet_kill() and tasklet_unlock_wait() spin and wait for the
TASKLET_STATE_SCHED resp. TASKLET_STATE_RUN bit in the tasklet state to be
cleared. This works on !RT nicely because the corresponding execution can
only happen on a different CPU.
On RT softirq processing
From: Thomas Gleixner
Inlines exist for a reason.
Signed-off-by: Thomas Gleixner
---
include/linux/interrupt.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -672,9 +672,9 @@ static inline void
From: Thomas Gleixner
On RT a task which has soft interrupts disabled can block on a lock and
schedule out to idle while soft interrupts are pending. This triggers the
warning in the NOHZ idle code which complains about going idle with pending
soft interrupts. But as the task is blocked soft
From: Thomas Gleixner
Soft interrupt disabled sections can legitimately be preempted or schedule
out when blocking on a lock on RT enabled kernels so the RCU preempt check
warning has to be disabled for RT kernels.
Signed-off-by: Thomas Gleixner
---
include/linux/rcupdate.h |3 ++-
1 file
and$0x00,%eax
Reported-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
V2: New patch
---
kernel/sched/cputime.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -60,7 +60,7 @@ void
From: Thomas Gleixner
RT requires the softirq processing and local bottomhalf disabled regions to
be preemptible. Using the normal preempt count based serialization is
therefore not possible because this implicitely disables preemption.
RT kernels use a per CPU local lock to serialize
RT runs softirq processing always in thread context and it requires that
both the softirq execution and the BH disabled sections are preemptible.
This is achieved by serialization through per CPU local locks and
substituting a few parts of the existing softirq processing code with
helper
On Fri, Dec 04 2020 at 14:26, Corentin Labbe wrote:
> On Fri, Dec 04, 2020 at 12:34:05AM +0100, Thomas Gleixner wrote:
>> The unmap comes from sg_miter_stop() and looking at the previous
>> map/unmap cycles there are never nested maps.
>>
>> [ 996.943030] cryptset
On Thu, Dec 03 2020 at 18:36, Jason Gunthorpe wrote:
> On Thu, Dec 03, 2020 at 10:31:02PM +0100, Thomas Gleixner wrote:
>> On Thu, Dec 03 2020 at 22:05, Thomas Gleixner wrote:
>> > On Thu, Dec 03 2020 at 12:16, Jason Gunthorpe wrote:
>> > So now we have two options to fi
nce count mechanics provides the required barriers already.
Signed-off-by: Thomas Gleixner
---
Applies on tip timers/core
---
kernel/time/tick-sched.c | 74 +--
1 file changed, 47 insertions(+), 27 deletions(-)
--- a/kernel/time/tick-sched.c
++
On Fri, Dec 04 2020 at 10:51, Alexandre Belloni wrote:
> On 04/12/2020 10:34:13+0100, Thomas Gleixner wrote:
>> So either the RTC knows the requirements for tsched, e.g. the MC14xxx
>> datasheet, or it can retrieve that information from DT or by querying
>> the und
On Thu, Dec 03 2020 at 23:00, Alexandre Belloni wrote:
> On 03/12/2020 22:05:09+0100, Thomas Gleixner wrote:
>> 2) I2C/SPI ...
>>
>>tsched t0 t1 t2
>> transfer(newsec) RTC update (newsec)RTC increments se
The following commit has been merged into the timers/core branch of tip:
Commit-ID: fef92cd2bc04c64bb3743d40c0b4be47aedf9e23
Gitweb:
https://git.kernel.org/tip/fef92cd2bc04c64bb3743d40c0b4be47aedf9e23
Author:Thomas Gleixner
AuthorDate:Fri, 04 Dec 2020 00:39:45 +01:00
On Thu, Dec 03 2020 at 20:23, Daniel Lezcano wrote:
> The following changes since commit b996544916429946bf4934c1c01a306d1690972c:
>
> tick: Get rid of tick_period (2020-11-19 10:48:29 +0100)
>
> are available in the Git repository at:
>
>
On Thu, Dec 03 2020 at 18:38, Corentin Labbe wrote:
> On Wed, Dec 02, 2020 at 09:59:36PM +0100, Thomas Gleixner wrote:
>> On Wed, Dec 02 2020 at 20:55, Corentin Labbe wrote:
>> > On Tue, Dec 01, 2020 at 04:15:08PM +0100, Thomas Gleixner wrote:
>> >
>> &
On Thu, Dec 03 2020 at 22:05, Thomas Gleixner wrote:
> On Thu, Dec 03 2020 at 12:16, Jason Gunthorpe wrote:
> So now we have two options to fix this:
>
>1) Use a negative sync_offset for devices which need #1 above
> (rtc_cmos & similar)
>
> That requires s
On Thu, Dec 03 2020 at 12:16, Jason Gunthorpe wrote:
> On Thu, Dec 03, 2020 at 04:39:21PM +0100, Thomas Gleixner wrote:
>
>> The logic in sync_cmos_clock() and rtc_set_ntp_time() is different as I
>> pointed out: sync_cmos_clock() hands -500ms to rtc_tv_nsec_ok() and
>>
Alexandre,
On Thu, Dec 03 2020 at 18:29, Alexandre Belloni wrote:
> On 03/12/2020 16:39:21+0100, Thomas Gleixner wrote:
>> On Thu, Dec 03 2020 at 03:10, Alexandre Belloni wrote:
>> > On 03/12/2020 02:14:12+0100, Thomas Gleixner wrote:
>> > Coincidentally, I was go
Alexandre,
On Thu, Dec 03 2020 at 03:10, Alexandre Belloni wrote:
> On 03/12/2020 02:14:12+0100, Thomas Gleixner wrote:
>> That said, can somebody answer the one million dollar question which
>> problem is solved by all of this magic nonsense?
>>
> The goal was to remove
Cc+ RTC folks.
On Wed, Dec 02 2020 at 23:08, Thomas Gleixner wrote:
> On Wed, Dec 02 2020 at 16:54, Jason Gunthorpe wrote:
>>> I don't think the timer should be canceled if the ntp_synced() state did
>>> not change. Otherwise every do_adtimex() call will cancel/resta
On Wed, Dec 02 2020 at 16:54, Jason Gunthorpe wrote:
> On Wed, Dec 02, 2020 at 08:21:00PM +0100, Thomas Gleixner wrote:
>> So it will not write immediately. It will run through at least one
>> retry.
>
> Right, bascially this is scheduling a WQ to do sched_sync_hw_clock()
&
On Wed, Dec 02 2020 at 20:55, Corentin Labbe wrote:
> On Tue, Dec 01, 2020 at 04:15:08PM +0100, Thomas Gleixner wrote:
>
> The result could be seen at http://kernel.montjoie.ovh/129768.log
> The log is 9Mb, but the ftrace dump seems not terminated, tell me if you need
>
On Wed, Dec 02 2020 at 12:27, Jason Gunthorpe wrote:
> On Wed, Dec 02, 2020 at 02:44:53PM +0100, Thomas Gleixner wrote:
>> if (IS_ENABLED(CONFIG_GENERIC_CMOS_UPDATE) ||
>> IS_ENABLED(CONFIG_RTC_SYSTOHC))
>> -queue_delayed_work(system_power_e
On Wed, Dec 02 2020 at 16:36, Miroslav Lichvar wrote:
> On Wed, Dec 02, 2020 at 04:07:28PM +0100, Miroslav Lichvar wrote:
>> On Wed, Dec 02, 2020 at 02:44:53PM +0100, Thomas Gleixner wrote:
>> > Something like the completely untested below should make this reliable
>> &
On Tue, Dec 01 2020 at 13:09, Mauro Carvalho Chehab wrote:
> Kernel-doc requires that a kernel-doc markup to be immediately
> below the function prototype, as otherwise it will rename it.
below?
On Tue, Dec 01 2020 at 13:35, Jason Gunthorpe wrote:
> On Tue, Dec 01, 2020 at 06:14:20PM +0100, Miroslav Lichvar wrote:
>> I found no good explanation. It seems to depend on what system is
>> doing, if it's idle, etc. I suspect it's a property of the workqueues
>> that they cannot generally
Hanks,
On Tue, Dec 01 2020 at 21:54, Hanks Chen wrote:
> On Fri, 2020-11-27 at 18:11 +, Marc Zyngier wrote:
>> On 2020-11-27 14:15, Hanks Chen wrote:
>> > + /*
>> > + * No move required, if interrupt is 1 of N IRQ.
>> > + * write current cpu_online_mask into affinity mask.
>> > + */
>>
On Tue, Dec 01 2020 at 16:45, Dexuan Cui wrote:
> The commit f36a74b9345a itself is good, but it causes a panic in a
> Linux VM that runs on a Hyper-V host that doesn't have the 15-bit
> Extended APIC ID support:
> kernel BUG at arch/x86/kernel/apic/io_apic.c:2408!
This has nothing to do with
The following commit has been merged into the core/entry branch of tip:
Commit-ID: 01fe185d95ba3cdd6629859dd911a94de8800562
Gitweb:
https://git.kernel.org/tip/01fe185d95ba3cdd6629859dd911a94de8800562
Author:Thomas Gleixner
AuthorDate:Wed, 02 Dec 2020 01:34:40 +01:00
On Tue, Dec 01 2020 at 15:27, Sven Schnelle wrote:
> this is v2 of the patch. I've split it up the to multiple ones,
> and added documentation. The first patch was basically a hack to demonstrate
> what i need, sorry for not sending a more cleaned up version.
It would have been nice to send it
On Tue, Dec 01 2020 at 15:21, Jonathan Corbet wrote:
> On Fri, 27 Nov 2020 14:32:38 -0500
> Gabriel Krisman Bertazi wrote:
>
>> Explain the interface, provide some background and security notes.
>>
>> Signed-off-by: Gabriel Krisman Bertazi
>> Reviewed-by: Kees Cook
>> Acked-by: Peter Zijlstra
On Tue, Dec 01 2020 at 15:27, Sven Schnelle wrote:
> __do_syscall is the function which gets called by low level entry.S code:
>
> void noinstr __do_syscall(struct pt_regs *regs)
> {
> enter_from_user_mode(regs); /* sets lockdep state, and other
> initial stuff */
>
> /*
>
On Fri, Nov 27 2020 at 14:32, Gabriel Krisman Bertazi wrote:
> +Compatibility layers like Wine need a way to efficiently emulate system
> +calls of only a part of their process - the part that has the
> +incompatible code - while being able to execute native syscalls without
> +a high performance
On Mon, Nov 30 2020 at 15:35, Maxim Levitsky wrote:
> + struct kvm_tsc_info {
> + __u32 flags;
> + __u64 nsec;
> + __u64 tsc;
> + __u64 tsc_adjust;
> + };
> +
> +flags values for ``struct kvm_tsc_info``:
> +
> +``KVM_TSC_INFO_TSC_ADJUST_VALID``
> +
> + ``tsc_adjust`` contains
601 - 700 of 29423 matches
Mail list logo
