twitter: linux.kernel - 25 new messages in 16 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* Makefile: set LC_CTYPE, LC_COLLATE, LC_NUMERIC to C - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e16ef3856932d616?hl=en
* spi/mpc8xxx: don't check platform_get_irq's return value against zero - 2
messages, 1 author
http://groups.google.com/group/linux.kernel/t/b57a909bdadeb960?hl=en
* Security: Add prctl(PR_{GET,SET}_NETWORK) interface. - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/a960a1b4696443c0?hl=en
* vfs pile 2 - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/59ce4a8f57a56775?hl=en
* Drop 80-character limit in checkpatch.pl - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/735854ce62c52e1e?hl=en
* backlight updates for 2.6.33 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b619a406641ad2b2?hl=en
* LED updates for 2.6.33 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/feaa951f30992ca2?hl=en
* xfs and block fixes for virtually indexed arches - 4 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/f6cf95c5b7d8e318?hl=en
* 2nd batch of SPI changes - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/9c5b85787b8bb0a1?hl=en
* SYSCTL: Fix sysctl breakage on systems with older glibc - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/1d0077f0532c36f1?hl=en
* x86: uv: Add serial number parameter to uv_bios_get_sn_info() - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/1994d426a6c5a0a3?hl=en
* [perf hw-breakpoints] Null pointer exception when using register_user_hw_
breakpoint with inherit flag - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/b0c83876065f8a36?hl=en
* spi: xilinx_spi: Fix up I/O routine wrapping bogosity. - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/d058caaad75d14f8?hl=en
* acpi, IO memory pre-mapping and atomic accessing - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ba70889765ea1910?hl=en
* ARM: Convert BUG() to use unreachable() - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/814622946b9269fc?hl=en
* Crypto: Talitos: Support for Async_tx XOR offload - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8032eb3dcb84d048?hl=en

==============================================================================
TOPIC: Makefile: set LC_CTYPE, LC_COLLATE, LC_NUMERIC to C
http://groups.google.com/group/linux.kernel/t/e16ef3856932d616?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Dec 17 2009 8:20 am
From: "tip-bot for H. Peter Anvin"

Commit-ID: c051346b7db27aaf674b8f3b4955240580b2a58a
Gitweb: http://git.kernel.org/tip/c051346b7db27aaf674b8f3b4955240580b2a58a
Author: H. Peter Anvin <hpa@zytor.com>
AuthorDate: Thu, 17 Dec 2009 06:56:11 -0800
Committer: H. Peter Anvin <hpa@zytor.com>
CommitDate: Thu, 17 Dec 2009 07:03:21 -0800

Makefile: set LC_CTYPE, LC_COLLATE, LC_NUMERIC to C

There are a number of common Unix constructs like character ranges in
grep/sed/awk which don't work as expected with LC_COLLATE set to other
than C. Similarly, set LC_CTYPE and LC_NUMERIC to C to avoid other
nasty surprises.

In order to make sure these actually take effect we also have to
clear LC_ALL.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Acked-by: Michal Marek <mmarek@sues.cz>
Acked-by: Masami Hiramatsu <mhiramat@redhat.com>
Acked-by: Roland Dreier <rdreier@cisco.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
LKML-Reference: <4B2A1761.4070904@suse.cz>
---
Makefile | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 33d4732..6e39af1 100644
--- a/Makefile
+++ b/Makefile
@@ -16,6 +16,13 @@ NAME = Man-Eating Seals of Antiquity
# o print "Entering directory ...";
MAKEFLAGS += -rR --no-print-directory

+# Avoid funny character set dependencies
+LC_ALL=
+LC_CTYPE=C
+LC_COLLATE=C
+LC_NUMERIC=C
+export LC_ALL LC_CTYPE LC_COLLATE LC_NUMERIC
+
# We are using a recursive build, so we need to do a little thinking
# to get the ordering right.
#
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: spi/mpc8xxx: don't check platform_get_irq's return value against zero
http://groups.google.com/group/linux.kernel/t/b57a909bdadeb960?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Dec 17 2009 8:30 am
From: Anton Vorontsov

On Thu, Dec 17, 2009 at 02:05:49PM +0100, Uwe Kleine-König wrote:
[...]
> > > Yes, there is an issue. If the platform device doesn't have a resource
> > > specifing the irq, platform_get_irq returns -ENXIO. So in the driver
> > > (unsigned)(-ENXIO) is passed to mpc8xxx_spi_probe as (!(-ENXIO)) is
> > > false and so the error isn't catched.
> >
> > If you look into how we create the platform device, you'll notice
> > that -ENXIO isn't possible.
> > It's in arch/powerpc/platforms/83xx/mpc832x_rdb.c:of_fsl_spi_probe(),
> > which is a legacy interface that I'd like to be removed anyway.
> >
> > Though, if you want to fix the inconsistency in the platform device
> > API, then I'd suggest to fix the platform_get_irq(). The driver itself
> > is correct.
> With platform_get_irq as it is today, the check in
>
> irq = platform_get_irq(pdev, 0);
> if (!irq)
> return -EINVAL;

