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: <20071027164832.GW27248@parisc-linux.org>
Date:	Sat, 27 Oct 2007 10:48:32 -0600
From:	Matthew Wilcox <matthew@....cx>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Rusty Russell <rusty@...tcorp.com.au>,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	Matthew Wilcox <willy@...ux.intel.com>
Subject: Re: [PATCH 1/4] stringbuf: A string buffer implementation

On Sat, Oct 27, 2007 at 07:34:47PM +0300, Pekka Enberg wrote:
> On 10/27/07, Rusty Russell <rusty@...tcorp.com.au> wrote:
> > On Saturday 27 October 2007 21:47:09 Pekka Enberg wrote:
> > > Why don't we just return -ENOMEM here just like all other APIs in the
> > > kernel?
> > I think Willy did it because this is for printk.  It makes more sense than
> > everyone opencoding an -ENOMEM handler, which will have to be replaced by
> > some mildly amusing string like "I want to printk but I have no memory!".
> > Next think you know 70% of the kernel will be bad limericks as everyone tries
> > to one-up each other.
> 
> My point was, of course, that the caller gets to decide what to do on
> OOM. For the most part, you probably want to ignore it but for things
> like pseudo filesystems where you generate a human-readable string,
> returning -ENOMEM from read(2) is preferable.

That was why I had an sb_error() as part of the API so a caller who
cared could check, and a caller who didn't care would never know --
they'd just print the out-of-memory string and continue happily.

It's not hard to add an sb_error to Rusty's rewrite.  It looks something
like:

static inline int sb_error(struct stringbuf *sb)
{
	if (sb == sb_enomem_string)
		return -ENOMEM;
	return 0;
}

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