linux-kernel - Re: [PATCH v3 02/25] printk: Add print format (%par) for struct range

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <66c77b1c5c65c_1719d2940@iweiny-mobl.notmuch>
Date: Thu, 22 Aug 2024 12:53:32 -0500
From: Ira Weiny <ira.weiny@...el.com>
To: Petr Mladek <pmladek@...e.com>, Ira Weiny <ira.weiny@...el.com>
CC: Dave Jiang <dave.jiang@...el.com>, Fan Ni <fan.ni@...sung.com>, "Jonathan
 Cameron" <Jonathan.Cameron@...wei.com>, Navneet Singh
	<navneet.singh@...el.com>, Chris Mason <clm@...com>, Josef Bacik
	<josef@...icpanda.com>, David Sterba <dsterba@...e.com>, Steven Rostedt
	<rostedt@...dmis.org>, Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Rasmus Villemoes <linux@...musvillemoes.dk>, Sergey Senozhatsky
	<senozhatsky@...omium.org>, Jonathan Corbet <corbet@....net>, Andrew Morton
	<akpm@...ux-foundation.org>, Dan Williams <dan.j.williams@...el.com>,
	Davidlohr Bueso <dave@...olabs.net>, Alison Schofield
	<alison.schofield@...el.com>, Vishal Verma <vishal.l.verma@...el.com>,
	<linux-btrfs@...r.kernel.org>, <linux-cxl@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-doc@...r.kernel.org>,
	<nvdimm@...ts.linux.dev>
Subject: Re: [PATCH v3 02/25] printk: Add print format (%par) for struct range

Petr Mladek wrote:
> On Fri 2024-08-16 09:44:10, Ira Weiny wrote:
> > The use of struct range in the CXL subsystem is growing.  In particular,
> > the addition of Dynamic Capacity devices uses struct range in a number
> > of places which are reported in debug and error messages.
> > 
> > To wit requiring the printing of the start/end fields in each print
> > became cumbersome.  Dan Williams mentions in [1] that it might be time
> > to have a print specifier for struct range similar to struct resource
> > 
> > A few alternatives were considered including '%pn' for 'print raNge' but
> > %par follows that struct range is most often used to store a range of
> > physical addresses.  So use '%par' for 'print address range'.
> > 
> > --- a/Documentation/core-api/printk-formats.rst
> > +++ b/Documentation/core-api/printk-formats.rst
> > @@ -231,6 +231,20 @@ width of the CPU data path.
> >  
> >  Passed by reference.
> >  
> > +Struct Range
> > +------------
> > +
> > +::
> > +
> > +	%par	[range 0x60000000-0x6fffffff] or
> 
> It seems that it is always 64-bit. It prints:
> 
> struct range {
> 	u64   start;
> 	u64   end;
> };

Indeed.  Thanks I should not have just copied/pasted.

> 
> > +		[range 0x0000000060000000-0x000000006fffffff]
> > +
> > +For printing struct range.  A variation of printing a physical address is to
> > +print the value of struct range which are often used to hold a physical address
> > +range.
> > +
> > +Passed by reference.
> > +
> >  DMA address types dma_addr_t
> >  ----------------------------
> >  
> > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > index 2d71b1115916..c132178fac07 100644
> > --- a/lib/vsprintf.c
> > +++ b/lib/vsprintf.c
> > @@ -1140,6 +1140,39 @@ char *resource_string(char *buf, char *end, struct resource *res,
> >  	return string_nocheck(buf, end, sym, spec);
> >  }
> >  
> > +static noinline_for_stack
> > +char *range_string(char *buf, char *end, const struct range *range,
> > +		      struct printf_spec spec, const char *fmt)
> > +{
> > +#define RANGE_PRINTK_SIZE		16
> > +#define RANGE_DECODED_BUF_SIZE		((2 * sizeof(struct range)) + 4)
> > +#define RANGE_PRINT_BUF_SIZE		sizeof("[range - ]")
> 
> I think that it should be "[range -]"

Sounds good.

> 
> > +	char sym[RANGE_DECODED_BUF_SIZE + RANGE_PRINT_BUF_SIZE];
> > +	char *p = sym, *pend = sym + sizeof(sym);
> > +
> > +	static const struct printf_spec str_spec = {
> > +		.field_width = -1,
> > +		.precision = 10,
> > +		.flags = LEFT,
> > +	};
> 
> Is this really needed? What about using "default_str_spec" instead?

Because I got confused and was coping from resource_string().

Deleted now...

> 
> > +	static const struct printf_spec range_spec = {
> > +		.base = 16,
> > +		.field_width = RANGE_PRINTK_SIZE,

However, my testing indicates this needs to be.

                .field_width = 18, /* 2 (0x) + 2 * 8 (bytes) */

... to properly zero pad the value.  Does that make sense?

> > +		.precision = -1,
> > +		.flags = SPECIAL | SMALL | ZEROPAD,
> > +	};
> > +
> > +	*p++ = '[';
> > +	p = string_nocheck(p, pend, "range ", str_spec);
> > +	p = number(p, pend, range->start, range_spec);
> > +	*p++ = '-';
> > +	p = number(p, pend, range->end, range_spec);
> > +	*p++ = ']';
> > +	*p = '\0';
> > +
> > +	return string_nocheck(buf, end, sym, spec);
> > +}
> > +
> >  static noinline_for_stack
> >  char *hex_string(char *buf, char *end, u8 *addr, struct printf_spec spec,
> >  		 const char *fmt)
> 
> Also add a selftest into lib/test_printf.c, please.

Yes of course...  Makes testing easier too.

Thanks,
Ira

> 
> Best Regards,
> Petr