diff mbox series

[v1,10/12] nfsd: Avoid non-flexible API in seq_quote_mem()

Message ID 20210503204907.34013-11-andriy.shevchenko@linux.intel.com (mailing list archive)
State New
Headers show
Series lib/string_helpers: get rid of ugly *_escape_mem_ascii() API | expand

Commit Message

Andy Shevchenko May 3, 2021, 8:49 p.m. UTC
string_escape_mem_ascii() followed by seq_escape_mem_ascii() is completely
non-flexible and shouldn't be exist from day 1.

Replace it with properly called string_escape_mem().

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 fs/nfsd/nfs4state.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

Comments

Al Viro May 3, 2021, 8:53 p.m. UTC | #1
On Mon, May 03, 2021 at 11:49:05PM +0300, Andy Shevchenko wrote:
> string_escape_mem_ascii() followed by seq_escape_mem_ascii() is completely
> non-flexible and shouldn't be exist from day 1.
> 
> Replace it with properly called string_escape_mem().


NAKed-by: Al Viro <viro@zeniv.linux.org.uk>

Reason: use of seq_get_buf().  Which should have been static inline in
fs/seq_file.c, to start with.

Again, any new uses of seq_get_buf()/seq_commit() are grounds for automatic
NAK.  These interfaces *will* be withdrawn.
Andy Shevchenko May 3, 2021, 8:56 p.m. UTC | #2
On Mon, May 3, 2021 at 11:54 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Mon, May 03, 2021 at 11:49:05PM +0300, Andy Shevchenko wrote:
> > string_escape_mem_ascii() followed by seq_escape_mem_ascii() is completely
> > non-flexible and shouldn't be exist from day 1.
> >
> > Replace it with properly called string_escape_mem().
>
> NAKed-by: Al Viro <viro@zeniv.linux.org.uk>
>
> Reason: use of seq_get_buf().  Which should have been static inline in
> fs/seq_file.c, to start with.

I see.

> Again, any new uses of seq_get_buf()/seq_commit() are grounds for automatic
> NAK.  These interfaces *will* be withdrawn.

You meant that this is no way to get rid of this guy?
Any suggestions how to replace that API with a newer one?
Al Viro May 3, 2021, 9:09 p.m. UTC | #3
On Mon, May 03, 2021 at 11:56:41PM +0300, Andy Shevchenko wrote:
> On Mon, May 3, 2021 at 11:54 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > On Mon, May 03, 2021 at 11:49:05PM +0300, Andy Shevchenko wrote:
> > > string_escape_mem_ascii() followed by seq_escape_mem_ascii() is completely
> > > non-flexible and shouldn't be exist from day 1.
> > >
> > > Replace it with properly called string_escape_mem().
> >
> > NAKed-by: Al Viro <viro@zeniv.linux.org.uk>
> >
> > Reason: use of seq_get_buf().  Which should have been static inline in
> > fs/seq_file.c, to start with.
> 
> I see.
> 
> > Again, any new uses of seq_get_buf()/seq_commit() are grounds for automatic
> > NAK.  These interfaces *will* be withdrawn.
> 
> You meant that this is no way to get rid of this guy?
> Any suggestions how to replace that API with a newer one?

seq_escape_mem(), perhaps?
Andy Shevchenko May 3, 2021, 9:11 p.m. UTC | #4
On Tue, May 4, 2021 at 12:09 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Mon, May 03, 2021 at 11:56:41PM +0300, Andy Shevchenko wrote:
> > On Mon, May 3, 2021 at 11:54 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> > >
> > > On Mon, May 03, 2021 at 11:49:05PM +0300, Andy Shevchenko wrote:
> > > > string_escape_mem_ascii() followed by seq_escape_mem_ascii() is completely
> > > > non-flexible and shouldn't be exist from day 1.
> > > >
> > > > Replace it with properly called string_escape_mem().
> > >
> > > NAKed-by: Al Viro <viro@zeniv.linux.org.uk>
> > >
> > > Reason: use of seq_get_buf().  Which should have been static inline in
> > > fs/seq_file.c, to start with.
> >
> > I see.
> >
> > > Again, any new uses of seq_get_buf()/seq_commit() are grounds for automatic
> > > NAK.  These interfaces *will* be withdrawn.
> >
> > You meant that this is no way to get rid of this guy?
> > Any suggestions how to replace that API with a newer one?
>
> seq_escape_mem(), perhaps?

I think I have a better idea. What about adding seq_escape_with_flags()
and seq_escape() --> seq_escape_with_flags(..., ESCAPE_OCTAL, ...) ?

Would it work for you?
Andy Shevchenko May 3, 2021, 9:14 p.m. UTC | #5
On Tue, May 4, 2021 at 12:11 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Tue, May 4, 2021 at 12:09 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
> > On Mon, May 03, 2021 at 11:56:41PM +0300, Andy Shevchenko wrote:
> > > On Mon, May 3, 2021 at 11:54 PM Al Viro <viro@zeniv.linux.org.uk> wrote:

...

> > > Any suggestions how to replace that API with a newer one?
> >
> > seq_escape_mem(), perhaps?
>
> I think I have a better idea. What about adding seq_escape_with_flags()
> and seq_escape() --> seq_escape_with_flags(..., ESCAPE_OCTAL, ...) ?
>
> Would it work for you?

Ah, it wouldn't work for the user, because it wants to pass the buffer size.
Okay, I'll take your suggestion, thanks!
diff mbox series

Patch

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index b517a8794400..15535589e5e4 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -2350,8 +2350,14 @@  static struct nfs4_client *get_nfsdfs_clp(struct inode *inode)
 
 static void seq_quote_mem(struct seq_file *m, char *data, int len)
 {
+	char *buf;
+	size_t size = seq_get_buf(m, &buf);
+	const char *only = "\"\\";
+	int ret;
+
 	seq_printf(m, "\"");
-	seq_escape_mem_ascii(m, data, len);
+	ret = string_escape_mem(data, len, buf, size, ESCAPE_HEX | ESCAPE_APPEND, only);
+	seq_commit(m, ret < size ? ret : -1);
 	seq_printf(m, "\"");
 }