On 7/17/20, 9:00 AM, "Thomas Gleixner" wrote:
Setting interrupt affinity on inactive interrupts is inconsistent when
hierarchical irq domains are enabled. The core code should just store the
affinity and not call into the irq chip driver for inactive interrupts
because the chip
On 6/8/20, 8:49 AM, "Thomas Gleixner" wrote:
"Herrenschmidt, Benjamin" writes:
> On Wed, 2020-06-03 at 16:16 +0100, Marc Zyngier wrote:
>> > My original patch should certain check activated and not disabled.
>> > With that do you still have reservations Marc?
>>
On 5/31/20, 9:40 PM, "Herrenschmidt, Benjamin" wrote:
On Sun, 2020-05-31 at 12:09 +0100, Marc Zyngier wrote:
>
>
> > Not great indeed. But this is not, as far as I can tell, a GIC
> > driver problem.
> >
> > The semantic of activate/deactivate (which maps to
Marc,
> On May 31, 2020, at 6:10 AM, Marc Zyngier wrote:
>> Not great indeed. But this is not, as far as I can tell, a GIC
>> driver problem.
>>
>> The semantic of activate/deactivate (which maps to started/shutdown
>> in the IRQ code) is that the HW resources for a given interrupt are
>> only
Hi Marc,
> On May 29, 2020, at 3:33 AM, Marc Zyngier wrote:
>
> Hi Ali,
>
>> On 2020-05-29 02:55, Ali Saidi wrote:
>> If an interrupt is disabled the ITS driver has sent a discard removing
>> the DeviceID and EventID from the ITT. After this occurs it can't be
>> moved to another collection
On 3/27/19, 2:52 PM, "linux-arm-kernel on behalf of Kees Cook"
wrote:
Adding some more people to CC... what do people think about this
moving of the brk to ELF_ET_DYN_BASE in this corner-case? Anything
that worked before should still work (i.e. the ultimately-launched
binary
On 3/21/19, 9:11 AM, "linux-arm-kernel on behalf of Thomas Gleixner"
wrote:
On Tue, 12 Mar 2019, Ali Saidi wrote:
> Increase mmap_base by the worst-case brk randomization so that
> the stack and heap remain apart.
>
> In Linux 4.13 a change was committed that
> On Mar 13, 2019, at 11:26 AM, Dave Hansen wrote:
>
>> On 3/12/19 10:32 AM, Ali Saidi wrote:
>> +/* Provide space for brk randomization */
>> +pad += SZ_32M;
>
> Just curious: Why is the padding in your other patch conditional on the
> 32-bit vs. 64-bit apps, but here it's always
8 matches
Mail list logo
