* Re: [PATCH 2/4] wimax: fix kconfig interactions with rfkill and input layers
From: David Miller @ 2009-01-08 19:07 UTC (permalink / raw)
To: inaky
Cc: netdev, wimax, greg, randy.dunlap, sfr, linux-next, linux-kernel,
linux-wimax
In-Reply-To: <f0f7dc5763046cc336ca087a2525c8b52811ddb4.1231355768.git.inaky@linux.intel.com>
From: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Date: Wed, 7 Jan 2009 11:22:20 -0800
> WiMAX can work without RFKILL, but it was missing a check to make sure
> RFKILL is not being made a module with wimax compiled into the
> kernel. This caused failed builds in s390, where CONFIG_INPUT is
> always off.
>
> When RFKILL is enabled, the code uses the input layer to report
> hardware switch changes; thus, if RFKILL is enabled, INPUT has to be
> too. It also needs to display some message when INPUT is disabled that
> explains why WiMAX is not selectable.
>
> (issues found by Randy Dunlap in the linux-next tree).
>
> Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/4] wimax: testing for rfkill support should also test for CONFIG_RFKILL_MODULE
From: David Miller @ 2009-01-08 19:08 UTC (permalink / raw)
To: inaky
Cc: randy.dunlap, sfr, wimax, netdev, linux-kernel, linux-wimax,
linux-next, greg
In-Reply-To: <ce4d7f71df1471d502e02861a7db65cbb2a5548f.1231355768.git.inaky@linux.intel.com>
From: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Date: Wed, 7 Jan 2009 11:22:21 -0800
> Current WiMAX rfkill code is missing the case where rfkill is compiled
> in as modules and works only when rfkill is compiled in. This is not
> correct. Fixed to test for CONFIG_RFKILL or CONFIG_RKILL_MODULE.
>
> Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH 4/4] i2400m/usb: wrap USB power saving in #ifdef CONFIG_PM
From: David Miller @ 2009-01-08 19:08 UTC (permalink / raw)
To: inaky
Cc: netdev, wimax, greg, randy.dunlap, sfr, linux-next, linux-kernel,
linux-wimax
In-Reply-To: <0e511f3772ac9887551bec34ee682fa5bf63fb69.1231355768.git.inaky@linux.intel.com>
From: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Date: Wed, 7 Jan 2009 11:22:22 -0800
> Current code was assuming PM was always enabled, which is not
> correct. Code which accesses members in the struct usb_device that are
> dependant on CONFIG_PM must be protected the same.
>
> Reported by Randy Dunlap from a build error in the linux-next tree on
> 07/01/2009.
>
> Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Also applied, thanks a lot.
^ permalink raw reply
* Re: linux-next: Tree for January 8 (multimedia/cx88)
From: Mauro Carvalho Chehab @ 2009-01-08 20:14 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, linux-media
In-Reply-To: <49663B74.6010707@oracle.com>
On Thu, 08 Jan 2009 09:44:20 -0800
Randy Dunlap <randy.dunlap@oracle.com> wrote:
>
> linux-next-20090108/drivers/media/video/cx88/cx88-i2c.c: In function 'cx88_call_i2c_clients':
> linux-next-20090108/drivers/media/video/cx88/cx88-i2c.c:122: error: 'struct cx88_core' has no member named 'gate_ctrl'
> linux-next-20090108/drivers/media/video/cx88/cx88-i2c.c:123: error: 'struct cx88_core' has no member named 'gate_ctrl'
> linux-next-20090108/drivers/media/video/cx88/cx88-i2c.c:127: error: 'struct cx88_core' has no member named 'gate_ctrl'
> linux-next-20090108/drivers/media/video/cx88/cx88-i2c.c:128: error: 'struct cx88_core' has no member named 'gate_ctrl'
Grrr... a small trivial bug... Anyway, trival to fix also.
Cheers,
Mauro
^ permalink raw reply
* Re: linux-next: manual merge of the rr tree
From: Andi Kleen @ 2009-01-08 20:48 UTC (permalink / raw)
To: Christoph Lameter
Cc: Andi Kleen, Rusty Russell, Stephen Rothwell, linux-next,
Mike Travis, Ingo Molnar, Richard Henderson, akpm
In-Reply-To: <Pine.LNX.4.64.0901071300430.8329@quilx.com>
On Wed, Jan 07, 2009 at 01:01:06PM -0600, Christoph Lameter wrote:
> On Wed, 7 Jan 2009, Andi Kleen wrote:
>
> > The C standard says that arithmetic on pointers in defined objects outside
> > the boundaries of these objects (except for the special case of one beyond
> > the end for arrays) is undefined. The gcc optimizers take advantage
> > of this by assuming that such arithmetic doesn't wrap (and might have other
> > assumptions)
>
> Ok then we need to say so in a comment around RELOC_HIDE.
Here's a patch to do that. Andrew, please add it.
-Andi
---
Add more comments to RELOC_HIDE
Requested by C. Lameter
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
include/linux/compiler-gcc.h | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
Index: linux-2.6.28-test/include/linux/compiler-gcc.h
===================================================================
--- linux-2.6.28-test.orig/include/linux/compiler-gcc.h 2008-05-08 12:56:10.000000000 +0200
+++ linux-2.6.28-test/include/linux/compiler-gcc.h 2009-01-08 21:31:55.000000000 +0100
@@ -11,9 +11,19 @@
/* The "volatile" is due to gcc bugs */
#define barrier() __asm__ __volatile__("": : :"memory")
-/* This macro obfuscates arithmetic on a variable address so that gcc
- shouldn't recognize the original var, and make assumptions about it */
-/*
+/*
+ * This macro obfuscates arithmetic on a variable address so that gcc
+ * shouldn't recognize the original var, and make assumptions about it.
+ *
+ * This is needed because the C standard makes it undefined to do
+ * pointer arithmetic on "objects" outside their boundaries and the
+ * gcc optimizers assume this is the case. In particular they
+ * assume such arithmetic does not wrap.
+ *
+ * A miscompilation has been observed because of this on PPC.
+ * To work around it we hide the relationship of the pointer and the object
+ * using this macro.
+ *
* Versions of the ppc64 compiler before 4.1 had a bug where use of
* RELOC_HIDE could trash r30. The bug can be worked around by changing
* the inline assembly constraint from =g to =r, in this particular
--
ak@linux.intel.com
^ permalink raw reply
* Re: linux-next: manual merge of the rr tree
From: Andrew Morton @ 2009-01-08 20:50 UTC (permalink / raw)
Cc: cl, andi, rusty, sfr, linux-next, travis, mingo, rth
In-Reply-To: <20090108204835.GI496@one.firstfloor.org>
On Thu, 8 Jan 2009 21:48:35 +0100
Andi Kleen <andi@firstfloor.org> wrote:
> +/*
> + * This macro obfuscates arithmetic on a variable address so that gcc
> + * shouldn't recognize the original var, and make assumptions about it.
> + *
> + * This is needed because the C standard makes it undefined to do
> + * pointer arithmetic on "objects" outside their boundaries and the
> + * gcc optimizers assume this is the case. In particular they
> + * assume such arithmetic does not wrap.
> + *
> + * A miscompilation has been observed because of this on PPC.
> + * To work around it we hide the relationship of the pointer and the object
> + * using this macro.
> + *
wow, thanks. I always wondered.
^ permalink raw reply
* Re: linux-next: manual merge of the rr tree
From: Christoph Lameter @ 2009-01-08 21:15 UTC (permalink / raw)
To: Andi Kleen
Cc: Rusty Russell, Stephen Rothwell, linux-next, Mike Travis,
Ingo Molnar, Richard Henderson, akpm
In-Reply-To: <20090108204835.GI496@one.firstfloor.org>
This also then means that RELOC_HIDE can simply be pointer arithmetic on
non PPC, right?
Reviewed-by: Christoph Lameter <cl@linux-foundation.org>
^ permalink raw reply
* Re: linux-next: manual merge of the rr tree
From: Andi Kleen @ 2009-01-08 21:49 UTC (permalink / raw)
To: Christoph Lameter
Cc: Andi Kleen, Rusty Russell, Stephen Rothwell, linux-next,
Mike Travis, Ingo Molnar, Richard Henderson, akpm
In-Reply-To: <Pine.LNX.4.64.0901081514360.13768@quilx.com>
On Thu, Jan 08, 2009 at 03:15:48PM -0600, Christoph Lameter wrote:
> This also then means that RELOC_HIDE can simply be pointer arithmetic on
> non PPC, right?
No, the C standard and the gcc optimizer are the same on all architectures.
-Andi
--
ak@linux.intel.com
^ permalink raw reply
* Re: linux-next: manual merge of the rr tree
From: Christoph Lameter @ 2009-01-08 22:21 UTC (permalink / raw)
To: Andi Kleen
Cc: Rusty Russell, Stephen Rothwell, linux-next, Mike Travis,
Ingo Molnar, Richard Henderson, akpm
In-Reply-To: <20090108214908.GJ496@one.firstfloor.org>
On Thu, 8 Jan 2009, Andi Kleen wrote:
> On Thu, Jan 08, 2009 at 03:15:48PM -0600, Christoph Lameter wrote:
> > This also then means that RELOC_HIDE can simply be pointer arithmetic on
> > non PPC, right?
>
> No, the C standard and the gcc optimizer are the same on all architectures.
The wrapping is okay on platforms that use straight 2 complement without
additional tricks in high bits. Some platforms do not wrap.
No need to stop the cc optimizer from optimizing pointer addition there.
The C compiler can generate more effective code if we do not go through
this asm segment. See how RELOC_HIDE is defined for the icc and
in include/linux/gcc.h.
Also: Would it not be better to rename RELOC_HIDE. To
ADD_POINTER_OFFSET_BEYOND_OBJECT_BOUNDARY or so?
What are the following uses of RELOC_HIDE to add a zero offset. Certainly
they have nothing to do with wrapping.
arch/mips/include/asm/page.h:#define __pa_symbol(x)
__pa(RELOC_HIDE((unsigned long)(x), 0))
arch/sh/include/asm/system.h: struct pt_regs *regs = RELOC_HIDE(&__regs,
0); \
arch/x86/include/asm/page_32.h:#define __phys_reloc_hide(x)
RELOC_HIDE((x), 0)
Guess we assume that GCC is passing some magic with a pointer that is
not lost when casting it?
What kind of magical properties are these? Address invalidation is messed
up in gcc and just icc does it right?
^ permalink raw reply
* Re: linux-next: Tree for January 8 (percpu)
From: Stephen Rothwell @ 2009-01-08 22:23 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next, LKML, Randy Dunlap
In-Reply-To: <496636AB.9000903@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]
(Forward to Rusty)
On Thu, 08 Jan 2009 09:23:55 -0800 Randy Dunlap <randy.dunlap@oracle.com> wrote:
>
> Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20090107:
> >
> > Undropped tree:
> > rr
> >
> > Dropped trees (temporarily):
> > ocfs2 (build problem)
> > cpu_alloc (build problem)
>
>
> When CONFIG_SMP=n, both arch/x86/include/asm/percpu.h and
> include/asm-generic/percpu.h define both of
> read_percpu_ptr() and read_percpu_var().
>
>
> build-r8079.out:linux-next-20090108/include/asm-generic/percpu.h:124:1: warning: "read_percpu_ptr" redefined
> build-r8079.out:linux-next-20090108/arch/x86/include/asm/percpu.h:107:1: warning: this is the location of the previous definition
> build-r8079.out:linux-next-20090108/include/asm-generic/percpu.h:120:1: warning: "read_percpu_var" redefined
> build-r8079.out:linux-next-20090108/arch/x86/include/asm/percpu.h:106:1: warning: this is the location of the previous definition
>
>
>
> --
> ~Randy
>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: import of rr tree failed
From: Stephen Rothwell @ 2009-01-08 22:24 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
Hi Rusty,
The import of the rr tree this morning failed like this:
cpualloc:documentation.patch
cpualloc:get_cpu_ptr.patch
error: patch failed: arch/alpha/include/asm/percpu.h:71
error: arch/alpha/include/asm/percpu.h: patch does not apply
error: patch failed: include/asm-generic/percpu.h:82
error: include/asm-generic/percpu.h: patch does not apply
I will use yesterday's tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the rr tree
From: David Miller @ 2009-01-08 22:25 UTC (permalink / raw)
To: cl; +Cc: andi, rusty, sfr, linux-next, travis, mingo, rth, akpm
In-Reply-To: <Pine.LNX.4.64.0901081539360.14124@quilx.com>
From: Christoph Lameter <cl@linux-foundation.org>
Date: Thu, 8 Jan 2009 16:21:32 -0600 (CST)
> On Thu, 8 Jan 2009, Andi Kleen wrote:
>
> > On Thu, Jan 08, 2009 at 03:15:48PM -0600, Christoph Lameter wrote:
> > > This also then means that RELOC_HIDE can simply be pointer arithmetic on
> > > non PPC, right?
> >
> > No, the C standard and the gcc optimizer are the same on all architectures.
>
> The wrapping is okay on platforms that use straight 2 complement without
> additional tricks in high bits. Some platforms do not wrap.
It's not okay for loop termination conditions and that's where GCC
takes advantage of this invariant.
Otherwise, if overflow is possible, tranforming an array index
comparison into a pointer comparison is no longer legal.
^ permalink raw reply
* linux-next: manual merge of the rr tree
From: Stephen Rothwell @ 2009-01-09 1:53 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next, Nathan Lynch, Benjamin Herrenschmidt, ppc-dev
[-- Attachment #1: Type: text/plain, Size: 684 bytes --]
Hi Rusty,
Today's linux-next merge of the rr tree got a conflict in
arch/powerpc/kernel/sysfs.c between commit
93197a36a9c16a85fb24cf5a8639f7bf9af838a3 ("powerpc: Rewrite sysfs
processor cache info code") from Linus' tree and commit
013ab448cec493262080ecc47b13e0adbcfaeccd ("cpualloc:rename-per_cpu-vars")
from the rr tree.
The former moved the code modified by the latter into another file and
rewrote it. This is part of the code churn that should not be happening
in linux-next during the merge window. :-(
I have dropped the rr tree for today, sorry.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: ocfs2 tree build failure
From: Mark Fasheh @ 2009-01-09 2:05 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Sunil Mushran
In-Reply-To: <20090108130158.d222ceea.sfr@canb.auug.org.au>
On Thu, Jan 08, 2009 at 01:01:58PM +1100, Stephen Rothwell wrote:
> Hi Mark,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> fs/ocfs2/super.c: In function 'ocfs2_osb_dump':
> fs/ocfs2/super.c:256: error: dereferencing pointer to incomplete type
> fs/ocfs2/super.c:256: error: dereferencing pointer to incomplete type
> fs/ocfs2/super.c:256: error: dereferencing pointer to incomplete type
> fs/ocfs2/super.c:259: error: dereferencing pointer to incomplete type
> fs/ocfs2/super.c:261: error: dereferencing pointer to incomplete type
This should be fixed now. Thanks for letting me know.
--Mark
--
Mark Fasheh
^ permalink raw reply
* linux-next: Tree for January 9
From: Stephen Rothwell @ 2009-01-09 4:27 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 6791 bytes --]
Hi all,
Changes since 20090108:
Dropped trees (temporarily):
ocfs2 (build problem)
rr (difficult conflict)
cpu_alloc (build problem)
audit (difficult conflicts)
The rr tree gained a difficult conflict against Linus' tree and was
dropped.
The nommu tree lost a conflict.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig,
ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES) and
i386, sparc and sparc64 defconfig.
Below is a summary of the state of the merge.
We are up to 129 trees (counting Linus' and 15 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
CONFLICT (content): Merge conflict in drivers/char/tty_audit.c
CONFLICT (content): Merge conflict in kernel/auditsc.c
Merging dwmw2/master
Merging arm/devel
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging mips/mips-for-linux-next
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging pxa/for-next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging x86/auto-x86-next
Merging xtensa/master
Merging quilt/driver-core
Merging quilt/usb
Merging tip-core/auto-core-next
Merging cpus4096/auto-cpus4096-next
CONFLICT (content): Merge conflict in kernel/rcuclassic.c
Merging ftrace/auto-ftrace-next
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
CONFLICT (content): Merge conflict in kernel/time/tick-common.c
Merging pci/linux-next
Merging quilt/device-mapper
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
Merging libata/NEXT
Merging nfs/linux-next
Merging xfs/master
Merging infiniband/for-next
Merging acpi/test
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
CONFLICT (content): Merge conflict in drivers/scsi/scsi_ioctl.c
CONFLICT (content): Merge conflict in drivers/scsi/sd.c
Merging ocfs2/linux-next
$ git reset --hard HEAD^
Merging ext4/next
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging mtd/master
CONFLICT (content): Merge conflict in drivers/mtd/devices/m25p80.c
CONFLICT (content): Merge conflict in drivers/mtd/devices/mtd_dataflash.c
Merging wireless/master
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
Merging cpufreq/next
Merging v9fs/for-next
Merging quilt/rr
CONFLICT (content): Merge conflict in arch/powerpc/kernel/sysfs.c
CONFLICT (content): Merge conflict in init/main.c
CONFLICT (content): Merge conflict in kernel/module.c
$ git reset --hard
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging bkl-removal/bkl-removal
CONFLICT (content): Merge conflict in fs/ioctl.c
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in drivers/net/e100.c
CONFLICT (content): Merge conflict in drivers/net/starfire.c
CONFLICT (content): Merge conflict in drivers/net/tg3.c
CONFLICT (content): Merge conflict in firmware/Makefile
CONFLICT (content): Merge conflict in firmware/WHENCE
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging kmemcheck/auto-kmemcheck-next
CONFLICT (content): Merge conflict in MAINTAINERS
Merging generic-ipi/auto-generic-ipi-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging quilt/ttydev
Merging agp/agp-next
Merging oprofile/auto-oprofile-next
Merging fastboot/auto-fastboot-next
Merging sparseirq/auto-sparseirq-next
Merging iommu/auto-iommu-next
Merging uwb/for-upstream
Merging watchdog/master
Merging proc/proc
Merging bdev/master
Merging dwmw2-iommu/master
CONFLICT (content): Merge conflict in drivers/pci/intel-iommu.c
CONFLICT (content): Merge conflict in include/linux/dma_remapping.h
Merging cputime/cputime
Merging osd/linux-next
Merging fatfs/master
Merging fuse/for-next
Merging jc_docs/docs-next
Merging nommu/master
CONFLICT (content): Merge conflict in kernel/fork.c
Merging trivial/for-next
Merging squashfs/master
Merging quilt/staging
Merging scsi-post-merge/master
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the rr tree
From: Christoph Lameter @ 2009-01-09 14:42 UTC (permalink / raw)
To: David Miller; +Cc: andi, rusty, sfr, linux-next, travis, mingo, rth, akpm
In-Reply-To: <20090108.142510.263686170.davem@davemloft.net>
On Thu, 8 Jan 2009, David Miller wrote:
> > The wrapping is okay on platforms that use straight 2 complement without
> > additional tricks in high bits. Some platforms do not wrap.
>
> It's not okay for loop termination conditions and that's where GCC
> takes advantage of this invariant.
Can you give me a concrete code example?
> Otherwise, if overflow is possible, tranforming an array index
> comparison into a pointer comparison is no longer legal.
This means that access to an object immediately before or after would wrap
around. If the object is not near 0 or near the end of the address space
then such a thing cannot occur. We have the ZERO page at address 0 so the
lower end is taken care and usually there are also special uses for very
high addresses.
The wrapping is mainly an issue if the percpu area is linked to very high
addresses but later the per cpu areas for the individual processors are
allocated on relatively low addresses. The address calculation of the
location of a percpu address for a particular cpu then occurs by
adding an offset that will wrap around zero. This is fine on x86.
^ permalink raw reply
* Re: linux-next: Tree for January 6 (MTD)
From: Randy Dunlap @ 2009-01-09 21:48 UTC (permalink / raw)
To: Alexey Korolev
Cc: Stephen Rothwell, linux-next, LKML, David Woodhouse,
Vasiliy Leonenko, Linus Torvalds
In-Reply-To: <alpine.LFD.2.00.0901061632590.4300@casper.infradead.org>
This commit was just merged:
Gitweb: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=60f26520e7bd4479dbebf77317c45fc2255ba2e8
Commit: 60f26520e7bd4479dbebf77317c45fc2255ba2e8
Parent: d81408304b06a71c28417445202af9cd6673168d
Author: Alexey Korolev <akorolev@infradead.org>
AuthorDate: Tue Dec 16 18:24:14 2008 +0000
Committer: David Woodhouse <David.Woodhouse@intel.com>
CommitDate: Mon Jan 5 13:58:47 2009 +0100
[MTD] LPDDR Makefile and KConfig
but the patch below is missing/still needed.
Alexey Korolev wrote:
> Hi Randy,
>
>> # CONFIG_MTD_LPDDR is not set
>> CONFIG_MTD_QINFO_PROBE=y
>>
>> There appears to be too little control/coordination between those
>> two kconfig symbols. Surely one of them (MTD_QINFO_PROBE) should
>> depend on the other (MTD_LPDDR). And why even build 2 modules
>> when MTD_QINFO_PROBE is enabled? Why not combine the code into
>> one module?
> Thanks a lot for good finding. Here is a fix for the problem.
>
> About combining: it is assumed to have one QINFO probing module for several
> kinds of LPDDR command set drivers. If we combine two modules into
> one it would make further extension rather hard. So it is better to have
> two modules.
> To fix a problem I just added dependency in Kconfig file.
> This temporary fix which will work until we have just one cmdset module.
> In near future we will make a fix which parse command set types
> and select proper driver according to device type.
>
> Thanks,
> Alexey
>
> Signed-off-by: Alexey Korolev <akorolev@infradead.org>
> ---
> diff --git a/drivers/mtd/lpddr/Kconfig b/drivers/mtd/lpddr/Kconfig
> index acd4ea9..5a401d8 100644
> --- a/drivers/mtd/lpddr/Kconfig
> +++ b/drivers/mtd/lpddr/Kconfig
> @@ -12,6 +12,7 @@ config MTD_LPDDR
> DDR memories, intended for battery-operated systems.
>
> config MTD_QINFO_PROBE
> + depends on MTD_LPDDR
> tristate "Detect flash chips by QINFO probe"
> help
> Device Information for LPDDR chips is offered through the Overlay
>
>
--
~Randy
^ permalink raw reply
* Re: linux-next: manual merge of the rr tree
From: David Miller @ 2009-01-09 22:54 UTC (permalink / raw)
To: cl; +Cc: andi, rusty, sfr, linux-next, travis, mingo, rth, akpm
In-Reply-To: <Pine.LNX.4.64.0901090836530.32079@quilx.com>
From: Christoph Lameter <cl@linux-foundation.org>
Date: Fri, 9 Jan 2009 08:42:09 -0600 (CST)
> On Thu, 8 Jan 2009, David Miller wrote:
>
> > Otherwise, if overflow is possible, tranforming an array index
> > comparison into a pointer comparison is no longer legal.
>
> This means that access to an object immediately before or after would wrap
> around. If the object is not near 0 or near the end of the address space
> then such a thing cannot occur. We have the ZERO page at address 0 so the
> lower end is taken care and usually there are also special uses for very
> high addresses.
GCC, or any compiler, cannot know about such invariants.
What it does know is that it can always transform
comparisons between "i" and "max_i" into comparisons
between '&array[i]' and '&array[max_i]'
> The wrapping is mainly an issue if the percpu area is linked to very high
> addresses but later the per cpu areas for the individual processors are
> allocated on relatively low addresses. The address calculation of the
> location of a percpu address for a particular cpu then occurs by
> adding an offset that will wrap around zero. This is fine on x86.
Anyways, the original reason for the RELOC_HIDE business is that GCC
would do common subexpression elimination on the address computation.
The percpu stuff was a calculation using a symbol address as some kind
of base, and GCC took liberties with that (which were legal given
the amount of information we (weren't) giving to it).
I honestly forget the exact details, I'm sure Rusty could explain...
^ permalink raw reply
* [PATCH] cacheinfo: rename cache_dir per-cpu variable
From: Nathan Lynch @ 2009-01-09 23:12 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Rusty Russell, linux-next, Benjamin Herrenschmidt, ppc-dev
In-Reply-To: <20090109125327.351b7f65.sfr@canb.auug.org.au>
The per_cpu__ prefix on DECLARE_PER_CPU'd variables is going away;
rename cache_dir to cache_dir_pcpu.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/kernel/cacheinfo.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
Not sure which route this should go, I assume either Rusty or Ben will
take it?
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index b33f041..bb37b1d 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -113,7 +113,7 @@ struct cache {
struct cache *next_local; /* next cache of >= level */
};
-static DEFINE_PER_CPU(struct cache_dir *, cache_dir);
+static DEFINE_PER_CPU(struct cache_dir *, cache_dir_pcpu);
/* traversal/modification of this list occurs only at cpu hotplug time;
* access is serialized by cpu hotplug locking
@@ -468,9 +468,9 @@ static struct cache_dir *__cpuinit cacheinfo_create_cache_dir(unsigned int cpu_i
cache_dir->kobj = kobj;
- WARN_ON_ONCE(per_cpu(cache_dir, cpu_id) != NULL);
+ WARN_ON_ONCE(per_cpu(cache_dir_pcpu, cpu_id) != NULL);
- per_cpu(cache_dir, cpu_id) = cache_dir;
+ per_cpu(cache_dir_pcpu, cpu_id) = cache_dir;
return cache_dir;
err:
@@ -820,13 +820,13 @@ void cacheinfo_cpu_offline(unsigned int cpu_id)
/* Prevent userspace from seeing inconsistent state - remove
* the sysfs hierarchy first */
- cache_dir = per_cpu(cache_dir, cpu_id);
+ cache_dir = per_cpu(cache_dir_pcpu, cpu_id);
/* careful, sysfs population may have failed */
if (cache_dir)
remove_cache_dir(cache_dir);
- per_cpu(cache_dir, cpu_id) = NULL;
+ per_cpu(cache_dir_pcpu, cpu_id) = NULL;
/* clear the CPU's bit in its cache chain, possibly freeing
* cache objects */
^ permalink raw reply related
* Re: linux-next: Tree for January 8 (percpu)
From: Rusty Russell @ 2009-01-10 6:18 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, Randy Dunlap
In-Reply-To: <20090109092322.fd43b3b6.sfr@canb.auug.org.au>
On Friday 09 January 2009 08:53:22 Stephen Rothwell wrote:
> (Forward to Rusty)
>
> On Thu, 08 Jan 2009 09:23:55 -0800 Randy Dunlap <randy.dunlap@oracle.com> wrote:
> >
> > Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Changes since 20090107:
> > >
> > > Undropped tree:
> > > rr
> > >
> > > Dropped trees (temporarily):
> > > ocfs2 (build problem)
> > > cpu_alloc (build problem)
> >
> >
> > When CONFIG_SMP=n, both arch/x86/include/asm/percpu.h and
> > include/asm-generic/percpu.h define both of
> > read_percpu_ptr() and read_percpu_var().
Erk... this header is a bit of a mess of 64bit/32bit UP/SMP defines.
I've thwacked it harder, thanks!
Rusty.
^ permalink raw reply
* Re: [PATCH -next] jbd2: fix printk format warning
From: Simon Holm Thøgersen @ 2009-01-11 18:52 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, akpm, linux-next, LKML, linux-ext4
In-Reply-To: <20090105121158.94d990c3.randy.dunlap@oracle.com>
man, 05 01 2009 kl. 12:11 -0800, skrev Randy Dunlap:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix jbd2 printk format:
>
> fs/jbd2/journal.c:848: warning: format '%lu' expects type 'long unsigned int',
> but argument 3 has type 'uint32_t'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> ---
> fs/jbd2/journal.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- linux-next-20090105.orig/fs/jbd2/journal.c
> +++ linux-next-20090105/fs/jbd2/journal.c
> @@ -845,7 +845,8 @@ static int jbd2_seq_info_show(struct seq
> seq_printf(seq, " %ums logging transaction\n",
> jiffies_to_msecs(s->stats->u.run.rs_logging / s->stats->ts_tid));
> seq_printf(seq, " %luus average transaction commit time\n",
> - do_div(s->journal->j_average_commit_time, 1000));
> + (unsigned long)do_div(s->journal->j_average_commit_time,
> + 1000));
> seq_printf(seq, " %lu handles per transaction\n",
> s->stats->u.run.rs_handle_count / s->stats->ts_tid);
> seq_printf(seq, " %lu blocks per transaction\n",
This patch is just as wrong as the original code. Please don't
apply it, but see my "[PATCH] jbd2: fix wrong use of do_div"
that I just sent out.
Simon Holm Thøgersen
^ permalink raw reply
* Re: [PATCH -next] jbd2: fix printk format warning
From: Randy Dunlap @ 2009-01-11 19:07 UTC (permalink / raw)
To: Simon Holm Thøgersen
Cc: Randy Dunlap, Stephen Rothwell, akpm, linux-next, LKML,
linux-ext4
In-Reply-To: <1231699973.17759.22.camel@odie.local>
Simon Holm Thøgersen wrote:
> man, 05 01 2009 kl. 12:11 -0800, skrev Randy Dunlap:
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>
>> Fix jbd2 printk format:
>>
>> fs/jbd2/journal.c:848: warning: format '%lu' expects type 'long unsigned int',
>> but argument 3 has type 'uint32_t'
>>
>> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
>> ---
>> fs/jbd2/journal.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> --- linux-next-20090105.orig/fs/jbd2/journal.c
>> +++ linux-next-20090105/fs/jbd2/journal.c
>> @@ -845,7 +845,8 @@ static int jbd2_seq_info_show(struct seq
>> seq_printf(seq, " %ums logging transaction\n",
>> jiffies_to_msecs(s->stats->u.run.rs_logging / s->stats->ts_tid));
>> seq_printf(seq, " %luus average transaction commit time\n",
>> - do_div(s->journal->j_average_commit_time, 1000));
>> + (unsigned long)do_div(s->journal->j_average_commit_time,
>> + 1000));
>> seq_printf(seq, " %lu handles per transaction\n",
>> s->stats->u.run.rs_handle_count / s->stats->ts_tid);
>> seq_printf(seq, " %lu blocks per transaction\n",
>
> This patch is just as wrong as the original code. Please don't
> apply it, but see my "[PATCH] jbd2: fix wrong use of do_div"
> that I just sent out.
ok, where did you send it? I don't see it...
--
~Randy
^ permalink raw reply
* Re: [PATCH -next] jbd2: fix printk format warning
From: Simon Holm Thøgersen @ 2009-01-11 19:20 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, akpm, linux-next, LKML, linux-ext4
In-Reply-To: <496A4361.5040807@oracle.com>
søn, 11 01 2009 kl. 11:07 -0800, skrev Randy Dunlap:
> ok, where did you send it? I don't see it...
It had a wrong recipient address so it never made it. I've sent it again
and verified that it made it this time.
Simon
^ permalink raw reply
* linux-next: origin tree build failure
From: Stephen Rothwell @ 2009-01-11 23:48 UTC (permalink / raw)
To: Linus Torvalds
Cc: Mike, David S. Miller, Rusty Russell, LKML, Travis, linuxppc-dev,
linux-next, Paul Mackerras, Andrew Morton, Ingo Molnar
[-- Attachment #1.1: Type: text/plain, Size: 1426 bytes --]
Hi Linus,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
arch/powerpc/platforms/pasemi/cpufreq.c: In function 'pas_cpufreq_cpu_init':
arch/powerpc/platforms/pasemi/cpufreq.c:216: error: incompatible types in assignment
arch/powerpc/platforms/powermac/cpufreq_64.c: In function 'g5_cpufreq_cpu_init':
arch/powerpc/platforms/powermac/cpufreq_64.c:365: error: incompatible types in assignment
arch/powerpc/platforms/cell/cbe_cpufreq.c: In function 'cbe_cpufreq_cpu_init':
arch/powerpc/platforms/cell/cbe_cpufreq.c:121: error: incompatible types in assignment
Caused by commit 835481d9bcd65720b473db6b38746a74a3964218 ("cpumask:
convert struct cpufreq_policy to cpumask_var_t") which missed updating
all the powerpc (at least) cpufreq drivers.
Reverting that one commit required fixups, so I reverted merge commit
4e9b1c184cadbece3694603de5f880b6e35bd7a7 ("Merge branch 'cpus4096-for-linus'
of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip")
instead.
I am hoping that this will be fixed soon and that revert doesn't
propagate more pain through today's linux-next.
This branch was last committed to in the tip tree on Jan 7 (the patch
above was committed on Jan 6) but was never propagated to linux-next
before being merged into your tree yesterday.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #2: Type: text/plain, Size: 146 bytes --]
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* linux-next: origin tree build failure
From: Stephen Rothwell @ 2009-01-11 23:48 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-next, Rusty Russell, Mike Travis, Ingo Molnar,
Andrew Morton, David S. Miller, LKML, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]
Hi Linus,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
arch/powerpc/platforms/pasemi/cpufreq.c: In function 'pas_cpufreq_cpu_init':
arch/powerpc/platforms/pasemi/cpufreq.c:216: error: incompatible types in assignment
arch/powerpc/platforms/powermac/cpufreq_64.c: In function 'g5_cpufreq_cpu_init':
arch/powerpc/platforms/powermac/cpufreq_64.c:365: error: incompatible types in assignment
arch/powerpc/platforms/cell/cbe_cpufreq.c: In function 'cbe_cpufreq_cpu_init':
arch/powerpc/platforms/cell/cbe_cpufreq.c:121: error: incompatible types in assignment
Caused by commit 835481d9bcd65720b473db6b38746a74a3964218 ("cpumask:
convert struct cpufreq_policy to cpumask_var_t") which missed updating
all the powerpc (at least) cpufreq drivers.
Reverting that one commit required fixups, so I reverted merge commit
4e9b1c184cadbece3694603de5f880b6e35bd7a7 ("Merge branch 'cpus4096-for-linus'
of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip")
instead.
I am hoping that this will be fixed soon and that revert doesn't
propagate more pain through today's linux-next.
This branch was last committed to in the tip tree on Jan 7 (the patch
above was committed on Jan 6) but was never propagated to linux-next
before being merged into your tree yesterday.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ 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