On Tue, Dec 01 2020 at 16:01, Peter Zijlstra wrote:
> On Tue, Dec 01, 2020 at 03:35:45PM +0100, Frederic Weisbecker wrote:
>> And that one too makes things simple. But note that
>>
>> account_hardirq_enter_time()
>>
>> will still need some preempt count checks to see if
>> this is a nested
On Tue, Dec 01 2020 at 15:45, Corentin Labbe wrote:
> On Tue, Dec 01, 2020 at 03:16:36PM +0100, Thomas Gleixner wrote:
> In fact the warn was a bit later so I added:
>preempt_disable();
> idx = arch_kmap_local_unmap_idx(kmap_local_idx(), addr);
> - WA
On Tue, Dec 01 2020 at 14:52, Corentin Labbe wrote:
> On Tue, Dec 01, 2020 at 02:28:54PM +0100, Thomas Gleixner wrote:
> The patch made the board too busy logging and fail to boot until the test.
Stupid me. Of course this wants to be conditional.
Thanks,
tglx
---
diff --gi
On Tue, Dec 01 2020 at 08:59, Dmitry Vyukov wrote:
> On Wed, Sep 30, 2020 at 5:29 PM Thomas Gleixner wrote:
>> On Thu, Sep 24 2020 at 12:01, Walter Wu wrote:
>> > Syzbot reports many UAF issues for workqueue or timer, see [1] and [2].
>> > In some of these
On Mon, Nov 30 2020 at 16:16, Marcelo Tosatti wrote:
> Not really. The synchronization logic tries to sync TSCs during
> BIOS boot (and CPU hotplug), because the TSC values are loaded
> sequentially, say:
>
> CPU realtimeTSC val
> vcpu0 0 usec 0
> vcpu1
On Mon, Nov 30 2020 at 16:16, Marcelo Tosatti wrote:
>> Besides, Linux guests don't sync the TSC via IA32_TSC write,
>> but rather use IA32_TSC_ADJUST which currently doesn't participate
>> in the tsc sync heruistics.
>
> Linux should not try to sync the TSC with IA32_TSC_ADJUST. It expects
> the
On Tue, Dec 01 2020 at 12:40, Frederic Weisbecker wrote:
> On Tue, Dec 01, 2020 at 12:33:26PM +0100, Thomas Gleixner wrote:
>> >/*
>> > * We do not account for softirq time from ksoftirqd here.
>> > * We want to continue accounting so
On Tue, Dec 01 2020 at 14:01, Corentin Labbe wrote:
> +[ 213.050152] [ cut here ]
> +[ 213.050207] WARNING: CPU: 0 PID: 18430 at mm/highmem.c:581
> kunmap_local_indexed+0x194/0x1d4
> +[ 213.050214] Modules linked in: sm4_generic authenc vmac xcbc hmac
>
On Tue, Dec 01 2020 at 10:20, Peter Zijlstra wrote:
> On Tue, Dec 01, 2020 at 01:12:25AM +0100, Frederic Weisbecker wrote:
> Why not something like:
>
> void irqtime_account_irq(struct task_struct *curr, unsigned int offset)
> {
> struct irqtime *irqtime = this_cpu_ptr(_irqtime);
>
Sven,
On Tue, Dec 01 2020 at 09:35, Sven Schnelle wrote:
> On s390, we can not call one function which sets lockdep
> state and do the syscall work at the same time. There add
> make enter_from_user_mode() and exit_to_user_mode() public, and
> add syscall_exit_to_user_mode1() which does the same
On Tue, Dec 01 2020 at 10:18, Laurențiu Nicola wrote:
> On Tue, Dec 1, 2020, at 01:34, Thomas Gleixner wrote:
>> Just for completeness sake. Can you provide the line in /proc/interrupts
>> for irq 7 on that machine?
>
>
> 55: 0 0 0
On Mon, Nov 30 2020 at 19:22, Laurențiu Nicola wrote:
> On Mon, Nov 30, 2020, at 18:56, Thomas Gleixner wrote:
>> > That's right, sorry. It still boots, but it's no longer "quiet",
>> > that's what I meant.
>>
>> Right, but surpressing that is not a
On Tue, Dec 01 2020 at 01:35, John Garry wrote:
> Add a function to allow the affinity of an interrupt be switched to
> managed, such that interrupts allocated for platform devices may be
> managed.
Could you please add a paragraph which explains the limitations of that
interface?
> +/**
> + *
Alexey,
On Tue, Nov 24 2020 at 17:17, Alexey Kardashevskiy wrote:
> This moves hierarchical domain's irqs cleanup into the kobject release
> hook to make irq_domain_free_irqs() as simple as kobject_put.
Truly simple: Simply broken in multiple ways.
CONFIG_SPARSE_IRQ=n is now completely
On Mon, Nov 30 2020 at 23:18, Thomas Gleixner wrote:
> On Tue, Nov 24 2020 at 17:17, Alexey Kardashevskiy wrote:
>> We want to make the irq_desc.kobj's release hook free associated resources
>> but we do not want to pollute the irqdesc code with domains.
>
> Can you please de
Alexey,
On Tue, Nov 24 2020 at 17:17, Alexey Kardashevskiy wrote:
> We want to make the irq_desc.kobj's release hook free associated resources
> but we do not want to pollute the irqdesc code with domains.
Can you please describe your changelog in factual ways without 'we and I
and want'? See
Alexey,
On Tue, Nov 24 2020 at 17:17, Alexey Kardashevskiy wrote:
> There are 10 users of __irq_domain_alloc_irqs() and only one - IOAPIC -
> passes realloc==true. There is no obvious reason for handling this
> specific case in the generic code.
There is also no obvious reason for _NOT_ handling
Feng,
On Fri, Nov 27 2020 at 14:11, Feng Tang wrote:
> On Fri, Nov 27, 2020 at 12:27:34AM +0100, Thomas Gleixner wrote:
>> On Thu, Nov 26 2020 at 09:24, Feng Tang wrote:
>> Yes, that can happen. But OTOH, we should start to think about the
>> requirements for using the TSC
Laurentiu,
On Fri, Nov 27 2020 at 10:03, Laurențiu Nicola wrote:
> On Fri, Nov 27, 2020, at 02:12, Thomas Gleixner wrote:
>> On Thu, Nov 26 2020 at 09:47, Laurențiu Nicola wrote:
>> > These messages are described as warnings in the MSI code.
>>
>> Where and what has
Stefan,
On Fri, Nov 27 2020 at 10:17, Stefan Bühler wrote:
> On 11/27/20 12:45 AM, Thomas Gleixner wrote:
>> Can you please run this as root so the Capabilities are accessible?
>
> My bad, sorry. I did intend to run it as root, but should have checked
> the output. Again
On Fri, Nov 27 2020 at 13:54, Andy Shevchenko wrote:
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging.
Linus,
please pull the latest locking/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-urgent-2020-11-29
up to: 6e1d2bc675bd: intel_idle: Fix intel_idle() vs tracing
Yet two more places which invoke tracing from RCU disabled regions in the
idle path.
Linus,
please pull the latest irq/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
irq-urgent-2020-11-29
up to: 7032908cd584: Merge tag 'irqchip-fixes-5.10-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent
Two fixes for
On Thu, Nov 26 2020 at 09:47, Laurențiu Nicola wrote:
> These messages are described as warnings in the MSI code.
Where and what has MSI to do with these messages?
> Spotted because they break quiet boot on a Ryzen 5000 CPU.
They don't break the boot.
The machine boots fine, but having
Stefan,
On Wed, Nov 25 2020 at 14:41, Stefan Bühler wrote:
> On 11/25/20 12:54 PM, Thomas Gleixner wrote:
>> On Wed, Sep 16 2020 at 12:12, Stefan Bühler wrote:
>> Can you please provide the output of:
>>
>> for ID in 05:00.0 06:00.0 06:00.1 06:01.0 06:01.1; do
Feng,
On Thu, Nov 26 2020 at 09:24, Feng Tang wrote:
> On Wed, Nov 25, 2020 at 01:46:23PM +0100, Thomas Gleixner wrote:
>> Now the more interesting question is why this needs to be a PCI quirk in
>> the first place. Can't we just disable the HPET based on family/
On Wed, Nov 25 2020 at 13:13, Bjorn Helgaas wrote:
> On Wed, Nov 25, 2020 at 01:46:23PM +0100, Thomas Gleixner wrote:
>> Now the more interesting question is why this needs to be a PCI quirk in
>> the first place. Can't we just disable the HPET based on family/model
>> quir
Carlos, Petr,
On Wed, Nov 25 2020 at 15:37, Carlos O'Donell wrote:
> On 11/19/20 7:14 PM, Thomas Gleixner wrote:
>> So from my point of view asking for distorted time still _is_ a request
>> for ponies.
>
> I'm happy if you say it's more work than the value it provides.
Laurent,
On Wed, Nov 25 2020 at 12:16, Laurent Vivier wrote:
The proper subsystem prefix is: 'genirq/irqdomain:' and the first letter
after the colon wants to be uppercase.
> This function adds an affinity parameter to irq_create_mapping().
> This parameter is needed to pass it to
On Thu, Nov 19 2020 at 12:19, Bjorn Helgaas wrote:
> 62187910b0fc ("x86/intel: Add quirk to disable HPET for the Baytrail
> platform") implemented force_disable_hpet() as a special early quirk.
> These run before the PCI core is initialized and depend on the
> x86/pci/early.c accessors that use
Stefan,
On Wed, Sep 16 2020 at 12:12, Stefan Bühler wrote:
sorry for the delay. This fell through the cracks.
> this quirk breaks our serial ports PCIe card (i.e. we don't see any
> output from the connected devices; no idea whether anything we send
> reaches them):
>
> 05:00.0 PCI bridge:
Cyril,
On Tue, Nov 24 2020 at 16:38, Cyril Hrubis wrote:
> Thomas can you please have a look? It looks like we can get the SysV IPC
> ctime to be one second off compared to what we get from realtime clock.
>
> Do we care to get this fixed in kernel or should we fix the tests?
See below.
>> This
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: 7032908cd5842af9710de4815a456241b5e6d2d1
Gitweb:
https://git.kernel.org/tip/7032908cd5842af9710de4815a456241b5e6d2d1
Author:Thomas Gleixner
AuthorDate:Wed, 25 Nov 2020 00:56:28 +01:00
On Tue, Nov 24 2020 at 21:03, Laurent Vivier wrote:
> With virtio multiqueue, normally each queue IRQ is mapped to a CPU.
>
> This problem cannot be shown on x86_64 for two reasons:
There is only _ONE_ reason why this is not a problem on x86. x86 uses
the generic PCI/MSI domain which supports
On Tue, Nov 24 2020 at 21:03, Laurent Vivier wrote:
> This parameter is needed to pass it to irq_domain_alloc_descs().
>
> This seems to have been missed by
> o06ee6d571f0e ("genirq: Add affinity hint to irq allocation")
No, this has not been missed at all. There was and is no reason to do
this.
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 5fbda3ecd14a5343644979c98d6eb65b7e7de9d8
Gitweb:
https://git.kernel.org/tip/5fbda3ecd14a5343644979c98d6eb65b7e7de9d8
Author:Thomas Gleixner
AuthorDate:Wed, 18 Nov 2020 20:48:43 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 14df32670291588036a498051a54cd8462d7f611
Gitweb:
https://git.kernel.org/tip/14df32670291588036a498051a54cd8462d7f611
Author:Thomas Gleixner
AuthorDate:Wed, 18 Nov 2020 20:48:41 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: f3ba3c710ac5a30cd058615a9eb62d2ad95bb782
Gitweb:
https://git.kernel.org/tip/f3ba3c710ac5a30cd058615a9eb62d2ad95bb782
Author:Thomas Gleixner
AuthorDate:Wed, 18 Nov 2020 20:48:44 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 6e799cb69a70eedbb41561b750f7180c12cff280
Gitweb:
https://git.kernel.org/tip/6e799cb69a70eedbb41561b750f7180c12cff280
Author:Thomas Gleixner
AuthorDate:Wed, 18 Nov 2020 20:48:39 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: e66f6e095486f0210fcf3c5eb3ecf13fa348be4c
Gitweb:
https://git.kernel.org/tip/e66f6e095486f0210fcf3c5eb3ecf13fa348be4c
Author:Thomas Gleixner
AuthorDate:Wed, 18 Nov 2020 20:48:45 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 0e91a0c6984c837a7c6760e3f28e8e1c532abf87
Gitweb:
https://git.kernel.org/tip/0e91a0c6984c837a7c6760e3f28e8e1c532abf87
Author:Thomas Gleixner
AuthorDate:Wed, 18 Nov 2020 20:48:40 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 7e015a279853e747f5d4f957855ec5310848c501
Gitweb:
https://git.kernel.org/tip/7e015a279853e747f5d4f957855ec5310848c501
Author:Thomas Gleixner
AuthorDate:Wed, 18 Nov 2020 20:48:46 +01:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 74d862b682f51e45d25b95b1ecf212428a4967b0
Gitweb:
https://git.kernel.org/tip/74d862b682f51e45d25b95b1ecf212428a4967b0
Author:Thomas Gleixner
AuthorDate:Wed, 18 Nov 2020 20:48:42 +01:00
Frederic,
On Tue, Nov 24 2020 at 01:13, Frederic Weisbecker wrote:
> On Tue, Nov 24, 2020 at 01:06:15AM +0100, Thomas Gleixner wrote:
>> Good point. Haven't thought about that. Let me have a look again.
>
> But I'm cooking a patchset which moves account_irq_enter_time() after
&
On Tue, Nov 24 2020 at 00:58, Frederic Weisbecker wrote:
> On Mon, Nov 23, 2020 at 08:27:33PM +0100, Thomas Gleixner wrote:
>> On Mon, Nov 23 2020 at 14:44, Frederic Weisbecker wrote:
>> > On Fri, Nov 13, 2020 at 03:02:21PM +0100, Thomas Gleixner wrote:
>> >> + /*
&
On Mon, Nov 23 2020 at 14:07, Andy Lutomirski wrote:
>> On Nov 23, 2020, at 1:25 PM, Thomas Gleixner wrote:
>> On Mon, Nov 23 2020 at 22:15, Thomas Gleixner wrote:
>>>> On Sun, Nov 22 2020 at 15:16, Andy Lutomirski wrote:
>>>>
>>>> The commo
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 9f112156f8da016df2dcbe77108e5b070aa58992
Gitweb:
https://git.kernel.org/tip/9f112156f8da016df2dcbe77108e5b070aa58992
Author:Thomas Gleixner
AuthorDate:Fri, 13 Nov 2020 15:02:08 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: fe3f1d5d7cd3062c0cb8fe70dd77470019dedd19
Gitweb:
https://git.kernel.org/tip/fe3f1d5d7cd3062c0cb8fe70dd77470019dedd19
Author:Thomas Gleixner
AuthorDate:Fri, 13 Nov 2020 15:02:09 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 7fd70c65faacd39628ba5f670be6490010c8132f
Gitweb:
https://git.kernel.org/tip/7fd70c65faacd39628ba5f670be6490010c8132f
Author:Thomas Gleixner
AuthorDate:Fri, 13 Nov 2020 15:02:12 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 769dda58d1f647a45270db2f02efe2e2de856709
Gitweb:
https://git.kernel.org/tip/769dda58d1f647a45270db2f02efe2e2de856709
Author:Thomas Gleixner
AuthorDate:Fri, 13 Nov 2020 15:02:10 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: e83694a7b249de63beb1d8b45474b796dce3cd45
Gitweb:
https://git.kernel.org/tip/e83694a7b249de63beb1d8b45474b796dce3cd45
Author:Thomas Gleixner
AuthorDate:Fri, 13 Nov 2020 15:02:11 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 2cb0837e56e1b04b773ed05df72297de4e010063
Gitweb:
https://git.kernel.org/tip/2cb0837e56e1b04b773ed05df72297de4e010063
Author:Thomas Gleixner
AuthorDate:Fri, 13 Nov 2020 15:02:13 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: fd15c1941f0ae0b46d48431d0020edfc843abd33
Gitweb:
https://git.kernel.org/tip/fd15c1941f0ae0b46d48431d0020edfc843abd33
Author:Thomas Gleixner
AuthorDate:Fri, 13 Nov 2020 15:02:15 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 1adb99eabce9deefb55985c19181d375ba6ff4aa
Gitweb:
https://git.kernel.org/tip/1adb99eabce9deefb55985c19181d375ba6ff4aa
Author:Thomas Gleixner
AuthorDate:Fri, 13 Nov 2020 15:02:14 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: e091bc90cd2d65f48e4688faead2911558d177d7
Gitweb:
https://git.kernel.org/tip/e091bc90cd2d65f48e4688faead2911558d177d7
Author:Thomas Gleixner
AuthorDate:Fri, 13 Nov 2020 15:02:16 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 15115830c88751ba83068aa37da996602ddc6a61
Gitweb:
https://git.kernel.org/tip/15115830c88751ba83068aa37da996602ddc6a61
Author:Thomas Gleixner
AuthorDate:Fri, 13 Nov 2020 15:02:17 +01:00
The following commit has been merged into the irq/core branch of tip:
Commit-ID: ae9ef58996a4447dd44aa638759f913c883ba816
Gitweb:
https://git.kernel.org/tip/ae9ef58996a4447dd44aa638759f913c883ba816
Author:Thomas Gleixner
AuthorDate:Fri, 13 Nov 2020 15:02:18 +01:00
On Mon, Nov 23 2020 at 17:58, Alex Belits wrote:
> From: Yuri Norov
>
> For nohz_full CPUs the desirable behavior is to receive interrupts
> generated by tick_nohz_full_kick_cpu(). But for hard isolation it's
> obviously not desirable because it breaks isolation.
>
> This patch adds check for it.
Alex,
On Mon, Nov 23 2020 at 17:57, Alex Belits wrote:
> Kernel entry and exit functions for task isolation are added to context
> tracking and common entry points. Common handling of pending work on exit
> to userspace now processes isolation breaking, cleanup and start.
Again: You fail to
Alex,
On Mon, Nov 23 2020 at 17:56, Alex Belits wrote:
> .../admin-guide/kernel-parameters.txt | 6 +
> drivers/base/cpu.c| 23 +
> include/linux/hrtimer.h | 4 +
> include/linux/isolation.h | 326
>
On Mon, Nov 23 2020 at 17:56, Alex Belits wrote:
> This function checks to see if a vmstat worker is not running,
> and the vmstat diffs don't require an update. The function is
> called from the task-isolation code to see if we need to
> actually do some work to quiet vmstat.
A changelog has to
Alex,
On Mon, Nov 23 2020 at 17:56, Alex Belits wrote:
why are you insisting on adding 'task_isolation: ' as prefix to every
single patch? That's wrong as I explained before.
The prefix denotes the affected subsystem and 'task_isolation' is _NOT_
a subsystem. It's the project name you are using
On Mon, Nov 23 2020 at 22:15, Thomas Gleixner wrote:
> On Sun, Nov 22 2020 at 15:16, Andy Lutomirski wrote:
>> On Fri, Nov 20, 2020 at 1:29 AM Peter Zijlstra wrote:
>> The common case of a CPU switching back and forth between a small
>> number of mms would have no
On Sun, Nov 22 2020 at 15:16, Andy Lutomirski wrote:
> On Fri, Nov 20, 2020 at 1:29 AM Peter Zijlstra wrote:
>> Anyway, clearly I'm the only one that cares, so I'll just crawl back
>> under my rock...
>
> I'll poke my head out of the rock for a moment, though...
>
> Several years ago, we
On Mon, Nov 23 2020 at 14:44, Frederic Weisbecker wrote:
> On Fri, Nov 13, 2020 at 03:02:21PM +0100, Thomas Gleixner wrote:
>> +/*
>> + * Adjust softirq count to SOFTIRQ_OFFSET which makes
>> + * in_serving_softirq() become true.
>> + */
&
Linus,
please pull the latest sched/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-2020-11-22
up to: 2279f540ea7d: sched/deadline: Fix priority inheritance with multiple
scheduling classes
A couple of scheduler fixes:
- Make the conditional
Linus,
please pull the latest perf/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-2020-11-22
up to: ebd19fc372e3: perf/x86: fix sysfs type mismatches
A single fix for the x86 perf sysfs interfaces which used kobject
attributes instead of device
Linus,
please pull the latest locking/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-urgent-2020-11-22
up to: 43be4388e94b: lockdep: Put graph lock/unlock under lock_recursion
protection
A single fix for lockdep which makes the recursion protection
On Tue, Nov 17 2020 at 13:45, Peter Zijlstra wrote:
> On Tue, Nov 10, 2020 at 12:38:47PM +0100, Sebastian Andrzej Siewior wrote:
>
> Moo... yes this is certainly the easiest solution, because nouveau is a
> horrible rats nest. But when I spoke to Greg KH about this, he suggested
> nouveau ought to
Marc,
On Fri, Nov 20 2020 at 09:20, Marc Zyngier wrote:
> On 2020-11-03 20:32, Thomas Gleixner wrote:
>> On Sun, Nov 01 2020 at 13:14, Marc Zyngier wrote:
>
> More seriously, it seems to me that we have a bit of a
> cross-architecture disconnect here. I have been trying
On Fri, Nov 20 2020 at 01:26, Frederic Weisbecker wrote:
> On Fri, Nov 13, 2020 at 03:02:21PM +0100, Thomas Gleixner wrote:
>> +void __local_bh_disable_ip(unsigned long ip, unsigned int cnt)
>> +{
>> +unsigned long flags;
>> +int newcnt;
>>
On Thu, Nov 19 2020 at 19:28, Peter Zijlstra wrote:
> On Thu, Nov 19, 2020 at 09:23:47AM -0800, Linus Torvalds wrote:
>> Because this is certainly not the only time migration limiting has
>> come up, and no, it has absolutely nothing to do with per-cpu page
>> tables being completely unacceptable.
On Thu, Nov 19 2020 at 13:37, Carlos O'Donell wrote:
> On 11/6/20 7:47 PM, Thomas Gleixner wrote:
>> Would CONFIG_DEBUG_DISTORTED_CLOCK_REALTIME be a way to go? IOW,
>> something which is clearly in the debug section of the kernel which wont
>> get turned on by distro
On Thu, Nov 19 2020 at 20:55, Alexandre Chartre wrote:
> On 11/19/20 8:10 PM, Thomas Gleixner wrote:
> Sorry I mixed up a few thing; I got confused with my own code which is not a
> good sign...
>
> It's not sleeping with the user page-table which, as you mentioned, doesn't
>
On Thu, Nov 19 2020 at 19:56, John Garry wrote:
3) Interrupt has already been switched to managed. Double init is not
really a good sign either.
>>> I just tested that and case 3) would be a problem. I don't see us
>>> clearing the managed flag when free'ing the interrupt. So
On Thu, Nov 19 2020 at 12:59, Andrea Arcangeli wrote:
> If reserved memory is mapped with ioremap_noncache() or ioremap_wc(),
> the kernel correctly splits the direct mapping and marks the PAGE_SIZE
> granular region uncached, so both the virtual direct mapping and the
> second virtual mapping in
The following commit has been merged into the core/mm branch of tip:
Commit-ID: a0e169978303ee5873142599c8c9660b2d296243
Gitweb:
https://git.kernel.org/tip/a0e169978303ee5873142599c8c9660b2d296243
Author:Thomas Gleixner
AuthorDate:Thu, 19 Nov 2020 20:45:03 +01:00
On Tue, Nov 17 2020 at 09:19, Alexandre Chartre wrote:
> On 11/16/20 9:24 PM, Borislav Petkov wrote:
>> On Mon, Nov 16, 2020 at 03:47:36PM +0100, Alexandre Chartre wrote:
>> So PTI was added exactly to *not* have kernel memory mapped in the user
>> page table. You're partially reversing that...
>
On Tue, Nov 17 2020 at 09:42, Alexandre Chartre wrote:
> On 11/17/20 12:06 AM, Andy Lutomirski wrote:
> The PTI stack does have guard pages because it maps only a part of the task
> stack into the user page-table, so pages around the PTI stack are not mapped
> into the user-pagetable (the page
On Mon, Nov 16 2020 at 19:10, Alexandre Chartre wrote:
> On 11/16/20 5:57 PM, Andy Lutomirski wrote:
>> On Mon, Nov 16, 2020 at 6:47 AM Alexandre Chartre
>> wrote:
> When executing more code in the kernel, we are likely to reach a point
> where we need to sleep while we are using the user
On Thu, Nov 19 2020 at 13:18, Frederic Weisbecker wrote:
> On Fri, Nov 13, 2020 at 03:02:19PM +0100, Thomas Gleixner wrote:
>> RT requires the softirq to be preemptible and uses a per CPU local lock to
>> protect BH disabled sections and softirq processing. Therefore RT cannot
>
On Thu, Nov 19 2020 at 09:31, John Garry wrote:
>> 1) Interrupt does not exist. Definitely a full fail
>>
>> 2) Interrupt is already started up. Not a good idea on init() and
>> a clear fail.
>>
>> 3) Interrupt has already been switched to managed. Double init is not
>> really a
On Thu, Nov 19 2020 at 13:25, Chris Wilson wrote:
> Quoting Peter Zijlstra (2020-11-19 13:02:44)
>>
>> Chris, I suspect this is due to i915 calling stop machine with all sorts
>> of locks held. Is there anything to be done about this? stop_machine()
>> is really nasty to begin with.
>>
>> What
On Thu, Nov 19 2020 at 13:12, Peter Zijlstra wrote:
> On Thu, Nov 19, 2020 at 12:51:32PM +0100, Peter Zijlstra wrote:
>> > +void __kmap_local_sched_in(void)
>> > +{
>> > + struct task_struct *tsk = current;
>> > + pte_t *kmap_pte = kmap_get_pte();
>> > + int i;
>> > +
>> > + /* Restore kmaps
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 01cf158e48d2b5ce947430de5896c10f4f7c1822
Gitweb:
https://git.kernel.org/tip/01cf158e48d2b5ce947430de5896c10f4f7c1822
Author:Thomas Gleixner
AuthorDate:Thu, 19 Nov 2020 15:07:19 +01:00
The following commit has been merged into the timers/core branch of tip:
Commit-ID: 7a35bf2a6a871cd0252cd371d741e7d070b53af9
Gitweb:
https://git.kernel.org/tip/7a35bf2a6a871cd0252cd371d741e7d070b53af9
Author:Thomas Gleixner
AuthorDate:Tue, 17 Nov 2020 14:19:47 +01:00
The following commit has been merged into the timers/core branch of tip:
Commit-ID: b996544916429946bf4934c1c01a306d1690972c
Gitweb:
https://git.kernel.org/tip/b996544916429946bf4934c1c01a306d1690972c
Author:Thomas Gleixner
AuthorDate:Tue, 17 Nov 2020 14:19:49 +01:00
The following commit has been merged into the timers/core branch of tip:
Commit-ID: c398960cd82b233886fbff163986f998b5a5c008
Gitweb:
https://git.kernel.org/tip/c398960cd82b233886fbff163986f998b5a5c008
Author:Thomas Gleixner
AuthorDate:Tue, 17 Nov 2020 14:19:44 +01:00
The following commit has been merged into the timers/core branch of tip:
Commit-ID: 372acbbaa80940189593f9d69c7c069955f24f7a
Gitweb:
https://git.kernel.org/tip/372acbbaa80940189593f9d69c7c069955f24f7a
Author:Thomas Gleixner
AuthorDate:Tue, 17 Nov 2020 14:19:45 +01:00
The following commit has been merged into the timers/core branch of tip:
Commit-ID: f73f64d5687192bc8eb7f3d9521ca6256b79f224
Gitweb:
https://git.kernel.org/tip/f73f64d5687192bc8eb7f3d9521ca6256b79f224
Author:Thomas Gleixner
AuthorDate:Tue, 17 Nov 2020 14:19:43 +01:00
This is the outstanding set of patches for the preemptible kmap_*()
implementation. The previous version is here:
https://lore.kernel.org/r/20201103092712.714480...@linutronix.de
The following changes come with it:
- Better debugging for kmap* by enforcing the temporary mappings even for
From: Thomas Gleixner
Replace kmap_atomic_pfn() with kmap_local_pfn() which is preemptible and
can take page faults.
Remove the indirection of the dump page and the related cruft which is not
longer required.
Signed-off-by: Thomas Gleixner
---
V3: New patch
---
arch/x86/kernel/crash_dump_32
From: Thomas Gleixner
Similar to kmap local provide a iomap local variant which only disables
migration, but neither disables pagefaults nor preemption.
Signed-off-by: Thomas Gleixner
---
V3: Restrict migrate disable to the 32bit mapping case and update documentation.
V2: Split out from
use the temporary fixmap mapping path.
Signed-off-by: Thomas Gleixner
---
V4: New patch
---
arch/x86/Kconfig|1 +
arch/x86/include/asm/fixmap.h | 12 +---
arch/x86/include/asm/pgtable_64_types.h |6 +-
3 files changed, 15 insertions(+), 4 deleti
From: Thomas Gleixner
Now that the kmap atomic index is stored in task struct provide a
preemptible variant. On context switch the maps of an outgoing task are
removed and the map of the incoming task are restored. That's obviously
slow, but highmem is slow anyway.
The kmap_local.*() functions
From: Thomas Gleixner
Instead of storing the map per CPU provide and use per task storage. That
prepares for local kmaps which are preemptible.
The context switch code is preparatory and not yet in use because
kmap_atomic() runs with preemption disabled. Will be made usable in the
next step
From: Thomas Gleixner
Now that the scheduler can deal with migrate disable properly, there is no
real compelling reason to make it only available for RT.
There are quite some code pathes which needlessly disable preemption in
order to prevent migration and some constructs like kmap_atomic
but it paves
the way to do so.
Signed-off-by: Thomas Gleixner
---
V4: New patch
---
include/asm-generic/kmap_size.h |2 +-
lib/Kconfig.debug |8
mm/highmem.c|4 ++--
3 files changed, 11 insertions(+), 3 deletions(-)
--- a/include/asm-generic
. This needs to be a seperate config switch
because this only works on architectures which do not have cache aliasing
problems.
Suggested-by: Linus Torvalds
Signed-off-by: Thomas Gleixner
---
V4: New patch
---
lib/Kconfig.debug | 14 ++
mm/highmem.c | 12 +++-
2 files changed
John,
On Wed, Nov 18 2020 at 11:34, John Garry wrote:
>> +/**
>> + * irq_update_affinity_desc - Update affinity management for an interrupt
>> + * @irq:The interrupt number to update
>> + * @affinity: Pointer to the affinity descriptor
>> + *
>> + * This interface can be used to
701 - 800 of 29421 matches
Mail list logo
