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

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

Today's topics:

* ssb: open-code dma_alloc_coherent - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/6bd5977a4ed1c4e1?hl=en
* linux-next: build warning after merge of the net tree - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f4202aba91e59ce5?hl=en
* Performance regression in scsi sequential throughput (iozone) due to "e084b -
page-allocator: preserve PFN ordering when __GFP_COLD is set" - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/0f198fe3053e9f98?hl=en
* linux-next: manual merge of the fsnotify tree with the vfs tree - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/3fca57688125f1ad?hl=en
* Resume lock up -- bisected, commit 3a1151e3f124fd1a2c54b8153f510f1a7c715369 -
1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/09ac7a70d02b0696?hl=en
* 2.6.33-rc8 breaks UML with Restrict initial stack space expansion to rlimit -
5 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/d88757ffc0c5d1f4?hl=en
* UML error - apps killed 50% of the time - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a7b0f59a78985724?hl=en
* UML broken - runaway loop modprobe binfmt-464c - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/87c54bda128748c9?hl=en
* sysfs: Remove sysfs_get/put_active_two - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/dc53e1c9066cca04?hl=en
* linux-next: manual merge of the devicetree tree with the microblaze tree - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/33a5224d5b53560f?hl=en
* HDA Intel Audio hang on boot - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c19fa05ad577d5d3?hl=en
* net: add checking to rcu_dereference() primitives - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/294af99c727e9a69?hl=en
* Provide a driver for the Apple Magic Mouse - opps - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/24254d069a593af0?hl=en
* Asynchronous writes up to 30% slower than in previous kernel versions - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/e304e94ab5c0997d?hl=en
* linux-next: manual merge of the net tree with the wireless-current tree - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/fdc2e6da35047c20?hl=en
* Blackfin: initial tracehook support - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5497cb48daecd717?hl=en
* oom killing kde erroneously (still) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/57e519b249eef777?hl=en
* register long sp asm("r1") incorrect - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/407001dca048cc73?hl=en

==============================================================================
TOPIC: ssb: open-code dma_alloc_coherent
http://groups.google.com/group/linux.kernel/t/6bd5977a4ed1c4e1?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Feb 14 2010 10:50 pm
From: Larry Finger

On 02/14/2010 11:21 PM, FUJITA Tomonori wrote:
> This patch is against -mm since it depends on the DMA API changes in
> -mm.

Are the patches that implement these DMA API changes available for testing? I
don't keep an -mm tree.

Larry

--
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: Sun, Feb 14 2010 11:30 pm
From: FUJITA Tomonori

On Mon, 15 Feb 2010 00:49:14 -0600
Larry Finger <Larry.Finger@lwfinger.net> wrote:

> On 02/14/2010 11:21 PM, FUJITA Tomonori wrote:
> > This patch is against -mm since it depends on the DMA API changes in
> > -mm.
>
> Are the patches that implement these DMA API changes available for testing? I
> don't keep an -mm tree.

All the patches are in -mm and I've just uploaded the patches against
2.6.33-rc8:

git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git pending

The ssb patch depends on the latest eight patches in the tree:

http://marc.info/?l=linux-kernel&m=126596737604808&w=2

Thanks!
--
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: linux-next: build warning after merge of the net tree
http://groups.google.com/group/linux.kernel/t/f4202aba91e59ce5?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 14 2010 11:00 pm
From: David Miller

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 15 Feb 2010 14:32:57 +1100