And I see no problem with this piece of code, really. I see the
problem in platform_get_irq() implementation (not that easy to fix,
see below).

> is non-sense as !irq always evaluates to 0. If your argue that the
> resources are right,

No, I'm arguing that there is no issue. There *could* be an issue in
the future (if someone break the platform code), but the way you're
trying to fix the *possibility* isn't quite correct.

Believe me, I'd have no problem with this particular patch if the
patch could possibly fix any real world issue with this driver.

For example, you may notice the following commit:

commit 2fac6674ddf3164da42a76d62f8912073d629a30
Author: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Tue Jan 6 14:42:11 2009 -0800

rtc: bunch of drivers: fix 'no irq' case handing

This patch fixes a bunch of irq checking misuses. Most drivers were
getting irq via platform_get_irq(), which returns -ENXIO or r->start.

Sounds similar, eh? But you may notice that the unfixed code
was really wrong and didn't work for every sane platform:

m48t59->irq = platform_get_irq(pdev, 0);
- if (m48t59->irq < 0)
+ if (m48t59->irq <= 0)

The checks were irq < 0, so the drivers were requesting irq0, and
then were failing to probe.

Unfortunately, I stopped half way, afraid to possibly break current
platforms that use these drivers, so I kept the "<" part. Which is
a shame, because... um, it seems I spread the bad example further.

Anyway, I just did 'grep platform_get_irq -A 2 -r drivers/', and
it looks horrible, most callers check for irq < 0, which means
the code won't work on anything but arches with NO_IRQ == -1
(ARM, parisc, xtensa).

It seems the situation is near to hopeless. Maybe someone needs to
sit down and cleanup this mess once and for ever...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Thurs, Dec 17 2009 8:50 am
From: Anton Vorontsov

On Wed, Dec 16, 2009 at 05:10:08PM +0100, Uwe Kleine-König wrote:
> platform_get_irq returns -ENXIO on failure, so !irq was probably
> always true. Better use (int)irq <= 0. Note that a return value of
> zero is still handled as error even though this could mean irq0.
>
> This is a followup to 305b3228f9ff4d59f49e6d34a7034d44ee8ce2f0 that
> changed the return value of platform_get_irq from 0 to -ENXIO on error.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Cc: David Vrabel <dvrabel@arcom.com>
> Cc: Greg Kroah-Hartman <gregkh@suse.de>
> Cc: David Brownell <dbrownell@users.sourceforge.net>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Cc: Anton Vorontsov <avorontsov@ru.mvista.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: spi-devel-general@lists.sourceforge.net
> ---
> drivers/spi/spi_mpc8xxx.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/spi/spi_mpc8xxx.c b/drivers/spi/spi_mpc8xxx.c
> index e9390d7..b13501a 100644
> --- a/drivers/spi/spi_mpc8xxx.c
> +++ b/drivers/spi/spi_mpc8xxx.c
> @@ -1339,7 +1339,7 @@ static int __devinit plat_mpc8xxx_spi_probe(struct platform_device *pdev)
> return -EINVAL;
>
> irq = platform_get_irq(pdev, 0);
> - if (!irq)
> + if ((int)irq <= 0)

I tend to think that it's really hopeless to fix the
platform_get_irq() in its current form, so can you get rid
of this ugly cast and just make the irq signed?

And I'll be fine with it. :-(

--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Security: Add prctl(PR_{GET,SET}_NETWORK) interface.
http://groups.google.com/group/linux.kernel/t/a960a1b4696443c0?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Dec 17 2009 8:30 am
From: Michael Stone

Américo Wang wrote:

> Any reason why you introdce a new source file?
> Why not just adding them to kernel/sys.c?

Modifying kernel/sys.c would be fine too, I think. I'll incorporate this
suggestion into the next revision of the prctl()-based patches.

Thanks!

Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Thurs, Dec 17 2009 9:20 am
From: Andi Kleen

> This is not very good because in some situations it is useful to disable
> connect() and bind() while still allowing ptracing of other processes. For
> example, Plash creates a new UID for each sandbox and it is possible to use
> strace and gdb inside a sandbox. Currently Plash is not able to block
> network access or allow only limited network access. If you treat ptrace()
> this way we won't have the ability to use strace and gdb while limiting
> network access.

