> On 7. Feb 2020, at 18:08, Arnd Bergmann wrote:
>
> On Fri, Feb 7, 2020 at 3:34 PM Christian Zigotzky
> wrote:
>>
>> Hello Arnd,
>>
>> We regularly compile and test Linux kernels every day during the merge
>> window. Since Thursday last week we have very high CPU usage because of
>> the a
On Fri, Feb 7, 2020 at 7:16 PM Greg Kurz wrote:
>
> On Thu, 19 Dec 2019 01:11:33 +1100
> Daniel Axtens wrote:
>
> > Jordan Niethe writes:
> >
> > > A user-mode access to an address a long way below the stack pointer is
> > > only valid if the instruction is one that would update the stack pointe
On 2/5/20 7:25 PM, Leonardo Bras wrote:
> On Thu, 2020-02-06 at 00:08 -0300, Leonardo Bras wrote:
>> gup_pgd_range(addr, end, gup_flags, pages, &nr);
>> - local_irq_enable();
>> + end_lockless_pgtbl_walk(IRQS_ENABLED);
>> ret = nr;
>>
On Fri, Feb 07, 2020 at 05:20:57PM +, Christophe Leroy wrote:
> When CONFIG_PROVE_LOCKING is selected together with (now default)
> CONFIG_VMAP_STACK, kernel enter deadlock during boot.
>
> At the point of checking whether interrupts are enabled or not, the
> value of MSR saved on stack is rea
When CONFIG_PROVE_LOCKING is selected together with (now default)
CONFIG_VMAP_STACK, kernel enter deadlock during boot.
At the point of checking whether interrupts are enabled or not, the
value of MSR saved on stack is read using the physical address of the
stack. But at this point, when using VMA
On 02/07/2020 01:44 PM, Guenter Roeck wrote:
On 2/7/20 5:29 AM, Christophe Leroy wrote:
On 02/07/2020 01:08 PM, Guenter Roeck wrote:
On 2/7/20 12:28 AM, Christophe Leroy wrote:
On 02/07/2020 06:13 AM, Christophe Leroy wrote:
Le 06/02/2020 à 21:31, Guenter Roeck a écrit :
On Sat, Dec
On Fri, Feb 7, 2020 at 3:34 PM Christian Zigotzky
wrote:
>
> Hello Arnd,
>
> We regularly compile and test Linux kernels every day during the merge
> window. Since Thursday last week we have very high CPU usage because of
> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The
>
Le 07/02/2020 à 13:21, Michael Ellerman a écrit :
The early versions of our kernel user access prevention (KUAP) were
written by Russell and Christophe, and didn't have separate
read/write access.
At some point I picked up the series and added the read/write access,
but I failed to update the
Hello Arnd,
We regularly compile and test Linux kernels every day during the merge
window. Since Thursday last week we have very high CPU usage because of
the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The
avahi daemon produces a lot of the following log message. This gene
On 2/7/20 5:29 AM, Christophe Leroy wrote:
On 02/07/2020 01:08 PM, Guenter Roeck wrote:
On 2/7/20 12:28 AM, Christophe Leroy wrote:
On 02/07/2020 06:13 AM, Christophe Leroy wrote:
Le 06/02/2020 à 21:31, Guenter Roeck a écrit :
On Sat, Dec 21, 2019 at 08:32:38AM +, Christophe Leroy w
On 07.02.2020 14:38, Thomas Gleixner wrote:
> Alexey Budankov writes:
>> On 22.01.2020 17:25, Alexey Budankov wrote:
>>> On 22.01.2020 17:07, Stephen Smalley wrote:
> It keeps the implementation simple and readable. The implementation is
> more
> performant in the sense of calling t
On 02/07/2020 01:08 PM, Guenter Roeck wrote:
On 2/7/20 12:28 AM, Christophe Leroy wrote:
On 02/07/2020 06:13 AM, Christophe Leroy wrote:
Le 06/02/2020 à 21:31, Guenter Roeck a écrit :
On Sat, Dec 21, 2019 at 08:32:38AM +, Christophe Leroy wrote:
A few changes to retrieve DAR and DS
On 2/7/20 12:28 AM, Christophe Leroy wrote:
On 02/07/2020 06:13 AM, Christophe Leroy wrote:
Le 06/02/2020 à 21:31, Guenter Roeck a écrit :
On Sat, Dec 21, 2019 at 08:32:38AM +, Christophe Leroy wrote:
A few changes to retrieve DAR and DSISR from struct regs
instead of retrieving them d
Michael Ellerman writes:
> The early versions of our kernel user access prevention (KUAP) were
> written by Russell and Christophe, and didn't have separate
> read/write access.
>
> At some point I picked up the series and added the read/write access,
> but I failed to update the usages in futex.
The early versions of our kernel user access prevention (KUAP) were
written by Russell and Christophe, and didn't have separate
read/write access.
At some point I picked up the series and added the read/write access,
but I failed to update the usages in futex.h to correctly allow read
and write.
Alexey Budankov writes:
> On 22.01.2020 17:25, Alexey Budankov wrote:
>> On 22.01.2020 17:07, Stephen Smalley wrote:
It keeps the implementation simple and readable. The implementation is more
performant in the sense of calling the API - one capable() call for
CAP_PERFMON
priv
On Thu, 19 Dec 2019 01:11:33 +1100
Daniel Axtens wrote:
> Jordan Niethe writes:
>
> > A user-mode access to an address a long way below the stack pointer is
> > only valid if the instruction is one that would update the stack pointer
> > to the address accessed. This is checked by directly look
Le 07/02/2020 à 05:57, Sam Bobroff a écrit :
Recovering a dead PHB can currently cause a deadlock as the PCI
rescan/remove lock is taken twice.
This is caused as part of an existing bug in
eeh_handle_special_event(). The pe is processed while traversing the
PHBs even though the pe is unrelate
On 02/07/2020 06:13 AM, Christophe Leroy wrote:
Le 06/02/2020 à 21:31, Guenter Roeck a écrit :
On Sat, Dec 21, 2019 at 08:32:38AM +, Christophe Leroy wrote:
A few changes to retrieve DAR and DSISR from struct regs
instead of retrieving them directly, as they may have
changed due to a T
Hi Leonardo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on asm-generic/master paulus-powerpc/kvm-ppc-next
linus/master v5.5 next-20200207]
[cannot apply to kvm-ppc/kvm-ppc-next]
[if your patch is applied to the wrong git
20 matches
Mail list logo
