* Re: linux-next: acpi tree build failure
From: Greg KH @ 2009-02-07 5:32 UTC (permalink / raw)
To: Len Brown; +Cc: Stephen Rothwell, linux-next, Matthew Garrett, Kay Sievers
In-Reply-To: <alpine.LFD.2.00.0902062303090.26256@localhost.localdomain>
On Fri, Feb 06, 2009 at 11:06:28PM -0500, Len Brown wrote:
>
> On Wed, 4 Feb 2009, Greg KH wrote:
>
> > On Thu, Feb 05, 2009 at 01:13:40PM +1100, Stephen Rothwell wrote:
> > > Greg, Len,
> > >
> > > On Mon, 2 Feb 2009 13:22:54 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > >
> > > > drivers/platform/x86/oqo-wmi.c: In function 'oqo_kine_init':
> > > > drivers/platform/x86/oqo-wmi.c:595: error: 'struct device' has no member named 'bus_id'
> > > >
> > > > Caused by commit 03919980ad590ad5c5c181d1bd7d58513ad170bc ("platform/x86:
> > > > Add oqo-wmi driver for model 2 OQO backlight and rfkill control")
> > > > interacting with commit c44c8304353aa6da82cbf98040c6a9c254e68e1c ("driver
> > > > core: get rid of struct device's bus_id string array") from the
> > > > driver-core tree.
> > >
> > > Still getting this (of course). Can you guys come up with a fix, please?
> >
> > Len, you have the patch from Kay, what do you want to do with it?
>
> I don't recall a patch from Kay specifically for OQO.
> OQO is sitting in my tree to get exposure while it waits for
> a few updates from Matthew.
Ah, sorry, I was confused with the other acpi bus_id patch.
> I think it can be restored with this 1 liner, which I can apply to it.
Yes, your patch looks fine.
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: acpi tree build failure
From: Len Brown @ 2009-02-07 4:06 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Rothwell, linux-next, Matthew Garrett, Kay Sievers
In-Reply-To: <20090205050056.GA7651@kroah.com>
On Wed, 4 Feb 2009, Greg KH wrote:
> On Thu, Feb 05, 2009 at 01:13:40PM +1100, Stephen Rothwell wrote:
> > Greg, Len,
> >
> > On Mon, 2 Feb 2009 13:22:54 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > drivers/platform/x86/oqo-wmi.c: In function 'oqo_kine_init':
> > > drivers/platform/x86/oqo-wmi.c:595: error: 'struct device' has no member named 'bus_id'
> > >
> > > Caused by commit 03919980ad590ad5c5c181d1bd7d58513ad170bc ("platform/x86:
> > > Add oqo-wmi driver for model 2 OQO backlight and rfkill control")
> > > interacting with commit c44c8304353aa6da82cbf98040c6a9c254e68e1c ("driver
> > > core: get rid of struct device's bus_id string array") from the
> > > driver-core tree.
> >
> > Still getting this (of course). Can you guys come up with a fix, please?
>
> Len, you have the patch from Kay, what do you want to do with it?
I don't recall a patch from Kay specifically for OQO.
OQO is sitting in my tree to get exposure while it waits for
a few updates from Matthew.
I think it can be restored with this 1 liner, which I can apply to it.
thanks,
Len Brown, Intel Open Source Technology Center
diff --git a/drivers/platform/x86/oqo-wmi.c b/drivers/platform/x86/oqo-wmi.c
index 940e605..0a88af8 100644
--- a/drivers/platform/x86/oqo-wmi.c
+++ b/drivers/platform/x86/oqo-wmi.c
@@ -592,7 +592,7 @@ static int __devinit oqo_kine_init(void)
oqo_kine->absmax[ABS_Y] =
oqo_kine->absmax[ABS_Z] = oqo_kine->absmax[ABS_MISC] = 32767;
- memcpy(oqo_kine->dev.bus_id, "kine", 4);
+ dev_set_name(&oqo_kine->dev, "kine");
oqo_kine_polled = input_allocate_polled_device();
if (!oqo_kine_polled) {
^ permalink raw reply related
* Re: linux-next: manual merge of the pci tree with the pci-current tree
From: Stephen Rothwell @ 2009-02-07 0:07 UTC (permalink / raw)
To: Jesse Barnes; +Cc: linux-next, Rafael J. Wysocki
In-Reply-To: <200902060909.32549.jbarnes@virtuousgeek.org>
[-- Attachment #1: Type: text/plain, Size: 522 bytes --]
Hi Jesse,
On Fri, 6 Feb 2009 09:09:31 -0800 Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>
> Oops yeah, thanks for bringing this up. I didn't rebase my linux-next branch
> on top of my for-linus branch with the last set of changes... Will do.
You shouldn't need to rebase just for this. Just wait for Linus to merge
the pci-current tree and then merge either it or Linus' tree into the
pci-tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the pci tree with the pci-current tree
From: Rafael J. Wysocki @ 2009-02-06 23:49 UTC (permalink / raw)
To: Jesse Barnes; +Cc: Stephen Rothwell, linux-next
In-Reply-To: <200902060909.32549.jbarnes@virtuousgeek.org>
On Friday 06 February 2009, Jesse Barnes wrote:
> On Thursday, February 5, 2009 6:50 pm Stephen Rothwell wrote:
> > Hi Jesse,
> >
> > Today's linux-next merge of the pci tree got a conflict in
> > drivers/pci/pcie/portdrv_pci.c between commit
> > 27be54a65c89c4b4aa9b25fc6fba31ffd01a08ca ("PCI: PCIe portdrv: Simplify
> > suspend and resume") from the pci-current tree and commit
> > 120d3f44dd4c7a16ac71f26d4ff44ad7498cb81a ("PCI: PCIe portdrv: Implement
> > pm object") from the pci tree.
> >
> > I fixed it up (I used the pci tree version) and assume it will be fixed in
> > the pci tree soon.
>
> Oops yeah, thanks for bringing this up. I didn't rebase my linux-next branch
> on top of my for-linus branch with the last set of changes... Will do.
Please let me know if there are problems with rebasing any of my patches.
Best,
Rafael
^ permalink raw reply
* Re: next-20090206: deadlock on ext4
From: Eric Sandeen @ 2009-02-06 20:07 UTC (permalink / raw)
To: Alexander Beregalov; +Cc: linux-next@vger.kernel.org, linux-ext4, LKML
In-Reply-To: <a4423d670902061004i424817e1vd699a61e335f010a@mail.gmail.com>
Alexander Beregalov wrote:
> 2009/2/6 Eric Sandeen <sandeen@redhat.com>:
>> Alexander Beregalov wrote:
>>> Hi
>>>
>>> I run dbench on ext4 on loop device.
>>>
>>> EXT4-fs: barriers enabled
>>> kjournald2 starting: pid 2420, dev loop0:8, commit interval 5 seconds
>>> EXT4 FS on loop0, internal journal on loop0:8
>>> EXT4-fs: delayed allocation enabled
>>> EXT4-fs: file extents enabled
>>> EXT4-fs: mballoc enabled
>>> EXT4-fs: mounted filesystem loop0 with ordered data mode
>>> JBD: barrier-based sync failed on loop0:8 - disabling barriers
>>>
>>> INFO: task pdflush:2339 blocked for more than 120 seconds.
>> Looks a lot like a bug I filed:
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=12579
>>
>> but I'm having trouble reproducing it, now. I'll try dbench!
> Yes, I can reproduce it easy with dbench.
Do you only hit it on loopback? What is the filesystem hosting the loop
file?
Thanks,
-Eric
^ permalink raw reply
* RE: [PATCH] revert headers_check fix: ia64, fpu.h
From: Luck, Tony @ 2009-02-06 18:53 UTC (permalink / raw)
To: Jaswinder Singh Rajput, KOSAKI Motohiro
Cc: Jaswinder Singh Rajput, Ingo Molnar, Linus Torvalds, Sam Ravnborg,
Andrew Morton, Russell King - ARM Linux, hskinnemoen@atmel.com,
cooloney@kernel.org, ralf@linux-mips.org, dhowells@redhat.com,
matthew@wil.cx, chris@zankel.net, LKML, linux-next, linux-ia64
In-Reply-To: <3f9a31f40902060053x18dacf58u40c739ab89f13860@mail.gmail.com>
> > -#include <linux/types.h>
> > +#include <asm/types.h>
> >
>
> No , we do not even need asm/types.h
...
> -#include <linux/types.h>
> -
This works.
Acked-by: Tony Luck <tony.luck@intel.com>
^ permalink raw reply
* Re: next-20090206: deadlock on ext4
From: Alexander Beregalov @ 2009-02-06 18:04 UTC (permalink / raw)
To: Eric Sandeen; +Cc: linux-next@vger.kernel.org, linux-ext4, LKML
In-Reply-To: <498C7671.1050309@redhat.com>
2009/2/6 Eric Sandeen <sandeen@redhat.com>:
> Alexander Beregalov wrote:
>> Hi
>>
>> I run dbench on ext4 on loop device.
>>
>> EXT4-fs: barriers enabled
>> kjournald2 starting: pid 2420, dev loop0:8, commit interval 5 seconds
>> EXT4 FS on loop0, internal journal on loop0:8
>> EXT4-fs: delayed allocation enabled
>> EXT4-fs: file extents enabled
>> EXT4-fs: mballoc enabled
>> EXT4-fs: mounted filesystem loop0 with ordered data mode
>> JBD: barrier-based sync failed on loop0:8 - disabling barriers
>>
>> INFO: task pdflush:2339 blocked for more than 120 seconds.
>
> Looks a lot like a bug I filed:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=12579
>
> but I'm having trouble reproducing it, now. I'll try dbench!
Yes, I can reproduce it easy with dbench.
^ permalink raw reply
* Re: next-20090206: deadlock on ext4
From: Eric Sandeen @ 2009-02-06 17:42 UTC (permalink / raw)
To: Alexander Beregalov; +Cc: linux-next@vger.kernel.org, linux-ext4, LKML
In-Reply-To: <a4423d670902060935y59e540beta417144935416560@mail.gmail.com>
Alexander Beregalov wrote:
> Hi
>
> I run dbench on ext4 on loop device.
>
> EXT4-fs: barriers enabled
> kjournald2 starting: pid 2420, dev loop0:8, commit interval 5 seconds
> EXT4 FS on loop0, internal journal on loop0:8
> EXT4-fs: delayed allocation enabled
> EXT4-fs: file extents enabled
> EXT4-fs: mballoc enabled
> EXT4-fs: mounted filesystem loop0 with ordered data mode
> JBD: barrier-based sync failed on loop0:8 - disabling barriers
>
> INFO: task pdflush:2339 blocked for more than 120 seconds.
Looks a lot like a bug I filed:
http://bugzilla.kernel.org/show_bug.cgi?id=12579
but I'm having trouble reproducing it, now. I'll try dbench!
-Eric
^ permalink raw reply
* Re: [linux-next][PATCH] revert headers_check fix: ia64, fpu.h
From: Ingo Molnar @ 2009-02-06 17:41 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Russell King - ARM Linux, Jaswinder Singh Rajput, KOSAKI Motohiro,
Jaswinder Singh Rajput, Linus Torvalds, Andrew Morton,
hskinnemoen, cooloney, tony.luck, ralf, dhowells, matthew, chris,
LKML, linux-next, linux-ia64
In-Reply-To: <20090206173249.GC11299@uranus.ravnborg.org>
* Sam Ravnborg <sam@ravnborg.org> wrote:
> On Fri, Feb 06, 2009 at 03:55:12PM +0000, Russell King - ARM Linux wrote:
> > On Fri, Feb 06, 2009 at 09:18:48PM +0530, Jaswinder Singh Rajput wrote:
> > > On Fri, 2009-02-06 at 15:33 +0000, Russell King - ARM Linux wrote:
> > > > On Fri, Feb 06, 2009 at 08:59:01PM +0530, Jaswinder Singh Rajput wrote:
> > > > > Jaswinder Singh Rajput (2):
> > > > > Neither asm/types.h nor linux/types.h is required for arch/ia64/include/asm/fpu.h
> > > > > make linux/types.h as assembly safe
> > > >
> > > > I continue to disagree with the need for the second patch.
> > >
> > > Like Ingo suggested:
> > >
> > > On Fri, 2009-02-06 at 15:58 +0100, Ingo Molnar wrote:
> > > > Well types.h easily gets included in other files though, which might be
> > > > partially suited for assembly - and have !__ASSEMBLY__ portions that rely on
> > > > a types.h include.
> > > >
> > > > So making this file an invariant in .S files does not sound like a bad idea
> > > > to me. Is there any downside?
> > > >
> > >
> > > We cannot see any downside of this patch.
> > >
> > > But we can see upside of this patch is:
> > > 1. No need to protect linux/types.h with #ifndef __ASSEMBLY__ in many
> > > files
> > > 2. So we trying to replace multiple #ifndef __ASSEMBLY__ with one.
> >
> > The point is:
> >
> > 1. If the parent include needs to include linux/types.h to get at C
> > types _and_ the include file needs to also be included by assembly
> > code, it itself needs to have #ifndef __ASSEMBLY__ to protect those
> > uses from the assembly code.
> >
> > In that case, the linux/types.h include should be contained within
> > the #ifndef __ASSEMBLY__ .. #endif block along with all C only
> > parts of the header file.
> >
> > 2. if it doesn't need C types from linux/types.h, then that header has
> > no business including linux/types.h, and the include should be
> > eliminated to save the already dirbolically slow compiler from
> > having to read and parse that file, and more importantly allowing
> > it to eliminate linux/types.h from the build dependencies.
> >
> > Yes, you can wrap linux/types.h with that ifndef, and yes it will fix
> > any problems, but I view it as a hack rather than fixing the real problem
> > which is lazyness by code writers to get their include dependencies right.
>
> You guys are getting this wrong.
> The patch from Jaswinder needs to be fixed so we unconditionally
> include <asm/types.h> from linux/types.h.
Yeah, that's true.
> And then ll users can safely include linux/types.h and when we one
> day realize we can move some stuff used in .S files from
> asm/types.h to linux/types.h then we are all safe and no breakage.
Yeah.
Ingo
^ permalink raw reply
* next-20090206: deadlock on ext4
From: Alexander Beregalov @ 2009-02-06 17:35 UTC (permalink / raw)
To: linux-next@vger.kernel.org, linux-ext4, LKML
Hi
I run dbench on ext4 on loop device.
EXT4-fs: barriers enabled
kjournald2 starting: pid 2420, dev loop0:8, commit interval 5 seconds
EXT4 FS on loop0, internal journal on loop0:8
EXT4-fs: delayed allocation enabled
EXT4-fs: file extents enabled
EXT4-fs: mballoc enabled
EXT4-fs: mounted filesystem loop0 with ordered data mode
JBD: barrier-based sync failed on loop0:8 - disabling barriers
INFO: task pdflush:2339 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
pdflush D 0000000000000002 3112 2339 2
ffff88007d861990 0000000000000046 ffff88007d861940 ffffffff802971c6
ffff88007d8618f8 0000000000004000 0000000000000000 ffff8800790bce40
ffff880035c7ce40 ffff8800790bd1d8 00000000790bce40 0000000000000282
Call Trace:
[<ffffffff802971c6>] ? mempool_alloc+0x56/0x150
[<ffffffff8062dbd5>] ? _spin_unlock_irqrestore+0x65/0x80
[<ffffffff8062ac47>] ? io_schedule+0x37/0x50
[<ffffffff8062abe3>] schedule+0x13/0x40
[<ffffffff8062ac47>] io_schedule+0x37/0x50
[<ffffffff8029442d>] sync_page+0x6d/0x80
[<ffffffff8062af52>] __wait_on_bit_lock+0x52/0xb0
[<ffffffff802943c0>] ? sync_page+0x0/0x80
[<ffffffff802943a4>] __lock_page+0x64/0x70
[<ffffffff80259460>] ? wake_bit_function+0x0/0x40
[<ffffffff8029e252>] ? pagevec_lookup_tag+0x22/0x30
[<ffffffff8029c687>] write_cache_pages+0x247/0x4a0
[<ffffffff8032b540>] ? __mpage_da_writepage+0x0/0x1b0
[<ffffffff8034cafe>] ? jbd2_journal_start+0xce/0x140
[<ffffffff8032b1e3>] ext4_da_writepages+0x263/0x4e0
[<ffffffff80269f65>] ? print_lock_contention_bug+0x25/0x120
[<ffffffff80269f65>] ? print_lock_contention_bug+0x25/0x120
[<ffffffff80269f65>] ? print_lock_contention_bug+0x25/0x120
[<ffffffff80269f65>] ? print_lock_contention_bug+0x25/0x120
[<ffffffff8032d090>] ? ext4_da_get_block_write+0x0/0x190
[<ffffffff8029c93b>] do_writepages+0x2b/0x50
[<ffffffff802e56a1>] __writeback_single_inode+0xa1/0x3f0
[<ffffffff802e5ee2>] ? generic_sync_sb_inodes+0x3a2/0x420
[<ffffffff802e5e88>] generic_sync_sb_inodes+0x348/0x420
[<ffffffff802e6145>] writeback_inodes+0x65/0x100
[<ffffffff8029d050>] background_writeout+0xb0/0xe0
[<ffffffff8029d840>] pdflush+0x110/0x1f0
[<ffffffff8029cfa0>] ? background_writeout+0x0/0xe0
[<ffffffff8029d730>] ? pdflush+0x0/0x1f0
[<ffffffff8029d730>] ? pdflush+0x0/0x1f0
[<ffffffff80258f76>] kthread+0x56/0x90
[<ffffffff8020ce5a>] child_rip+0xa/0x20
[<ffffffff80235759>] ? finish_task_switch+0x89/0x110
[<ffffffff8062db46>] ? _spin_unlock_irq+0x36/0x60
[<ffffffff8020c840>] ? restore_args+0x0/0x30
[<ffffffff80258f20>] ? kthread+0x0/0x90
[<ffffffff8020ce50>] ? child_rip+0x0/0x20
INFO: lockdep is turned off.
INFO: task kjournald2:2420 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kjournald2 D ffff88007b8d2090 4776 2420 2
ffff88003d117d40 0000000000000046 0000000000000000 ffff88007b8d2358
ffff8800790ba720 0000000000004000 0000000000000002 ffff8800790ba720
ffff88007c820000 ffff8800790baab8 000000028062dbd5 0000000000000286
Call Trace:
[<ffffffff8026bf69>] ? trace_hardirqs_on_caller+0x29/0x1e0
[<ffffffff8034e794>] ? jbd2_journal_commit_transaction+0x1d4/0x19b0
[<ffffffff8034e799>] ? jbd2_journal_commit_transaction+0x1d9/0x19b0
[<ffffffff8062abe3>] schedule+0x13/0x40
[<ffffffff8034e799>] jbd2_journal_commit_transaction+0x1d9/0x19b0
[<ffffffff8062dba8>] ? _spin_unlock_irqrestore+0x38/0x80
[<ffffffff80268709>] ? trace_hardirqs_off_caller+0x29/0xe0
[<ffffffff802358a0>] ? sub_preempt_count+0xc0/0x130
[<ffffffff80259420>] ? autoremove_wake_function+0x0/0x40
[<ffffffff8024cefc>] ? try_to_del_timer_sync+0x7c/0x90
[<ffffffff80354577>] kjournald2+0x117/0x380
[<ffffffff80259420>] ? autoremove_wake_function+0x0/0x40
[<ffffffff80354460>] ? kjournald2+0x0/0x380
[<ffffffff80258f76>] kthread+0x56/0x90
[<ffffffff8020ce5a>] child_rip+0xa/0x20
[<ffffffff80235759>] ? finish_task_switch+0x89/0x110
[<ffffffff8062db46>] ? _spin_unlock_irq+0x36/0x60
[<ffffffff8020c840>] ? restore_args+0x0/0x30
[<ffffffff80258f20>] ? kthread+0x0/0x90
[<ffffffff8020ce50>] ? child_rip+0x0/0x20
INFO: lockdep is turned off.
INFO: task dbench:2685 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
dbench D 0000000000000001 3296 2685 1
ffff8800793f9a18 0000000000000046 0000000000000000 ffff88007b8d21c8
ffff880035c78000 0000000000004000 0000000000000003 ffff880035c78000
ffff88007d2ace40 ffff880035c78398 000000038062dbd5 0000000000000286
Call Trace:
[<ffffffff8026bf69>] ? trace_hardirqs_on_caller+0x29/0x1e0
[<ffffffff8034c6a7>] ? start_this_handle+0x3b7/0x5e0
[<ffffffff8034c6ac>] ? start_this_handle+0x3bc/0x5e0
[<ffffffff8062abe3>] schedule+0x13/0x40
[<ffffffff8034c6ac>] start_this_handle+0x3bc/0x5e0
[<ffffffff80259420>] ? autoremove_wake_function+0x0/0x40
[<ffffffff8034caf7>] jbd2_journal_start+0xc7/0x140
[<ffffffff8029d5e5>] ? balance_dirty_pages_ratelimited_nr+0x365/0x3f0
[<ffffffff80336575>] ext4_journal_start_sb+0x55/0x90
[<ffffffff80329ef3>] ext4_da_write_begin+0xf3/0x260
[<ffffffff802965d7>] generic_file_buffered_write+0x137/0x340
[<ffffffff80296c19>] __generic_file_aio_write_nolock+0x269/0x470
[<ffffffff80296f29>] generic_file_aio_write+0x69/0xd0
[<ffffffff80325838>] ext4_file_write+0x58/0x170
[<ffffffff802c66a1>] do_sync_write+0xf1/0x140
[<ffffffff80259420>] ? autoremove_wake_function+0x0/0x40
[<ffffffff8026bf69>] ? trace_hardirqs_on_caller+0x29/0x1e0
[<ffffffff80250a72>] ? sys_kill+0xa2/0x1c0
[<ffffffff802c6d0b>] vfs_write+0xcb/0x170
[<ffffffff802c6e42>] sys_pwrite64+0x92/0xa0
[<ffffffff8020bddb>] system_call_fastpath+0x16/0x1b
^ permalink raw reply
* Re: [linux-next][PATCH] revert headers_check fix: ia64, fpu.h
From: Sam Ravnborg @ 2009-02-06 17:32 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jaswinder Singh Rajput, Ingo Molnar, KOSAKI Motohiro,
Jaswinder Singh Rajput, Linus Torvalds, Andrew Morton,
hskinnemoen, cooloney, tony.luck, ralf, dhowells, matthew, chris,
LKML, linux-next, linux-ia64
In-Reply-To: <20090206155512.GF13758@n2100.arm.linux.org.uk>
On Fri, Feb 06, 2009 at 03:55:12PM +0000, Russell King - ARM Linux wrote:
> On Fri, Feb 06, 2009 at 09:18:48PM +0530, Jaswinder Singh Rajput wrote:
> > On Fri, 2009-02-06 at 15:33 +0000, Russell King - ARM Linux wrote:
> > > On Fri, Feb 06, 2009 at 08:59:01PM +0530, Jaswinder Singh Rajput wrote:
> > > > Jaswinder Singh Rajput (2):
> > > > Neither asm/types.h nor linux/types.h is required for arch/ia64/include/asm/fpu.h
> > > > make linux/types.h as assembly safe
> > >
> > > I continue to disagree with the need for the second patch.
> >
> > Like Ingo suggested:
> >
> > On Fri, 2009-02-06 at 15:58 +0100, Ingo Molnar wrote:
> > > Well types.h easily gets included in other files though, which might be
> > > partially suited for assembly - and have !__ASSEMBLY__ portions that rely on
> > > a types.h include.
> > >
> > > So making this file an invariant in .S files does not sound like a bad idea
> > > to me. Is there any downside?
> > >
> >
> > We cannot see any downside of this patch.
> >
> > But we can see upside of this patch is:
> > 1. No need to protect linux/types.h with #ifndef __ASSEMBLY__ in many
> > files
> > 2. So we trying to replace multiple #ifndef __ASSEMBLY__ with one.
>
> The point is:
>
> 1. If the parent include needs to include linux/types.h to get at C
> types _and_ the include file needs to also be included by assembly
> code, it itself needs to have #ifndef __ASSEMBLY__ to protect those
> uses from the assembly code.
>
> In that case, the linux/types.h include should be contained within
> the #ifndef __ASSEMBLY__ .. #endif block along with all C only
> parts of the header file.
>
> 2. if it doesn't need C types from linux/types.h, then that header has
> no business including linux/types.h, and the include should be
> eliminated to save the already dirbolically slow compiler from
> having to read and parse that file, and more importantly allowing
> it to eliminate linux/types.h from the build dependencies.
>
> Yes, you can wrap linux/types.h with that ifndef, and yes it will fix
> any problems, but I view it as a hack rather than fixing the real problem
> which is lazyness by code writers to get their include dependencies right.
You guys are getting this wrong.
The patch from Jaswinder needs to be fixed so we unconditionally
include <asm/types.h> from linux/types.h.
And then ll users can safely include linux/types.h and when we one
day realize we can move some stuff used in .S files from
asm/types.h to linux/types.h then we are all safe and no breakage.
the rule of thum is to include the linux/* variant if the same
file exist in both linus/ and asm/ and types.h is in no way different
here
And trying to make it different just becasue it is used in userspace
intensively is just stupid and will be a cause of misunderstandings.
Sam
^ permalink raw reply
* Re: next-20090206: kernel BUG at mm/slub.c:1132
From: Yan Zheng @ 2009-02-06 17:25 UTC (permalink / raw)
To: Alexander Beregalov
Cc: linux-kernel, linux-mm, linux-btrfs, linux-next@vger.kernel.org
In-Reply-To: <a4423d670902060710m4919f6d6p1ffae13859c891be@mail.gmail.com>
2009/2/6 Alexander Beregalov <a.beregalov@gmail.com>:
> Hi
>
> I run dbench on btrfs, which is on file on xfs
>
> btrfs: disabling barriers on dev /dev/loop/0
> ------------[ cut here ]------------
> kernel BUG at mm/slub.c:1132!
> invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> last sysfs file: /sys/kernel/uevent_seqnum
> CPU 1
> Modules linked in:
> Pid: 2078, comm: loop0 Not tainted 2.6.29-rc3-next-20090206 #1
> RIP: 0010:[<ffffffff802c25ae>] [<ffffffff802c25ae>] __slab_alloc+0x41e/0x610
> RSP: 0018:ffff88007b17d620 EFLAGS: 00010202
> RAX: 0000000000000000 RBX: 0000000000120012 RCX: 0000000000000010
> RDX: 0000000000000000 RSI: ffffffff802c2301 RDI: ffffffff8026c12d
> RBP: ffff88007b17d670 R08: 0000000000000001 R09: 0000000000000000
> R10: ffff88007dbbce40 R11: 0000000000000000 R12: 0000000000000000
> R13: ffff88007db82ed8 R14: ffff88007d2554a8 R15: ffff88007d255488
> FS: 0000000000000000(0000) GS:ffff880004dd6000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 00007ff50c1bb000 CR3: 000000006c19d000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process loop0 (pid: 2078, threadinfo ffff88007b17c000, task ffff88007dbbce40)
> Stack:
> ffffffff802c27d9 ffffffff804379f7 ffffffff7d255488 0000001000120012
> ffff88007b17d660 0000000000000000 0000000000000202 0000000000120012
> ffff88007d255488 ffffffff804379f7 ffff88007b17d6b0 ffffffff802c2896
> Call Trace:
> [<ffffffff802c27d9>] ? kmem_cache_alloc+0x39/0x100
> [<ffffffff804379f7>] ? alloc_extent_state+0x17/0xa0
> [<ffffffff804379f7>] ? alloc_extent_state+0x17/0xa0
> [<ffffffff802c2896>] kmem_cache_alloc+0xf6/0x100
> [<ffffffff804379f7>] alloc_extent_state+0x17/0xa0
> [<ffffffff80439246>] clear_extent_bit+0x1a6/0x2e0
> [<ffffffff80439cee>] try_release_extent_state+0x7e/0xa0
> [<ffffffff80439e62>] try_release_extent_mapping+0x152/0x180
> [<ffffffff802a0520>] ? __remove_mapping+0xd0/0x100
> [<ffffffff804212f6>] __btrfs_releasepage+0x36/0x70
> [<ffffffff80421355>] btrfs_releasepage+0x25/0x30
> [<ffffffff8029391e>] try_to_release_page+0x2e/0x60
> [<ffffffff802a1542>] shrink_page_list+0x572/0x860
> [<ffffffff8062db3b>] ? _spin_unlock_irq+0x2b/0x60
> [<ffffffff802a1ae1>] ? shrink_list+0x2b1/0x680
> [<ffffffff802a1afd>] shrink_list+0x2cd/0x680
> [<ffffffff802358a0>] ? sub_preempt_count+0xc0/0x130
> [<ffffffff8062dbb2>] ? _spin_unlock_irqrestore+0x42/0x80
> [<ffffffff80475890>] ? __up_write+0x70/0x120
> [<ffffffff802a211b>] shrink_zone+0x26b/0x380
> [<ffffffff802a2b35>] try_to_free_pages+0x255/0x3d0
> [<ffffffff8029fc00>] ? isolate_pages_global+0x0/0x270
> [<ffffffff8029a767>] __alloc_pages_internal+0x237/0x590
> [<ffffffff80295545>] grab_cache_page_write_begin+0x85/0xd0
> [<ffffffff8062b88c>] ? __mutex_lock_common+0x37c/0x4d0
> [<ffffffff804fd7b3>] ? do_lo_send_aops+0x43/0x190
> [<ffffffff802ee577>] block_write_begin+0x87/0xf0
> [<ffffffff803eeee5>] xfs_vm_write_begin+0x25/0x30
> [<ffffffff803ef270>] ? xfs_get_blocks+0x0/0x20
> [<ffffffff802938eb>] pagecache_write_begin+0x1b/0x20
> [<ffffffff804fd823>] do_lo_send_aops+0xb3/0x190
> [<ffffffff8062db3b>] ? _spin_unlock_irq+0x2b/0x60
> [<ffffffff802358a0>] ? sub_preempt_count+0xc0/0x130
> [<ffffffff804fdd45>] loop_thread+0x445/0x4e0
> [<ffffffff804fd770>] ? do_lo_send_aops+0x0/0x190
> [<ffffffff80259420>] ? autoremove_wake_function+0x0/0x40
> [<ffffffff804fd900>] ? loop_thread+0x0/0x4e0
> [<ffffffff80258f76>] kthread+0x56/0x90
> [<ffffffff8020ce5a>] child_rip+0xa/0x20
> [<ffffffff80235759>] ? finish_task_switch+0x89/0x110
> [<ffffffff8062db46>] ? _spin_unlock_irq+0x36/0x60
> [<ffffffff8020c840>] ? restore_args+0x0/0x30
> [<ffffffff80258f20>] ? kthread+0x0/0x90
> [<ffffffff8020ce50>] ? child_rip+0x0/0x20
>
> Code: e8 18 69 1b 00 e9 48 ff ff ff 31 c9 48 c7 c2 00 4f 81 80 89 c6
> e8 93 7f fd ff 48 89 c3 48 85 c0 0f 85 73 fe ff ff e9 91 fd ff ff <0f>
> 0b eb fe 49 83 7f 60 00 90 0f 84 2d fd ff ff 4c 89 f7 e8 aa
> RIP [<ffffffff802c25ae>] __slab_alloc+0x41e/0x610
> RSP <ffff88007b17d620>
> --
In the call stack, the flags parameter for kmem_cache_alloc is same as
the gfp_flags parameter btrfs_releasepage gets. I guess the oops is due
to __GFP_HIGHMEM is passed to kmem_cache_alloc.
Regards
Yan Zheng
^ permalink raw reply
* Re: [linux-next][PATCH] revert headers_check fix: ia64, fpu.h
From: Russell King - ARM Linux @ 2009-02-06 17:22 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jaswinder Singh Rajput, KOSAKI Motohiro, Jaswinder Singh Rajput,
Linus Torvalds, Sam Ravnborg, Andrew Morton, hskinnemoen,
cooloney, tony.luck, ralf, dhowells, matthew, chris, LKML,
linux-next, linux-ia64
In-Reply-To: <20090206171400.GA14818@elte.hu>
On Fri, Feb 06, 2009 at 06:14:00PM +0100, Ingo Molnar wrote:
> I take this that you kind of agree that that removing ugly #ifdefs spread
> out is an upside. You failed to point out any downsides - you just seem to
> claim that you can live without the upsides. That is fine.
I'm sorry, I thought I pointed them out in my previous emails. Clearly
you didn't read those emails in spite of replying to them.
^ permalink raw reply
* Re: linux-next: manual merge of the pci tree with the pci-current tree
From: Jesse Barnes @ 2009-02-06 17:09 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Rafael J. Wysocki
In-Reply-To: <20090206135041.fd7a8e7e.sfr@canb.auug.org.au>
On Thursday, February 5, 2009 6:50 pm Stephen Rothwell wrote:
> Hi Jesse,
>
> Today's linux-next merge of the pci tree got a conflict in
> drivers/pci/pcie/portdrv_pci.c between commit
> 27be54a65c89c4b4aa9b25fc6fba31ffd01a08ca ("PCI: PCIe portdrv: Simplify
> suspend and resume") from the pci-current tree and commit
> 120d3f44dd4c7a16ac71f26d4ff44ad7498cb81a ("PCI: PCIe portdrv: Implement
> pm object") from the pci tree.
>
> I fixed it up (I used the pci tree version) and assume it will be fixed in
> the pci tree soon.
Oops yeah, thanks for bringing this up. I didn't rebase my linux-next branch
on top of my for-linus branch with the last set of changes... Will do.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [linux-next][PATCH] revert headers_check fix: ia64, fpu.h
From: Ingo Molnar @ 2009-02-06 17:14 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jaswinder Singh Rajput, KOSAKI Motohiro, Jaswinder Singh Rajput,
Linus Torvalds, Sam Ravnborg, Andrew Morton, hskinnemoen,
cooloney, tony.luck, ralf, dhowells, matthew, chris, LKML,
linux-next, linux-ia64
In-Reply-To: <20090206163857.GJ13758@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Fri, Feb 06, 2009 at 05:33:14PM +0100, Ingo Molnar wrote:
> >
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> >
> > > On Fri, Feb 06, 2009 at 05:12:29PM +0100, Ingo Molnar wrote:
> > > >
> > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > > >
> > > > > > We cannot see any downside of this patch.
> > > > > >
> > > > > > But we can see upside of this patch is:
> > > > > > 1. No need to protect linux/types.h with #ifndef __ASSEMBLY__ in many
> > > > > > files
> > > > > > 2. So we trying to replace multiple #ifndef __ASSEMBLY__ with one.
> > > > >
> > > > > The point is:
> > > > >
> > > > > 1. If the parent include needs to include linux/types.h to get at C
> > > > > types _and_ the include file needs to also be included by assembly
> > > > > code, it itself needs to have #ifndef __ASSEMBLY__ to protect those
> > > > > uses from the assembly code.
> > > > >
> > > > > In that case, the linux/types.h include should be contained within
> > > > > the #ifndef __ASSEMBLY__ .. #endif block along with all C only
> > > > > parts of the header file.
> > > >
> > > > That makes the code much less clean: putting #include's in the middle of a
> > > > header is poor style and leads to people failing to consider dependencies.
> > > > We generally put them to the header portion.
> > > >
> > > > Putting an #include line in the middle of a header file is a receipe for a
> > > > dependency hell (it can easily fall inside #ifdefs, can be overlooked,
> > > > etc.), so it's _strongly_ discouraged (at least on arch/x86).
> > >
> > > Put them at the top then with an additional ifndef.
> >
> > So you advocate 40 stupid pairs of #ifdefs spread out, instead of a
> > _single_, obvious #ifdef in a commonly used header?
>
> As I see it, if you want all your style points to be adhered to, then yes.
> And I do believe it to be a valid solution.
>
> Personally, I'd put them nearer the C code.
>
> That's precisely what I do with the ARM include files. Never been a
> problem.
I take this that you kind of agree that that removing ugly #ifdefs spread
out is an upside. You failed to point out any downsides - you just seem to
claim that you can live without the upsides. That is fine.
Ingo
^ permalink raw reply
* Re: [PATCH] revert headers_check fix: ia64, fpu.h
From: Russell King - ARM Linux @ 2009-02-06 16:38 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jaswinder Singh Rajput, KOSAKI Motohiro, Jaswinder Singh Rajput,
Linus Torvalds, Sam Ravnborg, Andrew Morton, hskinnemoen,
cooloney, tony.luck, ralf, dhowells, matthew, chris, LKML,
linux-next, linux-ia64
In-Reply-To: <20090206163314.GA11216@elte.hu>
On Fri, Feb 06, 2009 at 05:33:14PM +0100, Ingo Molnar wrote:
>
> * Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>
> > On Fri, Feb 06, 2009 at 05:12:29PM +0100, Ingo Molnar wrote:
> > >
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > >
> > > > > We cannot see any downside of this patch.
> > > > >
> > > > > But we can see upside of this patch is:
> > > > > 1. No need to protect linux/types.h with #ifndef __ASSEMBLY__ in many
> > > > > files
> > > > > 2. So we trying to replace multiple #ifndef __ASSEMBLY__ with one.
> > > >
> > > > The point is:
> > > >
> > > > 1. If the parent include needs to include linux/types.h to get at C
> > > > types _and_ the include file needs to also be included by assembly
> > > > code, it itself needs to have #ifndef __ASSEMBLY__ to protect those
> > > > uses from the assembly code.
> > > >
> > > > In that case, the linux/types.h include should be contained within
> > > > the #ifndef __ASSEMBLY__ .. #endif block along with all C only
> > > > parts of the header file.
> > >
> > > That makes the code much less clean: putting #include's in the middle of a
> > > header is poor style and leads to people failing to consider dependencies.
> > > We generally put them to the header portion.
> > >
> > > Putting an #include line in the middle of a header file is a receipe for a
> > > dependency hell (it can easily fall inside #ifdefs, can be overlooked,
> > > etc.), so it's _strongly_ discouraged (at least on arch/x86).
> >
> > Put them at the top then with an additional ifndef.
>
> So you advocate 40 stupid pairs of #ifdefs spread out, instead of a
> _single_, obvious #ifdef in a commonly used header?
As I see it, if you want all your style points to be adhered to, then yes.
And I do believe it to be a valid solution.
Personally, I'd put them nearer the C code.
That's precisely what I do with the ARM include files. Never been a
problem.
^ permalink raw reply
* Re: [PATCH] revert headers_check fix: ia64, fpu.h
From: Ingo Molnar @ 2009-02-06 16:33 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jaswinder Singh Rajput, KOSAKI Motohiro, Jaswinder Singh Rajput,
Linus Torvalds, Sam Ravnborg, Andrew Morton, hskinnemoen,
cooloney, tony.luck, ralf, dhowells, matthew, chris, LKML,
linux-next, linux-ia64
In-Reply-To: <20090206162352.GI13758@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Fri, Feb 06, 2009 at 05:12:29PM +0100, Ingo Molnar wrote:
> >
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> >
> > > > We cannot see any downside of this patch.
> > > >
> > > > But we can see upside of this patch is:
> > > > 1. No need to protect linux/types.h with #ifndef __ASSEMBLY__ in many
> > > > files
> > > > 2. So we trying to replace multiple #ifndef __ASSEMBLY__ with one.
> > >
> > > The point is:
> > >
> > > 1. If the parent include needs to include linux/types.h to get at C
> > > types _and_ the include file needs to also be included by assembly
> > > code, it itself needs to have #ifndef __ASSEMBLY__ to protect those
> > > uses from the assembly code.
> > >
> > > In that case, the linux/types.h include should be contained within
> > > the #ifndef __ASSEMBLY__ .. #endif block along with all C only
> > > parts of the header file.
> >
> > That makes the code much less clean: putting #include's in the middle of a
> > header is poor style and leads to people failing to consider dependencies.
> > We generally put them to the header portion.
> >
> > Putting an #include line in the middle of a header file is a receipe for a
> > dependency hell (it can easily fall inside #ifdefs, can be overlooked,
> > etc.), so it's _strongly_ discouraged (at least on arch/x86).
>
> Put them at the top then with an additional ifndef.
So you advocate 40 stupid pairs of #ifdefs spread out, instead of a
_single_, obvious #ifdef in a commonly used header?
Case closed.
Ingo
^ permalink raw reply
* Re: [linux-next][PATCH] revert headers_check fix: ia64, fpu.h
From: Russell King - ARM Linux @ 2009-02-06 16:23 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jaswinder Singh Rajput, KOSAKI Motohiro, Jaswinder Singh Rajput,
Linus Torvalds, Sam Ravnborg, Andrew Morton, hskinnemoen,
cooloney, tony.luck, ralf, dhowells, matthew, chris, LKML,
linux-next, linux-ia64
In-Reply-To: <20090206161229.GA8256@elte.hu>
On Fri, Feb 06, 2009 at 05:12:29PM +0100, Ingo Molnar wrote:
>
> * Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>
> > > We cannot see any downside of this patch.
> > >
> > > But we can see upside of this patch is:
> > > 1. No need to protect linux/types.h with #ifndef __ASSEMBLY__ in many
> > > files
> > > 2. So we trying to replace multiple #ifndef __ASSEMBLY__ with one.
> >
> > The point is:
> >
> > 1. If the parent include needs to include linux/types.h to get at C
> > types _and_ the include file needs to also be included by assembly
> > code, it itself needs to have #ifndef __ASSEMBLY__ to protect those
> > uses from the assembly code.
> >
> > In that case, the linux/types.h include should be contained within
> > the #ifndef __ASSEMBLY__ .. #endif block along with all C only
> > parts of the header file.
>
> That makes the code much less clean: putting #include's in the middle of a
> header is poor style and leads to people failing to consider dependencies.
> We generally put them to the header portion.
>
> Putting an #include line in the middle of a header file is a receipe for a
> dependency hell (it can easily fall inside #ifdefs, can be overlooked,
> etc.), so it's _strongly_ discouraged (at least on arch/x86).
Put them at the top then with an additional ifndef.
> > 2. if it doesn't need C types from linux/types.h, then that header has
> > no business including linux/types.h, and the include should be
> > eliminated to save the already dirbolically slow compiler from
> > having to read and parse that file, and more importantly allowing
> > it to eliminate linux/types.h from the build dependencies.
> >
> > Yes, you can wrap linux/types.h with that ifndef, and yes it will fix any
> > problems, but I view it as a hack rather than fixing the real problem
> > which is lazyness by code writers to get their include dependencies right.
>
> It is not about include dependencies at all - it is about the existing and
> accepted practice which you did not consider in your argument: the use of
> mixed-mode headers. A linux/types.h include there is perfectly clean and
> should not break the build.
It _is_ about include dependencies.
> Again, i repeat: there is nothing wrong about making a small number of very
> commonly used C header assembly-invariant. It results in better structured
> header files and cleaner code.
>
> The argument is as simple as that, and up until this email you wrote roughly
> 10 replies and it's not even that you disagreed with our point on some
> honest basis that we could argue with - the ting is that you failed to even
> _realize_ this argument of us and you tried to force your partial (and
> trivially flawed) world view on us impatiently. In view of that you need to
> be more careful before calling people 'stupidly obtuse' ;-)
If you think that I'm ignoring your argument, then screw you.
I'm making a counter argument which I believe is _equally_ valid and which
I believe is actually far more important - at least it is _to_ _me_.
I don't wish to see my build times extended any more than they already
have been by sloppy and lazy programming in the kernel. And if I didn't
make that point earlier, what a shame. I'm making it NOW.
I've been trying over the last six months to (a) reduce the number of
files included in the ARM sub-tree and (b) reduce the namespace pollution
from ARM headers into the generic kernel both with the aim of trying to
improve build time. That's something you can verify by looking through
the commits in arch/arm/include/asm if you think I'm making this up,
which clearly you will do.
Oh why bring it up after 11 replies. I guess I'm just useless at
expressing myself clearly.
^ permalink raw reply
* Re: [linux-next][PATCH] revert headers_check fix: ia64, fpu.h
From: Ingo Molnar @ 2009-02-06 16:12 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jaswinder Singh Rajput, KOSAKI Motohiro, Jaswinder Singh Rajput,
Linus Torvalds, Sam Ravnborg, Andrew Morton, hskinnemoen,
cooloney, tony.luck, ralf, dhowells, matthew, chris, LKML,
linux-next, linux-ia64
In-Reply-To: <20090206155512.GF13758@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > We cannot see any downside of this patch.
> >
> > But we can see upside of this patch is:
> > 1. No need to protect linux/types.h with #ifndef __ASSEMBLY__ in many
> > files
> > 2. So we trying to replace multiple #ifndef __ASSEMBLY__ with one.
>
> The point is:
>
> 1. If the parent include needs to include linux/types.h to get at C
> types _and_ the include file needs to also be included by assembly
> code, it itself needs to have #ifndef __ASSEMBLY__ to protect those
> uses from the assembly code.
>
> In that case, the linux/types.h include should be contained within
> the #ifndef __ASSEMBLY__ .. #endif block along with all C only
> parts of the header file.
That makes the code much less clean: putting #include's in the middle of a
header is poor style and leads to people failing to consider dependencies.
We generally put them to the header portion.
Putting an #include line in the middle of a header file is a receipe for a
dependency hell (it can easily fall inside #ifdefs, can be overlooked,
etc.), so it's _strongly_ discouraged (at least on arch/x86).
> 2. if it doesn't need C types from linux/types.h, then that header has
> no business including linux/types.h, and the include should be
> eliminated to save the already dirbolically slow compiler from
> having to read and parse that file, and more importantly allowing
> it to eliminate linux/types.h from the build dependencies.
>
> Yes, you can wrap linux/types.h with that ifndef, and yes it will fix any
> problems, but I view it as a hack rather than fixing the real problem
> which is lazyness by code writers to get their include dependencies right.
It is not about include dependencies at all - it is about the existing and
accepted practice which you did not consider in your argument: the use of
mixed-mode headers. A linux/types.h include there is perfectly clean and
should not break the build.
Again, i repeat: there is nothing wrong about making a small number of very
commonly used C header assembly-invariant. It results in better structured
header files and cleaner code.
The argument is as simple as that, and up until this email you wrote roughly
10 replies and it's not even that you disagreed with our point on some
honest basis that we could argue with - the ting is that you failed to even
_realize_ this argument of us and you tried to force your partial (and
trivially flawed) world view on us impatiently. In view of that you need to
be more careful before calling people 'stupidly obtuse' ;-)
Ingo
^ permalink raw reply
* Re: next-20090202: task kmemleak:763 blocked for more than 120seconds.
From: Catalin Marinas @ 2009-02-06 16:02 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Mandeep Singh Baines, Alexander Beregalov, linux-next, LKML
In-Reply-To: <20090203205204.GC6344@nowhere>
On Tue, 2009-02-03 at 20:52 +0000, Frederic Weisbecker wrote:
> Note that requiring kmemleak to be freezable looks only relevant if it does
> some memory allocations (hibernation needs some memory and prefer that there
> are not too much parallel memory allocations.)
OK. In this case, there is no need for the kmemleak thread to be
freezable. It only scans the memory periodically but doesn't allocate
any itself.
Thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCH] revert headers_check fix: ia64, fpu.h
From: Ingo Molnar @ 2009-02-06 16:01 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jaswinder Singh Rajput, KOSAKI Motohiro, Jaswinder Singh Rajput,
Linus Torvalds, Sam Ravnborg, Andrew Morton, hskinnemoen,
cooloney, tony.luck, ralf, dhowells, matthew, chris, LKML,
linux-next, linux-ia64
In-Reply-To: <20090206154917.GE13758@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Fri, Feb 06, 2009 at 04:45:39PM +0100, Ingo Molnar wrote:
> >
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> >
> > > On Fri, Feb 06, 2009 at 08:59:01PM +0530, Jaswinder Singh Rajput wrote:
> > > > Jaswinder Singh Rajput (2):
> > > > Neither asm/types.h nor linux/types.h is required for arch/ia64/include/asm/fpu.h
> > > > make linux/types.h as assembly safe
> > >
> > > I continue to disagree with the need for the second patch.
> >
> > But have not replied to my mail about that so far.
>
> Sigh. No I didn't - because I also got a reply from Jaswinder and
> covered all points in _that_ reply.
>
> Would you like me to re-send my reply so that you can appear in the To:
> header?
>
> Stop making this discussion stupidly obtuse.
I am not making anything stupidly obtuse, your reply to Jaswinder was in a
different (but related) portion of the thread, that i have not read yet at
that point. I have read it now and have replied.
Ingo
^ permalink raw reply
* Re: [linux-next][PATCH] revert headers_check fix: ia64, fpu.h
From: Russell King - ARM Linux @ 2009-02-06 15:55 UTC (permalink / raw)
To: Jaswinder Singh Rajput
Cc: Ingo Molnar, KOSAKI Motohiro, Jaswinder Singh Rajput,
Linus Torvalds, Sam Ravnborg, Andrew Morton, hskinnemoen,
cooloney, tony.luck, ralf, dhowells, matthew, chris, LKML,
linux-next, linux-ia64
In-Reply-To: <1233935328.3209.30.camel@localhost.localdomain>
On Fri, Feb 06, 2009 at 09:18:48PM +0530, Jaswinder Singh Rajput wrote:
> On Fri, 2009-02-06 at 15:33 +0000, Russell King - ARM Linux wrote:
> > On Fri, Feb 06, 2009 at 08:59:01PM +0530, Jaswinder Singh Rajput wrote:
> > > Jaswinder Singh Rajput (2):
> > > Neither asm/types.h nor linux/types.h is required for arch/ia64/include/asm/fpu.h
> > > make linux/types.h as assembly safe
> >
> > I continue to disagree with the need for the second patch.
>
> Like Ingo suggested:
>
> On Fri, 2009-02-06 at 15:58 +0100, Ingo Molnar wrote:
> > Well types.h easily gets included in other files though, which might be
> > partially suited for assembly - and have !__ASSEMBLY__ portions that rely on
> > a types.h include.
> >
> > So making this file an invariant in .S files does not sound like a bad idea
> > to me. Is there any downside?
> >
>
> We cannot see any downside of this patch.
>
> But we can see upside of this patch is:
> 1. No need to protect linux/types.h with #ifndef __ASSEMBLY__ in many
> files
> 2. So we trying to replace multiple #ifndef __ASSEMBLY__ with one.
The point is:
1. If the parent include needs to include linux/types.h to get at C
types _and_ the include file needs to also be included by assembly
code, it itself needs to have #ifndef __ASSEMBLY__ to protect those
uses from the assembly code.
In that case, the linux/types.h include should be contained within
the #ifndef __ASSEMBLY__ .. #endif block along with all C only
parts of the header file.
2. if it doesn't need C types from linux/types.h, then that header has
no business including linux/types.h, and the include should be
eliminated to save the already dirbolically slow compiler from
having to read and parse that file, and more importantly allowing
it to eliminate linux/types.h from the build dependencies.
Yes, you can wrap linux/types.h with that ifndef, and yes it will fix
any problems, but I view it as a hack rather than fixing the real problem
which is lazyness by code writers to get their include dependencies right.
^ permalink raw reply
* Re: [PATCH] revert headers_check fix: ia64, fpu.h
From: Russell King - ARM Linux @ 2009-02-06 15:49 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jaswinder Singh Rajput, KOSAKI Motohiro, Jaswinder Singh Rajput,
Linus Torvalds, Sam Ravnborg, Andrew Morton, hskinnemoen,
cooloney, tony.luck, ralf, dhowells, matthew, chris, LKML,
linux-next, linux-ia64
In-Reply-To: <20090206154539.GP18368@elte.hu>
On Fri, Feb 06, 2009 at 04:45:39PM +0100, Ingo Molnar wrote:
>
> * Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>
> > On Fri, Feb 06, 2009 at 08:59:01PM +0530, Jaswinder Singh Rajput wrote:
> > > Jaswinder Singh Rajput (2):
> > > Neither asm/types.h nor linux/types.h is required for arch/ia64/include/asm/fpu.h
> > > make linux/types.h as assembly safe
> >
> > I continue to disagree with the need for the second patch.
>
> But have not replied to my mail about that so far.
Sigh. No I didn't - because I also got a reply from Jaswinder and
covered all points in _that_ reply.
Would you like me to re-send my reply so that you can appear in the To:
header?
Stop making this discussion stupidly obtuse.
^ permalink raw reply
* Re: [PATCH] revert headers_check fix: ia64, fpu.h
From: Jaswinder Singh Rajput @ 2009-02-06 15:48 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Ingo Molnar, KOSAKI Motohiro, Jaswinder Singh Rajput,
Linus Torvalds, Sam Ravnborg, Andrew Morton, hskinnemoen,
cooloney, tony.luck, ralf, dhowells, matthew, chris, LKML,
linux-next, linux-ia64
In-Reply-To: <20090206153315.GD13758@n2100.arm.linux.org.uk>
On Fri, 2009-02-06 at 15:33 +0000, Russell King - ARM Linux wrote:
> On Fri, Feb 06, 2009 at 08:59:01PM +0530, Jaswinder Singh Rajput wrote:
> > On Fri, 2009-02-06 at 15:55 +0100, Ingo Molnar wrote:
> > > * KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> > >
> > > > > > Index: b/arch/ia64/include/asm/fpu.h
> > > > > > ===================================================================
> > > > > > --- a/arch/ia64/include/asm/fpu.h
> > > > > > +++ b/arch/ia64/include/asm/fpu.h
> > > > > > @@ -6,7 +6,7 @@
> > > > > > * David Mosberger-Tang <davidm@hpl.hp.com>
> > > > > > */
> > > > > >
> > > > > > -#include <linux/types.h>
> > > > > > +#include <asm/types.h>
> > > > > >
> > > > >
> > > > > No , we do not even need asm/types.h
> > > > >
> > > > > Subject: [PATCH] Neither asm/types.h nor linux/types.h is not required
> > > > > for arch/ia64/include/asm/fpu.h
> > > > >
> > > > > Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
> > > >
> > > > ok. I confirmed.
> > > > Tested-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> > > > Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> > >
> > > Thanks.
> > >
> > > Jaswinder, mind adding these tags to the commit and sending a pull request
> > > with all fixes?
> >
> > The following changes since commit 0b86a4e34d885e734a4c4e46293376f3f1c639eb:
> > Ingo Molnar (1):
> > Merge branch 'core/header-fixes' of git://git.kernel.org/.../jaswinder/linux-2.6-tip into core/header-fixes
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jaswinder/linux-2.6-tip.git core/header-fixes
> >
> > Jaswinder Singh Rajput (2):
> > Neither asm/types.h nor linux/types.h is required for arch/ia64/include/asm/fpu.h
> > make linux/types.h as assembly safe
>
> I continue to disagree with the need for the second patch.
Like Ingo suggested:
On Fri, 2009-02-06 at 15:58 +0100, Ingo Molnar wrote:
> Well types.h easily gets included in other files though, which might be
> partially suited for assembly - and have !__ASSEMBLY__ portions that rely on
> a types.h include.
>
> So making this file an invariant in .S files does not sound like a bad idea
> to me. Is there any downside?
>
We cannot see any downside of this patch.
But we can see upside of this patch is:
1. No need to protect linux/types.h with #ifndef __ASSEMBLY__ in many
files
2. So we trying to replace multiple #ifndef __ASSEMBLY__ with one.
Thanks,
--
JSR
^ permalink raw reply
* Re: [PATCH] revert headers_check fix: ia64, fpu.h
From: Ingo Molnar @ 2009-02-06 15:45 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jaswinder Singh Rajput, KOSAKI Motohiro, Jaswinder Singh Rajput,
Linus Torvalds, Sam Ravnborg, Andrew Morton, hskinnemoen,
cooloney, tony.luck, ralf, dhowells, matthew, chris, LKML,
linux-next, linux-ia64
In-Reply-To: <20090206153315.GD13758@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Fri, Feb 06, 2009 at 08:59:01PM +0530, Jaswinder Singh Rajput wrote:
> > On Fri, 2009-02-06 at 15:55 +0100, Ingo Molnar wrote:
> > > * KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> > >
> > > > > > Index: b/arch/ia64/include/asm/fpu.h
> > > > > > ===================================================================
> > > > > > --- a/arch/ia64/include/asm/fpu.h
> > > > > > +++ b/arch/ia64/include/asm/fpu.h
> > > > > > @@ -6,7 +6,7 @@
> > > > > > * David Mosberger-Tang <davidm@hpl.hp.com>
> > > > > > */
> > > > > >
> > > > > > -#include <linux/types.h>
> > > > > > +#include <asm/types.h>
> > > > > >
> > > > >
> > > > > No , we do not even need asm/types.h
> > > > >
> > > > > Subject: [PATCH] Neither asm/types.h nor linux/types.h is not required
> > > > > for arch/ia64/include/asm/fpu.h
> > > > >
> > > > > Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
> > > >
> > > > ok. I confirmed.
> > > > Tested-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> > > > Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> > >
> > > Thanks.
> > >
> > > Jaswinder, mind adding these tags to the commit and sending a pull request
> > > with all fixes?
> >
> > The following changes since commit 0b86a4e34d885e734a4c4e46293376f3f1c639eb:
> > Ingo Molnar (1):
> > Merge branch 'core/header-fixes' of git://git.kernel.org/.../jaswinder/linux-2.6-tip into core/header-fixes
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jaswinder/linux-2.6-tip.git core/header-fixes
> >
> > Jaswinder Singh Rajput (2):
> > Neither asm/types.h nor linux/types.h is required for arch/ia64/include/asm/fpu.h
> > make linux/types.h as assembly safe
>
> I continue to disagree with the need for the second patch.
But have not replied to my mail about that so far.
Why is it wrong to make types.h an assembly-invariant? It is positively
helpful for mixed-mode headers and has no downsides whatsoever.
Ingo
^ 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