* Re: [GIT PULL] tracing: Syscalls trace events + perf support
From: Ingo Molnar @ 2009-08-18 7:32 UTC (permalink / raw)
To: Paul Mundt, Stephen Rothwell, Jason Baron, Frederic Weisbecker,
LKML
In-Reply-To: <20090818004654.GA4402@linux-sh.org>
* Paul Mundt <lethal@linux-sh.org> wrote:
> [ Adding to Cc everyone that now has a broken tree thanks to this .. ]
>
> On Wed, Aug 12, 2009 at 11:11:33AM +0200, Ingo Molnar wrote:
> > * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > > This pull request integrate one cleanup/fix for ftrace and an
> > > update for syscall tracing: the migration from old-style tracer to
> > > individual tracepoints/trace_events and the support for perf
> > > counter.
> > >
> > > I've tested it with success either with ftrace (every syscall
> > > tracepoints enabled at the same time without problems) and with
> > > perfcounter.
> > >
> > > May be one drawback: it creates so much trace events that the
> > > ftrace selftests can take some time :-)
> >
> > Pulled, thanks a lot!
>
> And this has now subsequently broken every single SH and S390
> configuration, [...]
I test SH cross-builds regularly. I just checked the SH defconfig
and it builds just fine here:
$ make -j32 CROSS_COMPILE=sh3-linux- ARCH=sh vmlinux
...
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
KSYM .tmp_kallsyms1.S
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux
SYSMAP System.map
SYSMAP .tmp_System.map
phoenix:~/linux/linux> head .config
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.31-rc6
# Tue Aug 18 09:24:28 2009
#
CONFIG_SUPERH=y
CONFIG_SUPERH32=y
# CONFIG_SUPERH64 is not set
CONFIG_ARCH_DEFCONFIG="arch/sh/configs/shx3_defconfig"
AFAICS SH does not even have any syscall tracing added upstream.
Apparently you added them in the SH tree and then they got
integrated in linux-next, and the integrated end result broke?
Mind putting those bits into a separate Git branch and sending them
to the tracing tree too so that we can make sure it's properly
integrated and tested and that any changes to the generic facility
are propagated to SH too?
Thanks,
Ingo
^ permalink raw reply
* Re: linux-next: manual merge of the xfs tree with Linus' tree
From: Stephen Rothwell @ 2009-08-18 7:17 UTC (permalink / raw)
To: Felix Blyakher
Cc: David Chinner, xfs-masters, linux-next, linux-kernel,
Eric Sandeen, Christoph Hellwig
In-Reply-To: <523385BE-5397-49A3-A158-FD1B9D12F067@sgi.com>
[-- Attachment #1: Type: text/plain, Size: 483 bytes --]
Hi Felix,
On Tue, 18 Aug 2009 01:49:52 -0500 Felix Blyakher <felixb@sgi.com> wrote:
>
> Thanks for the fix, but there is no need to carrying it separately
> from the xfs master tree. I merged the bc990f5 commit back into the
> the master tree, and fixed all conflicts (there was another one in
> fs/xfs/xfs_iget.c). I planned to do it anyway for 2.6.32.
Thanks.
--
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 xfs tree with Linus' tree
From: Felix Blyakher @ 2009-08-18 6:49 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Chinner, xfs-masters, linux-next, linux-kernel,
Eric Sandeen, Christoph Hellwig
In-Reply-To: <20090818101215.aba4d0bf.sfr@canb.auug.org.au>
On Aug 17, 2009, at 7:12 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xfs tree got a conflict in
> fs/xfs/linux-2.6/xfs_sync.h between commit
> bc990f5cb424cdca9dda866785d088e2c2110ecc ("xfs: fix locking in
> xfs_iget_cache_hit") from Linus' tree and commit
> 370f048214b4e9aa2102fa3c454ae1374da287c5 ("xfs: add more statics &
> drop
> some unused functions") from the xfs tree.
Sorry, I didn't realize that there is a merge between linux-next,
which uses the xfs master tree, and the Linus' tree.
> Just context changes (add/remove). I fixed it up (see below) and can
> carry the fix as necessary.
Thanks for the fix, but there is no need to carrying it separately
from the xfs master tree. I merged the bc990f5 commit back into the
the master tree, and fixed all conflicts (there was another one in
fs/xfs/xfs_iget.c). I planned to do it anyway for 2.6.32.
Thanks,
Felix
>
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
>
> diff --cc fs/xfs/linux-2.6/xfs_sync.h
> index 5912060,23e7e7e..0000000
> --- a/fs/xfs/linux-2.6/xfs_sync.h
> +++ b/fs/xfs/linux-2.6/xfs_sync.h
> @@@ -48,8 -48,6 +48,7 @@@ int xfs_reclaim_inode(struct xfs_inode
> int xfs_reclaim_inodes(struct xfs_mount *mp, int mode);
>
> void xfs_inode_set_reclaim_tag(struct xfs_inode *ip);
> +void __xfs_inode_set_reclaim_tag(struct xfs_perag *pag, struct
> xfs_inode *ip);
> - void xfs_inode_clear_reclaim_tag(struct xfs_inode *ip);
> void __xfs_inode_clear_reclaim_tag(struct xfs_mount *mp, struct
> xfs_perag *pag,
> struct xfs_inode *ip);
>
^ permalink raw reply
* Re: linux-next: drbd tree build failure
From: Martin K. Petersen @ 2009-08-18 6:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Martin K. Petersen, Philipp Reisner, linux-next, linux-kernel,
Jens Axboe
In-Reply-To: <20090818153250.5ce293b5.sfr@canb.auug.org.au>
>>>>> "Stephen" == Stephen Rothwell <sfr@canb.auug.org.au> writes:
>> We've decided to keep blk_queue_stack_limits as a wrapper to ease the
>> transition. I sent Jens a patch earlier today that does this.
Stephen> I am still getting this error (3 weeks later) ... :-(
Jens applied it to for-linus and it's been upstream for a while. But it
looks like the block for-next tree has stale bits...
Jens?
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: linux-next: drbd tree build failure
From: Stephen Rothwell @ 2009-08-18 5:32 UTC (permalink / raw)
To: Martin K. Petersen; +Cc: Philipp Reisner, linux-next, linux-kernel, Jens Axboe
In-Reply-To: <yq1prbk59bv.fsf@sermon.lab.mkp.net>
[-- Attachment #1: Type: text/plain, Size: 778 bytes --]
Hi Martin, Jens,
On Wed, 29 Jul 2009 01:47:48 -0400 "Martin K. Petersen" <martin.petersen@oracle.com> wrote:
>
> >>>>> "Stephen" == Stephen Rothwell <sfr@canb.auug.org.au> writes:
>
> Stephen> drivers/block/drbd/drbd_nl.c: In function
> Stephen> 'drbd_setup_queue_param': drivers/block/drbd/drbd_nl.c:707:
> Stephen> error: implicit declaration of function
> Stephen> 'blk_queue_stack_limits'
>
> We've decided to keep blk_queue_stack_limits as a wrapper to ease the
> transition. I sent Jens a patch earlier today that does this.
I am still getting this error (3 weeks later) ... :-(
Maybe my original patch should be applied to the drbd 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
* linux-next: manual merge of the fsnotify tree with Linus' tree
From: Stephen Rothwell @ 2009-08-18 5:17 UTC (permalink / raw)
To: Eric Paris; +Cc: linux-next, linux-kernel
Hi Eric,
Today's linux-next merge of the fsnotify tree got conflicts in
fs/notify/inotify/inotify_fsnotify.c, fs/notify/inotify/inotify_user.c
and fs/notify/notification.c between commits
eef3a116be11d35396efb2a8cc7345fd3221e294 ("notify: unused event private
race") and cd94c8bbef8d4b796a7ed4c551355a334604fd36 ("inotify: tail drop
inotify q_overflow events") from Linus' tree and commits
7bf357aac07084acfac5f0e746aca85c42cc046e ("fsnotify: use
fsnotify_create_event to allocate the q_overflow event"),
cddf930f6410692ba1db0c53753492d119b1bd55 ("fsnotify: allow notification
requests to not include private data") and
7f51531a261beb6be2071f4345482ac488eea734 ("fsnotify: per group
notification queue merge types") from the fsnotify tree.
I fixed it up as best I can (see below) and can carry the fixes as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc fs/notify/inotify/inotify_fsnotify.c
index 5dcbafe,133f080..0000000
--- a/fs/notify/inotify/inotify_fsnotify.c
+++ b/fs/notify/inotify/inotify_fsnotify.c
@@@ -31,6 -31,56 +31,60 @@@
#include "inotify.h"
+ /*
+ * Check if 2 events contain the same information. We do not compare private data
+ * but at this moment that isn't a problem for any know fsnotify listeners.
+ */
+ static bool event_compare(struct fsnotify_event *old, struct fsnotify_event *new)
+ {
+ if ((old->mask == new->mask) &&
+ (old->to_tell == new->to_tell) &&
+ (old->data_type == new->data_type) &&
+ (old->name_len == new->name_len)) {
+ switch (old->data_type) {
+ case (FSNOTIFY_EVENT_INODE):
+ /* remember, after old was put on the wait_q we aren't
+ * allowed to look at the inode any more, only thing
+ * left to check was if the file_name is the same */
+ if (old->name_len &&
+ !strcmp(old->file_name, new->file_name))
+ return true;
+ break;
+ case (FSNOTIFY_EVENT_PATH):
+ if ((old->path.mnt == new->path.mnt) &&
+ (old->path.dentry == new->path.dentry))
+ return true;
+ break;
+ case (FSNOTIFY_EVENT_NONE):
++ if (old->mask & FS_Q_OVERFLOW)
++ return true;
++ else if (old->mask & FS_IN_IGNORED)
++ return false;
+ return true;
+ };
+ }
+ return false;
+ }
+
+ static int inotify_merge(struct list_head *list, struct fsnotify_event *event)
+ {
+ struct fsnotify_event_holder *last_holder;
+ struct fsnotify_event *last_event;
+ int ret = 0;
+
+ /* and the list better be locked by something too */
+ spin_lock(&event->lock);
+
+ last_holder = list_entry(list->prev, struct fsnotify_event_holder, event_list);
+ last_event = last_holder->event;
+ if (event_compare(last_event, event))
+ ret = -EEXIST;
+
+ spin_unlock(&event->lock);
+
+ return ret;
+ }
+
static int inotify_handle_event(struct fsnotify_group *group, struct fsnotify_event *event)
{
struct fsnotify_mark_entry *entry;
@@@ -61,15 -111,14 +115,15 @@@
fsn_event_priv->group = group;
event_priv->wd = wd;
- ret = fsnotify_add_notify_event(group, event, fsn_event_priv);
+ ret = fsnotify_add_notify_event(group, event, fsn_event_priv, inotify_merge);
- /* EEXIST is not an error */
- if (ret == -EEXIST)
- ret = 0;
-
- /* did event_priv get attached? */
- if (list_empty(&fsn_event_priv->event_list))
+ if (ret) {
inotify_free_event_priv(fsn_event_priv);
+ /* EEXIST says we tail matched, EOVERFLOW isn't something
+ * to report up the stack. */
+ if ((ret == -EEXIST) ||
+ (ret == -EOVERFLOW))
+ ret = 0;
+ }
/*
* If we hold the entry until after the event is on the queue
diff --cc fs/notify/inotify/inotify_user.c
index dc32ed8,d5e78f6..0000000
--- a/fs/notify/inotify/inotify_user.c
+++ b/fs/notify/inotify/inotify_user.c
@@@ -405,8 -401,10 +402,8 @@@ void inotify_ignored_and_remove_idr(str
fsn_event_priv->group = group;
event_priv->wd = ientry->wd;
- ret = fsnotify_add_notify_event(group, ignored_event, fsn_event_priv);
- fsnotify_add_notify_event(group, ignored_event, fsn_event_priv, NULL);
-
- /* did the private data get added? */
- if (list_empty(&fsn_event_priv->event_list))
++ ret = fsnotify_add_notify_event(group, ignored_event, fsn_event_priv, NULL);
+ if (ret)
inotify_free_event_priv(fsn_event_priv);
skip_send_ignore:
diff --cc fs/notify/notification.c
index 3816d57,4f69b6f..0000000
--- a/fs/notify/notification.c
+++ b/fs/notify/notification.c
@@@ -173,9 -140,10 +140,7 @@@ int fsnotify_add_notify_event(struct fs
{
struct fsnotify_event_holder *holder = NULL;
struct list_head *list = &group->notification_list;
- struct fsnotify_event_holder *last_holder;
- struct fsnotify_event *last_event;
-
- /* easy to tell if priv was attached to the event */
- if (priv)
- INIT_LIST_HEAD(&priv->event_list);
+ int ret = 0;
/*
* There is one fsnotify_event_holder embedded inside each fsnotify_event.
@@@ -195,8 -163,7 +160,8 @@@ alloc_holder
mutex_lock(&group->notification_mutex);
if (group->q_len >= group->max_events) {
- event = &q_overflow_event;
+ event = q_overflow_event;
+ ret = -EOVERFLOW;
/* sorry, no private data on the overflow event */
priv = NULL;
}
^ permalink raw reply
* Re: [PATCH -next] phonet: fix build when PROC_FS is disabled
From: David Miller @ 2009-08-18 0:49 UTC (permalink / raw)
To: remi; +Cc: randy.dunlap, linux-kernel, linux-next, netdev, akpm
In-Reply-To: <200908172343.44744.remi@remlab.net>
From: "Rémi Denis-Courmont" <remi@remlab.net>
Date: Mon, 17 Aug 2009 23:43:43 +0300
> Le lundi 17 août 2009 23:35:49 Randy Dunlap, vous avez écrit :
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>
>> Fix phonet build when PROC_FS is not enabled:
>>
>> net/built-in.o: In function `pn_sock_open':
>> socket.c:(.text+0x23c649): undefined reference to `seq_open_net'
>> net/built-in.o:(.rodata+0x21018): undefined reference to `seq_release_net'
>>
>> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
>
> Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Applied, thanks.
^ permalink raw reply
* Re: [GIT PULL] tracing: Syscalls trace events + perf support
From: Paul Mundt @ 2009-08-18 0:46 UTC (permalink / raw)
To: Ingo Molnar, Stephen Rothwell, Jason Baron
Cc: Frederic Weisbecker, LKML, Lai Jiangshan, Steven Rostedt,
Peter Zijlstra, Mathieu Desnoyers, Jiaying Zhang, Martin Bligh,
Li Zefan, Masami Hiramatsu, Martin Schwidefsky, Wu Zhangjin,
linux-next
In-Reply-To: <20090812091133.GA21655@elte.hu>
[ Adding to Cc everyone that now has a broken tree thanks to this .. ]
On Wed, Aug 12, 2009 at 11:11:33AM +0200, Ingo Molnar wrote:
> * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > This pull request integrate one cleanup/fix for ftrace and an
> > update for syscall tracing: the migration from old-style tracer to
> > individual tracepoints/trace_events and the support for perf
> > counter.
> >
> > I've tested it with success either with ftrace (every syscall
> > tracepoints enabled at the same time without problems) and with
> > perfcounter.
> >
> > May be one drawback: it creates so much trace events that the
> > ftrace selftests can take some time :-)
>
> Pulled, thanks a lot!
>
And this has now subsequently broken every single SH and S390
configuration, and anyone else unfortunate enough to be supporting ftrace
syscall tracing that isn't x86, without so much as a Cc, well done!
The s390 case can be fixed up in-tree as support has already been merged,
but in the SH case we had ftrace syscall tracing queued up for 2.6.32, so
it doesn't show up in -tip, but the end result in -next is now completely
broken.
I'm not sure how we should handle this, if tracing/core in -tip isn't
rebased, should I just pull the topic-branch in to my tree, fix up the sh
support on top of that, and push the end result out? This seems like the
easiest option at least, but I don't know what other dependencies exist
for tracing/core. Alternative suggestions welcome.
This happens again and again with ftrace and -tip, where people just
randomly change existing interfaces, break all of the existing users, and
then fail to tell anyone about it until it shows up in -next. Even if we
had pushed all of the sh ftrace bits to the -tip tree early on it would
not have changed anything, evident by the fact that s390 and all of the
non ftrace syscall architectures were broken by this change as well (the
latter case was at least caught and corrected, although not by the
original authors of this patch series). Is it really that much to task
that people who are running around breaking ftrace interfaces actually
bother to Cc the architectures that are using it?
If -tip is going to perpetuate this sort of half-assed development
methodology, it has no place in -next.
^ permalink raw reply
* linux-next: manual merge of the xfs tree with Linus' tree
From: Stephen Rothwell @ 2009-08-18 0:12 UTC (permalink / raw)
To: David Chinner, xfs-masters
Cc: linux-next, linux-kernel, Eric Sandeen, Felix Blyakher,
Christoph Hellwig
Hi all,
Today's linux-next merge of the xfs tree got a conflict in
fs/xfs/linux-2.6/xfs_sync.h between commit
bc990f5cb424cdca9dda866785d088e2c2110ecc ("xfs: fix locking in
xfs_iget_cache_hit") from Linus' tree and commit
370f048214b4e9aa2102fa3c454ae1374da287c5 ("xfs: add more statics & drop
some unused functions") from the xfs tree.
Just context changes (add/remove). I fixed it up (see below) and can
carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc fs/xfs/linux-2.6/xfs_sync.h
index 5912060,23e7e7e..0000000
--- a/fs/xfs/linux-2.6/xfs_sync.h
+++ b/fs/xfs/linux-2.6/xfs_sync.h
@@@ -48,8 -48,6 +48,7 @@@ int xfs_reclaim_inode(struct xfs_inode
int xfs_reclaim_inodes(struct xfs_mount *mp, int mode);
void xfs_inode_set_reclaim_tag(struct xfs_inode *ip);
+void __xfs_inode_set_reclaim_tag(struct xfs_perag *pag, struct xfs_inode *ip);
- void xfs_inode_clear_reclaim_tag(struct xfs_inode *ip);
void __xfs_inode_clear_reclaim_tag(struct xfs_mount *mp, struct xfs_perag *pag,
struct xfs_inode *ip);
^ permalink raw reply
* Re: [PATCH -next] trace_skb: fix build when CONFIG_NET is not enabled
From: David Miller @ 2009-08-18 0:03 UTC (permalink / raw)
To: mingo; +Cc: randy.dunlap, linux-kernel, linux-next, akpm, nhorman, rostedt
In-Reply-To: <20090817230654.GC16222@elte.hu>
From: Ingo Molnar <mingo@elte.hu>
Date: Tue, 18 Aug 2009 01:06:54 +0200
> ... but these are the wrong patches, they should be removed or
> reverted and redone properly.
Given the number of users of net-next-2.6, removal via rebasing is
simply not an option. The other two posibilities, sure...
> It's not just about keeping kernel/trace/* changes in the tracing
> tree (which we can relax on-demand given agreement), it's that
> these patches are also _wrong_ and we cannot relax anything about
> that.
Why don't we give Neil a chance to review the situation and fix things
up?
If revert is the final decision, that's fine, I'll revert everything.
But in the mean time at least give Neil a chance to read all of your
feedback and coordinate a way to fix things with everyone.
^ permalink raw reply
* Re: [PATCH -next] trace_skb: fix build when CONFIG_NET is not enabled
From: Ingo Molnar @ 2009-08-17 23:06 UTC (permalink / raw)
To: David Miller
Cc: randy.dunlap, linux-kernel, linux-next, akpm, nhorman, rostedt
In-Reply-To: <20090817.160041.40869355.davem@davemloft.net>
* David Miller <davem@davemloft.net> wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> Date: Mon, 17 Aug 2009 13:37:36 -0700
>
> > From: Randy Dunlap <randy.dunlap@oracle.com>
> >
> > Fix trace_skb_sources build when CONFIG_NET is not enabled:
> >
> > kernel/built-in.o: In function `probe_skb_dequeue':
> > trace_skb_sources.c:(.text+0xd9152): undefined reference to `init_net'
> > trace_skb_sources.c:(.text+0xd9188): undefined reference to `dev_get_by_index'
> >
> > Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
>
> Applied, thanks Randy.
... but these are the wrong patches, they should be removed or
reverted and redone properly.
It's not just about keeping kernel/trace/* changes in the tracing
tree (which we can relax on-demand given agreement), it's that
these patches are also _wrong_ and we cannot relax anything about
that.
Ingo
^ permalink raw reply
* Re: [PATCH -next] trace_skb: fix build when CONFIG_NET is not enabled
From: Ingo Molnar @ 2009-08-17 23:03 UTC (permalink / raw)
To: David Miller
Cc: randy.dunlap, linux-kernel, linux-next, akpm, nhorman, rostedt
In-Reply-To: <20090817.155942.143261709.davem@davemloft.net>
* David Miller <davem@davemloft.net> wrote:
> From: Ingo Molnar <mingo@elte.hu>
> Date: Tue, 18 Aug 2009 00:47:27 +0200
>
> > Also, has the review feedback from the tracing folks been
> > addressed? Please separate these patches out and lets do this
> > properly, this approach is not acceptable.
>
> Fine, will keep you guys in the loop next time :-)
thanks
If the TRACE_EVENT() form is used then it can be done just fine
from the networking tree too by enhancing
include/trace/events/skb.h - TRACE_EVENT() is a decentralized
facility.
We try not to add new ftrace plugins but extend the set of generic
tracepoints.
Ingo
^ permalink raw reply
* Re: [PATCH -next] trace_skb: fix build when CONFIG_NET is not enabled
From: David Miller @ 2009-08-17 23:00 UTC (permalink / raw)
To: randy.dunlap; +Cc: linux-kernel, linux-next, akpm, nhorman, rostedt
In-Reply-To: <4A89BF90.5070202@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Mon, 17 Aug 2009 13:37:36 -0700
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix trace_skb_sources build when CONFIG_NET is not enabled:
>
> kernel/built-in.o: In function `probe_skb_dequeue':
> trace_skb_sources.c:(.text+0xd9152): undefined reference to `init_net'
> trace_skb_sources.c:(.text+0xd9188): undefined reference to `dev_get_by_index'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Applied, thanks Randy.
^ permalink raw reply
* Re: [PATCH -next] trace_skb: fix build when CONFIG_NET is not enabled
From: Ingo Molnar @ 2009-08-17 23:00 UTC (permalink / raw)
To: David Miller
Cc: randy.dunlap, linux-kernel, linux-next, akpm, nhorman, rostedt
In-Reply-To: <20090817224727.GA13795@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
>
> * David Miller <davem@davemloft.net> wrote:
>
> > From: Ingo Molnar <mingo@elte.hu>
> > Date: Mon, 17 Aug 2009 23:58:08 +0200
> >
> > >> --- linux-next-20090817.orig/kernel/trace/Kconfig
> > >> +++ linux-next-20090817/kernel/trace/Kconfig
> > >> @@ -236,6 +236,7 @@ config BOOT_TRACER
> > >>
> > >> config SKB_SOURCES_TRACER
> > >> bool "Trace skb source information"
> > >> + depends on NET
> > >> select GENERIC_TRACER
> > >> help
> > >> This tracer helps developers/sysadmins correlate skb allocation and
> > >
> > > Hm, there's nothing like this in the tracing tree.
> > >
> > > Could we please move kernel/trace/* commits to the tracing tree, so
> > > that it gets adequate testing and review, etc?
> >
> > This one (like previous networking tracing changes Neil has made)
> > touched a decent amount of networking code, and thus we
> > integrated it into net-next-2.6
>
> the three skb-sources-tracer patches i saw submitted were:
>
> include/trace/events/skb.h | 20 ++++++++++++++++++++
> net/core/datagram.c | 3 +++
> 2 files changed, 23 insertions(+)
>
> kernel/traceKconfig | 10 ++++++++++
>
> kernel/trace/Makefile | 1
> kernel/trace/trace.h | 19 ++++++
> kernel/trace/trace_skb_sources.c | 154 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> only touched the networking code for 3 lines in
> net/core/datagram.c.
>
> Think about it: how would you react if i added a new file to
> net/core/ and modified net/Kconfig, and then broke the build?
> You'd quite likely insist on it being done via net-next-2.6,
> right? You'd also likely be upset about that kind of change,
> wouldnt you?
>
> Also, has the review feedback from the tracing folks been
> addressed? Please separate these patches out and lets do this
> properly, this approach is not acceptable.
btw., this isnt just a question of patch logistics - these patches
look unreviewed to me. Why is a new ftrace plugin needed? Why arent
they defined in a TRACE_EVENT() form? That way they'd be generally
usable together with other tracepoints, and would likely be enabled
in most distros. That way they could also be added via other trees,
as TRACE_EVENT() is a generic facility.
We try to migrate ftrace plugins to TRACE_EVENT() tracepoints.
Ingo
^ permalink raw reply
* Re: [PATCH -next] trace_skb: fix build when CONFIG_NET is not enabled
From: David Miller @ 2009-08-17 22:59 UTC (permalink / raw)
To: mingo; +Cc: randy.dunlap, linux-kernel, linux-next, akpm, nhorman, rostedt
In-Reply-To: <20090817224727.GA13795@elte.hu>
From: Ingo Molnar <mingo@elte.hu>
Date: Tue, 18 Aug 2009 00:47:27 +0200
> Also, has the review feedback from the tracing folks been
> addressed? Please separate these patches out and lets do this
> properly, this approach is not acceptable.
Fine, will keep you guys in the loop next time :-)
^ permalink raw reply
* Re: [PATCH -next] trace_skb: fix build when CONFIG_NET is not enabled
From: Ingo Molnar @ 2009-08-17 22:47 UTC (permalink / raw)
To: David Miller
Cc: randy.dunlap, linux-kernel, linux-next, akpm, nhorman, rostedt
In-Reply-To: <20090817.153326.69833512.davem@davemloft.net>
* David Miller <davem@davemloft.net> wrote:
> From: Ingo Molnar <mingo@elte.hu>
> Date: Mon, 17 Aug 2009 23:58:08 +0200
>
> >> --- linux-next-20090817.orig/kernel/trace/Kconfig
> >> +++ linux-next-20090817/kernel/trace/Kconfig
> >> @@ -236,6 +236,7 @@ config BOOT_TRACER
> >>
> >> config SKB_SOURCES_TRACER
> >> bool "Trace skb source information"
> >> + depends on NET
> >> select GENERIC_TRACER
> >> help
> >> This tracer helps developers/sysadmins correlate skb allocation and
> >
> > Hm, there's nothing like this in the tracing tree.
> >
> > Could we please move kernel/trace/* commits to the tracing tree, so
> > that it gets adequate testing and review, etc?
>
> This one (like previous networking tracing changes Neil has made)
> touched a decent amount of networking code, and thus we
> integrated it into net-next-2.6
the three skb-sources-tracer patches i saw submitted were:
include/trace/events/skb.h | 20 ++++++++++++++++++++
net/core/datagram.c | 3 +++
2 files changed, 23 insertions(+)
kernel/traceKconfig | 10 ++++++++++
kernel/trace/Makefile | 1
kernel/trace/trace.h | 19 ++++++
kernel/trace/trace_skb_sources.c | 154 ++++++++++++++++++++++++++++++++++++++++++++++++++++
only touched the networking code for 3 lines in
net/core/datagram.c.
Think about it: how would you react if i added a new file to
net/core/ and modified net/Kconfig, and then broke the build? You'd
quite likely insist on it being done via net-next-2.6, right? You'd
also likely be upset about that kind of change, wouldnt you?
Also, has the review feedback from the tracing folks been
addressed? Please separate these patches out and lets do this
properly, this approach is not acceptable.
Ingo
^ permalink raw reply
* Re: [PATCH -next] trace_skb: fix build when CONFIG_NET is not enabled
From: David Miller @ 2009-08-17 22:33 UTC (permalink / raw)
To: mingo; +Cc: randy.dunlap, linux-kernel, linux-next, akpm, nhorman, rostedt
In-Reply-To: <20090817215808.GB15016@elte.hu>
From: Ingo Molnar <mingo@elte.hu>
Date: Mon, 17 Aug 2009 23:58:08 +0200
>> --- linux-next-20090817.orig/kernel/trace/Kconfig
>> +++ linux-next-20090817/kernel/trace/Kconfig
>> @@ -236,6 +236,7 @@ config BOOT_TRACER
>>
>> config SKB_SOURCES_TRACER
>> bool "Trace skb source information"
>> + depends on NET
>> select GENERIC_TRACER
>> help
>> This tracer helps developers/sysadmins correlate skb allocation and
>
> Hm, there's nothing like this in the tracing tree.
>
> Could we please move kernel/trace/* commits to the tracing tree, so
> that it gets adequate testing and review, etc?
This one (like previous networking tracing changes Neil has
made) touched a decent amount of networking code, and thus
we integrated it into net-next-2.6
^ permalink raw reply
* Re: [PATCH -next] trace_skb: fix build when CONFIG_NET is not enabled
From: Ingo Molnar @ 2009-08-17 21:58 UTC (permalink / raw)
To: Randy Dunlap
Cc: Linux Kernel Mailing List, linux-next, Andrew Morton, Neil Horman,
Steven Rostedt
In-Reply-To: <4A89BF90.5070202@oracle.com>
* Randy Dunlap <randy.dunlap@oracle.com> wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix trace_skb_sources build when CONFIG_NET is not enabled:
>
> kernel/built-in.o: In function `probe_skb_dequeue':
> trace_skb_sources.c:(.text+0xd9152): undefined reference to `init_net'
> trace_skb_sources.c:(.text+0xd9188): undefined reference to `dev_get_by_index'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> ---
> kernel/trace/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> --- linux-next-20090817.orig/kernel/trace/Kconfig
> +++ linux-next-20090817/kernel/trace/Kconfig
> @@ -236,6 +236,7 @@ config BOOT_TRACER
>
> config SKB_SOURCES_TRACER
> bool "Trace skb source information"
> + depends on NET
> select GENERIC_TRACER
> help
> This tracer helps developers/sysadmins correlate skb allocation and
Hm, there's nothing like this in the tracing tree.
Could we please move kernel/trace/* commits to the tracing tree, so
that it gets adequate testing and review, etc?
Ingo
^ permalink raw reply
* Re: [PATCH -next] phonet: fix build when PROC_FS is disabled
From: Rémi Denis-Courmont @ 2009-08-17 20:43 UTC (permalink / raw)
To: Randy Dunlap
Cc: Linux Kernel Mailing List, linux-next, Netdev, David Miller,
Andrew Morton
In-Reply-To: <4A89BF25.9010404@oracle.com>
Le lundi 17 août 2009 23:35:49 Randy Dunlap, vous avez écrit :
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix phonet build when PROC_FS is not enabled:
>
> net/built-in.o: In function `pn_sock_open':
> socket.c:(.text+0x23c649): undefined reference to `seq_open_net'
> net/built-in.o:(.rodata+0x21018): undefined reference to `seq_release_net'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
--
Rémi Denis-Courmont
http://www.remlab.net/
^ permalink raw reply
* Re: [PATCH -next] staging/sep: fix build error & warning & kconfig
From: Greg KH @ 2009-08-17 20:42 UTC (permalink / raw)
To: Randy Dunlap, Alan Cox
Cc: Linux Kernel Mailing List, linux-next, Andrew Morton
In-Reply-To: <4A89BF12.6020908@xenotime.net>
On Mon, Aug 17, 2009 at 01:35:30PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix sep_driver build when CONFIG_PCI=n:
>
> drivers/staging/sep/sep_driver.c:2548: error: implicit declaration of function 'pci_dev_get'
I just merged a patch to fix this a few minutes ago.
> and printk format warning:
>
> drivers/staging/sep/sep_driver.c:290:
> warning: format '%d' expects type 'int', but argument 2 has type 'long unsigned
> int'
I think Alan is taking care of this stuff already.
> Also, the default kconfig value should not be 'y'.
>
> And something should be done about this warning (but I didn't fix it):
> drivers/staging/sep/sep_driver.c:1780: warning: 'error' may be used uninitialized in this function
Alan has already resolved this one.
thanks,
greg k-h
^ permalink raw reply
* [PATCH -next] trace_skb: fix build when CONFIG_NET is not enabled
From: Randy Dunlap @ 2009-08-17 20:37 UTC (permalink / raw)
To: Linux Kernel Mailing List, linux-next
Cc: Andrew Morton, Neil Horman, Steven Rostedt
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix trace_skb_sources build when CONFIG_NET is not enabled:
kernel/built-in.o: In function `probe_skb_dequeue':
trace_skb_sources.c:(.text+0xd9152): undefined reference to `init_net'
trace_skb_sources.c:(.text+0xd9188): undefined reference to `dev_get_by_index'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
---
kernel/trace/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20090817.orig/kernel/trace/Kconfig
+++ linux-next-20090817/kernel/trace/Kconfig
@@ -236,6 +236,7 @@ config BOOT_TRACER
config SKB_SOURCES_TRACER
bool "Trace skb source information"
+ depends on NET
select GENERIC_TRACER
help
This tracer helps developers/sysadmins correlate skb allocation and
--
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/
^ permalink raw reply
* [PATCH -next] phonet: fix build when PROC_FS is disabled
From: Randy Dunlap @ 2009-08-17 20:35 UTC (permalink / raw)
To: Linux Kernel Mailing List, linux-next, Netdev; +Cc: David Miller, Andrew Morton
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix phonet build when PROC_FS is not enabled:
net/built-in.o: In function `pn_sock_open':
socket.c:(.text+0x23c649): undefined reference to `seq_open_net'
net/built-in.o:(.rodata+0x21018): undefined reference to `seq_release_net'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
net/phonet/socket.c | 2 ++
1 file changed, 2 insertions(+)
--- linux-next-20090817.orig/net/phonet/socket.c
+++ linux-next-20090817/net/phonet/socket.c
@@ -413,6 +413,7 @@ found:
}
EXPORT_SYMBOL(pn_sock_get_port);
+#ifdef CONFIG_PROC_FS
static struct sock *pn_sock_get_idx(struct seq_file *seq, loff_t pos)
{
struct net *net = seq_file_net(seq);
@@ -509,3 +510,4 @@ const struct file_operations pn_sock_seq
.llseek = seq_lseek,
.release = seq_release_net,
};
+#endif
--
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/
^ permalink raw reply
* [PATCH -next] staging/sep: fix build error & warning & kconfig
From: Randy Dunlap @ 2009-08-17 20:35 UTC (permalink / raw)
To: Linux Kernel Mailing List, linux-next; +Cc: Greg KH, Andrew Morton
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix sep_driver build when CONFIG_PCI=n:
drivers/staging/sep/sep_driver.c:2548: error: implicit declaration of function 'pci_dev_get'
and printk format warning:
drivers/staging/sep/sep_driver.c:290:
warning: format '%d' expects type 'int', but argument 2 has type 'long unsigned
int'
Also, the default kconfig value should not be 'y'.
And something should be done about this warning (but I didn't fix it):
drivers/staging/sep/sep_driver.c:1780: warning: 'error' may be used uninitialized in this function
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/staging/sep/Kconfig | 3 +--
drivers/staging/sep/sep_driver.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
--- linux-next-20090817.orig/drivers/staging/sep/Kconfig
+++ linux-next-20090817/drivers/staging/sep/Kconfig
@@ -1,8 +1,7 @@
config DX_SEP
tristate "Discretix SEP driver"
# depends on MRST
- depends on RAR_REGISTER
- default y
+ depends on RAR_REGISTER && PCI
help
Discretix SEP driver
--- linux-next-20090817.orig/drivers/staging/sep/sep_driver.c
+++ linux-next-20090817/drivers/staging/sep/sep_driver.c
@@ -287,7 +287,7 @@ static int sep_map_and_alloc_shared_area
sep->shared_area = sep->shared_addr;
/* set the physical address of the shared area */
sep->shared_area_bus = sep->shared_bus;
- edbg("sep: shared_area %d bytes @%p (bus %08llx)\n",
+ edbg("sep: shared_area %lu bytes @%p (bus %08llx)\n",
size, sep->shared_addr, (unsigned long long)sep->shared_bus);
return 0;
}
--
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/
^ permalink raw reply
* Re: linux-next: suspend tree build failure
From: Rafael J. Wysocki @ 2009-08-17 12:06 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel
In-Reply-To: <20090817184048.db6d94f9.sfr@canb.auug.org.au>
On Monday 17 August 2009, Stephen Rothwell wrote:
> [Sorry if some get this twice, I fixed up the subject.]
>
> Hi Rafael,
Hi,
> Today's linux-next build (powerpc allyesconfig) failed like this:
>
> drivers/base/power/runtime.c:948: error: __ksymtab_pm_runtime_disable causes a section type conflict
>
> Caused by commit d9d4cc5169ca18df9ff5afd31c6e6b715ecb454a ("PM: Introduce
> core framework for run-time PM of I/O devices (rev. 17)") from the
> suspend tree. This commit EXPORTs pm_runtime_disable which is an inline
> function that calls __pm_runtime_disable (which is probably what was
> meant to be EXPORTed).
>
> I wish we could get these type of errors to fail on x86 as well ...
>
> I have applied the following patch for today.
Thanks for the patch, I'll fix up the tree later today.
Best,
Rafael
^ permalink raw reply
* linux-next: Tree for August 17
From: Stephen Rothwell @ 2009-08-17 8:54 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 8981 bytes --]
Hi all,
News:
The git tree is now hosted at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git and the
patches are now at http://www.kernel.org/pub/linux/kernel/v2.6/next/ .
There are symlinks from the old locations (so they will continue to work).
Changes since 20090814:
This tree fails to build for powerpc allyesconfig (due to a TOC overflow
problem in the final link).
The arm tree lost its conflict.
The net tree lost its conflict.
The suspend tree gained a build failure for which I applied a patch.
The tip tree gained a conflict against the net tree.
The sfi tree gained conflicts against the acpi tree.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES) and i386, sparc and sparc64 defconfig.
These builds also have CONFIG_ENABLE_WARN_DEPRECATED,
CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
We are up to 140 trees (counting Linus' and 21 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/tty.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging ide-curent/master
Merging dwmw2/master
Merging arm/devel
Merging davinci/for-next
Merging pxa/for-next
CONFLICT (content): Merge conflict in MAINTAINERS
Merging thumb-2/thumb-2
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
CONFLICT (content): Merge conflict in arch/mips/cavium-octeon/dma-octeon.c
CONFLICT (add/add): Merge conflict in arch/mips/cavium-octeon/executive/cvmx-helper-errata.c
CONFLICT (content): Merge conflict in arch/mips/mm/tlbex.c
CONFLICT (content): Merge conflict in arch/mips/sibyte/swarm/setup.c
CONFLICT (content): Merge conflict in drivers/char/hw_random/Kconfig
CONFLICT (content): Merge conflict in drivers/char/hw_random/Makefile
CONFLICT (add/add): Merge conflict in drivers/dma/txx9dmac.c
Merging parisc/next
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging xtensa/master
Merging cifs/master
Merging configfs/linux-next
CONFLICT (content): Merge conflict in fs/configfs/dir.c
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging jfs/next
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging squashfs/master
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
Merging reiserfs-bkl/reiserfs/kill-bkl
Merging vfs/for-next
Merging pci/linux-next
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/board-dm646x-evm.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm355.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm644x.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm646x.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/include/mach/dm355.h
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/include/mach/dm644x.h
Merging quota/for_next
Merging kbuild/master
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging wireless/master
Merging mtd/master
Merging crypto/master
Merging sound/for-next
Merging cpufreq/next
Merging quilt/rr
Merging mmc/next
Merging input/next
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
CONFLICT (content): Merge conflict in drivers/input/misc/Kconfig
Merging hdlc/hdlc-next
Merging drm/drm-next
CONFLICT (content): Merge conflict in drivers/gpu/drm/drm_crtc.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_sdvo.c
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging agp/agp-next
Merging uwb/for-upstream
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging omap/for-next
Merging quilt/aoe
Merging suspend/linux-next
Merging bluetooth/master
Merging fsnotify/for-next
Merging irda/for-next
Merging hwlat/for-linus
Merging drbd/drbd
Applying: drbd: fix for removal of blk_queue_stack_limits
Merging kmemleak/kmemleak
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/x86/include/asm/socket.h
CONFLICT (content): Merge conflict in include/linux/rcupdate.h
CONFLICT (content): Merge conflict in kernel/fork.c
CONFLICT (content): Merge conflict in kernel/trace/trace.h
Merging oprofile/for-next
CONFLICT (content): Merge conflict in kernel/trace/ring_buffer.c
Merging edac-amd/for-next
CONFLICT (content): Merge conflict in arch/x86/kernel/smpboot.c
CONFLICT (content): Merge conflict in include/linux/topology.h
Merging percpu/for-next
CONFLICT (content): Merge conflict in arch/sh/kernel/vmlinux.lds.S
Merging sfi/sfi-test
CONFLICT (content): Merge conflict in arch/x86/include/asm/io_apic.h
CONFLICT (content): Merge conflict in arch/x86/kernel/acpi/boot.c
CONFLICT (content): Merge conflict in arch/x86/kernel/apic/io_apic.c
CONFLICT (content): Merge conflict in drivers/acpi/internal.h
CONFLICT (content): Merge conflict in drivers/acpi/tables.c
CONFLICT (content): Merge conflict in include/linux/acpi.h
Merging asm-generic/next
Merging hwpoison/hwpoison
Merging quilt/driver-core
CONFLICT (content): Merge conflict in drivers/base/class.c
CONFLICT (content): Merge conflict in init/main.c
Merging quilt/tty
CONFLICT (content): Merge conflict in arch/x86/include/asm/termios.h
Merging quilt/usb
CONFLICT (content): Merge conflict in drivers/usb/gadget/m66592-udc.c
CONFLICT (content): Merge conflict in drivers/usb/host/r8a66597-hcd.c
Merging quilt/staging
CONFLICT (delete/modify): drivers/staging/epl/VirtualEthernetLinux.c deleted in quilt/staging and modified in HEAD. Version HEAD of drivers/staging/epl/VirtualEthernetLinux.c left in tree.
$ git rm -f drivers/staging/epl/VirtualEthernetLinux.c
Merging scsi-post-merge/master
Applying: suspend: EXPORT the correct function.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox