On Wed, Feb 06, 2008 at 08:06:18PM -0800, David Miller wrote: > > Greg, I'm pretty sure I know what's happening. > > For whatever reason we're invoking dev_attr_show() on attribute_group > objects.
Ugh, that makes sense. > The reason it probably only crashes on sparc64 is because perhaps at > that dev_attr->show offset on x86 there are zero bytes there instead > of a pointer, so the NULL check here in dev_attr_show() masks the bug. > > The problem with all of this "container_of() this", "container_of() > that" is that we lose real type checking. So unless we add magic > cookies to verify or other hacks, functions never really know if the > container they are being passed really is a subset object of the type > they expect. We are supposed to be careful about this, but bad things are known to happen :) > Can you read the code instead of asking more information from me to > try and figure out why the attribute showing paths might be > misconfigured for these block device objects after the changeset in > question? I can do this, but you're more likely to find the problem > quickly than I am. Yes, I'll look into it tonight if I get this -stable push out in time, or if not, first thing in the morning. > I redid the bisect to make sure it absolutely was that specific > changeset, and it is. Thanks for doing that, I'll let you know when I have a patch to test. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/