https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-4629 Lustre <p>This is a common ticket for all issues found by static analysis tools.<br/> The several patches are expected for this ticket.</p> LU-4629

Issues found by static analysis tools

Bug Critical Resolved Fixed Dmitry Eremin Dmitry Eremin kw Thu, 13 Feb 2014 19:32:52 +0000 Wed, 30 Aug 2023 21:40:00 +0000 Fri, 20 Jun 2014 05:07:01 +0000 Lustre 2.6.0 0 8 <p>Reviewed patches can be observed by <a href="http://review.whamcloud.com/#/q/message:LU-4629,n,z" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/q/message:LU-4629,n,z</a><br/> Merged patches can be observed by <a href="http://review.whamcloud.com/#/q/message:LU-4629+status:merged,n,z" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/q/message:LU-4629+status:merged,n,z</a></p> <p>I noticed several of these patches handle code paths that previously ignored returned NULL pointers. What I find confusing is when is LASSERT a proper solution versus just handling the error condition. There doesn't seem to be any clear standard in this practice in the Lustre code.</p> <p>James, there are two types of 'capsules' - server and client. Client 'capsule' is request buffers packed on client, server - packed reply buffers on server. So the main rule is to don't assert on wire data, so server must checks all clients buffers and return -EPROTO on them in case of error, the client must do the same for server buffers. Meanwhile server may assert on own just packed reply buffers because this means internal logic error in code, e.g. buffer wasn't properly packed. Just an error code is not working well in such cases because may be not noticed for a long time, while assertion will occur during new code development/testing, well, it should at least. </p> <p>So we are talking about two different cases - checking the incoming data through the wire (protocol correctness) and internal checks for code correctness, e.g. buffer must exists after successful allocation.</p> <p>Thank you Mikhail for the explanation. I have noticed several patches deal with strncpy issues. Why not use the kernels internal kstr* functions instead. This would seem a better way to go. We just have to implement wrappers for the non linux platforms.</p> <p>In most places buffer already allocated and usage of kstrndup() is not appropriate. Also I don't think that allocation many little chunks is a good idea. I prefer to allocate big chunk once instead of many small.</p> <p>Add more patches: <a href="http://review.whamcloud.com/#/q/message:LU-4629,n,z" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/q/message:LU-4629,n,z</a></p> <p>Remaining open patches landed for 2.6. Any future such issues will be tracked under new tickets linked to this one</p> <p>Hi Peter, Oleg</p> <p>Could we get this one bug completed with the review process and committed to 2.5?</p> <p>Thanks,<br/> Ian Costello</p> Duplicate LU-5172 Related LU-7595 LU-10264 LU-10657 LU-10658 LU-10668 LU-10772 LU-10811 LU-10896 LU-5384 LU-7354 LU-2753 LU-10528 LU-5831 LU-5832 LU-5865 LU-5869 LU-6021 LU-10809 LU-11021 LU-5200 LU-5316 LU-5382 LU-5383 LU-5493 LU-5864 LU-5870 LU-5922 LU-8128 LU-9057 LU-9077 LU-9152 LU-9315 LU-9513 LU-2875 Development Rank 1|hzwf2v: Rank (Obsolete) 12663 Severity