| Message ID | 20210503204907.34013-11-andriy.shevchenko@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | lib/string_helpers: get rid of ugly *_escape_mem_ascii() API | expand |
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.
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?
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?
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?
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 --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, "\""); }
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(-)