No that's not what the hunk does. I first thought the same. But it actually
just limits these processes from initiating ptracing themselves. You can still
attach gdb/strace to them.

Now I'm not sure if that's closing all holes, but at least I can't come
up with any obvious ones currently. I think I would still prefer a more
general security container in general.

-Andi
--
ak@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: vfs pile 2
http://groups.google.com/group/linux.kernel/t/59ce4a8f57a56775?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Dec 17 2009 8:30 am
From: Al Viro

Misc bits and pieces, cleaning the table for scaling stuff...
Please, pull from
git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/ master
in a few minutes (or directly from hera)

Al Viro (1):
dio: fix use-after-free

Christoph Hellwig (3):
fix up O_SYNC comments
fold do_sync_file_range into sys_sync_file_range
kill I_LOCK

Erez Zadok (2):
fsstack/ecryptfs: remove unused get_nlinks param to fsstack_copy_attr_all
VFS/fsstack: handle 32-bit smp + preempt + large files in fsstack_copy_inode_size

Jeff Layton (1):
vfs: remove extraneous NULL d_inode check from do_filp_open

Nick Piggin (2):
fs: anon_inodes implement dname
fs: no games with DCACHE_UNHASHED

== 2 of 2 ==
Date: Thurs, Dec 17 2009 8:40 am
From: Linus Torvalds

On Thu, 17 Dec 2009, Al Viro wrote:
>
> Misc bits and pieces, cleaning the table for scaling stuff...
> Please, pull from
> git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/ master
> in a few minutes (or directly from hera)

Btw, would you mind cleaning that repo up?

It has a few very annoying things, the first and foremost of which is that
HEAD points to some crazy branch (new-truncate).

So when you do "git pull" without mentioning the branch (which is the
normal behavior) and would expect to get your default thing (which was
also what you asked me to pull in your original pull request), you instead
get some totally inexplicable old random crud.

That's really unexpected for a bare repository. I spent some time looking
at the odd conflicts the other day when I pulled originally.

I suspect you just did a "scp -rp" or something to initially set it up,
which is why it contains some random branch - that just happened to be
your active branch at the time you did that setup.

(It also has FETCH_HEAD, index, COMMIT_EDITMSG etc - all things that don't
make sense in a bare repository)

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Drop 80-character limit in checkpatch.pl
http://groups.google.com/group/linux.kernel/t/735854ce62c52e1e?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Dec 17 2009 8:30 am
From: Linus Torvalds

On Thu, 17 Dec 2009, Bartlomiej Zolnierkiewicz wrote:
>
> Well, it could have been done in the other way:
>
> - ret = sscanf (buf, "0x%lx - 0x%lx", &start_addr, &end_addr);
> + ret = sscanf(buf, "0x%lx - 0x%lx",
> + &start_addr, &end_addr);
>
> Just an example that the limit itself is usually not a problem
> but its literal interpretation is..

What? Your version is no better.

In the above case it doesn't matter, but I've had grep's that fail due to
people splitting the actual string etc, which just drives me wild. We
fixed that to allow checkpatch to skip those warnings, but the fact is,
the fundamnetal problem has always been the "80 character" part.

I don't think any kernel developers use a vt100 any more. And even if they
do, I bet they curse the "24 lines" more than they curse the occasional
80+ character lines.

I'd be ok with changing the warning to 132 characters, which is another
perfectly fine historical limit. Or we can split the difference, and say
"ok, 106 characters is too much". I don't care. But 80 characters is
causing too many idiotic changes.

There are way worse problems in many patches than long lines. Too complex
expressions. Too deep indentation. Pure crap code. People seem to get way
too hung up on ".. but at least it passes checkpatch".

== 2 of 2 ==
Date: Thurs, Dec 17 2009 8:40 am
From: Janakiram Sistla

