From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ramon Fried Date: Sun, 27 May 2018 11:35:55 +0300 Subject: [U-Boot] [PATCH 6/6] common: iotrace: fix behaviour when buffer is full In-Reply-To: References: <20180525104128.7990-1-ramon.fried@gmail.com> <20180525104128.7990-7-ramon.fried@gmail.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Sun, May 27, 2018 at 1:18 AM, Simon Glass wrote: > Hi Ramon, > > On 26 May 2018 at 00:05, Ramon Fried wrote: >> On Sat, May 26, 2018 at 5:07 AM, Simon Glass wrote: >>> Hi Ramon, >>> >>> On 25 May 2018 at 04:41, Ramon Fried wrote: >>>> When the buffer is full, there supposed to be no more >>>> writes, the code however misses the else statement and >>>> subsequently writes to arbitrary pointer location and increases >>>> the offset. >>> >>> I don't think so. It writes to a local variable in this case. The >>> point of this is to detect how much space would be needed to hold the >>> I/O trace. Unless the pointer is incremented, there is no way to know. >> You're right. I missed the initial assignment to rec. >> >>> >>> Perhaps instead, iotrace_get_buffer() should be updated to also return >>> the number of valid records, as well as the pointer value? >>> >> It's a valid option, another one I have in mind is that >> we can return immediately like I suggested but add one time warning >> that states that the >> buffer is full ? > > The problem is that people want to be able to resize the buffer so > that they can try again, so they need to know the correct size. > > Can you make it report that it overflowed, and print the correct size? The correct size can only be printed in the end of the tracing. Maybe we can use WARN_ONCE when it first occurs and later when the user type "iotrace stats" it will state the required buffer size to accommodate all of the entries. What do you think ? > > Regards, > Simon