Messages in this thread | | | From | (David Wagner) | Subject | Re: [S390] cio: kernel stack overflow. | Date | Wed, 30 Aug 2006 19:05:54 +0000 (UTC) |
| |
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/
| |