On Wed, Dec 18, 2019 at 12:24:28PM +0300, Alexey Budankov wrote:
>
> Introduce CAP_SYS_PERFMON capability devoted to secure system performance
> monitoring and observability operations so that CAP_SYS_PERFMON would
> assist CAP_SYS_ADMIN capability in its governing role for perf_events,
> i915_per
Quoting Nathan Lynch (n...@pobox.com):
> Nathan Lynch wrote:
> >
> > Oren Laadan wrote:
> > >
> > > Nathan Lynch wrote:
> > > >
> > > > What doesn't work:
> > > > * restarting a 32-bit task from a 64-bit task and vice versa
> > >
> > > Is there a test to bail if we attempt to checkpoint such ta
Quoting Benjamin Herrenschmidt (b...@kernel.crashing.org):
> On Wed, 2009-02-04 at 18:44 -0500, Oren Laadan wrote:
> > * Anything that is decided at compiled time should probably go to the arch-
> > dependent header.
> >
> > * Anything that can change at boot time (e.g., for x86 that would include
Quoting Benjamin Herrenschmidt (b...@kernel.crashing.org):
>
> > +struct cr_hdr_cpu {
> > + struct pt_regs pt_regs;
> > + /* relevant fields from thread_struct */
> > + double fpr[32][TS_FPRWIDTH];
> > + unsigned int fpscr;
> > + int fpexc_mode;
> > + /* unsigned int align_ctl; this is
Quoting Oren Laadan (or...@cs.columbia.edu):
> > +static void cr_hdr_init(struct cr_hdr *hdr, __s16 type, __s16 len, __u32
> > parent)
> > +{
> > + hdr->type = type;
> > + hdr->len = len;
> > + hdr->parent = parent;
> > +}
> > +
>
> This function is rather generic and useful to non-arch-dep
Quoting Nathan Lynch (n...@pobox.com):
> The only thing of significance here is that the checkpointed task's
> pt_regs and fp state are saved and restored (see cr_write_cpu and
> cr_read_cpu); the rest of the code consists of dummy implementations
> of the APIs the arch needs to provide to the chec
Quoting Dave Hansen ([EMAIL PROTECTED]):
>
> I'm debating whether this is worth it. It makes this a bit more clean
> looking, but doesn't seriously enhance readability. But, I do think
> it helps a bit.
>
> Thoughts?
Absolutely. do_init_bootmem_node() is *still* a bit largish,
but far better b
