linux-kernel - RE: [PATCH v7 1/4] cpumask: introduce cpumap_print_to

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: <aae18c255c554dbaabbb0cd8ce3449f2@hisilicon.com>
Date:   Fri, 16 Jul 2021 00:57:43 +0000
From:   "Song Bao Hua (Barry Song)" <song.bao.hua@...ilicon.com>
To:     Yury Norov <yury.norov@...il.com>
CC:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "andriy.shevchenko@...ux.intel.com" 
        <andriy.shevchenko@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dave.hansen@...el.com" <dave.hansen@...el.com>,
        "linux@...musvillemoes.dk" <linux@...musvillemoes.dk>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>,
        "agordeev@...ux.ibm.com" <agordeev@...ux.ibm.com>,
        "sbrivio@...hat.com" <sbrivio@...hat.com>,
        "jianpeng.ma@...el.com" <jianpeng.ma@...el.com>,
        "valentin.schneider@....com" <valentin.schneider@....com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "bristot@...hat.com" <bristot@...hat.com>,
        "guodong.xu@...aro.org" <guodong.xu@...aro.org>,
        tangchengchang <tangchengchang@...wei.com>,
        "Zengtao (B)" <prime.zeng@...ilicon.com>,
        yangyicong <yangyicong@...wei.com>,
        "tim.c.chen@...ux.intel.com" <tim.c.chen@...ux.intel.com>,
        Linuxarm <linuxarm@...wei.com>,
        "tiantao (H)" <tiantao6@...ilicon.com>
Subject: RE: [PATCH v7 1/4] cpumask: introduce cpumap_print_to_buf to support
 large bitmask and list



> -----Original Message-----
> From: Song Bao Hua (Barry Song)
> Sent: Friday, July 16, 2021 9:08 AM
> To: 'Yury Norov' <yury.norov@...il.com>
> Cc: gregkh@...uxfoundation.org; akpm@...ux-foundation.org;
> andriy.shevchenko@...ux.intel.com; linux-kernel@...r.kernel.org;
> dave.hansen@...el.com; linux@...musvillemoes.dk; rafael@...nel.org;
> rdunlap@...radead.org; agordeev@...ux.ibm.com; sbrivio@...hat.com;
> jianpeng.ma@...el.com; valentin.schneider@....com; peterz@...radead.org;
> bristot@...hat.com; guodong.xu@...aro.org; tangchengchang
> <tangchengchang@...wei.com>; Zengtao (B) <prime.zeng@...ilicon.com>;
> yangyicong <yangyicong@...wei.com>; tim.c.chen@...ux.intel.com; Linuxarm
> <linuxarm@...wei.com>; tiantao (H) <tiantao6@...ilicon.com>
> Subject: RE: [PATCH v7 1/4] cpumask: introduce cpumap_print_to_buf to support
> large bitmask and list
> 
> 
> 
> > -----Original Message-----
> > From: Yury Norov [mailto:yury.norov@...il.com]
> > Sent: Friday, July 16, 2021 3:29 AM
> > To: Song Bao Hua (Barry Song) <song.bao.hua@...ilicon.com>
> > Cc: gregkh@...uxfoundation.org; akpm@...ux-foundation.org;
> > andriy.shevchenko@...ux.intel.com; linux-kernel@...r.kernel.org;
> > dave.hansen@...el.com; linux@...musvillemoes.dk; rafael@...nel.org;
> > rdunlap@...radead.org; agordeev@...ux.ibm.com; sbrivio@...hat.com;
> > jianpeng.ma@...el.com; valentin.schneider@....com; peterz@...radead.org;
> > bristot@...hat.com; guodong.xu@...aro.org; tangchengchang
> > <tangchengchang@...wei.com>; Zengtao (B) <prime.zeng@...ilicon.com>;
> > yangyicong <yangyicong@...wei.com>; tim.c.chen@...ux.intel.com; Linuxarm
> > <linuxarm@...wei.com>; tiantao (H) <tiantao6@...ilicon.com>
> > Subject: Re: [PATCH v7 1/4] cpumask: introduce cpumap_print_to_buf to support
> > large bitmask and list
> >
> > On Thu, Jul 15, 2021 at 11:58:53PM +1200, Barry Song wrote:
> > > (10.1.198.147)
> > > X-CFilter-Loop: Reflected
> > > Status: O
> > > Content-Length: 10263
> > > Lines: 252
> > >
> > > From: Tian Tao <tiantao6@...ilicon.com>
> >
> > [...]
> >
> > > +int bitmap_print_to_buf(bool list, char *buf, const unsigned long *maskp,
> > > +		int nmaskbits, loff_t off, size_t count)
> > > +{
> > > +	const char *fmt = list ? "%*pbl\n" : "%*pb\n";
> > > +	ssize_t size;
> > > +	void *data;
> > > +
> > > +	data = kasprintf(GFP_KERNEL, fmt, nmaskbits, maskp);
> > > +	if (!data)
> > > +		return -ENOMEM;
> > > +
> > > +	size = memory_read_from_buffer(buf, count, &off, data, strlen(data) +
> 1);
> > > +	kfree(data);
> > > +
> > > +	return size;
> > > +}
> > > +EXPORT_SYMBOL(bitmap_print_to_buf);
> >
> > In discussion to v4 of this series I've pointed out inefficiency of
> > this approach. Now it's v7, but the problem is still there.
> >
> > 1. You make user of your API guess aboout proper @count without any
> >    hint. This is worse than how it works now with pure vsnprintf().
> 
> This isn't true. While this count comes from sysfs bin_attribute,
> sysfs show() entry guarantee the count is proper and inside the
> valid range of the buffer. Otherwise, sysfs bin_attribute has totally
> broken for all users.

In addition, "You make user of your API guess about proper @count
without any hint" isn't true either. For a sysfs ABI and other
files, users will get EOF when it arrives the end of the file.
This is exactly the hint for users to stop further reading.

The new APIs are serving ABI purpose. hardly other kernel modules
will want a printed list.

Thanks
Barry