Re: kmemcheck warnings (con_font_op, fuse_open_common)

[Sitsofe Wheeler <sitsofe@yahoo.com>]

Hello,

> From: Vegard Nossum <vegard.nossum@gmail.com>

> 
> 2009/3/1 Sitsofe Wheeler :
> > Hi,
> >
> > I've run kmemcheck with the latest -tip and most of the warnings I was
> > getting have now died down. However dmesg seems to have warnings that
> > look somewhat legitimate now (and there are quite a few). Further after
> > a suspend to ram/resume one particular warning related to worker_thread
> > started appearing over and over. For now I've attached a slightly
> > modified dmesg below to see what you think:
> 
> You did suspend to ram/resume with kmemcheck!? And it worked? WOW! :-D

No one told me it wasn't supposed to work so... :D

> > [  311.779612]  [] copy_to_user+0x3e/0x60
> > [  311.780335]  [] con_font_op+0x290/0x3f0
> 
> This one is very likely a real information leak, because it does a
> copy to userspace (and the only way this can . On the other hand, the
> memory _does_ look like it's been initialized (all 0xff). IIRC, I
> tracked this one down to an overlong copy in vgacon before. But I'd
> have to look at it again...

For some reason I am sure that you had tracked this down before too. I think
I confused this with the drm patch you sent a few months ago in one of my
earlier emails.
 
> > [  312.284408] Pid: 952, comm: usplash Not tainted 
> (2.6.29-rc6-tip-02247-gf8dda9e #68) 900
> > [  312.284418] EIP: 0060:[] EFLAGS: 00013002 CPU: 0
> > [  312.284433] EIP is at __dequeue_signal+0xb7/0x140
> 
> This is in general a false positive. This case looks a little
> different from what I've seen here, though.

OK now I'm aware I will avoid bringing this type of message up in 
the future.

> > [ 1795.445139] Pid: 3898, comm: gvfs-fuse-daemo Not tainted 
> (2.6.29-rc6-tip-02247-gf8dda9e #68) 900
> > [ 1795.445146] EIP: 0060:[] EFLAGS: 00010246 CPU: 0
> > [ 1795.445159] EIP is at fuse_file_alloc+0x69/0x90
> 
> Hm. This is a false positive too. RB_CLEAR_NODE() will do a read on
> the uninitialized value before writing back the new parent pointer
> (colour remains uninitialized, however). I suspect that we could get
> away with changing RB_CLEAR_NODE() to just set the colour to 0 at the
> same time.

I have to admit I was struggling with this one for a long time. I was sure
that ff could not be uninitialized if it wasn't NULL :)
 
> Thanks for the report! I will try to fix the false positives (by
> annotating the code paths in question), and investigate the rest. It's
> a bit sad to see that we (still) have such a high false-positive rate,
> but it can't really be helped.

It sounds like a tricky business (plus I would guess that only the major paths
will wind up annotated even though drivers could really benefit from this). The
problem is that in the hands of inexpert users (such as myself) there is a strong
desire to simply report every kmemcheck warning and leave someone else to 
understand if it is legit. I'm trying to get a feel (purely based on the look of the 
stacktrace, whether the memory is initialized at all and frequency of the error) 
so that intuitively I am less likely to report false positives. Your guide (especially
the bit mentioned addr2line) has been really helpful too.