[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1989067.FY1I2HCei6@hyperiorarchmachine>
Date: Tue, 08 Jun 2021 16:50:45 +0300
From: jarmo.tiitto@...il.com
To: Kees Cook <keescook@...omium.org>,
Nathan Chancellor <nathan@...nel.org>,
clang-built-linux@...glegroups.com, Bill Wendling <wcw@...gle.com>,
Sami Tolvanen <samitolvanen@...gle.com>,
Nick Desaulniers <ndesaulniers@...gle.com>,
linux-kernel@...r.kernel.org
Cc: morbo@...gle.com, Jarmo Tiitto <jarmo.tiitto@...il.com>
Subject: Re: [PATCH v3 1/1] pgo: Fix sleep in atomic section in prf_open() v3
Kees Cook wrote tiistaina 8. kesäkuuta 2021 2.02.51 EEST:
> On Sat, 5 Jun 2021 21:31:29 +0300, Jarmo Tiitto wrote:
> > In prf_open() the required buffer size can be so large that
> > vzalloc() may sleep thus triggering bug:
> >
> > ======
> >
> > BUG: sleeping function called from invalid context at
> > include/linux/sched/mm.h:201 in_atomic(): 1, irqs_disabled(): 1,
> > non_block: 0, pid: 337, name: cat CPU: 1 PID: 337 Comm: cat Not tainted
> > 5.13.0-rc2-24-hack+ #154
> > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
> >
> > Call Trace:
> > dump_stack+0xc7/0x134
> > ___might_sleep+0x177/0x190
> > __might_sleep+0x5a/0x90
> > kmem_cache_alloc_node_trace+0x6b/0x3a0
> > ? __get_vm_area_node+0xcd/0x1b0
> > ? dput+0x283/0x300
> > __get_vm_area_node+0xcd/0x1b0
> > __vmalloc_node_range+0x7b/0x420
> > ? prf_open+0x1da/0x580
> > ? prf_open+0x32/0x580
> > ? __llvm_profile_instrument_memop+0x36/0x50
> > vzalloc+0x54/0x60
> > ? prf_open+0x1da/0x580
> > prf_open+0x1da/0x580
> > full_proxy_open+0x211/0x370
> > ....
> >
> > ======
> >
> > [...]
>
> Applied to for-next/clang/features, thanks! I made some additional tweaks
> on top of this, in a separate patch I just sent out.
>
> [1/1] pgo: Fix sleep in atomic section in prf_open() v3
> https://git.kernel.org/kees/c/d13b0485a7bb
>
> --
> Kees Cook
Oof. Looking now at your fixes, I'm sorry for the extra work needed. :-|
I should have cleaned up the error paths better, since that was mentioned
earlier.
My eyes were apparently pointed on the v2 module profiling code I have been
brewing the past weekend.
Thanks!
--
Jarmo
Powered by blists - more mailing lists