> After merging the net tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> net/mac80211/iface.c: In function 'ieee80211_stop':
> net/mac80211/iface.c:416: warning: passing argument 4 of '__dev_addr_unsync' makes pointer from integer without a cast
> include/linux/netdevice.h:1967: note: expected 'int *' but argument is of type 'int'
>
> Introduced by commit 4cd24eaf0c6ee7f0242e34ee77ec899f255e66b5 ("net: use
> netdev_mc_count and netdev_mc_empty when appropriate").

I'll fix this like so:

mac80211: Fix error introduced in netdev_mc_count() changes.

Commit 4cd24eaf0c6ee7f0242e34ee77ec899f255e66b5
("net: use netdev_mc_count and netdev_mc_empty when appropriate")
added this hunk to net/mac80211/iface.c:

__dev_addr_unsync(&local->mc_list, &local->mc_count,
- &dev->mc_list, &dev->mc_count);
+ &dev->mc_list, dev->mc_count);

which is definitely not correct, introduced a warning (reported
by Stephen Rothwell):

net/mac80211/iface.c: In function 'ieee80211_stop':
net/mac80211/iface.c:416: warning: passing argument 4 of '__dev_addr_unsync' makes pointer from integer without a cast
include/linux/netdevice.h:1967: note: expected 'int *' but argument is of type 'int'

and is thus reverted here.

Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/mac80211/iface.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index f943f5f..09fff46 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -413,7 +413,7 @@ static int ieee80211_stop(struct net_device *dev)
netif_addr_lock_bh(dev);
spin_lock_bh(&local->filter_lock);
__dev_addr_unsync(&local->mc_list, &local->mc_count,
- &dev->mc_list, dev->mc_count);
+ &dev->mc_list, &dev->mc_count);
spin_unlock_bh(&local->filter_lock);
netif_addr_unlock_bh(dev);

--
1.6.6.1

==============================================================================
TOPIC: Performance regression in scsi sequential throughput (iozone) due to "e
084b - page-allocator: preserve PFN ordering when __GFP_COLD is set"
http://groups.google.com/group/linux.kernel/t/0f198fe3053e9f98?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 14 2010 11:00 pm
From: Nick Piggin

On Fri, Feb 12, 2010 at 09:05:19PM +1100, Nick Piggin wrote:
> > This leaves me with two ideas what the real issue could be:
> > 1. either really the 6th parameter as this is the first one that needs to go on stack and that way might open a race and rob gcc a big pile of optimization chances
>
> It must be something to do wih code generation AFAIKS. I'm surprised
> the function isn't inlined, giving exactly the same result regardless
> of the patch.
>
> Unlikely to be a correctness issue with code generation, but I'm
> really surprised that a small difference in performance could have
> such a big (and apparently repeatable) effect on behaviour like this.
>
> What's the assembly look like?

Oh, and what happens if you always_inline it? I would have thought
gcc should be able to generate the same code in both cases -- unless
I'm really missing something and there is a functional change in
there?

==============================================================================
TOPIC: linux-next: manual merge of the fsnotify tree with the vfs tree
http://groups.google.com/group/linux.kernel/t/3fca57688125f1ad?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 14 2010 11:00 pm
From: Stephen Rothwell

Hi Eric,

