All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: David Wagner <daw-usenet@taverner.cs.berkeley.edu>,
	linux-kernel@vger.kernel.org
Subject: Re: [S390] cio: kernel stack overflow.
Date: Thu, 31 Aug 2006 11:06:07 +0200	[thread overview]
Message-ID: <1157015167.23755.7.camel@localhost> (raw)
In-Reply-To: <20060830191927.GA8408@osiris.ibm.com>

On Wed, 2006-08-30 at 21:19 +0200, Heiko Carstens 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?
> 
> You're right. Thanks for pointing this out! I will take care of it.

The ccw_device_id structure contains two more fields in addition to the
field that are set up in ccw_device_recog_done, namely match_flags and
driver_info. driver_info is set later in ccw_bus_match, so that is fine.
match_flags of the device is never used, only the match_flags of the
drivers version of the ccw_device_id is used. So the code is correct
even without the memset. But your point about the maintenance pitfall is
valid, we will add a memset after 2.6.18. I don't want to push yet
another patch.

-- 
blue skies,
  Martin.

Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH

"Reality continues to ruin my life." - Calvin.



  reply	other threads:[~2006-08-31  9:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-30 12:40 [S390] cio: kernel stack overflow Martin Schwidefsky
2006-08-30 17:09 ` David Wagner
2006-08-30 17:40   ` Martin Schwidefsky
2006-08-30 17:52   ` Julio Auto
2006-08-30 18:20     ` Julio Auto
2006-08-30 18:41     ` David Wagner
2006-08-30 19:05 ` David Wagner
2006-08-30 19:19   ` Heiko Carstens
2006-08-31  9:06     ` Martin Schwidefsky [this message]
2006-08-30 19:25   ` Julio Auto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1157015167.23755.7.camel@localhost \
    --to=schwidefsky@de.ibm.com \
    --cc=daw-usenet@taverner.cs.berkeley.edu \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.