----- Original Message ----- > From: "Niels de Vos" <ndevos@xxxxxxxxxx> > To: "Atin Mukherjee" <amukherj@xxxxxxxxxx> > Cc: "Gluster Devel" <gluster-devel@xxxxxxxxxxx> > Sent: Wednesday, December 17, 2014 2:21:50 PM > Subject: Re: Help needed with Coverity - How to remove tainted_data_argument? > > On Wed, Dec 17, 2014 at 01:54:09PM +0530, Atin Mukherjee wrote: > > > > > > On 12/17/2014 01:01 PM, Lalatendu Mohanty wrote: > > > On 12/17/2014 12:56 PM, Krishnan Parthasarathi wrote: > > >> I was looking into a Coverity issue (CID 1228603) in GlusterFS. > > >> I sent a patch[1] before I fully understood why this was an issue. > > >> After searching around in the internet for explanations, I identified > > >> that > > >> the core issue was that a character buffer, storing parts of a file > > >> (external I/O), > > >> was marked tainted. This taint spread wherever the buffer was used. > > >> This seems > > >> acceptable in the context of static analysis. How do we indicate to > > >> Coverity that > > >> the 'taint' would cause no harm as speculated? > > >> > > >> [1] - Coverity fix attempt: http://review.gluster.org/#/c/9286/ > > >> [2] - CID 1228603: Use of untrusted scalar value (TAINTED_SCALAR): > > >> glusterd-utils.c: 2131 in glusterd_readin_file() > > >> > > >> thanks, > > >> kp > > >> _______________________________________________ > > >> Gluster-devel mailing list > > >> Gluster-devel@xxxxxxxxxxx > > >> http://supercolony.gluster.org/mailman/listinfo/gluster-devel > > > KP, > > > > > > We can mark the CID in Coverity scan website that it is not an issue > > > (i.e. as designed) and it would stop reporting it as a bug. > > Question is whether coverity will stop reporting on such occurrences in > > other places in future, my guess is no. Idea is to make coverity > > understand that this pattern should not be reported further. > > This pattern can be dangerous. I think we need to review all occurences > and mark each occurence as 'intentional' or 'not a bug' if the usage is > safe. The unsafe occurences would receive a patch. +1. We should analyse each occurrence, there could be a potential unsafe usage as well. > > Niels > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxxx > http://supercolony.gluster.org/mailman/listinfo/gluster-devel > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
