All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: steiner@sgi.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [Patch 04/12] GRU - collect per-context user statistics
Date: Mon, 8 Jun 2009 16:07:40 -0700	[thread overview]
Message-ID: <20090608160740.4d57ba5d.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090608171953.673876000@sgi.com>

On Mon, 08 Jun 2009 12:16:52 -0500
steiner@sgi.com wrote:

>  /*
> + * Fetch GSEG statisticss
> + */
> +long gru_get_gseg_statistics(unsigned long arg)
> +{
> +	struct gru_thread_state *gts;
> +	struct gru_get_gseg_statistics_req req;
> +
> +	if (copy_from_user(&req, (void __user *)arg, sizeof(req)))
> +		return -EFAULT;
> +
> +	gts = gru_find_lock_gts(req.gseg);
> +	if (gts) {
> +		memcpy(&req.stats, &gts->ustats, sizeof(gts->ustats));
> +		gru_unlock_gts(gts);
> +	} else {
> +		memset(&req.stats, 0, sizeof(gts->ustats));
> +	}
> +
> +	if (copy_to_user((void __user *)arg, &req, sizeof(req)))
> +		return -EFAULT;
> +
> +	return 0;
> +}

So..  what's happening in the super-secret undocumented gts==NULL path?

It _looks_ like userspace passed into this ioctl a handle for something
which the kernel doesn't know about.  If so, shouldn't we return
-EINVAL or something?  


  reply	other threads:[~2009-06-08 23:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-08 17:16 [Patch 00/12] GRU - GRU Driver Updates steiner
2009-06-08 17:16 ` [Patch 01/12] GRU - fix cache coherency issues with instruction retry steiner
2009-06-08 17:16 ` [Patch 02/12] GRU - add user request to explicitly unload a gru context steiner
2009-06-08 23:05   ` Andrew Morton
2009-06-12 17:51     ` Jack Steiner
2009-06-08 17:16 ` [Patch 03/12] GRU - fix automatic retry of gru instruction failures steiner
2009-06-08 17:16 ` [Patch 04/12] GRU - collect per-context user statistics steiner
2009-06-08 23:07   ` Andrew Morton [this message]
2009-06-10  3:08     ` Jack Steiner
2009-06-08 17:16 ` [Patch 05/12] GRU - delete user request for fetching chiplet status steiner
2009-06-08 17:16 ` [Patch 06/12] GRU - cleanup gru inline functions steiner
2009-06-08 17:16 ` [Patch 07/12] GRU - generic infrastructure for context options steiner
2009-06-08 17:16 ` [Patch 08/12] GRU - add user request to specify gru slice steiner
2009-06-08 17:16 ` [Patch 09/12] GRU - fix potential use-after-free when purging GRU tlbs steiner
2009-06-08 17:16 ` [Patch 10/12] GRU - fixes to grudump utility steiner
2009-06-08 17:16 ` [Patch 11/12] GRU - remove references to the obsolete global status handle steiner
2009-06-08 17:17 ` [Patch 12/12] GRU - copyright fixes steiner

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=20090608160740.4d57ba5d.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=steiner@sgi.com \
    /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.