lkml.org 
[lkml]   [2020]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH next v2 1/2] printk: avoid and/or handle record truncation
On (20/09/30 11:07), John Ogness wrote:
[..]
> @@ -1389,6 +1391,9 @@ bool prb_reserve_in_last(struct prb_reserved_entry *e, struct printk_ringbuffer
> if (!data_check_size(&rb->text_data_ring, r->text_buf_size))
> goto fail;
>
> + if (r->text_buf_size > max_size)
> + goto fail;
> +
> r->text_buf = data_alloc(rb, &rb->text_data_ring, r->text_buf_size,
> &d->text_blk_lpos, id);
> } else {
> @@ -1410,6 +1415,9 @@ bool prb_reserve_in_last(struct prb_reserved_entry *e, struct printk_ringbuffer
> if (!data_check_size(&rb->text_data_ring, r->text_buf_size))
> goto fail;
>
> + if (r->text_buf_size > max_size)
> + goto fail;
> +
> r->text_buf = data_realloc(rb, &rb->text_data_ring, r->text_buf_size,
> &d->text_blk_lpos, id);
> }
[..]

> bool prb_reserve_in_last(struct prb_reserved_entry *e, struct printk_ringbuffer *rb,
> - struct printk_record *r, u32 caller_id);
> + struct printk_record *r, u32 caller_id, unsigned int max_size);

Isn't `max_size' always LOG_LINE_MAX?

-ss

\
 
 \ /
  Last update: 2020-09-30 11:43    [W:0.091 / U:8.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site