* Re: linux-next: Tree for December 1 (netfilter build error)
From: Eric Leblond @ 2008-12-10 18:43 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: Randy Dunlap, Stephen Rothwell, netdev, linux-next, LKML,
netfilter-devel, kaber
In-Reply-To: <20081210165455.GC6391@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 647 bytes --]
Hi,
Le mercredi 10 décembre 2008 à 22:24 +0530, Kamalesh Babulal a écrit :
> * Randy Dunlap <randy.dunlap@oracle.com> [2008-12-01 11:59:34]:
>
> the function nfulnl_log_packet is exported only if
> CONFIG_NETFILTER_NETLINK_LOG is enabled, so marking the loging function
> between ifdef.
>
My patch introduces a real depedency of xt_NFLOG with nfnetlink_log
(CONFIG_NETFILTER_NETLINK_LOG) but I forget to state it in Kconfig.
I thus disagree with your patch. It is better to fix the compilation
depedency instead by modifying Kconfig.
A patch fixing this issue is to come.
BR,
--
Eric Leblond <eric@inl.fr>
INL
[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* netfilter: xt_NFLOG is dependant of nfnetlink_log
From: Eric Leblond @ 2008-12-10 18:49 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: Randy Dunlap, Stephen Rothwell, netdev, linux-next, LKML,
netfilter-devel, kaber, Eric Leblond
In-Reply-To: <1228934630.5961.8.camel@ice-age>
The patch "don't call nf_log_packet in NFLOG module" make xt_NFLOG
dependant of nfnetlink_log. This patch forces the dependencies to fix
compilation in case only xt_NFLOG compilation was asked and modifies the
help message accordingly to the change.
Signed-off-by: Eric Leblond <eric@inl.fr>
---
net/netfilter/Kconfig | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index 25dcef9..c2bac9c 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -373,11 +373,10 @@ config NETFILTER_XT_TARGET_MARK
config NETFILTER_XT_TARGET_NFLOG
tristate '"NFLOG" target support'
default m if NETFILTER_ADVANCED=n
+ select NETFILTER_NETLINK_LOG
help
This option enables the NFLOG target, which allows to LOG
- messages through the netfilter logging API, which can use
- either the old LOG target, the old ULOG target or nfnetlink_log
- as backend.
+ messages through nfnetlink_log.
To compile it as a module, choose M here. If unsure, say N.
--
1.5.6.3
^ permalink raw reply related
* Re: linux-next: manual merge of the audit tree
From: David Howells @ 2008-12-10 18:58 UTC (permalink / raw)
To: Stephen Rothwell
Cc: dhowells, Al Viro, linux-next, James Morris, Eric Paris,
Serge Hallyn
In-Reply-To: <20081209175726.682d77cd.sfr@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Today's linux-next merge of the audit tree got a lot of conflict in
> include/linux/audit.h, kernel/auditsc.c, kernel/capability.c and
> security/commoncap.c against commits in the security-testing tree.
>
> Its not obvious how to resolve these, so can you, Eric, James and Dave
> have a conversation and see what you can come up with. Some will be
> easy, but there are several overlapping changes here.
>
> Looking harder, it looks like some (all?) of Eric's patches may already
> be in the security-testing tree ...
>
> I have dropped the audit tree for today.
I've looked at all the conflicting bits, and I think you should take what's in
the security tree over what's in Al's tree for all of them. I think the
security tree already has everything that Al's tree applies in the conflicting
areas, it's just that the security tree has further changes parked on top.
David
^ permalink raw reply
* Re: linux-next: manual merge of the audit tree
From: Eric Paris @ 2008-12-10 19:01 UTC (permalink / raw)
To: David Howells
Cc: Stephen Rothwell, Al Viro, linux-next, James Morris, Serge Hallyn
In-Reply-To: <13157.1228935509@redhat.com>
On Wed, 2008-12-10 at 18:58 +0000, David Howells wrote:
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Today's linux-next merge of the audit tree got a lot of conflict in
> > include/linux/audit.h, kernel/auditsc.c, kernel/capability.c and
> > security/commoncap.c against commits in the security-testing tree.
> >
> > Its not obvious how to resolve these, so can you, Eric, James and Dave
> > have a conversation and see what you can come up with. Some will be
> > easy, but there are several overlapping changes here.
> >
> > Looking harder, it looks like some (all?) of Eric's patches may already
> > be in the security-testing tree ...
> >
> > I have dropped the audit tree for today.
>
> I've looked at all the conflicting bits, and I think you should take what's in
> the security tree over what's in Al's tree for all of them. I think the
> security tree already has everything that Al's tree applies in the conflicting
> areas, it's just that the security tree has further changes parked on top.
>
> David
I think David is right, all the conflicts should come from
security-testing. Al does have other good stuff in his tree though, Al
do you want to just kick all of my patches out?
-Eric
^ permalink raw reply
* Re: linux-next: Tree for December 9
From: Andrew Morton @ 2008-12-10 19:16 UTC (permalink / raw)
To: NeilBrown; +Cc: kay.sievers, sfr, linux-next, linux-kernel, adobriyan, greg
In-Reply-To: <16e59424891c03bfe31eb0898fedeac9.squirrel@neil.brown.name>
On Wed, 10 Dec 2008 12:42:58 +1100 (EST)
"NeilBrown" <neilb@suse.de> wrote:
> On Wed, December 10, 2008 12:30 pm, Andrew Morton wrote:
> > On Wed, 10 Dec 2008 01:31:13 +0100 "Kay Sievers" <kay.sievers@vrfy.org>
> > wrote:
> >
> >> > akpm2:/home/akpm# udevmonitor
> >> > udevmonitor prints the received event from the kernel [UEVENT]
> >> > and the event which udev sends out after rule processing [UDEV]
> >> >
> >> > UDEV [1228867146.103334] add@/class/bdi/9:0
> >> > UDEV [1228867146.107566] remove@/block/md0
> >> > UDEV [1228867146.111969] remove@/class/bdi/9:0
> >> > UEVENT[1228867146.119889] add@/block/md0
> >> > UEVENT[1228867146.119964] add@/class/bdi/9:0
> >> > UEVENT[1228867146.120162] remove@/class/bdi/9:0
> >> > UEVENT[1228867146.120205] remove@/block/md0
> >> > UDEV [1228867146.122839] add@/block/md0
> >> > UDEV [1228867146.129125] add@/class/bdi/9:0
> >> > UDEV [1228867146.133459] remove@/block/md0
> >> > UDEV [1228867146.137813] remove@/class/bdi/9:0
> >> > UEVENT[1228867146.145652] add@/block/md0
> >>
> >> Weird loop, something is accessing /dev/md0, i guess, which creates
> >> the kernel device, and the event, which accesses /dev/md0 again and it
> >> goes crazy. Maybe caused by changes Neil did.
> >
> > I knew an Australian was to blame - it's just a matter of determining
> > which one.
>
> Let's not count our chickens .... :-)
>
> Can you get me
> tar czvf - /lib/udev /etc/udev | mail neilb
>
> so I can see exactly what FC6 is likely to try to do when an
> md device appears or disappears?
Is at http://userweb.kernel.org/~akpm/udev.tar.gz, thanks.
^ permalink raw reply
* Re: linux-next: manual merge of the audit tree
From: David Howells @ 2008-12-10 19:33 UTC (permalink / raw)
To: Eric Paris
Cc: dhowells, Stephen Rothwell, Al Viro, linux-next, James Morris,
Serge Hallyn
In-Reply-To: <1228935701.3524.3.camel@localhost.localdomain>
Eric Paris <eparis@redhat.com> wrote:
> I think David is right, all the conflicts should come from
> security-testing. Al does have other good stuff in his tree though, Al
> do you want to just kick all of my patches out?
Maybe it's worth James taking Al's changes into his tree and resolving all the
conflicts in favour of what's in his tree.
David
^ permalink raw reply
* Re: [bug?] bio: add experimental support for inlining a number of bio_vecs inside the bio
From: Andrew Morton @ 2008-12-10 21:13 UTC (permalink / raw)
To: Jens Axboe; +Cc: kosaki.motohiro, sfr, linux-next, linux-kernel
In-Reply-To: <20081210121237.GQ23742@kernel.dk>
On Wed, 10 Dec 2008 13:12:38 +0100
Jens Axboe <jens.axboe@oracle.com> wrote:
> > experimental??
>
> Experimental in the sense that it's the first version, not the concept.
> It's held up well for me, but just yesterday I received the first bug
> report on a ppc platform and now you have this on ia64.
Well there's another bug report up-list. "next-20081209: pdflush: page
allocation failure (xfs)".
The clearing of (__GFP_WAIT | __GFP_IO) will call the page allocator in the
weakest possible mode and will of course spew page allocations warnings
with great frequency. It should at least add in __GFP_NOWARN.
^ permalink raw reply
* Re: linux-next: Tree for December 9
From: Neil Brown @ 2008-12-10 22:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: kay.sievers, sfr, linux-next, linux-kernel, adobriyan, greg
In-Reply-To: <20081210111636.688cd882.akpm@linux-foundation.org>
On Wednesday December 10, akpm@linux-foundation.org wrote:
> On Wed, 10 Dec 2008 12:42:58 +1100 (EST)
> "NeilBrown" <neilb@suse.de> wrote:
>
> > On Wed, December 10, 2008 12:30 pm, Andrew Morton wrote:
> > > On Wed, 10 Dec 2008 01:31:13 +0100 "Kay Sievers" <kay.sievers@vrfy.org>
> > > wrote:
> > >
> > >> > akpm2:/home/akpm# udevmonitor
> > >> > udevmonitor prints the received event from the kernel [UEVENT]
> > >> > and the event which udev sends out after rule processing [UDEV]
> > >> >
> > >> > UDEV [1228867146.103334] add@/class/bdi/9:0
> > >> > UDEV [1228867146.107566] remove@/block/md0
> > >> > UDEV [1228867146.111969] remove@/class/bdi/9:0
> > >> > UEVENT[1228867146.119889] add@/block/md0
> > >> > UEVENT[1228867146.119964] add@/class/bdi/9:0
> > >> > UEVENT[1228867146.120162] remove@/class/bdi/9:0
> > >> > UEVENT[1228867146.120205] remove@/block/md0
> > >> > UDEV [1228867146.122839] add@/block/md0
> > >> > UDEV [1228867146.129125] add@/class/bdi/9:0
> > >> > UDEV [1228867146.133459] remove@/block/md0
> > >> > UDEV [1228867146.137813] remove@/class/bdi/9:0
> > >> > UEVENT[1228867146.145652] add@/block/md0
> > >>
> > >> Weird loop, something is accessing /dev/md0, i guess, which creates
> > >> the kernel device, and the event, which accesses /dev/md0 again and it
> > >> goes crazy. Maybe caused by changes Neil did.
> > >
> > > I knew an Australian was to blame - it's just a matter of determining
> > > which one.
> >
> > Let's not count our chickens .... :-)
> >
> > Can you get me
> > tar czvf - /lib/udev /etc/udev | mail neilb
> >
> > so I can see exactly what FC6 is likely to try to do when an
> > md device appears or disappears?
>
> Is at http://userweb.kernel.org/~akpm/udev.tar.gz, thanks.
Thanks.
That udev code does no special handling of md device, and runs vol-id
on every device that appears to see what it contains.
So if an md device is ever opened and closed immediately - as
typically happens at boot to sent the AUTO_RUN ioctl to do in-kernel
autodetection - then it will start a loop:
loop:
The open causes an ADD event to udev.
By the time udev handles it the device is closed, so when
udev opens the device (via vol-id), the device is re-created
triggering another ADD event.
vol-id then closes the device and it disappears.
Goto loop
So it isn't safe to destroy the md device as soon as it is closed.
Next best option is to destroy it after close providing at least one
ioctl has been made (or similar change via writing to sysfs).
This means that in most cases the device will disappear when not
needed, but in the particular case of some code which doesn't really
understand 'md' opening the device, it will hang around to avoid
causing confusion.
I have just pushed out an updated for-next branch.
The incremental patch is below.
Thanks,
NeilBrown
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 89700b5..bef91b8 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -262,7 +262,7 @@ static mddev_t * mddev_find(dev_t unit)
if (new) {
list_add(&new->all_mddevs, &all_mddevs);
spin_unlock(&all_mddevs_lock);
- new->hold_active = UNTIL_CLOSE;
+ new->hold_active = UNTIL_IOCTL;
return new;
}
} else if (new) {
@@ -3487,6 +3487,8 @@ md_attr_store(struct kobject *kobj, struct attribute *attr,
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
rv = mddev_lock(mddev);
+ if (mddev->hold_active == UNTIL_IOCTL)
+ mddev->hold_active = 0;
if (!rv) {
rv = entry->store(mddev, page, length);
mddev_unlock(mddev);
@@ -5160,6 +5162,9 @@ static int md_ioctl(struct block_device *bdev, fmode_t mode,
done_unlock:
abort_unlock:
+ if (mddev->hold_active == UNTIL_IOCTL &&
+ err != -EINVAL)
+ mddev->hold_active = 0;
mddev_unlock(mddev);
return err;
@@ -5209,8 +5214,6 @@ static int md_release(struct gendisk *disk, fmode_t mode)
BUG_ON(!mddev);
atomic_dec(&mddev->openers);
- if (mddev->hold_active == UNTIL_CLOSE)
- mddev->hold_active = 0;
mddev_put(mddev);
return 0;
diff --git a/include/linux/raid/md_k.h b/include/linux/raid/md_k.h
index 19756d7..dac4217 100644
--- a/include/linux/raid/md_k.h
+++ b/include/linux/raid/md_k.h
@@ -138,7 +138,7 @@ struct mddev_s
struct kobject kobj;
int hold_active;
-#define UNTIL_CLOSE 1
+#define UNTIL_IOCTL 1
#define UNTIL_STOP 2
/* Superblock information */
^ permalink raw reply related
* Re: linux-next: Tree for December 10
From: Andrew Morton @ 2008-12-10 22:52 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, linux-acpi, Ingo Molnar
In-Reply-To: <20081210164659.9ebb8158.sfr@canb.auug.org.au>
On Wed, 10 Dec 2008 16:46:59 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> (patches at
> http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/)
This tree breaks poweroff on my x86_64 test box. `halt -pfn' does all
the usual things, but the machine doesn't turn off.
config: http://userweb.kernel.org/~akpm/config-akpm2.txt
dmesg: http://userweb.kernel.org/~akpm/dmesg-akpm2.txt
Any suggestions which don't include the word "bisect" would be most welcome.
^ permalink raw reply
* Re: [PATCH] simnet: convert to net_device_ops
From: David Miller @ 2008-12-10 23:25 UTC (permalink / raw)
To: a.beregalov; +Cc: adobriyan, linux-next, netdev, linux-ia64
In-Reply-To: <a4423d670812100321qc93060evd0d3ae3f78418b29@mail.gmail.com>
From: "Alexander Beregalov" <a.beregalov@gmail.com>
Date: Wed, 10 Dec 2008 14:21:46 +0300
> 2008/12/10 David Miller <davem@davemloft.net>:
> > From: Alexey Dobriyan <adobriyan@gmail.com>
> > Date: Tue, 9 Dec 2008 18:08:27 +0300
> >
> >> On Tue, Dec 09, 2008 at 05:11:17PM +0300, Alexander Beregalov wrote:
> >> > CC arch/ia64/hp/sim/simeth.o
> >> > arch/ia64/hp/sim/simeth.c: In function 'simeth_probe1':
> >> > arch/ia64/hp/sim/simeth.c:212: error: 'struct net_device' has no member named 'open'
> >>
> >> [PATCH] simeth: convert to net_device_ops
> >>
> >> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> >
> > This doesn't explain the build failure.
> >
> > Using ->open() and friends should work perfectly fine for drivers not
> > yet converted to netdev_ops. The code protected by COMPAT_NET_DEV_OPS
> > provides this, and we force that Kconfig option to always be on.
> >
> > I don't want to add this patch and just shrug off this build failure.
> > If this build failures, we should be seeing 200 other drivers not
> > build too.
> >
> > I suspect something is messed up with this person's kernel config
> > or similar.
> >
>
> Thanks for explanation.
> Is it better?
Good fix, except that your email client corrupted the patch
by turning tab characters into spaces.
I fixed this up and applied your patch. But please next
time provide a proper Signed-off-by line too.
^ permalink raw reply
* Re: linux-next: manual merge of the audit tree
From: Al Viro @ 2008-12-10 23:28 UTC (permalink / raw)
To: Eric Paris
Cc: David Howells, Stephen Rothwell, linux-next, James Morris,
Serge Hallyn
In-Reply-To: <1228935701.3524.3.camel@localhost.localdomain>
On Wed, Dec 10, 2008 at 02:01:41PM -0500, Eric Paris wrote:
> On Wed, 2008-12-10 at 18:58 +0000, David Howells wrote:
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > > Today's linux-next merge of the audit tree got a lot of conflict in
> > > include/linux/audit.h, kernel/auditsc.c, kernel/capability.c and
> > > security/commoncap.c against commits in the security-testing tree.
> > >
> > > Its not obvious how to resolve these, so can you, Eric, James and Dave
> > > have a conversation and see what you can come up with. Some will be
> > > easy, but there are several overlapping changes here.
> > >
> > > Looking harder, it looks like some (all?) of Eric's patches may already
> > > be in the security-testing tree ...
> > >
> > > I have dropped the audit tree for today.
> >
> > I've looked at all the conflicting bits, and I think you should take what's in
> > the security tree over what's in Al's tree for all of them. I think the
> > security tree already has everything that Al's tree applies in the conflicting
> > areas, it's just that the security tree has further changes parked on top.
> >
> > David
>
> I think David is right, all the conflicts should come from
> security-testing. Al does have other good stuff in his tree though, Al
> do you want to just kick all of my patches out?
They are already gone from later branch...
Anyway, by now the only thing from that tree that is not in mainline or
security tree is s390 patchlet and I'll throw it to s390 folks anyway.
There are additional patches in my local tree and I'll push them tonight,
but that'll be for linux-audit testing. _Then_ they might go to -next;
for now, just drop audit tree from -next.
^ permalink raw reply
* Re: linux-next: Tree for December 10
From: Rafael J. Wysocki @ 2008-12-10 23:53 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, linux-next, linux-kernel, linux-acpi,
Ingo Molnar
In-Reply-To: <20081210145226.8a174e68.akpm@linux-foundation.org>
On Wednesday, 10 of December 2008, Andrew Morton wrote:
> On Wed, 10 Dec 2008 16:46:59 +1100
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > I have created today's linux-next tree at
> > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> > (patches at
> > http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/)
>
> This tree breaks poweroff on my x86_64 test box. `halt -pfn' does all
> the usual things, but the machine doesn't turn off.
>
> config: http://userweb.kernel.org/~akpm/config-akpm2.txt
> dmesg: http://userweb.kernel.org/~akpm/dmesg-akpm2.txt
>
> Any suggestions which don't include the word "bisect" would be most welcome.
Did you suspend-resume the box before that?
^ permalink raw reply
* linux-next: driver-core tree build failure
From: Stephen Rothwell @ 2008-12-11 0:21 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, Kay Sievers
[-- Attachment #1: Type: text/plain, Size: 669 bytes --]
Hi Greg,
Today's linux-next build (x86_64 allmodconfig) failed like this:
drivers/mtd/maps/physmap.c: In function 'physmap_flash_probe':
drivers/mtd/maps/physmap.c:108: error: expected ')' before '{' token
drivers/mtd/maps/physmap.c:144: error: expected expression before '}' token
Caused by commit 7267696c2421503e280d9da5bbdbd5c11e1e5b25 ("mtd: struct
device - replace bus_id with dev_name(), dev_set_name()").
I have reverted that patch for today.
Please be more careful ... allmodconfig is your friend when doing wide
ranging changes ...
--
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: Tree for December 10
From: Andrew Morton @ 2008-12-11 0:38 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Stephen Rothwell, linux-next, linux-kernel, linux-acpi,
Ingo Molnar
In-Reply-To: <200812110053.49012.rjw@sisk.pl>
On Thu, 11 Dec 2008 00:53:48 +0100 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> On Wednesday, 10 of December 2008, Andrew Morton wrote:
> > On Wed, 10 Dec 2008 16:46:59 +1100
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > > I have created today's linux-next tree at
> > > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> > > (patches at
> > > http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/)
> >
> > This tree breaks poweroff on my x86_64 test box. `halt -pfn' does all
> > the usual things, but the machine doesn't turn off.
> >
> > config: http://userweb.kernel.org/~akpm/config-akpm2.txt
> > dmesg: http://userweb.kernel.org/~akpm/dmesg-akpm2.txt
> >
> > Any suggestions which don't include the word "bisect" would be most welcome.
>
> Did you suspend-resume the box before that?
Nope. I've never tried suspend/resume on that machine, actually.
^ permalink raw reply
* Re: [bug?] bio: add experimental support for inlining a number of bio_vecs inside the bio
From: KOSAKI Motohiro @ 2008-12-11 0:39 UTC (permalink / raw)
To: Jens Axboe; +Cc: kosaki.motohiro, Stephen Rothwell, linux-next, LKML
In-Reply-To: <20081210121237.GQ23742@kernel.dk>
> > experimental??
>
> Experimental in the sense that it's the first version, not the concept.
> It's held up well for me, but just yesterday I received the first bug
> report on a ppc platform and now you have this on ia64. Can you pin
> point where in __blk_complete_request() it dies with the NULL pointer
> deref? I'm assuming you don't have CONFIG_FAIL_IO_TIMEOUT set, otherwise
> I don't see how it could fail. So that looks like req->q being NULL,
> which doesn't have much relation to this.
>
> Can you try with slab and pagealloc debugging options switched on? The
> above looks like a side effect of some badness there.
Yes, I don't set CONFIG_FAIL_IO_TIMEOUT.
However, your memory corruption fixing patch solve my problem too.
http://marc.info/?l=linux-kernel&m=122891947725303&w=2
Thanks.
^ permalink raw reply
* linux-next: manual merge of the ftrace tree
From: Stephen Rothwell @ 2008-12-11 0:41 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
Cc: linux-next, Hugh Dickins, Frederic Weisbecker, Steven Rostedt
Hi all,
Today's linux-next merge of the ftrace tree got a conflict in
include/linux/ftrace.h between commit
9c24624727f6d6c460e45762a408ca5f5b9b8ef2 ("KSYM_SYMBOL_LEN fixes") from
Linus' tree and commit 3f5ec13696fd4a33bde42f385406cbb1d3cc96fd
("tracing/fastboot: move boot tracer structs and funcs into their own
header") from the ftrace tree.
The latter moved some code that the former fixed. I fixed it up as best
I could (see below - I used the ftrace tree version of
include/linux/ftrace.h), but it should be checked and a merge with Linus'
tree done to resolve this conflict.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --git a/include/trace/boot.h b/include/trace/boot.h
index 6b54537..3ec58b4 100644
--- a/include/trace/boot.h
+++ b/include/trace/boot.h
@@ -9,7 +9,7 @@
*/
struct boot_trace_call {
pid_t caller;
- char func[KSYM_NAME_LEN];
+ char func[KSYM_SYMBOL_LEN];
};
/*
@@ -17,7 +17,7 @@ struct boot_trace_call {
* while it returns.
*/
struct boot_trace_ret {
- char func[KSYM_NAME_LEN];
+ char func[KSYM_SYMBOL_LEN];
int result;
unsigned long long duration; /* nsecs */
};
^ permalink raw reply related
* linux-next: manual merge of the pci tree
From: Stephen Rothwell @ 2008-12-11 0:53 UTC (permalink / raw)
To: Jesse Barnes; +Cc: linux-next, Rafael J. Wysocki, Greg KH, Roel Kluin
Hi Jesse,
Today's linux-next merge of the pci tree got a conflict in
drivers/pci/pci-driver.c between commit
fc9f864789c8a9e3ce747765f31ee8320bb66b60 ("PM: Simplify the new
suspend/hibernation framework for devices") from the driver-core tree and
commit be74163f1a84d5e5cfecda34232afceef8eb0b93 ("PCI: Make some
functions & structures static") from the pci 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 drivers/pci/pci-driver.c
index 99d867b,20c89a1..0000000
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@@ -681,15 -668,17 +695,15 @@@ static int pci_pm_restore_noirq(struct
#endif /* !CONFIG_HIBERNATION */
- struct dev_pm_ops pci_dev_pm_ops = {
-static struct pm_ext_ops pci_pm_ops = {
- .base = {
- .prepare = pci_pm_prepare,
- .complete = pci_pm_complete,
- .suspend = pci_pm_suspend,
- .resume = pci_pm_resume,
- .freeze = pci_pm_freeze,
- .thaw = pci_pm_thaw,
- .poweroff = pci_pm_poweroff,
- .restore = pci_pm_restore,
- },
++static struct dev_pm_ops pci_dev_pm_ops = {
+ .prepare = pci_pm_prepare,
+ .complete = pci_pm_complete,
+ .suspend = pci_pm_suspend,
+ .resume = pci_pm_resume,
+ .freeze = pci_pm_freeze,
+ .thaw = pci_pm_thaw,
+ .poweroff = pci_pm_poweroff,
+ .restore = pci_pm_restore,
.suspend_noirq = pci_pm_suspend_noirq,
.resume_noirq = pci_pm_resume_noirq,
.freeze_noirq = pci_pm_freeze_noirq,
^ permalink raw reply
* mpt fusion device warning 5 times
From: KOSAKI Motohiro @ 2008-12-11 1:15 UTC (permalink / raw)
To: Eric.Moore, support, DL-MPTFusionLinux, linux-scsi
Cc: kosaki.motohiro, linux-next, LKML, Stephen Rothwell
In-Reply-To: <20081210164659.9ebb8158.sfr@canb.auug.org.au>
Hi Eric,
> Hi all,
>
> Changes since 20081209:
>
> Undropped tree:
> mmc
>
> Dropped trees (temporarily):
> v4l-dvb (build problem)
> sound (build problem)
> drm (build problem)
> semaphore-removal (due to unfixed conflicts against Linus' tree)
> cpu_alloc (build problem)
> perfmon3 (concerns from the x86 team)
> audit (difficult conflicts)
> staging (build failure)
>
> The mtd tree transferred its conflict to the driver-core tree (by being
> merged into Linus' tree).
>
> The sound tree gained a build failure and was dropped.
my ia64 box output following warnings.
The init_timer() expect timer object stay in heap, but the timer of mpt stay in stack.
Is this a real bug?
====================================================
ODEBUG: object is on stack, but not annotated
------------[ cut here ]------------
WARNING: at lib/debugobjects.c:253 __debug_object_init+0x420/0x840()
Modules linked in: mptspi(+) mptscsih mptbase ehci_hcd ohci_hcd uhci_hcd usbcore
Call Trace:
[<a000000100017940>] show_stack+0x80/0xa0
sp=e0000040c30af760 bsp=e0000040c30a1450
[<a000000100017990>] dump_stack+0x30/0x60
sp=e0000040c30af930 bsp=e0000040c30a1438
[<a0000001000a96e0>] warn_slowpath+0x140/0x1a0
sp=e0000040c30af930 bsp=e0000040c30a13c8
[<a0000001003682a0>] __debug_object_init+0x420/0x840
sp=e0000040c30afa60 bsp=e0000040c30a1370
[<a000000100368790>] debug_object_init+0x50/0x80
sp=e0000040c30afa70 bsp=e0000040c30a1348
[<a0000001000c3430>] init_timer+0x30/0x60
sp=e0000040c30afa70 bsp=e0000040c30a1328
[<a000000201a4aa30>] mpt_config+0x390/0x6a0 [mptbase]
sp=e0000040c30afa70 bsp=e0000040c30a12c8
[<a000000201a4d7d0>] mpt_do_ioc_recovery+0x1710/0x2ee0 [mptbase]
sp=e0000040c30afaa0 bsp=e0000040c30a11f0
[<a000000201a52230>] mpt_attach+0x890/0x1f40 [mptbase]
sp=e0000040c30afd70 bsp=e0000040c30a1178
[<a000000201b92650>] mptspi_probe+0x30/0x7e0 [mptspi]
sp=e0000040c30afd80 bsp=e0000040c30a1128
[<a00000010037a770>] local_pci_probe+0x70/0xa0
sp=e0000040c30afd80 bsp=e0000040c30a1108
[<a00000010037b110>] pci_device_probe+0x310/0x360
sp=e0000040c30afd80 bsp=e0000040c30a10d0
[<a00000010046d370>] driver_probe_device+0x190/0x3a0
sp=e0000040c30afde0 bsp=e0000040c30a1088
[<a00000010046d660>] __driver_attach+0xe0/0x140
sp=e0000040c30afde0 bsp=e0000040c30a1050
[<a00000010046b900>] bus_for_each_dev+0xc0/0x140
sp=e0000040c30afde0 bsp=e0000040c30a1018
[<a00000010046cf80>] driver_attach+0x40/0x60
sp=e0000040c30afdf0 bsp=e0000040c30a0ff0
[<a00000010046c930>] bus_add_driver+0x370/0x4a0
sp=e0000040c30afdf0 bsp=e0000040c30a0fa8
[<a00000010046dad0>] driver_register+0xd0/0x340
sp=e0000040c30afdf0 bsp=e0000040c30a0f60
[<a00000010037b640>] __pci_register_driver+0xa0/0x120
sp=e0000040c30afdf0 bsp=e0000040c30a0f28
[<a000000201bd01b0>] mptspi_init+0x1b0/0x300 [mptspi]
sp=e0000040c30afdf0 bsp=e0000040c30a0ef8
[<a00000010000a920>] do_one_initcall+0x60/0x360
sp=e0000040c30afdf0 bsp=e0000040c30a0eb8
[<a000000100107460>] sys_init_module+0x140/0x3c0
sp=e0000040c30afe30 bsp=e0000040c30a0e48
[<a00000010000c6c0>] ia64_ret_from_syscall+0x0/0x20
sp=e0000040c30afe30 bsp=e0000040c30a0e48
[<a000000000010720>] __kernel_syscall_via_break+0x0/0x20
sp=e0000040c30b0000 bsp=e0000040c30a0e48
---[ end trace aef9c69889c77119 ]---
ODEBUG: object is on stack, but not annotated
------------[ cut here ]------------
WARNING: at lib/debugobjects.c:253 __debug_object_init+0x420/0x840()
Modules linked in: mptspi(+) mptscsih mptbase ehci_hcd ohci_hcd uhci_hcd usbcore
Call Trace:
[<a000000100017940>] show_stack+0x80/0xa0
sp=e0000040c30af760 bsp=e0000040c30a1450
[<a000000100017990>] dump_stack+0x30/0x60
sp=e0000040c30af930 bsp=e0000040c30a1438
[<a0000001000a96e0>] warn_slowpath+0x140/0x1a0
sp=e0000040c30af930 bsp=e0000040c30a13c8
[<a0000001003682a0>] __debug_object_init+0x420/0x840
sp=e0000040c30afa60 bsp=e0000040c30a1370
[<a000000100368790>] debug_object_init+0x50/0x80
sp=e0000040c30afa70 bsp=e0000040c30a1348
[<a0000001000c3430>] init_timer+0x30/0x60
sp=e0000040c30afa70 bsp=e0000040c30a1328
[<a000000201a4aa30>] mpt_config+0x390/0x6a0 [mptbase]
sp=e0000040c30afa70 bsp=e0000040c30a12c8
[<a000000201a4dcf0>] mpt_do_ioc_recovery+0x1c30/0x2ee0 [mptbase]
sp=e0000040c30afaa0 bsp=e0000040c30a11f0
[<a000000201a52230>] mpt_attach+0x890/0x1f40 [mptbase]
sp=e0000040c30afd70 bsp=e0000040c30a1178
[<a000000201b92650>] mptspi_probe+0x30/0x7e0 [mptspi]
sp=e0000040c30afd80 bsp=e0000040c30a1128
[<a00000010037a770>] local_pci_probe+0x70/0xa0
sp=e0000040c30afd80 bsp=e0000040c30a1108
[<a00000010037b110>] pci_device_probe+0x310/0x360
sp=e0000040c30afd80 bsp=e0000040c30a10d0
[<a00000010046d370>] driver_probe_device+0x190/0x3a0
sp=e0000040c30afde0 bsp=e0000040c30a1088
[<a00000010046d660>] __driver_attach+0xe0/0x140
sp=e0000040c30afde0 bsp=e0000040c30a1050
[<a00000010046b900>] bus_for_each_dev+0xc0/0x140
sp=e0000040c30afde0 bsp=e0000040c30a1018
[<a00000010046cf80>] driver_attach+0x40/0x60
sp=e0000040c30afdf0 bsp=e0000040c30a0ff0
[<a00000010046c930>] bus_add_driver+0x370/0x4a0
sp=e0000040c30afdf0 bsp=e0000040c30a0fa8
[<a00000010046dad0>] driver_register+0xd0/0x340
sp=e0000040c30afdf0 bsp=e0000040c30a0f60
[<a00000010037b640>] __pci_register_driver+0xa0/0x120
sp=e0000040c30afdf0 bsp=e0000040c30a0f28
[<a000000201bd01b0>] mptspi_init+0x1b0/0x300 [mptspi]
sp=e0000040c30afdf0 bsp=e0000040c30a0ef8
[<a00000010000a920>] do_one_initcall+0x60/0x360
sp=e0000040c30afdf0 bsp=e0000040c30a0eb8
[<a000000100107460>] sys_init_module+0x140/0x3c0
sp=e0000040c30afe30 bsp=e0000040c30a0e48
[<a00000010000c6c0>] ia64_ret_from_syscall+0x0/0x20
sp=e0000040c30afe30 bsp=e0000040c30a0e48
[<a000000000010720>] __kernel_syscall_via_break+0x0/0x20
sp=e0000040c30b0000 bsp=e0000040c30a0e48
---[ end trace aef9c69889c77119 ]---
ODEBUG: object is on stack, but not annotated
------------[ cut here ]------------
WARNING: at lib/debugobjects.c:253 __debug_object_init+0x420/0x840()
Modules linked in: mptspi(+) mptscsih mptbase ehci_hcd ohci_hcd uhci_hcd usbcore
Call Trace:
[<a000000100017940>] show_stack+0x80/0xa0
sp=e0000040c30af760 bsp=e0000040c30a1450
[<a000000100017990>] dump_stack+0x30/0x60
sp=e0000040c30af930 bsp=e0000040c30a1438
[<a0000001000a96e0>] warn_slowpath+0x140/0x1a0
sp=e0000040c30af930 bsp=e0000040c30a13c8
[<a0000001003682a0>] __debug_object_init+0x420/0x840
sp=e0000040c30afa60 bsp=e0000040c30a1370
[<a000000100368790>] debug_object_init+0x50/0x80
sp=e0000040c30afa70 bsp=e0000040c30a1348
[<a0000001000c3430>] init_timer+0x30/0x60
sp=e0000040c30afa70 bsp=e0000040c30a1328
[<a000000201a4aa30>] mpt_config+0x390/0x6a0 [mptbase]
sp=e0000040c30afa70 bsp=e0000040c30a12c8
[<a000000201a4e440>] mpt_do_ioc_recovery+0x2380/0x2ee0 [mptbase]
sp=e0000040c30afaa0 bsp=e0000040c30a11f0
[<a000000201a52230>] mpt_attach+0x890/0x1f40 [mptbase]
sp=e0000040c30afd70 bsp=e0000040c30a1178
[<a000000201b92650>] mptspi_probe+0x30/0x7e0 [mptspi]
sp=e0000040c30afd80 bsp=e0000040c30a1128
[<a00000010037a770>] local_pci_probe+0x70/0xa0
sp=e0000040c30afd80 bsp=e0000040c30a1108
[<a00000010037b110>] pci_device_probe+0x310/0x360
sp=e0000040c30afd80 bsp=e0000040c30a10d0
[<a00000010046d370>] driver_probe_device+0x190/0x3a0
sp=e0000040c30afde0 bsp=e0000040c30a1088
[<a00000010046d660>] __driver_attach+0xe0/0x140
sp=e0000040c30afde0 bsp=e0000040c30a1050
[<a00000010046b900>] bus_for_each_dev+0xc0/0x140
sp=e0000040c30afde0 bsp=e0000040c30a1018
[<a00000010046cf80>] driver_attach+0x40/0x60
sp=e0000040c30afdf0 bsp=e0000040c30a0ff0
[<a00000010046c930>] bus_add_driver+0x370/0x4a0
sp=e0000040c30afdf0 bsp=e0000040c30a0fa8
[<a00000010046dad0>] driver_register+0xd0/0x340
sp=e0000040c30afdf0 bsp=e0000040c30a0f60
[<a00000010037b640>] __pci_register_driver+0xa0/0x120
sp=e0000040c30afdf0 bsp=e0000040c30a0f28
[<a000000201bd01b0>] mptspi_init+0x1b0/0x300 [mptspi]
sp=e0000040c30afdf0 bsp=e0000040c30a0ef8
[<a00000010000a920>] do_one_initcall+0x60/0x360
sp=e0000040c30afdf0 bsp=e0000040c30a0eb8
[<a000000100107460>] sys_init_module+0x140/0x3c0
sp=e0000040c30afe30 bsp=e0000040c30a0e48
[<a00000010000c6c0>] ia64_ret_from_syscall+0x0/0x20
sp=e0000040c30afe30 bsp=e0000040c30a0e48
[<a000000000010720>] __kernel_syscall_via_break+0x0/0x20
sp=e0000040c30b0000 bsp=e0000040c30a0e48
---[ end trace aef9c69889c77119 ]---
ODEBUG: object is on stack, but not annotated
------------[ cut here ]------------
WARNING: at lib/debugobjects.c:253 __debug_object_init+0x420/0x840()
Modules linked in: mptspi(+) mptscsih mptbase ehci_hcd ohci_hcd uhci_hcd usbcore
Call Trace:
[<a000000100017940>] show_stack+0x80/0xa0
sp=e0000040c30af760 bsp=e0000040c30a1450
[<a000000100017990>] dump_stack+0x30/0x60
sp=e0000040c30af930 bsp=e0000040c30a1438
[<a0000001000a96e0>] warn_slowpath+0x140/0x1a0
sp=e0000040c30af930 bsp=e0000040c30a13c8
[<a0000001003682a0>] __debug_object_init+0x420/0x840
sp=e0000040c30afa60 bsp=e0000040c30a1370
[<a000000100368790>] debug_object_init+0x50/0x80
sp=e0000040c30afa70 bsp=e0000040c30a1348
[<a0000001000c3430>] init_timer+0x30/0x60
sp=e0000040c30afa70 bsp=e0000040c30a1328
[<a000000201a4aa30>] mpt_config+0x390/0x6a0 [mptbase]
sp=e0000040c30afa70 bsp=e0000040c30a12c8
[<a000000201a4dfb0>] mpt_do_ioc_recovery+0x1ef0/0x2ee0 [mptbase]
sp=e0000040c30afaa0 bsp=e0000040c30a11f0
[<a000000201a52230>] mpt_attach+0x890/0x1f40 [mptbase]
sp=e0000040c30afd70 bsp=e0000040c30a1178
[<a000000201b92650>] mptspi_probe+0x30/0x7e0 [mptspi]
sp=e0000040c30afd80 bsp=e0000040c30a1128
[<a00000010037a770>] local_pci_probe+0x70/0xa0
sp=e0000040c30afd80 bsp=e0000040c30a1108
[<a00000010037b110>] pci_device_probe+0x310/0x360
sp=e0000040c30afd80 bsp=e0000040c30a10d0
[<a00000010046d370>] driver_probe_device+0x190/0x3a0
sp=e0000040c30afde0 bsp=e0000040c30a1088
[<a00000010046d660>] __driver_attach+0xe0/0x140
sp=e0000040c30afde0 bsp=e0000040c30a1050
[<a00000010046b900>] bus_for_each_dev+0xc0/0x140
sp=e0000040c30afde0 bsp=e0000040c30a1018
[<a00000010046cf80>] driver_attach+0x40/0x60
sp=e0000040c30afdf0 bsp=e0000040c30a0ff0
[<a00000010046c930>] bus_add_driver+0x370/0x4a0
sp=e0000040c30afdf0 bsp=e0000040c30a0fa8
[<a00000010046dad0>] driver_register+0xd0/0x340
sp=e0000040c30afdf0 bsp=e0000040c30a0f60
[<a00000010037b640>] __pci_register_driver+0xa0/0x120
sp=e0000040c30afdf0 bsp=e0000040c30a0f28
[<a000000201bd01b0>] mptspi_init+0x1b0/0x300 [mptspi]
sp=e0000040c30afdf0 bsp=e0000040c30a0ef8
[<a00000010000a920>] do_one_initcall+0x60/0x360
sp=e0000040c30afdf0 bsp=e0000040c30a0eb8
[<a000000100107460>] sys_init_module+0x140/0x3c0
sp=e0000040c30afe30 bsp=e0000040c30a0e48
[<a00000010000c6c0>] ia64_ret_from_syscall+0x0/0x20
sp=e0000040c30afe30 bsp=e0000040c30a0e48
[<a000000000010720>] __kernel_syscall_via_break+0x0/0x20
sp=e0000040c30b0000 bsp=e0000040c30a0e48
---[ end trace aef9c69889c77119 ]---
ODEBUG: object is on stack, but not annotated
------------[ cut here ]------------
WARNING: at lib/debugobjects.c:253 __debug_object_init+0x420/0x840()
Modules linked in: mptspi(+) mptscsih mptbase ehci_hcd ohci_hcd uhci_hcd usbcore
Call Trace:
[<a000000100017940>] show_stack+0x80/0xa0
sp=e0000040c30af760 bsp=e0000040c30a1450
[<a000000100017990>] dump_stack+0x30/0x60
sp=e0000040c30af930 bsp=e0000040c30a1438
[<a0000001000a96e0>] warn_slowpath+0x140/0x1a0
sp=e0000040c30af930 bsp=e0000040c30a13c8
[<a0000001003682a0>] __debug_object_init+0x420/0x840
sp=e0000040c30afa60 bsp=e0000040c30a1370
[<a000000100368790>] debug_object_init+0x50/0x80
sp=e0000040c30afa70 bsp=e0000040c30a1348
[<a0000001000c3430>] init_timer+0x30/0x60
sp=e0000040c30afa70 bsp=e0000040c30a1328
[<a000000201a4aa30>] mpt_config+0x390/0x6a0 [mptbase]
sp=e0000040c30afa70 bsp=e0000040c30a12c8
[<a000000201a4cfb0>] mpt_do_ioc_recovery+0xef0/0x2ee0 [mptbase]
sp=e0000040c30afaa0 bsp=e0000040c30a11f0
[<a000000201a52230>] mpt_attach+0x890/0x1f40 [mptbase]
sp=e0000040c30afd70 bsp=e0000040c30a1178
[<a000000201b92650>] mptspi_probe+0x30/0x7e0 [mptspi]
sp=e0000040c30afd80 bsp=e0000040c30a1128
[<a00000010037a770>] local_pci_probe+0x70/0xa0
sp=e0000040c30afd80 bsp=e0000040c30a1108
[<a00000010037b110>] pci_device_probe+0x310/0x360
sp=e0000040c30afd80 bsp=e0000040c30a10d0
[<a00000010046d370>] driver_probe_device+0x190/0x3a0
sp=e0000040c30afde0 bsp=e0000040c30a1088
[<a00000010046d660>] __driver_attach+0xe0/0x140
sp=e0000040c30afde0 bsp=e0000040c30a1050
[<a00000010046b900>] bus_for_each_dev+0xc0/0x140
sp=e0000040c30afde0 bsp=e0000040c30a1018
[<a00000010046cf80>] driver_attach+0x40/0x60
sp=e0000040c30afdf0 bsp=e0000040c30a0ff0
[<a00000010046c930>] bus_add_driver+0x370/0x4a0
sp=e0000040c30afdf0 bsp=e0000040c30a0fa8
[<a00000010046dad0>] driver_register+0xd0/0x340
sp=e0000040c30afdf0 bsp=e0000040c30a0f60
[<a00000010037b640>] __pci_register_driver+0xa0/0x120
sp=e0000040c30afdf0 bsp=e0000040c30a0f28
[<a000000201bd01b0>] mptspi_init+0x1b0/0x300 [mptspi]
sp=e0000040c30afdf0 bsp=e0000040c30a0ef8
[<a00000010000a920>] do_one_initcall+0x60/0x360
sp=e0000040c30afdf0 bsp=e0000040c30a0eb8
[<a000000100107460>] sys_init_module+0x140/0x3c0
sp=e0000040c30afe30 bsp=e0000040c30a0e48
[<a00000010000c6c0>] ia64_ret_from_syscall+0x0/0x20
sp=e0000040c30afe30 bsp=e0000040c30a0e48
[<a000000000010720>] __kernel_syscall_via_break+0x0/0x20
sp=e0000040c30b0000 bsp=e0000040c30a0e48
---[ end trace aef9c69889c77119 ]---
========================================
if it is merely wrong annotation problem (I think so), fixing patch is here.
=====
Subject: [PATCH] mpt: timer annotaion fix in mpt_config()
The mpt_config() call to init_timer(), not init_tiemr_on_stack().
but all caller of the mpt_config() create a timer object on stack.
Then, if CONFIG_DEBUG_OBJECTS=y, kernel output following warning at boot time.
ODEBUG: object is on stack, but not annotated
------------[ cut here ]------------
WARNING: at lib/debugobjects.c:253 __debug_object_init+0x420/0x840()
Modules linked in: mptspi(+) mptscsih mptbase ehci_hcd ohci_hcd uhci_hcd usbcore
Call Trace:
[<a000000100017940>] show_stack+0x80/0xa0
sp=e0000040c30af760 bsp=e0000040c30a1450
[<a000000100017990>] dump_stack+0x30/0x60
sp=e0000040c30af930 bsp=e0000040c30a1438
[<a0000001000a96e0>] warn_slowpath+0x140/0x1a0
sp=e0000040c30af930 bsp=e0000040c30a13c8
[<a0000001003682a0>] __debug_object_init+0x420/0x840
sp=e0000040c30afa60 bsp=e0000040c30a1370
[<a000000100368790>] debug_object_init+0x50/0x80
sp=e0000040c30afa70 bsp=e0000040c30a1348
[<a0000001000c3430>] init_timer+0x30/0x60
sp=e0000040c30afa70 bsp=e0000040c30a1328
[<a000000201a4aa30>] mpt_config+0x390/0x6a0 [mptbase]
sp=e0000040c30afa70 bsp=e0000040c30a12c8
[<a000000201a4cfb0>] mpt_do_ioc_recovery+0xef0/0x2ee0 [mptbase]
sp=e0000040c30afaa0 bsp=e0000040c30a11f0
[<a000000201a52230>] mpt_attach+0x890/0x1f40 [mptbase]
sp=e0000040c30afd70 bsp=e0000040c30a1178
[<a000000201b92650>] mptspi_probe+0x30/0x7e0 [mptspi]
sp=e0000040c30afd80 bsp=e0000040c30a1128
[<a00000010037a770>] local_pci_probe+0x70/0xa0
sp=e0000040c30afd80 bsp=e0000040c30a1108
[<a00000010037b110>] pci_device_probe+0x310/0x360
sp=e0000040c30afd80 bsp=e0000040c30a10d0
[<a00000010046d370>] driver_probe_device+0x190/0x3a0
sp=e0000040c30afde0 bsp=e0000040c30a1088
[<a00000010046d660>] __driver_attach+0xe0/0x140
sp=e0000040c30afde0 bsp=e0000040c30a1050
[<a00000010046b900>] bus_for_each_dev+0xc0/0x140
sp=e0000040c30afde0 bsp=e0000040c30a1018
[<a00000010046cf80>] driver_attach+0x40/0x60
sp=e0000040c30afdf0 bsp=e0000040c30a0ff0
[<a00000010046c930>] bus_add_driver+0x370/0x4a0
sp=e0000040c30afdf0 bsp=e0000040c30a0fa8
[<a00000010046dad0>] driver_register+0xd0/0x340
sp=e0000040c30afdf0 bsp=e0000040c30a0f60
[<a00000010037b640>] __pci_register_driver+0xa0/0x120
sp=e0000040c30afdf0 bsp=e0000040c30a0f28
[<a000000201bd01b0>] mptspi_init+0x1b0/0x300 [mptspi]
sp=e0000040c30afdf0 bsp=e0000040c30a0ef8
[<a00000010000a920>] do_one_initcall+0x60/0x360
sp=e0000040c30afdf0 bsp=e0000040c30a0eb8
[<a000000100107460>] sys_init_module+0x140/0x3c0
sp=e0000040c30afe30 bsp=e0000040c30a0e48
[<a00000010000c6c0>] ia64_ret_from_syscall+0x0/0x20
sp=e0000040c30afe30 bsp=e0000040c30a0e48
[<a000000000010720>] __kernel_syscall_via_break+0x0/0x20
sp=e0000040c30b0000 bsp=e0000040c30a0e48
---[ end trace aef9c69889c77119 ]---
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
---
drivers/message/fusion/mptbase.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/message/fusion/mptbase.c
===================================================================
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -5902,7 +5902,7 @@ mpt_config(MPT_ADAPTER *ioc, CONFIGPARMS
/* Initalize the timer
*/
- init_timer(&pCfg->timer);
+ init_timer_on_stack(&pCfg->timer);
pCfg->timer.data = (unsigned long) ioc;
pCfg->timer.function = mpt_timer_expired;
pCfg->wait_done = 0;
^ permalink raw reply
* Re: linux-next: manual merge of the ftrace tree
From: Frédéric Weisbecker @ 2008-12-11 1:23 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next,
Hugh Dickins, Steven Rostedt
In-Reply-To: <20081211114154.5d420ff5.sfr@canb.auug.org.au>
Hi Stephen,
2008/12/11 Stephen Rothwell <sfr@canb.auug.org.au>:
> Hi all,
>
> Today's linux-next merge of the ftrace tree got a conflict in
> include/linux/ftrace.h between commit
> 9c24624727f6d6c460e45762a408ca5f5b9b8ef2 ("KSYM_SYMBOL_LEN fixes") from
> Linus' tree and commit 3f5ec13696fd4a33bde42f385406cbb1d3cc96fd
> ("tracing/fastboot: move boot tracer structs and funcs into their own
> header") from the ftrace tree.
>
> The latter moved some code that the former fixed. I fixed it up as best
> I could (see below - I used the ftrace tree version of
> include/linux/ftrace.h), but it should be checked and a merge with Linus'
> tree done to resolve this conflict.
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>
> diff --git a/include/trace/boot.h b/include/trace/boot.h
> index 6b54537..3ec58b4 100644
> --- a/include/trace/boot.h
> +++ b/include/trace/boot.h
> @@ -9,7 +9,7 @@
> */
> struct boot_trace_call {
> pid_t caller;
> - char func[KSYM_NAME_LEN];
> + char func[KSYM_SYMBOL_LEN];
> };
>
> /*
> @@ -17,7 +17,7 @@ struct boot_trace_call {
> * while it returns.
> */
> struct boot_trace_ret {
> - char func[KSYM_NAME_LEN];
> + char func[KSYM_SYMBOL_LEN];
> int result;
> unsigned long long duration; /* nsecs */
> };
>
Yes that's the right fix. The headers for the boot tracer have moved
for 2.6.29 merge window and the fix
should follow this move. If you agree, I will submit your patch to
latest -tip with the right "from " and
"signed-off-by" tags....
^ permalink raw reply
* Re: netfilter: xt_NFLOG is dependant of nfnetlink_log
From: David Miller @ 2008-12-11 1:24 UTC (permalink / raw)
To: eric
Cc: kamalesh, randy.dunlap, sfr, netdev, linux-next, linux-kernel,
netfilter-devel, kaber
In-Reply-To: <1228934957-11967-1-git-send-email-eric@inl.fr>
From: Eric Leblond <eric@inl.fr>
Date: Wed, 10 Dec 2008 19:49:17 +0100
> The patch "don't call nf_log_packet in NFLOG module" make xt_NFLOG
> dependant of nfnetlink_log. This patch forces the dependencies to fix
> compilation in case only xt_NFLOG compilation was asked and modifies the
> help message accordingly to the change.
>
> Signed-off-by: Eric Leblond <eric@inl.fr>
I've applied this to net-next-2.6, thanks Eric.
^ permalink raw reply
* [PATCH] cpumask:cpumask_of_node-ia64 fix
From: KOSAKI Motohiro @ 2008-12-11 1:58 UTC (permalink / raw)
To: Luck, Tony, Rusty Russell
Cc: kosaki.motohiro, linux-next, LKML, Stephen Rothwell
In-Reply-To: <20081210164659.9ebb8158.sfr@canb.auug.org.au>
===
Subject: [PATCH] cpumask:cpumask_of_node-ia64 fix
Impact: bug fix
commit 07c636deede53ff3e96d54df0ece2c838e61951f introduce new CPU mask API and change cpu_mask variable type.
-----------------------------------------------
- cpumask_t cpu_mask;
+ const struct cpumask *cpu_mask;
--------------------------------------------------
However, its change is incomplete. in build time, compiler output following type mismatch warnings.
arch/ia64/kernel/iosapic.c:708: warning: passing argument 2 of '__cpu_clear' from incompatible pointer type
arch/ia64/kernel/iosapic.c:711: warning: passing argument 1 of '__cpus_weight' from incompatible pointer type
arch/ia64/kernel/iosapic.c:719: warning: passing argument 1 of '__first_cpu' from incompatible pointer type
arch/ia64/kernel/iosapic.c:720: warning: passing argument 2 of '__next_cpu' from incompatible pointer type
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
CC: "Luck, Tony" <tony.luck@intel.com>
CC: Rusty Russell <rusty@rustcorp.com.au>
---
arch/ia64/kernel/iosapic.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
Index: b/arch/ia64/kernel/iosapic.c
===================================================================
--- a/arch/ia64/kernel/iosapic.c
+++ b/arch/ia64/kernel/iosapic.c
@@ -695,7 +695,7 @@ get_target_cpu (unsigned int gsi, int ir
#ifdef CONFIG_NUMA
{
int num_cpus, cpu_index, iosapic_index, numa_cpu, i = 0;
- const struct cpumask *cpu_mask;
+ struct cpumask *cpu_mask;
iosapic_index = find_iosapic(gsi);
if (iosapic_index < 0 ||
@@ -705,10 +705,10 @@ get_target_cpu (unsigned int gsi, int ir
cpu_mask = cpumask_of_node(iosapic_lists[iosapic_index].node);
for_each_cpu_and(numa_cpu, cpu_mask, &domain) {
if (!cpu_online(numa_cpu))
- cpu_clear(numa_cpu, cpu_mask);
+ cpu_clear(numa_cpu, *cpu_mask);
}
- num_cpus = cpus_weight(cpu_mask);
+ num_cpus = cpus_weight(*cpu_mask);
if (!num_cpus)
goto skip_numa_setup;
@@ -716,8 +716,8 @@ get_target_cpu (unsigned int gsi, int ir
/* Use irq assignment to distribute across cpus in node */
cpu_index = irq % num_cpus;
- for (numa_cpu = first_cpu(cpu_mask) ; i < cpu_index ; i++)
- numa_cpu = next_cpu(numa_cpu, cpu_mask);
+ for (numa_cpu = first_cpu(*cpu_mask) ; i < cpu_index ; i++)
+ numa_cpu = next_cpu(numa_cpu, *cpu_mask);
if (numa_cpu != NR_CPUS)
return cpu_physical_id(numa_cpu);
^ permalink raw reply
* Re: linux-next: manual merge of the ftrace tree
From: Stephen Rothwell @ 2008-12-11 2:07 UTC (permalink / raw)
To: "Frédéric Weisbecker"
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next,
Hugh Dickins, Steven Rostedt
In-Reply-To: <c62985530812101723u66dd1662x279ff15fa741e8e5@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 570 bytes --]
Hi Frédéric,
On Thu, 11 Dec 2008 02:23:57 +0100 "Frédéric Weisbecker" <fweisbec@gmail.com> wrote:
>
> Yes that's the right fix. The headers for the boot tracer have moved
> for 2.6.29 merge window and the fix
> should follow this move. If you agree, I will submit your patch to
> latest -tip with the right "from " and
> "signed-off-by" tags....
Thanks, that would save me carrying it.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
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: scsi tree build warnings
From: Stephen Rothwell @ 2008-12-11 2:25 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-next, James Smart
[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]
Hi James,
Today's linux-next build (powerpc ppc64_defconfig) produced these
warnings:
drivers/scsi/lpfc/lpfc_scsi.c: In function 'lpfc_parse_bg_err':
drivers/scsi/lpfc/lpfc_scsi.c:1319: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'sector_t'
drivers/scsi/lpfc/lpfc_scsi.c: In function 'lpfc_queuecommand':
drivers/scsi/lpfc/lpfc_scsi.c:2376: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'sector_t'
drivers/scsi/lpfc/lpfc_scsi.c:2382: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'sector_t'
drivers/scsi/lpfc/lpfc_scsi.c:2404: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'sector_t'
drivers/scsi/lpfc/lpfc_scsi.c:2409: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'sector_t'
drivers/scsi/lpfc/lpfc_attr.c: In function 'lpfc_bg_guard_err_show':
drivers/scsi/lpfc/lpfc_attr.c:126: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'uint64_t'
drivers/scsi/lpfc/lpfc_attr.c: In function 'lpfc_bg_apptag_err_show':
drivers/scsi/lpfc/lpfc_attr.c:137: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'uint64_t'
drivers/scsi/lpfc/lpfc_attr.c: In function 'lpfc_bg_reftag_err_show':
drivers/scsi/lpfc/lpfc_attr.c:148: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'uint64_t'
Introduced by commit 46c6a5eabb0284b10c0377bd78c04edcb4163ee0 ("[SCSI] lpfc 8.3.0 : Add BlockGuard support (T10-DIF) code").
I guess sector_t and uint64_t should be cast to "unsigned long long"
for printing as u64 is "unsigned long" on some architectures and
"unsigned long long" on others.
--
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: manual merge of the mtd tree
From: Stephen Rothwell @ 2008-12-11 2:43 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-next, Dmitry Baryshkov, Eric Miao, Russell King
[-- Attachment #1: Type: text/plain, Size: 882 bytes --]
Hi David,
Today's linux-next merge of the mtd tree got conflicts in
arch/arm/mach-pxa/corgi.c, arch/arm/mach-pxa/poodle.c and
arch/arm/mach-pxa/spitz.c between commits
4a9295ccb43ead9ec054d0bd374c992c692b2cf4 ("[ARM] pxa/corgi: add physmap
mapping for ROM"), 431a2cff07446b0325ec063e5b401ca7c11e0058 ("[ARM]
pxa/poodle: add physmap mapping for ROM") and
e5d3bf3c106c0557199076a57800adb85206c1ce ("[ARM] pxa/spitz: add physmap
mapping for ROM") from the arm tree and commit
6af7a8eb1eb2b5a0967fccf61e750b085d60ad48 ("[MTD] sharpsl-nand: move
registration to board code") from the mtd tree.
They seem to be overlapping changes. Can you guys rationalise this,
please, as I am in no position to fix these conflicts up.
I have dropped the mtd tree 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
* Re: [linux-next][PATCH] cpumask:cpumask_of_node-ia64 fix
From: KOSAKI Motohiro @ 2008-12-11 4:09 UTC (permalink / raw)
To: linux-ia64
Cc: kosaki.motohiro, Luck, Tony, Rusty Russell, linux-next, LKML,
Stephen Rothwell
In-Reply-To: <20081211105721.4FEE.KOSAKI.MOTOHIRO@jp.fujitsu.com>
Oops, sorry.
I forgot cc to linux-ia64.
> ===
> Subject: [PATCH] cpumask:cpumask_of_node-ia64 fix
> Impact: bug fix
>
> commit 07c636deede53ff3e96d54df0ece2c838e61951f introduce new CPU mask API and change cpu_mask variable type.
>
> -----------------------------------------------
> - cpumask_t cpu_mask;
> + const struct cpumask *cpu_mask;
> --------------------------------------------------
>
>
> However, its change is incomplete. in build time, compiler output following type mismatch warnings.
>
> arch/ia64/kernel/iosapic.c:708: warning: passing argument 2 of '__cpu_clear' from incompatible pointer type
> arch/ia64/kernel/iosapic.c:711: warning: passing argument 1 of '__cpus_weight' from incompatible pointer type
> arch/ia64/kernel/iosapic.c:719: warning: passing argument 1 of '__first_cpu' from incompatible pointer type
> arch/ia64/kernel/iosapic.c:720: warning: passing argument 2 of '__next_cpu' from incompatible pointer type
>
>
> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> CC: "Luck, Tony" <tony.luck@intel.com>
> CC: Rusty Russell <rusty@rustcorp.com.au>
> ---
> arch/ia64/kernel/iosapic.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> Index: b/arch/ia64/kernel/iosapic.c
> ===================================================================
> --- a/arch/ia64/kernel/iosapic.c
> +++ b/arch/ia64/kernel/iosapic.c
> @@ -695,7 +695,7 @@ get_target_cpu (unsigned int gsi, int ir
> #ifdef CONFIG_NUMA
> {
> int num_cpus, cpu_index, iosapic_index, numa_cpu, i = 0;
> - const struct cpumask *cpu_mask;
> + struct cpumask *cpu_mask;
>
> iosapic_index = find_iosapic(gsi);
> if (iosapic_index < 0 ||
> @@ -705,10 +705,10 @@ get_target_cpu (unsigned int gsi, int ir
> cpu_mask = cpumask_of_node(iosapic_lists[iosapic_index].node);
> for_each_cpu_and(numa_cpu, cpu_mask, &domain) {
> if (!cpu_online(numa_cpu))
> - cpu_clear(numa_cpu, cpu_mask);
> + cpu_clear(numa_cpu, *cpu_mask);
> }
>
> - num_cpus = cpus_weight(cpu_mask);
> + num_cpus = cpus_weight(*cpu_mask);
>
> if (!num_cpus)
> goto skip_numa_setup;
> @@ -716,8 +716,8 @@ get_target_cpu (unsigned int gsi, int ir
> /* Use irq assignment to distribute across cpus in node */
> cpu_index = irq % num_cpus;
>
> - for (numa_cpu = first_cpu(cpu_mask) ; i < cpu_index ; i++)
> - numa_cpu = next_cpu(numa_cpu, cpu_mask);
> + for (numa_cpu = first_cpu(*cpu_mask) ; i < cpu_index ; i++)
> + numa_cpu = next_cpu(numa_cpu, *cpu_mask);
>
> if (numa_cpu != NR_CPUS)
> return cpu_physical_id(numa_cpu);
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ 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