linux-kernel - Re: [RFC PATCH v2 0/3] genirq, serial: 8250: Workaround to avoid irq=0 for console

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55BA2A06.1080109@hurleysoftware.com>
Date:	Thu, 30 Jul 2015 09:43:34 -0400
From:	Peter Hurley <peter@...leysoftware.com>
To:	Thomas Gleixner <tglx@...utronix.de>,
	Taichi Kageyama <t-kageyama@...jp.nec.com>
CC:	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"jiang.liu@...ux.intel.com" <jiang.liu@...ux.intel.com>,
	"linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jslaby@...e.cz" <jslaby@...e.cz>,
	"prarit@...hat.com" <prarit@...hat.com>,
	Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC PATCH v2 0/3] genirq, serial: 8250: Workaround to avoid
 irq=0 for console

On 07/30/2015 06:12 AM, Thomas Gleixner wrote:
> On Thu, 30 Jul 2015, Taichi Kageyama wrote:
>> On 2015/07/29 22:35, Thomas Gleixner wrote:
>> I know your code is sample (console.h is required), 
>> but it is conflict with [patch v2 1/3].
>> I think serial8250_console_write should not touch ctrl reg during autoconfig_irq. 
>> To resolve the real problem, I think keeping only [patch v2 1/3] is best(opt1).
>> What do you think?
>>
>> opt1. keep [patch v2 1/3]
>>     + Don't touch other legacy drivers using autoprobe.
>>        Each driver can use console_lock to fix this problem if it happens.
> 
> No, we already know that autoprobing and console access can cause
> this, so we fix it at the core code and be done with it.
>  
> Can you please test Peters patch and confirm that is solves it.

Honestly, I'm not too sure this is the way to go.

Messing around with irqsoff tracer for 30 mins turned up:
3.664ms in intel_unmap_page
  - iotlb flush, spinlock contention on iova_rbtree_lock
1.726ms in intel_map_page()
  - iommu core @ __alloc_and_insert_iova_range()
1.859ms in syslog_print_all()
  - which is holding the logbuf_lock so that's pretty bad anyway
387us in nouveau @ nv50_vm_flush()
  - gpu tlb flush

I have irqsoff trace reports for all of these if anyone is interested.

Looks like lockdep would need to be off as well because I saw but
failed to capture a save_trace() in the 300us range.

I think this is just the tip of the iceberg for irqsoff.

I'm not saying these don't need fixing as well, but there's no way
irq probe will ever be reliable with this approach.

Going back to the RFC idea of pinning the irq affinity to the cpu
actually doing the probing (which is in a known context), what about
that is broken on UP? Just the implementation or is it the fundamental
concept?

Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/