On Thu, Mar 08, 2018 at 03:20:58PM -0800, Linus Torvalds wrote:
> Yes, so the reason the prologue is more important is that there's
> really two cases for the "Code:" line:
Yap, I had a hunch it must be about some of those but thanks for taking
the time and writing it down!
I've tried to
On Thu, Mar 08, 2018 at 03:20:58PM -0800, Linus Torvalds wrote:
> Yes, so the reason the prologue is more important is that there's
> really two cases for the "Code:" line:
Yap, I had a hunch it must be about some of those but thanks for taking
the time and writing it down!
I've tried to
On Thu, Mar 8, 2018 at 2:36 PM, Borislav Petkov wrote:
>
> Btw, do we have any explanation for the two-thirds prologue? I dug it
> out to the patch below but it doesn't say why the prologue being bigger
> is more important than the epilogue.
Yes, so the reason the prologue is
On Thu, Mar 8, 2018 at 2:36 PM, Borislav Petkov wrote:
>
> Btw, do we have any explanation for the two-thirds prologue? I dug it
> out to the patch below but it doesn't say why the prologue being bigger
> is more important than the epilogue.
Yes, so the reason the prologue is more important is
On Thu, Mar 08, 2018 at 10:00:09AM -0800, Linus Torvalds wrote:
> On Thu, Mar 8, 2018 at 2:16 AM, Borislav Petkov wrote:
> > +#define OPCODE_BUFSIZE 64
> > + unsigned int code_prologue = OPCODE_BUFSIZE * 43 / OPCODE_BUFSIZE;
>
> Heh.
>
> That's a very odd way of writing
On Thu, Mar 08, 2018 at 10:00:09AM -0800, Linus Torvalds wrote:
> On Thu, Mar 8, 2018 at 2:16 AM, Borislav Petkov wrote:
> > +#define OPCODE_BUFSIZE 64
> > + unsigned int code_prologue = OPCODE_BUFSIZE * 43 / OPCODE_BUFSIZE;
>
> Heh.
>
> That's a very odd way of writing "43".
I was
On Thu, Mar 8, 2018 at 2:16 AM, Borislav Petkov wrote:
> +#define OPCODE_BUFSIZE 64
> + unsigned int code_prologue = OPCODE_BUFSIZE * 43 / OPCODE_BUFSIZE;
Heh.
That's a very odd way of writing "43".
Honestly, the "43" is just "two thirds" rounded to closest, and it's
not
On Thu, Mar 8, 2018 at 2:16 AM, Borislav Petkov wrote:
> +#define OPCODE_BUFSIZE 64
> + unsigned int code_prologue = OPCODE_BUFSIZE * 43 / OPCODE_BUFSIZE;
Heh.
That's a very odd way of writing "43".
Honestly, the "43" is just "two thirds" rounded to closest, and it's
not important
On Wed, Mar 07, 2018 at 01:08:32PM -0800, Linus Torvalds wrote:
> On Wed, Mar 7, 2018 at 5:25 AM, Josh Poimboeuf wrote:
> >
> > How about we just remove the 'code_bytes=' option? (Or at the very
> > least, reduce its possible range to a reasonable max?)
>
> Ack. Just limit
On Wed, Mar 07, 2018 at 01:08:32PM -0800, Linus Torvalds wrote:
> On Wed, Mar 7, 2018 at 5:25 AM, Josh Poimboeuf wrote:
> >
> > How about we just remove the 'code_bytes=' option? (Or at the very
> > least, reduce its possible range to a reasonable max?)
>
> Ack. Just limit it to 64 bytes max
On Wed, Mar 7, 2018 at 5:25 AM, Josh Poimboeuf wrote:
>
> How about we just remove the 'code_bytes=' option? (Or at the very
> least, reduce its possible range to a reasonable max?)
Ack. Just limit it to 64 bytes max sounds plenty.
Linus
On Wed, Mar 7, 2018 at 5:25 AM, Josh Poimboeuf wrote:
>
> How about we just remove the 'code_bytes=' option? (Or at the very
> least, reduce its possible range to a reasonable max?)
Ack. Just limit it to 64 bytes max sounds plenty.
Linus
On Wed, Mar 07, 2018 at 07:25:35AM -0600, Josh Poimboeuf wrote:
> How about we just remove the 'code_bytes=' option?
Haha, removing stuff is my usual solution :-)
I'd love to.
> (Or at the very
> least, reduce its possible range to a reasonable max?)
>
> I doubt anybody actually uses it. I'd
On Wed, Mar 07, 2018 at 07:25:35AM -0600, Josh Poimboeuf wrote:
> How about we just remove the 'code_bytes=' option?
Haha, removing stuff is my usual solution :-)
I'd love to.
> (Or at the very
> least, reduce its possible range to a reasonable max?)
>
> I doubt anybody actually uses it. I'd
On Wed, Mar 07, 2018 at 11:13:14AM +0100, Borislav Petkov wrote:
> And that is fine if I do a 64-byte default, on-stack buffer but that
> code_bytes= thing can be 2 pages max which is yuck. No way I'm doing
> on-stack buffers then.
How about we just remove the 'code_bytes=' option? (Or at the
On Wed, Mar 07, 2018 at 11:13:14AM +0100, Borislav Petkov wrote:
> And that is fine if I do a 64-byte default, on-stack buffer but that
> code_bytes= thing can be 2 pages max which is yuck. No way I'm doing
> on-stack buffers then.
How about we just remove the 'code_bytes=' option? (Or at the
On Tue, Mar 06, 2018 at 10:47:56AM -0800, Linus Torvalds wrote:
> Are these always serialized? For oopses, I think we end up serializing
> with die_lock, but is that always the case?
Hmm, good question.
> Maybe at least a comment about why a static allocation is ok?
Well, I'm afraid it is not
On Tue, Mar 06, 2018 at 10:47:56AM -0800, Linus Torvalds wrote:
> Are these always serialized? For oopses, I think we end up serializing
> with die_lock, but is that always the case?
Hmm, good question.
> Maybe at least a comment about why a static allocation is ok?
Well, I'm afraid it is not
On Tue, Mar 6, 2018 at 1:49 AM, Borislav Petkov wrote:
>
> Make it read the whole buffer of code_bytes size in one go. By default
> use a statically allocated 64 bytes buffer. If "code_bytes=" is supplied
> on the cmdline a new buffer gets allocated.
Are these always serialized?
On Tue, Mar 6, 2018 at 1:49 AM, Borislav Petkov wrote:
>
> Make it read the whole buffer of code_bytes size in one go. By default
> use a statically allocated 64 bytes buffer. If "code_bytes=" is supplied
> on the cmdline a new buffer gets allocated.
Are these always serialized? For oopses, I
20 matches
Mail list logo