* RE: [PATCH RFC] SELinux support for DCCP
From: Joshua Brindle @ 2006-11-11 17:49 UTC (permalink / raw)
To: James Morris; +Cc: Arnaldo Carvalho de Melo, Stephen Smalley, dccp, selinux
In-Reply-To: <XMMS.LNX.4.64.0611111246360.29096@d.namei>
> From: James Morris [mailto:jmorris@namei.org]
>
> On Sat, 11 Nov 2006, Joshua Brindle wrote:
>
> > James Morris wrote:
> > > The kernel patch is included below, please review.
> > >
> > > Signed-off-by: James Morris <jmorris@namei.org>
> > > +#define CONTEXT__TRANSLATE 0x00000001UL
> > > +#define CONTEXT__CONTAINS 0x00000002UL
> > > + S_(SECCLASS_CONTEXT, CONTEXT__TRANSLATE, "translate")
> > > + S_(SECCLASS_CONTEXT, CONTEXT__CONTAINS, "contains")
> > > + S_("context")
> > > +#define SECCLASS_CONTEXT 59
> > >
> >
> > oops?
>
> What?
>
Did you mean to include context classes as part of the dccp patch?
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* RE: [PATCH RFC] SELinux support for DCCP
From: Joshua Brindle @ 2006-11-11 17:49 UTC (permalink / raw)
To: dccp
In-Reply-To: <XMMS.LNX.4.64.0611110203540.25507@d.namei>
> From: James Morris [mailto:jmorris@namei.org]
>
> On Sat, 11 Nov 2006, Joshua Brindle wrote:
>
> > James Morris wrote:
> > > The kernel patch is included below, please review.
> > >
> > > Signed-off-by: James Morris <jmorris@namei.org>
> > > +#define CONTEXT__TRANSLATE 0x00000001UL
> > > +#define CONTEXT__CONTAINS 0x00000002UL
> > > + S_(SECCLASS_CONTEXT, CONTEXT__TRANSLATE, "translate")
> > > + S_(SECCLASS_CONTEXT, CONTEXT__CONTAINS, "contains")
> > > + S_("context")
> > > +#define SECCLASS_CONTEXT 59
> > >
> >
> > oops?
>
> What?
>
Did you mean to include context classes as part of the dccp patch?
^ permalink raw reply
* Re: [PATCH RFC] SELinux support for DCCP
From: James Morris @ 2006-11-11 17:47 UTC (permalink / raw)
To: dccp
In-Reply-To: <XMMS.LNX.4.64.0611110203540.25507@d.namei>
On Sat, 11 Nov 2006, Joshua Brindle wrote:
> James Morris wrote:
> > The kernel patch is included below, please review.
> >
> > Signed-off-by: James Morris <jmorris@namei.org>
> > +#define CONTEXT__TRANSLATE 0x00000001UL
> > +#define CONTEXT__CONTAINS 0x00000002UL
> > + S_(SECCLASS_CONTEXT, CONTEXT__TRANSLATE, "translate")
> > + S_(SECCLASS_CONTEXT, CONTEXT__CONTAINS, "contains")
> > + S_("context")
> > +#define SECCLASS_CONTEXT 59
> >
>
> oops?
What?
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH RFC] SELinux support for DCCP
From: James Morris @ 2006-11-11 17:47 UTC (permalink / raw)
To: Joshua Brindle; +Cc: Arnaldo Carvalho de Melo, Stephen Smalley, dccp, selinux
In-Reply-To: <4555F2B1.6050003@tresys.com>
On Sat, 11 Nov 2006, Joshua Brindle wrote:
> James Morris wrote:
> > The kernel patch is included below, please review.
> >
> > Signed-off-by: James Morris <jmorris@namei.org>
> > +#define CONTEXT__TRANSLATE 0x00000001UL
> > +#define CONTEXT__CONTAINS 0x00000002UL
> > + S_(SECCLASS_CONTEXT, CONTEXT__TRANSLATE, "translate")
> > + S_(SECCLASS_CONTEXT, CONTEXT__CONTAINS, "contains")
> > + S_("context")
> > +#define SECCLASS_CONTEXT 59
> >
>
> oops?
What?
--
James Morris
<jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [PATCH RFC] SELinux support for DCCP
From: James Morris @ 2006-11-11 17:46 UTC (permalink / raw)
To: dccp
In-Reply-To: <XMMS.LNX.4.64.0611110203540.25507@d.namei>
On Sat, 11 Nov 2006, Eric Paris wrote:
> > +#define SECCLASS_CONTEXT 59
> > +#define SECCLASS_DCCP_SOCKET 60
>
>
> What are the SECCLASS_CONTEXT, CONTEXT__CONTAINS, and CONTEXT__TRANSLATE
> changes?
The kernel headers have to match the userspace headers. This context
stuff is from userland.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH RFC] SELinux support for DCCP
From: James Morris @ 2006-11-11 17:46 UTC (permalink / raw)
To: Eric Paris; +Cc: Arnaldo Carvalho de Melo, Stephen Smalley, dccp, selinux
In-Reply-To: <1163259994.12271.17.camel@localhost.localdomain>
On Sat, 11 Nov 2006, Eric Paris wrote:
> > +#define SECCLASS_CONTEXT 59
> > +#define SECCLASS_DCCP_SOCKET 60
>
>
> What are the SECCLASS_CONTEXT, CONTEXT__CONTAINS, and CONTEXT__TRANSLATE
> changes?
The kernel headers have to match the userspace headers. This context
stuff is from userland.
--
James Morris
<jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: gitk feature request..
From: Petr Baudis @ 2006-11-11 17:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git, Pierre Marc Dumuid
In-Reply-To: <7vslgu28do.fsf@assigned-by-dhcp.cox.net>
On Tue, Nov 07, 2006 at 11:34:59PM CET, Junio C Hamano wrote:
> Paul Mackerras <paulus@samba.org> writes:
>
> > Good idea. Junio, is there a canonical place under .git where gitk
> > should put such things?
>
> Well, we do not design things in advance but tend to let things
> evolve, which probably is a bad habit but I am not sure how else
> we can avoid overdesigning before knowing the needs.
>
> The existing state-keeping programs seem to keep their stuff
> immediately under $GIT_DIR. Examples are:
>
> .git/description (gitweb)
> .git/cvs-authors (cvsimport)
> .git/gitcvs.<branch>.sqlite (cvsserver)
>
> So, .git/gitk-<foo> (or .git/gitk/<bar>) would be in line with
> others. We _might_ want to have a standard plan to keep
> Porcelains stepping on each other's toes, and probably migrating
> everybody to .git/aux/{common,gitcvs,gitk,...}/<foo> would be a
> sane thing to do. description and cvs-authors could probably be
> shared across Porcelains, so I do not think we mind leaving them
> in the current place or throw them in .git/aux/common/
I think the porcelains tend to use pretty specific names for their stuff
and a risk of conflict is pretty small, so I don't think it's worth the
compatibility problems. Also, over time it's bound that qgit will
something like start to peek and poke at some gitk stuff and learn about
CVS imports so it'll peek at gitcvs as well, etc., so I'm not sure if
the net benefit would really be that large or rather give the porcelains
a false illusion of safety and privacy.
Except for cg-merge which is quite a pig when it comes to its state and
.git files; I guess it should use a .git/cg-merge-state/ directory
instead. And the hooks space where cg sort of hoped that git would reuse
its hooks names but it didn't play out.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* [take24 7/6] kevent: signal notifications.
From: Evgeniy Polyakov @ 2006-11-11 17:36 UTC (permalink / raw)
To: David Miller
Cc: David Miller, Ulrich Drepper, Andrew Morton, netdev, Zach Brown,
Christoph Hellwig, Chase Venters, Johann Borck, linux-kernel,
Jeff Garzik
In-Reply-To: <11630606361046@2ka.mipt.ru>
Signals which were requested to be delivered through kevent
subsystem must be registered through usual signal() and others
syscalls, this option allows alternative delivery.
With KEVENT_SIGNAL_NOMASK flag being set in kevent for set of
signals, they will not be delivered in a usual way.
Kevents for appropriate signals are not copied when process forks,
new process must add new kevents after fork(). Mask of signals
is copied as before.
Test application which registers two signal callbacks for usr1 and usr2
signals and it's deivery through kevent (the former with both callback and
kevent notifications, the latter only through kevent) is called signal.c
and can be found in archive on project homepage
http://tservice.net.ru/~s0mbre/old/?section=projects&item=kevent
Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
diff --git a/include/linux/kevent.h b/include/linux/kevent.h
index f7cbf6b..e588ae6 100644
--- a/include/linux/kevent.h
+++ b/include/linux/kevent.h
@@ -28,6 +28,7 @@ #include <linux/wait.h>
#include <linux/net.h>
#include <linux/rcupdate.h>
#include <linux/fs.h>
+#include <linux/sched.h>
#include <linux/kevent_storage.h>
#include <linux/ukevent.h>
@@ -220,4 +221,10 @@ #else
static inline void kevent_pipe_notify(struct inode *inode, u32 events) {}
#endif
+#ifdef CONFIG_KEVENT_SIGNAL
+extern int kevent_signal_notify(struct task_struct *tsk, int sig);
+#else
+static inline int kevent_signal_notify(struct task_struct *tsk, int sig) {return 0;}
+#endif
+
#endif /* __KEVENT_H */
diff --git a/include/linux/sched.h b/include/linux/sched.h
index fc4a987..ef38a3c 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -80,6 +80,7 @@ #include <linux/param.h>
#include <linux/resource.h>
#include <linux/timer.h>
#include <linux/hrtimer.h>
+#include <linux/kevent_storage.h>
#include <asm/processor.h>
@@ -1013,6 +1014,10 @@ #endif
#ifdef CONFIG_TASK_DELAY_ACCT
struct task_delay_info *delays;
#endif
+#ifdef CONFIG_KEVENT_SIGNAL
+ struct kevent_storage st;
+ u32 kevent_signals;
+#endif
};
static inline pid_t process_group(struct task_struct *tsk)
diff --git a/include/linux/ukevent.h b/include/linux/ukevent.h
index b14e14e..a6038eb 100644
--- a/include/linux/ukevent.h
+++ b/include/linux/ukevent.h
@@ -68,7 +68,8 @@ #define KEVENT_POLL 3
#define KEVENT_NAIO 4
#define KEVENT_AIO 5
#define KEVENT_PIPE 6
-#define KEVENT_MAX 7
+#define KEVENT_SIGNAL 7
+#define KEVENT_MAX 8
/*
* Per-type event sets.
@@ -81,7 +82,7 @@ #define KEVENT_MAX 7
#define KEVENT_TIMER_FIRED 0x1
/*
- * Socket/network asynchronous IO events.
+ * Socket/network asynchronous IO and PIPE events.
*/
#define KEVENT_SOCKET_RECV 0x1
#define KEVENT_SOCKET_ACCEPT 0x2
@@ -115,10 +116,20 @@ #define KEVENT_POLL_POLLREMOVE 0x1000
*/
#define KEVENT_AIO_BIO 0x1
-#define KEVENT_MASK_ALL 0xffffffff
+/*
+ * Signal events.
+ */
+#define KEVENT_SIGNAL_DELIVERY 0x1
+
+/* If set in raw64, then given signals will not be delivered
+ * in a usual way through sigmask update and signal callback
+ * invokation. */
+#define KEVENT_SIGNAL_NOMASK 0x8000000000000000ULL
+
/* Mask of all possible event values. */
-#define KEVENT_MASK_EMPTY 0x0
+#define KEVENT_MASK_ALL 0xffffffff
/* Empty mask of ready events. */
+#define KEVENT_MASK_EMPTY 0x0
struct kevent_id
{
diff --git a/kernel/fork.c b/kernel/fork.c
index 1c999f3..e5b5b14 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -46,6 +46,7 @@ #include <linux/cn_proc.h>
#include <linux/delayacct.h>
#include <linux/taskstats_kern.h>
#include <linux/random.h>
+#include <linux/kevent.h>
#include <asm/pgtable.h>
#include <asm/pgalloc.h>
@@ -115,6 +116,9 @@ void __put_task_struct(struct task_struc
WARN_ON(atomic_read(&tsk->usage));
WARN_ON(tsk == current);
+#ifdef CONFIG_KEVENT_SIGNAL
+ kevent_storage_fini(&tsk->st);
+#endif
security_task_free(tsk);
free_uid(tsk->user);
put_group_info(tsk->group_info);
@@ -1121,6 +1125,10 @@ #endif
if (retval)
goto bad_fork_cleanup_namespace;
+#ifdef CONFIG_KEVENT_SIGNAL
+ kevent_storage_init(p, &p->st);
+#endif
+
p->set_child_tid = (clone_flags & CLONE_CHILD_SETTID) ? child_tidptr : NULL;
/*
* Clear TID on mm_release()?
diff --git a/kernel/kevent/Kconfig b/kernel/kevent/Kconfig
index 267fc53..4b137ee 100644
--- a/kernel/kevent/Kconfig
+++ b/kernel/kevent/Kconfig
@@ -43,3 +43,18 @@ config KEVENT_PIPE
help
This option enables notifications through KEVENT subsystem of
pipe read/write operations.
+
+config KEVENT_SIGNAL
+ bool "Kernel event notifications for signals"
+ depends on KEVENT
+ help
+ This option enables signal delivery through KEVENT subsystem.
+ Signals which were requested to be delivered through kevent
+ subsystem must be registered through usual signal() and others
+ syscalls, this option allows alternative delivery.
+ With KEVENT_SIGNAL_NOMASK flag being set in kevent for set of
+ signals, they will not be delivered in a usual way.
+ Kevents for appropriate signals are not copied when process forks,
+ new process must add new kevents after fork(). Mask of signals
+ is copied as before.
+
diff --git a/kernel/kevent/Makefile b/kernel/kevent/Makefile
index d4d6b68..f98e0c8 100644
--- a/kernel/kevent/Makefile
+++ b/kernel/kevent/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_KEVENT_TIMER) += kevent_tim
obj-$(CONFIG_KEVENT_POLL) += kevent_poll.o
obj-$(CONFIG_KEVENT_SOCKET) += kevent_socket.o
obj-$(CONFIG_KEVENT_PIPE) += kevent_pipe.o
+obj-$(CONFIG_KEVENT_SIGNAL) += kevent_signal.o
diff --git a/kernel/kevent/kevent_signal.c b/kernel/kevent/kevent_signal.c
new file mode 100644
index 0000000..15f9d1f
--- /dev/null
+++ b/kernel/kevent/kevent_signal.c
@@ -0,0 +1,87 @@
+/*
+ * kevent_signal.c
+ *
+ * 2006 Copyright (c) Evgeniy Polyakov <johnpol@2ka.mipt.ru>
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/file.h>
+#include <linux/fs.h>
+#include <linux/kevent.h>
+
+static int kevent_signal_callback(struct kevent *k)
+{
+ struct task_struct *tsk = k->st->origin;
+ int sig = k->event.id.raw[0];
+ int ret = 0;
+
+ if (sig == tsk->kevent_signals)
+ ret = 1;
+
+ if (ret && (k->event.id.raw_u64 & KEVENT_SIGNAL_NOMASK))
+ tsk->kevent_signals |= 0x80000000;
+
+ return ret;
+}
+
+int kevent_signal_enqueue(struct kevent *k)
+{
+ int err;
+
+ err = kevent_storage_enqueue(¤t->st, k);
+ if (err)
+ goto err_out_exit;
+
+ err = k->callbacks.callback(k);
+ if (err)
+ goto err_out_dequeue;
+
+ return err;
+
+err_out_dequeue:
+ kevent_storage_dequeue(k->st, k);
+err_out_exit:
+ return err;
+}
+
+int kevent_signal_dequeue(struct kevent *k)
+{
+ kevent_storage_dequeue(k->st, k);
+ return 0;
+}
+
+int kevent_signal_notify(struct task_struct *tsk, int sig)
+{
+ tsk->kevent_signals = sig;
+ kevent_storage_ready(&tsk->st, NULL, KEVENT_SIGNAL_DELIVERY);
+ return (tsk->kevent_signals & 0x80000000);
+}
+
+static int __init kevent_init_signal(void)
+{
+ struct kevent_callbacks sc = {
+ .callback = &kevent_signal_callback,
+ .enqueue = &kevent_signal_enqueue,
+ .dequeue = &kevent_signal_dequeue};
+
+ return kevent_add_callbacks(&sc, KEVENT_SIGNAL);
+}
+module_init(kevent_init_signal);
diff --git a/kernel/signal.c b/kernel/signal.c
index fb5da6d..d3d3594 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -23,6 +23,7 @@ #include <linux/syscalls.h>
#include <linux/ptrace.h>
#include <linux/signal.h>
#include <linux/capability.h>
+#include <linux/kevent.h>
#include <asm/param.h>
#include <asm/uaccess.h>
#include <asm/unistd.h>
@@ -703,6 +704,9 @@ static int send_signal(int sig, struct s
{
struct sigqueue * q = NULL;
int ret = 0;
+
+ if (kevent_signal_notify(t, sig))
+ return 1;
/*
* fast-pathed signals for kernel-internal things like SIGSTOP
@@ -782,6 +786,17 @@ specific_send_sig_info(int sig, struct s
ret = send_signal(sig, info, t, &t->pending);
if (!ret && !sigismember(&t->blocked, sig))
signal_wake_up(t, sig == SIGKILL);
+#ifdef CONFIG_KEVENT_SIGNAL
+ /*
+ * Kevent allows to deliver signals through kevent queue,
+ * it is possible to setup kevent to not deliver
+ * signal through the usual way, in that case send_signal()
+ * returns 1 and signal is delivered only through kevent queue.
+ * We simulate successfull delivery notification through this hack:
+ */
+ if (ret == 1)
+ ret = 0;
+#endif
out:
return ret;
}
@@ -971,6 +986,17 @@ __group_send_sig_info(int sig, struct si
* to avoid several races.
*/
ret = send_signal(sig, info, p, &p->signal->shared_pending);
+#ifdef CONFIG_KEVENT_SIGNAL
+ /*
+ * Kevent allows to deliver signals through kevent queue,
+ * it is possible to setup kevent to not deliver
+ * signal through the usual way, in that case send_signal()
+ * returns 1 and signal is delivered only through kevent queue.
+ * We simulate successfull delivery notification through this hack:
+ */
+ if (ret == 1)
+ ret = 0;
+#endif
if (unlikely(ret))
return ret;
--
Evgeniy Polyakov
^ permalink raw reply related
* Re: [Xenomai-core] [PATCH] Doxygen hyperlinking utilitiy and demo programs
From: Gilles Chanteperdrix @ 2006-11-11 17:28 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: xenomai-core
In-Reply-To: <4554636C.4070704@domain.hid>
Wolfgang Grandegger wrote:
> Hello,
>
> the attached patch adds the RT-Socket-CAN utility programs as examples
> to the Doxygen documentation setup. This creates some nice cross
> reference from the documented API functions to the example code lines
> and vice versa. In a similar way, the Xenomai demo programs and code
> snippets could be integrated making it much easier to find example code
> or the description of an API function used in an example.
>
> Please have a look and comment?
This is a good idea. The native skin snippets were created with
the same idea in mind, it looks like I somehow forgot to finish the
work.
Now, about your patch, will not this hunk break some things ?
> # EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
> # certain files from those directories.
>
> -EXCLUDE_PATTERNS =
> +EXCLUDE_PATTERNS = "*.c"
--
Gilles Chanteperdrix.
^ permalink raw reply
* [PATCH] ACPI remove unused variable and fix a compile time warning
From: Burman Yan @ 2006-11-11 17:27 UTC (permalink / raw)
To: trivial; +Cc: len.brown, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 301 bytes --]
Hi.
This patch removes an unused variable and a warning that it generates.
Regards
Yan Burman
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
[-- Attachment #2: acpi_events_remove_unsed.patch --]
[-- Type: application/octet-stream, Size: 488 bytes --]
Remove unused variable that generates a compile time warning
Signed-off-by: Yan Burman <yan_952@hotmail.com>
--- linux-2.6.19-rc5_orig/drivers/acpi/events/evmisc.c 2006-11-09 12:16:21.000000000 +0200
+++ linux-2.6.19-rc5/drivers/acpi/events/evmisc.c 2006-11-11 00:11:22.000000000 +0200
@@ -331,7 +331,6 @@ static void ACPI_SYSTEM_XFACE acpi_ev_gl
static u32 acpi_ev_global_lock_handler(void *context)
{
u8 acquired = FALSE;
- acpi_status status;
/*
* Attempt to get the lock
^ permalink raw reply
* [U-Boot-Users] how to and a new component such as super io chip in u-boot?
From: Wolfgang Denk @ 2006-11-11 17:25 UTC (permalink / raw)
To: u-boot
In-Reply-To: <45557505.0000C1.09810@bj163app95.163.com>
In message <45557505.0000C1.09810@bj163app95.163.com> you wrote:
>
> I am a newbie to u-boot and i need to use a super io chip w83977 from winbond to add more uart to my board using a s3c2410 ,so how to add the component to u-boot so I can test the addtional uart port in booting stage?
Write a driver for it.
And please make sure to adhere to the Netiquette - restrict your line
length to 70 chars max. And please read
http://www.catb.org/%7eesr/faqs/smart-questions.html
> --Boundary-=_OGaKGcOSgOAnfXYStpCOxyLHHuxb
> Content-Type: text/html; charset="gb2312"
> Content-Transfer-Encoding: quoted-printable
And NEVER EVER post HTML on this list!!!
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Hegel was right when he said that we learn from history that man can
never learn anything from history. - George Bernard Shaw
^ permalink raw reply
* Re: OOM in 2.6.19-rc*
From: Benoit Boissinot @ 2006-11-11 17:23 UTC (permalink / raw)
To: Christian Kujau; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.64.0611111318230.1247@sheep.housecafe.de>
On 11/11/06, Christian Kujau <evil@g-house.de> wrote:
> Hello,
>
> a few days ago I upgraded my desktop machine (x86_64) to ubuntu/edgy
> thus completely changing the userland. Since I'm using kernel.org
> kernels I upgraded to a current kernel as well (2.6.19-rc4-git from Nov
> 4 and 2.6.19-rc4-mm2). Now, while working under X11, probably reading
> email, all of a sudden the machine was not responsible any more and the
> disk was spinning like wild. The desktop applet showed all swap being
> used up then the display froze too and ~5 min later the machine came
> back with the gnome-login screen: it had not rebooted but ran OOM and
> several apps got killed.
>
Just a thought, do you have a swap activated ? (there is a bug in edgy
where the swap isn't mounted)
regards,
Benoit
^ permalink raw reply
* Re: [Xenomai-core] [PATCH] Missing include when compiling an ipiped Linux kernel with CONFIG_PREEMPT for ARM
From: Philippe Gerum @ 2006-11-11 17:21 UTC (permalink / raw)
To: Sebastian Smolorz; +Cc: xenomai-core
In-Reply-To: <E1GiUTz-00027a-G9@domain.hid>
On Fri, 2006-11-10 at 12:23 +0100, Sebastian Smolorz wrote:
> Hi,
>
> here comes a fix for I-pipe for ARM. Without it the kernel refuses to compile
> when configured with CONFIG_PREEMPT.
Applied, thanks.
>
> Sebastian
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
^ permalink raw reply
* Re: [PATCH] remove unused filp from ioctl functions
From: Eric Sandeen @ 2006-11-11 17:12 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs
In-Reply-To: <20061111105627.GB3356@infradead.org>
Christoph Hellwig wrote:
> On Fri, Nov 10, 2006 at 09:28:59PM -0600, Eric Sandeen wrote:
>> There's a stuct file * passed around the ioctl code that is never
>> used... just takes up precious stack space near as I can tell :)
>
> While you're at it kill the inode paramater anyway, it can be retrieved
> from the vnode by trivial address arithmetics.
Hadn't noticed, let me look into that.
-Eric
^ permalink raw reply
* Proper patch posting question
From: Burman Yan @ 2006-11-11 17:12 UTC (permalink / raw)
To: linux-kernel
Hi.
I made a patch that replaces kmalloc+memset with kzalloc. The changes are in
many
different places in the kernel, but most of them are trivial. The whole
patch is about
360Kb. The less trivial parts that make more changes than just replacing
kmalloc with
kzalloc and removing the memset are in different patches that I will send to
the proper
maintainers.
My question is what would be the right way to post the trivial changes?
The way I see, I have a few options:
1) Post the entire patch on lkml
2) Split the patch into subsystems and post the smaller parts on lkml
3) Send the patch to trivial@kernel.org
Thank you in advance
Yan Burman
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
^ permalink raw reply
* Re: patchs commits
From: Tony Lindgren @ 2006-11-11 17:02 UTC (permalink / raw)
To: David Brownell; +Cc: Linux-omap-open-source
In-Reply-To: <200611101905.19713.david-b@pacbell.net>
* David Brownell <david-b@pacbell.net> [061111 05:05]:
> On Friday 10 November 2006 4:13 pm, Tony Lindgren wrote:
> > * David Brownell <david-b@pacbell.net> [061110 03:18]:
> > > > > Do you know if the USB OHCI and Gadget are functional for the OMAP2420 H4?
> > > >
> > > > I think after Kyungmin's and Dave's patches it may be close to working
> > > > in linux-omap tree :)
> > >
> > > Well, here's the missing "add H4 USB support" patch ... with one
> > > glitch, "doesn't work yet".
> > >
> > > ...
> >
> > Pushing. (And assuming you'll push the USB changes upstream eventually
> > via your USB channels)
>
> Stuff in drivers/usb (and the isp1301 driver) will eventually go
> upstream that way ... stuff in arch/arm should IMO be stuff you hand
> off through Russell.
OK, I'll split that patch accordingly for Russell.
Tony
^ permalink raw reply
* OOM in 2.6.19-rc*
From: Christian Kujau @ 2006-11-11 16:40 UTC (permalink / raw)
To: linux-kernel
Hello,
a few days ago I upgraded my desktop machine (x86_64) to ubuntu/edgy
thus completely changing the userland. Since I'm using kernel.org
kernels I upgraded to a current kernel as well (2.6.19-rc4-git from Nov
4 and 2.6.19-rc4-mm2). Now, while working under X11, probably reading
email, all of a sudden the machine was not responsible any more and the
disk was spinning like wild. The desktop applet showed all swap being
used up then the display froze too and ~5 min later the machine came
back with the gnome-login screen: it had not rebooted but ran OOM and
several apps got killed.
OK, must be some application leaking memory, I thought, that's what
happens to new userland version. Looking at the syslog, "nautilus"
(gnome filemanager) invoked the oom killer. OK, but the scenario
repeated the next day, early in the morning when I was not even on the
box, saying it was nautilus again.
In the last days other applications seem to invoke the OOM killer as
well and I wonder if each one of them is really to blame for leaking
memory or something else would be responsible for the killings. Here's
log output, each listing the first appliction triggering the OOM killer:
# for i in /var/log/messages*; do (zgrep "invoked" "$i" | head -1 ); done
Nov 11 08:04:16 prinz64 kernel: [104237.902269] firefox-bin invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
Nov 10 07:59:34 prinz64 kernel: [64627.382818] Xorg invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
Nov 9 07:59:22 prinz64 kernel: [25047.487534] rpc.idmapd invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=-17
Nov 8 17:33:59 prinz64 kernel: [ 919.954547] beep-media-play invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
Nov 7 18:55:23 prinz64 kernel: [ 842.590646] firefox-bin invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
Nov 5 07:55:34 prinz64 kernel: [18128.545690] nautilus invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
Nov 4 17:31:23 prinz64 kernel: [ 688.904652] nautilus invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
The kernels running when these were happening:
Nov 4 - 2.6.19-rc2
Nov 5 - 2.6.19-rc2
Nov 7 - 2.6.19-rc4-mm2
Nov 8 - 2.6.19-rc4
Nov 9 - 2.6.19-rc4
Nov 10 - 2.6.19-rc4
Nov 11 - 2.6.19-rc4
Because killing these application does not seem to free up memory,
plenty of other applications got killed shortly after this. Full logs
and .config can be found here: http://nerdbynature.de/bits/2.6.19-rc4/
I do notice anacron running just before the killings - but: even *if*
anacron runs a mem-leaking program: should the OOM killer just kill that
app and not the (probably) innocent ones in the first place?
Thanks for your thoughts,
Christian.
--
BOFH excuse #194:
We only support a 1200 bps connection.
^ permalink raw reply
* Re: 2.6.19-rc3 system freezes when ripping with cdparanoia at ioctl(SG_IO)
From: Douglas Gilbert @ 2006-11-11 16:39 UTC (permalink / raw)
To: Christoph Hellwig, Luben Tuikov, Tejun Heo, Brice Goglin,
Jens Axboe, Gregor Jasny, Linux Kernel, Jeff Garzik, linux-ide,
monty, linux-scsi
In-Reply-To: <20061111104642.GA3356@infradead.org>
Christoph Hellwig wrote:
> On Fri, Nov 10, 2006 at 12:08:15PM -0800, Luben Tuikov wrote:
>> P.S. I'd love to see SG_DXFER_TO_FROM_DEV completely ripped out
>> of sg.c, for obvious reasons. Can you not duplicate the resid "fix"
>> it provides into "FROM_DEV" -- do apps really rely on it?
>
> At the beginning of this thread it was mentioned cdparanio uses it.
> But in general we can't just rip out userland interfaces, we pretend
> to have a stable userspace abi (and except for the big sysfs mess that
> actually comes very close to the truth).
>
> What we should do is to document very well what SG_DXFER_TO_FROM_DEV
> is doing and that odd name that's been chosen for it. I'll prepare
> a patch for that.
Christoph,
It is documented and has been from day one. See scsi/sg.h
and http://sg.torque.net/sg/p/sg_v3_ho.html
Naming it is a challenge and at the time there
were no bidirectional transfers to/from a device
to worry about.
A more appropriate but impractical name might be:
SG_DXFER_TO_KERNEL_BUFFER_THEN_READ_FROM_DEV_VIA_KERNEL_BUFFER
Doug Gilbert
^ permalink raw reply
* Re: unexplainable read errors, copy/diff-issue
From: Christoph Anton Mitterer @ 2006-11-11 16:35 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: linux-kernel
In-Reply-To: <20061110135649.16cccca0.vsu@altlinux.ru>
Sergey Vlasov wrote:
>> http://marc.theaimsgroup.com/?t=116291314500001&r=1&w=2
>>
>>
>
> So you have 4GB RAM, and most likely some memory is remapped above the
> 4GB address boundary.
Uhm don't know,.. I'm running an amd64 kernel and I've always thought
there is no such boundaray.
But yes I have 4 GB.
> Could you show the full dmesg output after boot?
>
Yes I will but you'll have to wait until monday or tuesday. I'm
currently visiting my parents and have no access to my main PC :(
> Other things you can try:
>
> - Boot with mem=3072M (or some larger value which is still less than
> the amount of RAM below the 4GB boundary - the exact value could be
> found from the dmesg output) and check whether you can reproduce the
> corruption in this configuration.
>
I'll do that as soon as I'm at home.
> - Look in the BIOS setup for memory remapping options (Google indicates
> that it may be called "Hammer Configuration/Memory Hole Mapping" on
> this board). Maybe you need to try different values (AFAIR there
> were some complaints about unstabilities with software remapping;
> cannot find the exact page now).
>
I think I have correctly set these settings up.
As far as I can remember:
The Memhole Mapping was set to Hardware.
The IOMMU is enabled and the IOMMU memory was set to 64MB (I "found
this out" because for all values less than 64MB (i.e. 32) the Linux
kernel complained.
Some other things that I remember now from my exhaustive testing:
-The error also occurred directly after a reboot (thus the file cache
was empty) when running a script that went through all my test files and
verified them with their sha512 sums.
- I once did the following,.. suddenly after diff found a difference I
Ctrl-C'ed and copied the files to another location.
In this case the files were probably used from the cache, thus the error
was really stored on disk.
I used vbindiff (hex differ) and seen that, in the differing range, not
just all bytes were different,.. but some were ok, than some were
different again,.. and so on.
So, at least in that case, it was not one whole range that was totally
wrong, but only part of the bytes.
- Another thing... perhaps this was only by chance but:
When I did sha512 sums or diffs,.. the errors were always found in the
files I copied.... not in the original files. Of course diff could not
say me that (because it doesn't tell which files are original) but
sha512sum could.
This is very strange because:
My first big tests were:
1) The original by Exact Audio Copy under Windows created files on my
PATA disc in a FAT32 partition
- compared with -
a) copies from that files to another place on the FAT32 partition
b) copies from that files to an ext3 partition on one of the SATA discs.
=> There one could imagine that the failure would be done in the copying
(which is impossible or unlikely,.. because then the differences should
be always in the same file(s).
2) I copied the files from FAT32 to ext3 again,.. and then copied the
whole stuff from ext3 to another location on the ext3 partition.
The error happens here, too.
And I think it's very strange the even for test 2 the differences seemed
to be always in the most recent copy.
Perhaps this was only fortune.
- I tried the whole thing under Windows (installed GNU diff tools there).
Copied the files and started the diff.
Until I had to abort (because my parents came to get me...) there have
been found no differences.
Anyway I'm not sure if this says so much:
First of all,.. the diff is very very very slow in Windows (many times
slower than in Linux),.. any I have all DMA/Busmaster/etc drivers
installed in Windows.
Because of this I was not able to complete at least one whole diff over
all the files, thus it would still be possible that errors have occurred.
The Windows task manager (if I interpret his data right) told me that
diff has read about 20GB of data.... which mean it would have diffed
about 10GB of the files (so only one third).
Another thing that I wonder about:
The Task Manager shows me somewhere something like System Cache: 2,1 GB
(about).
As the EAC project was the first time for me to use Windows since
Windows 95 or so.... I'm not sure what that means and if it is the same
as the Linux file cache.
If so:
Linux seems to use all "free" memory for caching files but Windows would
use only about the half of my memory.
Perhaps that could be a reason if the error would not occur under
Windows (btw: I'm going to make several complete tests in Windows Monday
or Tuesday when I'm back in Munich). Just imagin if there would be an
hardware error in that unused 2GB.
I'm not sure enough about the internal Linux memory management to tell
if that may be a reason for the error. I could imagine that Linux reads
data first into the unused (cache) sections of mainmemory and copies it
from there to the virtual memory (which is actually physical memory too)
of the diff process.
Thus if there would be an error in my memory (although memtest86+ did
not, until now, tell me of an error) it could be possible that Windows
never use that memory regions, and thus the diff under windows won't get
any corrupted data, too.
You understand what I mean?
btw: Can someone tell me if it's possible to instruct windows to use the
whole memory as file cache? (And if so how ;-) )
My further tests (as I'm currently intend to do) are:
-Severall copy/diffs under windows
-An even longer memtest86+
-Using some Knoppix or so, to see if the error is related to my
Distribution, my custom kernel or something like that.
-The kernel options Sergey suggested me to try
-Everything else some of you would suggest me :)
Thanks and best wishes,
Chris.
^ permalink raw reply
* Re: information for a 60-minute "intro to git" needed
From: Randal L. Schwartz @ 2006-11-11 16:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ej4teo$bjo$1@sea.gmane.org>
This is all great. Thank you. And I hope to have a presentation
worthy of placing on that page within a week.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: [Xenomai-core] [PATCH] Xenomai configuration help for Linux 2.4
From: Philippe Gerum @ 2006-11-11 16:34 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: xenomai-core
In-Reply-To: <4555C56B.3070205@domain.hid>
On Sat, 2006-11-11 at 13:43 +0100, Wolfgang Grandegger wrote:
> Hello,
>
> the attached patch adds Xenomai configuration help for Linux 2.4:
>
> 2006-11-11 Wolfgang Grandegger <wg@domain.hid>
>
> * scripts/prepare_kernel.sh, scripts/help_from_kconfig.pl:
> prepare_kernel.sh will now add help for Xenomai configuration
> parameters to the Configure.help file of 2.4 kernels. The help
> is extracted from Xenomai's Kconfig files using a perl script.
>
Nice. Applied, thanks.
> Wolfgang.
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
^ permalink raw reply
* Re: [Xenomai-help] timer-handling adeos/xenomai on arm
From: Gilles Chanteperdrix @ 2006-11-11 16:31 UTC (permalink / raw)
To: Sebastian Smolorz; +Cc: xenomai
In-Reply-To: <200611111533.51160.Sebastian.Smolorz@domain.hid>
Sebastian Smolorz wrote:
> Sebastian Smolorz wrote:
> > Gilles Chanteperdrix wrote:
> > > Schlägl "Manfred jun." wrote:
> > > > Hi again!
> > > >
> > > > I've the presumption, there is something wrong with my timer-handling.
> > > > Could you please take a look at my handling.
> > > >
> > > > Thanks in advance!
> > >
> > > The problem I see with your code is that you are updating
> > > ns_timer_lxlost in __ipipe_mach_acktimer, the integrator architecture
> > > code, which also uses a decrementer does not do that. Apart from that, I
> > > see nothing wrong.
> >
> > I see another one which has to do with the fact that __ipipe_mach_tsc is
> > updated both in __ipipe_mach_get_tsc and __ipipe_mach_set_dec. This leads
> > to double-added ticks because the latter funcion is called only once a
> > period and the former even more than once. So Xenomai counts jiffies
> > in /proc/xenomai/timer to fast. Manfred, can you confirm this?
>
> Forget this, my eyes weren't open this morning ... In __ipipe_mach_get_tsc
> there is no update of __ipipe_mach_tsc, of course.
Right, but __ipipe_mach_tsc and ns_timer_lxlost get also updated in
__ipipe_mach_acktimer, this looks wrong, in the integrator
implementation, they are updated in the timer interrupt, only if the
timer is not stolen.
--
Gilles Chanteperdrix.
^ permalink raw reply
* Re: [TRIVIAL PATCH] Added information about Technisat Sky2Pc cards - take 3
From: Paolo Ciarrocchi @ 2006-11-11 16:31 UTC (permalink / raw)
To: Arjan van de Ven
Cc: mchehab, v4l-dvb-maintainer, video4linux-list,
Linux Kernel Mailing List, Adrian Bunk
In-Reply-To: <1163262465.3293.40.camel@laptopd505.fenrus.org>
On 11/11/06, Arjan van de Ven <arjan@infradead.org> wrote:
> On Sat, 2006-11-11 at 17:19 +0100, Paolo Ciarrocchi wrote:
> > Hi all,
> > This is the third time I submit the below patch (first sent on the
> > 29th of October), I'm adding lkml and Adrian since this is really
> > trivial.
>
> hi
Hi Arjan,
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/dvb/cards.txt b/Documentation/dvb/cards.txt
> > index ca58e33..cc09187 100644
> > --- a/Documentation/dvb/cards.txt
> > +++ b/Documentation/dvb/cards.txt
> > @@ -22,10 +22,10 @@ o Frontends drivers:
> > - ves1x93 : Alps BSRV2 (ves1893 demodulator) and dbox2 (ves1993)
> > - cx24110 : Conexant HM1221/HM1811 (cx24110 or cx24106
> > demod, cx24108 PLL)
> > - grundig_29504-491 : Grundig 29504-491 (Philips TDA8083
> > demodulator), tsa5522 PLL
> > - - mt312 : Zarlink mt312 or Mitel vp310 demodulator,
>
> Hi,
>
>
> your patch has gotten line-wrapped, so it's not possible to apply it
> using the patch command ;(
>
> you may need to resend it as an attachment to get it not damaged ;(
>
Sure, will do that as soon as I can access to the box running linux and git.
Thanks!
Regards,
--
Paolo
http://docs.google.com/View?docid=dhbdhs7d_4hsxqc8
http://www.linkedin.com/pub/0/132/9a3
^ permalink raw reply
* Re: [Xenomai-help] Xenomai Kernel limits
From: Philippe Gerum @ 2006-11-11 16:28 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Xenomai
In-Reply-To: <1163175259.5765.174.camel@domain.hid>
On Fri, 2006-11-10 at 17:14 +0100, Philippe Gerum wrote:
> On Fri, 2006-11-10 at 15:44 +0100, Jan Kiszka wrote:
> > Daniel Schnell wrote:
> > > Hi Jan,
> > >
> > >
> > > jan.kiszka@domain.hid wrote:
> > >> Maybe that bug is a symptom of some other scalability issue.
> > >
> > > I suppose so, too.
> > >
> > >>> +++
> > >>> bash-2.05b# cat /proc/heap
> > >>> size=131072:used=134400:pagesz=512
> > >>> +++
> > >>>
> > >>> This looks odd. Either the output is misleading or we have used more
> > >>> resources than possible. But then I would expect that the Xenomai
> > >>> initialization routines (e.g. pthread_create(), rt_dev_open(), etc.)
> > >>> should return with an error. Either should be fixed, I suppose.
> > >> Every services that allocates memory from the real-time heap should
> > >> fail now. If it doesn't (pthread_create is a good test candidate
> > >> here), we "only" face a statistics bug. Can you confirm that starting
> > >> further applications only increases the used counter but otherwise
> > >> works?
> > >
> > > I was running the cyclictest and the switchbench without problems at the
> > > same time and the /proc/xenomai/heap showed even a usage of 135 kBytes.
> > > So I assume that is a statistics bug.
> >
> > ...or some overwritten memory: The block size is encoded in each heap
> > chunk. Looks to me like we do not check for its sanity with a magic
> > number or so, do we? Would be a nice debug feature. Someone around who's
> > bored (rhetoric question)?
> >
>
> The block size is encoded in the pagemap area, idle blocks carry forward
> links into the free list for a given page. If we go down the way adding
> redzones to detect overwrites, I'm afraid that we would have to add them
> all over the place, since trashing the pagemap means that the entire
> heap is basically dead in the water.
>
> Regarding the size/used inconsistency from /proc/xenomai/heap, I would
> also rather suspect that xnheap::ubytes is being miscomputed, rather
> than trashed. E.g. there could be some mismatch/misuse in
> xnheap_alloc/xnheap_free, between block sizes implicitely derived from
> the log2 value found in the pagemap entries, and the sizes computed for
> blocks larger than 2 * page_size. In any case, I already see a bug there
> for allocation requests greater than 2 * page_size, but that would have
> the opposite effect than the current issue (i.e. leakage in used bytes
> accounting):
>
> --- ksrc/nucleus/heap.c (revision 1809)
> +++ ksrc/nucleus/heap.c (working copy)
> @@ -468,7 +468,7 @@
> block = get_free_range(heap, size, 0);
>
> if (block)
> - heap->ubytes += size;
> + heap->ubytes += xnheap_align(size, heap->pagesize);
> }
>
> release_and_exit:
>
> [...]
>
False alarm. This patch is useless since the requested size is already
rounded to the page size.
--
Philippe.
^ permalink raw reply
* Re: [TRIVIAL PATCH] Added information about Technisat Sky2Pc cards - take 3
From: Arjan van de Ven @ 2006-11-11 16:27 UTC (permalink / raw)
To: Paolo Ciarrocchi
Cc: mchehab, v4l-dvb-maintainer, video4linux-list,
Linux Kernel Mailing List, Adrian Bunk
In-Reply-To: <4d8e3fd30611110819r7e4dc941od93b9eb1220f2992@mail.gmail.com>
On Sat, 2006-11-11 at 17:19 +0100, Paolo Ciarrocchi wrote:
> Hi all,
> This is the third time I submit the below patch (first sent on the
> 29th of October), I'm adding lkml and Adrian since this is really
> trivial.
hi
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/dvb/cards.txt b/Documentation/dvb/cards.txt
> index ca58e33..cc09187 100644
> --- a/Documentation/dvb/cards.txt
> +++ b/Documentation/dvb/cards.txt
> @@ -22,10 +22,10 @@ o Frontends drivers:
> - ves1x93 : Alps BSRV2 (ves1893 demodulator) and dbox2 (ves1993)
> - cx24110 : Conexant HM1221/HM1811 (cx24110 or cx24106
> demod, cx24108 PLL)
> - grundig_29504-491 : Grundig 29504-491 (Philips TDA8083
> demodulator), tsa5522 PLL
> - - mt312 : Zarlink mt312 or Mitel vp310 demodulator,
Hi,
your patch has gotten line-wrapped, so it's not possible to apply it
using the patch command ;(
you may need to resend it as an attachment to get it not damaged ;(
Greetings,
Arjan van de Ven
^ 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.