On Thu, Nov 12 2020 at 08:26, Bjorn Helgaas wrote:
> On Thu, Nov 12, 2020 at 02:50:42PM +0100, Thomas Gleixner wrote:
>> So I had a closer look and the reason why it only matters for the
>> chained handler case is that
>>
>>__irq_set_handler(..., is_chained =
On Thu, Nov 12 2020 at 15:15, Thomas Gleixner wrote:
> On Thu, Nov 12 2020 at 08:55, Jason Gunthorpe wrote:
>> On Wed, Aug 26, 2020 at 01:16:28PM +0200, Thomas Gleixner wrote:
>> They were unable to bisect further into the series because some of the
>> interior commits don't
Jason,
(trimmed CC list a bit)
On Thu, Nov 12 2020 at 08:55, Jason Gunthorpe wrote:
> On Wed, Aug 26, 2020 at 01:16:28PM +0200, Thomas Gleixner wrote:
> They were unable to bisect further into the series because some of the
> interior commits don't boot :(
>
> When we try to load
On Thu, Nov 12 2020 at 12:28, Thomas Gleixner wrote:
> On Wed, Nov 11 2020 at 16:16, Bjorn Helgaas wrote:
>> On Wed, Nov 11, 2020 at 10:43:55PM +0100, Martin Kaiser wrote:
>> Thomas, it looks like irq_domain_set_info() and msi_domain_ops_init()
>> set the handler itself befor
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 2a656cad337e0e1ca582f58847d7b0c7eeba4dc8
Gitweb:
https://git.kernel.org/tip/2a656cad337e0e1ca582f58847d7b0c7eeba4dc8
Author:Thomas Gleixner
AuthorDate:Thu, 12 Nov 2020 11:59:32 +01:00
On Wed, Nov 11 2020 at 16:16, Bjorn Helgaas wrote:
> On Wed, Nov 11, 2020 at 10:43:55PM +0100, Martin Kaiser wrote:
>> This function uses the error status from irq_set_handler_data().
>> irq_set_chained_handler_and_data() returns no such error status. Is it
>> ok to drop the error handling?
>
>
().
Fixes: 298fa1ad5571 ("highmem: Provide generic variant of kmap_atomic*")
Reported-by: vto...@googlemail.com
Signed-off-by: Thomas Gleixner
---
mm/highmem.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
--- a/mm/highmem.c
+++ b/mm/highmem.c
@@ -426,
Marek,
On Thu, Nov 12 2020 at 09:10, Marek Szyprowski wrote:
> On 03.11.2020 10:27, Thomas Gleixner wrote:
>
> I can do more tests to help fixing this issue. Just let me know what to do.
Just sent out the fix before I saw your report.
https://lore.kernel.org/r/8
Ashok,
On Wed, Nov 11 2020 at 15:03, Ashok Raj wrote:
> On Wed, Nov 11, 2020 at 11:27:28PM +0100, Thomas Gleixner wrote:
>> which is the obvious sane and safe logic. But sure, why am I asking for
>> sane and safe in the context of virtualization?
>
> We can pick how to
On Wed, Nov 11 2020 at 09:36, Steven Rostedt wrote:
> Ingo Molnar wrote:
>> Not sure I understand the "problem 2)" outlined here, but I'm looking
>> forward to your patchset!
>>
> I think I understand it. For things like completions and other "wait for
> events" we have lockdep annotation, but
On Wed, Nov 11 2020 at 08:09, Ashok Raj wrote:
> On Wed, Nov 11, 2020 at 03:41:59PM +, Christoph Hellwig wrote:
>> On Sun, Nov 08, 2020 at 07:36:34PM +, David Woodhouse wrote:
>> > So it does look like we're going to need a hypercall interface to
>> > compose an MSI message on behalf of
The following commit has been merged into the x86/fpu branch of tip:
Commit-ID: cba08c5dc6dc1a906a0b5ddac9a9ac6c9a64f2e8
Gitweb:
https://git.kernel.org/tip/cba08c5dc6dc1a906a0b5ddac9a9ac6c9a64f2e8
Author:Thomas Gleixner
AuthorDate:Tue, 27 Oct 2020 11:09:51 +01:00
The following commit has been merged into the x86/fpu branch of tip:
Commit-ID: 5f0c71278d6848b4809f83af90f28196e1505ab1
Gitweb:
https://git.kernel.org/tip/5f0c71278d6848b4809f83af90f28196e1505ab1
Author:Thomas Gleixner
AuthorDate:Tue, 27 Oct 2020 11:09:50 +01:00
On Wed, Nov 11 2020 at 08:16, David Woodhouse wrote:
> On Tue, 2020-11-10 at 23:48 +0100, Thomas Gleixner wrote:
>> + * IRQCHIP_MSI_EXTID The MSI message created for this chip
>> can
>> + * have an otherwise forbidden ext
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 3015ef4b98f53fe7eba4f5f82f562c0e074d213c
Gitweb:
https://git.kernel.org/tip/3015ef4b98f53fe7eba4f5f82f562c0e074d213c
Author:Thomas Gleixner
AuthorDate:Wed, 26 Aug 2020 14:08:10 +02:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 1cf12e08bc4d50a76b80c42a3109c53d8794a0c9
Gitweb:
https://git.kernel.org/tip/1cf12e08bc4d50a76b80c42a3109c53d8794a0c9
Author:Thomas Gleixner
AuthorDate:Wed, 16 Sep 2020 09:27:18 +02:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: f2469a1fb43f85d243ce72638367fb6e15c33491
Gitweb:
https://git.kernel.org/tip/f2469a1fb43f85d243ce72638367fb6e15c33491
Author:Thomas Gleixner
AuthorDate:Mon, 14 Sep 2020 14:47:28 +02:00
On Tue, Nov 10 2020 at 16:00, Tom Lendacky wrote:
> On 11/10/20 3:30 PM, David Woodhouse wrote:
> [ 15.581115] WARNING: CPU: 6 PID: 1 at arch/x86/kernel/apic/apic.c:2527
> __irq_msi_compose_msg+0x9f/0xb0
> [ 15.581115] Call Trace:
> [ 15.581115] irq_msi_update_msg+0x4d/0x80
> [
On Tue, Nov 10 2020 at 19:21, David Woodhouse wrote:
> On 10 November 2020 18:56:17 GMT, Thomas Gleixner wrote:
>>On Tue, Nov 10 2020 at 18:50, Thomas Gleixner wrote:
>>> On Tue, Nov 10 2020 at 16:33, David Woodhouse wrote:
>>>> If I could get post-5.5 kernels to
Prarit,
On Tue, Nov 10 2020 at 14:24, Prarit Bhargava wrote:
> Occasionally when logging out of the ttyS0 aka serial console I see that
>
> irq 4: Affinity broken due to vector space exhaustion.
>
> *** console shutdown, IRQ released for cpu on socket 1
> *** console starts back up again,
On Tue, Nov 10 2020 at 18:50, Thomas Gleixner wrote:
> On Tue, Nov 10 2020 at 16:33, David Woodhouse wrote:
>> If I could get post-5.5 kernels to boot at all with the AMD IOMMU
>> enabled, I'd have a go at throwing that together now...
>
> It can share the dmar domain code.
On Tue, Nov 10 2020 at 16:33, David Woodhouse wrote:
> On Tue, 2020-11-10 at 10:17 -0600, Tom Lendacky wrote:
>> Yep. The warning started triggering with:
>> 47bea873cf80 ("x86/msi: Only use high bits of MSI address for DMAR unit")
>>
>> Here's the backtrace:
>>
>> [ 15.745929]
The following commit has been merged into the x86/apic branch of tip:
Commit-ID: aec8da04e4d71afdd4ab3025ea34a6517435f363
Gitweb:
https://git.kernel.org/tip/aec8da04e4d71afdd4ab3025ea34a6517435f363
Author:Thomas Gleixner
AuthorDate:Tue, 10 Nov 2020 15:34:32 +01:00
On Tue, Nov 10 2020 at 08:55, Tom Lendacky wrote:
> On 11/10/20 8:34 AM, Thomas Gleixner wrote:
> I was about to send the dmesg output when I saw this. A quick test with
> this change resolves the boot issue, thanks!
/me feels stupid
> I'm still seeing the warning at arch/x86/kernel
On Tue, Nov 10 2020 at 07:10, Borislav Petkov wrote:
> On Mon, Nov 09, 2020 at 05:15:03PM -0600, Tom Lendacky wrote:
>> [ 105.325371] hpet: Lost 9601 RTC interrupts
>> [ 105.485766] hpet: Lost 9600 RTC interrupts
>> [ 105.639182] hpet: Lost 9601 RTC interrupts
>> [ 105.792155] hpet: Lost 9601
Ashok,
On Mon, Nov 09 2020 at 21:14, Ashok Raj wrote:
> On Mon, Nov 09, 2020 at 11:42:29PM +0100, Thomas Gleixner wrote:
>> On Mon, Nov 09 2020 at 13:30, Jason Gunthorpe wrote:
> Approach to IMS is more of a phased approach.
>
> #1 Allow physical device to scale beyond l
On Mon, Nov 09 2020 at 20:59, Ira Weiny wrote:
> On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Also, we can convert the new memcpy_*_page() calls to kmap_local() as well.
> [For now my patch just uses kmap_atomic().]
>
> I've not looked at all of the patches
Ira,
On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> From: Ira Weiny
>
> To correctly support the semantics of kmap() with Kernel protection keys
> (PKS), kmap() may be required to set the protections on multiple
> processors (globally). Enabling PKS globally can be very expensive
> depending
On Mon, Nov 09 2020 at 13:30, Jason Gunthorpe wrote:
> On Mon, Nov 09, 2020 at 12:21:22PM +0100, Thomas Gleixner wrote:
>> >> Is the IOMMU/Interrupt remapping unit able to catch such messages which
>> >> go outside the space to which the guest is allowed to signal to? I
On Mon, Nov 09 2020 at 12:14, Thomas Gleixner wrote:
> On Sun, Nov 08 2020 at 15:58, Ashok Raj wrote:
>> On Sun, Nov 08, 2020 at 07:47:24PM +0100, Thomas Gleixner wrote:
>> But for SIOV devices there is no PASID filtering at the remap level since
>> interrupt messages don't c
On Mon, Nov 09 2020 at 14:14, Stephen Rothwell wrote:
> Today's linux-next merge of the tip tree got a conflict in:
>
> include/linux/sched/signal.h
> include/linux/tracehook.h
> kernel/signal.c
> kernel/task_work.c
>
> between commits:
>
> fdb5f027ce66 ("task_work: use TIF_NOTIFY_SIGNAL
On Sun, Nov 08 2020 at 15:58, Ashok Raj wrote:
> On Sun, Nov 08, 2020 at 07:47:24PM +0100, Thomas Gleixner wrote:
>>
>>
>> Now if we look at the virtualization scenario and device hand through
>> then the structure in the guest view is not any different from th
On Fri, Nov 06 2020 at 14:06, Alexey Kardashevskiy wrote:
> Hi,
>
> This one seems to be broken in the domain associating part so please
> ignore it, I'll post v3 soon. Thanks,
When you do that please use a proper subject line:
[ PATCH vN ] $subsystem: Shortlog
and to find the subsystem
On Sun, Nov 08 2020 at 22:09, David Woodhouse wrote:
>> On Fri, Nov 06 2020 at 09:14, Jason Gunthorpe wrote:
>>> On Fri, Nov 06, 2020 at 09:48:34AM +, Tian, Kevin wrote:
>>> For instance you could put a "disable IMS" flag in the ACPI tables, in
>>> the config space of the emuulated root port,
On Sun, Nov 08 2020 at 19:36, David Woodhouse wrote:
> On Sun, 2020-11-08 at 19:47 +0100, Thomas Gleixner wrote:
>> So this needs some thought.
>
> The problem here is that Intel implemented interrupt remapping in a way
> which is anathema to structured, ordered IRQ domains
On Fri, Nov 06 2020 at 09:14, Jason Gunthorpe wrote:
> On Fri, Nov 06, 2020 at 09:48:34AM +, Tian, Kevin wrote:
> For instance you could put a "disable IMS" flag in the ACPI tables, in
> the config space of the emuulated root port, or any other areas that
> clearly belong to the platform.
>
>
On Fri, Nov 06 2020 at 20:12, Jason Gunthorpe wrote:
> All IMS device drivers will work correctly. No VMM device emulation is
> ever needed to translate addr/data pairs.
>
> Earlier in this thread Kevin said hyper-v is already working this way,
> even for MSI/MSI-X. To me this says it is
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-08
up to: 82768a86c646: dt-bindings: irqchip: ti, sci-inta: Fix diagram
indentation for unmapped events
A set of fixes for interrupt chip drivers:
- Fix
Linus,
please pull the latest x86/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-2020-11-08
up to: 801284f97378: x86/platform/uv: Recognize UV5 hubless system identifier
A set of x86 fixes:
- Use SYM_FUNC_START_WEAK in the mem* ASM functions
that the lockdep interrupt state needs not to be established before calling
the RCU check.
Thanks,
tglx
-->
Thomas Gleixner (1):
entry: Fix the incorrect ordering of lockdep and RCU check
kernel/entry/common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deleti
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-08
up to: 9f5d1c336a10: futex: Handle transient "ownerless" rtmutex state
correctly
A single fix for the futex code where an intermediate state in
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-08
up to: 7bdb157cdebb: perf/core: Fix a memory leak in
perf_event_parse_addr_filter()
A single fix for the perf core plugging a memory leak in the
On Sat, Nov 07 2020 at 18:05, Mike Galbraith wrote:
> On Fri, 2020-11-06 at 21:26 +, tip-bot2 for Mike Galbraith wrote:
>> +if (unlikely(!newowner)) {
>> +ret = -EAGAIN;
> ^^^
>
> My box just discovered an unnoticed typo. That 'ret'
On Thu, Nov 05 2020 at 12:25, Carlos O'Donell wrote:
> On 10/30/20 9:38 PM, Thomas Gleixner wrote:
> If kata grows up quickly perhaps this entire problem becomes solved, but until
> then I continue to have a testing need for a distinct CLOCK_REALTIME in a
> time namespace
On Fri, Nov 06 2020 at 09:48, Kevin Tian wrote:
>> From: Jason Gunthorpe
>> On Wed, Nov 04, 2020 at 01:34:08PM +, Tian, Kevin wrote:
>> The interrupt controller is responsible to create an addr/data pair
>> for an interrupt message. It sets the message format and ensures it
>> routes to the
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 13f876ba77ebd5125799bb042201f22cf73df154
Gitweb:
https://git.kernel.org/tip/13f876ba77ebd5125799bb042201f22cf73df154
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:34 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 629ed3f7dad2a914b3a89fad49b358e363e3e6d1
Gitweb:
https://git.kernel.org/tip/629ed3f7dad2a914b3a89fad49b358e363e3e6d1
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:29 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 351191ad55c8a1eccaf23e4187c62056229c0779
Gitweb:
https://git.kernel.org/tip/351191ad55c8a1eccaf23e4187c62056229c0779
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:32 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 5af627a043e39d3226eecd75753dcd2c920c16ec
Gitweb:
https://git.kernel.org/tip/5af627a043e39d3226eecd75753dcd2c920c16ec
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:23 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: a4c33e83bca133ff979e13c784c7605e1ac143df
Gitweb:
https://git.kernel.org/tip/a4c33e83bca133ff979e13c784c7605e1ac143df
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:25 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 2a15ba82fa6ca3f35502b3060f22118a938d2889
Gitweb:
https://git.kernel.org/tip/2a15ba82fa6ca3f35502b3060f22118a938d2889
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:22 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 3293efa9780712ad8504689e0c296d2bd33827d5
Gitweb:
https://git.kernel.org/tip/3293efa9780712ad8504689e0c296d2bd33827d5
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:28 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 7ac1b26b0a7288fc8f87aa8978891375f23740b2
Gitweb:
https://git.kernel.org/tip/7ac1b26b0a7288fc8f87aa8978891375f23740b2
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:24 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 3c1016b53c311906878c703af1e2b29855a9a962
Gitweb:
https://git.kernel.org/tip/3c1016b53c311906878c703af1e2b29855a9a962
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:31 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 9bf6f7bab3bad4b30f108fca25aa5297dff0973f
Gitweb:
https://git.kernel.org/tip/9bf6f7bab3bad4b30f108fca25aa5297dff0973f
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:33 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 16675dda9355505245b89dd50723a2754819594b
Gitweb:
https://git.kernel.org/tip/16675dda9355505245b89dd50723a2754819594b
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:13 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 389755c250814185938f5b04334a4f0184c30647
Gitweb:
https://git.kernel.org/tip/389755c250814185938f5b04334a4f0184c30647
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:19 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: d7029e4549691ecaf1ead536d3322a00bda85659
Gitweb:
https://git.kernel.org/tip/d7029e4549691ecaf1ead536d3322a00bda85659
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:30 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 157e118b55113d1e6c7f8ddfcec0a1dbf3a69511
Gitweb:
https://git.kernel.org/tip/157e118b55113d1e6c7f8ddfcec0a1dbf3a69511
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:20 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: b819fd9da38508e0504624b87d9983fcc4237f3c
Gitweb:
https://git.kernel.org/tip/b819fd9da38508e0504624b87d9983fcc4237f3c
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:14 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: e8f147dc3f1f6b4c27b2eeaf82df4f469d80d469
Gitweb:
https://git.kernel.org/tip/e8f147dc3f1f6b4c27b2eeaf82df4f469d80d469
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:15 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 673afbace459ae6fd8d03bda410e0a9f10438c99
Gitweb:
https://git.kernel.org/tip/673afbace459ae6fd8d03bda410e0a9f10438c99
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:16 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 298fa1ad5571f59cb3ca5497a9455f36867f065e
Gitweb:
https://git.kernel.org/tip/298fa1ad5571f59cb3ca5497a9455f36867f065e
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:18 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 4f8b96cd47b06f1e3ec71c1a3216113efe8dbfb5
Gitweb:
https://git.kernel.org/tip/4f8b96cd47b06f1e3ec71c1a3216113efe8dbfb5
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:17 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 5f037ea3b26767e0b1bdc522948321b282268b49
Gitweb:
https://git.kernel.org/tip/5f037ea3b26767e0b1bdc522948321b282268b49
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:26 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 39cac191ff37939544af80d5d2af6b870fd94c9b
Gitweb:
https://git.kernel.org/tip/39cac191ff37939544af80d5d2af6b870fd94c9b
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:21 +01:00
The following commit has been merged into the core/mm branch of tip:
Commit-ID: 47da42b27a56f3ee5abace2858b69e277703f707
Gitweb:
https://git.kernel.org/tip/47da42b27a56f3ee5abace2858b69e277703f707
Author:Thomas Gleixner
AuthorDate:Tue, 03 Nov 2020 10:27:27 +01:00
On Thu, Nov 05 2020 at 09:20, Marc Zyngier wrote:
> On 2020-11-04 23:14, Thomas Gleixner wrote:
>> /* Resource alignment requirements */
>> resource_size_t (*align_resource)(struct pci_dev *dev,
>
> If that's the direction of travel, we also need something like thi
On Wed, Nov 04 2020 at 16:57, Andrea Arcangeli wrote:
> ---
> Documentation/admin-guide/kernel-parameters.txt | 5 ++---
Is Documentation/admin-guide/hw-vuln/* still correct? If not, please
fix that as well.
Aside of that please send patches in the proper format so they do not
need manual
Frank,
On Wed, Nov 04 2020 at 17:49, Frank Wunderlich wrote:
>> Von: "Thomas Gleixner"
>> Any architecture which selects PCI_MSI_ARCH_FALLBACKS and does not have
>> irqdomain support runs into:
>>
>> if (!d)
>> bus->bus_flags |
The following commit has been merged into the core/entry branch of tip:
Commit-ID: b6be002bcd1dd1dedb926abf3c90c794eacb77dc
Gitweb:
https://git.kernel.org/tip/b6be002bcd1dd1dedb926abf3c90c794eacb77dc
Author:Thomas Gleixner
AuthorDate:Mon, 02 Nov 2020 12:53:16 -08:00
On Wed, Nov 04 2020 at 09:46, Ira Weiny wrote:
> On Tue, Nov 03, 2020 at 12:36:16AM +0100, Thomas Gleixner wrote:
>> This is the wrong ordering, really.
>>
>> x86/entry: Move nmi entry/exit into common code
>>
>> is a general cleanup and has abso
The following commit has been merged into the core/urgent branch of tip:
Commit-ID: 9d820f68b2bdba5b2e7bf135123c3f57c5051d05
Gitweb:
https://git.kernel.org/tip/9d820f68b2bdba5b2e7bf135123c3f57c5051d05
Author:Thomas Gleixner
AuthorDate:Wed, 04 Nov 2020 14:06:23 +01:00
On Wed, Nov 04 2020 at 16:12, Thomas Gleixner wrote:
> From: Mike Galbraith
>
> Gratian managed to trigger the BUG_ON(!newowner) in fixup_pi_state_owner().
> This is one possible chain of events leading to this:
>
> Task Prio Operation
> T1 120 lock(F)
&
("futex: Avoid violating the 10th rule of futex")
Reported-by: Gratian Crisan
Signed-off-by: Mike Galbraith
Signed-off-by: Thomas Gleixner
Cc: sta...@vger.kernel.org
Link: https://lore.kernel.org/r/87a6w6x7bb@ni.com
---
kernel/futex.c | 16 ++--
1 file chan
On Wed, Nov 04 2020 at 12:17, Thomas Gleixner wrote:
> On Wed, Nov 04 2020 at 11:24, Thomas Gleixner wrote:
>> On Wed, Nov 04 2020 at 08:42, Mike Galbraith wrote:
>>> On Wed, 2020-11-04 at 01:56 +0100, Mike Galbraith wrote:
>>> --- a/kernel/futex.c
>>> +++ b/ke
as for the idle case and tell lockdep about the
irq state change first, invoke the RCU check and then do the lockdep and
tracer update.
Fixes: a5497bab5f72 ("entry: Provide generic interrupt entry/exit code")
Reported-by: Mark Rutland
Signed-off-by: Thomas Gleixner
Cc: sta...@vger.kernel.org
-
On Wed, Nov 04 2020 at 11:24, Thomas Gleixner wrote:
> On Wed, Nov 04 2020 at 08:42, Mike Galbraith wrote:
>> On Wed, 2020-11-04 at 01:56 +0100, Mike Galbraith wrote:
>> --- a/kernel/futex.c
>> +++ b/kernel/futex.c
>> @@ -2383,7 +2383,18 @@ static int fi
On Wed, Nov 04 2020 at 08:42, Mike Galbraith wrote:
> On Wed, 2020-11-04 at 01:56 +0100, Mike Galbraith wrote:
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -2383,7 +2383,18 @@ static int fixup_pi_state_owner(u32 __us
>* Since we just failed the trylock; there must be an
On Tue, Nov 03 2020 at 17:31, Gratian Crisan wrote:
> I apologize for waking up the futex demons (and replying to my own
> email), but ...
I was staring at it already but couldn't wrap my head around it.
> Gratian Crisan writes:
> I was able to reproduce the BUG_ON(!newowner) in
On Fri, Oct 30 2020 at 17:45, Sudeep Holla wrote:
> On Thu, Oct 29, 2020 at 02:37:06PM -0700, Elliot Berman wrote:
>> In the case where commercial device is using feature for thermal, device
>> should boot multiple small cores. Booting only one core means we would not
>> be able to use all
On Sun, Nov 01 2020 at 13:14, Marc Zyngier wrote:
> Vincent recently reported [1] that 5.10-rc1 showed a significant
> regression when running "perf bench sched pipe" on arm64, and
> pinpointed it to the recent move to handling IPIs as normal
> interrupts.
>
> The culprit is the use of
On Tue, Nov 03 2020 at 09:48, Linus Torvalds wrote:
> I have no complaints about the patch, but it strikes me that if people
> want to actually have much better debug coverage, this is where it
> should be (I like the "every other address" thing too, don't get me
> wrong).
>
> In particular,
Hi!
On Tue, Nov 03 2020 at 22:31, lkp wrote:
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: b643128b917ca8f1c8b1e14af64ebdc81147b2d1 ("x86/ioapic: Use
> irq_find_matching_fwspec() to find remapping irqdomain")
>
> [3.148819] ..TIMER: vector=0x30 apic1=0 pin1=2
On Tue, Nov 03 2020 at 11:41, Marc Zyngier wrote:
> On 2020-11-03 10:31, Thomas Gleixner wrote:
> We can do that, although I worried that it isn't 100% reliable:
>
> pci_host_probe() ends up calling pci_add_device(), and will start
> probing devices if the endpoint drivers have alr
. Going back to user
space with an active kmap local is a nono.
Signed-off-by: Thomas Gleixner
---
V4: Use the version which actually compiles and works
V3: Handle the debug case correctly
---
include/linux/highmem-internal.h | 10 +++
include/linux/sched.h|9 +++
kernel/entry
On Tue, Nov 03 2020 at 10:27, Thomas Gleixner wrote:
> +struct kmap_ctrl {
> +#ifdef CONFIG_KMAP_LOCAL
> + int idx;
> + pte_t pteval[KM_TYPE_NR];
I'm a moron. Fixed it on the test machine ...
Following up to the discussion in:
https://lore.kernel.org/r/20200914204209.256266...@linutronix.de
and the second version of this:
https://lore.kernel.org/r/20201029221806.189523...@linutronix.de
this series provides a preemptible variant of kmap_atomic & related
interfaces.
This is
nesting for the upcoming reemptible version would be:
2 maps in task context and a fault inside
2 maps in the fault handler
3 maps in softirq
2 maps in interrupt
So a total of 16 is sufficient and probably overestimated.
Signed-off-by: Thomas Gleixner
---
V3: New patch
to the generic kmap_local* implementation.
Signed-off-by: Thomas Gleixner
---
V3: New patch
---
mm/highmem.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
--- a/mm/highmem.c
+++ b/mm/highmem.c
@@ -374,9 +374,19 @@ EXPORT_SYMBOL(kunmap_high);
static DEFINE_PER_CPU(int
No reason having the same code in every architecture.
Signed-off-by: Thomas Gleixner
Cc: linux-c...@vger.kernel.org
---
V3: Does not compile with gcc 10
---
arch/csky/Kconfig |1
arch/csky/include/asm/fixmap.h |4 +-
arch/csky/include/asm/highmem.h |6 ++-
arch/csky
The mapping code is odd and looks broken. See FIXME in the comment.
Also fix the harmless off by one in the FIX_KMAP_END define.
Signed-off-by: Thomas Gleixner
Cc: Nick Hu
Cc: Greentime Hu
Cc: Vincent Chen
---
V3: Remove the kmap types cruft
---
arch/nds32/Kconfig.cpu |1
ot
fit. Randomly failing at runtime is not a really good option.
Signed-off-by: Thomas Gleixner
Cc: Vineet Gupta
Cc: linux-snps-...@lists.infradead.org
---
V3: Make it actually more correct.
---
arch/arc/Kconfig |1
arch/arc/include/asm/highmem.h| 26 ++
Convert X86 to the generic kmap atomic implementation and make the
iomap_atomic() naming convention consistent while at it.
Signed-off-by: Thomas Gleixner
Cc: x...@kernel.org
---
V3: Remove the kmap_types cruft
---
arch/x86/Kconfig |3 +
arch/x86/include/asm/fixmap.h
Nothing uses totalhigh_pages_dec() and totalhigh_pages_set().
Signed-off-by: Thomas Gleixner
---
V3: New patch
---
include/linux/highmem.h | 10 --
1 file changed, 10 deletions(-)
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -104,21 +104,11 @@ static inline void
All users gone.
Signed-off-by: Thomas Gleixner
---
include/linux/highmem.h | 63 +++-
mm/highmem.c|7 -
2 files changed, 5 insertions(+), 65 deletions(-)
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -86,31
No reason having the same code in every architecture
Signed-off-by: Thomas Gleixner
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
---
V3: Remove the kmap types cruft
---
arch/sparc/Kconfig |1
arch/sparc/include/asm/highmem.h|8 +-
arch/sparc/i
No reason having the same code in every architecture
Signed-off-by: Thomas Gleixner
Cc: Chris Zankel
Cc: Max Filippov
Cc: linux-xte...@linux-xtensa.org
---
V3: Remove the kmap types cruft
---
arch/xtensa/Kconfig |1
arch/xtensa/include/asm/fixmap.h |4 +--
arch/xtensa
No reason having the same code in every architecture
Signed-off-by: Thomas Gleixner
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-...@lists.ozlabs.org
---
V3: Remove the kmap types cruft
---
arch/powerpc/Kconfig |1
arch/powerpc/include
.
Making it available independent of RT allows to provide a preemptible
variant of kmap_atomic() and makes the code more consistent in general.
FIXME: Rework the comment in preempt.h
Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Juri Lelli
Cc: Vincent Guittot
Cc: Dietmar
901 - 1000 of 29423 matches
Mail list logo
