linux-kernel - Re: [S390] cio: kernel stack overflow.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ed4m57$gb0$1@taverner.cs.berkeley.edu>
Date:	Wed, 30 Aug 2006 18:41:43 +0000 (UTC)
From:	daw@...berkeley.edu (David Wagner)
To:	linux-kernel@...r.kernel.org
Subject: Re: [S390] cio: kernel stack overflow.

Martin Schwidefsky  wrote:
>-      chp->dev = (struct device) {
>-              .parent  = &css[0]->device,
>-              .release = chp_release,
>-      };
>+      chp->dev.parent = &css[0]->device;
>+      chp->dev.release = chp_release;

>On 8/30/06, David Wagner <daw@...berkeley.edu> wrote:
>Unless I'm missing something, it looks to
>me like this diff causes a change in the semantics of the code.

Julio Auto wrote:
>I can't see the semantic change.

Maybe "semantic change" isn't the right term.  I'm not sure how gcc
handles the case where some field (like .bus) is missing from the C99
initializer as the struct device is created -- but it seemed plausible to
me that gcc might guarantee that all missing fields are automatically
initialized to 0 when the struct is constructed.  If this is the
case, then the semantic change is that the original code guarantees
to initialize chp->dev.bus to 0, whereas the proposed replacement code
does not.  I don't know whether gcc actually promises to initialize to
0 all unmentioned fields, or whether the C standard requires that, but
you could imagine some compiler making that promise (it is a reasonable
thing to do).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/