Message ID | 20221121024418.1800-1-thunder.leizhen@huawei.com (mailing list archive) |
---|---|
Headers | show |
Series | fs: clear a UBSAN shift-out-of-bounds warning | expand |
On Mon, Nov 21, 2022 at 10:44:16AM +0800, Zhen Lei wrote: > v1 -- > v2: > 1. Replace INT_LIMIT(loff_t) with OFFSET_MAX in btrfs. > 2. Replace INT_LIMIT() with type_max(). Looks fine, except that I'd rather go for commit message along the lines of "INT_LIMIT tries to do what type_max does, except that type_max doesn't rely upon undefined behaviour; might as well use type_max() instead" If you want to credit UBSAN - sure, no problem, just don't clutter the commit message with that. As it is, it reads as "make $TOOL STFU"...
On 2022/11/25 14:43, Al Viro wrote: > On Mon, Nov 21, 2022 at 10:44:16AM +0800, Zhen Lei wrote: >> v1 -- > v2: >> 1. Replace INT_LIMIT(loff_t) with OFFSET_MAX in btrfs. >> 2. Replace INT_LIMIT() with type_max(). > > Looks fine, except that I'd rather go for commit message > along the lines of "INT_LIMIT tries to do what type_max does, > except that type_max doesn't rely upon undefined behaviour; > might as well use type_max() instead" Very good. Do I send v3, or do you update it? > > If you want to credit UBSAN - sure, no problem, just don't > clutter the commit message with that. As it is, it reads > as "make $TOOL STFU"... Okay, I'll pay attention next time. This USBAN problem is relatively simple and can be located without relying on other information, so I omitted the rest. After changing to your suggested description, it seems that there is no need to mention UBSAN, after all, it is just a false positive and there is no real problem. > > . >