* Re: [s390] next Feb 18: defconfig build break
From: Mike Frysinger @ 2009-02-19 17:14 UTC (permalink / raw)
To: Rusty Russell
Cc: Stephen Rothwell, Sachin P. Sant, linux-s390, linux-next, LKML,
schwidefsky, heiko.carstens
In-Reply-To: <200902192210.10368.rusty@rustcorp.com.au>
On Thu, Feb 19, 2009 at 06:40, Rusty Russell wrote:
> On Thursday 19 February 2009 12:25:13 Mike Frysinger wrote:
>> > +char *strncpy(char *dest, const char *src, size_t n);
>> > #define strncpy __inline_strncpy
>> > #include <asm/string.h>
>> > #undef strncpy
>>
>> size_t is not a builtin type so there needs to be a linux/types.h
>> include right above these two prototypes. then things build up fine
>> for me.
>
> OK, this time for sure!
>
>
> blackfin: allow usage of string functions in linux/string.h
>
> In introducing a trivial "strstarts()" function in linux/string.h, we
> hit the following error on blackfin:
>
> file included from include/linux/bitmap.h:9,
> from include/linux/nodemask.h:90,
> from include/linux/mmzone.h:17,
> from include/linux/gfp.h:5,
> from include/linux/kmod.h:23,
> from include/linux/module.h:14,
> from arch/blackfin/lib/strncmp.c:14:
> include/linux/string.h: In function 'strstarts':
> include/linux/string.h:124: error: implicit declaration of function 'strncmp'
>
> Because when including asm/string.h from arch/blackfin/lib/strncmp.c,
> we don't declare the string op we are about to define, and
> linux/string.h barfs.
>
> The fix is to declare the function whose definition we steal via the
> #define trick. I do this for all of them, so this won't bite us in
> future.
>
> Reported-by: linux-next
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Tested-by: Mike Frysinger <vapier@gentoo.org>
-mike
^ permalink raw reply
* [PATCH -next] eeepc: needs to depend on INPUT
From: Randy Dunlap @ 2009-02-19 17:16 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, Andrew Morton, Corentin Chary
In-Reply-To: <20090220002832.cad00fcd.sfr@canb.auug.org.au>
From: Randy Dunlap <randy.dunlap@oracle.com>
EEEPC_LAPTOP needs to depend on INPUT to fix build errors that
can happen when EEEPC_LAPTOP=y and INPUT=m:
drivers/built-in.o: In function `eeepc_hotk_add':
eeepc-laptop.c:(.text+0x14f403): undefined reference to `input_allocate_device'
eeepc-laptop.c:(.text+0x14f7a4): undefined reference to `input_register_device'
eeepc-laptop.c:(.text+0x14f7c8): undefined reference to `input_free_device'
drivers/built-in.o: In function `eeepc_input_exit':
eeepc-laptop.c:(.text+0x14f9d7): undefined reference to `input_unregister_device'
drivers/built-in.o: In function `eeepc_hotk_notify':
eeepc-laptop.c:(.text+0x14faf6): undefined reference to `input_event'
eeepc-laptop.c:(.text+0x14fb0c): undefined reference to `input_event'
eeepc-laptop.c:(.text+0x14fb32): undefined reference to `input_event'
eeepc-laptop.c:(.text+0x14fb48): undefined reference to `input_event'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
cc: Corentin Chary <corentincj@iksaif.net>
---
drivers/platform/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20090219.orig/drivers/platform/x86/Kconfig
+++ linux-next-20090219/drivers/platform/x86/Kconfig
@@ -313,7 +313,7 @@ config INTEL_MENLOW
config EEEPC_LAPTOP
tristate "Eee PC Hotkey Driver (EXPERIMENTAL)"
- depends on ACPI
+ depends on ACPI && INPUT
depends on EXPERIMENTAL
select BACKLIGHT_CLASS_DEVICE
select HWMON
^ permalink raw reply
* Re: [PATCH -next] eeepc: needs to depend on INPUT
From: Corentin Chary @ 2009-02-19 18:12 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, Andrew Morton
In-Reply-To: <499D93F0.2090803@oracle.com>
On Thu, Feb 19, 2009 at 6:16 PM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> EEEPC_LAPTOP needs to depend on INPUT to fix build errors that
> can happen when EEEPC_LAPTOP=y and INPUT=m:
There is already a patch sent to linux-acpi and Len Brown.
http://patchwork.kernel.org/patch/7354/
--
Corentin Chary
http://xf.iksaif.net
^ permalink raw reply
* Re: [PATCH -next] eeepc: needs to depend on INPUT
From: Randy Dunlap @ 2009-02-19 18:17 UTC (permalink / raw)
To: Corentin Chary
Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML, Andrew Morton
In-Reply-To: <71cd59b00902191012k764bab32n85f54fc049e35035@mail.gmail.com>
Corentin Chary wrote:
> On Thu, Feb 19, 2009 at 6:16 PM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>
>> EEEPC_LAPTOP needs to depend on INPUT to fix build errors that
>> can happen when EEEPC_LAPTOP=y and INPUT=m:
>
> There is already a patch sent to linux-acpi and Len Brown.
>
> http://patchwork.kernel.org/patch/7354/
Today's linux-next doesn't build (doesn't have that patch). :(
--
~Randy
^ permalink raw reply
* [PATCH] integrity: ima scatterlist bug fix
From: Mimi Zohar @ 2009-02-20 2:23 UTC (permalink / raw)
To: linux-next
Cc: Mimi Zohar, Alexander Beregalov, David Safford, LKML, Mimi Zohar
Based on Alexander Beregalov's post http://lkml.org/lkml/2009/2/19/198
- replaced sg_set_buf() with sg_init_one()
kernel BUG at include/linux/scatterlist.h:65!
invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
last sysfs file:
CPU 2
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.29-rc5-next-20090219 #5 PowerEdge 1950
RIP: 0010:[<ffffffff8045ec70>] [<ffffffff8045ec70>] ima_calc_hash+0xc0/0x160
RSP: 0018:ffff88007f46bc40 EFLAGS: 00010286
RAX: ffffe200032c45e8 RBX: 00000000fffffff4 RCX: 0000000087654321
RDX: 0000000000000002 RSI: 0000000000000001 RDI: ffff88007cf71048
RBP: ffff88007f46bcd0 R08: 0000000000000000 R09: 0000000000000163
R10: ffff88007f4707a8 R11: 0000000000000000 R12: ffff88007cf71048
R13: 0000000000001000 R14: 0000000000000000 R15: 0000000000009d98
FS: 0000000000000000(0000) GS:ffff8800051ac000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
---
security/integrity/ima/ima_crypto.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
index c2a46e4..50d572b 100644
--- a/security/integrity/ima/ima_crypto.c
+++ b/security/integrity/ima/ima_crypto.c
@@ -68,7 +68,7 @@ int ima_calc_hash(struct file *file, char *digest)
break;
}
offset += rbuf_len;
- sg_set_buf(sg, rbuf, rbuf_len);
+ sg_init_one(sg, rbuf, rbuf_len);
rc = crypto_hash_update(&desc, sg, rbuf_len);
if (rc)
@@ -95,7 +95,7 @@ int ima_calc_template_hash(int template_len, void *template, char *digest)
if (rc != 0)
return rc;
- sg_set_buf(sg, template, template_len);
+ sg_init_one(sg, template, template_len);
rc = crypto_hash_update(&desc, sg, template_len);
if (!rc)
rc = crypto_hash_final(&desc, digest);
--
1.5.6.6
^ permalink raw reply related
* Re: next-20090219: IMA: kernel BUG at include/linux/scatterlist.h:65
From: Mimi Zohar @ 2009-02-20 3:59 UTC (permalink / raw)
To: Alexander Beregalov
Cc: LKML, linux-next@vger.kernel.org, James Morris, David Safford
In-Reply-To: <a4423d670902190651t71638aaepbc2ba49b9b6a25c6@mail.gmail.com>
Alexander Beregalov <a.beregalov@gmail.com> wrote on 02/19/2009 09:51:12
AM:
> Hi
>
> kernel BUG at include/linux/scatterlist.h:65!
> invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> last sysfs file:
> CPU 2
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.29-rc5-next-20090219 #5 PowerEdge
1950
> RIP: 0010:[<ffffffff8045ec70>] [<ffffffff8045ec70>]
ima_calc_hash+0xc0/0x160
> RSP: 0018:ffff88007f46bc40 EFLAGS: 00010286
> RAX: ffffe200032c45e8 RBX: 00000000fffffff4 RCX: 0000000087654321
> RDX: 0000000000000002 RSI: 0000000000000001 RDI: ffff88007cf71048
> RBP: ffff88007f46bcd0 R08: 0000000000000000 R09: 0000000000000163
> R10: ffff88007f4707a8 R11: 0000000000000000 R12: ffff88007cf71048
> R13: 0000000000001000 R14: 0000000000000000 R15: 0000000000009d98
> FS: 0000000000000000(0000) GS:ffff8800051ac000(0000)
knlGS:0000000000000000
> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process swapper (pid: 1, threadinfo ffff88007f46a000, task
ffff88007f470000)
> Stack:
> ffffffff8045e49e 0000004800000246 ffff88007cfbc3b8 ffff88007c853980
> ffffffff8045e49e 0000000000000002 ffff88007cfbc440 ffff88007cfbc418
> 2222222222222222 2222222222222222 ffff88007d878b88 2222222200000000
> Call Trace:
> [<ffffffff8045e49e>] ? process_measurement+0x9e/0x110
> [<ffffffff8045e49e>] ? process_measurement+0x9e/0x110
The patch I posted on linux-next resolves this bug
(http://marc.info/?l=linux-next&m=123509665514552&w=2).
Mimi Zohar
^ permalink raw reply
* linux-next: manual merge of the slab tree with the ftrace tree
From: Stephen Rothwell @ 2009-02-20 5:57 UTC (permalink / raw)
To: Christoph Lameter
Cc: linux-next, Eduard - Gabriel Munteanu, Pekka Enberg,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
Hi all,
Today's linux-next merge of the slab tree got a conflict in mm/slub.c
between commit 5b882be4e00e53a44f47ad7eb997cac2938848bf ("kmemtrace: SLUB
hooks") from the ftrace tree and commit
8573e12414365585bfd601dc8c093b3efbef8854 ("SLUB: Do not pass 8k objects
through to the page allocator") from the slab tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc mm/slub.c
index e6bf32f,23115bd..0000000
--- a/mm/slub.c
+++ b/mm/slub.c
@@@ -2689,9 -2661,8 +2693,9 @@@ static struct kmem_cache *get_slab(size
void *__kmalloc(size_t size, gfp_t flags)
{
struct kmem_cache *s;
+ void *ret;
- if (unlikely(size > PAGE_SIZE))
+ if (unlikely(size > SLUB_MAX_SIZE))
return kmalloc_large(size, flags);
s = get_slab(size, flags);
@@@ -2723,18 -2689,9 +2727,19 @@@ static void *kmalloc_large_node(size_t
void *__kmalloc_node(size_t size, gfp_t flags, int node)
{
struct kmem_cache *s;
+ void *ret;
- if (unlikely(size > SLUB_MAX_SIZE))
- return kmalloc_large_node(size, flags, node);
++ if (unlikely(size > SLUB_MAX_SIZE)) {
+ if (unlikely(size > PAGE_SIZE)) {
+ ret = kmalloc_large_node(size, flags, node);
+
+ kmemtrace_mark_alloc_node(KMEMTRACE_TYPE_KMALLOC,
+ _RET_IP_, ret,
+ size, PAGE_SIZE << get_order(size),
+ flags, node);
+
+ return ret;
+ }
s = get_slab(size, flags);
@@@ -3276,9 -3225,8 +3281,9 @@@ static struct notifier_block __cpuinitd
void *__kmalloc_track_caller(size_t size, gfp_t gfpflags, unsigned long caller)
{
struct kmem_cache *s;
+ void *ret;
- if (unlikely(size > PAGE_SIZE))
+ if (unlikely(size > SLUB_MAX_SIZE))
return kmalloc_large(size, gfpflags);
s = get_slab(size, gfpflags);
@@@ -3299,9 -3241,8 +3304,9 @@@ void *__kmalloc_node_track_caller(size_
int node, unsigned long caller)
{
struct kmem_cache *s;
+ void *ret;
- if (unlikely(size > PAGE_SIZE))
+ if (unlikely(size > SLUB_MAX_SIZE))
return kmalloc_large_node(size, gfpflags, node);
s = get_slab(size, gfpflags);
^ permalink raw reply
* linux-next: hid tree build warning
From: Stephen Rothwell @ 2009-02-20 8:08 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linux-next, Oliver Neukum
[-- Attachment #1: Type: text/plain, Size: 481 bytes --]
Hi Jiri,
Today's linux-next build (powerpc ppc64_defconfig) produced this warning:
drivers/hid/usbhid/hid-core.c:1337: warning: 'hid_reset_resume' defined but not used
Introduced by commit 8aa650161ced641fec0bc9c38e3dea6a1f315442 ("HID: fix
USB HID devices after STD with autosuspend") from the hid tree.
hid_reset_resume() is only used if CONFIG_PM is set.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the slab tree with the ftrace tree
From: Pekka Enberg @ 2009-02-20 8:25 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Christoph Lameter, linux-next, Eduard - Gabriel Munteanu,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
In-Reply-To: <20090220165728.7f2cec61.sfr@canb.auug.org.au>
On Fri, 2009-02-20 at 16:57 +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the slab tree got a conflict in mm/slub.c
> between commit 5b882be4e00e53a44f47ad7eb997cac2938848bf ("kmemtrace: SLUB
> hooks") from the ftrace tree and commit
> 8573e12414365585bfd601dc8c093b3efbef8854 ("SLUB: Do not pass 8k objects
> through to the page allocator") from the slab tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Looks good to me! Thanks once again Stephen!
^ permalink raw reply
* Re: linux-next: manual merge of the slab tree with the ftrace tree
From: Stephen Rothwell @ 2009-02-20 8:59 UTC (permalink / raw)
To: Christoph Lameter
Cc: linux-next, Eduard - Gabriel Munteanu, Pekka Enberg,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
In-Reply-To: <20090220165728.7f2cec61.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 708 bytes --]
Hi all,
On Fri, 20 Feb 2009 16:57:28 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> @@@ -2723,18 -2689,9 +2727,19 @@@ static void *kmalloc_large_node(size_t
> void *__kmalloc_node(size_t size, gfp_t flags, int node)
> {
> struct kmem_cache *s;
> + void *ret;
>
> - if (unlikely(size > SLUB_MAX_SIZE))
> - return kmalloc_large_node(size, flags, node);
> ++ if (unlikely(size > SLUB_MAX_SIZE)) {
> + if (unlikely(size > PAGE_SIZE)) {
Except I screwed that up. I meant to delete the last line above. I will
add a patch to the end of linux-next for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: Tree for February 20
From: Stephen Rothwell @ 2009-02-20 9:12 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 8134 bytes --]
Hi all,
Changes since 20090219:
The slab tree lost a conflict but gained another against the ftrace tree.
I mismerged the slab tree which caused a build failuer in mm/slub.c, so
applied a patch to the end of the linux-next tree for today.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig,
ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES) and
i386, sparc and sparc64 defconfig.
Below is a summary of the state of the merge.
We are up to 133 trees (counting Linus' and 18 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging dwmw2/master
Merging arm/devel
CONFLICT (content): Merge conflict in arch/arm/mach-at91/gpio.c
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging mips/mips-for-linux-next
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging pxa/for-next
CONFLICT (rename/modify): Merge conflict in arch/arm/plat-pxa/dma.c
Merging s390/features
Merging sh/master
Merging sparc/master
Merging x86/auto-x86-next
Merging xtensa/master
Merging quilt/driver-core
Merging quilt/usb
Merging tip-core/auto-core-next
Merging cpus4096/auto-cpus4096-next
Merging ftrace/auto-ftrace-next
CONFLICT (content): Merge conflict in arch/x86/Kconfig
Merging genirq/auto-genirq-next
CONFLICT (content): Merge conflict in kernel/irq/handle.c
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 pci/linux-next
Merging quilt/device-mapper
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
CONFLICT (content): Merge conflict in Documentation/kernel-parameters.txt
Merging v4l-dvb/master
Merging quota/for_next
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
Merging libata/NEXT
Merging nfs/linux-next
Merging xfs/master
Merging infiniband/for-next
Merging acpi/test
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging ocfs2/linux-next
Merging ext4/next
Merging async_tx/next
Merging udf/for_next
Merging net/master
CONFLICT (delete/modify): drivers/net/wireless/orinoco/orinoco.c deleted in net/master and modified in HEAD. Version HEAD of drivers/net/wireless/orinoco/orinoco.c left in tree.
CONFLICT (content): Merge conflict in drivers/net/wireless/p54/p54common.c
$ git rm -f drivers/net/wireless/orinoco/orinoco.c
Applying: orinoco merge fixup
Merging mtd/master
Merging wireless/master
CONFLICT (content): Merge conflict in drivers/net/wireless/ath9k/main.c
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
CONFLICT (content): Merge conflict in sound/soc/pxa/pxa2xx-i2s.c
Merging cpufreq/next
Merging v9fs/for-next
CONFLICT (content): Merge conflict in net/9p/protocol.c
Merging quilt/rr
CONFLICT (delete/modify): arch/x86/include/asm/es7000/apic.h deleted in HEAD and modified in quilt/rr. Version quilt/rr of arch/x86/include/asm/es7000/apic.h left in tree.
CONFLICT (delete/modify): arch/x86/include/asm/numaq/apic.h deleted in HEAD and modified in quilt/rr. Version quilt/rr of arch/x86/include/asm/numaq/apic.h left in tree.
CONFLICT (content): Merge conflict in drivers/hid/hid-core.c
CONFLICT (content): Merge conflict in drivers/media/video/saa7134/saa7134-core.c
CONFLICT (content): Merge conflict in drivers/media/video/saa7134/saa7134.h
CONFLICT (content): Merge conflict in drivers/net/virtio_net.c
CONFLICT (content): Merge conflict in kernel/module.c
$ git rm -f arch/x86/include/asm/es7000/apic.h
$ git rm -f arch/x86/include/asm/numaq/apic.h
Applying: rr: fixup for cpumask:remove-address-of-CPU_MASK_ALL
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging bkl-removal/bkl-removal
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in sound/isa/Kconfig
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
CONFLICT (content): Merge conflict in mm/slob.c
CONFLICT (content): Merge conflict in mm/slub.c
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 quilt/ttydev
Merging agp/agp-next
Merging kmemcheck/auto-kmemcheck-next
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (content): Merge conflict in mm/Makefile
Merging generic-ipi/auto-generic-ipi-next
Merging oprofile/auto-oprofile-next
Merging fastboot/auto-fastboot-next
Merging sparseirq/auto-sparseirq-next
Merging iommu/auto-iommu-next
CONFLICT (content): Merge conflict in arch/x86/include/asm/dma-mapping.h
Merging uwb/for-upstream
Merging watchdog/master
Merging proc/proc
CONFLICT (content): Merge conflict in security/selinux/hooks.c
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging fatfs/master
Merging fuse/for-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging squashfs/master
Merging omap/for-next
Merging quilt/aoe
Merging kmemleak/kmemleak
CONFLICT (content): Merge conflict in Documentation/kernel-parameters.txt
CONFLICT (content): Merge conflict in include/linux/slab.h
CONFLICT (content): Merge conflict in init/main.c
CONFLICT (content): Merge conflict in lib/Kconfig.debug
CONFLICT (content): Merge conflict in mm/slab.c
CONFLICT (content): Merge conflict in mm/slob.c
CONFLICT (content): Merge conflict in mm/slub.c
Merging quilt/staging
Merging scsi-post-merge/master
[master]: created bc1f7bb: "slab: fixup for bad merge"
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the slab tree with the ftrace tree
From: Ingo Molnar @ 2009-02-20 9:37 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Pekka Enberg, Christoph Lameter, linux-next,
Eduard - Gabriel Munteanu, Thomas Gleixner, H. Peter Anvin
In-Reply-To: <20090220195911.3bff30fb.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> On Fri, 20 Feb 2009 16:57:28 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > @@@ -2723,18 -2689,9 +2727,19 @@@ static void *kmalloc_large_node(size_t
> > void *__kmalloc_node(size_t size, gfp_t flags, int node)
> > {
> > struct kmem_cache *s;
> > + void *ret;
> >
> > - if (unlikely(size > SLUB_MAX_SIZE))
> > - return kmalloc_large_node(size, flags, node);
> > ++ if (unlikely(size > SLUB_MAX_SIZE)) {
> > + if (unlikely(size > PAGE_SIZE)) {
>
> Except I screwed that up. I meant to delete the last line
> above. I will add a patch to the end of linux-next for today.
Hm, i'd love to eliminate the conflict, but it would either mean
us to pull the slab tree into the tracing tree, or the other way
around - and both have quite many items queued up to make this
impractical.
Ingo
^ permalink raw reply
* Re: linux-next: manual merge of the slab tree with the ftrace tree
From: Pekka Enberg @ 2009-02-20 9:41 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Christoph Lameter, linux-next,
Eduard - Gabriel Munteanu, Thomas Gleixner, H. Peter Anvin
In-Reply-To: <20090220093734.GI24555@elte.hu>
Hi Ingo,
On Fri, 2009-02-20 at 10:37 +0100, Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi all,
> >
> > On Fri, 20 Feb 2009 16:57:28 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > @@@ -2723,18 -2689,9 +2727,19 @@@ static void *kmalloc_large_node(size_t
> > > void *__kmalloc_node(size_t size, gfp_t flags, int node)
> > > {
> > > struct kmem_cache *s;
> > > + void *ret;
> > >
> > > - if (unlikely(size > SLUB_MAX_SIZE))
> > > - return kmalloc_large_node(size, flags, node);
> > > ++ if (unlikely(size > SLUB_MAX_SIZE)) {
> > > + if (unlikely(size > PAGE_SIZE)) {
> >
> > Except I screwed that up. I meant to delete the last line
> > above. I will add a patch to the end of linux-next for today.
>
> Hm, i'd love to eliminate the conflict, but it would either mean
> us to pull the slab tree into the tracing tree, or the other way
> around - and both have quite many items queued up to make this
> impractical.
Is it a big problem, though? We could do the s/PAGE_SIZE/SLUB_MAX_SIZE/g
rename as a separate preparational patch (without any of the functional
changes) and see if Linus merges it to mainline...
Pekka
^ permalink raw reply
* Re: linux-next: manual merge of the slab tree with the ftrace tree
From: Ingo Molnar @ 2009-02-20 9:53 UTC (permalink / raw)
To: Pekka Enberg
Cc: Stephen Rothwell, Christoph Lameter, linux-next,
Eduard - Gabriel Munteanu, Thomas Gleixner, H. Peter Anvin
In-Reply-To: <1235122897.29813.28.camel@penberg-laptop>
* Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> Hi Ingo,
>
> On Fri, 2009-02-20 at 10:37 +0100, Ingo Molnar wrote:
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > > Hi all,
> > >
> > > On Fri, 20 Feb 2009 16:57:28 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > >
> > > > @@@ -2723,18 -2689,9 +2727,19 @@@ static void *kmalloc_large_node(size_t
> > > > void *__kmalloc_node(size_t size, gfp_t flags, int node)
> > > > {
> > > > struct kmem_cache *s;
> > > > + void *ret;
> > > >
> > > > - if (unlikely(size > SLUB_MAX_SIZE))
> > > > - return kmalloc_large_node(size, flags, node);
> > > > ++ if (unlikely(size > SLUB_MAX_SIZE)) {
> > > > + if (unlikely(size > PAGE_SIZE)) {
> > >
> > > Except I screwed that up. I meant to delete the last line
> > > above. I will add a patch to the end of linux-next for today.
> >
> > Hm, i'd love to eliminate the conflict, but it would either mean
> > us to pull the slab tree into the tracing tree, or the other way
> > around - and both have quite many items queued up to make this
> > impractical.
>
> Is it a big problem, though? We could do the
> s/PAGE_SIZE/SLUB_MAX_SIZE/g rename as a separate preparational
> patch (without any of the functional changes) and see if Linus
> merges it to mainline...
Linus does not have to merge the changes - it's enough if both
you and me merge it, then there will be no conflicts if the two
trees are combined - Git will sort it all out.
Could you prepare such a patch please, merge it into a separate
(and append-only) branch your tree and then send me a pull
request after a bit of testing so i can merge it into the
tracing tree?
The only constraint is that this commit should never be rebased
after that point - but neither of us will do that.
Ingo
^ permalink raw reply
* Re: [s390] next Feb 18: defconfig build break
From: Martin Schwidefsky @ 2009-02-20 10:23 UTC (permalink / raw)
To: Rusty Russell
Cc: Mike Frysinger, Stephen Rothwell, Sachin P. Sant, linux-s390,
linux-next, LKML, heiko.carstens
In-Reply-To: <200902190913.27653.rusty@rustcorp.com.au>
Hi Rusty,
On Thu, 19 Feb 2009 09:13:26 +1030
Rusty Russell <rusty@rustcorp.com.au> wrote:
> Here's the s390 fix:
>
> Subject: s390: allow usage of string functions in linux/string.h
Thanks for the fix.
> Because when including asm/string.h from arch/s390/lib/string.c we
> don't declare the string ops we are about to define, and
> linux/string.h barfs.
>
> The fix is to declare them in this IN_ARCH_STRING_C case, but in
> general I wonder if there's a neater fix.
The out-of-line version of the string functions in
arch/s390/lib/string.c needs EXPORT_SYMBOL and other stuff. To fix the
problem without the seperate out-of-line prototypes would required to
avoid the inclusing of linux/string.h. Which would be fragile if
possible at all. So I think your patch is the best way to deal with the
problem.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Re: [PATCH] integrity: ima scatterlist bug fix
From: Alexander Beregalov @ 2009-02-20 10:51 UTC (permalink / raw)
To: Mimi Zohar; +Cc: linux-next, David Safford, LKML, Mimi Zohar
In-Reply-To: <1235096630-3099-1-git-send-email-zohar@linux.vnet.ibm.com>
2009/2/20 Mimi Zohar <zohar@linux.vnet.ibm.com>:
> Based on Alexander Beregalov's post http://lkml.org/lkml/2009/2/19/198
>
> - replaced sg_set_buf() with sg_init_one()
>
> kernel BUG at include/linux/scatterlist.h:65!
> invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> last sysfs file:
> CPU 2
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.29-rc5-next-20090219 #5 PowerEdge 1950
> RIP: 0010:[<ffffffff8045ec70>] [<ffffffff8045ec70>] ima_calc_hash+0xc0/0x160
> RSP: 0018:ffff88007f46bc40 EFLAGS: 00010286
> RAX: ffffe200032c45e8 RBX: 00000000fffffff4 RCX: 0000000087654321
> RDX: 0000000000000002 RSI: 0000000000000001 RDI: ffff88007cf71048
> RBP: ffff88007f46bcd0 R08: 0000000000000000 R09: 0000000000000163
> R10: ffff88007f4707a8 R11: 0000000000000000 R12: ffff88007cf71048
> R13: 0000000000001000 R14: 0000000000000000 R15: 0000000000009d98
> FS: 0000000000000000(0000) GS:ffff8800051ac000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>
> Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Tested-by: Alexander Beregalov <a.beregalov@gmail.com>
^ permalink raw reply
* next-20090220: XFS, IMA: BUG: sleeping function called from invalid context at mm/slub.c:1613
From: Alexander Beregalov @ 2009-02-20 11:00 UTC (permalink / raw)
To: LKML, linux-next@vger.kernel.org, xfs, Mimi Zohar
Hi
I have applied the following patch from Mimi Zohar
http://marc.info/?l=linux-next&m=123509665514552
That is why it is dirty.
The kernel can not boot without it when IMA is enabled.
BUG: sleeping function called from invalid context at mm/slub.c:1613
in_atomic(): 1, irqs_disabled(): 0, pid: 1514, name: mkdir
3 locks held by mkdir/1514:
#0: (&type->i_mutex_dir_key#2/1){+.+.+.}, at: [<ffffffff802d3460>]
lookup_create+0x30/0xd0
#1: (&(&ip->i_lock)->mr_lock/1){+.+.+.}, at: [<ffffffff803ca77f>]
xfs_ilock+0xdf/0x120
#2: (&pag->pag_ici_lock){++++.+}, at: [<ffffffff803caed6>]
xfs_iget+0x156/0x650
Pid: 1514, comm: mkdir Not tainted 2.6.29-rc5-next-20090220-dirty #1
Call Trace:
[<ffffffff8026ad33>] ? __debug_show_held_locks+0x13/0x30
[<ffffffff80234fe5>] __might_sleep+0x105/0x140
[<ffffffff802c6191>] kmem_cache_alloc+0xd1/0x100
[<ffffffff8045fb29>] ima_iint_insert+0x49/0xf0
[<ffffffff8045fbed>] ima_inode_alloc+0x1d/0x30
[<ffffffff802dfa5f>] inode_init_always+0xaf/0x250
[<ffffffff803caf86>] xfs_iget+0x206/0x650
[<ffffffff803eb8e8>] xfs_trans_iget+0x208/0x250
[<ffffffff803ce571>] xfs_ialloc+0xc1/0x700
[<ffffffff803ec6f9>] xfs_dir_ialloc+0xa9/0x340
[<ffffffff8025e009>] ? down_write_nested+0x79/0x90
[<ffffffff803ef0c1>] xfs_create+0x3e1/0x690
[<ffffffff803fb813>] xfs_vn_mknod+0x63/0xf0
[<ffffffff803fb8ae>] xfs_vn_mkdir+0xe/0x10
[<ffffffff802d487c>] vfs_mkdir+0x8c/0xd0
[<ffffffff802d6a56>] sys_mkdirat+0x106/0x120
[<ffffffff8020bc0c>] ? sysret_check+0x27/0x62
[<ffffffff8026c79d>] ? trace_hardirqs_on_caller+0x17d/0x1e0
[<ffffffff802d6a83>] sys_mkdir+0x13/0x20
[<ffffffff8020bbdb>] system_call_fastpath+0x16/0x1b
BUG: sleeping function called from invalid context at mm/slub.c:1613
in_atomic(): 1, irqs_disabled(): 0, pid: 1514, name: mkdir
3 locks held by mkdir/1514:
#0: (&type->i_mutex_dir_key#2/1){+.+.+.}, at: [<ffffffff802d3460>]
lookup_create+0x30/0xd0
#1: (&(&ip->i_lock)->mr_lock/1){+.+.+.}, at: [<ffffffff803ca77f>]
xfs_ilock+0xdf/0x120
#2: (&pag->pag_ici_lock){++++.+}, at: [<ffffffff803caed6>]
xfs_iget+0x156/0x650
Pid: 1514, comm: mkdir Not tainted 2.6.29-rc5-next-20090220-dirty #1
Call Trace:
[<ffffffff8026ad33>] ? __debug_show_held_locks+0x13/0x30
[<ffffffff80234fe5>] __might_sleep+0x105/0x140
[<ffffffff802c6191>] kmem_cache_alloc+0xd1/0x100
[<ffffffff8048131a>] radix_tree_preload+0x6a/0xf0
[<ffffffff8045fb3b>] ima_iint_insert+0x5b/0xf0
[<ffffffff8045fbed>] ima_inode_alloc+0x1d/0x30
[<ffffffff802dfa5f>] inode_init_always+0xaf/0x250
[<ffffffff803caf86>] xfs_iget+0x206/0x650
[<ffffffff803eb8e8>] xfs_trans_iget+0x208/0x250
[<ffffffff803ce571>] xfs_ialloc+0xc1/0x700
[<ffffffff803ec6f9>] xfs_dir_ialloc+0xa9/0x340
[<ffffffff8025e009>] ? down_write_nested+0x79/0x90
[<ffffffff803ef0c1>] xfs_create+0x3e1/0x690
[<ffffffff803fb813>] xfs_vn_mknod+0x63/0xf0
[<ffffffff803fb8ae>] xfs_vn_mkdir+0xe/0x10
[<ffffffff802d487c>] vfs_mkdir+0x8c/0xd0
[<ffffffff802d6a56>] sys_mkdirat+0x106/0x120
[<ffffffff8020bc0c>] ? sysret_check+0x27/0x62
[<ffffffff8026c79d>] ? trace_hardirqs_on_caller+0x17d/0x1e0
[<ffffffff802d6a83>] sys_mkdir+0x13/0x20
[<ffffffff8020bbdb>] system_call_fastpath+0x16/0x1b
^ permalink raw reply
* Re: linux-next: manual merge of the slab tree with the ftrace tree
From: Pekka Enberg @ 2009-02-20 11:12 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Christoph Lameter, linux-next,
Eduard - Gabriel Munteanu, Thomas Gleixner, H. Peter Anvin
In-Reply-To: <20090220095355.GL24555@elte.hu>
Hi Ingo,
On Fri, 2009-02-20 at 10:53 +0100, Ingo Molnar wrote:
> > Is it a big problem, though? We could do the
> > s/PAGE_SIZE/SLUB_MAX_SIZE/g rename as a separate preparational
> > patch (without any of the functional changes) and see if Linus
> > merges it to mainline...
>
> Linus does not have to merge the changes - it's enough if both
> you and me merge it, then there will be no conflicts if the two
> trees are combined - Git will sort it all out.
>
> Could you prepare such a patch please, merge it into a separate
> (and append-only) branch your tree and then send me a pull
> request after a bit of testing so i can merge it into the
> tracing tree?
Aye, aye, cap'n:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6.git for-ingo
the commit is here in case someone wants to take a look at it:
http://git.kernel.org/?p=linux/kernel/git/penberg/slab-2.6.git;a=commitdiff;h=fe1200b63d158b28eef6d4de1e5b5f99c681ba2f
Pekka
^ permalink raw reply
* Re: linux-next: manual merge of the slab tree with the ftrace tree
From: Ingo Molnar @ 2009-02-20 11:16 UTC (permalink / raw)
To: Pekka Enberg
Cc: Stephen Rothwell, Christoph Lameter, linux-next,
Eduard - Gabriel Munteanu, Thomas Gleixner, H. Peter Anvin
In-Reply-To: <1235128361.29813.32.camel@penberg-laptop>
* Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> Hi Ingo,
>
> On Fri, 2009-02-20 at 10:53 +0100, Ingo Molnar wrote:
> > > Is it a big problem, though? We could do the
> > > s/PAGE_SIZE/SLUB_MAX_SIZE/g rename as a separate preparational
> > > patch (without any of the functional changes) and see if Linus
> > > merges it to mainline...
> >
> > Linus does not have to merge the changes - it's enough if both
> > you and me merge it, then there will be no conflicts if the two
> > trees are combined - Git will sort it all out.
> >
> > Could you prepare such a patch please, merge it into a separate
> > (and append-only) branch your tree and then send me a pull
> > request after a bit of testing so i can merge it into the
> > tracing tree?
>
> Aye, aye, cap'n:
>
> git pull git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6.git for-ingo
>
> the commit is here in case someone wants to take a look at it:
>
> http://git.kernel.org/?p=linux/kernel/git/penberg/slab-2.6.git;a=commitdiff;h=fe1200b63d158b28eef6d4de1e5b5f99c681ba2f
Pulled into tip:tracing/kmemtrace, thanks Pekka!
Below is the conflict resolution i did. Will push out a new
tip:auto-ftrace-next tree once it got a bit of testing.
Ingo
------------------->
commit 057685cf57066bc8aaed68de1b1970e12f0075d2
Merge: 64b36ca... fe1200b...
Author: Ingo Molnar <mingo@elte.hu>
Date: Fri Feb 20 12:15:30 2009 +0100
Merge branch 'for-ingo' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6 into tracing/kmemtrace
Conflicts:
mm/slub.c
diff --cc include/linux/slub_def.h
index 6b657f7,986e09d..9e3a575
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@@ -228,10 -224,8 +241,10 @@@ static __always_inline void *kmalloc_la
static __always_inline void *kmalloc(size_t size, gfp_t flags)
{
+ void *ret;
+
if (__builtin_constant_p(size)) {
- if (size > PAGE_SIZE)
+ if (size > SLUB_MAX_SIZE)
return kmalloc_large(size, flags);
if (!(flags & SLUB_DMA)) {
@@@ -256,26 -244,10 +269,26 @@@
void *__kmalloc_node(size_t size, gfp_t flags, int node);
void *kmem_cache_alloc_node(struct kmem_cache *, gfp_t flags, int node);
+#ifdef CONFIG_KMEMTRACE
+extern void *kmem_cache_alloc_node_notrace(struct kmem_cache *s,
+ gfp_t gfpflags,
+ int node);
+#else
+static __always_inline void *
+kmem_cache_alloc_node_notrace(struct kmem_cache *s,
+ gfp_t gfpflags,
+ int node)
+{
+ return kmem_cache_alloc_node(s, gfpflags, node);
+}
+#endif
+
static __always_inline void *kmalloc_node(size_t size, gfp_t flags, int node)
{
+ void *ret;
+
if (__builtin_constant_p(size) &&
- size <= PAGE_SIZE && !(flags & SLUB_DMA)) {
+ size <= SLUB_MAX_SIZE && !(flags & SLUB_DMA)) {
struct kmem_cache *s = kmalloc_slab(size);
if (!s)
diff --cc mm/slub.c
index 3525e7b,5a5e7f5..6de5e07
--- a/mm/slub.c
+++ b/mm/slub.c
@@@ -2688,9 -2657,8 +2688,9 @@@ static struct kmem_cache *get_slab(size
void *__kmalloc(size_t size, gfp_t flags)
{
struct kmem_cache *s;
+ void *ret;
- if (unlikely(size > PAGE_SIZE))
+ if (unlikely(size > SLUB_MAX_SIZE))
return kmalloc_large(size, flags);
s = get_slab(size, flags);
@@@ -2722,18 -2685,9 +2722,18 @@@ static void *kmalloc_large_node(size_t
void *__kmalloc_node(size_t size, gfp_t flags, int node)
{
struct kmem_cache *s;
+ void *ret;
- if (unlikely(size > PAGE_SIZE)) {
- if (unlikely(size > SLUB_MAX_SIZE))
- return kmalloc_large_node(size, flags, node);
++ if (unlikely(size > SLUB_MAX_SIZE)) {
+ ret = kmalloc_large_node(size, flags, node);
+
+ kmemtrace_mark_alloc_node(KMEMTRACE_TYPE_KMALLOC,
+ _RET_IP_, ret,
+ size, PAGE_SIZE << get_order(size),
+ flags, node);
+
+ return ret;
+ }
s = get_slab(size, flags);
@@@ -3275,9 -3221,8 +3275,9 @@@ static struct notifier_block __cpuinitd
void *__kmalloc_track_caller(size_t size, gfp_t gfpflags, unsigned long caller)
{
struct kmem_cache *s;
+ void *ret;
- if (unlikely(size > PAGE_SIZE))
+ if (unlikely(size > SLUB_MAX_SIZE))
return kmalloc_large(size, gfpflags);
s = get_slab(size, gfpflags);
@@@ -3298,9 -3237,8 +3298,9 @@@ void *__kmalloc_node_track_caller(size_
int node, unsigned long caller)
{
struct kmem_cache *s;
+ void *ret;
- if (unlikely(size > PAGE_SIZE))
+ if (unlikely(size > SLUB_MAX_SIZE))
return kmalloc_large_node(size, gfpflags, node);
s = get_slab(size, gfpflags);
^ permalink raw reply
* Re: linux-next: hid tree build warning
From: Jiri Kosina @ 2009-02-20 11:55 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Oliver Neukum
In-Reply-To: <20090220190846.46ec3d76.sfr@canb.auug.org.au>
On Fri, 20 Feb 2009, Stephen Rothwell wrote:
> Today's linux-next build (powerpc ppc64_defconfig) produced this warning:
>
> drivers/hid/usbhid/hid-core.c:1337: warning: 'hid_reset_resume' defined but not used
>
> Introduced by commit 8aa650161ced641fec0bc9c38e3dea6a1f315442 ("HID: fix
> USB HID devices after STD with autosuspend") from the hid tree.
>
> hid_reset_resume() is only used if CONFIG_PM is set.
Thanks a lot for catching this, I have fixed it (moved hid_reset_resume()
into the ifdef CONFIG_PM part of the source) and pushed the fix to the
branch you pull into -next.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] integrity: ima scatterlist bug fix
From: James Morris @ 2009-02-20 13:31 UTC (permalink / raw)
To: Alexander Beregalov
Cc: Mimi Zohar, linux-next, David Safford, LKML, Mimi Zohar
In-Reply-To: <a4423d670902200251l6087d8afu88409bf4e2e6cb4e@mail.gmail.com>
On Fri, 20 Feb 2009, Alexander Beregalov wrote:
> > Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
> Tested-by: Alexander Beregalov <a.beregalov@gmail.com>
Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* [PATCH] oqo: depends on INPUT_POLLDEV
From: Randy Dunlap @ 2009-02-20 16:30 UTC (permalink / raw)
To: lkml, linux-next; +Cc: lenb, Matthew Garrett
This patch (from 2009-feb-10) is still needed in today's linux-next.
Begin forwarded message:
Date: Tue, 10 Feb 2009 09:53:19 -0800
From: Randy Dunlap <randy.dunlap@oracle.com>
To: lkml <linux-kernel@vger.kernel.org>, akpm <akpm@linux-foundation.org>
Cc: linux-next@vger.kernel.org, Matthew Garrett <mjg59@srcf.ucam.org>
Subject: [PATCH] oqo: depends on INPUT_POLLDEV
From: Randy Dunlap <randy.dunlap@oracle.com>
oqo driver uses polled input functions, so make it depend
on INPUT_POLLDEV.
ERROR: "input_register_polled_device" [drivers/platform/x86/oqo-wmi.ko] undefined!
ERROR: "input_allocate_polled_device" [drivers/platform/x86/oqo-wmi.ko] undefined!
ERROR: "input_free_polled_device" [drivers/platform/x86/oqo-wmi.ko] undefined!
ERROR: "input_unregister_polled_device" [drivers/platform/x86/oqo-wmi.ko] undefined!
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
cc: Matthew Garrett <mjg59@srcf.ucam.org>
---
drivers/platform/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20090210.orig/drivers/platform/x86/Kconfig
+++ linux-next-20090210/drivers/platform/x86/Kconfig
@@ -137,7 +137,7 @@ config MSI_LAPTOP
config OQO_WMI
tristate "OQO WMI extras"
depends on ACPI_WMI
- depends on INPUT
+ depends on INPUT && INPUT_POLLDEV
depends on RFKILL
depends on BACKLIGHT_CLASS_DEVICE
help
^ permalink raw reply
* Re: linux-next: Tree for February 20
From: Bartlomiej Zolnierkiewicz @ 2009-02-20 16:32 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML
In-Reply-To: <20090220201224.3f32ae24.sfr@canb.auug.org.au>
On Friday 20 February 2009, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20090219:
I've just noticed stall patch version in ide tree so if you're
using ide this patch is also necessary (fixes hang on boot):
--- linux-next/drivers/ide/ide-iops.c 2009-02-20 18:00:28.000000000 +0100
+++ linux-2.6.git/drivers/ide/ide-iops.c 2009-02-19 18:31:04.000000000 +0100
@@ -468,9 +468,9 @@
unsigned long flags;
spin_lock_irqsave(&hwif->lock, flags);
- if ((drive->atapi_flags & IDE_AFLAG_DRQ_INTERRUPT) &&
- (cmd->protocol == ATAPI_PROT_DMA ||
- cmd->protocol == ATAPI_PROT_PIO))
+ if ((cmd->protocol != ATAPI_PROT_DMA &&
+ cmd->protocol != ATAPI_PROT_PIO) ||
+ (drive->atapi_flags & IDE_AFLAG_DRQ_INTERRUPT))
__ide_set_handler(drive, handler, timeout);
hwif->tp_ops->exec_command(hwif, cmd->tf.command);
/*
^ permalink raw reply
* Re: [PATCH] oqo: depends on INPUT_POLLDEV
From: Matthew Garrett @ 2009-02-20 16:36 UTC (permalink / raw)
To: Randy Dunlap; +Cc: lkml, linux-next, lenb
In-Reply-To: <20090220083007.7bd0a153.randy.dunlap@oracle.com>
On Fri, Feb 20, 2009 at 08:30:07AM -0800, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> oqo driver uses polled input functions, so make it depend
> on INPUT_POLLDEV.
>
> ERROR: "input_register_polled_device" [drivers/platform/x86/oqo-wmi.ko] undefined!
> ERROR: "input_allocate_polled_device" [drivers/platform/x86/oqo-wmi.ko] undefined!
> ERROR: "input_free_polled_device" [drivers/platform/x86/oqo-wmi.ko] undefined!
> ERROR: "input_unregister_polled_device" [drivers/platform/x86/oqo-wmi.ko] undefined!
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> cc: Matthew Garrett <mjg59@srcf.ucam.org>
Acked-by: Matthew Garrett <mjg@redhat.com>
I've got a cleaned up version of this written now - I'll push it to Len
later today.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* [PATCH] mimio: depends on INPUT
From: Randy Dunlap @ 2009-02-20 16:48 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, Greg KH, mwilder
In-Reply-To: <20090220201224.3f32ae24.sfr@canb.auug.org.au>
From: Randy Dunlap <randy.dunlap@oracle.com>
mimio driver uses input_* functions so it needs to depend on INPUT.
mimio.c:(.text+0x2526c9): undefined reference to `input_unregister_device'
mimio.c:(.text+0x2526da): undefined reference to `input_close_device'
mimio.c:(.text+0x252725): undefined reference to `input_free_device'
mimio.c:(.text+0x2528f1): undefined reference to `input_event'
mimio.c:(.text+0x252904): undefined reference to `input_event'
mimio.c:(.text+0x252921): undefined reference to `input_event'
mimio.c:(.text+0x252b3e): undefined reference to `input_event'
mimio.c:(.text+0x252b51): undefined reference to `input_event'
drivers/built-in.o:mimio.c:(.text+0x252bbd): more undefined references to `input_event' follow
mimio.c:(.text+0x252e42): undefined reference to `input_allocate_device'
mimio.c:(.text+0x2530ef): undefined reference to `input_register_device'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
cc: mwilder@cs.nmsu.edu
---
drivers/staging/mimio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20090220.orig/drivers/staging/mimio/Kconfig
+++ linux-next-20090220/drivers/staging/mimio/Kconfig
@@ -1,6 +1,6 @@
config INPUT_MIMIO
tristate "Mimio Xi interactive whiteboard support"
- depends on USB
+ depends on USB && INPUT
default N
help
Say Y here if you want to use a Mimio Xi interactive
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox