Assign array_size() to variable _size_ and use it in both vzalloc()
and memcpy(). These sorts of multiplication factors need to be wrapped
in array_size().
This issue was found with the help of Coccinelle and, audited and fixed
manually.
Signed-off-by: Gustavo A. R. Silva
---
On Fri 2020-07-10 11:58:34, John Ogness wrote:
> On 2020-07-10, Petr Mladek wrote:
> >> The next series in the printk-rework (move LOG_CONT handling from
> >> writers to readers) makes some further changes that, while not
> >> incompatible, could affect the output of existing tools. It may be a
>
On 2020-07-10, Petr Mladek wrote:
>> The next series in the printk-rework (move LOG_CONT handling from
>> writers to readers) makes some further changes that, while not
>> incompatible, could affect the output of existing tools. It may be a
>> good idea to let the new ringbuffer sit in linux-next
On Thu 2020-07-09 09:09:31, John Ogness wrote:
> On 2020-07-08, Petr Mladek wrote:
> > OK, I think that we are ready to try this in linux-next.
> > I am going to push it there via printk/linux.git.
> >
> > [...]
> >
> > Of course, there are still many potential problems. The following comes
> >
On (20/07/10 17:43), Sergey Senozhatsky wrote:
> [..]
>
> > +void prb_init(struct printk_ringbuffer *rb,
> > + char *text_buf, unsigned int textbits,
> > + char *dict_buf, unsigned int dictbits,
> > + struct prb_desc *descs, unsigned int descbits)
> > +{
> > +
On (20/07/09 15:29), John Ogness wrote:
[..]
> +/*
> + * A data block: mapped directly to the beginning of the data block area
> + * specified as a logical position within the data ring.
> + *
> + * @id: the ID of the associated descriptor
> + * @data: the writer data
> + *
> + * Note that the
On Thu 2020-07-09 15:29:40, John Ogness wrote:
> Hello,
>
> Here is a v5 for the first series to rework the printk
> subsystem. The v4 is here [0]. This first series
> only replaces the existing ringbuffer implementation. No locking
> is removed. The semantics/behavior of printk are kept the same
On Thu, Jul 9, 2020 at 6:30 PM HATAYAMA Daisuke wrote:
>
> We faced recently a memory dump collected by sadump where unused part
> of register values are non-zero. For the crash dump, calculating
> kaslr_offset fails because it is based on the assumption that unused
> part of register values in