Today's linux-next merge of the fsnotify tree got a conflict in
fs/notify/inotify/inotify_user.c between commit
9f009a78fb3b54976cfe8173d05ef483dbda4571 ("switch inotify_user to
anon_inode") from the vfs tree and commit
9036fe89f12afba49cd3e5b44b2f94fbd3269269 ("inotify: rename mark_entry to
just mark") from the fsnotify tree.

Just context changes. I fixed it up (see below) and can carry the fix as
necessary.

--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au

diff --cc fs/notify/inotify/inotify_user.c
index 472cdf2,bc1f395..0000000
--- a/fs/notify/inotify/inotify_user.c
+++ b/fs/notify/inotify/inotify_user.c
@@@ -767,7 -873,17 +836,7 @@@ out
*/
static int __init inotify_user_setup(void)
{
- inotify_inode_mark_cachep = KMEM_CACHE(inotify_inode_mark_entry, SLAB_PANIC);
- int ret;
-
- ret = register_filesystem(&inotify_fs_type);
- if (unlikely(ret))
- panic("inotify: register_filesystem returned %d!\n", ret);
-
- inotify_mnt = kern_mount(&inotify_fs_type);
- if (IS_ERR(inotify_mnt))
- panic("inotify: kern_mount ret %ld!\n", PTR_ERR(inotify_mnt));
-
+ inotify_inode_mark_cachep = KMEM_CACHE(inotify_inode_mark, SLAB_PANIC);
event_priv_cachep = KMEM_CACHE(inotify_event_private_data, SLAB_PANIC);

inotify_max_queued_events = 16384;
--
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: Resume lock up -- bisected, commit 3a1151e3f124fd1a2c54b8153f510f1a7c
715369
http://groups.google.com/group/linux.kernel/t/09ac7a70d02b0696?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 14 2010 11:00 pm
From: Rafał Miłecki

2010/2/15 Rafael J. Wysocki <rjw@sisk.pl>:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.31 and 2.6.32.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.31 and 2.6.32. Please verify if it still should
> be listed and let the tracking team know (either way).

It should be, there is one testing request I didn't make yet. I'll do
this soon, after my today's study final exam.

--
Rafał
--
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: 2.6.33-rc8 breaks UML with Restrict initial stack space expansion to
rlimit
http://groups.google.com/group/linux.kernel/t/d88757ffc0c5d1f4?hl=en
==============================================================================

== 1 of 5 ==
Date: Sun, Feb 14 2010 11:00 pm
From: Jouni Malinen

On Mon, Feb 15, 2010 at 09:03:39AM +1100, Michael Neuling wrote:
> Crud, the "killed" is definitely something this patch could cause.
>
> I'm not familiar with UML. Is this the guest and the host booting rc8,
> or just the host? Does UML use stack protection at all?

Only the guest was booting rc8 (host is Ubuntu 2.6.31-19-generic), i.e.,
the issue shows up in the guest kernel after rc8 (and is removed by
reverting 803bf5). I do not know whether stack protection is used.

> Can you try booting the guest to init=/bin/sh and try running some tests
> to see what you can set 'ulimit -s' to and still be able to run a simple
> command like '/bin/ls'?

With 803bf5 included, init=/bin/sh seems to fail the boot quite
frequently, but not always. Once I get to shell on the UML guest,
/bin/ls fails about half of the time (e.g., running /bin/ls in /root
failed six times out of ten). This was before touching ulimit -s at all
("ulimit -s" shows 8192).

The behavior of 'ls' run with various ulimit -s values:

24-10000: OK or Killed
16-23: OK or Segmentation fault or Killed
1-15: Killed or Segmentation fault

I have no idea what is causing the random behavior in the results, but
anyway, it looks like 'ulimit -s 23' is the first point where
segmentation faults start showing up and 'ulimit -s 15' is the point
where ls fails every time.

If I start the guest (normal boot with multiple virtual consoles) with
803bf5 reverted, 'ulimit -s 84' has /bin/ls working every time and
'ulimit -s 83' makes it fail every time.

--
Jouni Malinen PGP id EFC895FA
--
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 5 ==
Date: Sun, Feb 14 2010 11:00 pm
From: KOSAKI Motohiro

>
>
> In message <20100214164023.GA2726@jm.kir.nu> you wrote:
> > It looks like the commit 803bf5ec259941936262d10ecc84511b76a20921
> > (fs/exec.c: restrict initial stack space expansion to rlimit) broke my
> > user mode Linux setup by somehow preventing system setup from running
> > properly (or killing some processes that try to mount things, etc.).
> > This commit turned up as the reason based on git bisect and reverting it
> > fixes my UML test setup (Ubuntu 9.10 on both host and in UML and AMD64
> > arch for both). I have no idea what exactly would be the main cause for
> > this issue, but this looks like a somewhat unfortunately timed
> > regression in 2.6.33-rc8.
> >
> > The failed run shows like this (with current linux-2.6.git):
> >
> > ...
> > EXT3-fs (ubda): mounted filesystem with writeback data mode
> > VFS: Mounted root (ext3 filesystem) readonly on device 98:0.
> > IRQ 3/console-write: IRQF_DISABLED is not guaranteed on shared IRQs
> > IRQ 2/console: IRQF_DISABLED is not guaranteed on shared IRQs
> > IRQ 10/winch: IRQF_DISABLED is not guaranteed on shared IRQs
> > IRQ 10/winch: IRQF_DISABLED is not guaranteed on shared IRQs
> > mountall: mount /sys/kernel/debug [218] killed by KILL signal
> > mountall: Filesystem could not be mounted: /sys/kernel/debug
> > mountall: mount /dev [219] killed by KILL signal
> > mountall: Filesystem could not be mounted: /dev
> > mountall: mount /tmp [220] killed by KILL signal
> > mountall: Filesystem could not be mounted: /tmp
> > mountall: mount /var/lock [222] killed by KILL signal
> > mountall: Filesystem could not be mounted: /var/lock
> > ...
> >
> >
> > With 803bf5ec reverted, UML comes up and the output looks like this:
> >
> > ...
> > EXT3-fs (ubda): mounted filesystem with writeback data mode
> > VFS: Mounted root (ext3 filesystem) readonly on device 98:0.
> > IRQ 3/console-write: IRQF_DISABLED is not guaranteed on shared IRQs
> > IRQ 2/console: IRQF_DISABLED is not guaranteed on shared IRQs
> > IRQ 10/winch: IRQF_DISABLED is not guaranteed on shared IRQs
> > IRQ 10/winch: IRQF_DISABLED is not guaranteed on shared IRQs
> > init: procps main process (226) terminated with status 255
> > fsck from util-linux-ng 2.16
> > ...
>
> Jouni,
>
> I can reproduce this now.
>
> We got the logic wrong in one of the cleanups and hence we aren't
> actually changing the stack reservation ever, when we intended on
> allocating up to 20 new pages.
>
> The:
> rlim_stack = min(rlim_stack, stack_size);
> always chooses stack_size hence we end up not changing the stack at all.
> This seems to cause fatal problems on UML, but is obviously not what was
> intended for archs as well.
>
> The following works for me on PPC64 64k and 4k pages and UML on x86_64.
>
> Let me know if it fixes it for you also.
>
> Mikey
>
>
> exec/fs: fix initial stack reservation
>
> 803bf5ec259941936262d10ecc84511b76a20921 (fs/exec.c: restrict initial
> stack space expansion to rlimit) attempts to limit the initial stack to
> 20*PAGE_SIZE. Unfortunately, in also attempting ensure the stack is not
> reduced in size, we ended up not changing the stack at all.
>
> This caused a regression in UML resulting in most guest processes to be
> killed.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> cc: <stable@kernel.org>
>
> diff --git a/fs/exec.c b/fs/exec.c
> index e95c692..e0e7b3c 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -637,15 +637,16 @@ int setup_arg_pages(struct linux_binprm *bprm,
> * will align it up.
> */
> rlim_stack = rlimit(RLIMIT_STACK) & PAGE_MASK;
> - rlim_stack = min(rlim_stack, stack_size);
> #ifdef CONFIG_STACK_GROWSUP
> if (stack_size + stack_expand > rlim_stack)
> - stack_base = vma->vm_start + rlim_stack;
> + /* Expand only to rlimit, making sure not to shrink it */
> + stack_base = vma->vm_start + max(rlim_stack,stack_size);
> else
> stack_base = vma->vm_end + stack_expand;
> #else
> if (stack_size + stack_expand > rlim_stack)
> - stack_base = vma->vm_end - rlim_stack;
> + /* Expand only to rlimit, making sure not to shrink it */
> + stack_base = vma->vm_end - max(rlim_stack,stack_size);
> else
> stack_base = vma->vm_start - stack_expand;
>

twitter

Sunday, February 14, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts