Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v3 3/6] staging: r8188eu: add error handling of rtw_read8
To:     David Laight <David.Laight@ACULAB.COM>,
        'Dan Carpenter' <dan.carpenter@oracle.com>
Cc:     "Larry.Finger@lwfinger.net" <Larry.Finger@lwfinger.net>,
        "phil@philpotter.co.uk" <phil@philpotter.co.uk>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "straube.linux@gmail.com" <straube.linux@gmail.com>,
        "fmdefrancesco@gmail.com" <fmdefrancesco@gmail.com>,
        "linux-staging@lists.linux.dev" <linux-staging@lists.linux.dev>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
References: <cover.1629789580.git.paskripkin@gmail.com>
 <c59d5d850bf9aab208704182c83086609289cb9c.1629789580.git.paskripkin@gmail.com>
 <f5c20e0f1b934e04ad11a3627d71f5db@AcuMS.aculab.com>
 <20210826112745.5e1421ed@gmail.com>
 <a251767ca181405b93b5ea55a26c3ff0@AcuMS.aculab.com>
 <20210826112127.GZ1931@kadam>
 <dc133b63e1f54f45a19e67d75a6fcb40@AcuMS.aculab.com>
From:   Pavel Skripkin <paskripkin@gmail.com>
Message-ID: <b4d8ed8f-db03-a5b1-bb7a-0f086ea8ffbd@gmail.com>
Date:   Fri, 27 Aug 2021 11:22:57 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <dc133b63e1f54f45a19e67d75a6fcb40@AcuMS.aculab.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 8/27/21 11:14 AM, David Laight wrote:
> From: Dan Carpenter
>> Sent: 26 August 2021 12:21
> ...
>> > > > ...
>> > > > > +		len += snprintf(page + len, count - len,
>> > > > > "rtw_read8(0x%x)=0x%x\n",
>> > > > > +				proc_get_read_addr, (u8) tmp);
>> > > >
>> > > > That is broken.
>> > > >
>> > >
>> > > Don't get it, sorry. Previous code did exactly the same thing, but
>> > > didn't check if read() was successful.
>> >
>> > Look up the return value of snprintf().
>> >
>> 
>> It's hard to understand what you are saying.  I think you are confusing
>> libc snprintf with the kernel snprintf?  In libc the snprintf function
>> can return negatives but in the kernel it cannot.  This is not going
>> to change.  Any code which checks for negative snprintf returns in the
>> kernel is wrong and should be fixed.
>> 
>> Anyway, the code works fine.  snprintf here is going to return a number
>> between 18-32 range.  It's not going to overflow the PAGE_SIZE buffer.
> 
> IIRC it is also in a loop ...
> 
> Maybe, but the idiom is just broken.
> Largely the result of snprintf() is never the value you are looking
> for and should be ignored.
> 

AFAIK, snprintf return value is largely used in sysfs at least.

$ grep -Ir "= snprintf" | wc -l
1200

Anyway, I will convert this dead code to sysfs interface and maybe 
snprintf will go away...


Thank you for your help and comments


> Userspace fprintf() is even worse.
> If you care about the write failing you need to call fflush()
> and then ferror() (typically before fclose()).
> 
> Fortunately I've never seen a 'must check' attribute on it.
> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
> 


With regards,
Pavel Skripkin