On Tue, Jun 09, 2020 at 07:15:42AM -0700, Guenter Roeck wrote:
> On 6/9/20 5:10 AM, Joerg Roedel wrote:
> >
> I have stopped building unicore32 images since v4.19 since there is
> no available compiler that is still supported by the kernel. I am
> surprised that support for it has not been
On 6/9/20 9:23 AM, Joerg Roedel wrote:
> Hi Guenter,
>
> On Tue, Jun 09, 2020 at 07:15:42AM -0700, Guenter Roeck wrote:
>> To build csky images, you have to disable CONFIG_FRAME_POINTER or use a
>> non-upstream compiler. To build any images reliably, you have to disable
>>
Hi Guenter,
On Tue, Jun 09, 2020 at 07:15:42AM -0700, Guenter Roeck wrote:
> To build csky images, you have to disable CONFIG_FRAME_POINTER or use a
> non-upstream compiler. To build any images reliably, you have to disable
> CONFIG_GCC_PLUGIN_RANDSTRUCT or use a version of gcc old enough to not
Hi Joerg,
On Tue, Jun 09, 2020 at 02:10:56PM +0200, Joerg Roedel wrote:
> Hi Mike,
>
> On Fri, Jun 05, 2020 at 01:00:59PM +0300, Mike Rapoport wrote:
> > We already have include/asm-generic/pgalloc.h, so maybe something like
> > that patch below would fork. This is not even compile tested.
> >
On 6/9/20 5:10 AM, Joerg Roedel wrote:
> Hi Mike,
>
> On Fri, Jun 05, 2020 at 01:00:59PM +0300, Mike Rapoport wrote:
>> We already have include/asm-generic/pgalloc.h, so maybe something like
>> that patch below would fork. This is not even compile tested.
>>
>> diff --git
Hi Mike,
On Fri, Jun 05, 2020 at 01:00:59PM +0300, Mike Rapoport wrote:
> We already have include/asm-generic/pgalloc.h, so maybe something like
> that patch below would fork. This is not even compile tested.
>
> diff --git a/include/asm-generic/pgalloc.h b/include/asm-generic/pgalloc.h
I
On Fri, Jun 05, 2020 at 10:16:44AM +0200, Joerg Roedel wrote:
> On Thu, Jun 04, 2020 at 02:12:14PM -0700, Linus Torvalds wrote:
> > That said, the commentary about "why is p.._alloc_track() in such a
> > core header file, when it's only used by two special cases" is
> > probably still true
On Thu, Jun 04, 2020 at 02:12:14PM -0700, Linus Torvalds wrote:
> That said, the commentary about "why is p.._alloc_track() in such a
> core header file, when it's only used by two special cases" is
> probably still true regardless of the 5-level fixup header.. I assume
> Mike didn't do those
On Thu, Jun 04, 2020 at 10:16:07AM -0700, Linus Torvalds wrote:
> On Thu, Jun 4, 2020 at 1:35 AM Joerg Roedel wrote:
> >
> > I posted the fix for this already:
> >
> > https://lore.kernel.org/lkml/20200604074446.23944-1-j...@8bytes.org/
>
> Ugh.
>
> I was going to apply this directly,
On Thu, Jun 4, 2020 at 2:06 PM Andrew Morton wrote:
>
> As discussed over in
> https://lore.kernel.org/linux-mm/20200604164814.ga7...@kernel.org/,
> Mike's "mm: remove __ARCH_HAS_5LEVEL_HACK" patchset
> (http://lkml.kernel.org/r/20200414153455.21744-1-r...@kernel.org) is
> expected to fix this.
On Thu, 4 Jun 2020 10:16:07 -0700 Linus Torvalds
wrote:
> On Thu, Jun 4, 2020 at 1:35 AM Joerg Roedel wrote:
> >
> > I posted the fix for this already:
> >
> > https://lore.kernel.org/lkml/20200604074446.23944-1-j...@8bytes.org/
>
> Ugh.
>
> I was going to apply this directly, but as
On Thu, Jun 4, 2020 at 1:35 AM Joerg Roedel wrote:
>
> I posted the fix for this already:
>
> https://lore.kernel.org/lkml/20200604074446.23944-1-j...@8bytes.org/
Ugh.
I was going to apply this directly, but as I looked at the patch I
just found it fairly illegible.
Is there some
Hi Guenter,
On Wed, Jun 03, 2020 at 04:23:11PM -0700, Guenter Roeck wrote:
> This patch causes crashes with all my ppc64 boot tests, in various
> locations depending on the platform. Reverting it together with its
> companion "mm/ioremap: track which page-table levels were modified"
> fixes the
On Mon, Jun 01, 2020 at 09:52:22PM -0700, Joerg Roedel wrote:
> Track at which levels in the page-table entries were modified by
> vmap/vunmap.
>
> After the page-table has been modified, use that information do decide
> whether the new arch_sync_kernel_mappings() needs to be called.
>
>
14 matches
Mail list logo