On Thu, Dec 17, 2009 at 9:51 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Thu, 17 Dec 2009, Bartlomiej Zolnierkiewicz wrote:
>>
>> Well, it could have been done in the other way:
>>
>> - ret = sscanf (buf, "0x%lx - 0x%lx", &start_addr, &end_addr);
>> + ret = sscanf(buf, "0x%lx - 0x%lx",
>> + &start_addr, &end_addr);
>>
>> Just an example that the limit itself is usually not a problem
>> but its literal interpretation is..
>
> What? Your version is no better.
>
> In the above case it doesn't matter, but I've had grep's that fail due to
> people splitting the actual string etc, which just drives me wild. We
> fixed that to allow checkpatch to skip those warnings, but the fact is,
> the fundamnetal problem has always been the "80 character" part.
>
> I don't think any kernel developers use a vt100 any more. And even if they
> do, I bet they curse the "24 lines" more than they curse the occasional
> 80+ character lines.
>
> I'd be ok with changing the warning to 132 characters, which is another
> perfectly fine historical limit. Or we can split the difference, and say
> "ok, 106 characters is too much". I don't care. But 80 characters is
> causing too many idiotic changes.
>
> There are way worse problems in many patches than long lines. Too complex
> expressions. Too deep indentation. Pure crap code. People seem to get way
> too hung up on ".. but at least it passes checkpatch".
>
I truely agree on this.It will better if we can change the warning for
100+ as suggested.This cleans the code alot infact.

-Ram
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: backlight updates for 2.6.33
http://groups.google.com/group/linux.kernel/t/b619a406641ad2b2?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Dec 17 2009 8:40 am
From: Richard Purdie

Linus,

Could you please pull from:

git://git.o-hand.com/linux-rpurdie-backlight for-linus

for the backlight tree updates for 2.6.33. These are mainly minor
improvements, bugfixes or new device table entries. Most patches have
been in -mm for a while.

Thanks, Richard

Documentation/laptops/thinkpad-acpi.txt | 51 +++++++-------------------------
drivers/platform/x86/thinkpad_acpi.c | 24 ++++++++++++++-
drivers/video/backlight/adp5520_bl.c | 2 -
drivers/video/backlight/adx_bl.c | 2 -
drivers/video/backlight/atmel-pwm-bl.c | 2 -
drivers/video/backlight/backlight.c | 2 -
drivers/video/backlight/corgi_lcd.c | 2 -
drivers/video/backlight/cr_bllcd.c | 4 +-
drivers/video/backlight/da903x_bl.c | 2 -
drivers/video/backlight/generic_bl.c | 2 -
drivers/video/backlight/hp680_bl.c | 2 -
drivers/video/backlight/jornada720_bl.c | 2 -
drivers/video/backlight/kb3886_bl.c | 2 -
drivers/video/backlight/locomolcd.c | 2 -
drivers/video/backlight/mbp_nvidia_bl.c | 20 +++++++++++-
drivers/video/backlight/omap1_bl.c | 2 -
drivers/video/backlight/progear_bl.c | 2 -
drivers/video/backlight/pwm_bl.c | 11 ++++--
drivers/video/backlight/tosa_bl.c | 2 -
drivers/video/backlight/wm831x_bl.c | 2 -
include/linux/backlight.h | 12 +++----
include/linux/pwm_backlight.h | 2 -
22 files changed, 85 insertions(+), 69 deletions(-)

Ben Dooks (1):
backlight: Pass device through notify callback in the pwm driver

Daniel Ritz (1):
backlight: mbp_nvidia_bl - add two more MacBookPro variants

Emese Revfy (1):
backlight: Constify struct backlight_ops

Henrique de Moraes Holschuh (1):
backlight/thinkpad-acpi: issue backlight class events

Roel Kluin (1):
backlight: PTR_ERR return of wrong pointer in cr_backlight_probe()

--
Richard Purdie
Intel Open Source Technology Centre

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: LED updates for 2.6.33
http://groups.google.com/group/linux.kernel/t/feaa951f30992ca2?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Dec 17 2009 8:40 am
From: Richard Purdie

Linus,

Could you please pull from:

git://git.o-hand.com/linux-rpurdie-leds for-linus

for the LED tree updates for 2.6.33. This mainly includes new drivers
but also some bugfixes and tweaks. Most patches have been in -mm for a
while.

Thanks, Richard

Antonio Ospite (3):
leds: Add LED class driver for regulator driven LEDs.
leds: leds-pca9532.h- indent with tabs, not spaces
leds: leds-lp3944.h - remove unneeded includes

Daniel Mack (2):
leds: leds-alix2c - take port address from MSR
leds: Add driver for LT3593 controlled LEDs

Dave Hansen (2):
leds: LED driver for Intel NAS SS4200 series (v5)
leds-ss4200: Check pci_enable_device return

Florian Fainelli (1):
leds: use default-on trigger for Cobalt Qube

H Hartley Sweeten (2):
leds: leds-cobalt-raq.c - use resource_size()
leds: leds-cobalt-qube.c: use resource_size()

Lars-Peter Clausen (1):
leds: leds-pwm: Set led_classdev max_brightness

Michael Hennerich (1):
leds: Add driver for ADP5520/ADP5501 MFD PMICs

akpm@linux-foundation.org (1):
leds: drivers/leds/leds-ss4200.c: fix return statement

--
Richard Purdie
Intel Open Source Technology Centre

==============================================================================
TOPIC: xfs and block fixes for virtually indexed arches
http://groups.google.com/group/linux.kernel/t/f6cf95c5b7d8e318?hl=en
==============================================================================

== 1 of 4 ==
Date: Thurs, Dec 17 2009 8:40 am
From: tytso@mit.edu

On Thu, Dec 17, 2009 at 08:16:12AM -0800, Linus Torvalds wrote:
>
> I hate them.
>
> I don't see what the point of allowing kernel virtual addresses in bio's
> is. It's wrong. The fact that XFS does that sh*t is an XFS issue. Handle
> it there.
>
> Fix XFS. Or convince me with some really good arguments, and make sure
> that Jens signs off on the cr*p too.

I have a somewhat similar issue that comes up for ext4; at the moment
occasionaly we need to clone a buffer head buffer; either because the
first four bytes match the magic JBD "escape sequence", and we need to
modify the block and escape it before writing it to the journal, or
because we need to make a copy of a allocation bitmap block so we can
write a fixed copy to disk while we modify the "real" block during a
commit. At the moment we allocate a full page, even if that means
allocating a 16k PPC page when the file system block size is 4k, or
allocating a 4k x86 page when the file system block size is 1k.

That's because apparently the iSCSI and DMA blocks assume that they
have Real Pages (tm) passed to block I/O requests, and apparently XFS
ran into problems when sending vmalloc'ed pages. I don't know if this
is a problem if we pass the bio layer addresses coming from the SLAB
allocator, but oral tradition seems to indicate this is problematic,
although no one has given me the full chapter and verse explanation
about why this is so.

Now that I see Linus's complaint, I'm wondering if the issue is really
about kernel virtual addresses (i.e., coming from vmalloc), and not a
requirement for Real Pages (i.e., coming from the SLAB allocator as
opposed to get_free_page). And can this be documented someplace? I
tried looking at the bio documentation, and couldn't find anything
definitive on the subject.

Thanks,

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 4 ==
Date: Thurs, Dec 17 2009 8:50 am
From: Linus Torvalds

On Thu, 17 Dec 2009, tytso@mit.edu wrote:
>
> That's because apparently the iSCSI and DMA blocks assume that they
> have Real Pages (tm) passed to block I/O requests, and apparently XFS
> ran into problems when sending vmalloc'ed pages. I don't know if this
> is a problem if we pass the bio layer addresses coming from the SLAB
> allocator, but oral tradition seems to indicate this is problematic,
> although no one has given me the full chapter and verse explanation
> about why this is so.

kmalloc() memory should be ok. It's backed by "real pages". Doing the DMA
translations for such pages is trivial and fundamental.

In contrast, vmalloc is pure and utter unadulterated CRAP. The pages
may be contiguous virtually, but it makes no difference for the block
layer, that has to be able to do IO by DMA anyway, so it has to look up
the page translations in the page tables etc crazy sh*t.

So passing vmalloc'ed page addresses around to something that will
eventually do a non-CPU-virtual thing on them is fundamentally insane. The
vmalloc space is about CPU virtual addresses. Such concepts simpyl do not
-exist- for some random block device.

> Now that I see Linus's complaint, I'm wondering if the issue is really
> about kernel virtual addresses (i.e., coming from vmalloc), and not a
> requirement for Real Pages (i.e., coming from the SLAB allocator as
> opposed to get_free_page). And can this be documented someplace? I
> tried looking at the bio documentation, and couldn't find anything
> definitive on the subject.

The whole "vmalloc is special" has always been true. If you want to
treat vmalloc as normal memory, you need to look up the pages yourself. We
have helpers for that (including helpers that populate vmalloc space from
a page array to begin with - so you can _start_ from some array of pages
and then lay them out virtually if you want to have a convenient CPU
access to the array).

And this whole "vmalloc is about CPU virtual addresses" is so obviously
and fundamentally true that I don't understand how anybody can ever be
confused about it. The "v" in vmalloc is for "virtual" as in virtual
memory.

Think of it like virtual user addresses. Does anybody really expect to be
able to pass a random user address to the BIO layer?

And if you do, I would suggest that you get out of kernel programming
pronto. You're a danger to society, and have a lukewarm IQ. I don't want
you touching kernel code.

And no, I do _not_ want the BIO layer having to walk page tables. Not for
vmalloc space, not for user virtual addresses.

(And don't tell me it already does. Maybe somebody sneaked it in past me,
without me ever noticing. That wouldn't be an excuse, that would be just
sad. Jesus wept)

