On Fri 2017-08-18 16:25:42, Joe Lawrence wrote:
> On 08/17/2017 10:05 AM, Petr Mladek wrote:
> > On Mon 2017-08-14 16:02:43, Joe Lawrence wrote:
> >> [ ... snip ... ]
> >> + /* Allocate a new shadow variable for use inside the lock below */
> >> + new_shadow = kzalloc(size + sizeof(*new_shadow), gfp_flags);
> >
> > We should print an error message when the memory cannot be allocated.
> > Otherwise we will return NULL without explanation. It will be
> > especially helpful when a caller forgets to check for NULL.
>
> Interesting, I hadn't seen this checkpatch complaint before:
>
> WARNING: Possible unnecessary 'out of memory' message
> #416: FILE: kernel/livepatch/shadow.c:143:
> + if (!new_shadow) {
> + pr_err("failed to allocate shadow variable <0x%p, %lu>\n",
>
> Discussion thread:
> https://lkml.org/lkml/2014/6/10/382
Interesting, I was not aware of this.
> Think the stack trace that the memory subsystem would emit is good
> enough, or would you like to see <obj, id> for debugging purposes?
I agree that the backtrace should be enough to locate the problematic call
quickly. Feel free to omit it.
Now, I just need to update my patterns when looking for problematic
code.
Best Regards,
Petr
--
To unsubscribe from this list: send the line "unsubscribe live-patching" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
