All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 3/6] m68k: simplify the singlestepping handling in signals
From: Al Viro @ 2010-10-07 17:09 UTC (permalink / raw)
  To: linux-m68k; +Cc: linux-kernel


Instead of checking the return value of do_signal() we can just do
the work (raise SIGTRAP and clear SR.T1) directly in handle_signal(),
when setting the sigframe up.  Simplifies the assembler glue and is
closer to the way we do it on other targets.

Note that do_delayed_trace does *not* disappear; it's still needed
to deal with single-stepping through syscall, since 68040 doesn't
raise the trace exception at all if the trap exception is pending.
We hit it after returning from sys_...() if TIF_DELAYED_TRACE is
set; all that has changed is that we don't reuse it for "single-step
into the handler" codepath.

As the result, do_signal() doesn't need to return anything anymore.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
 arch/m68k/kernel/entry.S  |    6 +-----
 arch/m68k/kernel/signal.c |   11 +++++++----
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/m68k/kernel/entry.S b/arch/m68k/kernel/entry.S
index 3a15a03..4e49f57 100644
--- a/arch/m68k/kernel/entry.S
+++ b/arch/m68k/kernel/entry.S
@@ -178,11 +178,7 @@ do_signal_return:
 	addql	#4,%sp
 	RESTORE_SWITCH_STACK
 	addql	#4,%sp
-	tstl	%d0
-	jeq	resume_userspace
-	| when single stepping into handler stop at the first insn
-	btst	#6,%curptr@(TASK_INFO+TINFO_FLAGS+2)
-	jeq	resume_userspace
+	jbra	resume_userspace
 
 do_delayed_trace:
 	bclr	#7,%sp@(PT_OFF_SR)	| clear trace bit in SR
diff --git a/arch/m68k/kernel/signal.c b/arch/m68k/kernel/signal.c
index fa8200d..a18b251 100644
--- a/arch/m68k/kernel/signal.c
+++ b/arch/m68k/kernel/signal.c
@@ -978,6 +978,11 @@ handle_signal(int sig, struct k_sigaction *ka, siginfo_t *info,
 	if (!(ka->sa.sa_flags & SA_NODEFER))
 		sigaddset(&current->blocked,sig);
 	recalc_sigpending();
+
+	if (test_thread_flag(TIF_DELAYED_TRACE)) {
+		regs->sr &= ~0x8000;
+		send_sig(SIGTRAP, current, 1);
+	}
 }
 
 /*
@@ -985,7 +990,7 @@ handle_signal(int sig, struct k_sigaction *ka, siginfo_t *info,
  * want to handle. Thus you cannot kill init even with a SIGKILL even by
  * mistake.
  */
-asmlinkage int do_signal(struct pt_regs *regs)
+asmlinkage void do_signal(struct pt_regs *regs)
 {
 	siginfo_t info;
 	struct k_sigaction ka;
@@ -1004,7 +1009,7 @@ asmlinkage int do_signal(struct pt_regs *regs)
 		/* Whee!  Actually deliver the signal.  */
 		handle_signal(signr, &ka, &info, oldset, regs);
 		clear_thread_flag(TIF_RESTORE_SIGMASK);
-		return 1;
+		return;
 	}
 
 	/* Did we come from a system call? */
@@ -1017,6 +1022,4 @@ asmlinkage int do_signal(struct pt_regs *regs)
 		clear_thread_flag(TIF_RESTORE_SIGMASK);
 		sigprocmask(SIG_SETMASK, &current->saved_sigmask, NULL);
 	}
-
-	return 0;
 }
-- 
1.5.6.5

^ permalink raw reply related

* [PATCH] jffs2: Reduce excessive scan of empty blocks
From: Joakim Tjernlund @ 2010-10-07 17:09 UTC (permalink / raw)
  To: linux-mtd; +Cc: Joakim Tjernlund

Scanning 1024 bytes to see if an EB is empty is a bit much.
Lower it to 256 bytes and make sure the while loop is
optimized.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
 fs/jffs2/scan.c |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/fs/jffs2/scan.c b/fs/jffs2/scan.c
index 3131860..4657918 100644
--- a/fs/jffs2/scan.c
+++ b/fs/jffs2/scan.c
@@ -20,7 +20,7 @@
 #include "summary.h"
 #include "debug.h"
 