== 3 of 4 ==
Date: Thurs, Dec 17 2009 9:10 am
From: Christoph Hellwig

On Thu, Dec 17, 2009 at 08:46:33AM -0800, Linus Torvalds wrote:
> The whole "vmalloc is special" has always been true. If you want to
> treat vmalloc as normal memory, you need to look up the pages yourself. We
> have helpers for that (including helpers that populate vmalloc space from
> a page array to begin with - so you can _start_ from some array of pages
> and then lay them out virtually if you want to have a convenient CPU
> access to the array).

Which is exactly what the XFS code does. Pages are allocated manually
and we store pointers to the page struct that later get added to the
bio. But we access them through vmap (which I added exactly for this
reason back in 2002) for kernel accesses. On all architectures with
sane caches things just work, but for parisc, arm and friends that have
virtually indexed caches we need to make sure to flush caches for this
different access. The vmalloc linear address is not used for I/O
everywhere.

== 4 of 4 ==
Date: Thurs, Dec 17 2009 9:20 am
From: Christoph Hellwig

On Thu, Dec 17, 2009 at 11:30:36AM -0500, tytso@mit.edu wrote:
> That's because apparently the iSCSI and DMA blocks assume that they
> have Real Pages (tm) passed to block I/O requests, and apparently XFS
> ran into problems when sending vmalloc'ed pages. I don't know if this
> is a problem if we pass the bio layer addresses coming from the SLAB
> allocator, but oral tradition seems to indicate this is problematic,
> although no one has given me the full chapter and verse explanation
> about why this is so.

Actually at least iscsi now has a workaround for that by checking for
PageSlab. Back when we deal with the XFS issue that check was only
available with debug options enabled. I tried to sort it out by
agreeing with the block and iscsi folks that either

a) we need to send down refcountable pages
b) block drivers need to accept kmalloced pages

I could not get any afreement, and thus we stopped using the kmalloced
pages in XFS which was easy enough. A bit later people fixed iscsi,
but we still don't have formal rules about what is acceptable to the
block layer.

==============================================================================
TOPIC: 2nd batch of SPI changes
http://groups.google.com/group/linux.kernel/t/9c5b85787b8bb0a1?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Dec 17 2009 8:50 am
From: Grant Likely

Hi Linus,

This is later than I'd like it to be, and I hope it gets to you before
you cut -rc1. There was some slack between Andrew and I on handing
off SPI maintainership. Patches I had picked up in the last batch
conflicted with his stack and we decided it was best if I just take
the remainder of his SPI queue and commit them to my tree.
(Basically, I made the mess, so I got to clean it up). It took me a
bit to get sorted out.

Commits in this batch are either a) from Andrew's tree, b) trivial
fixes from the list, or c) new drivers.

The following changes since commit 718deb6b61e34c200c1f2b706176d9aac334cb2d:
Al Viro (1):
Fix breakage in shmem.c

are available in the git repository at:

git://git.secretlab.ca/git/linux-2.6 next-spi

Ben Dooks (1):
spi_s3c24xx: add FIQ pseudo-DMA support

Ben Nizette (1):
atmel_spi: fix dma addr calculation for len > BUFFER_SIZE

Feng Tang (1):
spi: controller driver for Designware SPI core

Jassi Brar (1):
spi: Add s3c64xx SPI Controller driver

Mike Frysinger (1):
spidev: add proper section markers

Thadeu Lima de Souza Cascardo (1):
spidev: use DECLARE_BITMAP instead of declaring the array

hartleys (5):
spi: atmel_spi.c: use resource_size()
spi: spi_bfin5xx.c: use resource_size()
spi: spi_mpc8xxx.c: use resource_size()
spi: spi_sh_sci.c: use resource_size()
spi: spi_txx9.c: use resource_size()

arch/arm/mach-s3c2410/include/mach/spi.h | 2 +
drivers/spi/Kconfig | 28 +
drivers/spi/Makefile | 10 +-
drivers/spi/atmel_spi.c | 6 +-
drivers/spi/dw_spi.c | 944 +++++++++++++++++++++++
drivers/spi/dw_spi_pci.c | 169 +++++
drivers/spi/spi_bfin5xx.c | 2 +-
drivers/spi/spi_mpc8xxx.c | 2 +-
drivers/spi/spi_s3c24xx.c | 244 ++++++-
drivers/spi/spi_s3c24xx_fiq.S | 116 +++
drivers/spi/spi_s3c24xx_fiq.h | 26 +
drivers/spi/spi_s3c64xx.c | 1196 ++++++++++++++++++++++++++++++
drivers/spi/spi_sh_sci.c | 2 +-
drivers/spi/spi_txx9.c | 6 +-
drivers/spi/spidev.c | 18 +-
include/linux/spi/dw_spi.h | 212 ++++++
16 files changed, 2950 insertions(+), 33 deletions(-)
create mode 100644 drivers/spi/dw_spi.c
create mode 100644 drivers/spi/dw_spi_pci.c
create mode 100644 drivers/spi/spi_s3c24xx_fiq.S
create mode 100644 drivers/spi/spi_s3c24xx_fiq.h
create mode 100644 drivers/spi/spi_s3c64xx.c
create mode 100644 include/linux/spi/dw_spi.h

