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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 4 Dec 2020 00:43:49 +0000 From: Alex Belits <abelits@...vell.com> To: "mark.rutland@....com" <mark.rutland@....com> CC: Prasun Kapoor <pkapoor@...vell.com>, "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>, "davem@...emloft.net" <davem@...emloft.net>, "trix@...hat.com" <trix@...hat.com>, "mingo@...nel.org" <mingo@...nel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "rostedt@...dmis.org" <rostedt@...dmis.org>, "peterx@...hat.com" <peterx@...hat.com>, "tglx@...utronix.de" <tglx@...utronix.de>, "nitesh@...hat.com" <nitesh@...hat.com>, "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>, "mtosatti@...hat.com" <mtosatti@...hat.com>, "will@...nel.org" <will@...nel.org>, "catalin.marinas@....com" <catalin.marinas@....com>, "peterz@...radead.org" <peterz@...radead.org>, "frederic@...nel.org" <frederic@...nel.org>, "leon@...ebranch.com" <leon@...ebranch.com>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "pauld@...hat.com" <pauld@...hat.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org> Subject: Re: [EXT] Re: [PATCH v5 5/9] task_isolation: Add driver-specific hooks On Wed, 2020-12-02 at 14:18 +0000, Mark Rutland wrote: > External Email > > ------------------------------------------------------------------- > --- > On Mon, Nov 23, 2020 at 05:57:42PM +0000, Alex Belits wrote: > > Some drivers don't call functions that call > > task_isolation_kernel_enter() in interrupt handlers. Call it > > directly. > > I don't think putting this in drivers is the right approach. IIUC we > only need to track user<->kernel transitions, and we can do that > within > the architectural entry code before we ever reach irqchip code. I > suspect the current approacch is an artifact of that being difficult > in > the old structure of the arch code; recent rework should address > that, > and we can restruecture things further in future. I agree completely. This patch only covers irqchip drivers with unusual entry procedures. -- Alex
Powered by blists - more mailing lists