From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9817AC433E0 for ; Wed, 29 Jul 2020 20:11:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6E795206D7 for ; Wed, 29 Jul 2020 20:11:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726810AbgG2ULb (ORCPT ); Wed, 29 Jul 2020 16:11:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56208 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726365AbgG2ULb (ORCPT ); Wed, 29 Jul 2020 16:11:31 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C3B5BC061794; Wed, 29 Jul 2020 13:11:30 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1k0sQ1-005BLO-LM; Wed, 29 Jul 2020 20:11:17 +0000 Date: Wed, 29 Jul 2020 21:11:17 +0100 From: Al Viro To: Jiri Olsa Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , netdev@vger.kernel.org, bpf@vger.kernel.org, Song Liu , Yonghong Song , Martin KaFai Lau , David Miller , John Fastabend , Wenbo Zhang , KP Singh , Brendan Gregg , Florent Revest Subject: Re: [PATCH v8 bpf-next 09/13] bpf: Add d_path helper Message-ID: <20200729201117.GA1233513@ZenIV.linux.org.uk> References: <20200722211223.1055107-1-jolsa@kernel.org> <20200722211223.1055107-10-jolsa@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200722211223.1055107-10-jolsa@kernel.org> Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Wed, Jul 22, 2020 at 11:12:19PM +0200, Jiri Olsa wrote: > +BPF_CALL_3(bpf_d_path, struct path *, path, char *, buf, u32, sz) > +{ > + char *p = d_path(path, buf, sz - 1); > + int len; > + > + if (IS_ERR(p)) { > + len = PTR_ERR(p); > + } else { > + len = strlen(p); > + if (len && p != buf) > + memmove(buf, p, len); *blink* What the hell do you need that strlen() for? d_path() copies into the end of buffer (well, starts there and prepends to it); all you really need is memmove(buf, p, buf + sz - p) > + buf[len] = 0; Wait a minute... Why are you NUL-terminating it separately? You do rely upon having NUL in the damn thing (and d_path() does guarantee it there). Without that strlen() would've gone into the nasal demon country; you can't call it on non-NUL-terminated array. So you are guaranteed that p[len] will be '\0'; why bother copying the first len bytes and then separately deal with that NUL? Just memmove() the fucker and be done with that... If you are worried about stray NUL in the middle of the returned data... can't happen. Note the rename_lock use in fs/d_path.c; the names of everything involved are guaranteed to have been stable throughout the copying them into the buffer - if anything were to be renamed while we are doing that, we'd repeat the whole thing (with rename_lock taken exclusive the second time around). So make it simply if (IS_ERR(p)) return PTR_ERR(p); len = buf + sz - p; memmove(buf, p, len); return len; and be done with that. BTW, the odds of p == buf are pretty much nil - it would happen only if sz - 1 happened to be the exact length of pathname.