* [Qemu-devel] qemu exec.c
From: Paul Brook @ 2006-04-08 20:02 UTC (permalink / raw)
To: qemu-devel
CVSROOT: /sources/qemu
Module name: qemu
Branch:
Changes by: Paul Brook <pbrook@savannah.gnu.org> 06/04/08 20:02:06
Modified files:
. : exec.c
Log message:
Initialize physical memory space to IO_MEM_UNASSIGNED.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/exec.c.diff?tr1=1.76&tr2=1.77&r1=text&r2=text
^ permalink raw reply
* Re: [PATCH] Script for automated historical Git tree grafting
From: Nicholas Miell @ 2006-04-08 20:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Andrew Morton, torvalds, linux-kernel, git
In-Reply-To: <20060408030936.GN27631@pasky.or.cz>
On Sat, 2006-04-08 at 05:09 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 07, 2006 at 02:52:46AM CEST, I got a letter
> where Andrew Morton <akpm@osdl.org> said that...
> > Petr Baudis <pasky@suse.cz> wrote:
> > >
> > > This script enables Git users to easily graft the historical Git tree
> > > (Bitkeeper history import) to the current history.
> >
> > What impact will that have on the (already rather poor) performance of
> > git-whatchanged, gitk, etc?
>
> Negative. ;-)
>
> I didn't try gitk myself, but according to Nick Riviera it eats 1.6G...
> Otherwise, assuming that you have at least git-1.2.5, git-whatchanged on
> the whole tree should be roughly equally fast as it was before grafting,
> but git-whatchanged on individual paths is _significantly_ slower.
>
> That said, 1.3.0rc2 should already have Linus' optimization which should
> fix or at least mitigate the performance hit on narrowed-down
> git-whatchanged.
Actually, it ate more than 1.6G -- that was just the resident size, and
it likes to allocate more memory in between you closing the window and
it finally exiting (or, you killing it before it OOMs the box, whichever
comes first).
qgit has absolutely no problem with the grafted full history, though,
and those previously mentioned rev-list changes by Linus should fix
git-whatchanged.
Unfortunately, this does nothing to fix the disturbing lack of useless
Simpsons trivia knowledge in the git community. Keith Packard made the
same mistake last week.
--
Nicholas Miell <nmiell@comcast.net>
^ permalink raw reply
* Linux 2.6.17-rc1: /sbin/iptables does not find kernel netfilter
From: Ville Herva @ 2006-04-08 20:09 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.4.64.0604022037380.3781@g5.osdl.org>
On Sun, Apr 02, 2006 at 08:47:06PM -0700, you [Linus Torvalds] wrote:
>
> Ok,
> it's two weeks since 2.6.16, and the merge window is closed.
I upgraded from 2.6.15-rc7 to 2.6.17-rc1. rc1 seems nice other than that
iptables stopped working:
failed iptables v1.3.5: can't initialize iptables table filter: iptables
who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
iptables is compiled in the kernel, not a module:
CONFIG_NETFILTER=y
I can even do "modprobe iptable_nat" successfully (iptable_nat is module),
but iptables refuses to work. iptables is of version iptables-1.3.5-1.2.
The kernel config is copied with make oldconfig from 2.6.15-rc7 (which
worked), not much else has changed. I just booted back to 2.6.15-rc7 and
verified it works. Any ideas?
-- v --
v@iki.fi
^ permalink raw reply
* [PATCH rc1-mm 0/3] coredump: rfc
From: Oleg Nesterov @ 2006-04-09 0:11 UTC (permalink / raw)
To: linux-kernel
Cc: Eric W. Biederman, Ingo Molnar, Paul E. McKenney, Roland McGrath,
Andrew Morton, Lee Revell
I am unsure about this series. It adds some optimizations, but
complicates the code.
So I am asking for yours opinion not only about correctness, but
also about usefulness.
Oleg.
^ permalink raw reply
* Re: + git-klibc-mktemp-fix.patch added to -mm tree
From: Sam Ravnborg @ 2006-04-08 20:14 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, hpa, mm-commits
In-Reply-To: <200604080707.k38778VV023208@shell0.pdx.osdl.net>
On Sat, Apr 08, 2006 at 12:05:54AM -0700, akpm@osdl.org wrote:
> diff -puN usr/dash/mkbuiltins~git-klibc-mktemp-fix usr/dash/mkbuiltins
> --- 25/usr/dash/mkbuiltins~git-klibc-mktemp-fix Sat Apr 8 14:51:11 2006
> +++ 25-akpm/usr/dash/mkbuiltins Sat Apr 8 14:51:11 2006
> @@ -37,7 +37,7 @@
>
> tempfile=tempfile
> if ! type tempfile > /dev/null 2>&1; then
> - tempfile=mktemp
> + tempfile="mktemp /tmp/tmp.XXXXXX"
Shouldn't that be:
> + tempfile="$(mktemp /tmp/tmp.XXXXXX)"
Sam
^ permalink raw reply
* [PATCH rc1-mm 1/3] coredump: some code relocations
From: Oleg Nesterov @ 2006-04-09 0:11 UTC (permalink / raw)
To: linux-kernel
Cc: Eric W. Biederman, Ingo Molnar, Paul E. McKenney, Roland McGrath,
Andrew Morton, Lee Revell
This is a preparation for the next patch. No functional changes.
Basically, this patch moves '->flags & SIGNAL_GROUP_EXIT' check
into zap_threads(), and 'complete(vfork_done)' into coredump_wait
outside of ->mmap_sem protected area.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
--- MM/fs/exec.c~1_clean 2006-04-07 01:32:02.000000000 +0400
+++ MM/fs/exec.c 2006-04-09 02:33:28.000000000 +0400
@@ -1405,20 +1405,22 @@ static void zap_process(struct task_stru
unlock_task_sighand(start, &flags);
}
-static void zap_threads(struct mm_struct *mm)
+static inline int zap_threads(struct task_struct *tsk, struct mm_struct *mm,
+ int exit_code)
{
struct task_struct *g, *p;
- struct task_struct *tsk = current;
- struct completion *vfork_done = tsk->vfork_done;
+ int err = -EAGAIN;
- /*
- * Make sure nobody is waiting for us to release the VM,
- * otherwise we can deadlock when we wait on each other
- */
- if (vfork_done) {
- tsk->vfork_done = NULL;
- complete(vfork_done);
+ spin_lock_irq(&tsk->sighand->siglock);
+ if (!(tsk->signal->flags & SIGNAL_GROUP_EXIT)) {
+ tsk->signal->flags = SIGNAL_GROUP_EXIT;
+ tsk->signal->group_exit_code = exit_code;
+ tsk->signal->group_stop_count = 0;
+ err = 0;
}
+ spin_unlock_irq(&tsk->sighand->siglock);
+ if (err)
+ return err;
rcu_read_lock();
for_each_process(g) {
@@ -1432,22 +1434,43 @@ static void zap_threads(struct mm_struct
} while ((p = next_thread(p)) != g);
}
rcu_read_unlock();
+
+ return mm->core_waiters;
}
-static void coredump_wait(struct mm_struct *mm)
+static int coredump_wait(int exit_code)
{
- DECLARE_COMPLETION(startup_done);
+ struct task_struct *tsk = current;
+ struct mm_struct *mm = tsk->mm;
+ struct completion startup_done;
+ struct completion *vfork_done;
int core_waiters;
+ init_completion(&mm->core_done);
+ init_completion(&startup_done);
mm->core_startup_done = &startup_done;
- zap_threads(mm);
- core_waiters = mm->core_waiters;
+ core_waiters = zap_threads(tsk, mm, exit_code);
up_write(&mm->mmap_sem);
+ if (unlikely(core_waiters < 0))
+ goto fail;
+
+ /*
+ * Make sure nobody is waiting for us to release the VM,
+ * otherwise we can deadlock when we wait on each other
+ */
+ vfork_done = tsk->vfork_done;
+ if (vfork_done) {
+ tsk->vfork_done = NULL;
+ complete(vfork_done);
+ }
+
if (core_waiters)
wait_for_completion(&startup_done);
+fail:
BUG_ON(mm->core_waiters);
+ return core_waiters;
}
int do_coredump(long signr, int exit_code, struct pt_regs * regs)
@@ -1481,22 +1504,9 @@ int do_coredump(long signr, int exit_cod
}
mm->dumpable = 0;
- retval = -EAGAIN;
- spin_lock_irq(¤t->sighand->siglock);
- if (!(current->signal->flags & SIGNAL_GROUP_EXIT)) {
- current->signal->flags = SIGNAL_GROUP_EXIT;
- current->signal->group_exit_code = exit_code;
- current->signal->group_stop_count = 0;
- retval = 0;
- }
- spin_unlock_irq(¤t->sighand->siglock);
- if (retval) {
- up_write(&mm->mmap_sem);
+ retval = coredump_wait(exit_code);
+ if (retval < 0)
goto fail;
- }
-
- init_completion(&mm->core_done);
- coredump_wait(mm);
/*
* Clear any false indication of pending signals that might
^ permalink raw reply
* [PATCH rc1-mm 2/3] coredump: shutdown current process first
From: Oleg Nesterov @ 2006-04-09 0:11 UTC (permalink / raw)
To: linux-kernel
Cc: Eric W. Biederman, Ingo Molnar, Paul E. McKenney, Roland McGrath,
Andrew Morton, Lee Revell
This patch optimize zap_threads() for the case when there are
no ->mm users except the current's thread group. In that case
we can avoid 'for_each_process()' loop.
It also adds a useful invariant: SIGNAL_GROUP_EXIT (if checked
under ->siglock) always implies that all threads (except may be
current) have pending SIGKILL.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
--- MM/fs/exec.c~2_optmz 2006-04-09 02:33:28.000000000 +0400
+++ MM/fs/exec.c 2006-04-09 03:06:43.000000000 +0400
@@ -1383,13 +1383,7 @@ static void format_corename(char *corena
static void zap_process(struct task_struct *start)
{
struct task_struct *t;
- unsigned long flags;
- /*
- * start->sighand can't disappear, but may be
- * changed by de_thread()
- */
- lock_task_sighand(start, &flags);
start->signal->flags = SIGNAL_GROUP_EXIT;
start->signal->group_stop_count = 0;
@@ -1401,40 +1395,51 @@ static void zap_process(struct task_stru
signal_wake_up(t, 1);
}
} while ((t = next_thread(t)) != start);
-
- unlock_task_sighand(start, &flags);
}
static inline int zap_threads(struct task_struct *tsk, struct mm_struct *mm,
int exit_code)
{
struct task_struct *g, *p;
+ unsigned long flags;
int err = -EAGAIN;
spin_lock_irq(&tsk->sighand->siglock);
if (!(tsk->signal->flags & SIGNAL_GROUP_EXIT)) {
- tsk->signal->flags = SIGNAL_GROUP_EXIT;
tsk->signal->group_exit_code = exit_code;
- tsk->signal->group_stop_count = 0;
+ zap_process(tsk);
err = 0;
}
spin_unlock_irq(&tsk->sighand->siglock);
if (err)
return err;
+ if (atomic_read(&mm->mm_users) == mm->core_waiters + 1)
+ goto done;
+
rcu_read_lock();
for_each_process(g) {
+ if (g == tsk->group_leader)
+ continue;
+
p = g;
do {
if (p->mm) {
- if (p->mm == mm)
+ if (p->mm == mm) {
+ /*
+ * p->sighand can't disappear, but
+ * may be changed by de_thread()
+ */
+ lock_task_sighand(p, &flags);
zap_process(p);
+ unlock_task_sighand(p, &flags);
+ }
break;
}
} while ((p = next_thread(p)) != g);
}
rcu_read_unlock();
-
+done:
return mm->core_waiters;
}
^ permalink raw reply
* [PATCH rc1-mm 3/3] coredump: copy_process: don't check SIGNAL_GROUP_EXIT
From: Oleg Nesterov @ 2006-04-09 0:11 UTC (permalink / raw)
To: linux-kernel
Cc: Eric W. Biederman, Ingo Molnar, Paul E. McKenney, Roland McGrath,
Andrew Morton, Lee Revell
After the previous patch SIGNAL_GROUP_EXIT implies a pending SIGKILL,
we can remove this check from copy_process() because we already checked
!signal_pending().
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
--- MM/kernel/fork.c~3_fork 2006-03-23 22:59:33.000000000 +0300
+++ MM/kernel/fork.c 2006-04-09 03:17:12.000000000 +0400
@@ -1157,18 +1157,6 @@ static task_t *copy_process(unsigned lon
}
if (clone_flags & CLONE_THREAD) {
- /*
- * Important: if an exit-all has been started then
- * do not create this new thread - the whole thread
- * group is supposed to exit anyway.
- */
- if (current->signal->flags & SIGNAL_GROUP_EXIT) {
- spin_unlock(¤t->sighand->siglock);
- write_unlock_irq(&tasklist_lock);
- retval = -EAGAIN;
- goto bad_fork_cleanup_namespace;
- }
-
p->group_leader = current->group_leader;
list_add_tail_rcu(&p->thread_group, &p->group_leader->thread_group);
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Brad Campbell @ 2006-04-08 20:19 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <443802FB.9060700@win4lin.com>
Leonardo E. Reiter wrote:
> The mouse sync solution we have in Win4Lin Pro is okay, but it's a bit
> slow and I'd like to do something much cleaner. Of course if I do the
> wacom tablet implementation, it will be open source and part of QEMU
> itself.
>
This link might or might not be intersting
http://72.14.203.104/search?q=cache:fZ3xQJYOy6UJ:www.codecomments.com/archive421-2005-5-499360.html+hid+mouse+absolute+support&hl=en&ct=clnk&cd=1&lr=lang_en
Apparently USB HID supports absolute input devices natively. Given we have a HID mouse driver of
sorts in qemu I wonder if that is another avenue perhaps ?
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
^ permalink raw reply
* Re: [PATCH 2/3] [libnetfilter_conntrack] fixed duration connection
From: Eric Leblond @ 2006-04-08 20:23 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Netfilter Development Mailinglist, nufw-devel
In-Reply-To: <44381602.5090105@trash.net>
[-- Attachment #1: Type: text/plain, Size: 637 bytes --]
Patrick McHardy wrote:
> Eric Leblond wrote:
>
>>Hi,
>>
>>This patch add support for the IPS_FIXED_TIMEOUT state.
> I didn't see the patch adding support for this in the kernel. Since
> there is no seperate fixed timeout anymore, this also looks obsolete.
> The way I understood the kernel patch, you would just do two netlink
> operations:
>
> - set flag FIXED_TIMEOUT
> - change timeout using CTA_TIMEOUT
>
> Am I missing something?
Clearly not. I was a little bit too tired yesterday and I've done a "svn
diff" in the bad directory. Please ignore previous patch and consider
this far smaller one.
Best regards,
--
Eric Leblond
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: libnetfilter_conntrack_fixed_timeout-flag.patch --]
[-- Type: text/x-patch; name="libnetfilter_conntrack_fixed_timeout-flag.patch", Size: 574 bytes --]
Index: include/libnetfilter_conntrack/libnetfilter_conntrack.h
===================================================================
--- include/libnetfilter_conntrack/libnetfilter_conntrack.h (révision 6578)
+++ include/libnetfilter_conntrack/libnetfilter_conntrack.h (copie de travail)
@@ -191,6 +191,11 @@
/* Connection is dying (removed from lists), can not be unset. */
IPS_DYING_BIT = 9,
IPS_DYING = (1 << IPS_DYING_BIT),
+
+ /* Connection has fixed timeout. */
+ IPS_FIXED_TIMEOUT_BIT = 10,
+ IPS_FIXED_TIMEOUT = (1 << IPS_FIXED_TIMEOUT_BIT),
+
};
enum {
^ permalink raw reply
* [PATCH] Fix test for command line syntax.
From: Peter Eriksen @ 2006-04-08 20:24 UTC (permalink / raw)
To: git
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
test-delta.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
3e2552fff69fb01249fed53380e24e11754afcdf
diff --git a/test-delta.c b/test-delta.c
index 1be8ee0..94b47f0 100644
--- a/test-delta.c
+++ b/test-delta.c
@@ -27,7 +27,7 @@ int main(int argc, char *argv[])
void *from_buf, *data_buf, *out_buf;
unsigned long from_size, data_size, out_size;
- if (argc != 5 || (strcmp(argv[1], "-d") && strcmp(argv[1], "-p"))) {
+ if (argc != 5 || (strcmp(argv[1], "-d") || strcmp(argv[1], "-p"))) {
fprintf(stderr, "Usage: %s\n", usage);
return 1;
}
--
1.3.0.rc1.g40e9
^ permalink raw reply related
* Re: + git-klibc-mktemp-fix.patch added to -mm tree
From: H. Peter Anvin @ 2006-04-08 20:27 UTC (permalink / raw)
To: Sam Ravnborg, Herbert Xu; +Cc: linux-kernel, akpm, mm-commits
In-Reply-To: <20060408201412.GA26946@mars.ravnborg.org>
Sam Ravnborg wrote:
> On Sat, Apr 08, 2006 at 12:05:54AM -0700, akpm@osdl.org wrote:
>> diff -puN usr/dash/mkbuiltins~git-klibc-mktemp-fix usr/dash/mkbuiltins
>> --- 25/usr/dash/mkbuiltins~git-klibc-mktemp-fix Sat Apr 8 14:51:11 2006
>> +++ 25-akpm/usr/dash/mkbuiltins Sat Apr 8 14:51:11 2006
>> @@ -37,7 +37,7 @@
>>
>> tempfile=tempfile
>> if ! type tempfile > /dev/null 2>&1; then
>> - tempfile=mktemp
>> + tempfile="mktemp /tmp/tmp.XXXXXX"
>
> Shouldn't that be:
>> + tempfile="$(mktemp /tmp/tmp.XXXXXX)"
>
No, it's invoked later on as:
temp=$($tempfile)
temp2=$($tempfile)
Either which way; I have a better fix for the bison issue (this all has
to do with the fact that make's handling of tools that output more than
one file at a time is at the very best insane); however, I'm getting
rather unhappy with some of the code in dash.
In particular, mksyntax.c seems to assume it runs on the same machine
that the resulting code is going to execute on, for example, it tries to
detect whether or not "char" is signed, but that doesn't work when
cross-compiling.
dash isn't actually necessary in the in-kernel build, although it's a
very nice bonus for customizing initramfs to have a shell to glue things
together with.
Herbert: can the code be restructured with appropriate casts so that
signed/unsigned is factored out of mksyntax? As it currently stands,
it's not cross-compile-safe, which is unacceptable.
-hpa
^ permalink raw reply
* Re: [PATCH] Fix test for command line syntax.
From: Peter Eriksen @ 2006-04-08 20:29 UTC (permalink / raw)
To: git
In-Reply-To: <20060408202450.GA5548@bohr.gbar.dtu.dk>
On Sat, Apr 08, 2006 at 10:24:50PM +0200, Peter Eriksen wrote:
>
> Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
>
>
> ---
>
> test-delta.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Please ignore this. Sorry for the noise.
Peter
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Leonardo E. Reiter @ 2006-04-08 20:29 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <44381AE0.1020106@wasp.net.au>
I saw something like this once but dismissed it for some reason (like it
was questionable whether or not Windows supported these types of
devices)... it's quite interesting.
Thanks,
- Leo Reiter
Brad Campbell wrote:
> This link might or might not be intersting
>
> http://72.14.203.104/search?q=cache:fZ3xQJYOy6UJ:www.codecomments.com/archive421-2005-5-499360.html+hid+mouse+absolute+support&hl=en&ct=clnk&cd=1&lr=lang_en
>
>
> Apparently USB HID supports absolute input devices natively. Given we
> have a HID mouse driver of sorts in qemu I wonder if that is another
> avenue perhaps ?
>
>
--
Leonardo E. Reiter
Vice President of Product Development, CTO
Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com
^ permalink raw reply
* [ALSA - driver 0002008]: No Sound with snd-hda-intel driver Asus P5VDC-MX
From: bugtrack @ 2006-04-08 20:30 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2008>
======================================================================
Reported By: mborsick
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 2008
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Redhat/Fedora
Kernel Version: 2.6.16-1.2080 and with Xen
======================================================================
Date Submitted: 04-07-2006 00:43 CEST
Last Modified: 04-08-2006 22:30 CEST
======================================================================
Summary: No Sound with snd-hda-intel driver Asus P5VDC-MX
Description:
Kernel is up-to-date Xen kernel.
Initial install did not recognize the sound on an ASUS P5VDC-MX
motherboard.
Motherboard has southbridge VIA VT8251. CODEC is Realtek ACL653 AC'97 6
channel
Audio. Tried the updated drivers in 002404, but was unsuccessful. Also
tried
drivers on VIA site and Realltek site. The last couple of tries show no
errors
in compiling, make, etc. However, as I am just above novice in
understanding
everything about Linux, this has thrown me for a loop.
======================================================================
----------------------------------------------------------------------
buboleck - 04-08-06 00:44
----------------------------------------------------------------------
ok. can you direct me please how to describe it?
----------------------------------------------------------------------
mborsick - 04-08-06 22:30
----------------------------------------------------------------------
Been following this, but have been unable to jump in because of other IT
projects I am working on here. Do you want me to file this with the linnux
kernel folks?
Issue History
Date Modified Username Field Change
======================================================================
04-07-06 00:43 mborsick New Issue
04-07-06 00:43 mborsick Distribution => Redhat/Fedora
04-07-06 00:43 mborsick Kernel Version => 2.6.16-1.2080 and
with Xen
04-07-06 01:07 rlrevell Note Added: 0009129
04-07-06 02:13 mborsick Note Added: 0009130
04-07-06 02:35 rlrevell Note Added: 0009131
04-07-06 06:38 mborsick Note Added: 0009135
04-07-06 22:45 buboleck Note Added: 0009156
04-07-06 22:47 buboleck Note Edited: 0009156
04-07-06 22:49 buboleck Note Edited: 0009156
04-07-06 23:06 rlrevell Note Added: 0009157
04-07-06 23:16 buboleck Issue Monitored: buboleck
04-07-06 23:26 buboleck Note Added: 0009158
04-07-06 23:32 rlrevell Note Added: 0009159
04-07-06 23:39 buboleck Note Added: 0009160
04-07-06 23:40 buboleck Note Edited: 0009160
04-07-06 23:43 buboleck Note Edited: 0009160
04-07-06 23:46 buboleck Note Edited: 0009160
04-07-06 23:47 rlrevell Note Added: 0009161
04-07-06 23:52 buboleck Note Added: 0009162
04-08-06 00:02 rlrevell Note Added: 0009163
04-08-06 00:16 buboleck Note Added: 0009164
04-08-06 00:19 buboleck Note Added: 0009165
04-08-06 00:29 rlrevell Note Added: 0009166
04-08-06 00:32 buboleck Note Added: 0009167
04-08-06 00:41 rlrevell Note Added: 0009168
04-08-06 00:42 buboleck Note Added: 0009169
04-08-06 00:44 buboleck Note Edited: 0009169
04-08-06 22:30 mborsick Note Added: 0009173
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [LARTC] source routing does not work with extra ip addresses
From: Martin A. Brown @ 2006-04-08 20:31 UTC (permalink / raw)
To: lartc
In-Reply-To: <20060408123017.4a108613.mailinglists@lucassen.org>
Hello again,
: > Does server have one or two IP addresses? Best solution? Use two
: > IP addresses on server.
:
: Hmmm, one for ISP1 and one for ISP2? That would be a nice idea to
: workaround this problem :-)
Only way I have done this myself, although I recall somebody else on
LARTC using connmark with nfmark and/or the ROUTE target to solve
this problem using only a single IP. Perhaps the archive will help
you here....
: > Try changing this (or adding another rule):
: >
: > ip rule add from 10.0.0.2 lookup table_eth1
:
: Nope. I already tried that, but no way.
: No. The packets are returned through ISP1.
:
: > If you would like to handle inbound traffic on both links, then add
: > a secondary IP address to your server, and enter another DNAT rule
: > which specifies another NAT mapping for the secondary IP.
:
: That's a very nice idea, but packets keep on entering the wrong
: table (default), I think it's a bug somewhere in the kernel.
While the kernel certainly has seen bugs before and will see more, I
hope you don't mind if I continue to entertain a bit of skepticism
on this point. :)
: It only works when the ip is direct on the external interface of
: the Linuxbox, but as soon as 1 tcp port is translated, the return
: packets for that translated port get into the wrong (default)
: table.
:
: Even when using fw marks it doesn't work. I mark all packets coming
: from the servers second ip address with '1' and a simple
:
: ip ru a fwmark 1 table t_eth1
:
: should do the job. But no way. Packets keep on getting out
: through ISP1 (t_eth0).
:
: This is the real test:
:
: 10.0.2.1 is the server, 10.0.2.3 is its second ip.
: 10.0.2.1 = external 10.1.3.100
: 10.0.2.3 = external 192.168.201.3
OK, got it!
: # ip r s
: 192.168.201.3 via 10.0.2.3 dev eth2
: 10.1.3.100 via 10.0.2.1 dev eth2
[ snipped main and ancillary routing tables except for unusual and
possibly extraneous routes. ]
Routing tables t_eth0 and t_eth1 look fine, although t_eth0 and main
should be exactly the same. I believe your two host routes (for
192.168.201.3 and 10.1.3.100) are unnecessary and simply complicate
your scenario.
I still think your problem is in the RPDB and addressing of the
packet at routing time. I do not believe (check the KPTD and its
offspring [0] [1]) that the packet's source address has yet been
rewritten. Think about this, and look at your RPDB:
: # ip ru s
: 0: from all lookup local
: 32762: from all fwmark 0x1 lookup t_eth1
: 32764: from 192.168.201.2 lookup t_eth1
: 32765: from 10.1.3.101 lookup t_eth0
: 32766: from all lookup main
: 32767: from all lookup default
The addresses you have entered are the public side addresses. When
the server transmits packets, these packets will have the 10.0.2.1
and 10.0.2.3 addresses for source addresses. The RPDB should
include references to these private addresses instead of the
addresses available on the public side.
: btw: iproute2-ss06011, kernel 2.6.16.2, iptables 1.3.5
I hope this helps, and thanks for the detailed listing of your
configuration. It's always helpful.
Best of luck,
-Martin
[0] http://www.docum.org/docum.org/kptd/
[1] http://linux-ip.net/nf/nfk-traversal.eps
http://linux-ip.net/nf/nfk-traversal.png
--
Martin A. Brown --- Wonderfrog Enterprises --- martin@wonderfrog.net
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
From: Al Boldi @ 2006-04-08 20:31 UTC (permalink / raw)
To: Peter Williams; +Cc: linux-kernel
In-Reply-To: <443711EC.7070003@bigpond.net.au>
Peter Williams wrote:
> Al Boldi wrote:
> > Can you try the attached mem-eater passing it the number of kb to be
> > eaten.
> >
> > i.e. '# while :; do ./eatm 9999 ; done'
> >
> > This will print the number of bytes eaten and the timing in ms.
> >
> > Adjust the number of kb to be eaten such that the timing will be less
> > than timeslice (120ms by default for spa). Switch to another vt and
> > start pressing enter. A console lockup should follow within seconds for
> > all spas except ebs.
>
> This doesn't seem to present a problem (other than the eatme loop being
> hard to kill with control-C) on my system using spa_ws with standard
> settings. I tried both UP and SMP. I may be doing something wrong or
> perhaps don't understand what you mean by a console lock up.
Switching from one vt to another receives hardly any response.
This is especially visible in spa_no_frills, and spa_ws recovers from this
lockup somewhat and starts exhibiting this problem as a choking behavior.
Running '# top d.1 (then shift T)' on another vt shows this choking behavior
as the proc gets boosted.
> When you say "less than the timeslice" how much smaller do you mean?
This depends on your machine's performance. On my 400MhzP2 UP 128MB, w/
spa_no_frills default settings, looping eatm 9999 takes 63ms per eat and
causes the rest of the system to be starved. Raising kb to 19999 takes
126ms which is greater than the default 120ms timeslice and causes no system
starvation.
What numbers do you get?
Thanks!
--
Al
^ permalink raw reply
* Re: [PATCH 3/7] uts namespaces: use init_utsname when appropriate
From: Serge E. Hallyn @ 2006-04-08 20:27 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Serge E. Hallyn, linux-kernel, Kirill Korotaev, herbert, devel,
sam, xemul, James Morris
In-Reply-To: <m1psjslf1s.fsf@ebiederm.dsl.xmission.com>
Quoting Eric W. Biederman (ebiederm@xmission.com):
> "Serge E. Hallyn" <serue@us.ibm.com> writes:
>
> > diff --git a/include/asm-i386/elf.h b/include/asm-i386/elf.h
> > index 4153d80..8d455e2 100644
> > --- a/include/asm-i386/elf.h
> > +++ b/include/asm-i386/elf.h
> > @@ -108,7 +108,7 @@ typedef struct user_fxsr_struct elf_fpxr
> > For the moment, we have only optimizations for the Intel generations,
> > but that could change... */
> >
> > -#define ELF_PLATFORM (system_utsname.machine)
> > +#define ELF_PLATFORM (init_utsname()->machine)
> >
> > #ifdef __KERNEL__
> > #define SET_PERSONALITY(ex, ibcs2) do { } while (0)
>
> I think this one needs to be utsname()->machine.
>
> Currently it doesn't matter. But Herbert has expressed
> the desire to make a machine appear like an older one.
Ok.
> > diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
> > index cb8a92f..81db372 100644
...
> > @@ -1479,11 +1479,11 @@ static int __init ip_auto_config_setup(c
> > case 4:
> > if ((dp = strchr(ip, '.'))) {
> > *dp++ = '\0';
> > - strlcpy(system_utsname.domainname, dp,
> > - sizeof(system_utsname.domainname));
> > + strlcpy(init_utsname()->domainname, dp,
> > + sizeof(init_utsname()->domainname));
> > }
> > - strlcpy(system_utsname.nodename, ip,
> > - sizeof(system_utsname.nodename));
> > + strlcpy(init_utsname()->nodename, ip,
> > + sizeof(init_utsname()->nodename));
> > ic_host_name_set = 1;
> > break;
> > case 5:
>
> This also probably makes sense as utsname(). It doesn't
> really matter as this is before init is executed. But logically
> this is a user space or per namespace action.
Right, I was kind of favoring using init_utsname() for anything
__init. But utsname() will of course work just as well there.
> > diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
> > index aa8965e..97c8439 100644
> > --- a/net/sunrpc/clnt.c
> > +++ b/net/sunrpc/clnt.c
> > @@ -176,10 +176,10 @@ rpc_new_client(struct rpc_xprt *xprt, ch
> > }
> >
> > /* save the nodename */
> > - clnt->cl_nodelen = strlen(system_utsname.nodename);
> > + clnt->cl_nodelen = strlen(init_utsname()->nodename);
> > if (clnt->cl_nodelen > UNX_MAXNODENAME)
> > clnt->cl_nodelen = UNX_MAXNODENAME;
> > - memcpy(clnt->cl_nodename, system_utsname.nodename, clnt->cl_nodelen);
> > + memcpy(clnt->cl_nodename, init_utsname()->nodename, clnt->cl_nodelen);
> > return clnt;
> >
> > out_no_auth:
>
> Using nodename is practically the definition of something
> that should per namespace I think. Plus it would be really inconsistent
> to use utsname() and the init_utsname for the nfs rpc calls.
>
> Unless I am missing something.
It seemed like this would be happening in any old context, so that
current->uts_ns could be any process'. Tracing it back further,
it seems like nfs+lockd should have the context available. So I'll
switch this as well.
thanks,
-serge
^ permalink raw reply
* Re: [RFC][PATCH 1/5] uts namespaces: Implement utsname namespaces
From: Serge E. Hallyn @ 2006-04-08 20:28 UTC (permalink / raw)
To: Andi Kleen; +Cc: Serge E. Hallyn, linux-kernel
In-Reply-To: <p73hd549o5u.fsf@bragg.suse.de>
Quoting Andi Kleen (ak@suse.de):
> "Serge E. Hallyn" <serue@us.ibm.com> writes:
>
> > This patch defines the uts namespace and some manipulators.
> > Adds the uts namespace to task_struct, and initializes a
> > system-wide init namespace which will continue to be used when
> > it makes sense.
>
> So to get this straight - you want to add a new pointer to
> task_struct for each possible virtualized entity?
>
> After you're doing by how many bytes will task_struct be bloated?
> I don't think that's a very good approach because you'll crank
> up the per thread memory overhead which is already far too big
> in Linux. Also it adds cache foot print and generally makes
> things slower.
>
> If anything I would request using a proxy data structure
> that contains all the virtualized namespaces for a set
> of processes. And give each task only has a single pointer
> to one of these.
This is something we've been discussing - whether to use a single
"container" structure pointing to all the namespaces, or put everything
into the task_struct. Using container structs means more cache misses
and refcounting issues, but keeps task_struct smaller as you point out.
The consensus so far has been to start putting things into task_struct
and move if needed. At least the performance numbers show that so far
there is no impact.
iirc container patches have been sent before. Should those be resent,
then, and perhaps this patchset rebased on those?
thanks,
-serge
^ permalink raw reply
* Re: Building a small sparc32 kernel
From: Wolfram Quester @ 2006-04-08 20:38 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <20060404151927.GC2358@cassis>
[-- Attachment #1: Type: text/plain, Size: 812 bytes --]
Hi altogether!
On Sat, Apr 08, 2006 at 04:24:28PM +0200, Ludovic Courtès wrote:
[...snip...]
>
> The machine has two SuperSPARC 390Z50. In your original message you
> mentioned that support for SuperSPARC II was relatively stable, so maybe
> this just means that support for this older SuperSPARC flavor is not yet
> in such a good shape? ;-)
Probably I'm wrong but wasn't there an issue with the 390Z50 not having
cache (in contrast to Z55) an thus not being supported in SMP mode?
With best regards,
Wolfi
>
> Let me know how I can help with this.
>
> Thanks,
> Ludovic.
>
> -
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: blame now knows -S
From: Junio C Hamano @ 2006-04-08 20:39 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Martin Langhoff, git
In-Reply-To: <20060408114240.GA10137@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> There is another possible optimisation with respect to xdiff. Instead
> of producing the diff on the xdiff side and parsing the diff in
> blame.c, we could add another call back which just gets the relevant
> information from the hunk header. I don't know how much we would gain
> from this, but it might be worth a try.
I've tried and then it turned out it did not make much of a
difference.
^ permalink raw reply
* {PATCH] Audit Filter Performance
From: Steve Grubb @ 2006-04-08 20:46 UTC (permalink / raw)
To: linux-audit, aviro
Hi,
While testing the watch performance, I noticed that selinux_task_ctxid() was
creeping into the results more than it should. Investigation showed that the
function call was being called whether it was needed or not. The below patch
fixes this.
Signed-off-by: Steve Grubb
diff -ur linux-2.6.16.x86_64.orig/kernel/auditsc.c linux-2.6.16.x86_64/kernel/auditsc.c
--- linux-2.6.16.x86_64.orig/kernel/auditsc.c 2006-04-08 16:28:16.000000000 -0400
+++ linux-2.6.16.x86_64/kernel/auditsc.c 2006-04-08 16:33:33.000000000 -0400
@@ -190,9 +190,6 @@
enum audit_state *state)
{
int i, j;
- u32 sid;
-
- selinux_task_ctxid(tsk, &sid);
for (i = 0; i < rule->field_count; i++) {
struct audit_field *f = &rule->fields[i];
@@ -295,11 +292,15 @@
match for now to avoid losing information that
may be wanted. An error message will also be
logged upon error */
- if (f->se_rule)
+ if (f->se_rule) {
+ u32 sid;
+
+ selinux_task_ctxid(tsk, &sid);
result = selinux_audit_rule_match(sid, f->type,
f->op,
f->se_rule,
ctx);
+ }
break;
case AUDIT_ARG0:
case AUDIT_ARG1:
^ permalink raw reply
* Re: How to create independent branches
From: Junio C Hamano @ 2006-04-08 20:49 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <20060408180244.GA4807@xp.machine.de>
Peter Baumann <peter.baumann@gmail.com> writes:
> Another question. I'd like to create a totaly independent branch (like
> the "todo" branch in git). Is there a more user friendly way than doing
>
> git-checkout -b todo
> rm .git/refs/heads/todo
> rm .git/index
> rm <all_files_in_your_workdir>
>
> ... hack hack hack ...
> git-commit -a
>
> I looked all over the docs, but can't find anything obvious.
My "todo" branch is not even part of my main git repository. I
just have two independent repositories (git and todo) locally,
and push into the same public repository.
^ permalink raw reply
* [LARTC] iproute v2.6.15 20060110 kernel 2.4.31-gentoo-r1 ip route
From: Andrew Lyon @ 2006-04-08 20:49 UTC (permalink / raw)
To: lartc
I am using policy based routing and I have 3 route tables setup, ADSLLink1,
ADSLLink2, and ADSLLoadBalanced, "ip route show <table>" will show me the
routes that I have added to the first two, but not from ADSLLoadBalanced, it
will show the last route that was added to the table but no others.
There are approx 16 routes added to the table, I know they are there because
they work, I cannot add them again, and I can delete them (but not delete
them again without adding them).
It did work with 4 routes added to the table I seem to recall, but I cannot
test that again as the machine is in use and rather important.
Where does iproute ip read the routes from? Is there a proc entry that I can
read to check if the kernel is exposing them or if the fault lies in
iproute?
Thanks
Andy
Ignore this text, it disables our lame email disclaimer from being appended
to this email: JOSEDV001TAG ;)
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: strange behavior when pulling updates / get uptodate with git.git
From: Junio C Hamano @ 2006-04-08 20:55 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <4438158C.1080208@iaglans.de>
Nicolas Vilz 'niv' <niv@iaglans.de> writes:
> URL: git://git.kernel.org/pub/scm/git/git.git
> Pull: refs/heads/master:refs/heads/origin
> Pull: refs/heads/todo:refs/heads/todo
> Pull: refs/heads/maint:refs/heads/maint
> Pull: refs/heads/pu:refs/heads/pu
> Pull: refs/heads/man:refs/heads/man
> Pull: refs/heads/next:refs/heads/next
> Pull: refs/heads/html:refs/heads/html
>
> so i suppose, if i try to pull origin, and i am in master, i should be
> able to pull these remote heads each in the correct local head...
>
> But I obviously don't.
Most likely it is aborted by the "pu" branch not
fast-forwarding.
Pull: +refs/heads/pu:refs/heads/pu
or dropping "pu" altogether if you are not interested in it,
would help. My repositories (the ones I fetch/pull from for
testing) have only these:
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: refs/heads/master:refs/heads/origin
Pull: refs/heads/next:refs/heads/next
Pull: +refs/heads/pu:refs/heads/pu
Pull: refs/heads/maint:refs/heads/maint
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.