On 03/23/2012 11:39 AM, Tim Bird wrote:
> On 03/22/2012 05:06 AM, Jason Wessel wrote:
>> On 03/22/2012 01:30 AM, Dan Carpenter wrote:
>>> Hello Tim Bird,
>>>
>>> This is a semi-automatic email about new static checker warnings.
>>>
>>> The patch 3492c71d374c: "kdb: Avoid using dbg_io_ops until it is 
>>> initialized" from Sep 21, 2011, leads to the following Smatch 
>>> complaint:
>>>
>>> kernel/debug/kdb/kdb_io.c:746 vkdb_printf()
>>>      error: we previously assumed 'dbg_io_ops' could be null (see line 692)
>>>
>>> kernel/debug/kdb/kdb_io.c
>>>    691              } else {
>>>    692                      if (dbg_io_ops && !dbg_io_ops->is_console) {
>>>                             ^^^^^^^^^^
>>> New check.
>>>
>>>    693                              len = strlen(kdb_buffer);
>>>    694                              cp = kdb_buffer;
>>>    695                              while (len--) {
>>>    696                                      dbg_io_ops->write_char(*cp);
>>>    697                                      cp++;
>>>    698                              }
>>>    699                      }
>>>
>>>     [snip]
>>>
>>>    742      
>>>    743                      kdb_input_flush();
>>>    744                      c = console_drivers;
>>>    745      
>>>    746                      if (!dbg_io_ops->is_console) {
>>>                              ^^^^^^^^^^
>>> Old dereference.  Should we check here as well?
>> I had the same question when I reviewed and tested this code.  This section 
>> of code is protected by the kdb pager block, where dbg_io_ops cannot be null.
>>
>> Should I be adding a comment to that effect, or just pay the price for the 
>> null check to squelch the warning?
> I double-checked this in my code, and was surprised to see that
> I already had a null check here.  Hmm...  There's something wrong
> with my patch submission skils, that this didn't get included
> in my original patch. :-(
>
> I have to admit that the states that affect this function are somewhat
> baffling to me.  I hate adding extra code, but it's probably safest to
> add the check.  We know that during bootup dbg_io_ops spends some time
> being null.  I would hate to see a future modification to some unrelated state
> (e.g. some change to the kdb pager block, which looks completely unrelated),
> allow us to hit this problem again in the future.
>
> My vote would be to add the check.

No problem.  I'll make a simple patch, post it, and put it in the queue, to 
clean it up before 3.4-rc2.

Cheers,
Jason.

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Kgdb-bugreport mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport

Reply via email to