Re: [PATCH] RISC-V: Fix FIXMAP area corruption on RV32 systems

[Alistair Francis]

On Mon, 2019-08-26 at 14:17 -0700, Palmer Dabbelt wrote:
> On Sun, 18 Aug 2019 21:49:01 PDT (-0700), anup@xxxxxxxxxxxxxx wrote:
> > On Sun, Aug 18, 2019 at 11:49 PM Christoph Hellwig <
> > hch@xxxxxxxxxxxxx> wrote:
> > > > +#define FIXADDR_TOP      (VMALLOC_START)
> > > 
> > > Nit: no need for the braces, the definitions below don't use it
> > > either.
> > 
> > Sure, I will update and send v2 soon.
> > 
> > > > +#ifdef CONFIG_64BIT
> > > > +#define FIXADDR_SIZE     PMD_SIZE
> > > > +#else
> > > > +#define FIXADDR_SIZE     PGDIR_SIZE
> > > > +#endif
> > > > +#define FIXADDR_START    (FIXADDR_TOP - FIXADDR_SIZE)
> > > > +
> > > >  /*
> > > > - * Task size is 0x4000000000 for RV64 or 0xb800000 for RV32.
> > > > + * Task size is 0x4000000000 for RV64 or 0x9fc00000 for RV32.
> > > >   * Note that PGDIR_SIZE must evenly divide TASK_SIZE.
> > > >   */
> > > >  #ifdef CONFIG_64BIT
> > > >  #define TASK_SIZE (PGDIR_SIZE * PTRS_PER_PGD / 2)
> > > >  #else
> > > > -#define TASK_SIZE VMALLOC_START
> > > > +#define TASK_SIZE FIXADDR_START
> > > >  #endif
> > > 
> > > Mentioning the addresses is a little weird.  IMHO this would be
> > > a much nicer place to explain the high-level memory layout,
> > > including
> > > maybe a little ASCII art.  Also we could have one #ifdef
> > > CONFIG_64BIT
> > > for both related values.  Last but not least instead of saying
> > > that
> > > something should be dividable it would be nice to have a
> > > BUILD_BUG_ON
> > > to enforce it.
> > > 
> > > Either way we are late in the cycle, so I guess this is ok for
> > > now:
> > > 
> > > Reviewed-by: Christoph Hellwig <hch@xxxxxx>
> > > 
> > > But I'd love to see this area improved a little further as it is
> > > full
> > > of mine fields.
> > 
> > I agree with you. We also have Sparsemem and KASAN patches which
> > touch virtual memory layout so it's important to have virtual
> > memory layout
> > documented clearly. I can add the required documentation as
> > separate patch.
> 
> Documentation is great, but if we document something that is broken
> then it's 
> still broken :)

I'm confused here. What is broken?

Right now RV32 does not work with the 5.3 kernel and this patch fixes
the regression.

> 
> I think this needs to just be redone -- we keep running into issues
> here and 
> fixing them, but there are probably more issues and it'll probably be
> faster to 
> just think through the memory map than to keep fixing bugs as they
> crop up.  
> This was one of the areas of the port I didn't rewrite as part of the
> upstream 
> submission process, and as a result it's pretty crusty.

I can't speak for rewriting the code, but that seems like something
that should happen in the 5.4 merge window right? With RC6 already out 
this patch seems like the only option for 5.3. Unless we are just going
to drop RV32 support from Linux in the 5.3 release?

Alistair

> 
> > I think the best place to add ASCII art would be asm/pgtable.h
> > where all
> > virtual memory related defines are placed. Suggestions??