--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: SYSCTL: Fix sysctl breakage on systems with older glibc
http://groups.google.com/group/linux.kernel/t/1d0077f0532c36f1?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Dec 17 2009 8:50 am
From: Andi Kleen

On Thu, Dec 17, 2009 at 07:07:54AM -0800, Eric W. Biederman wrote:
> reaction would be. If it makes logging in and manually using the
> machine unbearable on systems with versions of glibc from days of
> yore, the level of logging is too high.

The reason I was slightly annoyed is because I flagged this
during code review and it wasn't addressed before merging.

>
> > I see this on a SUSE 10.0 system with glibc 2.3.5.
> > Don't warn for this common case.
>
> Perhaps it is just my sample of the world but glibc < 2.5 isn't
> common, especially on machines that I am putting new kernels on.
> Equally machines with 3+ year old installs are rare.

Linux simply cannot abandon older user land. We still (near)
fully support a.out executables, even on 64bit.

>
> > Signed-off-by: Andi Kleen <ak@linux.intel.com>
> >
> > diff -u linux-2.6.32-git12/kernel/sysctl_binary.c-o linux-2.6.32-git12/kernel/sysctl_binary.c
> > --- linux-2.6.32-git12/kernel/sysctl_binary.c-o 2009-12-16 12:15:52.000000000 +0100
> > +++ linux-2.6.32-git12/kernel/sysctl_binary.c 2009-12-16 12:14:58.000000000 +0100
> > @@ -1399,6 +1399,13 @@
> > {
> > int i;
> >
> > + /*
> > + * CTL_KERN/KERN_VERSION is used by older glibc and cannot
> > + * ever go away.
> > + */
> The comment is wrong. Older versions of glibc are perfectly happy
> getting -ENOSYS form sys_sysctl.

and it fills and fills and fills the kernel log. In practice
that's not usable.

>
> > + if (name[0] == CTL_KERN && name[1] == KERN_VERSION)
> > + return;
>
> If you make it printk_once for this case I think that strikes the right
> balance. You won't be spammed to death by messages telling you about
> a silly old glibc, but you will be told.

It's not a "silly old glibc", it's a "perfectly functional old glibc"

==============================================================================
TOPIC: x86: uv: Add serial number parameter to uv_bios_get_sn_info()
http://groups.google.com/group/linux.kernel/t/1994d426a6c5a0a3?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Dec 17 2009 9:00 am
From: Russ Anderson

Add system_serial_number to the information returned by
uv_bios_get_sn_info() UV BIOS call.

Signed-off-by: Russ Anderson <rja@sgi.com>
Cc: Jack Steiner <steiner@sgi.com>
---

This patch only effects UV systems.

arch/x86/include/asm/uv/bios.h | 7 ++++---
arch/x86/kernel/apic/x2apic_uv_x.c | 6 +++---
arch/x86/kernel/bios_uv.c | 20 ++++++++++++++------
3 files changed, 21 insertions(+), 12 deletions(-)

Index: linux/arch/x86/include/asm/uv/bios.h
===================================================================
--- linux.orig/arch/x86/include/asm/uv/bios.h 2009-12-16 15:59:58.000000000 -0600
+++ linux/arch/x86/include/asm/uv/bios.h 2009-12-16 16:16:35.000000000 -0600
@@ -18,8 +18,8 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
- * Copyright (c) 2008 Silicon Graphics, Inc. All Rights Reserved.
- * Copyright (c) Russ Anderson
+ * Copyright (c) 2008-2009 Silicon Graphics, Inc. All Rights Reserved.
+ * Copyright (c) Russ Anderson <rja@sgi.com>
*/

#include <linux/rtc.h>
@@ -89,7 +89,7 @@ extern s64 uv_bios_call(enum uv_bios_cmd
extern s64 uv_bios_call_irqsave(enum uv_bios_cmd, u64, u64, u64, u64, u64);
extern s64 uv_bios_call_reentrant(enum uv_bios_cmd, u64, u64, u64, u64, u64);

-extern s64 uv_bios_get_sn_info(int, int *, long *, long *, long *);
+extern s64 uv_bios_get_sn_info(int, int *, long *, long *, long *, long *);
extern s64 uv_bios_freq_base(u64, u64 *);
extern int uv_bios_mq_watchlist_alloc(unsigned long, unsigned int,
unsigned long *);
@@ -104,6 +104,7 @@ extern int uv_type;
extern long sn_partition_id;
extern long sn_coherency_id;
extern long sn_region_size;
+extern long system_serial_number;
#define partition_coherence_id() (sn_coherency_id)

extern struct kobject *sgi_uv_kobj; /* /sys/firmware/sgi_uv */
Index: linux/arch/x86/kernel/apic/x2apic_uv_x.c
===================================================================
--- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c 2009-12-16 15:59:58.000000000 -0600
+++ linux/arch/x86/kernel/apic/x2apic_uv_x.c 2009-12-16 16:01:13.000000000 -0600
@@ -5,7 +5,7 @@
*
* SGI UV APIC functions (note: not an Intel compatible APIC)
*
- * Copyright (C) 2007-2008 Silicon Graphics, Inc. All rights reserved.
+ * Copyright (C) 2007-2009 Silicon Graphics, Inc. All rights reserved.
*/
#include <linux/cpumask.h>
#include <linux/hardirq.h>
@@ -627,8 +627,8 @@ void __init uv_system_init(void)
}

uv_bios_init();
- uv_bios_get_sn_info(0, &uv_type, &sn_partition_id,
- &sn_coherency_id, &sn_region_size);
+ uv_bios_get_sn_info(0, &uv_type, &sn_partition_id, &sn_coherency_id,
+ &sn_region_size, &system_serial_number);
uv_rtc_init();

for_each_present_cpu(cpu) {
Index: linux/arch/x86/kernel/bios_uv.c
===================================================================
--- linux.orig/arch/x86/kernel/bios_uv.c 2009-12-16 15:59:58.000000000 -0600
+++ linux/arch/x86/kernel/bios_uv.c 2009-12-16 16:19:11.000000000 -0600
@@ -15,8 +15,8 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
- * Copyright (c) 2008 Silicon Graphics, Inc. All Rights Reserved.
- * Copyright (c) Russ Anderson
+ * Copyright (c) 2008-2009 Silicon Graphics, Inc. All Rights Reserved.
+ * Copyright (c) Russ Anderson <rja@sgi.com>
*/

#include <linux/efi.h>
@@ -30,6 +30,7 @@ static struct uv_systab uv_systab;
s64 uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3, u64 a4, u64 a5)
{
struct uv_systab *tab = &uv_systab;
+ s64 ret;

if (!tab->function)
/*
@@ -37,9 +38,11 @@ s64 uv_bios_call(enum uv_bios_cmd which,
*/
return BIOS_STATUS_UNIMPLEMENTED;

- return efi_call6((void *)__va(tab->function),
- (u64)which, a1, a2, a3, a4, a5);
+ ret = efi_call6((void *)__va(tab->function), (u64)which,
+ a1, a2, a3, a4, a5);
+ return ret;
}
+EXPORT_SYMBOL_GPL(uv_bios_call);

s64 uv_bios_call_irqsave(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3,
u64 a4, u64 a5)
@@ -73,11 +76,14 @@ long sn_coherency_id;
EXPORT_SYMBOL_GPL(sn_coherency_id);
long sn_region_size;
EXPORT_SYMBOL_GPL(sn_region_size);
+long system_serial_number;
+EXPORT_SYMBOL_GPL(system_serial_number);
int uv_type;
+EXPORT_SYMBOL_GPL(uv_type);

s64 uv_bios_get_sn_info(int fc, int *uvtype, long *partid, long *coher,
- long *region)
+ long *region, long *ssn)
{
s64 ret;
u64 v0, v1;
@@ -97,8 +103,11 @@ s64 uv_bios_get_sn_info(int fc, int *uvt
*coher = part.coherence_id;
if (region)
*region = part.region_size;
+ if (ssn)
+ *ssn = v1;
return ret;
}
+EXPORT_SYMBOL_GPL(uv_bios_get_sn_info);

int
uv_bios_mq_watchlist_alloc(unsigned long addr, unsigned int mq_size,
@@ -185,4 +194,3 @@ void uv_bios_init(void)

void uv_bios_init(void) { }

twitter

Thursday, December 17, 2009

linux.kernel - 25 new messages in 16 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts