linux-next: Tree for July 30

linux-next: Tree for July 30

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 6474 bytes --]

Hi all,

The summary of the difference between 2.6.27-rc1 and today's tree is:

 1383 files changed, 50871 insertions(+), 37618 deletions(-)

thanks partly to the include/asm-sh -> arch/sh/include/asm rename, 1307
kvm commits and 188 xfs commits.

Changes since next-20080729:

Temporarily dropped trees: acpi (it is being moved to a new tree and is
just accumulating conflicts against Linus' tree).
	v4l-dvb (got lots of conflicts against the version that was
merged to Linus).

Linus' tree gained a three build fix (from the pci-current tree).

The driver-core tree had a commit reverted but the problem is actually
elsewhere.

The battery tree lost its conflicts.

I have also applied the following patches for known problems:

	hfcmulti is not supported on big endian
	cpumask: statement expressions confuse some versions of gcc
	tests: lkdtm needs ide.h

The sparc(32) defconfig build still fails - this is probably a toolchain
problem.

----------------------------------------------------------------------------

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, it is also built with powerpc allnoconfig,
44x_defconfig and allyesconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

We are up to 105 trees (counting Linus' and 14 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
Applying move iommu_num_pages helper to x86
Merging powerpc-merge/merge
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sparc-current/master
Merging sound-current/for-linus
Merging arm-current/master
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
CONFLICT (content): Merge conflict in drivers/dca/dca-sysfs.c
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-2.6.26
Merging quilt/driver-core
Created commit cfe6207: Revert "warn when statically-allocated kobjects are used"
Merging quilt/usb
Merging tip-core/auto-core-next
Merging cpus4096/auto-cpus4096-next
CONFLICT (content): Merge conflict in net/sunrpc/svc.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
Merging x86/auto-x86-next
CONFLICT (content): Merge conflict in drivers/pci/dmar.c
Merging pci/linux-next
Merging quilt/device-mapper
Merging hid/mm
Merging quilt/i2c
Merging quilt/kernel-doc
Merging avr32/avr32-arch
Merging s390/features
Merging sh/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 blackfin/for-linus
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging hwmon/testing
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging ia64/test
Merging tests/master
Merging ocfs2/linux-next
Merging quilt/m68k
Merging powerpc/next
Merging ext4/next
Merging 4xx/next
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging sparc/master
Merging galak/powerpc-next
Merging mtd/master
Merging wireless/master
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
Merging arm/devel
Merging cpufreq/next
Merging v9fs/for-next
Merging quilt/rr
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging semaphore/semaphore
Merging semaphore-removal/semaphore-removal
Merging bkl-removal/bkl-removal
Merging trivial/next
CONFLICT (content): Merge conflict in Documentation/edac.txt
CONFLICT (content): Merge conflict in include/linux/securebits.h
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in drivers/media/dvb/ttpci/Kconfig
CONFLICT (content): Merge conflict in drivers/media/dvb/ttpci/Makefile
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging m68knommu/for-next
Merging uclinux/for-next
Merging md/for-next
Merging cris/for-next
Merging kmemcheck/auto-kmemcheck-next
Merging generic-ipi/auto-generic-ipi-next
Merging mips/mips-for-linux-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
CONFLICT (add/add): Merge conflict in drivers/gpu/Makefile
CONFLICT (add/add): Merge conflict in drivers/gpu/drm/i830/Makefile
CONFLICT (content): Merge conflict in include/Kbuild
CONFLICT (add/add): Merge conflict in include/drm/Kbuild
Merging voltage/reg-for-linus
Merging security-testing/next
Merging lblnet/master
Merging quilt/ttydev
Applying hfcmulti is not supported on big endian
Applying cpumask: statement expressions confuse some versions of gcc
Applying tests: lkdtm needs ide.h

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: Tree for July 30

[Takashi Iwai]

At Wed, 30 Jul 2008 17:06:35 +1000,
Stephen Rothwell wrote:
> 
> Hi all,
> 
> The summary of the difference between 2.6.27-rc1 and today's tree is:
> 
>  1383 files changed, 50871 insertions(+), 37618 deletions(-)
> 
> thanks partly to the include/asm-sh -> arch/sh/include/asm rename, 1307
> kvm commits and 188 xfs commits.
> 
> Changes since next-20080729:
> 
> Temporarily dropped trees: acpi (it is being moved to a new tree and is
> just accumulating conflicts against Linus' tree).
> 	v4l-dvb (got lots of conflicts against the version that was
> merged to Linus).
> 
> Linus' tree gained a three build fix (from the pci-current tree).
> 
> The driver-core tree had a commit reverted but the problem is actually
> elsewhere.
> 
> The battery tree lost its conflicts.
> 
> I have also applied the following patches for known problems:
> 
> 	hfcmulti is not supported on big endian
> 	cpumask: statement expressions confuse some versions of gcc
> 	tests: lkdtm needs ide.h
> 
> The sparc(32) defconfig build still fails - this is probably a toolchain
> problem.

I got a build error on ia64 regarding kvm:

  CC [M]  arch/ia64/kvm/../../../virt/kvm/ioapic.o
arch/ia64/kvm/../../../virt/kvm/ioapic.c:42:17: error: irq.h: No such file or directory
arch/ia64/kvm/../../../virt/kvm/ioapic.c: In function '__kvm_ioapic_update_eoi':
arch/ia64/kvm/../../../virt/kvm/ioapic.c:296: error: implicit declaration of function 'kvm_notify_acked_irq'
arch/ia64/kvm/../../../virt/kvm/ioapic.c: In function 'ioapic_mmio_write':
arch/ia64/kvm/../../../virt/kvm/ioapic.c:389: error: too few arguments to function 'kvm_ioapic_update_eoi'
make[1]: *** [arch/ia64/kvm/../../../virt/kvm/ioapic.o] Error 1

Since the build with next-0729 was OK, the culprit looks like the commit:

commit 4233cf141eeb8d6363e0fb78e2e2ea391c269200
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date:   Sat Jul 26 17:01:00 2008 -0300

    KVM: irq ack notification


Takashi

Re: linux-next: Tree for July 30

[Andrew Morton]

On Wed, 30 Jul 2008 17:06:35 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git

The X server broke on my FC8 t61p thinkpad.  Mainline is OK.

Various information is at http://userweb.kernel.org/~akpm/mo/

I'm suspecting the input layer - my synaptics device seems to have
disappeared?  See http://userweb.kernel.org/~akpm/mo/Xorg-log-diff.txt

Re: linux-next: Tree for July 30

[Dmitry Torokhov]

On Wed, Jul 30, 2008 at 11:10:29PM -0700, Andrew Morton wrote:
> On Wed, 30 Jul 2008 17:06:35 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > I have created today's linux-next tree at
> > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> 
> The X server broke on my FC8 t61p thinkpad.  Mainline is OK.
> 
> Various information is at http://userweb.kernel.org/~akpm/mo/
> 
> I'm suspecting the input layer - my synaptics device seems to have
> disappeared?  See http://userweb.kernel.org/~akpm/mo/Xorg-log-diff.txt
> 

I think this patch should help with Synaptics:

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: [PATCH] Fix crash on kernels with extended keymap space

The len argument of EVIOCGBIT(ev,len) is the size of the receiving
buffer in bytes, not maximim number of bits to retrieve.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---
 eventcomm.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/eventcomm.c b/eventcomm.c
index e3257cd..2d0a347 100644
--- a/eventcomm.c
+++ b/eventcomm.c
@@ -89,7 +89,7 @@ event_query_is_touchpad(int fd)
 
     /* Check for ABS_X, ABS_Y, ABS_PRESSURE and BTN_TOOL_FINGER */
 
-    SYSCALL(ret = ioctl(fd, EVIOCGBIT(0, EV_MAX), evbits));
+    SYSCALL(ret = ioctl(fd, EVIOCGBIT(0, sizeof(evbits)), evbits));
     if (ret < 0)
 	return FALSE;
     if (!TEST_BIT(EV_SYN, evbits) ||
@@ -97,7 +97,7 @@ event_query_is_touchpad(int fd)
 	!TEST_BIT(EV_KEY, evbits))
 	return FALSE;
 
-    SYSCALL(ret = ioctl(fd, EVIOCGBIT(EV_ABS, KEY_MAX), evbits));
+    SYSCALL(ret = ioctl(fd, EVIOCGBIT(EV_ABS, sizeof(evbits)), evbits));
     if (ret < 0)
 	return FALSE;
     if (!TEST_BIT(ABS_X, evbits) ||
@@ -105,7 +105,7 @@ event_query_is_touchpad(int fd)
 	!TEST_BIT(ABS_PRESSURE, evbits))
 	return FALSE;
 
-    SYSCALL(ret = ioctl(fd, EVIOCGBIT(EV_KEY, KEY_MAX), evbits));
+    SYSCALL(ret = ioctl(fd, EVIOCGBIT(EV_KEY, sizeof(evbits)), evbits));
     if (ret < 0)
 	return FALSE;
     if (!TEST_BIT(BTN_TOOL_FINGER, evbits))
-- 
1.5.5.1

Re: linux-next: Tree for July 30

[Bartlomiej Zolnierkiewicz]

On Thu, Jul 31, 2008 at 4:07 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Wed, Jul 30, 2008 at 11:10:29PM -0700, Andrew Morton wrote:
>> On Wed, 30 Jul 2008 17:06:35 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> > I have created today's linux-next tree at
>> > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
>>
>> The X server broke on my FC8 t61p thinkpad.  Mainline is OK.
>>
>> Various information is at http://userweb.kernel.org/~akpm/mo/
>>
>> I'm suspecting the input layer - my synaptics device seems to have
>> disappeared?  See http://userweb.kernel.org/~akpm/mo/Xorg-log-diff.txt
>>
>
> I think this patch should help with Synaptics:

Which unfortunately doesn't help all people running with older synaptics
user-space after commit 0571c5d20aca71c735222132b02aebddf593045c
("Input: expand keycode space").

Can't this be solved without breaking Xorg on newer kernels running
older synaptics?

> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Subject: [PATCH] Fix crash on kernels with extended keymap space
>
> The len argument of EVIOCGBIT(ev,len) is the size of the receiving
> buffer in bytes, not maximim number of bits to retrieve.
>
> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
> ---
>  eventcomm.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/eventcomm.c b/eventcomm.c
> index e3257cd..2d0a347 100644
> --- a/eventcomm.c
> +++ b/eventcomm.c
> @@ -89,7 +89,7 @@ event_query_is_touchpad(int fd)
>
>     /* Check for ABS_X, ABS_Y, ABS_PRESSURE and BTN_TOOL_FINGER */
>
> -    SYSCALL(ret = ioctl(fd, EVIOCGBIT(0, EV_MAX), evbits));
> +    SYSCALL(ret = ioctl(fd, EVIOCGBIT(0, sizeof(evbits)), evbits));
>     if (ret < 0)
>        return FALSE;
>     if (!TEST_BIT(EV_SYN, evbits) ||
> @@ -97,7 +97,7 @@ event_query_is_touchpad(int fd)
>        !TEST_BIT(EV_KEY, evbits))
>        return FALSE;
>
> -    SYSCALL(ret = ioctl(fd, EVIOCGBIT(EV_ABS, KEY_MAX), evbits));
> +    SYSCALL(ret = ioctl(fd, EVIOCGBIT(EV_ABS, sizeof(evbits)), evbits));
>     if (ret < 0)
>        return FALSE;
>     if (!TEST_BIT(ABS_X, evbits) ||
> @@ -105,7 +105,7 @@ event_query_is_touchpad(int fd)
>        !TEST_BIT(ABS_PRESSURE, evbits))
>        return FALSE;
>
> -    SYSCALL(ret = ioctl(fd, EVIOCGBIT(EV_KEY, KEY_MAX), evbits));
> +    SYSCALL(ret = ioctl(fd, EVIOCGBIT(EV_KEY, sizeof(evbits)), evbits));
>     if (ret < 0)
>        return FALSE;
>     if (!TEST_BIT(BTN_TOOL_FINGER, evbits))
> --
> 1.5.5.1

Re: linux-next: Tree for July 30

[Dmitry Torokhov]

On Thu, Jul 31, 2008 at 05:36:16PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Thu, Jul 31, 2008 at 4:07 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Wed, Jul 30, 2008 at 11:10:29PM -0700, Andrew Morton wrote:
> >> On Wed, 30 Jul 2008 17:06:35 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >> > I have created today's linux-next tree at
> >> > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> >>
> >> The X server broke on my FC8 t61p thinkpad.  Mainline is OK.
> >>
> >> Various information is at http://userweb.kernel.org/~akpm/mo/
> >>
> >> I'm suspecting the input layer - my synaptics device seems to have
> >> disappeared?  See http://userweb.kernel.org/~akpm/mo/Xorg-log-diff.txt
> >>
> >
> > I think this patch should help with Synaptics:
> 
> Which unfortunately doesn't help all people running with older synaptics
> user-space after commit 0571c5d20aca71c735222132b02aebddf593045c
> ("Input: expand keycode space").
> 
> Can't this be solved without breaking Xorg on newer kernels running
> older synaptics?
> 

No. The X driver is broken. It tells kernel to use buffer bugger than
allocated and gets its stack smashed. Tslib has also soma funkiness
in the ioctl handling as well... *shrug*

We have a couple months to get distros updated...

-- 
Dmitry

Re: linux-next: Tree for July 30

[Andrew Morton]

On Thu, 31 Jul 2008 11:56:48 -0400 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> On Thu, Jul 31, 2008 at 05:36:16PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Thu, Jul 31, 2008 at 4:07 PM, Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> > > On Wed, Jul 30, 2008 at 11:10:29PM -0700, Andrew Morton wrote:
> > >> On Wed, 30 Jul 2008 17:06:35 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >>
> > >> > I have created today's linux-next tree at
> > >> > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> > >>
> > >> The X server broke on my FC8 t61p thinkpad.  Mainline is OK.
> > >>
> > >> Various information is at http://userweb.kernel.org/~akpm/mo/
> > >>
> > >> I'm suspecting the input layer - my synaptics device seems to have
> > >> disappeared?  See http://userweb.kernel.org/~akpm/mo/Xorg-log-diff.txt
> > >>
> > >
> > > I think this patch should help with Synaptics:
> > 
> > Which unfortunately doesn't help all people running with older synaptics
> > user-space after commit 0571c5d20aca71c735222132b02aebddf593045c
> > ("Input: expand keycode space").
> > 
> > Can't this be solved without breaking Xorg on newer kernels running
> > older synaptics?
> > 
> 
> No. The X driver is broken. It tells kernel to use buffer bugger than
> allocated and gets its stack smashed. Tslib has also soma funkiness
> in the ioctl handling as well... *shrug*
> 
> We have a couple months to get distros updated...
> 

aaarrrrgggggghhh.  I don't think this is practical.  This means that
(for example) FC5 machines (of which I happen to have one) are dead. 
And lots of other older-distro-based systems.

Is there some userspace workaround which doesn't require an X server
update?

Surely it must be possible to make the kernel contiue to support these
servers?

Re: linux-next: Tree for July 30

[Dmitry Torokhov]

On Thu, Jul 31, 2008 at 10:44:37AM -0700, Andrew Morton wrote:
> On Thu, 31 Jul 2008 11:56:48 -0400 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> 
> > On Thu, Jul 31, 2008 at 05:36:16PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > On Thu, Jul 31, 2008 at 4:07 PM, Dmitry Torokhov
> > > <dmitry.torokhov@gmail.com> wrote:
> > > > On Wed, Jul 30, 2008 at 11:10:29PM -0700, Andrew Morton wrote:
> > > >> On Wed, 30 Jul 2008 17:06:35 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > >>
> > > >> > I have created today's linux-next tree at
> > > >> > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> > > >>
> > > >> The X server broke on my FC8 t61p thinkpad.  Mainline is OK.
> > > >>
> > > >> Various information is at http://userweb.kernel.org/~akpm/mo/
> > > >>
> > > >> I'm suspecting the input layer - my synaptics device seems to have
> > > >> disappeared?  See http://userweb.kernel.org/~akpm/mo/Xorg-log-diff.txt
> > > >>
> > > >
> > > > I think this patch should help with Synaptics:
> > > 
> > > Which unfortunately doesn't help all people running with older synaptics
> > > user-space after commit 0571c5d20aca71c735222132b02aebddf593045c
> > > ("Input: expand keycode space").
> > > 
> > > Can't this be solved without breaking Xorg on newer kernels running
> > > older synaptics?
> > > 
> > 
> > No. The X driver is broken. It tells kernel to use buffer bugger than
> > allocated and gets its stack smashed. Tslib has also soma funkiness
> > in the ioctl handling as well... *shrug*
> > 
> > We have a couple months to get distros updated...
> > 
> 
> aaarrrrgggggghhh.  I don't think this is practical.  This means that
> (for example) FC5 machines (of which I happen to have one) are dead. 
> And lots of other older-distro-based systems.
> 
> Is there some userspace workaround which doesn't require an X server
> update?
> 
> Surely it must be possible to make the kernel contiue to support these
> servers?
> 

Andrew,

It is not like we broke ABI here. The progam (synaptics driver) had a
grave bug. Older kernels happened to paper over the bug because they
did not fill the whole buffer that was advertised as available. Now
that we have more data to report the bug bit us. What do you want me
to do?

Synaptics driver is a small package and takes 2 minutes to recompile.
You don't have to update entire X server with it (in fact I don't think
it is even part of X distribution because it is GPL).

-- 
Dmitry

Re: linux-next: Tree for July 30

[Andrew Morton]

On Thu, 31 Jul 2008 14:17:31 -0400 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> On Thu, Jul 31, 2008 at 10:44:37AM -0700, Andrew Morton wrote:
> > On Thu, 31 Jul 2008 11:56:48 -0400 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > 
> > > On Thu, Jul 31, 2008 at 05:36:16PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > On Thu, Jul 31, 2008 at 4:07 PM, Dmitry Torokhov
> > > > <dmitry.torokhov@gmail.com> wrote:
> > > > > On Wed, Jul 30, 2008 at 11:10:29PM -0700, Andrew Morton wrote:
> > > > >> On Wed, 30 Jul 2008 17:06:35 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > >>
> > > > >> > I have created today's linux-next tree at
> > > > >> > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> > > > >>
> > > > >> The X server broke on my FC8 t61p thinkpad.  Mainline is OK.
> > > > >>
> > > > >> Various information is at http://userweb.kernel.org/~akpm/mo/
> > > > >>
> > > > >> I'm suspecting the input layer - my synaptics device seems to have
> > > > >> disappeared?  See http://userweb.kernel.org/~akpm/mo/Xorg-log-diff.txt
> > > > >>
> > > > >
> > > > > I think this patch should help with Synaptics:
> > > > 
> > > > Which unfortunately doesn't help all people running with older synaptics
> > > > user-space after commit 0571c5d20aca71c735222132b02aebddf593045c
> > > > ("Input: expand keycode space").
> > > > 
> > > > Can't this be solved without breaking Xorg on newer kernels running
> > > > older synaptics?
> > > > 
> > > 
> > > No. The X driver is broken. It tells kernel to use buffer bugger than
> > > allocated and gets its stack smashed. Tslib has also soma funkiness
> > > in the ioctl handling as well... *shrug*
> > > 
> > > We have a couple months to get distros updated...
> > > 
> > 
> > aaarrrrgggggghhh.  I don't think this is practical.  This means that
> > (for example) FC5 machines (of which I happen to have one) are dead. 
> > And lots of other older-distro-based systems.
> > 
> > Is there some userspace workaround which doesn't require an X server
> > update?
> > 
> > Surely it must be possible to make the kernel contiue to support these
> > servers?
> > 
> 
> Andrew,
> 
> It is not like we broke ABI here. The progam (synaptics driver) had a
> grave bug. Older kernels happened to paper over the bug because they
> did not fill the whole buffer that was advertised as available. Now
> that we have more data to report the bug bit us. What do you want me
> to do?

Paper over the bug again.  When it happens, spit out a loud printk.

> Synaptics driver is a small package and takes 2 minutes to recompile.
> You don't have to update entire X server with it (in fact I don't think
> it is even part of X distribution because it is GPL).

What proportion of the X servers out there did we just break?

Was the crash I saw due to this?

Where would I (Aunt Tillie running FC5) go to find out how to fix my
machine up again? 

Re: linux-next: Tree for July 30

[Dmitry Torokhov]

On Thu, Jul 31, 2008 at 11:26:54AM -0700, Andrew Morton wrote:
> On Thu, 31 Jul 2008 14:17:31 -0400 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> 
> > On Thu, Jul 31, 2008 at 10:44:37AM -0700, Andrew Morton wrote:
> > > On Thu, 31 Jul 2008 11:56:48 -0400 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > > 
> > > > On Thu, Jul 31, 2008 at 05:36:16PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > > On Thu, Jul 31, 2008 at 4:07 PM, Dmitry Torokhov
> > > > > <dmitry.torokhov@gmail.com> wrote:
> > > > > > On Wed, Jul 30, 2008 at 11:10:29PM -0700, Andrew Morton wrote:
> > > > > >> On Wed, 30 Jul 2008 17:06:35 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > > >>
> > > > > >> > I have created today's linux-next tree at
> > > > > >> > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> > > > > >>
> > > > > >> The X server broke on my FC8 t61p thinkpad.  Mainline is OK.
> > > > > >>
> > > > > >> Various information is at http://userweb.kernel.org/~akpm/mo/
> > > > > >>
> > > > > >> I'm suspecting the input layer - my synaptics device seems to have
> > > > > >> disappeared?  See http://userweb.kernel.org/~akpm/mo/Xorg-log-diff.txt
> > > > > >>
> > > > > >
> > > > > > I think this patch should help with Synaptics:
> > > > > 
> > > > > Which unfortunately doesn't help all people running with older synaptics
> > > > > user-space after commit 0571c5d20aca71c735222132b02aebddf593045c
> > > > > ("Input: expand keycode space").
> > > > > 
> > > > > Can't this be solved without breaking Xorg on newer kernels running
> > > > > older synaptics?
> > > > > 
> > > > 
> > > > No. The X driver is broken. It tells kernel to use buffer bugger than
> > > > allocated and gets its stack smashed. Tslib has also soma funkiness
> > > > in the ioctl handling as well... *shrug*
> > > > 
> > > > We have a couple months to get distros updated...
> > > > 
> > > 
> > > aaarrrrgggggghhh.  I don't think this is practical.  This means that
> > > (for example) FC5 machines (of which I happen to have one) are dead. 
> > > And lots of other older-distro-based systems.
> > > 
> > > Is there some userspace workaround which doesn't require an X server
> > > update?
> > > 
> > > Surely it must be possible to make the kernel contiue to support these
> > > servers?
> > > 
> > 
> > Andrew,
> > 
> > It is not like we broke ABI here. The progam (synaptics driver) had a
> > grave bug. Older kernels happened to paper over the bug because they
> > did not fill the whole buffer that was advertised as available. Now
> > that we have more data to report the bug bit us. What do you want me
> > to do?
> 
> Paper over the bug again.  When it happens, spit out a loud printk.

For that we we need to be sure that the size of the buffer passed to
us is incorrect. I.e. if we decide that 512 is a magic bad number and
decide to limit the output then legit programs supplying 512 byte
buffers they will not get the whole thing.

> 
> > Synaptics driver is a small package and takes 2 minutes to recompile.
> > You don't have to update entire X server with it (in fact I don't think
> > it is even part of X distribution because it is GPL).
> 
> What proportion of the X servers out there did we just break?
> 
> Was the crash I saw due to this?
> 
> Where would I (Aunt Tillie running FC5) go to find out how to fix my
> machine up again? 

What is Aunt Tillie doing compiling her own kernels on FC5? You
OTOH managed to get an answer fairly quickly ;)

-- 
Dmitry

Re: linux-next: Tree for July 30

[Rafael J. Wysocki]

On Thursday, 31 of July 2008, Dmitry Torokhov wrote:
> On Thu, Jul 31, 2008 at 10:44:37AM -0700, Andrew Morton wrote:
> > On Thu, 31 Jul 2008 11:56:48 -0400 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > 
> > > On Thu, Jul 31, 2008 at 05:36:16PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > On Thu, Jul 31, 2008 at 4:07 PM, Dmitry Torokhov
> > > > <dmitry.torokhov@gmail.com> wrote:
> > > > > On Wed, Jul 30, 2008 at 11:10:29PM -0700, Andrew Morton wrote:
> > > > >> On Wed, 30 Jul 2008 17:06:35 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > >>
> > > > >> > I have created today's linux-next tree at
> > > > >> > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> > > > >>
> > > > >> The X server broke on my FC8 t61p thinkpad.  Mainline is OK.
> > > > >>
> > > > >> Various information is at http://userweb.kernel.org/~akpm/mo/
> > > > >>
> > > > >> I'm suspecting the input layer - my synaptics device seems to have
> > > > >> disappeared?  See http://userweb.kernel.org/~akpm/mo/Xorg-log-diff.txt
> > > > >>
> > > > >
> > > > > I think this patch should help with Synaptics:
> > > > 
> > > > Which unfortunately doesn't help all people running with older synaptics
> > > > user-space after commit 0571c5d20aca71c735222132b02aebddf593045c
> > > > ("Input: expand keycode space").
> > > > 
> > > > Can't this be solved without breaking Xorg on newer kernels running
> > > > older synaptics?
> > > > 
> > > 
> > > No. The X driver is broken. It tells kernel to use buffer bugger than
> > > allocated and gets its stack smashed. Tslib has also soma funkiness
> > > in the ioctl handling as well... *shrug*
> > > 
> > > We have a couple months to get distros updated...
> > > 
> > 
> > aaarrrrgggggghhh.  I don't think this is practical.  This means that
> > (for example) FC5 machines (of which I happen to have one) are dead. 
> > And lots of other older-distro-based systems.
> > 
> > Is there some userspace workaround which doesn't require an X server
> > update?
> > 
> > Surely it must be possible to make the kernel contiue to support these
> > servers?
> > 
> 
> Andrew,
> 
> It is not like we broke ABI here. The progam (synaptics driver) had a
> grave bug. Older kernels happened to paper over the bug because they
> did not fill the whole buffer that was advertised as available. Now
> that we have more data to report the bug bit us. What do you want me
> to do?
> 
> Synaptics driver is a small package and takes 2 minutes to recompile.
> You don't have to update entire X server with it (in fact I don't think
> it is even part of X distribution because it is GPL).

Well, we're not supposed to break user space that we used to work with, even
if it is known to be buggy.  Many people use the older user space on their
test systems which are not practical to upgrade.

IOW, if the change responsible for this makes it to the mainline kernel, it
will be considered as a regression.

Thanks,
Rafael

Re: linux-next: Tree for July 30

[Dmitry Torokhov]

On Thu, Jul 31, 2008 at 08:48:56PM +0200, Rafael J. Wysocki wrote:
> On Thursday, 31 of July 2008, Dmitry Torokhov wrote:
> > On Thu, Jul 31, 2008 at 10:44:37AM -0700, Andrew Morton wrote:
> > > On Thu, 31 Jul 2008 11:56:48 -0400 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > > 
> > > > On Thu, Jul 31, 2008 at 05:36:16PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > > On Thu, Jul 31, 2008 at 4:07 PM, Dmitry Torokhov
> > > > > <dmitry.torokhov@gmail.com> wrote:
> > > > > > On Wed, Jul 30, 2008 at 11:10:29PM -0700, Andrew Morton wrote:
> > > > > >> On Wed, 30 Jul 2008 17:06:35 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > > >>
> > > > > >> > I have created today's linux-next tree at
> > > > > >> > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> > > > > >>
> > > > > >> The X server broke on my FC8 t61p thinkpad.  Mainline is OK.
> > > > > >>
> > > > > >> Various information is at http://userweb.kernel.org/~akpm/mo/
> > > > > >>
> > > > > >> I'm suspecting the input layer - my synaptics device seems to have
> > > > > >> disappeared?  See http://userweb.kernel.org/~akpm/mo/Xorg-log-diff.txt
> > > > > >>
> > > > > >
> > > > > > I think this patch should help with Synaptics:
> > > > > 
> > > > > Which unfortunately doesn't help all people running with older synaptics
> > > > > user-space after commit 0571c5d20aca71c735222132b02aebddf593045c
> > > > > ("Input: expand keycode space").
> > > > > 
> > > > > Can't this be solved without breaking Xorg on newer kernels running
> > > > > older synaptics?
> > > > > 
> > > > 
> > > > No. The X driver is broken. It tells kernel to use buffer bugger than
> > > > allocated and gets its stack smashed. Tslib has also soma funkiness
> > > > in the ioctl handling as well... *shrug*
> > > > 
> > > > We have a couple months to get distros updated...
> > > > 
> > > 
> > > aaarrrrgggggghhh.  I don't think this is practical.  This means that
> > > (for example) FC5 machines (of which I happen to have one) are dead. 
> > > And lots of other older-distro-based systems.
> > > 
> > > Is there some userspace workaround which doesn't require an X server
> > > update?
> > > 
> > > Surely it must be possible to make the kernel contiue to support these
> > > servers?
> > > 
> > 
> > Andrew,
> > 
> > It is not like we broke ABI here. The progam (synaptics driver) had a
> > grave bug. Older kernels happened to paper over the bug because they
> > did not fill the whole buffer that was advertised as available. Now
> > that we have more data to report the bug bit us. What do you want me
> > to do?
> > 
> > Synaptics driver is a small package and takes 2 minutes to recompile.
> > You don't have to update entire X server with it (in fact I don't think
> > it is even part of X distribution because it is GPL).
> 
> Well, we're not supposed to break user space that we used to work with, even
> if it is known to be buggy.

No, I am sorry. We are not supposed to break userspace ABI, but that
is it. Can you vouch that 2.6.25 did not break a single userspace
program out there?

>  Many people use the older user space on their
> test systems which are not practical to upgrade.
> 

I don't understand this - it is expected that everyone jumps and
upgrades their kernels with ease but updating broken userspace
bits is super-hard... Plus, in this case the fixed driver will
happily work with old kernels.

> IOW, if the change responsible for this makes it to the mainline kernel, it
> will be considered as a regression.
> 

Like I said, I don't agree.

-- 
Dmitry

Re: linux-next: Tree for July 30

[Andrew Morton]

On Thu, 31 Jul 2008 14:34:41 -0400
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> > > > > No. The X driver is broken. It tells kernel to use buffer bugger than
> > > > > allocated and gets its stack smashed. Tslib has also soma funkiness
> > > > > in the ioctl handling as well... *shrug*
> > > > > 
> > > > > We have a couple months to get distros updated...
> > > > > 
> > > > 
> > > > aaarrrrgggggghhh.  I don't think this is practical.  This means that
> > > > (for example) FC5 machines (of which I happen to have one) are dead. 
> > > > And lots of other older-distro-based systems.
> > > > 
> > > > Is there some userspace workaround which doesn't require an X server
> > > > update?
> > > > 
> > > > Surely it must be possible to make the kernel contiue to support these
> > > > servers?
> > > > 
> > > 
> > > Andrew,
> > > 
> > > It is not like we broke ABI here. The progam (synaptics driver) had a
> > > grave bug. Older kernels happened to paper over the bug because they
> > > did not fill the whole buffer that was advertised as available. Now
> > > that we have more data to report the bug bit us. What do you want me
> > > to do?
> > 
> > Paper over the bug again.  When it happens, spit out a loud printk.
> 
> For that we we need to be sure that the size of the buffer passed to
> us is incorrect. I.e. if we decide that 512 is a magic bad number and
> decide to limit the output then legit programs supplying 512 byte
> buffers they will not get the whole thing.

uh.  I'm still scrabbling to understand all this.  Where is the
information about this kept?  Which commit caused this problem to
occur?

It _sounds_ like userspace is passing in a buffer and is also passing
in an incorrect (too large) `size' parameter, yes?

This is an ioctl interface?  Could we leave the old ioctl unchanged and
introduce the offending changes into a new ioctl number?

> > 
> > > Synaptics driver is a small package and takes 2 minutes to recompile.
> > > You don't have to update entire X server with it (in fact I don't think
> > > it is even part of X distribution because it is GPL).
> > 
> > What proportion of the X servers out there did we just break?
> > 
> > Was the crash I saw due to this?
> > 
> > Where would I (Aunt Tillie running FC5) go to find out how to fix my
> > machine up again? 
> 
> What is Aunt Tillie doing compiling her own kernels on FC5? You
> OTOH managed to get an answer fairly quickly ;)

I'll ask again: where do our users go to find out how to make their X
server work again?  If the answer is "nowhere" then can we please at 
least write up a simple step-by-step repair procedure, as we'll surely
be needing it a lot.

Re: linux-next: Tree for July 30

[Dmitry Torokhov]

On Thu, Jul 31, 2008 at 11:55:38AM -0700, Andrew Morton wrote:
> On Thu, 31 Jul 2008 14:34:41 -0400
> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> 
> > > > > > No. The X driver is broken. It tells kernel to use buffer bugger than
> > > > > > allocated and gets its stack smashed. Tslib has also soma funkiness
> > > > > > in the ioctl handling as well... *shrug*
> > > > > > 
> > > > > > We have a couple months to get distros updated...
> > > > > > 
> > > > > 
> > > > > aaarrrrgggggghhh.  I don't think this is practical.  This means that
> > > > > (for example) FC5 machines (of which I happen to have one) are dead. 
> > > > > And lots of other older-distro-based systems.
> > > > > 
> > > > > Is there some userspace workaround which doesn't require an X server
> > > > > update?
> > > > > 
> > > > > Surely it must be possible to make the kernel contiue to support these
> > > > > servers?
> > > > > 
> > > > 
> > > > Andrew,
> > > > 
> > > > It is not like we broke ABI here. The progam (synaptics driver) had a
> > > > grave bug. Older kernels happened to paper over the bug because they
> > > > did not fill the whole buffer that was advertised as available. Now
> > > > that we have more data to report the bug bit us. What do you want me
> > > > to do?
> > > 
> > > Paper over the bug again.  When it happens, spit out a loud printk.
> > 
> > For that we we need to be sure that the size of the buffer passed to
> > us is incorrect. I.e. if we decide that 512 is a magic bad number and
> > decide to limit the output then legit programs supplying 512 byte
> > buffers they will not get the whole thing.
> 
> uh.  I'm still scrabbling to understand all this.  Where is the
> information about this kept?  Which commit caused this problem to
> occur?
> 

It is commit "Input: expand keycode space" (git log
include/linux/input.h)

> It _sounds_ like userspace is passing in a buffer and is also passing
> in an incorrect (too large) `size' parameter, yes?
> 

Yes.

> This is an ioctl interface?

Yes.

>  Could we leave the old ioctl unchanged and
> introduce the offending changes into a new ioctl number?
> 

Then you will punish other users of this ioctl (the ones that
use it correctly). X proper, HAL, DirectFB, etc, etc. They will have
to implement the new interface just because of other programs having
an issue.

> > > 
> > > > Synaptics driver is a small package and takes 2 minutes to recompile.
> > > > You don't have to update entire X server with it (in fact I don't think
> > > > it is even part of X distribution because it is GPL).
> > > 
> > > What proportion of the X servers out there did we just break?
> > > 
> > > Was the crash I saw due to this?
> > > 
> > > Where would I (Aunt Tillie running FC5) go to find out how to fix my
> > > machine up again? 
> > 
> > What is Aunt Tillie doing compiling her own kernels on FC5? You
> > OTOH managed to get an answer fairly quickly ;)
> 
> I'll ask again: where do our users go to find out how to make their X
> server work again?  If the answer is "nowhere" then can we please at 
> least write up a simple step-by-step repair procedure, as we'll surely
> be needing it a lot.
> 

Changes? We could also get Peter to add some verbage onto his web-page
that hosts the driver. We are looking at .28 release for this code so
we have some time.

-- 
Dmitry

Re: linux-next: Tree for July 30

[Linus Torvalds]

On Thu, 31 Jul 2008, Dmitry Torokhov wrote:
> > 
> > Well, we're not supposed to break user space that we used to work with, even
> > if it is known to be buggy.
> 
> No, I am sorry. We are not supposed to break userspace ABI, but that
> is it. Can you vouch that 2.6.25 did not break a single userspace
> program out there?

Dmitry - irrelevant. If we know of breakage, then that is a FACT, and it's 
a regression, and it needs to be fixed.

Trying to say "there might be _other_ breakage that we don't even know of" 
does not change the situation ONE LITTLE BIT!

Don't you see how stupid that approach is? You're basically trying to make 
excuses for known breakage by saying that there might be _other_ breakage 
that we don't know about? Why the _hell_ do you think that is an excuse at 
all?

> >  Many people use the older user space on their
> > test systems which are not practical to upgrade.
> 
> I don't understand this - it is expected that everyone jumps and
> upgrades their kernels with ease but updating broken userspace
> bits is super-hard...

You're missing the point.

People are supposed to be able to upgrade things _independently_. It's not 
about "you're supposed to be able to upgrade the kernel, but not upgrade 
user space". It's about "you shouldn't evemn have to _worry_ about it.

> > IOW, if the change responsible for this makes it to the mainline kernel, it
> > will be considered as a regression.
> 
> Like I said, I don't agree.

Sorry, but you're simply wrong.

If somebody has the commit that broke user space, that commit will be 
_reverted_ unless it's fixed. It's that simple. The rules are: we don't 
knowingly break user space. 

			Linus

Re: linux-next: Tree for July 30

[Andrew Morton]

On Thu, 31 Jul 2008 14:54:52 -0400
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> > IOW, if the change responsible for this makes it to the mainline kernel, it
> > will be considered as a regression.
> > 
> 
> Like I said, I don't agree.

It really really doesn't matter what the causes are or which piece of
code is at fault or anything else like that.

What _does_ matter is that people's stuff will break.  Apparently lots
of people's.  That's a problem.  A _practical_ problem.  Can we
pleeeeeeze be practical and find some way of preventing it?

I assume this is the commit?


commit 03bac96fae0efdb25e2059e5accbe4f3ee6328dd
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Mon Jun 23 10:47:34 2008 -0400

    Input: expand keycode space
    
    Expand the number of potential key codes from 512 to 768 since people
    are coming up with more and more keys.
    
    Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

diff --git a/include/linux/input.h b/include/linux/input.h
index a5802c9..7fae1de 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -579,7 +579,7 @@ struct input_absinfo {
 
 /* We avoid low common keys in module aliases so they don't get huge. */
 #define KEY_MIN_INTERESTING	KEY_MUTE
-#define KEY_MAX			0x1ff
+#define KEY_MAX			0x2ff
 #define KEY_CNT			(KEY_MAX+1)
 
 /*
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index c4db582..0dddfa4 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -274,7 +274,7 @@ struct pcmcia_device_id {
 /* Input */
 #define INPUT_DEVICE_ID_EV_MAX		0x1f
 #define INPUT_DEVICE_ID_KEY_MIN_INTERESTING	0x71
-#define INPUT_DEVICE_ID_KEY_MAX		0x1ff
+#define INPUT_DEVICE_ID_KEY_MAX		0x2ff
 #define INPUT_DEVICE_ID_REL_MAX		0x0f
 #define INPUT_DEVICE_ID_ABS_MAX		0x3f
 #define INPUT_DEVICE_ID_MSC_MAX		0x07


I'm unable to work out how necessary this change is?


Please: what proportion of the existing X installations do you expect will
be affected by this?

Re: linux-next: Tree for July 30

[Hugh Dickins]

On Thu, 31 Jul 2008, Andrew Morton wrote:
> On Thu, 31 Jul 2008 14:34:41 -0400
> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > > 
> > > Where would I (Aunt Tillie running FC5) go to find out how to fix my
> > > machine up again? 
> > 
> > What is Aunt Tillie doing compiling her own kernels on FC5? You
> > OTOH managed to get an answer fairly quickly ;)
> 
> I'll ask again: where do our users go to find out how to make their X
> server work again?  If the answer is "nowhere" then can we please at 
> least write up a simple step-by-step repair procedure, as we'll surely
> be needing it a lot.

Thanks for pursuing this, Andrew: here's a kernel patch deduced
from this thread, which has indeed got me moving again.  Perhaps
an optional patch for hotfixes while the right answer is decided.


If you want to test 2.6.27-rc1-mm1, but your Synaptics pad is making X
crash immediately, and like Aunt Tillie and me you're more comfortable
patching your kernel than messing around in your userspace,
then reverting back from 768 to 512 keys should help.

Signed-off-by: Hugh Dickins <hugh@veritas.com>
---

 include/linux/input.h           |    2 +-
 include/linux/mod_devicetable.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- 2.6.27-rc1-mm1/include/linux/input.h	2008-07-31 09:30:09.000000000 +0100
+++ linux/include/linux/input.h	2008-07-31 19:39:20.000000000 +0100
@@ -592,7 +592,7 @@ struct input_absinfo {
 
 /* We avoid low common keys in module aliases so they don't get huge. */
 #define KEY_MIN_INTERESTING	KEY_MUTE
-#define KEY_MAX			0x2ff
+#define KEY_MAX			0x1ff
 #define KEY_CNT			(KEY_MAX+1)
 
 /*
--- 2.6.27-rc1-mm1/include/linux/mod_devicetable.h	2008-07-31 09:30:09.000000000 +0100
+++ linux/include/linux/mod_devicetable.h	2008-07-31 19:43:19.000000000 +0100
@@ -274,7 +274,7 @@ struct pcmcia_device_id {
 /* Input */
 #define INPUT_DEVICE_ID_EV_MAX		0x1f
 #define INPUT_DEVICE_ID_KEY_MIN_INTERESTING	0x71
-#define INPUT_DEVICE_ID_KEY_MAX		0x2ff
+#define INPUT_DEVICE_ID_KEY_MAX		0x1ff
 #define INPUT_DEVICE_ID_REL_MAX		0x0f
 #define INPUT_DEVICE_ID_ABS_MAX		0x3f
 #define INPUT_DEVICE_ID_MSC_MAX		0x07

Re: linux-next: Tree for July 30

[Dmitry Torokhov]

On Thu, Jul 31, 2008 at 12:10:40PM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 31 Jul 2008, Dmitry Torokhov wrote:
> > > 
> > > Well, we're not supposed to break user space that we used to work with, even
> > > if it is known to be buggy.
> > 
> > No, I am sorry. We are not supposed to break userspace ABI, but that
> > is it. Can you vouch that 2.6.25 did not break a single userspace
> > program out there?
> 
> Dmitry - irrelevant. If we know of breakage, then that is a FACT, and it's 
> a regression, and it needs to be fixed.

Does it have to be papered over in the kernel though?

> 
> Trying to say "there might be _other_ breakage that we don't even know of" 
> does not change the situation ONE LITTLE BIT!
> 
> Don't you see how stupid that approach is? You're basically trying to make 
> excuses for known breakage by saying that there might be _other_ breakage 
> that we don't know about? Why the _hell_ do you think that is an excuse at 
> all?

We can only guarantee one thing - ABI. And that is kept intact. But I
literally have no idea if a kernel breaks a random program out there
that happens to have a bug.

> 
> > >  Many people use the older user space on their
> > > test systems which are not practical to upgrade.
> > 
> > I don't understand this - it is expected that everyone jumps and
> > upgrades their kernels with ease but updating broken userspace
> > bits is super-hard...
> 
> You're missing the point.
> 
> People are supposed to be able to upgrade things _independently_. It's not 
> about "you're supposed to be able to upgrade the kernel, but not upgrade 
> user space". It's about "you shouldn't evemn have to _worry_ about it.
> 
> > > IOW, if the change responsible for this makes it to the mainline kernel, it
> > > will be considered as a regression.
> > 
> > Like I said, I don't agree.
> 
> Sorry, but you're simply wrong.
> 
> If somebody has the commit that broke user space, that commit will be 
> _reverted_ unless it's fixed. It's that simple. The rules are: we don't 
> knowingly break user space. 
>

We have 3 options now:

1. Never change KEY_MAX and dont add any new key definitions.
2. Introduce a new ioctl and have all wel-behaving programs rewritten
   to support it.
3. Fix userspace driver (patch is available).

Gioventhe fact that I wanted that change to go when .28 opens and it
will really hit users in 6+ months I'd still like to have 3.
 
-- 
Dmitry

Re: linux-next: Tree for July 30

[Dmitry Torokhov]

On Thu, Jul 31, 2008 at 03:24:02PM -0400, Dmitry Torokhov wrote:
> On Thu, Jul 31, 2008 at 12:10:40PM -0700, Linus Torvalds wrote:
> > 
> > Sorry, but you're simply wrong.
> > 
> > If somebody has the commit that broke user space, that commit will be 
> > _reverted_ unless it's fixed. It's that simple. The rules are: we don't 
> > knowingly break user space. 
> >
> 
> We have 3 options now:
> 
> 1. Never change KEY_MAX and dont add any new key definitions.
> 2. Introduce a new ioctl and have all wel-behaving programs rewritten
>    to support it.
> 3. Fix userspace driver (patch is available).
> 
> Gioventhe fact that I wanted that change to go when .28 opens and it
> will really hit users in 6+ months I'd still like to have 3.
>  

I guess we could do something like the below, but it is soooo ugly...

Input: paper over a bug in Synaptics X driver

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

 drivers/input/evdev.c |   14 +++++++++++++-
 1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 2d65411..c78a63b 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -736,8 +736,10 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
 			if ((_IOC_NR(cmd) & ~EV_MAX) == _IOC_NR(EVIOCGBIT(0, 0))) {
 
 				unsigned long *bits;
+				unsigned int buf_len = _IOC_SIZE(cmd);
 				int len;
 
+
 				switch (_IOC_NR(cmd) & EV_MAX) {
 
 				case      0: bits = dev->evbit;  len = EV_MAX;  break;
@@ -751,7 +753,17 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
 				case EV_SW:  bits = dev->swbit;  len = SW_MAX;  break;
 				default: return -EINVAL;
 				}
-				return bits_to_user(bits, len, _IOC_SIZE(cmd), p, compat_mode);
+
+				if ((_IOC_NR(cmd) & EV_MAX) == EV_KEY && buf_len == 0x1ff) {
+					printk(KERN_WARNING
+						"evdev.c(EVIOCGBIT): Detected suspicious "
+						"buffer size 0x1ff, limiting output to 64 "
+						"bytes. Make sure you are not using "
+						"EVIOCGBIT(EV_KEY, KEY_MAX)\n");
+					buf_len = 64; 
+				}
+
+				return bits_to_user(bits, len, buf_len, p, compat_mode);
 			}
 
 			if (_IOC_NR(cmd) == _IOC_NR(EVIOCGKEY(0)))

Re: linux-next: Tree for July 30

[Linus Torvalds]

On Thu, 31 Jul 2008, Dmitry Torokhov wrote:
> 
> Does it have to be papered over in the kernel though?

Yes. It's how we have worked. Asking people to upgrade big core programs 
is not reasonable.

Think of it this way: we absolutely _want_ people to run the latest 
kernel. We want it for their own sake (security etc fixes), but we want it 
even more for *our* own sake (testing, fixes etc).

And if we want to encourage people to upgrade their kernel very 
aggressively (and we absolutely do!), then that means that we have to also 
make sure it doesn't require them upgrading anything else.

> We can only guarantee one thing - ABI. And that is kept intact. But I
> literally have no idea if a kernel breaks a random program out there
> that happens to have a bug.

There are gray areas, yes. For example, timing changes do mean that a new 
kenrel can easily break a program that used to work. We cannot handle 
_everyting_. 

But when the ABI in question is some very specific one, that some 
important program uses (even if the "uses" is "misuses") then it really 
isn't a gray area any more.

And quite frankly, the ABI was apparently pretty bad to begin with, if 
user space got an array back but didn't get to specify the size. So you 
may want to say that user space was broken, but on the other hand, it's 
equally arguable that the ABI was crap.

(Which is something you can pretty much take for granted with ioctl's, of 
course. DO NOT CHANGE IOCTL'S. EVER!)

> We have 3 options now:
> 
> 1. Never change KEY_MAX and dont add any new key definitions.
> 2. Introduce a new ioctl and have all wel-behaving programs rewritten
>    to support it.
> 3. Fix userspace driver (patch is available).

You ignore the obvious choice, which is how we _usually_ do it:

 - help fix up the userspace driver regardless

 - a year down the line, maybe breakage will be a non-issue.

 - but at least _think_ about the fact that yes, most ioctl interfaces are 
   pure and utter sh*t, and the problem was probably not so much the user 
   space driver as the crap interface to begin with!

and discuss whether KEY_MAX really needs to be changed that much. I 
suspect that the change was done without even realizing just how painful 
it was, and that if you look at the original reason for it with the 
hindsight of knowing that it was painful, maybe it wasn't that critical to 
do it after all?

		Linus

Re: linux-next: Tree for July 30

[Rafael J. Wysocki]

On Thursday, 31 of July 2008, Dmitry Torokhov wrote:
> On Thu, Jul 31, 2008 at 08:48:56PM +0200, Rafael J. Wysocki wrote:
> > On Thursday, 31 of July 2008, Dmitry Torokhov wrote:
> > > On Thu, Jul 31, 2008 at 10:44:37AM -0700, Andrew Morton wrote:
> > > > On Thu, 31 Jul 2008 11:56:48 -0400 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > > > 
> > > > > On Thu, Jul 31, 2008 at 05:36:16PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > > > On Thu, Jul 31, 2008 at 4:07 PM, Dmitry Torokhov
> > > > > > <dmitry.torokhov@gmail.com> wrote:
> > > > > > > On Wed, Jul 30, 2008 at 11:10:29PM -0700, Andrew Morton wrote:
> > > > > > >> On Wed, 30 Jul 2008 17:06:35 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > > > >>
> > > > > > >> > I have created today's linux-next tree at
> > > > > > >> > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> > > > > > >>
> > > > > > >> The X server broke on my FC8 t61p thinkpad.  Mainline is OK.
> > > > > > >>
> > > > > > >> Various information is at http://userweb.kernel.org/~akpm/mo/
> > > > > > >>
> > > > > > >> I'm suspecting the input layer - my synaptics device seems to have
> > > > > > >> disappeared?  See http://userweb.kernel.org/~akpm/mo/Xorg-log-diff.txt
> > > > > > >>
> > > > > > >
> > > > > > > I think this patch should help with Synaptics:
> > > > > > 
> > > > > > Which unfortunately doesn't help all people running with older synaptics
> > > > > > user-space after commit 0571c5d20aca71c735222132b02aebddf593045c
> > > > > > ("Input: expand keycode space").
> > > > > > 
> > > > > > Can't this be solved without breaking Xorg on newer kernels running
> > > > > > older synaptics?
> > > > > > 
> > > > > 
> > > > > No. The X driver is broken. It tells kernel to use buffer bugger than
> > > > > allocated and gets its stack smashed. Tslib has also soma funkiness
> > > > > in the ioctl handling as well... *shrug*
> > > > > 
> > > > > We have a couple months to get distros updated...
> > > > > 
> > > > 
> > > > aaarrrrgggggghhh.  I don't think this is practical.  This means that
> > > > (for example) FC5 machines (of which I happen to have one) are dead. 
> > > > And lots of other older-distro-based systems.
> > > > 
> > > > Is there some userspace workaround which doesn't require an X server
> > > > update?
> > > > 
> > > > Surely it must be possible to make the kernel contiue to support these
> > > > servers?
> > > > 
> > > 
> > > Andrew,
> > > 
> > > It is not like we broke ABI here. The progam (synaptics driver) had a
> > > grave bug. Older kernels happened to paper over the bug because they
> > > did not fill the whole buffer that was advertised as available. Now
> > > that we have more data to report the bug bit us. What do you want me
> > > to do?
> > > 
> > > Synaptics driver is a small package and takes 2 minutes to recompile.
> > > You don't have to update entire X server with it (in fact I don't think
> > > it is even part of X distribution because it is GPL).
> > 
> > Well, we're not supposed to break user space that we used to work with, even
> > if it is known to be buggy.
> 
> No, I am sorry. We are not supposed to break userspace ABI, but that
> is it. Can you vouch that 2.6.25 did not break a single userspace
> program out there?

It probably did break some, but that doesn't imply it's acceptable.

> >  Many people use the older user space on their
> > test systems which are not practical to upgrade.
> > 
> 
> I don't understand this - it is expected that everyone jumps and
> upgrades their kernels with ease but updating broken userspace
> bits is super-hard... Plus, in this case the fixed driver will
> happily work with old kernels.

Please look at it from a different angle.

Kernel testers usually don't expect the kernel to break their X servers,
whatever the reason.  So, if they are not warned to expect the breakage, they
will search for the reason of it, as Andrew has just done, losing their time.
To prevent such losses of time from happening, it's better not to break user
space.

Still, if you really think there's no other way to go (like deferring the change
in question until everyone can be safely assumed to have upgraded their user
space already), please do something to keep people informed.

Thanks,
Rafael

Re: linux-next: Tree for July 30

[Dmitry Torokhov]

On Thu, Jul 31, 2008 at 12:44:04PM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 31 Jul 2008, Dmitry Torokhov wrote:
> > 
> > Does it have to be papered over in the kernel though?
> 
> Yes. It's how we have worked. Asking people to upgrade big core programs 
> is not reasonable.
>
> Think of it this way: we absolutely _want_ people to run the latest 
> kernel. We want it for their own sake (security etc fixes), but we want it 
> even more for *our* own sake (testing, fixes etc).
> 
> And if we want to encourage people to upgrade their kernel very 
> aggressively (and we absolutely do!), then that means that we have to also 
> make sure it doesn't require them upgrading anything else.

Sometimes we do need to upgrade userspace though. Can we make
Documentation/Changes more prominent? Maybe have it published on
kernel.org?

> 
> > We can only guarantee one thing - ABI. And that is kept intact. But I
> > literally have no idea if a kernel breaks a random program out there
> > that happens to have a bug.
> 
> There are gray areas, yes. For example, timing changes do mean that a new 
> kenrel can easily break a program that used to work. We cannot handle 
> _everyting_. 
> 
> But when the ABI in question is some very specific one, that some 
> important program uses (even if the "uses" is "misuses") then it really 
> isn't a gray area any more.
> 
> And quite frankly, the ABI was apparently pretty bad to begin with, if 
> user space got an array back but didn't get to specify the size. So you 
> may want to say that user space was broken, but on the other hand, it's 
> equally arguable that the ABI was crap.

It did specify the size. Something 448 more bytes than it allocated:

    unsigned long evbits[NBITS(KEY_MAX)];

    /* Check for ABS_X, ABS_Y, ABS_PRESSURE and BTN_TOOL_FINGER */

    SYSCALL(ret = ioctl(fd, EVIOCGBIT(0, KEY_MAX), evbits));

So we allocate 64 bytes on stack and then as kernel to fill it with
511 bytes worth of data.

> 
> (Which is something you can pretty much take for granted with ioctl's, of 
> course. DO NOT CHANGE IOCTL'S. EVER!)
> 
> > We have 3 options now:
> > 
> > 1. Never change KEY_MAX and dont add any new key definitions.
> > 2. Introduce a new ioctl and have all wel-behaving programs rewritten
> >    to support it.
> > 3. Fix userspace driver (patch is available).
> 
> You ignore the obvious choice, which is how we _usually_ do it:
> 
>  - help fix up the userspace driver regardless

In progress.
> 
>  - a year down the line, maybe breakage will be a non-issue.
>

Around when 2.6.28 is released, right? ;)
 
>  - but at least _think_ about the fact that yes, most ioctl interfaces are 
>    pure and utter sh*t, and the problem was probably not so much the user 
>    space driver as the crap interface to begin with!
> 
> and discuss whether KEY_MAX really needs to be changed that much. I 
> suspect that the change was done without even realizing just how painful 
> it was, and that if you look at the original reason for it with the 
> hindsight of knowing that it was painful, maybe it wasn't that critical to 
> do it after all?
>

We do need more keycodes. People are coming wioth more and more. The
patch following the one in question adds about 10 new kodes for remote
controls/phones. And we will get more.

-- 
Dmitry

Re: linux-next: Tree for July 30

[Andrew Morton]

On Thu, 31 Jul 2008 15:42:07 -0400
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> -				return bits_to_user(bits, len, _IOC_SIZE(cmd), p, compat_mode);
> +
> +				if ((_IOC_NR(cmd) & EV_MAX) == EV_KEY && buf_len == 0x1ff) {
> +					printk(KERN_WARNING
> +						"evdev.c(EVIOCGBIT): Detected suspicious "
> +						"buffer size 0x1ff, limiting output to 64 "
> +						"bytes. Make sure you are not using "
> +						"EVIOCGBIT(EV_KEY, KEY_MAX)\n");
> +					buf_len = 64; 
> +				}

If that works then great.  But I think the printk could be improved. 
Please provide sufficient information so that users (not programmers)
can go off and fix things up without needing to email kernel developers.

One suitable approach would be

	printk("see http://userweb.kernel.org/~dtor/read-this.txt")

Re: linux-next: Tree for July 30

[Linus Torvalds]

On Thu, 31 Jul 2008, Dmitry Torokhov wrote:
> 
> Sometimes we do need to upgrade userspace though. Can we make
> Documentation/Changes more prominent? Maybe have it published on
> kernel.org?

We basically _never_ have to upgrade userspace that aggressively. We can 
have a Changes file that talks about things that will eventually break 
when we remove support for it eventually, but it should never EVER be used 
as an excuse for "I needed to break it now".

So no, I refuse to make it any more prominent. Because it would just be 
used as an excuse for behavior that I consider unacceptable. It was 
different back when we had 3-year development windows and people upgrading 
from 2.4.x to 2.6.x had to learn new things, but for 2.6.26 to .27 or 
similar it's simply not acceptable.

Look at the VFS layer. Look at how we have multiple different versions of 
"readdir()" (well, getdents, really), and "stat()". Exactly because we 
don't break user space.

> It did specify the size. Something 448 more bytes than it allocated:
> 
>     unsigned long evbits[NBITS(KEY_MAX)];
> 
>     /* Check for ABS_X, ABS_Y, ABS_PRESSURE and BTN_TOOL_FINGER */
> 
>     SYSCALL(ret = ioctl(fd, EVIOCGBIT(0, KEY_MAX), evbits));
> 
> So we allocate 64 bytes on stack and then as kernel to fill it with
> 511 bytes worth of data.

Ok, I can see how it's confused, asking for KEY_MAX _bits_. If this is the 
main user, why not just change the definition to be in bits?

> >  - help fix up the userspace driver regardless
> 
> In progress.
> > 
> >  - a year down the line, maybe breakage will be a non-issue.
> 
> Around when 2.6.28 is released, right? ;)

A year down the line would be 2.6.30 or so.

> We do need more keycodes. People are coming wioth more and more. The
> patch following the one in question adds about 10 new kodes for remote
> controls/phones. And we will get more.

Maybe the problem is a bad design that encourages people to just create 
new keycodes when they really shouldn't? 

			Linus

Re: linux-next: Tree for July 30

[Linus Torvalds]

On Thu, 31 Jul 2008, Linus Torvalds wrote:
> >     /* Check for ABS_X, ABS_Y, ABS_PRESSURE and BTN_TOOL_FINGER */
> > 
> >     SYSCALL(ret = ioctl(fd, EVIOCGBIT(0, KEY_MAX), evbits));
> > 
> > So we allocate 64 bytes on stack and then as kernel to fill it with
> > 511 bytes worth of data.
> 
> Ok, I can see how it's confused, asking for KEY_MAX _bits_. If this is the 
> main user, why not just change the definition to be in bits?

Or just say that "if the buffer is really much too big, maybe they meant 
bits"?

IOW, something like this?

(And no, I'm not seriously proposing _this_ patch, but you get the idea)

		Linus
---
 drivers/input/evdev.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 2d65411..e45451d 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -734,7 +734,7 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
 		if (_IOC_DIR(cmd) == _IOC_READ) {
 
 			if ((_IOC_NR(cmd) & ~EV_MAX) == _IOC_NR(EVIOCGBIT(0, 0))) {
-
+				unsigned int size = _IOC_SIZE(cmd);
 				unsigned long *bits;
 				int len;
 
@@ -751,7 +751,12 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
 				case EV_SW:  bits = dev->swbit;  len = SW_MAX;  break;
 				default: return -EINVAL;
 				}
-				return bits_to_user(bits, len, _IOC_SIZE(cmd), p, compat_mode);
+
+				/* Some people get confused about size in bits vs bytes */
+				if (size >= len/8)
+					size = size/8;
+
+				return bits_to_user(bits, len, size, p, compat_mode);
 			}
 
 			if (_IOC_NR(cmd) == _IOC_NR(EVIOCGKEY(0)))

Re: linux-next: Tree for July 30

[Dmitry Torokhov]

On Thu, Jul 31, 2008 at 01:16:52PM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 31 Jul 2008, Dmitry Torokhov wrote:
> > 
> > Sometimes we do need to upgrade userspace though. Can we make
> > Documentation/Changes more prominent? Maybe have it published on
> > kernel.org?
> 
> We basically _never_ have to upgrade userspace that aggressively. We can 
> have a Changes file that talks about things that will eventually break 
> when we remove support for it eventually, but it should never EVER be used 
> as an excuse for "I needed to break it now".
> 
> So no, I refuse to make it any more prominent. 

OK.

> Because it would just be 
> used as an excuse for behavior that I consider unacceptable. It was 
> different back when we had 3-year development windows and people upgrading 
> from 2.4.x to 2.6.x had to learn new things, but for 2.6.26 to .27 or 
> similar it's simply not acceptable.
> 
> Look at the VFS layer. Look at how we have multiple different versions of 
> "readdir()" (well, getdents, really), and "stat()". Exactly because we 
> don't break user space.

Here we don't extend the interface though.
> 
> > It did specify the size. Something 448 more bytes than it allocated:
> > 
> >     unsigned long evbits[NBITS(KEY_MAX)];
> > 
> >     /* Check for ABS_X, ABS_Y, ABS_PRESSURE and BTN_TOOL_FINGER */
> > 
> >     SYSCALL(ret = ioctl(fd, EVIOCGBIT(0, KEY_MAX), evbits));
> > 
> > So we allocate 64 bytes on stack and then as kernel to fill it with
> > 511 bytes worth of data.
> 
> Ok, I can see how it's confused, asking for KEY_MAX _bits_. If this is the 
> main user, why not just change the definition to be in bits?
> 

Because X proper, HAL, DirectFB and many other users got it right and
changing it to mean bits would break _them_.

> > >  - help fix up the userspace driver regardless
> > 
> > In progress.
> > > 
> > >  - a year down the line, maybe breakage will be a non-issue.
> > 
> > Around when 2.6.28 is released, right? ;)
> 
> A year down the line would be 2.6.30 or so.
> 

I guess that means that we have to have that patch that spits warning
and reduces size of returned data of it detects 01ff buffer size.
Still, its uuuuugllllyyy.

> > We do need more keycodes. People are coming wioth more and more. The
> > patch following the one in question adds about 10 new kodes for remote
> > controls/phones. And we will get more.
> 
> Maybe the problem is a bad design that encourages people to just create 
> new keycodes when they really shouldn't? 

That is bigger topic. HID spec has much more events for differect
things though. FOr example the new key definitions for the phones - we
want to have a separate # key and not try to combine "shift" and "3"
and also have separate numeric keys taht don't depend on register and
NumLock state. If we don't have such keycodes we have trouble with
some european users that have numbers in upper register...

-- 
Dmitry

Re: linux-next: Tree for July 30

[Dmitry Torokhov]

On Thu, Jul 31, 2008 at 01:28:37PM -0700, Linus Torvalds wrote:
> 
> +				/* Some people get confused about size in bits vs bytes */
> +				if (size >= len/8)
> +					size = size/8;

People usually allocate single buffer (big enough) and the do a bunch
of tests so this condiion is likely to fire on EV_SW and similar event
types. I think it is safer to explicitely test for EV_KEY/0x1ff.

-- 
Dmitry

Re: linux-next: Tree for July 30

[Linus Torvalds]

Ok, I apparently missed this whole subthread yesterday, only getting back 
to it when going over my old queues.

On Thu, 31 Jul 2008, Dmitry Torokhov wrote:
> 
> Input: paper over a bug in Synaptics X driver

Yeah, it's not pretty, but how about moving that EV_KEY thing into the 
switch() statement? Also, the printk could certainly be a bit more useful.

But before doing _any_ of that, the first thing to do should be to not 
have that four-deep indentation by just splitting that horrible function 
up a bit.

IOW, start off with a patch like the appended, and _then_ add the special 
case handling to the EV_KEY thing. It would probably be most easily done 
by just literally limiting "len" to OLD_KEY_MAX. Something like

   #define OLD_KEY_MAX 0x1ff
   ...
	case EV_KEY:
		bits = dev->keybit;
		len = KEY_MAX;
		/* Hacky workaround for old bug in Xorg */
		if (buf_len == OLD_KEY_MAX) 
			len = OLD_KEY_MAX;
		break;
  ...

or similar.

Yeah, it's not pretty, but pragmatism before beauty.

		Linus
---
 drivers/input/evdev.c |   44 ++++++++++++++++++++++++--------------------
 1 files changed, 24 insertions(+), 20 deletions(-)

diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 2d65411..ef8c2ed 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -647,6 +647,28 @@ static int str_to_user(const char *str, unsigned int maxlen, void __user *p)
 	return copy_to_user(p, str, len) ? -EFAULT : len;
 }
 
+static int handle_eviocgbit(struct input_dev *dev, unsigned int cmd, void __user *p, int compat_mode)
+{
+	unsigned long *bits;
+	int len;
+
+	switch (_IOC_NR(cmd) & EV_MAX) {
+
+	case      0: bits = dev->evbit;  len = EV_MAX;  break;
+	case EV_KEY: bits = dev->keybit; len = KEY_MAX; break;
+	case EV_REL: bits = dev->relbit; len = REL_MAX; break;
+	case EV_ABS: bits = dev->absbit; len = ABS_MAX; break;
+	case EV_MSC: bits = dev->mscbit; len = MSC_MAX; break;
+	case EV_LED: bits = dev->ledbit; len = LED_MAX; break;
+	case EV_SND: bits = dev->sndbit; len = SND_MAX; break;
+	case EV_FF:  bits = dev->ffbit;  len = FF_MAX;  break;
+	case EV_SW:  bits = dev->swbit;  len = SW_MAX;  break;
+	default: return -EINVAL;
+	}
+	return bits_to_user(bits, len, _IOC_SIZE(cmd), p, compat_mode);
+}
+
+
 static long evdev_do_ioctl(struct file *file, unsigned int cmd,
 			   void __user *p, int compat_mode)
 {
@@ -733,26 +755,8 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
 
 		if (_IOC_DIR(cmd) == _IOC_READ) {
 
-			if ((_IOC_NR(cmd) & ~EV_MAX) == _IOC_NR(EVIOCGBIT(0, 0))) {
-
-				unsigned long *bits;
-				int len;
-
-				switch (_IOC_NR(cmd) & EV_MAX) {
-
-				case      0: bits = dev->evbit;  len = EV_MAX;  break;
-				case EV_KEY: bits = dev->keybit; len = KEY_MAX; break;
-				case EV_REL: bits = dev->relbit; len = REL_MAX; break;
-				case EV_ABS: bits = dev->absbit; len = ABS_MAX; break;
-				case EV_MSC: bits = dev->mscbit; len = MSC_MAX; break;
-				case EV_LED: bits = dev->ledbit; len = LED_MAX; break;
-				case EV_SND: bits = dev->sndbit; len = SND_MAX; break;
-				case EV_FF:  bits = dev->ffbit;  len = FF_MAX;  break;
-				case EV_SW:  bits = dev->swbit;  len = SW_MAX;  break;
-				default: return -EINVAL;
-				}
-				return bits_to_user(bits, len, _IOC_SIZE(cmd), p, compat_mode);
-			}
+			if ((_IOC_NR(cmd) & ~EV_MAX) == _IOC_NR(EVIOCGBIT(0, 0)))
+				return handle_eviocgbit(dev, cmd, p, compat_mode);
 
 			if (_IOC_NR(cmd) == _IOC_NR(EVIOCGKEY(0)))
 				return bits_to_user(dev->key, KEY_MAX, _IOC_SIZE(cmd),

Re: linux-next: Tree for July 30

[Dmitry Torokhov]

On Fri, Aug 01, 2008 at 12:12:19PM -0700, Linus Torvalds wrote:
> 
> Ok, I apparently missed this whole subthread yesterday, only getting back 
> to it when going over my old queues.
> 
> On Thu, 31 Jul 2008, Dmitry Torokhov wrote:
> > 
> > Input: paper over a bug in Synaptics X driver
> 
> Yeah, it's not pretty, but how about moving that EV_KEY thing into the 
> switch() statement?

I want to to be visually separated. It is not a hot path so extra
comparison won't hurt us.

> Also, the printk could certainly be a bit more useful.

I think I will follow Andrew's advice and point people to a page on
kernel.org (to be written).

> have that four-deep indentation by just splitting that horrible function 
> up a bit.
> 
> IOW, start off with a patch like the appended,

Makes sense. Signed-off-by please ;)

-- 
Dmitry

Re: linux-next: Tree for July 30

[Linus Torvalds]

On Fri, 1 Aug 2008, Dmitry Torokhov wrote:
> 
> Makes sense. Signed-off-by please ;)

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

		Linus

Re: linux-next: Tree for July 30

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

Hi Andrew, Dmitry,

On Wed, 30 Jul 2008 23:10:29 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 30 Jul 2008 17:06:35 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > I have created today's linux-next tree at
> > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> 
> The X server broke on my FC8 t61p thinkpad.  Mainline is OK.
> 
> Various information is at http://userweb.kernel.org/~akpm/mo/
> 
> I'm suspecting the input layer - my synaptics device seems to have
> disappeared?  See http://userweb.kernel.org/~akpm/mo/Xorg-log-diff.txt

I have reverted commit 03bac96fae0efdb25e2059e5accbe4f3ee6328dd ("Input:
expand keycode space") from linux-next until we have some resolution of
this problem.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: Tree for July 30

[Dmitry Torokhov]

On Thu, Jul 31, 2008 at 01:10:56PM -0700, Andrew Morton wrote:
> 
> If that works then great.  But I think the printk could be improved. 
> Please provide sufficient information so that users (not programmers)
> can go off and fix things up without needing to email kernel developers.
> 
> One suitable approach would be
> 
> 	printk("see http://userweb.kernel.org/~dtor/read-this.txt")
> 

Ok, I made a small page here:

	http://userweb.kernel.org/~dtor/eviocgbit-bug.html

If you think this is sufficient I'd like to put the patch with the
warning in 2.6.27 so people and distributions could start updarting
affected programs.

-- 
Dmitry

Re: linux-next: Tree for July 30

[Andrew Morton]

On Thu, 7 Aug 2008 14:11:09 -0400
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> On Thu, Jul 31, 2008 at 01:10:56PM -0700, Andrew Morton wrote:
> > 
> > If that works then great.  But I think the printk could be improved. 
> > Please provide sufficient information so that users (not programmers)
> > can go off and fix things up without needing to email kernel developers.
> > 
> > One suitable approach would be
> > 
> > 	printk("see http://userweb.kernel.org/~dtor/read-this.txt")
> > 
> 
> Ok, I made a small page here:
> 
> 	http://userweb.kernel.org/~dtor/eviocgbit-bug.html

You need to mv that file.  It's actually at
http://userweb.kernel.org/~dtor/eviogcbit-bug.html

And

     evdev.c(EVIOCGBIT): Suspicious buffer size 511, limiting output to 64
     bytes. See http://userweb.kernel.org/~dtor/eviocgbit-bug.html 

will get a 404.

typo: s/distribbution/distribution/

The text looks good.  A user would come away wondering which packages
need to be updated.  Do we have a suitable text pattern whcih will help
them?

On a fedora system I have

y:/home/akpm> rpm -qa|grep -i syna
synaptics-0.14.6-2.fc8

So "the synaptics package" would be a suitably distro-neutral description.

`rpm -qa|grep -i tslib' comes up blank so I don't know about that one.

> If you think this is sufficient I'd like to put the patch with the
> warning in 2.6.27 so people and distributions could start updarting
> affected programs.

Sure.  It'd make sense to get that warning into 2.6.25.x and 2.6.26.x
as well, to accelerate the process a bit.

Re: linux-next: Tree for July 30

[Rafael J. Wysocki]

On Thursday, 7 of August 2008, Dmitry Torokhov wrote:
> On Thu, Jul 31, 2008 at 01:10:56PM -0700, Andrew Morton wrote:
> > 
> > If that works then great.  But I think the printk could be improved. 
> > Please provide sufficient information so that users (not programmers)
> > can go off and fix things up without needing to email kernel developers.
> > 
> > One suitable approach would be
> > 
> > 	printk("see http://userweb.kernel.org/~dtor/read-this.txt")
> > 
> 
> Ok, I made a small page here:
> 
> 	http://userweb.kernel.org/~dtor/eviocgbit-bug.html

404: Not Found

> If you think this is sufficient I'd like to put the patch with the
> warning in 2.6.27 so people and distributions could start updarting
> affected programs.

Re: linux-next: Tree for July 30

[Dmitry Torokhov]

On Thu, Aug 07, 2008 at 11:50:31AM -0700, Andrew Morton wrote:
> On Thu, 7 Aug 2008 14:11:09 -0400
> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> 
> > On Thu, Jul 31, 2008 at 01:10:56PM -0700, Andrew Morton wrote:
> > > 
> > > If that works then great.  But I think the printk could be improved. 
> > > Please provide sufficient information so that users (not programmers)
> > > can go off and fix things up without needing to email kernel developers.
> > > 
> > > One suitable approach would be
> > > 
> > > 	printk("see http://userweb.kernel.org/~dtor/read-this.txt")
> > > 
> > 
> > Ok, I made a small page here:
> > 
> > 	http://userweb.kernel.org/~dtor/eviocgbit-bug.html
> 
> You need to mv that file.  It's actually at
> http://userweb.kernel.org/~dtor/eviogcbit-bug.html
> 
> And
> 
>      evdev.c(EVIOCGBIT): Suspicious buffer size 511, limiting output to 64
>      bytes. See http://userweb.kernel.org/~dtor/eviocgbit-bug.html 
> 
> will get a 404.
> 

Fixed.

> typo: s/distribbution/distribution/
> 

Fixed.

> The text looks good.  A user would come away wondering which packages
> need to be updated.  Do we have a suitable text pattern whcih will help
> them?
> 
> On a fedora system I have
> 
> y:/home/akpm> rpm -qa|grep -i syna
> synaptics-0.14.6-2.fc8
> 
> So "the synaptics package" would be a suitably distro-neutral description.
> 

There is apparently Synaptic package manager - quite similar name - so
I want to emphasize that we are concerned with a driver for X.

> `rpm -qa|grep -i tslib' comes up blank so I don't know about that one.

This is a touchscreen library that is used by embedded people.
Unfortunately I have no idea where the authoritative source is.

> 
> > If you think this is sufficient I'd like to put the patch with the
> > warning in 2.6.27 so people and distributions could start updarting
> > affected programs.
> 
> Sure.  It'd make sense to get that warning into 2.6.25.x and 2.6.26.x
> as well, to accelerate the process a bit.
> 

Ok, good.

-- 
Dmitry

linux-next: Tree for July 30

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 43422 bytes --]

Hi all,

Please do not add anything to linux-next included branches/series that is
destined for v3.7 until after v3.6-rc1 is released.

Reminder: do not rebase your branches before asking Linus to pull them ...

Changes since 20120727:

Linus' tree lost its build failure.

The vfs tree gained conflicts against Linus' tree.

The tty tree still has its build failures for which I have disabled 2
staging drivers and applied a patch.

The arm-soc tree gained a conflict against Linus' tree.

I have still reverted 3 commits from the signal tree at the request of the
arm maintainer.

----------------------------------------------------------------------------

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/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 (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 197 trees (counting Linus' and 26 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 Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

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 (f7da9cd Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (9023a40 Merge tag 'mmc-fixes-for-3.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc)
Merging kbuild-current/rc-fixes (f8f5701 Linux 3.5-rc1)
Merging arm-current/fixes (ff001ff ARM: 7480/1: only call smp_send_stop() on SMP)
Merging m68k-current/for-linus (1525e06 m68k/apollo: Rename "timer" to "apollo_timer")
Merging powerpc-merge/merge (bac821a powerpc/ftrace: Trace function graph entry before updating index)
Merging sparc/master (b387e41 Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc)
Merging net/master (f7da9cd Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging sound-current/for-linus (e427c23 ALSA: hda - Workaround for silent output on VAIO Z with ALC889)
Merging pci-current/for-linus (314489b Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging wireless/master (9dbf5f5 bcma: add missing iounmap on error path)
Merging driver-core.current/driver-core-linus (84a1caf Linux 3.5-rc7)
Merging tty.current/tty-linus (38bd2a1 pch_uart: Fix parity setting issue)
Merging usb.current/usb-linus (84a1caf Linux 3.5-rc7)
Merging staging.current/staging-linus (6887a41 Linux 3.5-rc5)
Merging char-misc.current/char-misc-linus (84a1caf Linux 3.5-rc7)
Merging input-current/for-linus (314820c Merge branch 'next' into for-linus)
Merging md-current/for-linus (58e94ae md/raid1: close some possible races on write errors during resync)
Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix)
Merging crypto-current/master (a434788 crypto: twofish-avx - remove useless instruction)
Merging ide/master (39a50b4 Merge branch 'hfsplus')
Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6)
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions)
Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting)
Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for of_parse_phandle_with_args)
Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using proper "spi:" modalias prefixes.)
Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, remove cast)
Merging arm/for-next (ed2784d Merge branch 'audit' into for-next)
CONFLICT (content): Merge conflict in drivers/dma/Makefile
CONFLICT (content): Merge conflict in drivers/dma/Kconfig
Merging arm-perf/for-next/perf (dee8c1b ARM: perf: remove arm_perf_pmu_ids global enumeration)
Merging davinci/davinci-next (fe0d422 Linux 3.0-rc6)
Merging samsung/next-samsung (9edb240 ARM: H1940/RX1950: Change default LED triggers)
Merging xilinx/arm-next (b85a3ef ARM: Xilinx: Adding Xilinx board support)
Merging blackfin/for-linus (719154c bf60x: fix build warning)
Merging c6x/for-linux-next (b9b8722 C6X: clean up compiler warning)
Merging cris/for-next (2608747 CRIS: Remove VCS simulator specific code)
Merging hexagon/linux-next (5042ab9 various Kconfig cleanup and old platform build code removal)
Merging ia64/next (a119365 [IA64] Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts)
Merging m68k/for-next (1525e06 m68k/apollo: Rename "timer" to "apollo_timer")
Merging m68knommu/for-next (b1f7735 m68k: allow PCI bus to be enabled for ColdFire m54xx CPUs)
Merging microblaze/next (a01ee16 Merge branch 'for-linus' of git://git.open-osd.org/linux-open-osd)
Merging mips/mips-for-linux-next (68d8848 Merge branches 'next/generic', 'next/alchemy', 'next/bcm63xx', 'next/cavium', 'next/jz4740', 'next/lantiq', 'next/loongson1b' and 'next/netlogic' into mips-for-linux-next)
Merging openrisc/for-upstream (207e715 openrisc: use scratch regs in atomic syscall)
Merging parisc/for-next (bba3d8c [PARISC] Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts)
Merging powerpc/next (bdc0077 Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging 4xx/next (2074b1d powerpc: Fix irq distribution)
Merging mpc5xxx/next (4d2f4e1 powerpc: Option FB_FSL_DIU is not really optional for mpc512x)
Merging galak/next (ae33d08 powerpc/85xx: introduce support for the Freescale / iVeia P1022RDK)
Merging s390/features (216550e s390: update defconfig)
Merging sh/sh-latest (b9ccfda sh: modify the sh_dmae_slave_config for RSPI in setup-sh7757)
Merging sparc-next/master (31a6710 Fix blocking allocations called very early during bootup)
Merging tile/master (bdc0077 Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging unicore32/unicore32 (e4baa56 UniCore32-bugfix: Remove definitions in asm/bug.h to solve difference between native and cross compiler)
Merging ceph/master (26ce171 libceph: fix NULL dereference in reset_connection())
CONFLICT (content): Merge conflict in net/ceph/osd_client.c
CONFLICT (content): Merge conflict in net/ceph/messenger.c
Merging cifs/for-next (1a500f0 CIFS: Add SMB2 support for rmdir)
Merging configfs/linux-next (b930c26 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs)
Merging ecryptfs/next (5f5b331 eCryptfs: check for eCryptfs cipher support at mount)
Merging ext3/for_next (0143fc5 udf: avoid info leak on export)
Merging ext4/dev (03179fe ext4: undo ext4_calc_metadata_amount if we fail to claim space)
Merging fuse/for-next (f3840dc fuse: add missing INIT flag descriptions)
Merging gfs2/master (bdc0077 Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging logfs/master (9f0bbd8 logfs: query block device for number of pages to send with bio)
Merging nfs/linux-next (4886e15 Merge branch 'nfs-for-3.6' into linux-next)
Merging nfsd/nfsd-next (96d6d59 locks: move lease-specific code out of locks_delete_lock)
Merging ocfs2/linux-next (2dfd060 aio: make kiocb->private NUll in init_sync_kiocb())
Merging omfs/for-next (976d167 Linux 3.1-rc9)
Merging squashfs/master (4b0180a Squashfs: add mount time sanity check for block_size and block_log match)
Merging v9fs/for-next (5fcb08b 9p: BUG before corrupting memory)
Merging ubifs/linux-next (7074e5e UBIFS: remove invalid reference to list iterator variable)
Merging xfs/for-next (9a57fa8 xfs: wait for the write the superblock on unmount)
CONFLICT (content): Merge conflict in fs/xfs/xfs_log_priv.h
CONFLICT (content): Merge conflict in fs/xfs/xfs_log.c
CONFLICT (content): Merge conflict in fs/xfs/xfs_buf.c
Merging vfs/for-next (bf88489 lockd: handle lockowner allocation failure in nlmclnt_proc())
CONFLICT (content): Merge conflict in drivers/usb/gadget/storage_common.c
CONFLICT (content): Merge conflict in drivers/staging/gdm72xx/usb_boot.c
Merging pci/next (63b96f7 Merge branch 'pci/yinghai-pciehp-unused' into next)
Merging hid/for-next (e8ff13b Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid)
Merging quilt/i2c (bdc0077 Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging bjdooks-i2c/next-i2c (fc84fe1 Merge branch 'for_3.3/i2c/misc' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into for-33/i2c/omap)
CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-omap.c
Merging i2c-embedded/i2c-embedded/for-next (5db20c4 Revert "i2c: tegra: convert normal suspend/resume to *_noirq")
CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-nomadik.c
Merging quilt/jdelvare-hwmon (73e15f6 hwmon: struct x86_cpu_id arrays can be __initconst)
Merging hwmon-staging/hwmon-next (829917c hwmon: (applesmc) Decode and act on read/write status codes)
Merging v4l-dvb/master (07c4a1e Merge /home/v4l/v4l/patchwork)
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
Applying: Use a named union in struct v4l2_ioctl_info
Merging kbuild/for-next (85b170e Merge branches 'kbuild/kconfig' and 'kbuild/misc' into kbuild/for-next)
Merging kconfig/for-next (4503379 localmodconfig: Add debug environment variable LOCALMODCONFIG_DEBUG)
Merging libata/NEXT (354b2ea libata-acpi: fix up for acpi_pm_device_sleep_state API)
Merging infiniband/for-next (5dedb9f Merge tag 'rdma-for-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband)
Merging acpi/next (ec033d0 Merge branches 'acpi_pad', 'acpica', 'apei-bugzilla-43282', 'battery', 'cpuidle-coupled', 'cpuidle-tweaks', 'intel_idle-ivb', 'ost', 'red-hat-bz-772730', 'thermal', 'thermal-spear' and 'turbostat-v2' into release)
Merging cpuidle/cpuidle-next (3cf7997 acpi: intel_idle : break dependency between modules)
CONFLICT (add/add): Merge conflict in drivers/cpuidle/coupled.c
Merging cpupowerutils/master (f166033 cpupower tools: add install target to the debug tools' makefiles)
Merging ieee1394/for-next (e3cbd92 firewire: core: document is_local sysfs attribute)
Merging ubi/linux-next (87e773c UBI: harmonize the update of ubi->beb_rsvd_pebs)
Merging dlm/next (96006ea dlm: fix missing dir remove)
Merging scsi/for-next (641aa03 Merge branch 'misc' into for-next)
CONFLICT (content): Merge conflict in drivers/ata/libata-core.c
Merging target-updates/for-next (bf6932f iscsi-target: Drop bogus struct file usage for iSCSI/SCTP)
Merging target-merge/for-next-merge (1247c37 tcm_vhost: Initial merge for vhost level target fabric driver)
Merging ibft/linux-next (935a9fe ibft: Fix finding IBFT ACPI table on UEFI)
Merging isci/all (6734092 isci: add a couple __iomem annotations)
Merging slave-dma/next (6343325 dmaengine: Cleanup logging messages)
Merging dmaengine/next (a2bd114 netdma: adding alignment check for NETDMA ops)
Merging net-next/master (173f865 Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4)
Merging wireless-next/master (36eb22e libertas: firmware.c: remove duplicated include)
Merging bluetooth/master (8bd38a6 Bluetooth: Added /proc/net/sco via bt_procfs_init())
Merging mtd/master (4800399 mtd: m25p80: Add support for serial flash STM/Micron N25Q032)
Merging l2-mtd/master (cd0a30d mtd: m25p80: Fix the Spansion chip detection)
CONFLICT (content): Merge conflict in arch/arm/mach-imx/clk-imx6q.c
Merging crypto/master (a434788 crypto: twofish-avx - remove useless instruction)
Merging drm/drm-next (98c7b42 Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next)
Merging sound/for-next (e427c23 ALSA: hda - Workaround for silent output on VAIO Z with ALC889)
Merging sound-asoc/for-next (e13ab2a ASoC: mc13783: Provide codec->control_data)
Merging quilt/rr (3804700 Make most arch asm/module.h files use asm-generic/module.h)
CONFLICT (content): Merge conflict in arch/arm/Kconfig
Merging input/next (c039450 Input: synaptics - handle out of bounds values from the hardware)
Merging input-mt/for-next (c45361a Revert "Input: atmel_mxt_ts - warn if sysfs could not be created")
Merging cgroup/for-next (4b2ebf0 Merge branch 'for-3.6' into for-next)
Merging block/for-next (f45d342 Merge branch 'for-linus' into for-next)
Merging quilt/device-mapper (8d5ab5c Commit outstanding metadata before returning the status for a dm thin pool so that the numbers reported are as up-to-date as possible.)
Merging embedded/master (4744b43 embedded: fix vc_translate operator precedence)
Merging firmware/master (6e03a20 firmware: speed up request_firmware(), v3)
Merging pcmcia/master (80af9e6 pcmcia at91_cf: fix raw gpio number usage)
Merging mmc/mmc-next (30b87c6 mmc: sdhci-dove: Prepare for common clock framework)
Merging kgdb/kgdb-next (3751d3e x86,kgdb: Fix DEBUG_RODATA limitation using text_poke())
Merging slab/for-next (44a8bde slob: Fix early boot kernel crash)
Merging uclinux/for-next (5e442a4 Revert "proc: fix races against execve() of /proc/PID/fd**")
Merging md/for-next (cd853a6 md: avoid taking the mutex on some ioctls.)
Merging mfd/for-next (3b3a030 mfd: Apply the AB8500 CODEC's compatible string to the ab8500-core MFD cell)
CONFLICT (modify/delete): include/linux/mfd/s5m87xx/s5m-core.h deleted in mfd/for-next and modified in HEAD. Version HEAD of include/linux/mfd/s5m87xx/s5m-core.h left in tree.
CONFLICT (content): Merge conflict in drivers/usb/host/ehci-omap.c
CONFLICT (content): Merge conflict in drivers/regulator/s5m8767.c
CONFLICT (content): Merge conflict in drivers/mfd/mc13xxx-spi.c
CONFLICT (content): Merge conflict in arch/arm/configs/tegra_defconfig
$ git rm -f include/linux/mfd/s5m87xx/s5m-core.h
Merging battery/master (ecc2edd olpc-battery: update CHARGE_FULL_DESIGN property for BYD LiFe batteries)
Applying: ACPI-Thermal: fix for an API change
Merging fbdev/fbdev-next (a023907 da8xx-fb: fix compile issue due to missing include)
Merging viafb/viafb-next (838ac78 viafb: avoid refresh and mode lookup in set_par)
Merging omap_dss2/for-next (974a658 Merge "Apply LCD manager related parameters" from Archit)
Merging regulator/for-next (3384fb9 Merge branch 'regulator-drivers' into regulator-next)
Merging security/next (6637284 Smack: Maintainer Record)
Merging selinux/master (c2d7b24 Merge tag 'v3.4' into 20120409)
Merging lblnet/master (7e27d6e Linux 2.6.35-rc3)
Merging watchdog/master (06a3fa7 watchdog: fix watchdog-test.c build warning)
Merging dwmw2-iommu/master (c3b92c8 Linux 3.1)
Merging iommu/next (395e51f Merge branches 'iommu/fixes', 'x86/amd', 'groups', 'arm/tegra' and 'api/domain-attr' into next)
Merging vfio/next (59b9426 vfio: Add PCI device driver)
Merging osd/linux-next (a7fdf6a exofs: stop using s_dirt)
Merging jc_docs/docs-next (5c050fb docs: update the development process document)
Merging trivial/for-next (d14b7a4 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial)
Merging audit/for-next (dcd6c92 Linux 3.3-rc1)
Merging pm/linux-next (26ba678 Merge branch 'master' into linux-next)
Merging apm/for-next (f283d22 APM: fix deadlock in APM_IOC_SUSPEND ioctl)
Merging fsnotify/for-next (1aec9c0 inotify: automatically restart syscalls)
Merging edac/linux_next (a92cdec Merge branch 'devel' into next)
Merging edac-amd/for-next (305f1c3 Merge branch '3.3-pci_device_id' into edac-for-next)
CONFLICT (content): Merge conflict in drivers/edac/amd64_edac.c
CONFLICT (content): Merge conflict in Documentation/edac.txt
Merging devicetree/devicetree/next (efd68e7 devicetree: add helper inline for retrieving a node's full name)
Merging dt-rh/for-next (e95d8aa of: mtd: nuke useless const qualifier)
Merging spi/spi/next (d8e328b spi: Add "spi:" prefix to modalias attribute of spi devices)
Merging spi-mb/spi-next (8ceffa7 spi/orion: remove uneeded spi_info)
Merging tip/auto-latest (bb35bef Merge branch 'x86/urgent')
Merging rcu/rcu/next (5cf05ad rcu: Fix broken strings in RCU's source code.)
Merging cputime/cputime (c3e0ef9 [S390] fix cputime overflow in uptime_proc_show)
Merging uprobes/for-next (0326f5a uprobes/core: Handle breakpoint and singlestep exceptions)
Merging kmemleak/kmemleak (4878677 kmemleak: do not leak object after tree insertion error)
Merging kvm/linux-next (ade38c3 KVM: s390: Add implementation-specific trace events)
Merging kvm-ppc/kvm-ppc-next (1ee245b KVM: PPC: Critical interrupt emulation support)
CONFLICT (content): Merge conflict in arch/powerpc/kvm/booke_interrupts.S
Merging oprofile/for-next (c16fa4f Linux 3.3)
Merging xen/upstream/xen (af3a3ab Merge git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes)
Merging xen-two/linux-next (64b0a47 Merge commit 'v3.5-rc7' into linux-next)
Merging xen-pvhvm/linux-next (b056b6a xen: suspend: remove xen_hvm_suspend)
Merging percpu/for-next (61011677 Merge tag 'dlm-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm)
Merging workqueues/for-next (6fec10a workqueue: fix spurious CPU locality WARN from process_one_work())
Merging drivers-x86/linux-next (00d3959 thinkpad_acpi: Free hotkey_keycode_map after unregistering tpacpi_inputdev)
Merging hwpoison/hwpoison (46e387b Merge branch 'hwpoison-hugepages' into hwpoison)
Merging sysctl/master (4e474a0 sysctl: protect poll() in entries that may go away)
Merging regmap/for-next (38e2319 Merge branches 'regmap-core', 'regmap-irq' and 'regmap-page' into regmap-next)
Merging hsi/for-next (43139a6 HSI: hsi_char: Update ioctl-number.txt)
Merging leds/for-next (d45bb11 leds-lp8788: forgotten unlock at lp8788_led_work)
Merging driver-core/driver-core-next (6791457 printk: Export struct log size and member offsets through vmcoreinfo)
Merging tty/tty-next (d155255 tty: Fix race in tty release)
Applying: disable SERIAL_IPOCTAL broken by tty updates
Applying: disable USB_SERIAL_QUATECH2 broken by tty update
Applying: tty: fix up usb serial console for termios change.
Merging usb/usb-next (e387ef5 usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams)
Merging staging/staging-next (419e926 staging: csr: delete a bunch of unused library functions)
Merging char-misc/char-misc-next (6078188 mei: use module_pci_driver)
Merging tmem/linux-next (78821b2 Merge branch 'stable/for-linus-3.6' into linux-next)
Merging writeback/writeback-for-next (331cbde writeback: Fix some comment errors)
CONFLICT (content): Merge conflict in fs/sync.c
Merging arm-dt/devicetree/arm-next (ede338f dt: add documentation of ARM dt boot interface)
Merging hwspinlock/linux-next (8b37fcf hwspinlock: add MAINTAINERS entries)
Merging pinctrl/for-next (c9eebe7 pinctrl/pinctrl-u300: remove unneeded devm_kfree call)
Merging moduleh/for-sfr (6b16351 Linux 3.5-rc4)
Merging vhost/linux-next (e0953c8 tun: experimental zero copy tx support)
CONFLICT (content): Merge conflict in drivers/net/tun.c
Merging kmap_atomic/kmap_atomic (2164d33 pipe: remove KM_USER0 from comments)
Merging memblock/memblock-kill-early_node_map (7bd0b0f memblock: Reimplement memblock allocation using reverse free area iterator)
Merging remoteproc/for-next (6bb697b MAINTAINERS: add remoteproc's git)
Merging irqdomain/irqdomain/next (f5a1ad0 irqdomain: Improve diagnostics when a domain mapping fails)
Merging gpio/gpio/next (3e11f7b gpio/generic: initialize basic_mmio_gpio shadow variables properly)
Merging gpio-lw/for-next (4fbb002 gpio: of_get_named_gpio_flags() return -EPROBE_DEFER if GPIO not yet available)
Merging arm-soc/for-next (deac1d4 ARM: arm-soc: add arm-soc-for-next-contents.txt)
CONFLICT (content): Merge conflict in drivers/watchdog/orion_wdt.c
Merging ep93xx/ep93xx-for-next (9b6a359 Merge branch 'ep93xx-fixes' into ep93xx-for-next)
Merging renesas/next (45c7a01 Merge branch 'renesas-marzen' into renesas-board)
Merging s5p/for-next (6701bca Merge branch 'next/board-samsung-3' into for-next)
Merging tegra/for-next (a04ef1f Merge branch 'for-3.6/defconfig' into for-next)
Merging kvmtool/master (8598de5 kvm tools, powerpc: Use MMU info for ibm,slb-size)
Merging dma-mapping/dma-mapping-next (9da9c1b ARM: dma-mapping: add support for DMA_ATTR_SKIP_CPU_SYNC attribute)
Merging pwm/for-next (19891b2 pwm: pwm-tiehrpwm: PWM driver support for EHRPWM)
CONFLICT (content): Merge conflict in drivers/pwm/pwm-samsung.c
CONFLICT (content): Merge conflict in arch/arm/plat-samsung/Makefile
CONFLICT (content): Merge conflict in arch/arm/mach-tegra/board-dt-tegra30.c
CONFLICT (content): Merge conflict in arch/arm/mach-tegra/board-dt-tegra20.c
Merging dma-buf/for-next (ca24a14 Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm)
Merging userns/for-next (491fa9e userns: Allow the usernamespace support to build after the removal of usbfs)
Merging ktest/for-next (648a182 ktest: Allow a test to override REBOOT_ON_SUCCESS)
Merging signal/from-sfr (2e117f2 Revert "arm: pull all work_pending logics into C function")
CONFLICT (content): Merge conflict in arch/powerpc/kernel/entry_64.S
CONFLICT (content): Merge conflict in arch/arm/include/asm/thread_info.h
Merging clk/clk-next (137f8a7 clk: fix compile for OF && !COMMON_CLK)
Merging random/dev (d2e7c96 random: mix in architectural randomness in extract_buf())
CONFLICT (content): Merge conflict in drivers/usb/gadget/omap_udc.c
CONFLICT (content): Merge conflict in drivers/mfd/ab3100-core.c
Merging scsi-post-merge/merge-base:master ()
$ git checkout akpm
Applying: mm: fix wrong argument of migrate_huge_pages() in soft_offline_huge_page()
Applying: pcdp: use early_ioremap/early_iounmap to access pcdp table
Applying: cciss: fix incorrect scsi status reporting
Applying: acpi_memhotplug.c: fix memory leak when memory device is unbound from the module acpi_memhotplug
Applying: acpi_memhotplug.c: free memory device if acpi_memory_enable_device() failed
Applying: acpi_memhotplug.c: remove memory info from list before freeing it
Applying: acpi_memhotplug.c: don't allow to eject the memory device if it is being used
Applying: acpi_memhotplug.c: bind the memory device when the driver is being loaded
Applying: acpi_memhotplug.c: auto bind the memory device which is hotplugged before the driver is loaded
Applying: arch/x86/platform/iris/iris.c: register a platform device and a platform driver
Applying: arch/x86/include/asm/spinlock.h: fix comment
Applying: arch/x86/kernel/cpu/perf_event_intel_uncore.h: make UNCORE_PMU_HRTIMER_INTERVAL 64-bit
Applying: mn10300: only add -mmem-funcs to KBUILD_CFLAGS if gcc supports it
Applying: drivers/dma/dmaengine.c: lower the priority of 'failed to get' dma channel message
Applying: prctl: remove redunant assignment of "error" to zero
Applying: timeconst.pl: remove deprecated defined(@array)
Applying: time: don't inline EXPORT_SYMBOL functions
Applying: thermal: fix potential out-of-bounds memory access
Applying: thermal: add Renesas R-Car thermal sensor support
Applying: thermal: add generic cpufreq cooling implementation
Applying: hwmon: exynos4: move thermal sensor driver to driver/thermal directory
Applying: thermal: exynos5: add exynos5 thermal sensor driver support
Applying: thermal: exynos: register the tmu sensor with the kernel thermal layer
Applying: ARM: exynos: add thermal sensor driver platform data support
Applying: ocfs2: use find_last_bit()
Applying: ocfs2: use bitmap_weight()
Applying: drivers/scsi/atp870u.c: fix bad use of udelay
Applying: vfs: increment iversion when a file is truncated
Applying: fs: push rcu_barrier() from deactivate_locked_super() to filesystems
Applying: fs/xattr.c:getxattr(): improve handling of allocation failures
Applying: fs: make dumpable=2 require fully qualified path
Applying: coredump: warn about unsafe suid_dumpable / core_pattern combo
Applying: xtensa/mm/fault.c: port OOM changes to do_page_fault
Applying: mm/slab: remove duplicate check
Applying: slab: do not call compound_head() in page_get_cache()
Applying: vmalloc: walk vmap_areas by sorted list instead of rb_next()
Applying: mm: make vb_alloc() more foolproof
Applying: mm-make-vb_alloc-more-foolproof-fix
Applying: memcg: rename MEM_CGROUP_STAT_SWAPOUT as MEM_CGROUP_STAT_SWAP
Applying: memcg: rename MEM_CGROUP_CHARGE_TYPE_MAPPED as MEM_CGROUP_CHARGE_TYPE_ANON
Applying: memcg: remove MEM_CGROUP_CHARGE_TYPE_FORCE
Applying: swap: allow swap readahead to be merged
Applying: documentation: update how page-cluster affects swap I/O
Applying: mm: account the total_vm in the vm_stat_account()
Applying: mm/buddy: cleanup on should_fail_alloc_page
Applying: mm: prepare for removal of obsolete /proc/sys/vm/nr_pdflush_threads
Applying: hugetlb: rename max_hstate to hugetlb_max_hstate
Applying: hugetlb: don't use ERR_PTR with VM_FAULT* values
Applying: hugetlb: add an inline helper for finding hstate index
Applying: hugetlb: use mmu_gather instead of a temporary linked list for accumulating pages
Applying: hugetlb: avoid taking i_mmap_mutex in unmap_single_vma() for hugetlb
Applying: hugetlb: simplify migrate_huge_page()
Applying: hugetlb: add a list for tracking in-use HugeTLB pages
Applying: hugetlb: make some static variables global
Applying: hugeltb: mark hugelb_max_hstate __read_mostly
Applying: mm/hugetlb: add new HugeTLB cgroup
Applying: mm-hugetlb-add-new-hugetlb-cgroup-fix
Applying: mm-hugetlb-add-new-hugetlb-cgroup-fix-fix
Applying: hugetlb/cgroup: remove unnecessary NULL checks
Applying: hugetlb/cgroup: Mark root_h_cgroup static
Applying: hugetlb/cgroup: add the cgroup pointer to page lru
Applying: hugetlb/cgroup: add charge/uncharge routines for hugetlb cgroup
Applying: hugetlb/cgroup: Remove unnecessary NULL checks
Applying: mm/hugetlb_cgroup: Add huge_page_order check to avoid incorrectly uncharge
Applying: hugetlb/cgroup: add support for cgroup removal
Applying: hugetlb/cgroup: add hugetlb cgroup control files
Applying: hugetlb-cgroup-add-hugetlb-cgroup-control-files-fix
Applying: hugetlb-cgroup-add-hugetlb-cgroup-control-files-fix-fix
Applying: hugetlb/cgroup: migrate hugetlb cgroup info from oldpage to new page during migration
Applying: hugetlb/cgroup: add HugeTLB controller documentation
Applying: hugetlb: move all the in use pages to active list
Applying: hugetlb/cgroup: assign the page hugetlb cgroup when we move the page to active list.
Applying: hugetlb/cgroup: remove exclude and wakeup rmdir calls from migrate
Applying: mm, oom: do not schedule if current has been killed
Applying: mm/memblock.c:memblock_double_array(): cosmetic cleanups
Applying: memcg: remove check for signal_pending() during rmdir()
Applying: memcg: clean up force_empty_list() return value check
Applying: memcg: mem_cgroup_move_parent() doesn't need gfp_mask
Applying: memcg: make mem_cgroup_force_empty_list() return bool
Applying: memcg-make-mem_cgroup_force_empty_list-return-bool-fix
Applying: mm/compaction: cleanup on compaction_deferred
Applying: mm, fadvise: don't return -EINVAL when filesystem cannot implement fadvise()
Applying: mm-fadvise-dont-return-einval-when-filesystem-cannot-implement-fadvise-checkpatch-fixes
Applying: mm: clear pages_scanned only if draining a pcp adds pages to the buddy allocator again
Applying: mm, oom: fix potential killing of thread that is disabled from oom killing
Applying: mm, oom: replace some information in tasklist dump
Applying: mm: do not use page_count() without a page pin
Applying: mm: clean up __count_immobile_pages()
Applying: memcg: rename config variables
Applying: memcg-rename-config-variables-fix
Applying: memcg-rename-config-variables-fix-fix
Applying: mm: remove unused LRU_ALL_EVICTABLE
Applying: memcg: fix bad behavior in use_hierarchy file
Applying: memcg: rename mem_control_xxx to memcg_xxx
Applying: mm: have order > 0 compaction start off where it left
Applying: mm-have-order-0-compaction-start-off-where-it-left-checkpatch-fixes
Applying: mm: have order > 0 compaction start off where it left
Applying: mm-have-order-0-compaction-start-off-where-it-left-v3-typo
Applying: mm: CONFIG_HAVE_MEMBLOCK_NODE -> CONFIG_HAVE_MEMBLOCK_NODE_MAP
Applying: vmscan: remove obsolete shrink_control comment
Applying: mm/memory.c:print_vma_addr(): call up_read(&mm->mmap_sem) directly
Applying: mm: setup pageblock_order before it's used by sparsemem
Applying: mm/memcg: complete documentation for tcp memcg files
Applying: mm/memcg: mem_cgroup_relize_xxx_limit can guarantee memcg->res.limit <= memcg->memsw.limit
Applying: mm/memcg: replace inexistence move_lock_page_cgroup() by move_lock_mem_cgroup() in comment
Applying: mm/hotplug: correctly setup fallback zonelists when creating new pgdat
Applying: mm/hotplug: correctly add new zone to all other nodes' zone lists
Applying: mm/hotplug: free zone->pageset when a zone becomes empty
Applying: mm/hotplug: mark memory hotplug code in page_alloc.c as __meminit
Applying: mm, oom: move declaration for mem_cgroup_out_of_memory to oom.h
Applying: mm, oom: introduce helper function to process threads during scan
Applying: mm, memcg: introduce own oom handler to iterate only over its own threads
Applying: mm, oom: reduce dependency on tasklist_lock
Applying: mm, oom: reduce dependency on tasklist_lock: fix
Applying: mm, memcg: move all oom handling to memcontrol.c
Applying: mm: factor out memory isolate functions
Applying: mm: fix free page check in zone_watermark_ok()
Applying: memory-hotplug: fix kswapd looping forever problem
Applying: memory-hotplug-fix-kswapd-looping-forever-problem-fix
Applying: memory-hotplug-fix-kswapd-looping-forever-problem-fix-fix
Applying: mm: sl[au]b: add knowledge of PFMEMALLOC reserve pages
Applying: mm: slub: optimise the SLUB fast path to avoid pfmemalloc checks
Applying: mm: introduce __GFP_MEMALLOC to allow access to emergency reserves
Applying: mm: allow PF_MEMALLOC from softirq context
Applying: mm: only set page->pfmemalloc when ALLOC_NO_WATERMARKS was used
Applying: mm: ignore mempolicies when using ALLOC_NO_WATERMARK
Applying: net: introduce sk_gfp_atomic() to allow addition of GFP flags depending on the individual socket
Applying: netvm: allow the use of __GFP_MEMALLOC by specific sockets
Applying: netvm: allow skb allocation to use PFMEMALLOC reserves
Applying: netvm: propagate page->pfmemalloc to skb
Applying: netvm: propagate page->pfmemalloc from skb_alloc_page to skb
Applying: netvm-propagate-page-pfmemalloc-from-skb_alloc_page-to-skb-fix
Applying: netvm: set PF_MEMALLOC as appropriate during SKB processing
Applying: mm: micro-optimise slab to avoid a function call
Applying: nbd: set SOCK_MEMALLOC for access to PFMEMALLOC reserves
Applying: mm: throttle direct reclaimers if PF_MEMALLOC reserves are low and swap is backed by network storage
Applying: mm: account for the number of times direct reclaimers get throttled
Applying: netvm: prevent a stream-specific deadlock
Applying: selinux: tag avc cache alloc as non-critical
Applying: mm: methods for teaching filesystems about PG_swapcache pages
Applying: mm: add support for a filesystem to activate swap files and use direct_IO for writing swap pages
Applying: mm: swap: implement generic handler for swap_activate
Applying: mm: add get_kernel_page[s] for pinning of kernel addresses for I/O
Applying: mm: add support for direct_IO to highmem pages
Applying: nfs: teach the NFS client how to treat PG_swapcache pages
Applying: nfs: disable data cache revalidation for swapfiles
Applying: nfs: enable swap on NFS
Applying: nfs: prevent page allocator recursions with swap over NFS.
Applying: swapfile: avoid dereferencing bd_disk during swap_entry_free for network storage
Applying: mm: memcg: fix compaction/migration failing due to memcg limits
Applying: mm: swapfile: clean up unuse_pte race handling
Applying: mm: memcg: push down PageSwapCache check into uncharge entry functions
Applying: mm: memcg: only check for PageSwapCache when uncharging anon
Applying: mm: memcg: move swapin charge functions above callsites
Applying: mm: memcg: remove unneeded shmem charge type
Applying: mm: memcg: remove needless !mm fixup to init_mm when charging
Applying: mm: memcg: split swapin charge function into private and public part
Applying: mm: memcg: only check swap cache pages for repeated charging
Applying: mm: memcg: only check anon swapin page charges for swap cache
Applying: mm: mmu_notifier: fix freed page still mapped in secondary MMU
Applying: memcg: prevent OOM with too many dirty pages
Applying: memcg: further prevent OOM with too many dirty pages
Applying: memcg: add mem_cgroup_from_css() helper
Applying: memcg-add-mem_cgroup_from_css-helper-fix
Applying: shmem: provide vm_ops when also providing a mem policy
Applying: tmpfs: interleave the starting node of /dev/shmem
Applying: frv: kill used but uninitialized variable
Applying: alpha: remove mysterious if zero-ed out includes
Applying: avr32/mm/fault.c: port OOM changes to do_page_fault
Applying: avr32-mm-faultc-port-oom-changes-to-do_page_fault-fix
Applying: clk: add non CONFIG_HAVE_CLK routines
Applying: clk: remove redundant depends on from drivers/Kconfig
Applying: i2c/i2c-pxa: remove conditional compilation of clk code
Applying: usb/marvell: remove conditional compilation of clk code
Applying: usb/musb: remove conditional compilation of clk code
Applying: ata/pata_arasan: remove conditional compilation of clk code
Applying: net/c_can: remove conditional compilation of clk code
Applying: net/stmmac: remove conditional compilation of clk code
Applying: gadget/m66592: remove conditional compilation of clk code
Applying: gadget/r8a66597: remove conditional compilation of clk code
Applying: usb/host/r8a66597: remove conditional compilation of clk code
Applying: arch/arm/mach-netx/fb.c: reuse dummy clk routines for CONFIG_HAVE_CLK=n
Applying: clk: validate pointer in __clk_disable()
Applying: panic: fix a possible deadlock in panic()
Applying: NMI watchdog: fix for lockup detector breakage on resume
Applying: kernel/sys.c: avoid argv_free(NULL)
Applying: kmsg: /dev/kmsg - properly return possible copy_from_user() failure
Applying: printk: add generic functions to find KERN_<LEVEL> headers
Applying: printk-add-generic-functions-to-find-kern_level-headers-fix
Applying: printk: add kern_levels.h to make KERN_<LEVEL> available for asm use
Applying: arch: remove direct definitions of KERN_<LEVEL> uses
Applying: btrfs: use printk_get_level and printk_skip_level, add __printf, fix fallout
Applying: btrfs-use-printk_get_level-and-printk_skip_level-add-__printf-fix-fallout-fix
Applying: btrfs-use-printk_get_level-and-printk_skip_level-add-__printf-fix-fallout-checkpatch-fixes
Applying: sound: use printk_get_level and printk_skip_level
Applying: printk: convert the format for KERN_<LEVEL> to a 2 byte pattern
Applying: printk: only look for prefix levels in kernel messages
Applying: printk: remove the now unnecessary "C" annotation for KERN_CONT
Applying: vsprintf: add %pMR for Bluetooth MAC address
Applying: Documentation/printk-formats.txt: add description for %pMR
Applying: lib/vsprintf.c: remind people to update Documentation/printk-formats.txt when adding printk formats
Applying: lib/vsprintf.c: kptr_restrict: fix pK-error in SysRq show-all-timers(Q)
Applying: MAINTAINERS: update EXYNOS DP DRIVER F: patterns
Applying: drivers/video/backlight/atmel-pwm-bl.c: use devm_ functions
Applying: drivers/video/backlight/ot200_bl.c: use devm_ functions
Applying: drivers/video/backlight/lm3533_bl.c: use devm_ functions
Applying: backlight: atmel-pwm-bl: use devm_gpio_request()
Applying: backlight: ot200_bl: use devm_gpio_request()
Applying: backlight: tosa_lcd: use devm_gpio_request()
Applying: backlight: tosa_bl: use devm_gpio_request()
Applying: backlight: lms283gf05: use devm_gpio_request()
Applying: backlight: corgi_lcd: use devm_gpio_request()
Applying: backlight: l4f00242t03: export and use devm_gpio_request_one()
Applying: backlight: move register definitions from header to source
Applying: backlight: move lp855x header into platform_data directory
Applying: string: introduce memweight()
Applying: string-introduce-memweight-fix
Applying: string: fix build error caused by memweight() introduction
Applying: qnx4fs: use memweight()
Applying: dm: use memweight()
Applying: affs: use memweight()
Applying: video/uvc: use memweight()
Applying: ocfs2: use memweight()
Applying: ext2: use memweight()
Applying: ext3: use memweight()
Applying: ext4: use memweight()
Applying: ipc/mqueue: remove unnecessary rb_init_node() calls
Applying: rbtree: reference Documentation/rbtree.txt for usage instructions
Applying: rbtree: empty nodes have no color
Applying: rbtree: fix incorrect rbtree node insertion in fs/proc/proc_sysctl.c
Applying: rbtree: move some implementation details from rbtree.h to rbtree.c
Applying: rbtree: fix jffs2 build issue due to renamed __rb_parent_color field
Applying: rbtree: performance and correctness test
Applying: rbtree: break out of rb_insert_color loop after tree rotation
Applying: rbtree: adjust root color in rb_insert_color() only when necessary
Applying: rbtree: low level optimizations in rb_insert_color()
Applying: rbtree: adjust node color in __rb_erase_color() only when necessary
Applying: rbtree: optimize case selection logic in __rb_erase_color()
Applying: rbtree: low level optimizations in __rb_erase_color()
Applying: rbtree: coding style adjustments
Applying: rbtree: rb_erase updates and comments
Applying: rbtree: optimize fetching of sibling node
Applying: atomic64_test: simplify the #ifdef for atomic64_dec_if_positive() test
Applying: checkpatch: Update alignment check
Applying: checkpatch: test for non-standard signatures
Applying: checkpatch: check usleep_range() arguments
Applying: checkpatch: Add acheck for use of sizeof without parenthesis
Applying: checkpatch-add-check-for-use-of-sizeof-without-parenthesis-v2
Applying: checkpatch: add checks for do {} while (0) macro misuses
Applying: nsproxy: move free_nsproxy() out of do_exit() path
Applying: drivers/message/i2o/i2o_proc.c: the pointer returned from chtostr() points to an array which is no longer valid
Applying: drivers/rtc/rtc-coh901331.c: use clk_prepare/unprepare
Applying: drivers/rtc/rtc-coh901331.c: use devm allocation
Applying: rtc: pl031: encapsulate per-vendor ops
Applying: rtc: pl031: use per-vendor variables for special init
Applying: rtc: pl031: fix up IRQ flags
Applying: drivers/rtc/rtc-ab8500.c: use UIE emulation
Applying: drivers-rtc-rtc-ab8500c-use-uie-emulation-checkpatch-fixes
Applying: drivers/rtc/rtc-ab8500.c: remove fix for AB8500 ED version
Applying: drivers/rtc/rtc-r9701.c: avoid second call to rtc_valid_tm()
Applying: drivers/rtc/rtc-r9701.c: check that r9701_set_datetime() succeeded
Applying: drivers/rtc/rtc-s3c.c: replace #include header files from asm/* to linux/*
Applying: rtc/mc13xxx: use MODULE_DEVICE_TABLE instead of MODULE_ALIAS
Applying: rtc/mc13xxx: add support for the rtc in the mc34708 pmic
Applying: rtc/rtc-88pm80x: assign ret only when rtc_register_driver fails
Applying: rtc/rtc-88pm80x: remove unneed devm_kfree
Applying: rtc/rtc-da9052: remove unneed devm_kfree call
Applying: nilfs2: add omitted comment for ns_mount_state field of the_nilfs structure
Applying: nilfs2: remove references to long gone super operations
Applying: nilfs2: fix timing issue between rmcp and chcp ioctls
Applying: nilfs2: fix deadlock issue between chcp and thaw ioctls
Applying: nilfs2: add omitted comments for structures in nilfs2_fs.h
Applying: nilfs2: add omitted comments for different structures in driver implementation
Applying: hfsplus: use -ENOMEM when kzalloc() fails
Applying: fat: accessors for msdos_dir_entry 'start' fields
Applying: fat: Refactor shortname parsing
Applying: fat (exportfs): move NFS support code
Applying: fat (exportfs): fix dentry reconnection
Applying: kernel/kmod.c: document call_usermodehelper_fns() a bit
Applying: kmod: avoid deadlock from recursive kmod call
Applying: coredump: fix wrong comments on core limits of pipe coredump case
Applying: fork: use vma_pages() to simplify the code
Applying: fork-use-vma_pages-to-simplify-the-code-fix
Applying: revert "sched: Fix fork() error path to not crash"
Applying: fork: fix error handling in dup_task()
Applying: kdump: append newline to the last lien of vmcoreinfo note
Applying: ipc: add COMPAT_SHMLBA support
Applying: ipc: allow compat IPC version field parsing if !ARCH_WANT_OLD_COMPAT_IPC
Applying: ipc: compat: use signed size_t types for msgsnd and msgrcv
Applying: ipc: use Kconfig options for __ARCH_WANT_[COMPAT_]IPC_PARSE_VERSION
Applying: ipc/sem.c: alternatives to preempt_disable()
Applying: sysctl: suppress kmemleak messages
Applying: pps: return PTR_ERR on error in device_create
Applying: fs: cachefiles: add support for large files in filesystem caching
Applying: include/linux/aio.h: cpp->C conversions
Applying: resource: make sure requested range is included in the root range
Applying: c/r: fcntl: add F_GETOWNER_UIDS option
Applying: fault-injection: notifier error injection
Applying: notifier error injection documentation
Applying: cpu: rewrite cpu-notifier-error-inject module
Applying: PM: PM notifier error injection module
Applying: memory: memory notifier error injection module
Applying: notifier error injection: fix copy-and-paste error in Kconfig help
Applying: powerpc: pSeries reconfig notifier error injection module
Applying: fault-injection: add selftests for cpu and memory hotplug
Applying: fault-injection: add tool to run command with failslab or fail_page_alloc
Applying: fault-injection: mention failcmd.sh tool in document
Applying: lib/scatterlist: do not re-write gfp_flags in __sg_alloc_table()
Merging quilt/akpm (3000089 lib/scatterlist: do not re-write gfp_flags in __sg_alloc_table())

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: Tree for July 30

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 13105 bytes --]

Hi all,

Changes since 20100729:

The s5p tree gained a conflict against the arm tree.

The tegra tree gained conflicts against the arm and s5p trees.

The 52xx-and-virtex tree lost its conflict.

The net tree lost its build failure.

The kvm tree still has its build failure.

The security-testing tree gained a build failure so I used the version
from next-20100729.

The devicetree tree gained a build failure so I used the version from
next-20100729.

The tip tree lost its build failure.

----------------------------------------------------------------------------

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/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 (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 168 trees (counting Linus' and 22 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 fixes/fixes
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/rc-fixes
Merging quilt/driver-core.current
Merging quilt/tty.current
Merging quilt/usb.current
Merging quilt/staging.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging ide-curent/master
Merging dwmw2/master
Merging gcl-current/merge
Merging arm/devel
Merging davinci/davinci-next
Merging i.MX/for-next
CONFLICT (add/add): Merge conflict in drivers/media/video/mx2_camera.c
Merging msm/for-next
Merging omap/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-3430sdp.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-3630sdp.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-am3517evm.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-cm-t35.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-devkit8000.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-igep0020.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-ldp.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-omap3beagle.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-omap3evm.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-omap3pandora.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-omap3touchbook.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-overo.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-zoom2.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-zoom3.c
Merging pxa/for-next
Merging samsung/next-samsung
Merging s5p/for-next
CONFLICT (content): Merge conflict in arch/arm/Kconfig
Merging tegra/for-next
CONFLICT (content): Merge conflict in arch/arm/Kconfig
CONFLICT (content): Merge conflict in arch/arm/mm/Kconfig
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
Merging parisc/next
Merging powerpc/next
Merging 4xx/next
Merging 52xx-and-virtex/next
Merging galak/next
Merging s390/features
Merging sh/master
Merging genesis/master
CONFLICT (content): Merge conflict in arch/arm/configs/ap4evb_defconfig
CONFLICT (content): Merge conflict in arch/arm/configs/g3evm_defconfig
CONFLICT (content): Merge conflict in arch/arm/configs/g4evm_defconfig
Merging sparc/master
Merging tile/master
Merging xtensa/master
Merging ceph/for-next
Merging cifs/master
Merging configfs/linux-next
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging jfs/next
Merging logfs/master
CONFLICT (content): Merge conflict in fs/logfs/logfs.h
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging omfs/for-next
Merging squashfs/master
Merging udf/for_next
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
CONFLICT (content): Merge conflict in fs/ext4/inode.c
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_aops.c
Merging vfs/for-next
CONFLICT (content): Merge conflict in fs/nilfs2/super.c
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_aops.c
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_super.c
Applying: v9fs: fixup for inode_setattr being removed
Applying: xfs: update tracing for clear_inode to evit_inode transition
Applying: cifs: fix for clear_inode -> evict_inode API change
Merging pci/linux-next
Merging hid/for-next
Merging quilt/i2c
Merging bjdooks-i2c/next-i2c
CONFLICT (content): Merge conflict in arch/arm/plat-omap/i2c.c
CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-cpm.c
CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-mpc.c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging kbuild/for-next
Merging kconfig/for-next
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging idle-test/idle-test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/linux-next
CONFLICT (content): Merge conflict in arch/x86/kvm/paging_tmpl.h
Applying: kvm: u64's should be printed with %llx
Merging dlm/next
Merging ibft/master
Merging swiotlb/master
Merging scsi/master
Merging async_tx/next
CONFLICT (content): Merge conflict in arch/arm/mach-ux500/devices-db8500.c
Merging net/master
CONFLICT (content): Merge conflict in drivers/net/e1000e/hw.h
CONFLICT (content): Merge conflict in net/bridge/br_input.c
Merging wireless/master
Merging mtd/master
Merging crypto/master
Merging sound/for-next
CONFLICT (content): Merge conflict in Documentation/kernel-parameters.txt
Merging cpufreq/next
Merging quilt/rr
CONFLICT (content): Merge conflict in arch/um/drivers/hostaudio_kern.c
Merging input/next
CONFLICT (add/add): Merge conflict in arch/arm/plat-samsung/include/plat/keypad.h
Merging lsm/for-next
Merging block/for-next
CONFLICT (content): Merge conflict in drivers/block/virtio_blk.c
CONFLICT (content): Merge conflict in drivers/scsi/scsi_error.c
Merging quilt/device-mapper
CONFLICT (content): Merge conflict in drivers/md/dm.c
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
CONFLICT (content): Merge conflict in drivers/power/Kconfig
CONFLICT (content): Merge conflict in drivers/power/Makefile
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 mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging viafb/viafb-next
Merging voltage/for-next
Merging security-testing/next
$ git reset --hard HEAD^
Merging refs/next/20100729/security-testing
Merging lblnet/master
Merging agp/agp-next
Merging uwb/for-upstream
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging quilt/aoe
Merging suspend/linux-next
CONFLICT (content): Merge conflict in drivers/net/wireless/ipw2x00/ipw2100.c
Merging bluetooth/master
Merging fsnotify/for-next
CONFLICT (delete/modify): fs/notify/inotify/inotify.c deleted in fsnotify/for-next and modified in HEAD. Version HEAD of fs/notify/inotify/inotify.c left in tree.
$ git rm -f fs/notify/inotify/inotify.c
Merging irda/for-next
CONFLICT (content): Merge conflict in drivers/net/irda/irda-usb.c
Merging catalin/for-next
CONFLICT (content): Merge conflict in arch/arm/include/asm/io.h
CONFLICT (content): Merge conflict in arch/arm/kernel/entry-armv.S
CONFLICT (content): Merge conflict in arch/arm/mm/cache-l2x0.c
CONFLICT (content): Merge conflict in arch/arm/mm/mmu.c
Merging alacrity/linux-next
Merging i7core_edac/linux_next
CONFLICT (content): Merge conflict in MAINTAINERS
Merging devicetree/next-devicetree
CONFLICT (content): Merge conflict in arch/microblaze/kernel/Makefile
$ git reset --hard HEAD^
Merging refs/next/20100729/devicetree
CONFLICT (content): Merge conflict in arch/microblaze/kernel/Makefile
[master b590161] Merge commit 'refs/next/20100729/devicetree'
Merging spi/next-spi
Merging limits/writable_limits
CONFLICT (content): Merge conflict in arch/x86/ia32/ia32entry.S
CONFLICT (content): Merge conflict in arch/x86/include/asm/unistd_32.h
CONFLICT (content): Merge conflict in arch/x86/include/asm/unistd_64.h
CONFLICT (content): Merge conflict in arch/x86/kernel/syscall_table_32.S
CONFLICT (content): Merge conflict in include/asm-generic/unistd.h
Merging omap_dss2/for-next
Merging xen/upstream/xen
Merging tip/auto-latest
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
CONFLICT (content): Merge conflict in Makefile
CONFLICT (content): Merge conflict in arch/powerpc/kernel/time.c
CONFLICT (content): Merge conflict in drivers/Makefile
CONFLICT (content): Merge conflict in drivers/cpufreq/cpufreq.c
Merging lost-spurious-irq/lost-spurious-irq
Merging edac-amd/for-next
Merging oprofile/for-next
Merging percpu/for-next
Merging workqueues/for-next
CONFLICT (content): Merge conflict in fs/cifs/cifsfs.c
CONFLICT (content): Merge conflict in fs/cifs/cifsglob.h
CONFLICT (content): Merge conflict in fs/cifs/file.c
CONFLICT (content): Merge conflict in include/linux/libata.h
CONFLICT (content): Merge conflict in include/linux/workqueue.h
CONFLICT (content): Merge conflict in kernel/trace/Kconfig
CONFLICT (content): Merge conflict in kernel/workqueue.c
Merging sfi/sfi-test
Merging asm-generic/next
Merging drivers-x86/linux-next
Merging hwpoison/hwpoison
CONFLICT (content): Merge conflict in mm/memory-failure.c
Merging sysctl/master
Merging bkl-core/bkl/core
Merging bkl-procfs/bkl/procfs
Merging bkl-ioctl/bkl/ioctl
Merging quilt/driver-core
Merging quilt/tty
CONFLICT (content): Merge conflict in include/linux/serial_core.h
Merging quilt/usb
Merging staging-next/staging-next
CONFLICT (content): Merge conflict in drivers/staging/Kconfig
CONFLICT (content): Merge conflict in drivers/staging/batman-adv/bat_sysfs.c
CONFLICT (delete/modify): drivers/staging/batman-adv/device.c deleted in staging-next/staging-next and modified in HEAD. Version HEAD of drivers/staging/batman-adv/device.c left in tree.
CONFLICT (content): Merge conflict in drivers/staging/batman-adv/hard-interface.c
CONFLICT (delete/modify): drivers/staging/cx25821/cx25821-audups11.c deleted in HEAD and modified in staging-next/staging-next. Version staging-next/staging-next of drivers/staging/cx25821/cx25821-audups11.c left in tree.
$ git rm -f drivers/staging/cx25821/cx25821-audups11.c
$ git rm -f drivers/staging/batman-adv/device.c
Merging slabh/slabh
Merging scsi-post-merge/merge-base:master
$ git checkout scsi-post-merge/master
Applying: [SCSI] be2iscsi: Add support for iscsi boot
Applying: [SCSI] be2iscsi: Increase max sector
Applying: [SCSI] be2iscsi: Driver Version change to 2.0.549.0

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

linux-next: Tree for July 30

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 8553 bytes --]

Hi all,

Changes since 20090729:

New trees: kmemleak (really this time - it was accidentally left out of
	yesterday's tree)

Dropped tree: kmemleak (build problem)

This tree fails to build for powerpc allyesconfig (final link problem).

The scsi-rc-fixes tree gained a build failure so I reverted a commit.

The i2c series failed to import so I used the version from next-20090729.

The edac-amd tree gained a conflict against the rr tree.

The fsnotify tree lost its conflict.

The drbd tree lost one of its build failures.

The kmemleak tree gained a build failure so I dropped it for today as I
have no previous version to use.

----------------------------------------------------------------------------

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 (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES) and i386, sparc and sparc64 defconfig.
These builds also have CONFIG_ENABLE_WARN_DEPRECATED,
CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 135 trees (counting Linus' and 19 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 fixes/fixes
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
Merging crypto-current/master
Merging dwmw2/master
Merging arm/devel
Merging davinci/for-next
Merging pxa/for-next
Merging thumb-2/thumb-2
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
CONFLICT (content): Merge conflict in arch/mips/cavium-octeon/dma-octeon.c
CONFLICT (add/add): Merge conflict in arch/mips/cavium-octeon/executive/cvmx-helper-errata.c
CONFLICT (content): Merge conflict in arch/mips/mm/tlbex.c
CONFLICT (content): Merge conflict in arch/mips/sibyte/swarm/setup.c
CONFLICT (content): Merge conflict in drivers/char/hw_random/Kconfig
CONFLICT (content): Merge conflict in drivers/char/hw_random/Makefile
CONFLICT (add/add): Merge conflict in drivers/dma/txx9dmac.c
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging xtensa/master
Merging cifs/master
Merging configfs/linux-next
CONFLICT (content): Merge conflict in fs/configfs/dir.c
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging jfs/next
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging squashfs/master
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
Merging reiserfs-bkl/reiserfs/kill-bkl-rc6
CONFLICT (content): Merge conflict in fs/reiserfs/journal.c
CONFLICT (content): Merge conflict in fs/reiserfs/super.c
Merging vfs/for-next
Merging pci/linux-next
Merging hid/for-next
Merging quilt/i2c
CONFLICT (content): Merge conflict in drivers/i2c/chips/tsl2550.c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/board-dm646x-evm.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm355.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm644x.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm646x.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/include/mach/dm355.h
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/include/mach/dm644x.h
CONFLICT (content): Merge conflict in drivers/media/dvb/b2c2/flexcop-fe-tuner.c
Merging quota/for_next
Merging kbuild/master
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging async_tx/next
Merging udf/for_next
Merging net/master
CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-3945.h
CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-tx.c
CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl3945-base.c
Merging wireless/master
Merging mtd/master
Merging crypto/master
Merging sound/for-next
Merging cpufreq/next
Merging quilt/rr
Merging mmc/next
Merging input/next
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
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 mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging agp/agp-next
Merging uwb/for-upstream
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging omap/for-next
Merging quilt/aoe
Merging suspend/linux-next
Merging bluetooth/master
Merging edac-amd/for-next
CONFLICT (content): Merge conflict in include/linux/topology.h
Merging fsnotify/for-next
Merging irda/for-next
Merging hwlat/for-linus
Merging drbd/drbd
Applying: drbd: fix for removal of blk_queue_stack_limits
Merging kmemleak/kmemleak
$ git reset --hard HEAD^
Merging tip/auto-latest
CONFLICT (content): Merge conflict in drivers/oprofile/oprofile_stats.c
CONFLICT (content): Merge conflict in include/linux/rcupdate.h
Merging percpu/for-next
CONFLICT (content): Merge conflict in arch/sh/kernel/vmlinux.lds.S
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/perf_counter.c
CONFLICT (content): Merge conflict in drivers/cpufreq/cpufreq_ondemand.c
Merging sfi/sfi-test
Merging asm-generic/next
Merging quilt/driver-core
CONFLICT (content): Merge conflict in init/main.c
Merging quilt/usb
CONFLICT (content): Merge conflict in drivers/usb/gadget/m66592-udc.c
CONFLICT (content): Merge conflict in drivers/usb/host/r8a66597-hcd.c
Merging quilt/staging
CONFLICT (delete/modify): drivers/staging/epl/VirtualEthernetLinux.c deleted in quilt/staging and modified in HEAD. Version HEAD of drivers/staging/epl/VirtualEthernetLinux.c left in tree.
$ git rm -f drivers/staging/epl/VirtualEthernetLinux.c
Merging scsi-post-merge/master
[master 469ff03] Revert "[SCSI] libsas: fix wide port hotplug issues"

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]