lkml.org 
[lkml]   [2006]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [S390] cio: kernel stack overflow.
Date
Thanks for pointing out that in most cases there was immediately
preceding code that zeroes out the whole struct using kzalloc() or
memset(.., 0, ..). Sorry that I overlooked that; my mistake. That
takes care of all but one of these. But in the interests of caution,
let me ask about the following one:

Martin Schwidefsky wrote:
>- cdev->id = (struct ccw_device_id) {
>- .cu_type = cdev->private->senseid.cu_type,
>- .cu_model = cdev->private->senseid.cu_model,
>- .dev_type = cdev->private->senseid.dev_type,
>- .dev_model = cdev->private->senseid.dev_model,
>- };
>+ cdev->id.cu_type = cdev->private->senseid.cu_type;
>+ cdev->id.cu_model = cdev->private->senseid.cu_model;
>+ cdev->id.dev_type = cdev->private->senseid.dev_type;
>+ cdev->id.dev_model = cdev->private->senseid.dev_model;

I don't see any obvious place that zeroes out cdev->id.
In particular, it looks like cdev->id.match_flags and .driver_info
are never cleared (i.e., they retain whatever old garbage they had
before). More importantly, if anyone ever adds any more fields to
struct ccw_device_id, then they will also be retain old garbage values,
which is a maintenance pitfall. Is this right, or did I miss something
again?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-08-30 21:09    [W:0.050 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site