On Tue, Sep 18, 2018 at 08:02:30PM +0800, Gao Xiang wrote: > Hi Greg, > > On 2018/9/18 19:19, Greg Kroah-Hartman wrote: > > On Fri, Sep 14, 2018 at 10:40:22PM +0800, Gao Xiang wrote: > >> In order to avoid conflicts with cleanup patches, Chao and I think > >> it is better to send reviewed preview patches in the erofs mailing list > >> to the community in time. > >> > >> So here is reviewed & tested patches right now, which clean up and > >> enhance the error handing and add some tracepoints for decompression. > >> > >> Note that in this patchset, bare use of 'unsigned' and NULL comparison are > >> also fixed compared with the preview patches according to the previous > >> discussion in the staging mailing list. > > > > I applied this, but I need to go delete it as this patch series adds a > > build warning to the system: > > > > In file included from drivers/staging/erofs/unzip_vle.h:16:0, > > from drivers/staging/erofs/unzip_vle.c:13: > > drivers/staging/erofs/unzip_vle.c: In function ‘z_erofs_map_blocks_iter’: > > drivers/staging/erofs/internal.h:303:34: warning: ‘pblk’ may be used uninitialized in this function [-Wmaybe-uninitialized] > > #define blknr_to_addr(nr) ((erofs_off_t)(nr) * EROFS_BLKSIZ) > > ^ > > drivers/staging/erofs/unzip_vle.c:1574:20: note: ‘pblk’ was declared here > > erofs_blk_t mblk, pblk; > > ^~~~ > > > > Please fix that up and resend. > > strange... my compiler (4.8.4) and huawei internal CI don't report that, > and this patchset has been in Chao's tree for a while, I don't get any report so far... > > I just looked into that code again and it seems a false warning since > 1) this code is heavily running on the products and working fine till now. > 2) pblk gets a proper value before unzip_vle.c:1690 map->m_pa = blknr_to_addr(pblk); > > so I think I need to silence this warning for now and check if there is a really issue.... Don't just silent the warning. Usually gcc now properly detects where there really is a problem, it should not be a false-positive. And in looking at the code, it does seem that pblk could not be set if one of the different case statements is taken and then exact_hitted: is jumped to, right? Or is gcc just being "dumb" here? What about clang, have you tried building it with that compiler as well? thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
