> On Jun 10, 2019, at 5:08 PM, Dave Hansen wrote:
>
>> On 6/10/19 4:54 PM, Andy Lutomirski wrote:
>> Another benefit of kernel management: we could plausibly auto-clear
>> the bits corresponding to munmapped regions. Is this worth it?
>
> I did it for MPX. I think I even went to the trouble
On 6/10/19 4:54 PM, Andy Lutomirski wrote:
> Another benefit of kernel management: we could plausibly auto-clear
> the bits corresponding to munmapped regions. Is this worth it?
I did it for MPX. I think I even went to the trouble of zapping the
whole pages that got unused.
But, MPX tables took
> On Jun 10, 2019, at 3:59 PM, Dave Hansen wrote:
>
>> On 6/10/19 3:40 PM, Yu-cheng Yu wrote:
>> Ok, we will go back to do_mmap() with MAP_PRIVATE, MAP_NORESERVE and
>> VM_DONTDUMP. The bitmap will cover only 48-bit address space.
>
> Could you make sure to discuss the downsides of only doin
On 6/10/19 4:20 PM, H.J. Lu wrote:
>>> Perhaps we still let the app fill the bitmap?
>> I think I'd want to see some performance data on it first.
> Updating legacy bitmap in user space from kernel requires
>
> long q;
>
> get_user(q, ...);
> q |= mask;
> put_user(q, ...);
>
> instead of
>
> *p
On Mon, Jun 10, 2019 at 3:59 PM Dave Hansen wrote:
>
> > We then create PR_MARK_CODE_AS_LEGACY. The kernel will set the bitmap, but
> > it
> > is going to be slow.
>
> Slow compared to what? We're effectively adding one (quick) system call
> to a path that, today, has at *least* half a dozen sy
On 6/10/19 3:40 PM, Yu-cheng Yu wrote:
> Ok, we will go back to do_mmap() with MAP_PRIVATE, MAP_NORESERVE and
> VM_DONTDUMP. The bitmap will cover only 48-bit address space.
Could you make sure to discuss the downsides of only doing a 48-bit
address space?
What are the reasons behind and implica
On Mon, 2019-06-10 at 15:02 -0700, Dave Hansen wrote:
> On 6/10/19 1:58 PM, Yu-cheng Yu wrote:
> > > > On each memory request, the kernel then must consider a percentage of
> > > > allocated space in its calculation, and on systems with less memory
> > > > this quickly becomes a problem.
> > >
> >
On 6/10/19 1:58 PM, Yu-cheng Yu wrote:
>>> On each memory request, the kernel then must consider a percentage of
>>> allocated space in its calculation, and on systems with less memory
>>> this quickly becomes a problem.
>> I'm not sure what you're referring to here? Are you referring to our
>> ov
On Mon, 2019-06-10 at 13:43 -0700, Dave Hansen wrote:
> On 6/10/19 1:27 PM, Yu-cheng Yu wrote:
> > > > If the loader cannot allocate a big bitmap to cover all 5-level
> > > > address space (the bitmap will be large), it can put all legacy lib's
> > > > at lower address. We cannot do these easily i
On 6/10/19 1:27 PM, Yu-cheng Yu wrote:
>>> If the loader cannot allocate a big bitmap to cover all 5-level
>>> address space (the bitmap will be large), it can put all legacy lib's
>>> at lower address. We cannot do these easily in the kernel.
>> This is actually an argument to do it in the kernel
On Mon, 2019-06-10 at 12:52 -0700, Dave Hansen wrote:
> On 6/10/19 12:38 PM, Yu-cheng Yu wrote:
> > > > When an application starts, its highest stack address is determined.
> > > > It uses that as the maximum the bitmap needs to cover.
> > >
> > > Huh, I didn't think we ran code from the stack. ;)
On Mon, Jun 10, 2019 at 12:52 PM Dave Hansen wrote:
>
> On 6/10/19 12:38 PM, Yu-cheng Yu wrote:
> >>> When an application starts, its highest stack address is determined.
> >>> It uses that as the maximum the bitmap needs to cover.
> >> Huh, I didn't think we ran code from the stack. ;)
> >>
> >>
On 6/10/19 12:38 PM, Yu-cheng Yu wrote:
>>> When an application starts, its highest stack address is determined.
>>> It uses that as the maximum the bitmap needs to cover.
>> Huh, I didn't think we ran code from the stack. ;)
>>
>> Especially given the way that we implemented the new 5-level-paging
On Mon, 2019-06-10 at 11:02 -0700, Dave Hansen wrote:
> On 6/10/19 8:22 AM, Yu-cheng Yu wrote:
> > > How does glibc know the linear address space size? We don’t want LA64 to
> > > break old binaries because the address calculation changed.
> >
> > When an application starts, its highest stack add
On 6/10/19 8:22 AM, Yu-cheng Yu wrote:
>> How does glibc know the linear address space size? We don’t want LA64 to
>> break old binaries because the address calculation changed.
> When an application starts, its highest stack address is determined.
> It uses that as the maximum the bitmap needs to
On 6/10/19 9:05 AM, Yu-cheng Yu wrote:
> On Fri, 2019-06-07 at 14:09 -0700, Dave Hansen wrote:
>> On 6/7/19 1:06 PM, Yu-cheng Yu wrote:
Huh, how does glibc know about all possible past and future legacy code
in the application?
>>> When dlopen() gets a legacy binary and the policy allows
On Mon, 10 Jun 2019 14:27:12 -0300
Jason Gunthorpe wrote:
> Looks OK to me, do you want to run these patches through the docs tree
> or through RDMA?
>
> Given that we've generally pushed doc updates through rdma, I think
> I'd prefer the latter? Jonathan?
Whichever works best for you is fine w
* Yu-cheng Yu:
> On Fri, 2019-06-07 at 14:09 -0700, Dave Hansen wrote:
>> On 6/7/19 1:06 PM, Yu-cheng Yu wrote:
>> > > Huh, how does glibc know about all possible past and future legacy code
>> > > in the application?
>> >
>> > When dlopen() gets a legacy binary and the policy allows that, it wil
On Sat, Jun 08, 2019 at 11:27:03PM -0300, Mauro Carvalho Chehab wrote:
> The InfiniBand docs are plain text with no markups.
> So, all we needed to do were to add the title markups and
> some markup sequences in order to properly parse tables,
> lists and literal blocks.
>
> At its new index.rst,
* Yu-cheng Yu:
> To me, looking at PT_GNU_PROPERTY and not trying to support anything is a
> logical choice. And it breaks only a limited set of toolchains.
>
> I will simplify the parser and leave this patch as-is for anyone who wants to
> back-port. Are there any objections or concerns?
Red H
On Mon, Jun 10, 2019 at 09:29:04AM -0700, Yu-cheng Yu wrote:
> On Fri, 2019-06-07 at 19:01 +0100, Dave Martin wrote:
> > On Thu, Jun 06, 2019 at 01:06:41PM -0700, Yu-cheng Yu wrote:
> > > An ELF file's .note.gnu.property indicates features the executable file
> > > can support. For example, the pr
On Fri, 2019-06-07 at 19:01 +0100, Dave Martin wrote:
> On Thu, Jun 06, 2019 at 01:06:41PM -0700, Yu-cheng Yu wrote:
> > An ELF file's .note.gnu.property indicates features the executable file
> > can support. For example, the property GNU_PROPERTY_X86_FEATURE_1_AND
> > indicates the file supports
In data Sunday, June 9, 2019 4:26:59 AM CEST, Mauro Carvalho Chehab ha
scritto:
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists markups;
> - mark literal blocks;
> - adjust title markups.
>
> At
On Fri, 2019-06-07 at 14:09 -0700, Dave Hansen wrote:
> On 6/7/19 1:06 PM, Yu-cheng Yu wrote:
> > > Huh, how does glibc know about all possible past and future legacy code
> > > in the application?
> >
> > When dlopen() gets a legacy binary and the policy allows that, it will
> > manage
> > the bi
On Fri, 2019-06-07 at 15:27 -0700, Andy Lutomirski wrote:
> > On Jun 7, 2019, at 2:09 PM, Dave Hansen wrote:
> >
> > On 6/7/19 1:06 PM, Yu-cheng Yu wrote:
> > > > Huh, how does glibc know about all possible past and future legacy code
> > > > in the application?
> > >
> > > When dlopen() gets a
On Sat, 2019-06-08 at 22:52 +0200, Pavel Machek wrote:
> Hi!
>
> > > I've no idea what the kernel should do; since you failed to answer the
> > > question what happens when you point this to garbage.
> > >
> > > Does it then fault or what?
> >
> > Yeah, I think you'll fault with a rather mysteri
On Sun, Jun 09, 2019 at 09:29:40AM -0300, Mauro Carvalho Chehab wrote:
> Em Sun, 9 Jun 2019 11:16:43 +0200
> > Will there be a web page (e.g. kernel.org), which contains always the
> > latest upstream version?
>
> Yes:
>
> https://www.kernel.org/doc/html/latest/
>
> I guess this one is bas
On Fri, 2019-06-07 at 13:43 -0700, Andy Lutomirski wrote:
> > On Jun 7, 2019, at 12:49 PM, Yu-cheng Yu wrote:
> >
> > On Fri, 2019-06-07 at 11:29 -0700, Andy Lutomirski wrote:
> > > > On Jun 7, 2019, at 10:59 AM, Dave Hansen wrote:
> > > >
> > > > > On 6/7/19 10:43 AM, Peter Zijlstra wrote:
> >
powerpc architecture (both 64-bit and 32-bit) supports stack protector
mechanism since some time now [see commit 06ec27aea9fc ("powerpc/64:
add stack protector support")].
Update stackprotector arch support documentation to reflect the same.
Cc: Jonathan Corbet
Cc: Michael Ellerman
Cc: linux-do
On Thu, 06 Jun 2019, Randy Dunlap wrote:
> > On Thu, 2019-06-06 at 16:51 +0200, Greg Kroah-Hartman wrote:
> >> Again, don't be noisy, it's not hard, and is how things have been
> >> trending for many years now.
>
> Ack that.
Not to say that this particular print is acceptable, but there are
place
30 matches
Mail list logo