-#define DEFAULT_EMPTY_SCAN_SIZE 1024
+#define DEFAULT_EMPTY_SCAN_SIZE 256
 
 #define noisy_printk(noise, args...) do { \
 	if (*(noise)) { \
@@ -435,7 +435,7 @@ static int jffs2_scan_eraseblock (struct jffs2_sb_info *c, struct jffs2_eraseblo
 				  unsigned char *buf, uint32_t buf_size, struct jffs2_summary *s) {
 	struct jffs2_unknown_node *node;
 	struct jffs2_unknown_node crcnode;
-	uint32_t ofs, prevofs;
+	uint32_t ofs, prevofs, max_ofs;
 	uint32_t hdr_crc, buf_ofs, buf_len;
 	int err;
 	int noise = 0;
@@ -550,12 +550,12 @@ static int jffs2_scan_eraseblock (struct jffs2_sb_info *c, struct jffs2_eraseblo
 
 	/* We temporarily use 'ofs' as a pointer into the buffer/jeb */
 	ofs = 0;
-
-	/* Scan only 4KiB of 0xFF before declaring it's empty */
-	while(ofs < EMPTY_SCAN_SIZE(c->sector_size) && *(uint32_t *)(&buf[ofs]) == 0xFFFFFFFF)
+	max_ofs = EMPTY_SCAN_SIZE(c->sector_size);
+	/* Scan only EMPTY_SCAN_SIZE of 0xFF before declaring it's empty */
+	while(ofs < max_ofs && *(uint32_t *)(&buf[ofs]) == 0xFFFFFFFF)
 		ofs += 4;
 
-	if (ofs == EMPTY_SCAN_SIZE(c->sector_size)) {
+	if (ofs == max_ofs) {
 #ifdef CONFIG_JFFS2_FS_WRITEBUFFER
 		if (jffs2_cleanmarker_oob(c)) {
 			/* scan oob, take care of cleanmarker */
-- 
1.7.2.2

^ permalink raw reply related

* [refpolicy] [ patch 25/44] shutdown: search parent.
From: Christopher J. PeBenito @ 2010-10-07 17:09 UTC (permalink / raw)
  To: refpolicy
In-Reply-To: <1286216636-28449-27-git-send-email-domg472@gmail.com>

On 10/04/10 14:23, Dominick Grift wrote:
>
> Signed-off-by: Dominick Grift<domg472@gmail.com>

Merged.

> :100644 100644 d2c068d... 300d741... M	policy/modules/admin/shutdown.if
>   policy/modules/admin/shutdown.if |    1 +
>   1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/policy/modules/admin/shutdown.if b/policy/modules/admin/shutdown.if
> index d2c068d..300d741 100644
> --- a/policy/modules/admin/shutdown.if
> +++ b/policy/modules/admin/shutdown.if
> @@ -15,6 +15,7 @@ interface(`shutdown_domtrans',`
>   		type shutdown_t, shutdown_exec_t;
>   	')
>
> +	corecmd_search_bin($1)
>   	domtrans_pattern($1, shutdown_exec_t, shutdown_t)
>
>   	ifdef(`hide_broken_symptoms', `


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

^ permalink raw reply

* [PATCH 2/6] m68k: switch to saner sigsuspend()
From: Al Viro @ 2010-10-07 17:09 UTC (permalink / raw)
  To: linux-m68k; +Cc: linux-kernel


and saner do_signal() arguments, while we are at it

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
 arch/m68k/include/asm/thread_info_mm.h |    1 +
 arch/m68k/include/asm/unistd.h         |    1 +
 arch/m68k/kernel/entry.S               |   19 +---------
 arch/m68k/kernel/signal.c              |   64 ++++++++++---------------------
 4 files changed, 24 insertions(+), 61 deletions(-)

diff --git a/arch/m68k/include/asm/thread_info_mm.h b/arch/m68k/include/asm/thread_info_mm.h
index 3bf31dc..b2ea8be 100644
--- a/arch/m68k/include/asm/thread_info_mm.h
+++ b/arch/m68k/include/asm/thread_info_mm.h
@@ -67,5 +67,6 @@ struct thread_info {
 #define TIF_SYSCALL_TRACE	15	/* syscall trace active */
 #define TIF_MEMDIE		16	/* is terminating due to OOM killer */
 #define TIF_FREEZE		17	/* thread is freezing for suspend */
+#define TIF_RESTORE_SIGMASK	18	/* restore signal mask in do_signal */
 
 #endif	/* _ASM_M68K_THREAD_INFO_H */
diff --git a/arch/m68k/include/asm/unistd.h b/arch/m68k/include/asm/unistd.h
index b43b36b..26d851d 100644
--- a/arch/m68k/include/asm/unistd.h
+++ b/arch/m68k/include/asm/unistd.h
@@ -373,6 +373,7 @@
 #define __ARCH_WANT_SYS_SIGPENDING
 #define __ARCH_WANT_SYS_SIGPROCMASK
 #define __ARCH_WANT_SYS_RT_SIGACTION
+#define __ARCH_WANT_SYS_RT_SIGSUSPEND
 
 /*
  * "Conditional" syscalls
diff --git a/arch/m68k/kernel/entry.S b/arch/m68k/kernel/entry.S
index 6360c43..3a15a03 100644
--- a/arch/m68k/kernel/entry.S
+++ b/arch/m68k/kernel/entry.S
@@ -174,9 +174,8 @@ do_signal_return:
 	subql	#4,%sp			| dummy return address
 	SAVE_SWITCH_STACK
 	pea	%sp@(SWITCH_STACK_SIZE)
-	clrl	%sp@-
 	bsrl	do_signal
-	addql	#8,%sp
+	addql	#4,%sp
 	RESTORE_SWITCH_STACK
 	addql	#4,%sp
 	tstl	%d0
@@ -290,22 +289,6 @@ ENTRY(sys_vfork)
 	RESTORE_SWITCH_STACK
 	rts
 
-ENTRY(sys_sigsuspend)
-	SAVE_SWITCH_STACK
-	pea	%sp@(SWITCH_STACK_SIZE)
-	jbsr	do_sigsuspend
-	addql	#4,%sp
-	RESTORE_SWITCH_STACK
-	rts
-
-ENTRY(sys_rt_sigsuspend)
-	SAVE_SWITCH_STACK
-	pea	%sp@(SWITCH_STACK_SIZE)
-	jbsr	do_rt_sigsuspend
-	addql	#4,%sp
-	RESTORE_SWITCH_STACK
-	rts
-
 ENTRY(sys_sigreturn)
 	SAVE_SWITCH_STACK
 	jbsr	do_sigreturn
diff --git a/arch/m68k/kernel/signal.c b/arch/m68k/kernel/signal.c
index c776c81..fa8200d 100644
--- a/arch/m68k/kernel/signal.c
+++ b/arch/m68k/kernel/signal.c
@@ -51,8 +51,6 @@
 
 #define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP)))
 
-asmlinkage int do_signal(sigset_t *oldset, struct pt_regs *regs);
-
 const int frame_extra_sizes[16] = {
   [1]	= -1, /* sizeof(((struct frame *)0)->un.fmt1), */
   [2]	= sizeof(((struct frame *)0)->un.fmt2),
@@ -74,51 +72,21 @@ const int frame_extra_sizes[16] = {
 /*
  * Atomically swap in the new signal mask, and wait for a signal.
  */
-asmlinkage int do_sigsuspend(struct pt_regs *regs)
+asmlinkage int
+sys_sigsuspend(int unused0, int unused1, old_sigset_t mask)
 {
-	old_sigset_t mask = regs->d3;
-	sigset_t saveset;
-
 	mask &= _BLOCKABLE;
-	saveset = current->blocked;
+	spin_lock_irq(&current->sighand->siglock);
+	current->saved_sigmask = current->blocked;
 	siginitset(&current->blocked, mask);
 	recalc_sigpending();
+	spin_unlock_irq(&current->sighand->siglock);
 
-	regs->d0 = -EINTR;
-	while (1) {
-		current->state = TASK_INTERRUPTIBLE;
-		schedule();
-		if (do_signal(&saveset, regs))
-			return -EINTR;
-	}
-}
-
-asmlinkage int
-do_rt_sigsuspend(struct pt_regs *regs)
-{
-	sigset_t __user *unewset = (sigset_t __user *)regs->d1;
-	size_t sigsetsize = (size_t)regs->d2;
-	sigset_t saveset, newset;
-
-	/* XXX: Don't preclude handling different sized sigset_t's.  */
-	if (sigsetsize != sizeof(sigset_t))
-		return -EINVAL;
-
-	if (copy_from_user(&newset, unewset, sizeof(newset)))
-		return -EFAULT;
-	sigdelsetmask(&newset, ~_BLOCKABLE);
-
-	saveset = current->blocked;
-	current->blocked = newset;
-	recalc_sigpending();
+	current->state = TASK_INTERRUPTIBLE;
+	schedule();
+	set_restore_sigmask();
 
-	regs->d0 = -EINTR;
-	while (1) {
-		current->state = TASK_INTERRUPTIBLE;
-		schedule();
-		if (do_signal(&saveset, regs))
-			return -EINTR;
-	}
+	return -ERESTARTNOHAND;
 }
 
 asmlinkage int
@@ -1017,21 +985,25 @@ handle_signal(int sig, struct k_sigaction *ka, siginfo_t *info,
  * want to handle. Thus you cannot kill init even with a SIGKILL even by
  * mistake.
  */
-asmlinkage int do_signal(sigset_t *oldset, struct pt_regs *regs)
+asmlinkage int do_signal(struct pt_regs *regs)
 {
 	siginfo_t info;
 	struct k_sigaction ka;
 	int signr;
+	sigset_t *oldset;
 
 	current->thread.esp0 = (unsigned long) regs;
 
-	if (!oldset)
+	if (test_thread_flag(TIF_RESTORE_SIGMASK))
+		oldset = &current->saved_sigmask;
+	else
 		oldset = &current->blocked;
 
 	signr = get_signal_to_deliver(&info, &ka, regs, NULL);
 	if (signr > 0) {
 		/* Whee!  Actually deliver the signal.  */
 		handle_signal(signr, &ka, &info, oldset, regs);
+		clear_thread_flag(TIF_RESTORE_SIGMASK);
 		return 1;
 	}
 
@@ -1040,5 +1012,11 @@ asmlinkage int do_signal(sigset_t *oldset, struct pt_regs *regs)
 		/* Restart the system call - no handlers present */
 		handle_restart(regs, NULL, 0);
 
+	/* If there's no signal to deliver, we just restore the saved mask.  */
+	if (test_thread_flag(TIF_RESTORE_SIGMASK)) {
+		clear_thread_flag(TIF_RESTORE_SIGMASK);
+		sigprocmask(SIG_SETMASK, &current->saved_sigmask, NULL);
+	}
+
 	return 0;
 }
-- 
1.5.6.5

^ permalink raw reply related

* [PATCH 1/6] m68k: resetting sa_handler in local copy of k_sigaction is pointless
From: Al Viro @ 2010-10-07 17:09 UTC (permalink / raw)
  To: linux-m68k; +Cc: linux-kernel


... and had been such since the introduction of get_signal_to_deliver()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
 arch/m68k/kernel/signal.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/arch/m68k/kernel/signal.c b/arch/m68k/kernel/signal.c
index 4b38753..c776c81 100644
--- a/arch/m68k/kernel/signal.c
+++ b/arch/m68k/kernel/signal.c
@@ -1006,9 +1006,6 @@ handle_signal(int sig, struct k_sigaction *ka, siginfo_t *info,
 	else
 		setup_frame(sig, ka, oldset, regs);
 
-	if (ka->sa.sa_flags & SA_ONESHOT)
-		ka->sa.sa_handler = SIG_DFL;
-
 	sigorsets(&current->blocked,&current->blocked,&ka->sa.sa_mask);
 	if (!(ka->sa.sa_flags & SA_NODEFER))
 		sigaddset(&current->blocked,sig);
-- 
1.5.6.5

^ permalink raw reply related

* [refpolicy] [ patch 26/44] shutdown: permission sets.
From: Christopher J. PeBenito @ 2010-10-07 17:08 UTC (permalink / raw)
  To: refpolicy
In-Reply-To: <1286216636-28449-28-git-send-email-domg472@gmail.com>

On 10/04/10 14:23, Dominick Grift wrote:
>
> Signed-off-by: Dominick Grift<domg472@gmail.com>

Merged.

> :100644 100644 300d741... b301c61... M	policy/modules/admin/shutdown.if
>   policy/modules/admin/shutdown.if |    2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/policy/modules/admin/shutdown.if b/policy/modules/admin/shutdown.if
> index 300d741..b301c61 100644
> --- a/policy/modules/admin/shutdown.if
> +++ b/policy/modules/admin/shutdown.if
> @@ -64,5 +64,5 @@ interface(`shutdown_getattr_exec_files',`
>   		type shutdown_exec_t;
>   	')
>
> -	allow $1 shutdown_exec_t:file getattr;
> +	allow $1 shutdown_exec_t:file getattr_file_perms;
>   ')


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

^ permalink raw reply

* [refpolicy] [ patch 27/44] shutdown: search parent.
From: Christopher J. PeBenito @ 2010-10-07 17:08 UTC (permalink / raw)
  To: refpolicy
In-Reply-To: <1286216636-28449-29-git-send-email-domg472@gmail.com>

On 10/04/10 14:23, Dominick Grift wrote:
>
> Signed-off-by: Dominick Grift<domg472@gmail.com>

Merged.

> :100644 100644 b301c61... d0604cf... M	policy/modules/admin/shutdown.if
>   policy/modules/admin/shutdown.if |    1 +
>   1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/policy/modules/admin/shutdown.if b/policy/modules/admin/shutdown.if
> index b301c61..d0604cf 100644
> --- a/policy/modules/admin/shutdown.if
> +++ b/policy/modules/admin/shutdown.if
> @@ -64,5 +64,6 @@ interface(`shutdown_getattr_exec_files',`
>   		type shutdown_exec_t;
>   	')
>
> +	corecmd_search_bin($1)
>   	allow $1 shutdown_exec_t:file getattr_file_perms;
>   ')


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

^ permalink raw reply

* [refpolicy] [ patch 28/44] shutdown: for sudo.
From: Christopher J. PeBenito @ 2010-10-07 17:08 UTC (permalink / raw)
  To: refpolicy
In-Reply-To: <1286216636-28449-30-git-send-email-domg472@gmail.com>

On 10/04/10 14:23, Dominick Grift wrote:
>
> Signed-off-by: Dominick Grift<domg472@gmail.com>

Merged.

> :100644 100644 51f7c3a... 7824539... M	policy/modules/admin/shutdown.te
>   policy/modules/admin/shutdown.te |    2 ++
>   1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/policy/modules/admin/shutdown.te b/policy/modules/admin/shutdown.te
> index 51f7c3a..7824539 100644
> --- a/policy/modules/admin/shutdown.te
> +++ b/policy/modules/admin/shutdown.te
> @@ -33,6 +33,8 @@ files_etc_filetrans(shutdown_t, shutdown_etc_t, file)
>   manage_files_pattern(shutdown_t, shutdown_var_run_t, shutdown_var_run_t)
>   files_pid_filetrans(shutdown_t, shutdown_var_run_t, file)
>
> +domain_use_interactive_fds(shutdown_t)
> +
>   files_read_etc_files(shutdown_t)
>   files_read_generic_pids(shutdown_t)
>


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

^ permalink raw reply

* [refpolicy] [ patch 29/44] shutdown: needs to connect to init with a unix stream socket.
From: Christopher J. PeBenito @ 2010-10-07 17:08 UTC (permalink / raw)
  To: refpolicy
In-Reply-To: <1286216636-28449-31-git-send-email-domg472@gmail.com>

On 10/04/10 14:23, Dominick Grift wrote:
>
> Signed-off-by: Dominick Grift<domg472@gmail.com>

Merged.

> :100644 100644 7824539... cf81d13... M	policy/modules/admin/shutdown.te
> :100644 100644 f6aafe7... 8419a01... M	policy/modules/system/init.if
>   policy/modules/admin/shutdown.te |    1 +
>   policy/modules/system/init.if    |   18 ++++++++++++++++++
>   2 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/policy/modules/admin/shutdown.te b/policy/modules/admin/shutdown.te
> index 7824539..cf81d13 100644
> --- a/policy/modules/admin/shutdown.te
> +++ b/policy/modules/admin/shutdown.te
> @@ -45,6 +45,7 @@ auth_write_login_records(shutdown_t)
>
>   init_dontaudit_write_utmp(shutdown_t)
>   init_read_utmp(shutdown_t)
> +init_stream_connect(shutdown_t)
>   init_telinit(shutdown_t)
>
>   logging_send_audit_msgs(shutdown_t)
> diff --git a/policy/modules/system/init.if b/policy/modules/system/init.if
> index f6aafe7..8419a01 100644
> --- a/policy/modules/system/init.if
> +++ b/policy/modules/system/init.if
> @@ -508,6 +508,24 @@ interface(`init_sigchld',`
>
>   ########################################
>   ##<summary>
> +##	Connect to init with a unix socket.
> +##</summary>
> +##<param name="domain">
> +##	<summary>
> +##	Domain allowed access.
> +##	</summary>
> +##</param>
> +#
> +interface(`init_stream_connect',`
> +	gen_require(`
> +		type init_t;
> +	')
> +
> +	allow $1 init_t:unix_stream_socket connectto;
> +')
> +
> +########################################
> +##<summary>
>   ##	Inherit and use file descriptors from init.
>   ##</summary>
>   ##<desc>


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

^ permalink raw reply

* Re: [Xenomai-core] Overcoming the "foreign" stack
From: Philippe Gerum @ 2010-10-07 17:08 UTC (permalink / raw)
  To: Jan Kiszka; +Cc: Xenomai core
In-Reply-To: <4CAC3F55.4050007@domain.hid>

On Wed, 2010-10-06 at 11:20 +0200, Jan Kiszka wrote: 
> Am 05.10.2010 16:21, Gilles Chanteperdrix wrote:
> > Jan Kiszka wrote:
> >> Am 05.10.2010 15:50, Gilles Chanteperdrix wrote:
> >>> Jan Kiszka wrote:
> >>>> Am 05.10.2010 15:42, Gilles Chanteperdrix wrote:
> >>>>> Jan Kiszka wrote:
> >>>>>> Am 05.10.2010 15:15, Gilles Chanteperdrix wrote:
> >>>>>>> Jan Kiszka wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> quite a few limitations and complications of using Linux services over
> >>>>>>>> non-Linux domains relate to potentially invalid "current" and
> >>>>>>>> "thread_info". The non-Linux domain could maintain their own kernel
> >>>>>>>> stacks while Linux tend to derive current and thread_info from the stack
> >>>>>>>> pointer. This is not an issue anymore on x86-64 (both states are stored
> >>>>>>>> in per-cpu variables) but other archs (e.g. x86-32 or ARM) still use the
> >>>>>>>> stack and may continue to do so.
> >>>>>>>>
> >>>>>>>> I just looked into this thing again as I'm evaluating ways to exploit
> >>>>>>>> the kernel's tracing framework also under Xenomai. Unfortunately, it
> >>>>>>>> does a lot of fiddling with preempt_count and need_resched, so patching
> >>>>>>>> it for Xenomai use would become a maintenance nightmare.
> >>>>>>>>
> >>>>>>>> An alternative, also for other use cases like kgdb and probably perf, is
> >>>>>>>> to get rid of our dependency on home-grown stacks. I think we are on
> >>>>>>>> that way already as in-kernel skins have been deprecated. The only
> >>>>>>>> remaining user after them will be RTDM driver tasks. But I think those
> >>>>>>>> could simply become in-kernel shadows of kthreads which would bind their
> >>>>>>>> stacks to what Linux provides. Moreover, Xenomai could start updating
> >>>>>>>> "current" and "thread_info" on context switches (unless this already
> >>>>>>>> happens implicitly). That would give us proper contexts for system-level
> >>>>>>>> tracing and profiling.
> >>>>>>>>
> >>>>>>>> My key question is currently if and how much of this could be realized
> >>>>>>>> in 2.6. Could we drop in-kernel skins in that version? If not, what
> >>>>>>>> about disabling them by default, converting RTDM tasks to a
> >>>>>>>> kthread-based approach, and enabling tracing etc. only in that case?
> >>>>>>>> However, this might be a bit fragile unless we can establish
> >>>>>>>> compile-time or run-time requirements negotiation between Adeos and its
> >>>>>>>> users (Xenomai) about the stack model.
> >>>>>>> A stupid question: why not make things the other way around: patch the
> >>>>>>> current and current_thread_info functions to be made I-pipe aware and
> >>>>>>> use an "ipipe_current" pointer to the current thread task_struct. Of
> >>>>>>> course, there are places where the current or current_thread_info macros
> >>>>>>> are implemented in assembly, so it may be not simple as it sounds, but
> >>>>>>> it would allow to keep 128 Kb stacks if we want. This also means that we
> >>>>>>> would have to put a task_struct at the bottom of every Xenomai task.
> >>>>>> First of all, overhead vs. maintenance. Either every access to
> >>>>>> preempt_count() would require a check for the current domain and its
> >>>>>> foreign stack flag, or I would have to patch dozens (if that is enough)
> >>>>>> of code sites in the tracer framework.
> >>>>> No. I mean we would dereference a pointer named ipipe_current. That is
> >>>>> all, no other check. This pointer would be maintained elsewhere. And we
> >>>>> modify the "current" macro, like:
> >>>>>
> >>>>> #ifdef CONFIG_IPIPE
> >>>>> extern struct task_struct *ipipe_current;
> >>>>> #define current ipipe_current
> >>>>> #endif
> >>>>>
> >>>>> Any calll site gets modified automatically. Or current_thread_info, if
> >>>>> it is current_thread_info which is obtained using the stack pointer mask
> >>>>> trick.
> >>>> The stack pointer mask trick only works with fixed-sized stacks, not a
> >>>> guaranteed property of in-kernel Xenomai threads.
> >>> Precisely the reason why I propose to replace it with a global variable
> >>> reference, or a per-cpu variable for SMP systems.
> >>
> >> Then why is Linux not using this in favor of the stack pointer approach
> >> on, say, ARM?
> >>
> >> For sure, we can patch all Adeos-supported archs away from stack-based
> >> to per-cpu current & thread_info, but I don't feel comfortable with this
> >> in some way invasive approach as well. Well, maybe it's just my personal
> >> misperception.
> > 
> > It is as much invasive as modifying local_irq_save/local_irq_restore.
> > The real question about the global pointer approach, is, if it so much
> > less efficient, how does Xenomai, which uses this scheme, manage to have
> > good performances on ARM?
> 
> Xenomai has no heavily-used preempt_disable/enable that is built on top
> of thread_info. But I also have no numbers on this.
> 
> I looked closer at the kernel dependencies on a fixed stack size.
> Besides current and thread_info, further features that make use of this
> are stack unwinding (boundary checks) and overflow checking. So while we
> can work around the dependency for some tracing requirements, I really
> see no point in heading for this long-term. It just creates more subtle
> patching needs in Adeos, and it also requires work on Xenomai side. I
> really think it's better provide a compatible context to reduce
> maintenance efforts.
> 
> So I played a bit with converting RTDM tasks to in-kernel shadows. It
> works but needs more fine-tuning. My proposal for 2.6 now looks like this:
> 
>  - add mm-less shadow support to the nucleus (changes in
>    xnarch_switch_to and xnshadow_map)
>  - convert RTDM tasks to in-kernel shadows
>  - switch current and thread_info on Xenomai task switches
>  - make in-kernel skins optional, default off
>  - let in-kernel skins dependent on disabled tracing

I agree with your approach of moving to kernel space shadows, this is
the best way to get rid of foreign stacks. Those are a relic of the
kernel-only era, this introduces painful constraints, e.g. in low-level
thread switching code (i.e. so-called "hybrid" scheduling) and other
weirdnesses. This definitely has to go.

I'm on a wait and see stance about generalizing the use of the ftrace
framework for our needs; like Gilles saw with ARM, I must admit that I
did notice a massive overhead on low-end ppc as well when we moved the
pipeline tracer over it. I'm aware of the mcount optimizations that
should be there when cycles really matter, and that ftrace does branch
directly to the trace function when only a single one exists, but this
may not be easy to keep after the generalization has taken place.
Anyway, I'll wait for more data to make my opinion.

However, those changes can't be targeted at 2.6. The rationale for
issuing 2.6 is really about cleaning up some ABI issues and merging
invasive but non-critical infrastructure changes, so that we can
maintain the 2.x series for a long time without being stuck by the ABI
constraints of 2.5.x. Your proposal is clean material for 3.x though,
given that we won't even have to bother with in-kernel skin APIs there.

This said, I understand we need a branch to experiment radical changes
aimed at 3.x, but xenomai-head is no place for that. I have been
tracking -head for some time, doing massive cuts in the code to
eliminate most of the obvious legacy we don't want to care about anymore
(e.g. 2.4 kernel support, in-kernel skin APIs, and a few others). I will
shortly open a new tree on git.xenomai.org called "forge" with that code
base, so that we have the proper playground to get wild with our
chainsaws in the Xenomai core aimed at 3.x.

-- 
Philippe.





^ permalink raw reply

* [refpolicy] [ patch 30/44] shutdown: search generic log directories.
From: Christopher J. PeBenito @ 2010-10-07 17:07 UTC (permalink / raw)
  To: refpolicy
In-Reply-To: <1286216636-28449-32-git-send-email-domg472@gmail.com>

On 10/04/10 14:23, Dominick Grift wrote:
>
> Signed-off-by: Dominick Grift<domg472@gmail.com>

Merged.

> :100644 100644 cf81d13... 97e6b23... M	policy/modules/admin/shutdown.te
>   policy/modules/admin/shutdown.te |    1 +
>   1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/policy/modules/admin/shutdown.te b/policy/modules/admin/shutdown.te
> index cf81d13..97e6b23 100644
> --- a/policy/modules/admin/shutdown.te
> +++ b/policy/modules/admin/shutdown.te
> @@ -48,6 +48,7 @@ init_read_utmp(shutdown_t)
>   init_stream_connect(shutdown_t)
>   init_telinit(shutdown_t)
>
> +logging_search_logs(shutdown_t)
>   logging_send_audit_msgs(shutdown_t)
>
>   miscfiles_read_localization(shutdown_t)


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

^ permalink raw reply

* Re: [RFC PATCH] poll(): add poll_wait_set_exclusive()
From: Mathieu Desnoyers @ 2010-10-07 17:07 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Linus Torvalds, LKML, Andrew Morton, Peter Zijlstra, Ingo Molnar,
	Frederic Weisbecker, Thomas Gleixner, Christoph Hellwig, Li Zefan,
	Lai Jiangshan, Johannes Berg, Masami Hiramatsu,
	Arnaldo Carvalho de Melo, Tom Zanussi, KOSAKI Motohiro,
	Andi Kleen, Paul E. McKenney
In-Reply-To: <1286397096.6661.2.camel@gandalf.stny.rr.com>

* Steven Rostedt (rostedt@goodmis.org) wrote:
> On Wed, 2010-10-06 at 15:04 -0400, Mathieu Desnoyers wrote:
> 
> > For reference, here is the use-case: The user-space daemon runs typically one
> > thread per cpu, each with a handle on many file descriptors. Each thread waits
> > for data to be available using poll(). In order to follow the poll semantic,
> > when data becomes available on a file descriptor, the kernel wakes up all
> > threads at once, but in my case only one of them will successfully consume the
> > data (all other thread's splice or read will fail with -ENODATA). With many
> > threads, these useless wakeups add an unwanted overhead and scalability
> > limitation.
> 
> Mathieu, I'm curious to why you have multiple threads reading the same
> fd. Since the threads are per cpu, does the fd handle all CPUs?

The fd is local to a single ring buffer (which is per-cpu, transporting a group
of events). The threads consuming the file descriptors are approximately per
cpu, modulo cpu hotplug events, user preferences, etc. I would prefer not to
make that a strong 1-1 mapping (with affinity and all), because a typical
tracing scenario is that a single CPU is heavily used by the OS (thus producing
trace data), while other CPUs are idle, available to pull the data from the
buffers. Therefore, I strongly prefer not to affine reader threads to their
"local" buffers in the general case. That being said, it could be kept as an
option, since it might make sense in some other use-cases, especially with tiny
buffers, where it makes sense to keep locality of reference in the L2 cache.

> Or do you have an fd per event per CPU, in which case the threads should just
> poll off of their own fds.

I have one fd per per-cpu buffer, but there can be many per-cpu buffers, each
transporting a group of events. Therefore, I don't want to associate one thread
per event group, because this would be a resource waste.  Typically, only a few
per-cpu buffers will be very active, and others will be very quiet.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

^ permalink raw reply

* Re: [PATCH 3/3] pnfs_submit: enforce requested DS only pNFS role
From: Benny Halevy @ 2010-10-07 17:06 UTC (permalink / raw)
  To: andros; +Cc: linux-nfs
In-Reply-To: <1286480230-9418-3-git-send-email-andros@netapp.com>

On 2010-10-07 15:37, andros@netapp.com wrote:
> From: Andy Adamson <andros@netapp.com>
> 
> Signed-off-by: Andy Adamson <andros@netapp.com>
> ---
>  fs/nfs/nfs4filelayoutdev.c |    5 -----
>  fs/nfs/nfs4state.c         |    5 +++++
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/nfs/nfs4filelayoutdev.c b/fs/nfs/nfs4filelayoutdev.c
> index e0edf93..1f0ab62 100644
> --- a/fs/nfs/nfs4filelayoutdev.c
> +++ b/fs/nfs/nfs4filelayoutdev.c
> @@ -183,11 +183,6 @@ nfs4_pnfs_ds_create(struct nfs_server *mds_srv, struct nfs4_pnfs_ds *ds)
>  		goto out_put;
>  	}
>  	/*
> -	 * Mask the (possibly) returned EXCHGID4_FLAG_USE_PNFS_MDS pNFS role
> -	 * The is_ds_only_session depends on this.
> -	 */
> -	clp->cl_exchange_flags &= ~EXCHGID4_FLAG_USE_PNFS_MDS;
> -	/*
>  	 * Set DS lease equal to the MDS lease, renewal is scheduled in
>  	 * create_session
>  	 */
> diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
> index 91584ad..e2fc175 100644
> --- a/fs/nfs/nfs4state.c
> +++ b/fs/nfs/nfs4state.c
> @@ -188,6 +188,7 @@ static int nfs4_begin_drain_session(struct nfs_client *clp)
>  int nfs41_init_clientid(struct nfs_client *clp, struct rpc_cred *cred)
>  {
>  	int status;
> +	u32 req_exchange_flags = clp->cl_exchange_flags;
>  
>  	nfs4_begin_drain_session(clp);
>  	status = nfs4_proc_exchange_id(clp, cred);
> @@ -196,6 +197,10 @@ int nfs41_init_clientid(struct nfs_client *clp, struct rpc_cred *cred)
>  	status = nfs4_proc_create_session(clp);
>  	if (status != 0)
>  		goto out;
> +	if (is_ds_only_session(req_exchange_flags))
> +		/* Mask the (possibly) returned MDS and non-pNFS roles */

This comment does not really add anything substantial that the code doesn't tell you :)

> +		clp->cl_exchange_flags &=
> +		     ~(EXCHGID4_FLAG_USE_PNFS_MDS | EXCHGID4_FLAG_USE_NON_PNFS);

I'm not why you want to mask out EXCHGID4_FLAG_USE_NON_PNFS.
If the server is not a DS why not just return an error?

Benny

>  	nfs41_setup_state_renewal(clp);
>  	nfs_mark_client_ready(clp, NFS_CS_READY);
>  out:

^ permalink raw reply

* Re: RFC: btusb firmware load help
From: Bala Shanmugam @ 2010-10-07 17:06 UTC (permalink / raw)
  To: Marcel Holtmann
  Cc: Shanmugamkamatchi Balashanmugam, Luis Rodriguez, Johannes Berg,
	linux-bluetooth, linux-kernel@vger.kernel.org,
	linux-wireless@vger.kernel.org, Deepak Dhamdhere, Sree Durbha
In-Reply-To: <1286469741.6145.165.camel@aeonflux>

  On 10/7/2010 10:12 PM, Marcel Holtmann wrote:
> Hi Bala,
>
>>>> Thanks Johannes.  This would be better option to change PID in firmware
>>>> as blacklisting 3002 might create problems for 3011 chipsets.
>>>> Will try and let you people know.
>>> The misbehaving 3002 needs to be blacklisted in btusb.c anyway. However
>>> after loading the firmware to 3002 device, it should change its PID to
>>> something else.
>>>
>>> I am still trying to figure out if this is one stage firmware loading or
>>> a two stage firmware loading. This is all pretty unclear and nobody has
>>> answered this clearly so far.
>> eeprom based 3011 chips comes up with PID 3000 giving control to DFU
>> driver [ath3k].  ath3k downloads the
>> firmware changing PID to 3002.  Now btusb gets control.
>>
>> In sflash based devices to reduce windows suspend/resume time we had a
>> small firmware in flash which
>> enables the device to get detected as Generic Bluetooth USB device with
>> PID 3002.  So control reaches btusb when device is plugged in, leaving
>> no option for us to load the actual firmware.
>>
>> Solution would be to blacklist 3002 in btusb, enable ath3k to get
>> control for both the devices, download the firmware and change PID to
>> 3003 so that control with come to btusb.
> so here is the thing that needs to be done.
>
> a) Get a firmware for PID 3000 devices that change the firmware to some
> other PID. Since 3003 is already in use as well, using 3004 or later is
> better approach.
>
> b) Blacklist PID 3002 in btusb.c.
>
> c) Handle special firmware loading case for PID 3002 sflash devices. If
> firmware is loaded changed to 3005 or other.
>
> And as a general note, I prefer that the PID after loading firmware is
> different if you don't happen to actually load the same firmware.
>
> So please sort out your USB PID assignment for Bluetooth in general.
> This seems to be a mess that is not thought through properly.
>
> Regards
>
> Marcel
>
>
Thanks for your suggestion Marcel.
Can't we have same PID[3004 or later] for both the devices after loading 
the firmware by ath3k?
We need two different firmware if we plan to have two different PIDs for 
these two bluetooth devices.

Regards,
Bala.

^ permalink raw reply

* Re: [PATCH V2] Use firmware provided index to register a network interface
From: Kay Sievers @ 2010-10-07 17:05 UTC (permalink / raw)
  To: Greg KH
  Cc: Matt Domsch, Narendra_K, netdev, linux-hotplug, linux-pci,
	Jordan_Hargrave, Vijay_Nijhawan, Charles_Rose
In-Reply-To: <20101007164835.GA27339@kroah.com>

On Thu, Oct 7, 2010 at 18:48, Greg KH <greg@kroah.com> wrote:
> On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
>> 1) SMBIOS type 41 method.  Windows does not use this today, and I
>>    can't speak to their future plans.  Narendra's kernel patch does,
>>    as has biosdevname, the udev helper we first wrote for this
>>    purpose, for several years.
>
> Then stick with that udev helper please :)

What about just exporting this information in sysfs, and not touch the naming?

Anyway, I'm pretty sure all of this naming of onboard devices should
happen only at install time, or from a system management tool and not
at hotplug time.

We should not get confused by the way the (very simple)
automatic-rule-creater for persistent netdev naming in udev works.
This is really just a tool for the common case, and works fine for the
majority of people.

I'm not sure, if we should put all these special use cases in the
hotplug path. I mean it's not that people add and remove 4 port
network cards with special BIOS all the time, and expect proper naming
on the first bootup, right? The installer, or the system management
tool could just create/edit udev rules to provide proper device naming
on whatever property is available at a specific hardware, be it the
MAC address or some other persistent match?

Kay

^ permalink raw reply

* Re: [PATCH V2] Use firmware provided index to register a network interface
From: Kay Sievers @ 2010-10-07 17:05 UTC (permalink / raw)
  To: Greg KH
  Cc: Matt Domsch, Narendra_K, netdev, linux-hotplug, linux-pci,
	Jordan_Hargrave, Vijay_Nijhawan, Charles_Rose
In-Reply-To: <20101007164835.GA27339@kroah.com>

On Thu, Oct 7, 2010 at 18:48, Greg KH <greg@kroah.com> wrote:
> On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
>> 1) SMBIOS type 41 method.  Windows does not use this today, and I
>>    can't speak to their future plans.  Narendra's kernel patch does,
>>    as has biosdevname, the udev helper we first wrote for this
>>    purpose, for several years.
>
> Then stick with that udev helper please :)

What about just exporting this information in sysfs, and not touch the naming?

Anyway, I'm pretty sure all of this naming of onboard devices should
happen only at install time, or from a system management tool and not
at hotplug time.

We should not get confused by the way the (very simple)
automatic-rule-creater for persistent netdev naming in udev works.
This is really just a tool for the common case, and works fine for the
majority of people.

I'm not sure, if we should put all these special use cases in the
hotplug path. I mean it's not that people add and remove 4 port
network cards with special BIOS all the time, and expect proper naming
on the first bootup, right? The installer, or the system management
tool could just create/edit udev rules to provide proper device naming
on whatever property is available at a specific hardware, be it the
MAC address or some other persistent match?

Kay

^ permalink raw reply

* Re: [PATCH] Skip "rootfs" entry when checking for ext4 filesystem.
From: Eric Sandeen @ 2010-10-07 17:04 UTC (permalink / raw)
  To: ext4 development; +Cc: ravi
In-Reply-To: <4ACE480E.9070508@redhat.com>

On 10/08/2009 03:14 PM, Eric Sandeen wrote:
> Ping on this one?

Ping++

-Eric

> Ravi reported a failure w/o it:
> 
>> Hi,
>>
>> I'm playing with e4defrag from e2frprogs git, and I've run into a bug.
>> When I try to defragment files on my root filesystem, it refuses to
>> acknowledge that the filesystem is ext4. I believe the problem is that
>> it checks the filesystem type by parsing /etc/mtab, but the root
>> filesystem shows up there like this:
>>
>> rootfs on / type rootfs (rw)
>> /dev/root on / type ext4 (rw,noatime,barrier=1,data=ordered)
>>
>> so it gets confused by the bogus first entry. It works just fine on
>> other ext4 filesystems I have.
>>
>> (If this is the wrong mailing list, I apologize; I couldn't find one for
>> e2fsprogs, so I thought this was the next best thing.)
>>
>> --Ravi
> 
> Thanks,
> -Eric
> 
> Eric Sandeen wrote:
>> Skip "rootfs" entry when checking for ext4 filesystem.
>>
>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>> ---
>>
>> diff --git a/misc/e4defrag.c b/misc/e4defrag.c
>> index 82e3868..0d04df9 100644
>> --- a/misc/e4defrag.c
>> +++ b/misc/e4defrag.c
>> @@ -430,6 +430,8 @@ static int is_ext4(const char *file)
>>  	}
>>  
>>  	while ((mnt = getmntent(fp)) != NULL) {
>> +		if (mnt->mnt_fsname[0] != '/')
>> +			continue;
>>  		len = strlen(mnt->mnt_dir);
>>  		ret = memcmp(file_path, mnt->mnt_dir, len);
>>  		if (ret != 0)
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


^ permalink raw reply

* Re: [PATCH v4] i2c: davinci: Fix race when setting up for TX
From: Kevin Hilman @ 2010-10-07 17:01 UTC (permalink / raw)
  To: Ben Dooks, Jon Povey
  Cc: davinci-linux-open-source@linux.davincidsp.com,
	linux-i2c@vger.kernel.org
In-Reply-To: <70E876B0EA86DD4BAF101844BC814DFE093EE3EA57-lPJtnb2sqtq44ywRPIzf9A@public.gmane.org>

Jon Povey <Jon.Povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org> writes:

> Hi Ben,
>
> I am not on the i2c list but noticed this pull request:
> http://www.spinics.net/linux/lists/linux-i2c/msg04022.html
>
> I think you have the wrong (old) version of this patch in that branch,
> http://git.fluff.org/gitweb?p=bjdooks/linux.git;a=commitdiff;h=4bba0fd8d1c6d405df666e2573e1a1f917098be0
>
> The correct v4 one from the start of this thread has more lines
> of patch and this commit message:

It is also available in my davinci-i2c branch:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git davinci-i2c

Thanks Jon for catching this,

Kevin

>>>>>> When setting up to transmit, a race exists between the ISR and
>>>>>> i2c_davinci_xfer_msg() trying to load the first byte and adjust
>>>>>> counters. This is mostly visible for transmits > 1 byte long.
>>>>>>
>>>>>> The hardware starts sending immediately that MDR.STT is set. IMR
>>>>>> trickery doesn't work because if we start sending, finish the
>>>>>> first byte and an XRDY event occurs before we load IMR to unmask
>>>>>> it, we never get an interrupt, and we timeout.
>>>>>>
>>>>>> Sudhakar Rajashekhara explains that at least OMAP-L138 requires
>>>>>> MDR mode settings before DXR for correct behaviour, so load MDR
>>>>>> first with STT cleared and later load again with STT set.
>>>>>>
>>>>>> Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
>>>>>>
>>>>>> Signed-off-by: Jon Povey <jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org>
>>>>>> CC: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
>>>>>> CC: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
>
> It also has some more acks and a tested, via Kevin:
>
>> Acked-by: Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
>> Tested-by: Sudhakar Rajashekhara <sudhakar.raj-l0cyMroinI0@public.gmane.org>
>> Acked-by: Kevin Hilman <khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
>
>
> --
> Jon Povey
> jon.povey-Ean/AyPsLtfkYMGBc/C6ZA@public.gmane.org
>
> Racelogic is a limited company registered in England. Registered number 2743719 .
> Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .
>
> The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network

^ permalink raw reply

* Re: [RFC] tidspbridge: use a parameter to allocate shared memory
From: Omar Ramirez Luna @ 2010-10-07 17:01 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: linux-arm-kernel@lists.infradead.org, Tony Lindgren,
	Ohad Ben-Cohen, Greg Kroah-Hartman, Russell King,
	Gomez Castellanos, Ivan, Felipe Contreras, Ramos Falcon, Ernesto,
	linux-omap@vger.kernel.org, Ameya Palande
In-Reply-To: <201010070940.14208.laurent.pinchart@ideasonboard.com>

On 10/7/2010 2:40 AM, Laurent Pinchart wrote:
> Hi Omar,
>
> On Thursday 07 October 2010 07:45:36 Omar Ramirez Luna wrote:
>> tidspbridge driver uses a block of memory denominated SHared Memory
>> to store info&  communicate with DSP, this SHM needs to be physically
>> contiguous and non-cacheable,
>
> There are non-cacheable mappings, but there's no such thing as non-cacheable
> memory. Does the MPU mapping for that SHM block really needs to be non-
> cacheable,

yes

> your could you instead flush the cache after writing to it
> (performance issues might be involved, I don't know the details about that SHM
> usage) ?

You can do that too, but it will involve more changes to dsp side, and 
yes performance might be an issue too.

The so called "shared memory" is used between arm tidspbridge and the 
DSP, they exchange communication structures/streams/messages/parameters 
needed on both sides for its correct functionality (this is an eagle-eye 
view of the SHM, for more info if interested check page 32 of the 
overview pdf[1]).

tidspbridge could have the changes made for flushing the SHM every time 
it writes into it, a flag could be used to prevent both of them (ARM & 
DSP) flushing at the same time if needed, but I don't know how feasible 
would be making those changes in the dsp code.

Regards,

Omar

---
[1] 
https://gforge.ti.com/gf/download/docmanfileversion/17/674/OMAP3430_Bridge_overview.pdf

^ permalink raw reply

* [RFC] tidspbridge: use a parameter to allocate shared memory
From: Omar Ramirez Luna @ 2010-10-07 17:01 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <201010070940.14208.laurent.pinchart@ideasonboard.com>

On 10/7/2010 2:40 AM, Laurent Pinchart wrote:
> Hi Omar,
>
> On Thursday 07 October 2010 07:45:36 Omar Ramirez Luna wrote:
>> tidspbridge driver uses a block of memory denominated SHared Memory
>> to store info&  communicate with DSP, this SHM needs to be physically
>> contiguous and non-cacheable,
>
> There are non-cacheable mappings, but there's no such thing as non-cacheable
> memory. Does the MPU mapping for that SHM block really needs to be non-
> cacheable,

yes

> your could you instead flush the cache after writing to it
> (performance issues might be involved, I don't know the details about that SHM
> usage) ?

You can do that too, but it will involve more changes to dsp side, and 
yes performance might be an issue too.

The so called "shared memory" is used between arm tidspbridge and the 
DSP, they exchange communication structures/streams/messages/parameters 
needed on both sides for its correct functionality (this is an eagle-eye 
view of the SHM, for more info if interested check page 32 of the 
overview pdf[1]).

tidspbridge could have the changes made for flushing the SHM every time 
it writes into it, a flag could be used to prevent both of them (ARM & 
DSP) flushing at the same time if needed, but I don't know how feasible 
would be making those changes in the dsp code.

Regards,

Omar

---
[1] 
https://gforge.ti.com/gf/download/docmanfileversion/17/674/OMAP3430_Bridge_overview.pdf

^ permalink raw reply

* [U-Boot] [RFC PATCH 1/2 v2] nand: allow delayed initialization
From: Mike Frysinger @ 2010-10-07 17:00 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <20101006204047.D1B691539A0@gemini.denx.de>

On Wednesday, October 06, 2010 16:40:47 Wolfgang Denk wrote:
> I'm not sure where we are with this.
> 
> Do you plan to post an update?

there isnt a clear indication of where to take this.  seems like we want to do 
this, and we want it as the default moving forward, but we want all existing 
boards to be unchanged.  so only reasonable way would be to invert the logic, 
add a define for the arch lib/board.c files, and then add that define to all 
existing boards.

call the new define CONFIG_NAND_EARLY_INIT ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101007/2c929629/attachment.pgp 

^ permalink raw reply

* [xen-4.0-testing test] 2341: regressions - FAIL
From: xen.org @ 2010-10-07 17:00 UTC (permalink / raw)
  To: xen-devel; +Cc: ian.jackson

flight 2341 xen-4.0-testing real
http://www.chiark.greenend.org.uk/~xensrcts/logs/2341/

Regressions :-(

tests which did not succeed:
 build-amd64-oldkern           1 xen-build                  fail REGR. vs. 2200
 test-amd64-amd64-pair       12 guest-migrate/src_host/dst_host fail never pass
 test-amd64-amd64-pv          10 guest-saverestore.2          fail   never pass
 test-amd64-amd64-xl          10 guest-saverestore.2          fail   never pass
 test-amd64-i386-pair         11 guest-start               fail blocked in 2200
 test-amd64-i386-pv            7 guest-start                fail REGR. vs. 2200
 test-amd64-i386-xl            7 guest-start                fail REGR. vs. 2200
 test-amd64-xcpkern-i386-xl   12 guest-stop                   fail   never pass
 test-i386-i386-pair         12 guest-migrate/src_host/dst_host fail never pass
 test-i386-i386-pv             7 guest-start                fail REGR. vs. 2200
 test-i386-i386-xl            10 guest-saverestore.2          fail   never pass
 test-i386-xcpkern-i386-pair  12 guest-migrate/src_host/dst_host fail like 2200
 test-i386-xcpkern-i386-xl    12 guest-stop                   fail   never pass

version targeted for testing:
 xen                  c32e9163328d
baseline version:
 xen                  6e0ffcd2d9e0

jobs:
 build-i386-xcpkern           pass     
 build-amd64                  pass     
 build-i386                   pass     
 build-amd64-oldkern          fail     
 build-i386-oldkern           pass     
 test-amd64-amd64-xl          fail     
 test-amd64-i386-xl           fail     
 test-i386-i386-xl            fail     
 test-amd64-xcpkern-i386-xl   fail     
 test-i386-xcpkern-i386-xl    fail     
 test-amd64-amd64-pair        fail     
 test-amd64-i386-pair         fail     
 test-i386-i386-pair          fail     
 test-amd64-xcpkern-i386-pair pass     
 test-i386-xcpkern-i386-pair  fail     
 test-amd64-amd64-pv          fail     
 test-amd64-i386-pv           fail     
 test-i386-i386-pv            fail     
 test-amd64-xcpkern-i386-pv   pass     
 test-i386-xcpkern-i386-pv    pass     
 test-amd64-amd64-win         pass     
 test-amd64-i386-win          pass     
 test-i386-i386-win           pass     
 test-amd64-xcpkern-i386-win  pass     
 test-i386-xcpkern-i386-win   pass     

-------------------------------------------------------------------------------
build-i386-xcpkern:
 1 kernel-build                 pass     
 linux           110879:32fc6955a6a5
 pq_linux        156:7eea17db9add
-------------------------------------------------------------------------------
build-amd64:
 1 host-install(1)              pass     
 2 host-build-prep              pass     
 3 xen-build                    pass     
 linux           41a85de5caef68bbd58e
 qemu            0a940d892e90c820567c
 xen             21367:c32e9163328d
-------------------------------------------------------------------------------
build-i386:
 1 host-install(1)              pass     
 2 host-build-prep              pass     
 3 xen-build                    pass     
 linux           41a85de5caef68bbd58e
 qemu            0a940d892e90c820567c
 xen             21367:c32e9163328d
-------------------------------------------------------------------------------
build-amd64-oldkern:
 1 xen-build                    fail     
 linux           1041:5dd203fba380
 qemu            0a940d892e90c820567c
 xen             21367:c32e9163328d
-------------------------------------------------------------------------------
build-i386-oldkern:
 1 xen-build                    pass     
 linux           1041:5dd203fba380
 qemu            0a940d892e90c820567c
 xen             21367:c32e9163328d
-------------------------------------------------------------------------------
test-amd64-amd64-xl:
 1 xen-build-check(1)           pass     
 2 host-install(2)              pass     
 3 xen-install                  pass     
 4 xen-boot                     pass     
 5 debian-install               pass     
 6 debian-fixup                 pass     
 7 guest-start                  pass     
 8 guest-saverestore            pass     
 9 guest-localmigrate           pass     
10 guest-saverestore.2          fail     
11 capture-logs(11)             pass     
-------------------------------------------------------------------------------
test-amd64-i386-xl:
 1 xen-build-check(1)           pass     
 2 host-install(2)              pass     
 3 xen-install                  pass     
 4 xen-boot                     pass     
 5 debian-install               pass     
 6 debian-fixup                 pass     
 7 guest-start                  fail     
 8 capture-logs(8)              pass     
-------------------------------------------------------------------------------
test-i386-i386-xl:
 1 xen-build-check(1)           pass     
 2 host-install(2)              pass     
 3 xen-install                  pass     
 4 xen-boot                     pass     
 5 debian-install               pass     
 6 debian-fixup                 pass     
 7 guest-start                  pass     
 8 guest-saverestore            pass     
 9 guest-localmigrate           pass     
10 guest-saverestore.2          fail     
11 capture-logs(11)             pass     
-------------------------------------------------------------------------------
test-amd64-xcpkern-i386-xl:
 1 xen-build-check(1)           pass     
 2 host-install(2)              pass     
 3 xen-install                  pass     
 4 xen-boot                     pass     
 5 debian-install               pass     
 6 debian-fixup                 pass     
 7 guest-start                  pass     
 8 guest-saverestore            pass     
 9 guest-localmigrate           pass     
10 guest-saverestore.2          pass     
11 guest-localmigrate.2         pass     
12 guest-stop                   fail     
13 capture-logs(13)             pass     
-------------------------------------------------------------------------------
test-i386-xcpkern-i386-xl:
 1 xen-build-check(1)           pass     
 2 host-install(2)              pass     
 3 xen-install                  pass     
 4 xen-boot                     pass     
 5 debian-install               pass     
 6 debian-fixup                 pass     
 7 guest-start                  pass     
 8 guest-saverestore            pass     
 9 guest-localmigrate           pass     
10 guest-saverestore.2          pass     
11 guest-localmigrate.2         pass     
12 guest-stop                   fail     
13 capture-logs(13)             pass     
-------------------------------------------------------------------------------
test-amd64-amd64-pair:
 1 xen-build-check(1)           pass     
 2 host-install/src_host(2)     pass     
 3 host-install/dst_host(3)     pass     
 4 xen-install/src_host         pass     
 5 xen-install/dst_host         pass     
 6 xen-boot/src_host            pass     
 7 xen-boot/dst_host            pass     
 8 debian-install/dst_host      pass     
 9 debian-fixup/dst_host        pass     
10 guests-nbd-mirror            pass     
11 guest-start                  pass     
12 guest-migrate/src_host/dst_host fail     
13 capture-logs/src_host(13)    pass     
14 capture-logs/dst_host(14)    pass     
-------------------------------------------------------------------------------
test-amd64-i386-pair:
 1 xen-build-check(1)           pass     
 2 host-install/src_host(2)     pass     
 3 host-install/dst_host(3)     pass     
 4 xen-install/src_host         pass     
 5 xen-install/dst_host         pass     
 6 xen-boot/src_host            pass     
 7 xen-boot/dst_host            pass     
 8 debian-install/dst_host      pass     
 9 debian-fixup/dst_host        pass     
10 guests-nbd-mirror            pass     
11 guest-start                  fail     
12 capture-logs/src_host(12)    pass     
13 capture-logs/dst_host(13)    pass     
-------------------------------------------------------------------------------
test-i386-i386-pair:
 1 xen-build-check(1)           pass     
 2 host-install/src_host(2)     pass     
 3 host-install/dst_host(3)     pass     
 4 xen-install/src_host         pass     
 5 xen-install/dst_host         pass     
 6 xen-boot/src_host            pass     
 7 xen-boot/dst_host            pass     
 8 debian-install/dst_host      pass     
 9 debian-fixup/dst_host        pass     
10 guests-nbd-mirror            pass     
11 guest-start                  pass     
12 guest-migrate/src_host/dst_host fail     
13 capture-logs/src_host(13)    pass     
14 capture-logs/dst_host(14)    pass     
-------------------------------------------------------------------------------
test-amd64-xcpkern-i386-pair:
 1 xen-build-check(1)           pass     
 2 host-install/src_host(2)     pass     
 3 host-install/dst_host(3)     pass     
 4 xen-install/src_host         pass     
 5 xen-install/dst_host         pass     
 6 xen-boot/src_host            pass     
 7 xen-boot/dst_host            pass     
 8 debian-install/dst_host      pass     
 9 debian-fixup/dst_host        pass     
10 guests-nbd-mirror            pass     
11 guest-start                  pass     
12 guest-migrate/src_host/dst_host pass     
13 guest-migrate/dst_host/src_host pass     
14 capture-logs/src_host(14)    pass     
15 capture-logs/dst_host(15)    pass     
-------------------------------------------------------------------------------
test-i386-xcpkern-i386-pair:
 1 xen-build-check(1)           pass     
 2 host-install/src_host(2)     pass     
 3 host-install/dst_host(3)     pass     
 4 xen-install/src_host         pass     
 5 xen-install/dst_host         pass     
 6 xen-boot/src_host            pass     
 7 xen-boot/dst_host            pass     
 8 debian-install/dst_host      pass     
 9 debian-fixup/dst_host        pass     
10 guests-nbd-mirror            pass     
11 guest-start                  pass     
12 guest-migrate/src_host/dst_host fail     
13 capture-logs/src_host(13)    pass     
14 capture-logs/dst_host(14)    pass     
-------------------------------------------------------------------------------
test-amd64-amd64-pv:
 1 xen-build-check(1)           pass     
 2 host-install(2)              pass     
 3 xen-install                  pass     
 4 xen-boot                     pass     
 5 debian-install               pass     
 6 debian-fixup                 pass     
 7 guest-start                  pass     
 8 guest-saverestore            pass     
 9 guest-localmigrate           pass     
10 guest-saverestore.2          fail     
11 capture-logs(11)             pass     
-------------------------------------------------------------------------------
test-amd64-i386-pv:
 1 xen-build-check(1)           pass     
 2 host-install(2)              pass     
 3 xen-install                  pass     
 4 xen-boot                     pass     
 5 debian-install               pass     
 6 debian-fixup                 pass     
 7 guest-start                  fail     
 8 capture-logs(8)              pass     
-------------------------------------------------------------------------------
test-i386-i386-pv:
 1 xen-build-check(1)           pass     
 2 host-install(2)              pass     
 3 xen-install                  pass     
 4 xen-boot                     pass     
 5 debian-install               pass     
 6 debian-fixup                 pass     
 7 guest-start                  fail     
 8 capture-logs(8)              pass     
-------------------------------------------------------------------------------
test-amd64-xcpkern-i386-pv:
 1 xen-build-check(1)           pass     
 2 host-install(2)              pass     
 3 xen-install                  pass     
 4 xen-boot                     pass     
 5 debian-install               pass     
 6 debian-fixup                 pass     
 7 guest-start                  pass     
 8 guest-saverestore            pass     
 9 guest-localmigrate           pass     
10 guest-saverestore.2          pass     
11 guest-localmigrate.2         pass     
12 guest-stop                   pass     
13 capture-logs(13)             pass     
-------------------------------------------------------------------------------
test-i386-xcpkern-i386-pv:
 1 xen-build-check(1)           pass     
 2 host-install(2)              pass     
 3 xen-install                  pass     
 4 xen-boot                     pass     
 5 debian-install               pass     
 6 debian-fixup                 pass     
 7 guest-start                  pass     
 8 guest-saverestore            pass     
 9 guest-localmigrate           pass     
10 guest-saverestore.2          pass     
11 guest-localmigrate.2         pass     
12 guest-stop                   pass     
13 capture-logs(13)             pass     
-------------------------------------------------------------------------------
test-amd64-amd64-win:
 1 xen-build-check(1)           pass     
 2 host-install(2)              pass     
 3 xen-install                  pass     
 4 xen-boot                     pass     
 5 windows-install              pass     
 6 guest-saverestore            pass     
 7 guest-localmigrate           pass     
 8 guest-saverestore.2          pass     
 9 guest-localmigrate.2         pass     
10 guest-stop                   pass     
11 capture-logs(11)             pass     
-------------------------------------------------------------------------------
test-amd64-i386-win:
 1 xen-build-check(1)           pass     
 2 host-install(2)              pass     
 3 xen-install                  pass     
 4 xen-boot                     pass     
 5 windows-install              pass     
 6 guest-saverestore            pass     
 7 guest-localmigrate           pass     
 8 guest-saverestore.2          pass     
 9 guest-localmigrate.2         pass     
10 guest-stop                   pass     
11 capture-logs(11)             pass     
-------------------------------------------------------------------------------
test-i386-i386-win:
 1 xen-build-check(1)           pass     
 2 host-install(2)              pass     
 3 xen-install                  pass     
 4 xen-boot                     pass     
 5 windows-install              pass     
 6 guest-saverestore            pass     
 7 guest-localmigrate           pass     
 8 guest-saverestore.2          pass     
 9 guest-localmigrate.2         pass     
10 guest-stop                   pass     
11 capture-logs(11)             pass     
-------------------------------------------------------------------------------
test-amd64-xcpkern-i386-win:
 1 xen-build-check(1)           pass     
 2 host-install(2)              pass     
 3 xen-install                  pass     
 4 xen-boot                     pass     
 5 windows-install              pass     
 6 guest-saverestore            pass     
 7 guest-localmigrate           pass     
 8 guest-saverestore.2          pass     
 9 guest-localmigrate.2         pass     
10 guest-stop                   pass     
11 capture-logs(11)             pass     
-------------------------------------------------------------------------------
test-i386-xcpkern-i386-win:
 1 xen-build-check(1)           pass     
 2 host-install(2)              pass     
 3 xen-install                  pass     
 4 xen-boot                     pass     
 5 windows-install              pass     
 6 guest-saverestore            pass     
 7 guest-localmigrate           pass     
 8 guest-saverestore.2          pass     
 9 guest-localmigrate.2         pass     
10 guest-stop                   pass     
11 capture-logs(11)             pass     

------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

^ permalink raw reply

* Re: [PATCH 5/7] Add MCI card support to barebox
From: Sascha Hauer @ 2010-10-07 16:59 UTC (permalink / raw)
  To: Juergen Beisert; +Cc: barebox
In-Reply-To: <201010071800.06450.jbe@pengutronix.de>

On Thu, Oct 07, 2010 at 06:00:06PM +0200, Juergen Beisert wrote:
> Sascha Hauer wrote:
> > On Thu, Oct 07, 2010 at 03:24:16PM +0200, Juergen Beisert wrote:
> > > This adds the basic framework to handle MCI cards in barebox.
> > >
> > > Signed-off-by: Juergen Beisert <jbe@pengutronix.de>
> > > ---
> > >  drivers/Kconfig        |    1 +
> > >  drivers/Makefile       |    1 +
> > >  drivers/mci/Kconfig    |   30 ++
> > >  drivers/mci/Makefile   |    1 +
> > >  drivers/mci/mci-core.c | 1308
> > > ++++++++++++++++++++++++++++++++++++++++++++++++ include/mci.h          |
> > >  230 +++++++++
> > >  6 files changed, 1571 insertions(+), 0 deletions(-)
> > >  create mode 100644 drivers/mci/Kconfig
> > >  create mode 100644 drivers/mci/Makefile
> > >  create mode 100644 drivers/mci/mci-core.c
> > >  create mode 100644 include/mci.h
> >
> > This whole patch looks quite good.
> > Please add some linebreaks in mci-core.c. I don't want strict 80
> > character lines, but some lines are really long.
> >
> > [snip]
> >
> > > +static int mci_probe(struct device_d *mci_dev)
> > > +{
> > > +	struct mci *mci;
> > > +	int rc;
> > > +
> > > +	mci = xzalloc(sizeof(struct mci));
> > > +	mci_dev->priv = mci;
> > > +
> > > +#ifdef CONFIG_MCI_STARTUP
> > > +	/* if enabled, probe the attached card immediately */
> > > +	rc = mci_card_probe(mci_dev);
> > > +	if (rc == -ENODEV) {
> > > +		/*
> > > +		 * If it fails, add the 'probe' parameter to give the user
> > > +		 * a chance to insert a card and try again. Note: This may fail
> > > +		 * systems that rely on the MCI card for startup (for the
> > > +		 * persistant environment for example)
> > > +		 */
> > > +		rc = add_mci_parameter(mci_dev);
> > > +		if (rc != 0) {
> > > +			pr_err("Failed to add 'probe' parameter to the MCI device\n");
> > > +			goto on_error;
> > > +		}
> > > +	}
> > > +#endif
> > > +
> > > +#ifndef CONFIG_MCI_STARTUP
> >
> > #else instead?
> >
> > > +	/* add params on demand */
> > > +	rc = add_mci_parameter(mci_dev);
> > > +	if (rc != 0) {
> > > +		pr_err("Failed to add 'probe' parameter to the MCI device\n");
> > > +		goto on_error;
> > > +	}
> > > +#endif
> > > +
> > > +	return rc;
> > > +
> > > +on_error:
> > > +	free(mci);
> > > +	return rc;
> > > +}
> > > +
> >
> > [snip]
> >
> > > +
> > > +/** host information */
> > > +struct mci_platformdata {
> > > +	struct device_d *hw_dev;	/**< the host MCI hardware device */
> > > +	unsigned voltages;
> > > +	unsigned host_caps;	/**< Host's interface capabilities, refer MMC_VDD_*
> > > and FIXME */ +	unsigned f_min;		/**< host interface lower limit */
> > > +	unsigned f_max;		/**< host interface upper limit */
> > > +	unsigned clock;		/**< Current clock used to talk to the card */
> > > +	unsigned bus_width;	/**< used data bus width to the card */
> > > +
> > > +	int (*init)(struct device_d*, struct device_d*);	/**< init the host
> > > interface */ +	void (*set_ios)(struct device_d*, struct device_d*,
> > > unsigned, unsigned);	/**< change host interface settings */ +	int
> > > (*send_cmd)(struct device_d*, struct mci_cmd*, struct mci_data*);	/**<
> > > handle a command */ +};
> >
> > I prefer this struct named mci_host, this seems to match better what it
> > actually is.
> 
> Hmm, no, its not a "host". It is the MMC/SD card instance. The host is more 
> the interface, isn't it (at least for me)?

It's a host at least in the Linux terminology.

> 
> > For the convenience of drivers set init/set_ios/send_cmd 
> > functions should be passed a pointer to the mci_host, not the device,
> > because that's what they actually registered. I already prepared a patch
> > for this, I'll send it in a seperate mail.
> 
> I tried to layering the devices:
> 
>  disk_device -> knows how to handle disk drives and partition tables
>     |
>  mci_device -> knows how to probe and manage MMC/SD cards
>     |
>  hw_device -> knows how to transfer data
> 
> Most functions in the hw_device layer do not need access to any other 
> structure data than their own device (okay, there is a exception). So, I 
> tried to keep it simple.

I didn't change the underlying structure, only the pointer which is
passed to the functions.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply

* Re: [patch] infiniband: uverbs: limit the number of entries
From: Dan Carpenter @ 2010-10-07 16:59 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Roland Dreier, Sean Hefty, Hal Rosenstock,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA,
	kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101007161649.GD21206-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>

On Thu, Oct 07, 2010 at 10:16:49AM -0600, Jason Gunthorpe wrote:
> On Thu, Oct 07, 2010 at 09:16:10AM +0200, Dan Carpenter wrote:
> > If we don't limit cmd.ne then the multiplications can overflow.  This
> > will allocate a small amount of RAM successfully for the "resp" and
> > "wc" buffers.  The heap will get corrupted when we call ib_poll_cq().
> 
> I think you could cap the number of returned entries to
> UVERBS_MAX_NUM_ENTRIES rather than return EINVAL. That might be more
> compatible with user space..
> 

Good idea.  I don't actually have this hardware, so I can't test it, but
that definitely sounds reasonable.

If we did that then UVERBS_MAX_NUM_ENTRIES could be lower than 1000.
What is a reasonable number?

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [patch] infiniband: uverbs: limit the number of entries
From: Dan Carpenter @ 2010-10-07 16:59 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Roland Dreier, Sean Hefty, Hal Rosenstock,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA,
	kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101007161649.GD21206-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>

On Thu, Oct 07, 2010 at 10:16:49AM -0600, Jason Gunthorpe wrote:
> On Thu, Oct 07, 2010 at 09:16:10AM +0200, Dan Carpenter wrote:
> > If we don't limit cmd.ne then the multiplications can overflow.  This
> > will allocate a small amount of RAM successfully for the "resp" and
> > "wc" buffers.  The heap will get corrupted when we call ib_poll_cq().
> 
> I think you could cap the number of returned entries to
> UVERBS_MAX_NUM_ENTRIES rather than return EINVAL. That might be more
> compatible with user space..
> 

Good idea.  I don't actually have this hardware, so I can't test it, but
that definitely sounds reasonable.

If we did that then UVERBS_MAX_NUM_ENTRIES could be lower than 1000.
What is a reasonable number?

regards,
dan carpenter


^ permalink raw reply


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.