Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Song Liu <songliubraving@fb.com>
To:     Arnd Bergmann <arnd@arndb.de>
CC:     Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Yonghong Song <yhs@fb.com>,
        "David S. Miller" <davem@davemloft.net>, Martin Lau <kafai@fb.com>,
        Chenbo Feng <fengc@google.com>,
        Jakub Kicinski <jakub.kicinski@netronome.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH, net-next 2/2] bpf: avoid -Wmaybe-uninitialized warning
Thread-Topic: [PATCH, net-next 2/2] bpf: avoid -Wmaybe-uninitialized warning
Thread-Index: AQHT9HAwmV7gBmqT/UaT5SYlaUzmvaRA/OmA
Date:   Fri, 25 May 2018 21:54:04 +0000
Message-ID: <1E0F5F01-EB03-4717-95E4-41944690B3E9@fb.com>
References: <20180525213331.2115471-1-arnd@arndb.de>
 <20180525213331.2115471-2-arnd@arndb.de>
In-Reply-To: <20180525213331.2115471-2-arnd@arndb.de>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: fb.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <ACC7F4B0BA38374BA660309BBAD4EB01@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a52f191a-510b-4c66-07ba-08d5c28a08a0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2018 21:54:04.6899
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1421
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-25_08:,,
 signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On May 25, 2018, at 2:33 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>=20
> The stack_map_get_build_id_offset() function is too long for gcc to track
> whether 'work' may or may not be initialized at the end of it, leading
> to a false-positive warning:
>=20
> kernel/bpf/stackmap.c: In function 'stack_map_get_build_id_offset':
> kernel/bpf/stackmap.c:334:13: error: 'work' may be used uninitialized in =
this function [-Werror=3Dmaybe-uninitialized]
>=20
> This removes the 'in_nmi_ctx' flag and uses the state of that variable
> itself to see if it got initialized.
>=20
> Fixes: bae77c5eb5b2 ("bpf: enable stackmap with build_id in nmi context")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> kernel/bpf/stackmap.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>=20
> diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
> index b59ace0f0f09..b675a3f3d141 100644
> --- a/kernel/bpf/stackmap.c
> +++ b/kernel/bpf/stackmap.c
> @@ -285,11 +285,10 @@ static void stack_map_get_build_id_offset(struct bp=
f_stack_build_id *id_offs,
> {
> 	int i;
> 	struct vm_area_struct *vma;
> -	bool in_nmi_ctx =3D in_nmi();
> 	bool irq_work_busy =3D false;
> -	struct stack_map_irq_work *work;
> +	struct stack_map_irq_work *work =3D NULL;
>=20
> -	if (in_nmi_ctx) {
> +	if (in_nmi()) {
> 		work =3D this_cpu_ptr(&up_read_work);
> 		if (work->irq_work.flags & IRQ_WORK_BUSY)
> 			/* cannot queue more up_read, fallback */
> @@ -328,7 +327,7 @@ static void stack_map_get_build_id_offset(struct bpf_=
stack_build_id *id_offs,
> 		id_offs[i].status =3D BPF_STACK_BUILD_ID_VALID;
> 	}
>=20
> -	if (!in_nmi_ctx) {
> +	if (!work) {
> 		up_read(&current->mm->mmap_sem);
> 	} else {
> 		work->sem =3D &current->mm->mmap_sem;
> --=20
> 2.9.0
>=20

Acked-by: Song Liu <songliubraving@fb.com>=