* [PATCH 4/7] wire up sys_time_change_notify() on powerpc
From: Alexander Shishkin @ 2010-09-16 22:10 UTC (permalink / raw)
To: linux-kernel
Cc: Jesper Nilsson, Greg KH, Chris Friesen, John Stultz,
Andreas Schwab, Kay Sievers, linuxppc-dev, Alexander Shishkin,
Paul Mackerras, H. Peter Anvin, Kirill A. Shutemov, Andrew Morton,
Linus Torvalds, Christoph Hellwig
In-Reply-To: <1284675049-23479-1-git-send-email-virtuoso@slind.org>
Signed-off-by: Alexander Shishkin <virtuoso@slind.org>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Andreas Schwab <schwab@linux-m68k.org>
CC: Alexander Shishkin <virtuoso@slind.org>
CC: Christoph Hellwig <hch@lst.de>
CC: Jesper Nilsson <jesper.nilsson@axis.com>
CC: linuxppc-dev@lists.ozlabs.org
CC: linux-kernel@vger.kernel.org
---
arch/powerpc/include/asm/systbl.h | 1 +
arch/powerpc/include/asm/unistd.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/systbl.h b/arch/powerpc/include/asm/systbl.h
index 3d21266..124b610 100644
--- a/arch/powerpc/include/asm/systbl.h
+++ b/arch/powerpc/include/asm/systbl.h
@@ -329,3 +329,4 @@ COMPAT_SYS(rt_tgsigqueueinfo)
SYSCALL(fanotify_init)
COMPAT_SYS(fanotify_mark)
SYSCALL_SPU(prlimit64)
+SYSCALL(time_change_notify)
diff --git a/arch/powerpc/include/asm/unistd.h b/arch/powerpc/include/asm/unistd.h
index 597e6f9..6ab64da 100644
--- a/arch/powerpc/include/asm/unistd.h
+++ b/arch/powerpc/include/asm/unistd.h
@@ -348,10 +348,11 @@
#define __NR_fanotify_init 323
#define __NR_fanotify_mark 324
#define __NR_prlimit64 325
+#define __NR_time_change_notify 326
#ifdef __KERNEL__
-#define __NR_syscalls 326
+#define __NR_syscalls 327
#define __NR__exit __NR_exit
#define NR_syscalls __NR_syscalls
--
1.7.2.1.45.gb66c2
^ permalink raw reply related
* Re: linux support for freescale e5500 core?
From: Benjamin Herrenschmidt @ 2010-09-16 22:03 UTC (permalink / raw)
To: Chris Friesen; +Cc: Scott Wood, linuxppc-dev, paulus, timur
In-Reply-To: <4C928FC5.9050700@genband.com>
On Thu, 2010-09-16 at 15:44 -0600, Chris Friesen wrote:
> On 09/16/2010 03:39 PM, Scott Wood wrote:
> > On Thu, 16 Sep 2010 14:06:37 -0600
> > Chris Friesen <chris.friesen@genband.com> wrote:
> >
> >> We're looking at maybe doing some work with an e5500-based system. Is
> >> there any support existing/planned for this core?
> >
> > Check with whoever you'd be getting the hardware from about a BSP.
> >
> > And yes, it should be supported upstream at some point.
>
> We haven't settled on a vendor yet, so I was just wondering in general
> what the story was around support.
Well, the "core" support for 64-bit BookE is upstream (and has been for
a little while) so +/- specific tweaks FSL may have done and the usual
SoC/board support, it shouldn't be too far off.
> Right. We currently use a 970-series cpu and have implemented a
> per-process flag to indicate whether 32-byte mode is needed or not.
> We'd have to do something similar with the new cpu.
Sounds like a candidate for upstreaming the patch :-)
> One last question--can you comment on the speed of an e5500 relative to
> a 970 for integer operations?
Cheers,
Ben.
^ permalink raw reply
* Re: Reserved pages in PowerPC
From: Benjamin Herrenschmidt @ 2010-09-16 21:52 UTC (permalink / raw)
To: Ankita Garg; +Cc: linuxppc-dev, linux-mm
In-Reply-To: <20100916120806.GJ2332@in.ibm.com>
On Thu, 2010-09-16 at 17:38 +0530, Ankita Garg wrote:
> Thanks Ben for taking a look at this. So I checked the rtas messages
> on
> the serial console and see the following:
>
> instantiating rtas at 0x000000000f632000... done
>
> Which does not correspond to the higher addresses that I see as
> reserved
> (observation on a 16G machine).
Well, I'd suggest you audit prom_init.c which builds the reserve map,
and the various memblock_reserve() calls in prom.c
Cheers,
Ben.
^ permalink raw reply
* Re: linux support for freescale e5500 core?
From: Chris Friesen @ 2010-09-16 21:44 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus, timur
In-Reply-To: <20100916163911.6255d359@schlenkerla.am.freescale.net>
On 09/16/2010 03:39 PM, Scott Wood wrote:
> On Thu, 16 Sep 2010 14:06:37 -0600
> Chris Friesen <chris.friesen@genband.com> wrote:
>
>> We're looking at maybe doing some work with an e5500-based system. Is
>> there any support existing/planned for this core?
>
> Check with whoever you'd be getting the hardware from about a BSP.
>
> And yes, it should be supported upstream at some point.
We haven't settled on a vendor yet, so I was just wondering in general
what the story was around support.
>> Also, do we know what the cache line size is--we have some legacy apps
>> that assume 32-byte.
>
> The cache line is 64 bytes. As with e500mc, there is a "dcbz32" mode
> for compatibility, though you probably lose much of the performance
> benefit of dcbz, and it might upset other software that properly checks
> for the cache line size but doesn't use dcbzl.
Right. We currently use a 970-series cpu and have implemented a
per-process flag to indicate whether 32-byte mode is needed or not.
We'd have to do something similar with the new cpu.
One last question--can you comment on the speed of an e5500 relative to
a 970 for integer operations?
Thanks,
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* Re: linux support for freescale e5500 core?
From: Scott Wood @ 2010-09-16 21:39 UTC (permalink / raw)
To: Chris Friesen; +Cc: linuxppc-dev, paulus, timur
In-Reply-To: <4C9278CD.10607@genband.com>
On Thu, 16 Sep 2010 14:06:37 -0600
Chris Friesen <chris.friesen@genband.com> wrote:
> We're looking at maybe doing some work with an e5500-based system. Is
> there any support existing/planned for this core?
Check with whoever you'd be getting the hardware from about a BSP.
And yes, it should be supported upstream at some point.
> Also, do we know what the cache line size is--we have some legacy apps
> that assume 32-byte.
The cache line is 64 bytes. As with e500mc, there is a "dcbz32" mode
for compatibility, though you probably lose much of the performance
benefit of dcbz, and it might upset other software that properly checks
for the cache line size but doesn't use dcbzl.
-Scott
^ permalink raw reply
* Can't find Ethernet PHY on MDIO bus
From: Juliano Maia @ 2010-09-16 20:39 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]
Hi.
I have 2 Ethernet PHYs connected to Powerpc MPC8313 TSEC1 and TSEC2
interfaces. The PHY I'm having trouble with is a Marvell 88E3015, and its
connected to TSEC2. I have mapped them in DTS file as follows:
mdio@24520 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-mdio";
reg = <0x24520 0x20>;
phy3: ethernet-phy@3 {
reg = <0x3>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
interrupt-parent = <&ipic>;
interrupts = <24 0x8>;
reg = <0x1>;
device_type = "ethernet-phy";
};
};
enet0: ethernet@24000 {
cell-index = <0>;
device_type = "network";
compatible = "gianfar";
reg = <0x24000 0x1000>;
model = "eTSEC";
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <32 0x8 33 0x8 34 0x8>;
interrupt-parent = <&ipic>;
fixed-link = <3 1 100 1 0>;
linux,network-index = <0>;
};
enet1: ethernet@25000 {
#address-cells = <1>;
#size-cells = <1>;
cell-index = <1>;
device_type = "network";
model = "eTSEC";
compatible = "gianfar";
reg = <0x25000 0x1000>;
local-mac-address = [ 00 a0 3e a8 a6 6E ];
interrupts = <35 0x8 36 0x8 37 0x8>;
interrupt-parent = <&ipic>;
phy-handle = < &phy1 >;
};
The problem is I'm not being able to set *ETH1* up. When i try, say "*ifconfig
eth1 up*" i got:
*vmunix: Trying to connect phy mdio@e0024520:01
vmunix: eth1: Could not attach to PHY*
I've tried to track this error down and found that the it raises from *
bus_find_device_by_name* function at *bus.c*. For some reason ETH1 is never
added do *devices_kset* for MDIO bus. It only contains an entry for ETH0,
which is 00:3.
What could be wrong? In a hardware point of view, this PHY seems to be OK,
since I've made some tests from U-boot command line trying some MDIO
commands. I've also checked MDIO pins with oscilloscope and everything seems
to be fine. But during Linux initialization I could not see any activity in
MDIO pins. Is that normal? Is there any other files I should change (other
than DTS) to make PHYs work?
Thanks
--
Juliano Maia
[-- Attachment #2: Type: text/html, Size: 2907 bytes --]
^ permalink raw reply
* Re: [PATCH] spi_mpc8xxx: fix buffer overrun when sending only/receiving only more than PAGE_SIZE bytes
From: Grant Likely @ 2010-09-16 20:15 UTC (permalink / raw)
To: christophe leroy
Cc: spi-devel-general, David Brownell, linuxppc-dev, linux-kernel
In-Reply-To: <20100916070525.4882CC7391@messagerie.si.c-s.fr>
On Thu, Sep 16, 2010 at 09:05:25AM +0200, christophe leroy wrote:
> This patch applies to 2.6.34.7 and 2.6.35.4
> It fixes an issue when sending only or receiving only more than PAGE_SIZE bytes
>
> Signed-off-by: christophe leroy <christophe.leroy@c-s.fr>
applied to merge-spi branch, thanks.
g.
>
> diff -urN c/drivers/spi/spi_mpc8xxx.c d/drivers/spi/spi_mpc8xxx.c
> --- c/drivers/spi/spi_mpc8xxx.c 2010-09-08 16:44:03.000000000 +0200
> +++ d/drivers/spi/spi_mpc8xxx.c 2010-09-08 16:44:14.000000000 +0200
> @@ -393,11 +393,17 @@
>
> xfer_ofs = mspi->xfer_in_progress->len - mspi->count;
>
> - out_be32(&rx_bd->cbd_bufaddr, mspi->rx_dma + xfer_ofs);
> + if (mspi->rx_dma == mspi->dma_dummy_rx)
> + out_be32(&rx_bd->cbd_bufaddr, mspi->rx_dma);
> + else
> + out_be32(&rx_bd->cbd_bufaddr, mspi->rx_dma + xfer_ofs);
> out_be16(&rx_bd->cbd_datlen, 0);
> out_be16(&rx_bd->cbd_sc, BD_SC_EMPTY | BD_SC_INTRPT | BD_SC_WRAP);
>
> - out_be32(&tx_bd->cbd_bufaddr, mspi->tx_dma + xfer_ofs);
> + if (mspi->tx_dma == mspi->dma_dummy_tx)
> + out_be32(&tx_bd->cbd_bufaddr, mspi->tx_dma);
> + else
> + out_be32(&tx_bd->cbd_bufaddr, mspi->tx_dma + xfer_ofs);
> out_be16(&tx_bd->cbd_datlen, xfer_len);
> out_be16(&tx_bd->cbd_sc, BD_SC_READY | BD_SC_INTRPT | BD_SC_WRAP |
> BD_SC_LAST);
^ permalink raw reply
* Help with finding memory read performance problem
From: Ayman El-Khashab @ 2010-09-16 20:12 UTC (permalink / raw)
To: linuxppc-dev
For our code we needed a fast memory compare of 5 buffers. I've implemented
said routine in asm and it works fine and is very fast in the test bench.
However when integrated with the app it is much less performant and we
are trying to figure out why.
The app in question gets the 5 4MB buffers in the kernel via kmalloc and
then uses them for DMA. No other methods are being called for the memory
besides kmalloc. This is an embedded system on the 460EX, so there is no
drive, only RAM. Within the user code mmap is called on these buffers
physical address and they are given to the compare routine. The result
is slow. If I allocate buffers in user space then the performance is
excellent.
Next I implemented my compare routine within a kernel module so that it
was using the kernel virtual addresses for each of the buffers. I did
not see any change between this and the mmap approach.
For comparison sake, using the kernel memory is about 19s whereas user
memory is about 11s for the same size / configuration of buffer. In the
test bench the algorithm is about 8s. The processor is not doing any
other intensive tasks during these tests and the times are repeatable.
Is something happening to mmap'd memory that causes the access to it to
be slow? Is there a way to speed that up? Why are the kernel memory
access slower than user memory?
What is the best overall approach? Is it to DMA into user memory and
then run the routines there? Is kmalloc not the best approach for
kernel DMA memory?
This is on linux 2.6.31.5 on 460EX
thanks
ayman
^ permalink raw reply
* linux support for freescale e5500 core?
From: Chris Friesen @ 2010-09-16 20:06 UTC (permalink / raw)
To: linuxppc-dev, timur, Benjamin Herrenschmidt, paulus
Hi,
We're looking at maybe doing some work with an e5500-based system. Is
there any support existing/planned for this core?
Also, do we know what the cache line size is--we have some legacy apps
that assume 32-byte.
Thanks,
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* Re: [PATCH] spi_mpc8xxx: fix writing to adress 0
From: Grant Likely @ 2010-09-16 20:11 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: christophe leroy, spi-devel-general, David Brownell, linuxppc-dev,
linux-kernel
In-Reply-To: <OFE491C952.64B1BE24-ONC12577A0.0029DACE-C12577A0.002A0993@transmode.se>
On Thu, Sep 16, 2010 at 09:39:09AM +0200, Joakim Tjernlund wrote:
> > From: christophe leroy <christophe.leroy@c-s.fr>
> > To: David Brownell <dbrownell@users.sourceforge.net>, Grant Likely
> > <grant.likely@secretlab.ca>, spi-devel-general@lists.sourceforge.net, linux-
> > kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
> > Date: 2010/09/16 09:06
> > Subject: [PATCH] spi_mpc8xxx: fix writing to adress 0
> > Sent by: linuxppc-dev-bounces+joakim.tjernlund=transmode.se@lists.ozlabs.org
> >
> > This patch applies to 2.6.34.7 (already included in 2.6.35.4)
> > It fixes an issue when sending only or receiving only (mspi->tx-dma was reset
> > as when no tx_buf is defined, tx_dma is 0)
> >
> > Signed-off-by: christophe leroy <christophe.leroy@c-s.fr>
>
> Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
>
You need to send this to the linux-stable list and include the sha1
commit id that fixes it in mainline.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
g.
^ permalink raw reply
* Re: 2.6.35-stable/ppc64/p7: suspicious rcu_dereference_check() usage detected during 2.6.35-stable boot
From: Subrata Modak @ 2010-09-16 18:19 UTC (permalink / raw)
To: Peter Zijlstra
Cc: sachinp, Valdis.Kletnieks, Li Zefan, linux-kernel, Linuxppc-dev,
paulmck, DIVYA PRAKASH
In-Reply-To: <20100916161259.GF2462@linux.vnet.ibm.com>
On Thu, 2010-09-16 at 09:12 -0700, Paul E. McKenney wrote:
> On Thu, Sep 16, 2010 at 05:50:31PM +0200, Peter Zijlstra wrote:
> > On Mon, 2010-08-09 at 09:12 -0700, Paul E. McKenney wrote:
> >
> > > > [ 0.051203] CPU0: AMD QEMU Virtual CPU version 0.12.4 stepping 03
> > > > [ 0.052999] lockdep: fixing up alternatives.
> > > > [ 0.054105]
> > > > [ 0.054106] ===================================================
> > > > [ 0.054999] [ INFO: suspicious rcu_dereference_check() usage. ]
> > > > [ 0.054999] ---------------------------------------------------
> > > > [ 0.054999] kernel/sched.c:616 invoked rcu_dereference_check() without protection!
> > > > [ 0.054999]
> > > > [ 0.054999] other info that might help us debug this:
> > > > [ 0.054999]
> > > > [ 0.054999]
> > > > [ 0.054999] rcu_scheduler_active = 1, debug_locks = 1
> > > > [ 0.054999] 3 locks held by swapper/1:
> > > > [ 0.054999] #0: (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff814be933>] cpu_up+0x42/0x6a
> > > > [ 0.054999] #1: (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff810400d8>] cpu_hotplug_begin+0x2a/0x51
> > > > [ 0.054999] #2: (&rq->lock){-.-...}, at: [<ffffffff814be2f7>] init_idle+0x2f/0x113
> > > > [ 0.054999]
> > > > [ 0.054999] stack backtrace:
> > > > [ 0.054999] Pid: 1, comm: swapper Not tainted 2.6.35 #1
> > > > [ 0.054999] Call Trace:
> > > > [ 0.054999] [<ffffffff81068054>] lockdep_rcu_dereference+0x9b/0xa3
> > > > [ 0.054999] [<ffffffff810325c3>] task_group+0x7b/0x8a
> > > > [ 0.054999] [<ffffffff810325e5>] set_task_rq+0x13/0x40
> > > > [ 0.054999] [<ffffffff814be39a>] init_idle+0xd2/0x113
> > > > [ 0.054999] [<ffffffff814be78a>] fork_idle+0xb8/0xc7
> > > > [ 0.054999] [<ffffffff81068717>] ? mark_held_locks+0x4d/0x6b
> > > > [ 0.054999] [<ffffffff814bcebd>] do_fork_idle+0x17/0x2b
> > > > [ 0.054999] [<ffffffff814bc89b>] native_cpu_up+0x1c1/0x724
> > > > [ 0.054999] [<ffffffff814bcea6>] ? do_fork_idle+0x0/0x2b
> > > > [ 0.054999] [<ffffffff814be876>] _cpu_up+0xac/0x127
> > > > [ 0.054999] [<ffffffff814be946>] cpu_up+0x55/0x6a
> > > > [ 0.054999] [<ffffffff81ab562a>] kernel_init+0xe1/0x1ff
> > > > [ 0.054999] [<ffffffff81003854>] kernel_thread_helper+0x4/0x10
> > > > [ 0.054999] [<ffffffff814c353c>] ? restore_args+0x0/0x30
> > > > [ 0.054999] [<ffffffff81ab5549>] ? kernel_init+0x0/0x1ff
> > > > [ 0.054999] [<ffffffff81003850>] ? kernel_thread_helper+0x0/0x10
> > > > [ 0.056074] Booting Node 0, Processors #1lockdep: fixing up alternatives.
> > > > [ 0.130045] #2lockdep: fixing up alternatives.
> > > > [ 0.203089] #3 Ok.
> > > > [ 0.275286] Brought up 4 CPUs
> > > > [ 0.276005] Total of 4 processors activated (16017.17 BogoMIPS).
> > >
> > > This does look like a new one, thank you for reporting it!
> > >
> > > Here is my analysis, which should at least provide some humor value to
> > > those who understand the code better than I do. ;-)
> > >
> > > So the corresponding rcu_dereference_check() is in
> > > task_subsys_state_check(), and is fetching the cpu_cgroup_subsys_id
> > > element of the newly created task's task->cgroups->subsys[] array.
> > > The "git grep" command finds only three uses of cpu_cgroup_subsys_id,
> > > but no definition.
> > >
> > > Now, fork_idle() invokes copy_process(), which invokes cgroup_fork(),
> > > which sets the child process's ->cgroups pointer to that of the parent,
> > > also invoking get_css_set(), which increments the corresponding reference
> > > count, doing both operations under task_lock() protection (->alloc_lock).
> > > Because fork_idle() does not specify any of CLONE_NEWNS, CLONE_NEWUTS,
> > > CLONE_NEWIPC, CLONE_NEWPID, or CLONE_NEWNET, copy_namespaces() should
> > > not create a new namespace, and so there should be no ns_cgroup_clone().
> > > We should thus retain the parent's ->cgroups pointer. And copy_process()
> > > installs the new task in the various lists, so that the task is externally
> > > accessible upon return.
> > >
> > > After a non-error return from copy_process(), fork_init() invokes
> > > init_idle_pid(), which does not appear to affect the task's cgroup
> > > state. Next fork_init() invokes init_idle(), which in turn invokes
> > > __set_task_cpu(), which invokes set_task_rq(), which calls task_group()
> > > several times, which calls task_subsys_state_check(), which calls the
> > > rcu_dereference_check() that complained above.
> > >
> > > However, the result returns by rcu_dereference_check() is stored into
> > > the task structure:
> > >
> > > p->se.cfs_rq = task_group(p)->cfs_rq[cpu];
> > > p->se.parent = task_group(p)->se[cpu];
> > >
> > > This means that the corresponding structure must have been tied down with
> > > a reference count or some such. If such a reference has been taken, then
> > > this complaint is a false positive, and could be suppressed by putting
> > > rcu_read_lock() and rcu_read_unlock() around the call to init_idle()
> > > from fork_idle(). However, although, reference to the enclosing ->cgroups
> > > struct css_set is held, it is not clear to me that this reference applies
> > > to the structures pointed to by the ->subsys[] array, especially given
> > > that the cgroup_subsys_state structures referenced by this array have
> > > their own reference count, which does not appear to me to be acquired
> > > by this code path.
> > >
> > > Or are the cgroup_subsys_state structures referenced by idle tasks
> > > never freed or some such?
> >
> > I would hope so!, the idle tasks should be part of the root cgroup,
> > which is not removable.
> >
> > The problem is that while we do in-fact hold rq->lock, the newly spawned
> > idle thread's cpu is not yet set to the correct cpu so the lockdep check
> > in task_group():
> >
> > lockdep_is_held(&task_rq(p)->lock)
> >
> > will fail.
> >
> > But of a chicken and egg problem. Setting the cpu needs to have the cpu
> > set ;-)
>
> OK, makes sense to me.
>
> > Ingo, why do we have rq->lock there at all? The CPU isn't up and running
> > yet, nothing should be touching it.
>
> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> > Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Thanks Peter for the fix.
Regards--
Subrata
> > ---
> > kernel/sched.c | 12 ++++++++++++
> > 1 files changed, 12 insertions(+), 0 deletions(-)
> >
> > diff --git a/kernel/sched.c b/kernel/sched.c
> > index bd8b487..6241049 100644
> > --- a/kernel/sched.c
> > +++ b/kernel/sched.c
> > @@ -5332,7 +5332,19 @@ void __cpuinit init_idle(struct task_struct *idle, int cpu)
> > idle->se.exec_start = sched_clock();
> >
> > cpumask_copy(&idle->cpus_allowed, cpumask_of(cpu));
> > + /*
> > + * We're having a chicken and egg problem, even though we are
> > + * holding rq->lock, the cpu isn't yet set to this cpu so the
> > + * lockdep check in task_group() will fail.
> > + *
> > + * Similar case to sched_fork(). / Alternatively we could
> > + * use task_rq_lock() here and obtain the other rq->lock.
> > + *
> > + * Silence PROVE_RCU
> > + */
> > + rcu_read_lock();
> > __set_task_cpu(idle, cpu);
> > + rcu_read_unlock();
> >
> > rq->curr = rq->idle = idle;
> > #if defined(CONFIG_SMP) && defined(__ARCH_WANT_UNLOCKED_CTXSW)
> >
^ permalink raw reply
* Re: Generating elf kernel ?
From: Scott Wood @ 2010-09-16 17:09 UTC (permalink / raw)
To: tiejun.chen; +Cc: linuxppc-dev, Guillaume Dargaud
In-Reply-To: <4C9182EC.5030900@windriver.com>
On Thu, 16 Sep 2010 10:37:32 +0800
"tiejun.chen" <tiejun.chen@windriver.com> wrote:
> 1> can you load the Linux vmlinux directly to the physical address '0' on
> current bootloader?
That depends on what bootloader we're talking about -- I don't know
what the original poster's custom loader can do. Obviously the
bootloader itself would have to be executing from some other address
(e.g. U-Boot runs from the top of RAM).
> 2> additionally you have to find a way to pass dtb to the native vmlinux.
Yes, of course. But that's a different issue. :-)
> I believe the hypervisor can boot vmlinux directly. But your so-called vmlinux
> should be guest OS. And the hypervisor will handle/assit TLB exception for the
> guest OS on MMU. Right? So you can use the hypervisor to load vmlinux to any
> physical address as you expect.
I was just using our hypervisor as an example, since it has an ELF
loader that can pass a device tree.
> But the guest OS should not be same as the native Linux.
The guest OS *is* the same as native Linux, as far as TLB handling is
concerned.
-Scott
^ permalink raw reply
* Re: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Scott Wood @ 2010-09-16 16:53 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, dedekind1, Zang Roy-R61911, Lan Chunhe-B25806,
linuxppc-dev, linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <20100916164044.GA5669@oksana.dev.rtsoft.ru>
On Thu, 16 Sep 2010 20:40:44 +0400
Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> On Thu, Sep 16, 2010 at 11:14:48AM -0500, Scott Wood wrote:
> > > > DEFINE_MUTEX(fsl_elbc_mutex);
> > >
> > > I'd place the mutex inside the fsl_lbc_ctrl_dev,
> > > i.e. fsl_lbc_ctrl_dev->nand_lock. This is to avoid more
> > > global variables.
> >
> > I wouldn't. If the lock is only meaningful to the NAND driver, it
> > should be declared in the NAND driver.
> >
> > Besides, it's not any less of a global just because it's sitting inside
> > a singleton struct.
> >
> > Perhaps it should be declared as a static local inside the probe
> > function, if it's just to guard against this one race.
>
> OK, in that case better be persistent and not introduce
> fsl_lbc_ctrl_dev->nand at all, as it isn't used outside
> of the driver.
We could, though it would be a step further away from being able to
support multiple controllers if that ever does happen. Whereas sharing
a mutex between multiple controllers isn't a problem (it's just init,
not a performance-sensitive path where fine-grained locking is
desireable).
> Having fsl_lbc_ctrl_dev->nand and its lock elsewhere in
> the code makes no sense.
That depends on whether you see it as that field's lock or as the init
code's lock, I guess.
It's not that big of a deal either way.
-Scott
^ permalink raw reply
* Re: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Anton Vorontsov @ 2010-09-16 16:40 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, dedekind1, Zang Roy-R61911, Lan Chunhe-B25806,
linuxppc-dev, linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <20100916111448.27ef7440@schlenkerla.am.freescale.net>
On Thu, Sep 16, 2010 at 11:14:48AM -0500, Scott Wood wrote:
> > > DEFINE_MUTEX(fsl_elbc_mutex);
> >
> > I'd place the mutex inside the fsl_lbc_ctrl_dev,
> > i.e. fsl_lbc_ctrl_dev->nand_lock. This is to avoid more
> > global variables.
>
> I wouldn't. If the lock is only meaningful to the NAND driver, it
> should be declared in the NAND driver.
>
> Besides, it's not any less of a global just because it's sitting inside
> a singleton struct.
>
> Perhaps it should be declared as a static local inside the probe
> function, if it's just to guard against this one race.
OK, in that case better be persistent and not introduce
fsl_lbc_ctrl_dev->nand at all, as it isn't used outside
of the driver.
Having fsl_lbc_ctrl_dev->nand and its lock elsewhere in
the code makes no sense.
> > Btw, even before this patch, it seems that the driver had
> > all these bugs/races, i.e. ctrl->controller.lock was not
> > used at all. Ugh.
>
> It is used, search nand_base.c for controller->lock.
OK, now I see, the driver implements its own chip->controller
(which is exactly what ctrl->controller is). Then we're fine.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Scott Wood @ 2010-09-16 16:14 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, dedekind1, Zang Roy-R61911, Lan Chunhe-B25806,
linuxppc-dev, linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <20100916112624.GA32074@oksana.dev.rtsoft.ru>
On Thu, 16 Sep 2010 15:26:24 +0400
Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> On Thu, Sep 16, 2010 at 06:39:40PM +0800, Zang Roy-R61911 wrote:
> [...]
> > But my code has some assignment for "foo" instead of a simple
> > allocation, how about this way for my code:
>
> This will surely work, and all the rest is just a matter of
> taste. So, I'm fine with it. But see below, I think I found
> some new, quite serious issues.
>
> > DEFINE_MUTEX(fsl_elbc_mutex);
>
> I'd place the mutex inside the fsl_lbc_ctrl_dev,
> i.e. fsl_lbc_ctrl_dev->nand_lock. This is to avoid more
> global variables.
I wouldn't. If the lock is only meaningful to the NAND driver, it
should be declared in the NAND driver.
Besides, it's not any less of a global just because it's sitting inside
a singleton struct.
Perhaps it should be declared as a static local inside the probe
function, if it's just to guard against this one race.
> > elbc_fcm_ctrl->read_bytes = 0;
> > elbc_fcm_ctrl->index = 0;
> > elbc_fcm_ctrl->addr = NULL;
>
> I guess these variables should be per chip select, as
> otherwise there will be tons of races when somebody try
> to access two or more NAND chips simultaneously.
The NAND layer has its own per-controller mutex that prevents this.
> So, I'd suggest to redo the whole thing this way: don't allocate
> elbc_fcm_ctrl in this driver, but make an array inside the
> fsl_lbc_ctrl_dev. I.e.
> fsl_lbc_ctrl_dev->nand_ctrl[MAX_CHIP_SELECTS]
NACK.
There is not a separate controller per chip select.
> Btw, even before this patch, it seems that the driver had
> all these bugs/races, i.e. ctrl->controller.lock was not
> used at all. Ugh.
It is used, search nand_base.c for controller->lock.
-Scott
^ permalink raw reply
* Re: 2.6.35-stable/ppc64/p7: suspicious rcu_dereference_check() usage detected during 2.6.35-stable boot
From: Paul E. McKenney @ 2010-09-16 16:12 UTC (permalink / raw)
To: Peter Zijlstra
Cc: sachinp, Valdis.Kletnieks, Li Zefan, linux-kernel, Linuxppc-dev,
Subrata Modak, DIVYA PRAKASH
In-Reply-To: <1284652231.2275.569.camel@laptop>
On Thu, Sep 16, 2010 at 05:50:31PM +0200, Peter Zijlstra wrote:
> On Mon, 2010-08-09 at 09:12 -0700, Paul E. McKenney wrote:
>
> > > [ 0.051203] CPU0: AMD QEMU Virtual CPU version 0.12.4 stepping 03
> > > [ 0.052999] lockdep: fixing up alternatives.
> > > [ 0.054105]
> > > [ 0.054106] ===================================================
> > > [ 0.054999] [ INFO: suspicious rcu_dereference_check() usage. ]
> > > [ 0.054999] ---------------------------------------------------
> > > [ 0.054999] kernel/sched.c:616 invoked rcu_dereference_check() without protection!
> > > [ 0.054999]
> > > [ 0.054999] other info that might help us debug this:
> > > [ 0.054999]
> > > [ 0.054999]
> > > [ 0.054999] rcu_scheduler_active = 1, debug_locks = 1
> > > [ 0.054999] 3 locks held by swapper/1:
> > > [ 0.054999] #0: (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff814be933>] cpu_up+0x42/0x6a
> > > [ 0.054999] #1: (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff810400d8>] cpu_hotplug_begin+0x2a/0x51
> > > [ 0.054999] #2: (&rq->lock){-.-...}, at: [<ffffffff814be2f7>] init_idle+0x2f/0x113
> > > [ 0.054999]
> > > [ 0.054999] stack backtrace:
> > > [ 0.054999] Pid: 1, comm: swapper Not tainted 2.6.35 #1
> > > [ 0.054999] Call Trace:
> > > [ 0.054999] [<ffffffff81068054>] lockdep_rcu_dereference+0x9b/0xa3
> > > [ 0.054999] [<ffffffff810325c3>] task_group+0x7b/0x8a
> > > [ 0.054999] [<ffffffff810325e5>] set_task_rq+0x13/0x40
> > > [ 0.054999] [<ffffffff814be39a>] init_idle+0xd2/0x113
> > > [ 0.054999] [<ffffffff814be78a>] fork_idle+0xb8/0xc7
> > > [ 0.054999] [<ffffffff81068717>] ? mark_held_locks+0x4d/0x6b
> > > [ 0.054999] [<ffffffff814bcebd>] do_fork_idle+0x17/0x2b
> > > [ 0.054999] [<ffffffff814bc89b>] native_cpu_up+0x1c1/0x724
> > > [ 0.054999] [<ffffffff814bcea6>] ? do_fork_idle+0x0/0x2b
> > > [ 0.054999] [<ffffffff814be876>] _cpu_up+0xac/0x127
> > > [ 0.054999] [<ffffffff814be946>] cpu_up+0x55/0x6a
> > > [ 0.054999] [<ffffffff81ab562a>] kernel_init+0xe1/0x1ff
> > > [ 0.054999] [<ffffffff81003854>] kernel_thread_helper+0x4/0x10
> > > [ 0.054999] [<ffffffff814c353c>] ? restore_args+0x0/0x30
> > > [ 0.054999] [<ffffffff81ab5549>] ? kernel_init+0x0/0x1ff
> > > [ 0.054999] [<ffffffff81003850>] ? kernel_thread_helper+0x0/0x10
> > > [ 0.056074] Booting Node 0, Processors #1lockdep: fixing up alternatives.
> > > [ 0.130045] #2lockdep: fixing up alternatives.
> > > [ 0.203089] #3 Ok.
> > > [ 0.275286] Brought up 4 CPUs
> > > [ 0.276005] Total of 4 processors activated (16017.17 BogoMIPS).
> >
> > This does look like a new one, thank you for reporting it!
> >
> > Here is my analysis, which should at least provide some humor value to
> > those who understand the code better than I do. ;-)
> >
> > So the corresponding rcu_dereference_check() is in
> > task_subsys_state_check(), and is fetching the cpu_cgroup_subsys_id
> > element of the newly created task's task->cgroups->subsys[] array.
> > The "git grep" command finds only three uses of cpu_cgroup_subsys_id,
> > but no definition.
> >
> > Now, fork_idle() invokes copy_process(), which invokes cgroup_fork(),
> > which sets the child process's ->cgroups pointer to that of the parent,
> > also invoking get_css_set(), which increments the corresponding reference
> > count, doing both operations under task_lock() protection (->alloc_lock).
> > Because fork_idle() does not specify any of CLONE_NEWNS, CLONE_NEWUTS,
> > CLONE_NEWIPC, CLONE_NEWPID, or CLONE_NEWNET, copy_namespaces() should
> > not create a new namespace, and so there should be no ns_cgroup_clone().
> > We should thus retain the parent's ->cgroups pointer. And copy_process()
> > installs the new task in the various lists, so that the task is externally
> > accessible upon return.
> >
> > After a non-error return from copy_process(), fork_init() invokes
> > init_idle_pid(), which does not appear to affect the task's cgroup
> > state. Next fork_init() invokes init_idle(), which in turn invokes
> > __set_task_cpu(), which invokes set_task_rq(), which calls task_group()
> > several times, which calls task_subsys_state_check(), which calls the
> > rcu_dereference_check() that complained above.
> >
> > However, the result returns by rcu_dereference_check() is stored into
> > the task structure:
> >
> > p->se.cfs_rq = task_group(p)->cfs_rq[cpu];
> > p->se.parent = task_group(p)->se[cpu];
> >
> > This means that the corresponding structure must have been tied down with
> > a reference count or some such. If such a reference has been taken, then
> > this complaint is a false positive, and could be suppressed by putting
> > rcu_read_lock() and rcu_read_unlock() around the call to init_idle()
> > from fork_idle(). However, although, reference to the enclosing ->cgroups
> > struct css_set is held, it is not clear to me that this reference applies
> > to the structures pointed to by the ->subsys[] array, especially given
> > that the cgroup_subsys_state structures referenced by this array have
> > their own reference count, which does not appear to me to be acquired
> > by this code path.
> >
> > Or are the cgroup_subsys_state structures referenced by idle tasks
> > never freed or some such?
>
> I would hope so!, the idle tasks should be part of the root cgroup,
> which is not removable.
>
> The problem is that while we do in-fact hold rq->lock, the newly spawned
> idle thread's cpu is not yet set to the correct cpu so the lockdep check
> in task_group():
>
> lockdep_is_held(&task_rq(p)->lock)
>
> will fail.
>
> But of a chicken and egg problem. Setting the cpu needs to have the cpu
> set ;-)
OK, makes sense to me.
> Ingo, why do we have rq->lock there at all? The CPU isn't up and running
> yet, nothing should be touching it.
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> ---
> kernel/sched.c | 12 ++++++++++++
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/sched.c b/kernel/sched.c
> index bd8b487..6241049 100644
> --- a/kernel/sched.c
> +++ b/kernel/sched.c
> @@ -5332,7 +5332,19 @@ void __cpuinit init_idle(struct task_struct *idle, int cpu)
> idle->se.exec_start = sched_clock();
>
> cpumask_copy(&idle->cpus_allowed, cpumask_of(cpu));
> + /*
> + * We're having a chicken and egg problem, even though we are
> + * holding rq->lock, the cpu isn't yet set to this cpu so the
> + * lockdep check in task_group() will fail.
> + *
> + * Similar case to sched_fork(). / Alternatively we could
> + * use task_rq_lock() here and obtain the other rq->lock.
> + *
> + * Silence PROVE_RCU
> + */
> + rcu_read_lock();
> __set_task_cpu(idle, cpu);
> + rcu_read_unlock();
>
> rq->curr = rq->idle = idle;
> #if defined(CONFIG_SMP) && defined(__ARCH_WANT_UNLOCKED_CTXSW)
>
^ permalink raw reply
* Re: 2.6.35-stable/ppc64/p7: suspicious rcu_dereference_check() usage detected during 2.6.35-stable boot
From: Peter Zijlstra @ 2010-09-16 15:50 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: sachinp, Li Zefan, linux-kernel, Linuxppc-dev, paulmck,
Subrata Modak, DIVYA PRAKASH
In-Reply-To: <10430.1284649951@localhost>
On Thu, 2010-09-16 at 11:12 -0400, Valdis.Kletnieks@vt.edu wrote:
>=20
> Ping? I just hit it on 2.6.36-rc4-mmotm0915. Just wanted to make sure t=
he
> issue hadn't been lost/forgotten.=20
lost,.. thanks!
^ permalink raw reply
* Re: 2.6.35-stable/ppc64/p7: suspicious rcu_dereference_check() usage detected during 2.6.35-stable boot
From: Peter Zijlstra @ 2010-09-16 15:50 UTC (permalink / raw)
To: paulmck
Cc: sachinp, Valdis.Kletnieks, Li Zefan, linux-kernel, Linuxppc-dev,
Subrata Modak, DIVYA PRAKASH
In-Reply-To: <20100809161200.GC3026@linux.vnet.ibm.com>
On Mon, 2010-08-09 at 09:12 -0700, Paul E. McKenney wrote:
> > [ 0.051203] CPU0: AMD QEMU Virtual CPU version 0.12.4 stepping 03
> > [ 0.052999] lockdep: fixing up alternatives.
> > [ 0.054105]
> > [ 0.054106] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
> > [ 0.054999] [ INFO: suspicious rcu_dereference_check() usage. ]
> > [ 0.054999] ---------------------------------------------------
> > [ 0.054999] kernel/sched.c:616 invoked rcu_dereference_check() witho=
ut protection!
> > [ 0.054999]
> > [ 0.054999] other info that might help us debug this:
> > [ 0.054999]
> > [ 0.054999]
> > [ 0.054999] rcu_scheduler_active =3D 1, debug_locks =3D 1
> > [ 0.054999] 3 locks held by swapper/1:
> > [ 0.054999] #0: (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff814be=
933>] cpu_up+0x42/0x6a
> > [ 0.054999] #1: (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff810400d8=
>] cpu_hotplug_begin+0x2a/0x51
> > [ 0.054999] #2: (&rq->lock){-.-...}, at: [<ffffffff814be2f7>] init=
_idle+0x2f/0x113
> > [ 0.054999]
> > [ 0.054999] stack backtrace:
> > [ 0.054999] Pid: 1, comm: swapper Not tainted 2.6.35 #1
> > [ 0.054999] Call Trace:
> > [ 0.054999] [<ffffffff81068054>] lockdep_rcu_dereference+0x9b/0xa3
> > [ 0.054999] [<ffffffff810325c3>] task_group+0x7b/0x8a
> > [ 0.054999] [<ffffffff810325e5>] set_task_rq+0x13/0x40
> > [ 0.054999] [<ffffffff814be39a>] init_idle+0xd2/0x113
> > [ 0.054999] [<ffffffff814be78a>] fork_idle+0xb8/0xc7
> > [ 0.054999] [<ffffffff81068717>] ? mark_held_locks+0x4d/0x6b
> > [ 0.054999] [<ffffffff814bcebd>] do_fork_idle+0x17/0x2b
> > [ 0.054999] [<ffffffff814bc89b>] native_cpu_up+0x1c1/0x724
> > [ 0.054999] [<ffffffff814bcea6>] ? do_fork_idle+0x0/0x2b
> > [ 0.054999] [<ffffffff814be876>] _cpu_up+0xac/0x127
> > [ 0.054999] [<ffffffff814be946>] cpu_up+0x55/0x6a
> > [ 0.054999] [<ffffffff81ab562a>] kernel_init+0xe1/0x1ff
> > [ 0.054999] [<ffffffff81003854>] kernel_thread_helper+0x4/0x10
> > [ 0.054999] [<ffffffff814c353c>] ? restore_args+0x0/0x30
> > [ 0.054999] [<ffffffff81ab5549>] ? kernel_init+0x0/0x1ff
> > [ 0.054999] [<ffffffff81003850>] ? kernel_thread_helper+0x0/0x10
> > [ 0.056074] Booting Node 0, Processors #1lockdep: fixing up alter=
natives.
> > [ 0.130045] #2lockdep: fixing up alternatives.
> > [ 0.203089] #3 Ok.
> > [ 0.275286] Brought up 4 CPUs
> > [ 0.276005] Total of 4 processors activated (16017.17 BogoMIPS).
>=20
> This does look like a new one, thank you for reporting it!
>=20
> Here is my analysis, which should at least provide some humor value to
> those who understand the code better than I do. ;-)
>=20
> So the corresponding rcu_dereference_check() is in
> task_subsys_state_check(), and is fetching the cpu_cgroup_subsys_id
> element of the newly created task's task->cgroups->subsys[] array.
> The "git grep" command finds only three uses of cpu_cgroup_subsys_id,
> but no definition.
>=20
> Now, fork_idle() invokes copy_process(), which invokes cgroup_fork(),
> which sets the child process's ->cgroups pointer to that of the parent,
> also invoking get_css_set(), which increments the corresponding reference
> count, doing both operations under task_lock() protection (->alloc_lock).
> Because fork_idle() does not specify any of CLONE_NEWNS, CLONE_NEWUTS,
> CLONE_NEWIPC, CLONE_NEWPID, or CLONE_NEWNET, copy_namespaces() should
> not create a new namespace, and so there should be no ns_cgroup_clone().
> We should thus retain the parent's ->cgroups pointer. And copy_process()
> installs the new task in the various lists, so that the task is externall=
y
> accessible upon return.
>=20
> After a non-error return from copy_process(), fork_init() invokes
> init_idle_pid(), which does not appear to affect the task's cgroup
> state. Next fork_init() invokes init_idle(), which in turn invokes
> __set_task_cpu(), which invokes set_task_rq(), which calls task_group()
> several times, which calls task_subsys_state_check(), which calls the
> rcu_dereference_check() that complained above.
>=20
> However, the result returns by rcu_dereference_check() is stored into
> the task structure:
>=20
> p->se.cfs_rq =3D task_group(p)->cfs_rq[cpu];
> p->se.parent =3D task_group(p)->se[cpu];
>=20
> This means that the corresponding structure must have been tied down with
> a reference count or some such. If such a reference has been taken, then
> this complaint is a false positive, and could be suppressed by putting
> rcu_read_lock() and rcu_read_unlock() around the call to init_idle()
> from fork_idle(). However, although, reference to the enclosing ->cgroup=
s
> struct css_set is held, it is not clear to me that this reference applies
> to the structures pointed to by the ->subsys[] array, especially given
> that the cgroup_subsys_state structures referenced by this array have
> their own reference count, which does not appear to me to be acquired
> by this code path.
>=20
> Or are the cgroup_subsys_state structures referenced by idle tasks
> never freed or some such?
I would hope so!, the idle tasks should be part of the root cgroup,
which is not removable.
The problem is that while we do in-fact hold rq->lock, the newly spawned
idle thread's cpu is not yet set to the correct cpu so the lockdep check
in task_group():
lockdep_is_held(&task_rq(p)->lock)
will fail.
But of a chicken and egg problem. Setting the cpu needs to have the cpu
set ;-)
Ingo, why do we have rq->lock there at all? The CPU isn't up and running
yet, nothing should be touching it.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
kernel/sched.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/kernel/sched.c b/kernel/sched.c
index bd8b487..6241049 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -5332,7 +5332,19 @@ void __cpuinit init_idle(struct task_struct *idle, i=
nt cpu)
idle->se.exec_start =3D sched_clock();
=20
cpumask_copy(&idle->cpus_allowed, cpumask_of(cpu));
+ /*
+ * We're having a chicken and egg problem, even though we are
+ * holding rq->lock, the cpu isn't yet set to this cpu so the
+ * lockdep check in task_group() will fail.
+ *
+ * Similar case to sched_fork(). / Alternatively we could
+ * use task_rq_lock() here and obtain the other rq->lock.
+ *
+ * Silence PROVE_RCU
+ */
+ rcu_read_lock();
__set_task_cpu(idle, cpu);
+ rcu_read_unlock();
=20
rq->curr =3D rq->idle =3D idle;
#if defined(CONFIG_SMP) && defined(__ARCH_WANT_UNLOCKED_CTXSW)
^ permalink raw reply related
* Re: 2.6.35-stable/ppc64/p7: suspicious rcu_dereference_check() usage detected during 2.6.35-stable boot
From: Valdis.Kletnieks @ 2010-09-16 15:12 UTC (permalink / raw)
To: paulmck
Cc: sachinp, Peter Zijlstra, Li Zefan, linux-kernel, Linuxppc-dev,
Subrata Modak, DIVYA PRAKASH
In-Reply-To: <20100809161200.GC3026@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 974 bytes --]
On Mon, 09 Aug 2010 09:12:00 PDT, "Paul E. McKenney" said:
> On Mon, Aug 02, 2010 at 02:22:12PM +0530, Subrata Modak wrote:
> > Hi,
> >
> > The following suspicious rcu_dereference_check() usage is detected
> > during 2.6.35-stable boot on my ppc64/p7 machine:
> >
> > =========================
> > [ INFO: suspicious rcu_dereference_check() usage. ]
> > ---------------------------------------------------
> > kernel/sched.c:616 invoked rcu_dereference_check() without protection!
> > other info that might help us debug this:
> Thank you for locating this one! This looks like the same issue that
> Ilia Mirkin located. Please see below for my analysis -- no fix yet,
> as I need confirmation from cgroups experts. I can easily create a
> patch that suppresses the warning, but I don't yet know whether this is
> the right thing to do.
Ping? I just hit it on 2.6.36-rc4-mmotm0915. Just wanted to make sure the
issue hadn't been lost/forgotten.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: Reserved pages in PowerPC
From: Ankita Garg @ 2010-09-16 12:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-mm
In-Reply-To: <1284631464.30449.85.camel@pasglop>
Hi Ben,
On Thu, Sep 16, 2010 at 08:04:24PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2010-09-16 at 10:53 +0530, Ankita Garg wrote:
> >
> > With some debugging I found that that section has reserved pages. On
> > instrumenting the memblock_reserve() and reserve_bootmem() routines, I can see
> > that many of the memory areas are reserved for kernel and initrd by the
> > memblock reserve() itself. reserve_bootmem then looks at the pages already
> > reserved and marks them reserved. However, for the very last section, I see
> > that bootmem reserves it but I am unable to find a corresponding reservation
> > by the memblock code.
>
> It's probably RTAS (firmware runtime services). I'ts instanciated at
> boot from prom_init and we do favor high addresses for it below 1G iirc.
>
Thanks Ben for taking a look at this. So I checked the rtas messages on
the serial console and see the following:
instantiating rtas at 0x000000000f632000... done
Which does not correspond to the higher addresses that I see as reserved
(observation on a 16G machine).
--
Regards,
Ankita Garg (ankita@in.ibm.com)
Linux Technology Center
IBM India Systems & Technology Labs,
Bangalore, India
^ permalink raw reply
* Re: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Anton Vorontsov @ 2010-09-16 11:26 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <3850A844E6A3854C827AC5C0BEC7B60A1FC6E1@zch01exm23.fsl.freescale.net>
On Thu, Sep 16, 2010 at 06:39:40PM +0800, Zang Roy-R61911 wrote:
[...]
> But my code has some assignment for "foo" instead of a simple
> allocation, how about this way for my code:
This will surely work, and all the rest is just a matter of
taste. So, I'm fine with it. But see below, I think I found
some new, quite serious issues.
> DEFINE_MUTEX(fsl_elbc_mutex);
I'd place the mutex inside the fsl_lbc_ctrl_dev,
i.e. fsl_lbc_ctrl_dev->nand_lock. This is to avoid more
global variables.
> ...
> static int __devinit fsl_elbc_nand_probe(struct platform_device *dev)
> {
> ...
> mutex_lock(&fsl_lbc_mutex);
> if (!fsl_lbc_ctrl_dev->nand) {
> elbc_fcm_ctrl = kzalloc(sizeof(*elbc_fcm_ctrl), GFP_KERNEL);
> if (!elbc_fcm_ctrl) {
> dev_err(fsl_lbc_ctrl_dev->dev, "failed to allocate "
> "memory\n");
> ret = -ENOMEM;
> goto err;
> }
>
> elbc_fcm_ctrl->read_bytes = 0;
> elbc_fcm_ctrl->index = 0;
> elbc_fcm_ctrl->addr = NULL;
I guess these variables should be per chip select, as
otherwise there will be tons of races when somebody try
to access two or more NAND chips simultaneously.
(Plus, you don't need these = 0 and = NULL as you used
kzalloc() for allocation.)
>
> spin_lock_init(&elbc_fcm_ctrl->controller.lock);
> init_waitqueue_head(&elbc_fcm_ctrl->controller.wq);
Some of these may need to be per chip select too.
So, I'd suggest to redo the whole thing this way: don't allocate
elbc_fcm_ctrl in this driver, but make an array inside the
fsl_lbc_ctrl_dev. I.e.
fsl_lbc_ctrl_dev->nand_ctrl[MAX_CHIP_SELECTS]
or something like that.
Btw, even before this patch, it seems that the driver had
all these bugs/races, i.e. ctrl->controller.lock was not
used at all. Ugh.
> fsl_lbc_ctrl_dev->nand = elbc_fcm_ctrl;
> } else
> elbc_fcm_ctrl = fsl_lbc_ctrl_dev->nand;
Per coding style this should be
} else {
elbc_fcm_ctrl = fsl_lbc_ctrl_dev->nand;
}
> mutex_unlock(&fsl_lbc_mutex);
>
> elbc_fcm_ctrl->chips[bank] = priv;
> ...
> }
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 11/15] ppc/cell: beat dma ops cleanup
From: Arnd Bergmann @ 2010-09-16 11:23 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: cbe-oss-dev, Milton Miller, Paul Mackerras, linuxppc-dev,
David S. Miller
In-Reply-To: <1284573958-8397-12-git-send-email-nacc@us.ibm.com>
On Wednesday 15 September 2010, Nishanth Aravamudan wrote:
> direct_dma_ops is the default pci dma ops.
>
> No need to call a function to get the pci dma ops, we know they are the
> dma_direct_ops.
>
> Signed-off-by: Milton Miller <miltonm@bga.com>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* RE: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Zang Roy-R61911 @ 2010-09-16 10:39 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <20100916101429.GA27393@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIFNlcHRl
bWJlciAxNiwgMjAxMCAxODoxNCBQTQ0KPiBUbzogWmFuZyBSb3ktUjYxOTExDQo+IENjOiBXb29k
IFNjb3R0LUIwNzQyMTsgZGVkZWtpbmQxQGdtYWlsLmNvbTsgTGFuIENodW5oZS1CMjU4MDY7IGxp
bnV4cHBjLQ0KPiBkZXZAb3psYWJzLm9yZzsgbGludXgtbXRkQGxpc3RzLmluZnJhZGVhZC5vcmc7
IGFrcG1AbGludXgtZm91bmRhdGlvbi5vcmc7DQo+IGR3bXcyQGluZnJhZGVhZC5vcmc7IEdhbGEg
S3VtYXItQjExNzgwDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMi8zIHYzXSBQNDA4MC9tdGQ6IE9u
bHkgbWFrZSBlbGJjIG5hbmQgZHJpdmVyIGRldGVjdCBuYW5kDQo+IGZsYXNoIHBhcnRpdGlvbnMN
Cj4gDQo+IE9uIFRodSwgU2VwIDE2LCAyMDEwIGF0IDA2OjA4OjE0UE0gKzA4MDAsIFphbmcgUm95
LVI2MTkxMSB3cm90ZToNCj4gWy4uLl0NCj4gPiBJbnRlcmVzdGluZy4NCj4gPiBIb3cgYWJvdXQg
dGhpcz8NCj4gPiAjaW5jbHVkZSA8c3RkaW8uaD4NCj4gPiAjaW5jbHVkZSA8bWFsbG9jLmg+DQo+
ID4NCj4gPiBjaGFyICpmb287DQo+ID4NCj4gPiB2b2lkIHByb2JlKHZvaWQpDQo+ID4gew0KPiA+
ICAgICAgICAgY2hhciAqYmFyID0gTlVMTDsNCj4gPg0KPiA+ICAgICAgICAgaWYgKCFmb28pIHsN
Cj4gPiAgICAgICAgICAgICAgICAgYmFyID0gbWFsbG9jKHNpemVvZigqYmFyKSk7DQo+ID4gICAg
ICAgICAgICAgICAgIGlmICghYmFyKQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgIHJldHVy
bjsNCj4gPiAgICAgICAgICAgICAgICAgZm9vID0gYmFyOw0KPiA+ICAgICAgICAgfSBlbHNlDQo+
ID4gCQkgICBiYXIgPSBmb287DQo+IA0KPiBUaGlzIHdpbGxsIHdvcmsgb2YgY291cnNlOyBidXQg
SSdkIHdyaXRlIGl0IGFzDQo+IA0KPiBmb29fbG9jaygpOw0KPiBpZiAoIWZvbykNCj4gCWZvbyA9
IGFsbG9jKCk7DQo+IGZvb191bmxvY2soKTsNCj4gDQo+IGJhciA9IGZvbzsNCj4gYmFyLT5iYXo7
DQpCdXQgbXkgY29kZSBoYXMgc29tZSBhc3NpZ25tZW50IGZvciAiZm9vIiBpbnN0ZWFkIG9mIGEg
c2ltcGxlDQphbGxvY2F0aW9uLCBob3cgYWJvdXQgdGhpcyB3YXkgZm9yIG15IGNvZGU6DQpERUZJ
TkVfTVVURVgoZnNsX2VsYmNfbXV0ZXgpOw0KLi4uDQpzdGF0aWMgaW50IF9fZGV2aW5pdCBmc2xf
ZWxiY19uYW5kX3Byb2JlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKmRldikNCnsNCi4uLg0KICAg
ICAgICBtdXRleF9sb2NrKCZmc2xfbGJjX211dGV4KTsNCiAgICAgICAgaWYgKCFmc2xfbGJjX2N0
cmxfZGV2LT5uYW5kKSB7DQogICAgICAgICAgICAgICAgZWxiY19mY21fY3RybCA9IGt6YWxsb2Mo
c2l6ZW9mKCplbGJjX2ZjbV9jdHJsKSwgR0ZQX0tFUk5FTCk7DQogICAgICAgICAgICAgICAgaWYg
KCFlbGJjX2ZjbV9jdHJsKSB7DQogICAgICAgICAgICAgICAgICAgICAgICBkZXZfZXJyKGZzbF9s
YmNfY3RybF9kZXYtPmRldiwgImZhaWxlZCB0byBhbGxvY2F0ZSAiDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIm1lbW9yeVxuIik7DQogICAgICAgICAgICAgICAgICAg
ICAgICByZXQgPSAtRU5PTUVNOw0KICAgICAgICAgICAgICAgICAgICAgICAgZ290byBlcnI7DQog
ICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgZWxiY19mY21fY3RybC0+cmVhZF9i
eXRlcyA9IDA7DQogICAgICAgICAgICAgICAgZWxiY19mY21fY3RybC0+aW5kZXggPSAwOw0KICAg
ICAgICAgICAgICAgIGVsYmNfZmNtX2N0cmwtPmFkZHIgPSBOVUxMOw0KDQogICAgICAgICAgICAg
ICAgc3Bpbl9sb2NrX2luaXQoJmVsYmNfZmNtX2N0cmwtPmNvbnRyb2xsZXIubG9jayk7DQogICAg
ICAgICAgICAgICAgaW5pdF93YWl0cXVldWVfaGVhZCgmZWxiY19mY21fY3RybC0+Y29udHJvbGxl
ci53cSk7DQogICAgICAgICAgICAgICAgZnNsX2xiY19jdHJsX2Rldi0+bmFuZCA9IGVsYmNfZmNt
X2N0cmw7DQogICAgICAgIH0gZWxzZQ0KICAgICAgICAgICAgICAgIGVsYmNfZmNtX2N0cmwgPSBm
c2xfbGJjX2N0cmxfZGV2LT5uYW5kOw0KICAgICAgICBtdXRleF91bmxvY2soJmZzbF9sYmNfbXV0
ZXgpOw0KDQogICAgICAgIGVsYmNfZmNtX2N0cmwtPmNoaXBzW2JhbmtdID0gcHJpdjsNCi4uLg0K
fQ0KDQpBbnkgY29tbWVudD8NClRoYW5rcy4NClJveQ0KDQoNCg0K
^ permalink raw reply
* Re: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Anton Vorontsov @ 2010-09-16 10:14 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <3850A844E6A3854C827AC5C0BEC7B60A1FC6DB@zch01exm23.fsl.freescale.net>
On Thu, Sep 16, 2010 at 06:08:14PM +0800, Zang Roy-R61911 wrote:
[...]
> Interesting.
> How about this?
> #include <stdio.h>
> #include <malloc.h>
>
> char *foo;
>
> void probe(void)
> {
> char *bar = NULL;
>
> if (!foo) {
> bar = malloc(sizeof(*bar));
> if (!bar)
> return;
> foo = bar;
> } else
> bar = foo;
This willl work of course; but I'd write it as
foo_lock();
if (!foo)
foo = alloc();
foo_unlock();
bar = foo;
bar->baz;
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* RE: [PATCH 2/3 v3] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Zang Roy-R61911 @ 2010-09-16 10:08 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <20100916092551.GA17548@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIFNlcHRl
bWJlciAxNiwgMjAxMCAxNzoyNiBQTQ0KPiBUbzogWmFuZyBSb3ktUjYxOTExDQo+IENjOiBsaW51
eC1tdGRAbGlzdHMuaW5mcmFkZWFkLm9yZzsgZHdtdzJAaW5mcmFkZWFkLm9yZzsgZGVkZWtpbmQx
QGdtYWlsLmNvbTsNCj4gYWtwbUBsaW51eC1mb3VuZGF0aW9uLm9yZzsgTGFuIENodW5oZS1CMjU4
MDY7IFdvb2QgU2NvdHQtQjA3NDIxOyBHYWxhIEt1bWFyLQ0KPiBCMTE3ODA7IGxpbnV4cHBjLWRl
dkBvemxhYnMub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMi8zIHYzXSBQNDA4MC9tdGQ6IE9u
bHkgbWFrZSBlbGJjIG5hbmQgZHJpdmVyIGRldGVjdCBuYW5kDQo+IGZsYXNoIHBhcnRpdGlvbnMN
Cj4gDQo+IE9uIFRodSwgU2VwIDE2LCAyMDEwIGF0IDA0OjUwOjA1UE0gKzA4MDAsIFphbmcgUm95
LVI2MTkxMSB3cm90ZToNCj4gPiA+IE9uIFRodSwgU2VwIDE2LCAyMDEwIGF0IDAyOjQxOjIzUE0g
KzA4MDAsIFJveSBaYW5nIHdyb3RlOg0KPiA+ID4gWy4uLl0NCj4gPiA+ID4gLXN0YXRpYyBpbnQg
X19kZXZpbml0IGZzbF9lbGJjX2NoaXBfcHJvYmUoc3RydWN0IGZzbF9lbGJjX2N0cmwgKmN0cmws
DQo+ID4gPiA+IC0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBk
ZXZpY2Vfbm9kZSAqbm9kZSkNCj4gPiA+ID4gKy8qDQo+ID4gPiA+ICsgKiBDdXJyZW50bHkgb25s
eSBvbmUgZWxiYyBwcm9iZSBpcyBzdXBwb3J0ZWQuDQo+ID4gPiA+ICsgKi8NCj4gPiA+ID4gK3N0
YXRpYyBpbnQgX19kZXZpbml0IGZzbF9lbGJjX25hbmRfcHJvYmUoc3RydWN0IHBsYXRmb3JtX2Rl
dmljZSAqZGV2KQ0KPiA+ID4gPiAgew0KPiA+ID4gPiAtICAgICBzdHJ1Y3QgZnNsX2xiY19yZWdz
IF9faW9tZW0gKmxiYyA9IGN0cmwtPnJlZ3M7DQo+ID4gPiA+ICsgICAgIHN0cnVjdCBmc2xfbGJj
X3JlZ3MgX19pb21lbSAqbGJjOw0KPiA+ID4gPiAgICAgICBzdHJ1Y3QgZnNsX2VsYmNfbXRkICpw
cml2Ow0KPiA+ID4gPiAgICAgICBzdHJ1Y3QgcmVzb3VyY2UgcmVzOw0KPiA+ID4gPiArICAgICBz
dHJ1Y3QgZnNsX2VsYmNfZmNtX2N0cmwgKmVsYmNfZmNtX2N0cmwgPSBOVUxMOw0KPiA+ID4gWy4u
Ll0NCj4gPiA+ID4gLSAgICAgY3RybC0+Y2hpcHNbYmFua10gPSBwcml2Ow0KPiA+ID4gPiArICAg
ICBpZiAoZnNsX2xiY19jdHJsX2Rldi0+bmFuZCA9PSBOVUxMKSB7DQo+ID4gPiA+ICsgICAgICAg
ICAgICAgZWxiY19mY21fY3RybCA9IGt6YWxsb2Moc2l6ZW9mKCplbGJjX2ZjbV9jdHJsKSwNCj4g
R0ZQX0tFUk5FTCk7DQo+ID4gPiA+ICsgICAgICAgICAgICAgaWYgKCFlbGJjX2ZjbV9jdHJsKSB7
DQo+ID4gPiBbLi4uXQ0KPiA+ID4gPiArICAgICAgICAgICAgICAgICAgICAgZ290byBlcnI7DQo+
ID4gPiA+ICsgICAgICAgICAgICAgfQ0KPiA+ID4gPiArICAgICAgICAgICAgIGZzbF9sYmNfY3Ry
bF9kZXYtPm5hbmQgPSBlbGJjX2ZjbV9jdHJsOw0KPiA+ID4gPiArICAgICB9DQo+ID4gPiA+ICsN
Cj4gPiA+ID4gKyAgICAgZWxiY19mY21fY3RybC0+Y2hpcHNbYmFua10gPSBwcml2Ow0KPiA+ID4N
Cj4gPiA+IEFnYWluLCB0aGlzIHdpbGwgb29wcyBvbiB0aGUgc2Vjb25kIHByb2JlLg0KPiA+IFdo
eT8NCj4gDQo+IEJlY2F1c2Ugb2YgYSBOVUxMIGRlcmVmZXJlbmNlICgiZWxiY19mY21fY3RybC0+
IikuDQo+IA0KPiBJIHVuZGVyc3RhbmQgdGhhdCB5b3UgZG9uJ3QgaGF2ZSB0byBiZWxpZXZlIG1l
LCBidXQgd2lsbCB5b3UgYmVsaWV2ZQ0KPiBhIGNvbXBpbGVyPw0KPiANCj4gb2tzYW5hOn4kIGNh
dCBhLmMNCj4gI2luY2x1ZGUgPHN0ZGlvLmg+DQo+ICNpbmNsdWRlIDxtYWxsb2MuaD4NCj4gDQo+
IGNoYXIgKmZvbzsNCj4gDQo+IHZvaWQgcHJvYmUodm9pZCkNCj4gew0KPiAgICAgICAgIGNoYXIg
KmJhciA9IE5VTEw7DQo+IA0KPiAgICAgICAgIGlmICghZm9vKSB7DQo+ICAgICAgICAgICAgICAg
ICBiYXIgPSBtYWxsb2Moc2l6ZW9mKCpiYXIpKTsNCj4gICAgICAgICAgICAgICAgIGlmICghYmFy
KQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICByZXR1cm47DQo+ICAgICAgICAgICAgICAgICBm
b28gPSBiYXI7DQo+ICAgICAgICAgfQ0KPiAgICAgICAgICpiYXIgPSAnYSc7DQo+IH0NCj4gDQo+
IGludCBtYWluKHZvaWQpDQo+IHsNCj4gICAgICAgICBwcm9iZSgpOw0KPiAgICAgICAgIHByb2Jl
KCk7DQo+ICAgICAgICAgcmV0dXJuIDA7DQo+IH0NCj4gb2tzYW5hOn4kIGdjYyBhLmMgJiYgLi9h
Lm91dA0KPiBTZWdtZW50YXRpb24gZmF1bHQNCkludGVyZXN0aW5nLg0KSG93IGFib3V0IHRoaXM/
DQojaW5jbHVkZSA8c3RkaW8uaD4NCiNpbmNsdWRlIDxtYWxsb2MuaD4NCg0KY2hhciAqZm9vOw0K
DQp2b2lkIHByb2JlKHZvaWQpDQp7DQogICAgICAgIGNoYXIgKmJhciA9IE5VTEw7DQoNCiAgICAg
ICAgaWYgKCFmb28pIHsNCiAgICAgICAgICAgICAgICBiYXIgPSBtYWxsb2Moc2l6ZW9mKCpiYXIp
KTsNCiAgICAgICAgICAgICAgICBpZiAoIWJhcikNCiAgICAgICAgICAgICAgICAgICAgICAgIHJl
dHVybjsNCiAgICAgICAgICAgICAgICBmb28gPSBiYXI7DQogICAgICAgIH0gZWxzZQ0KCQkgICBi
YXIgPSBmb287CSAgDQogICAgICAgICpiYXIgPSAnYSc7DQp9DQoNCmludCBtYWluKHZvaWQpDQp7
DQogICAgICAgIHByb2JlKCk7DQogICAgICAgIHByb2JlKCk7DQogICAgICAgIHJldHVybiAwOw0K
fQ0KDQo=
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox