Sebastien Marie wrote:
> On Fri, Sep 10, 2021 at 08:12:58AM -0600, Theo de Raadt wrote:
> > > for Rust programs. It should even be free as Rust libc crate doesn't
> > > have `struct kinfo_proc` definition. I can't comment on Go side.
> >
> > The structure has nothing to do with libc!
> >
> >
On Fri, Sep 10, 2021 at 08:12:58AM -0600, Theo de Raadt wrote:
> > for Rust programs. It should even be free as Rust libc crate doesn't
> > have `struct kinfo_proc` definition. I can't comment on Go side.
>
> The structure has nothing to do with libc!
>
> So why would it occur there?
Because
> for Rust programs. It should even be free as Rust libc crate doesn't
> have `struct kinfo_proc` definition. I can't comment on Go side.
The structure has nothing to do with libc!
So why would it occur there?
On Thu, Sep 09, 2021 at 12:01:14PM -0600, Theo de Raadt wrote:
> Stuart Henderson wrote:
>
> > On 2021/09/09 06:47, Greg Steuck wrote:
> > > Mark Kettenis writes:
> > >
> > > >> From: "Theo de Raadt"
> > > >> Date: Tue, 07 Sep 2021 07:08:19 -0600
> > > >>
> > > >> Or we could coordinate the
Stuart Henderson wrote:
> On 2021/09/09 06:47, Greg Steuck wrote:
> > Mark Kettenis writes:
> >
> > >> From: "Theo de Raadt"
> > >> Date: Tue, 07 Sep 2021 07:08:19 -0600
> > >>
> > >> Or we could coordinate the Greg approach as a sysctl ABI change near a
> > >> libc major bump. On the other
On 2021/09/09 06:47, Greg Steuck wrote:
> Mark Kettenis writes:
>
> >> From: "Theo de Raadt"
> >> Date: Tue, 07 Sep 2021 07:08:19 -0600
> >>
> >> Or we could coordinate the Greg approach as a sysctl ABI change near a
> >> libc major bump. On the other side of such a bump, all kernel + base +
Mark Kettenis writes:
>> From: "Theo de Raadt"
>> Date: Tue, 07 Sep 2021 07:08:19 -0600
>>
>> Or we could coordinate the Greg approach as a sysctl ABI change near a
>> libc major bump. On the other side of such a bump, all kernel + base +
>> packages are updated to use the new storage ABI.
On Tue, 07 Sep 2021 21:38:27 +0200, Mark Kettenis wrote:
> I'm not convinced the original diff is right:
>
> * We have several places in the kernel where we store numbers of pages
> in a (32-bit) int. Changing just one of these places is dangerous.
>
> * Changing the type of just vm_dsize
> From: "Theo de Raadt"
> Date: Tue, 07 Sep 2021 07:08:19 -0600
>
> Claudio Jeker wrote:
>
> > > @@ -443,7 +443,7 @@ struct kinfo_proc {
> > >
> > > int32_t p_vm_rssize;/* SEGSZ_T: current resident set size
> > > in pages */
> > > int32_t p_vm_tsize; /* SEGSZ_T:
On Tue, 07 Sep 2021 09:46:02 +0200, Claudio Jeker wrote:
> From my understanding this is not how struct kinfo_proc should be modified.
> Instead the code should add the u_int64_t version at the end and leave the
> old in place. This way old userland still works with new kernel.
Correct.
- todd
Claudio Jeker wrote:
> > @@ -443,7 +443,7 @@ struct kinfo_proc {
> >
> > int32_t p_vm_rssize;/* SEGSZ_T: current resident set size
> > in pages */
> > int32_t p_vm_tsize; /* SEGSZ_T: text size (pages) */
> > - int32_t p_vm_dsize; /* SEGSZ_T: data
On Mon, Sep 06, 2021 at 12:39:56PM -0700, Greg Steuck wrote:
> In the course of making ASan work on OpenBSD I ran into an accounting
> limitation. struct vmspace declares vm_dsize as segsz_t (aka int32_t).
> This effectively limits it to 2^31 pages (2^43 bytes on amd64). This
> would be enough if
In the course of making ASan work on OpenBSD I ran into an accounting
limitation. struct vmspace declares vm_dsize as segsz_t (aka int32_t).
This effectively limits it to 2^31 pages (2^43 bytes on amd64). This
would be enough if didn't also count sparse allocation.
ASan allocates 1/8th of the
13 matches
Mail list logo
