public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Paul Jackson <pj@sgi.com>
Cc: rusty@rustcorp.com.au, linux-kernel@vger.kernel.org,
	akpm@osdl.org, ak@suse.de
Subject: Re: [PATCH] fix sys cpumap for > 352 NR_CPUS
Date: Thu, 3 Jun 2004 09:51:42 -0700	[thread overview]
Message-ID: <20040603165142.GA3959@kroah.com> (raw)
In-Reply-To: <20040603093807.33bc670d.pj@sgi.com>

On Thu, Jun 03, 2004 at 09:38:07AM -0700, Paul Jackson wrote:
> > We do check for an error in that function, so returning any negative
> > error value for a show() sysfs callback will be handled properly.
> 
> If a show() function returns an error, you handle it - good.  As it
> should be.
> 
> But if a show() function overwrites the page buffer provided to it,
> before returning, then there is nothing you can do beyond sending
> condolences to the next of kin.

Yup, you broke the kernel, you get to keep both pieces :)

> This PATCH and email thread came about because the buffer size is not
> passed into the show() function, nor, so far as I can tell, is it
> documented anywhere other than implicitly in the fill_read_buffer()
> code:
> 
>     buffer->page = (char *) get_zeroed_page(GFP_KERNEL);

I agree that we should document this better.  This thread has shown
that.

> So we were getting confused as to what size buffer we had, when
> coding defensively to avoid buffer overrun.

Panicing the kernel is not really acceptable, even if you did just
scribble accross any portion of kernel memory in your show() function.
Just be aware of the size and code your show() function to be defensive
and not overrun that size.

thanks,

greg k-h

  reply	other threads:[~2004-06-03 16:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-02 23:11 [PATCH] fix sys cpumap for > 352 NR_CPUS Paul Jackson
2004-06-02 23:23 ` Andrew Morton
2004-06-02 23:59   ` Paul Jackson
2004-06-03  0:17     ` Andrew Morton
2004-06-03 16:24       ` Greg KH
2004-06-03 16:28         ` Paul Jackson
2004-06-03  0:22 ` Rusty Russell
2004-06-03  4:25   ` Paul Jackson
2004-06-03  6:26     ` Rusty Russell
2004-06-03  8:27       ` Paul Jackson
2004-06-04  1:12         ` Rusty Russell
2004-06-04  2:25           ` Paul Jackson
2004-06-03 15:49       ` Paul Jackson
2004-06-03  4:34   ` Paul Jackson
2004-06-03  4:35     ` Rusty Russell
2004-06-03 16:27   ` Greg KH
2004-06-03 16:38     ` Paul Jackson
2004-06-03 16:51       ` Greg KH [this message]
2004-06-04  1:27         ` Rusty Russell
2004-06-04 18:15           ` Greg KH

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=20040603165142.GA3959@kroah.com \
    --to=greg@kroah.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pj@sgi.com \
    --cc=rusty@rustcorp.com.au \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox