Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <6ffce33f-8ab7-a29a-e931-8d7522cfa8ab@gmail.com>
Date:   Mon, 8 Aug 2022 00:27:19 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.1.0
Subject: Re: [PATCH v5 29/32] d_path: prt_path()
Content-Language: en-US
To:     Al Viro <viro@zeniv.linux.org.uk>,
        "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc:     linux-kernel@vger.kernel.org, pmladek@suse.com
References: <20220808024128.3219082-1-willy@infradead.org>
 <20220808024128.3219082-30-willy@infradead.org> <YvCOVGdlGqRVlZwL@ZenIV>
From:   Kent Overstreet <kent.overstreet@gmail.com>
In-Reply-To: <YvCOVGdlGqRVlZwL@ZenIV>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 8/8/22 00:17, Al Viro wrote:
> On Mon, Aug 08, 2022 at 03:41:25AM +0100, Matthew Wilcox (Oracle) wrote:
>> From: Kent Overstreet <kent.overstreet@gmail.com>
>>
>> This implements a new printbuf version of d_path()/mangle_path(), which
>> will replace the seq_buf version.
>>
>> Part of what we're trying to do with printbufs is standardizing a
>> calling convention so they don't have to live in lib/vsprintf.c, and can
>> instead with the code for the types they're printing - so this patch
>> adds prt_path() to d_path.c, another patch will switch vsprintf.c to use
>> it.
> 
> To use it for *what*?  If you mean replacing %pd with it - forget about that.
> Not going to happen.
> 
> There's a hard requirement for printk - it should be safe to call in any
> locking environment.  d_path() isn't, and that's impossible to avoid.

Oof, good catch. It was to replace seq_buf_path() in this patch series, 
and is only used in trace_seq.c. I'll have to investigate what's going 
on in the tracing code, because now that you mention it that did look 
suspect.