[PATCH 0/2] Restrict address space for sv39,sv48,sv57

[Conor Dooley]

On Tue, Jun 27, 2023 at 02:51:51PM -0700, Atish Kumar Patra wrote:
> On Tue, Jun 27, 2023 at 2:12 PM Conor Dooley <conor at kernel.org> wrote:
> 
> > On Tue, Jun 27, 2023 at 10:10:06PM +0100, Conor Dooley wrote:
> > > On Tue, Jun 27, 2023 at 01:44:18PM -0700, Charles Jenkins wrote:
> > >
> > > - all the random CCs
> >
> > And without ballsing up Konstantin's address....
> >
> > >
> > > > On Tue, Jun 27, 2023 at 11:24 AM Conor Dooley <conor at kernel.org>
> > wrote:
> > > > > On Mon, Jun 26, 2023 at 11:36:02AM -0700, Charlie Jenkins wrote:
> > > > > > Make sv39 the default address space for mmap as some applications
> > > > > > currently depend on this assumption. The RISC-V specification
> > enforces
> > > > > > that bits outside of the virtual address range are not used, so
> > > > > > restricting the size of the default address space as such should be
> > > > > > temporary. A hint address passed to mmap will cause the largest
> > address
> > > > > > space that fits entirely into the hint to be used. If the hint is
> > less
> > > > > > than or equal to 1<<38, a 39-bit address will be used. After an
> > address
> > > > > > space is completely full, the next smallest address space will be
> > used.
> > > > > >
> > > > > > Documentation is also added to the RISC-V virtual memory section
> > to  explain
> > > > > > these changes.
> > > > >
> > > > > I don't know what went wrong here, but this never ended up in
> > patchwork
> > > > > for some reason, although it has appeared on lore. That seems to be
> > via
> > > > > the docs mailing list, rather than linux-riscv. Could you speak to
> > Atish
> > > > > and see if he knows what went wrong?
> > >
> > > > I talked to Atish, he's not sure what's going on here either. I am
> > going
> > > > to add him to the CC list.
> > >
> > > Atish is the one with admin for the list, I figured he'd be able to tell
> > > if it got bounced properly. If it got bounced correctly, but didn't
> > > arrive in patchwork then I don't know.
> > >
> 
> 
> That's the first thing I checked while talking to charlie. It did not
> bounce either.
> I checked the admin portal and no pending messages either. I guess gmail
> just dropped it randomly!
> It is a known fact that gmail doesn't like linux mailing lists much. I just
> discovered few of linux-riscv emails
> landed up in the spam!

Usually that seems to be on the incoming side, I know my work emails end
up in gmail spam boxes. I opted to just mark all mail with a list in CC
as non-spam in my filters, I'll eat the random emails in Polish we get
every now and then, in exchange for not missing stuff.
The outgoing side is usually more reliable, so surprised if that's the
problem.

> @Charlie Jenkins <charlie at rivosinc.com> : Try to resend the series with a
> reduced cc list hoping that it would end up in linux-riscv this time :)

Yeah, maybe that would help. Too big a CC list is often problematic, I
think 1024 or so characters might be the limit for infradead, and the
strategy of doing "To: Charlie, Cc: all maintainers & lists" seems to
have produced a list well in excess of 1024. That seems like a likely
culprit!
There's a bunch of people CCed on that that probably don't care one
iota for what we are doing on RISC-V, RMK is probably a good example of
that, who don't need to be CCed.

> > > Usually when a bunch of lists are CCed, multiple entries show up on
> > > lore, afair. In this case, a bunch of lists were CCed, but only the one
> > > via linux-doc appeared on lore.
> > >
> > > Konstantin, any ideas?
> > >
> > > Cheers,
> > > Conor.
> > >
> >
> >
> >
> > > _______________________________________________
> > > linux-riscv mailing list
> > > linux-riscv at lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> >
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20230627/7ef700c2/attachment.sig>