* Re: [RFC 2/4] net: netfilter conntrack - add per-net functionality for DCCP protocol
From: Cyrill Gorcunov @ 2009-03-10 10:59 UTC (permalink / raw)
To: Daniel Lezcano
Cc: davem, kaber, netdev, linux-next, xemul, adobriyan,
Cyrill Gorcunov
In-Reply-To: <49B6420B.4080309@free.fr>
On Tue, Mar 10, 2009 at 1:33 PM, Daniel Lezcano <daniel.lezcano@free.fr> wrote:
> Daniel Lezcano wrote:
>>
>> Cyrill Gorcunov wrote:
>>>
>>> Module specific data moved into per-net site and being allocated/freed
>>> during net namespace creation/deletion.
>>>
>>> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
>>> ---
>>> net/netfilter/nf_conntrack_proto_dccp.c | 148
>>> ++++++++++++++++++++++++--------
>>> 1 file changed, 111 insertions(+), 37 deletions(-)
>>>
>>>
>>> static int __init nf_conntrack_proto_dccp_init(void)
>>> {
>>> int err;
>>> - err = nf_conntrack_l4proto_register(&dccp_proto4);
>>> + err = register_pernet_gen_device(&dccp_net_id, &dccp_net_ops);
>>>
>
> [ cut ]
>>
>> Shouldn't it be register_pernet_gen_subsys ?
No, I believe. By using register_pernet_gen_device I'm allowed to
not modify 'struct net' and friends and keep all I need in my own
pointer retrieved thru per-net gen-device id I've registered.
>
> If you use register_pernet_gen_device, your subsystem will be deleted before
> the network devices and potentially you can receive a packet even if your
> subsystem is already freed.
>
> Eric did a fix for tcp and icmp a few weeks ago. I thing its explanation is
> better than mine :)
> it is the commit 6eb0777228f31932fc941eafe8b08848466630a1 for net-2.6
>
> Thanks.
> -- Daniel
>
Thanks a lot Daniel, will check!
^ permalink raw reply
* Re: [RFC 2/4] net: netfilter conntrack - add per-net functionality for DCCP protocol
From: Daniel Lezcano @ 2009-03-10 10:33 UTC (permalink / raw)
To: Cyrill Gorcunov
Cc: davem, kaber, netdev, linux-next, xemul, adobriyan,
Cyrill Gorcunov
In-Reply-To: <49B63EA6.2060802@free.fr>
Daniel Lezcano wrote:
> Cyrill Gorcunov wrote:
>> Module specific data moved into per-net site and being allocated/freed
>> during net namespace creation/deletion.
>>
>> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
>> ---
>> net/netfilter/nf_conntrack_proto_dccp.c | 148
>> ++++++++++++++++++++++++--------
>> 1 file changed, 111 insertions(+), 37 deletions(-)
>>
>>
>>
>> static int __init nf_conntrack_proto_dccp_init(void)
>> {
>> int err;
>>
>> - err = nf_conntrack_l4proto_register(&dccp_proto4);
>> + err = register_pernet_gen_device(&dccp_net_id, &dccp_net_ops);
>>
[ cut ]
> Shouldn't it be register_pernet_gen_subsys ?
If you use register_pernet_gen_device, your subsystem will be deleted
before the network devices and potentially you can receive a packet even
if your subsystem is already freed.
Eric did a fix for tcp and icmp a few weeks ago. I thing its explanation
is better than mine :)
it is the commit 6eb0777228f31932fc941eafe8b08848466630a1 for net-2.6
Thanks.
-- Daniel
^ permalink raw reply
* Re: [RFC 3/4] net: netfilter conntrack - add per-net functionality for SCTP protocol
From: Daniel Lezcano @ 2009-03-10 10:21 UTC (permalink / raw)
To: Cyrill Gorcunov
Cc: davem, kaber, netdev, linux-next, xemul, adobriyan,
Cyrill Gorcunov
In-Reply-To: <20090309182731.907328228@gmail.com>
Cyrill Gorcunov wrote:
> Module specific data moved into per-net site and being allocated/freed
> during net namespace creation/deletion.
>
> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
> ---
> net/netfilter/nf_conntrack_proto_sctp.c | 179 ++++++++++++++++++++++++--------
> 1 file changed, 139 insertions(+), 40 deletions(-)
>
> Index: linux-2.6.git/net/netfilter/nf_conntrack_proto_sctp.c
> ===================================================================
> --- linux-2.6.git.orig/net/netfilter/nf_conntrack_proto_sctp.c
> +++ linux-2.6.git/net/netfilter/nf_conntrack_proto_sctp.c
> @@ -21,6 +21,9 @@
> #include <linux/spinlock.h>
> #include <linux/interrupt.h>
>
> +#include <net/net_namespace.h>
> +#include <net/netns/generic.h>
> +
> #include <net/netfilter/nf_conntrack.h>
> #include <net/netfilter/nf_conntrack_l4proto.h>
> #include <net/netfilter/nf_conntrack_ecache.h>
> @@ -49,16 +52,6 @@ static const char *const sctp_conntrack_
> #define HOURS * 60 MINS
> #define DAYS * 24 HOURS
>
> -static unsigned int sctp_timeouts[SCTP_CONNTRACK_MAX] __read_mostly = {
> - [SCTP_CONNTRACK_CLOSED] = 10 SECS,
> - [SCTP_CONNTRACK_COOKIE_WAIT] = 3 SECS,
> - [SCTP_CONNTRACK_COOKIE_ECHOED] = 3 SECS,
> - [SCTP_CONNTRACK_ESTABLISHED] = 5 DAYS,
> - [SCTP_CONNTRACK_SHUTDOWN_SENT] = 300 SECS / 1000,
> - [SCTP_CONNTRACK_SHUTDOWN_RECD] = 300 SECS / 1000,
> - [SCTP_CONNTRACK_SHUTDOWN_ACK_SENT] = 3 SECS,
> -};
> -
> #define sNO SCTP_CONNTRACK_NONE
> #define sCL SCTP_CONNTRACK_CLOSED
> #define sCW SCTP_CONNTRACK_COOKIE_WAIT
> @@ -130,6 +123,25 @@ static const u8 sctp_conntracks[2][9][SC
> }
> };
>
> +/* this module per-net specifics */
> +static int sctp_net_id;
> +struct sctp_net {
> + unsigned int sctp_timeouts[SCTP_CONNTRACK_MAX];
> +#ifdef CONFIG_SYSCTL
> + struct ctl_table_header *sysctl_header;
> + struct ctl_table *sysctl_table;
> +#ifdef CONFIG_NF_CONNTRACK_PROC_COMPAT
> + struct ctl_table_header *compat_sysctl_header;
> + struct ctl_table *compat_sysctl_table;
> +#endif
> +#endif
> +};
> +
> +static inline struct sctp_net *sctp_pernet(struct net *net)
> +{
> + return net_generic(net, sctp_net_id);
> +}
> +
> static bool sctp_pkt_to_tuple(const struct sk_buff *skb, unsigned int dataoff,
> struct nf_conntrack_tuple *tuple)
> {
> @@ -297,6 +309,7 @@ static int sctp_packet(struct nf_conn *c
> const struct sctp_chunkhdr *sch;
> struct sctp_chunkhdr _sch;
> u_int32_t offset, count;
> + struct sctp_net *sn;
> unsigned long map[256 / sizeof(unsigned long)] = { 0 };
>
> sh = skb_header_pointer(skb, dataoff, sizeof(_sctph), &_sctph);
> @@ -373,7 +386,8 @@ static int sctp_packet(struct nf_conn *c
> }
> write_unlock_bh(&sctp_lock);
>
> - nf_ct_refresh_acct(ct, ctinfo, skb, sctp_timeouts[new_state]);
> + sn = sctp_pernet(nf_ct_net(ct));
> + nf_ct_refresh_acct(ct, ctinfo, skb, sn->sctp_timeouts[new_state]);
>
> if (old_state == SCTP_CONNTRACK_COOKIE_ECHOED &&
> dir == IP_CT_DIR_REPLY &&
> @@ -540,54 +554,49 @@ static int nlattr_to_sctp(struct nlattr
> #endif
>
> #ifdef CONFIG_SYSCTL
> -static unsigned int sctp_sysctl_table_users;
> -static struct ctl_table_header *sctp_sysctl_header;
> +/*
> + * we use these tables as templates when create per-net syctl tables
> + * tables data will be assigned later
> + */
> static struct ctl_table sctp_sysctl_table[] = {
> {
> .procname = "nf_conntrack_sctp_timeout_closed",
> - .data = &sctp_timeouts[SCTP_CONNTRACK_CLOSED],
> .maxlen = sizeof(unsigned int),
> .mode = 0644,
> .proc_handler = proc_dointvec_jiffies,
> },
> {
> .procname = "nf_conntrack_sctp_timeout_cookie_wait",
> - .data = &sctp_timeouts[SCTP_CONNTRACK_COOKIE_WAIT],
> .maxlen = sizeof(unsigned int),
> .mode = 0644,
> .proc_handler = proc_dointvec_jiffies,
> },
> {
> .procname = "nf_conntrack_sctp_timeout_cookie_echoed",
> - .data = &sctp_timeouts[SCTP_CONNTRACK_COOKIE_ECHOED],
> .maxlen = sizeof(unsigned int),
> .mode = 0644,
> .proc_handler = proc_dointvec_jiffies,
> },
> {
> .procname = "nf_conntrack_sctp_timeout_established",
> - .data = &sctp_timeouts[SCTP_CONNTRACK_ESTABLISHED],
> .maxlen = sizeof(unsigned int),
> .mode = 0644,
> .proc_handler = proc_dointvec_jiffies,
> },
> {
> .procname = "nf_conntrack_sctp_timeout_shutdown_sent",
> - .data = &sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_SENT],
> .maxlen = sizeof(unsigned int),
> .mode = 0644,
> .proc_handler = proc_dointvec_jiffies,
> },
> {
> .procname = "nf_conntrack_sctp_timeout_shutdown_recd",
> - .data = &sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_RECD],
> .maxlen = sizeof(unsigned int),
> .mode = 0644,
> .proc_handler = proc_dointvec_jiffies,
> },
> {
> .procname = "nf_conntrack_sctp_timeout_shutdown_ack_sent",
> - .data = &sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_ACK_SENT],
> .maxlen = sizeof(unsigned int),
> .mode = 0644,
> .proc_handler = proc_dointvec_jiffies,
> @@ -601,49 +610,42 @@ static struct ctl_table sctp_sysctl_tabl
> static struct ctl_table sctp_compat_sysctl_table[] = {
> {
> .procname = "ip_conntrack_sctp_timeout_closed",
> - .data = &sctp_timeouts[SCTP_CONNTRACK_CLOSED],
> .maxlen = sizeof(unsigned int),
> .mode = 0644,
> .proc_handler = proc_dointvec_jiffies,
> },
> {
> .procname = "ip_conntrack_sctp_timeout_cookie_wait",
> - .data = &sctp_timeouts[SCTP_CONNTRACK_COOKIE_WAIT],
> .maxlen = sizeof(unsigned int),
> .mode = 0644,
> .proc_handler = proc_dointvec_jiffies,
> },
> {
> .procname = "ip_conntrack_sctp_timeout_cookie_echoed",
> - .data = &sctp_timeouts[SCTP_CONNTRACK_COOKIE_ECHOED],
> .maxlen = sizeof(unsigned int),
> .mode = 0644,
> .proc_handler = proc_dointvec_jiffies,
> },
> {
> .procname = "ip_conntrack_sctp_timeout_established",
> - .data = &sctp_timeouts[SCTP_CONNTRACK_ESTABLISHED],
> .maxlen = sizeof(unsigned int),
> .mode = 0644,
> .proc_handler = proc_dointvec_jiffies,
> },
> {
> .procname = "ip_conntrack_sctp_timeout_shutdown_sent",
> - .data = &sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_SENT],
> .maxlen = sizeof(unsigned int),
> .mode = 0644,
> .proc_handler = proc_dointvec_jiffies,
> },
> {
> .procname = "ip_conntrack_sctp_timeout_shutdown_recd",
> - .data = &sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_RECD],
> .maxlen = sizeof(unsigned int),
> .mode = 0644,
> .proc_handler = proc_dointvec_jiffies,
> },
> {
> .procname = "ip_conntrack_sctp_timeout_shutdown_ack_sent",
> - .data = &sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_ACK_SENT],
> .maxlen = sizeof(unsigned int),
> .mode = 0644,
> .proc_handler = proc_dointvec_jiffies,
> @@ -653,7 +655,7 @@ static struct ctl_table sctp_compat_sysc
> }
> };
> #endif /* CONFIG_NF_CONNTRACK_PROC_COMPAT */
> -#endif
> +#endif /* CONFIG_SYSCTL */
>
> static struct nf_conntrack_l4proto nf_conntrack_l4proto_sctp4 __read_mostly = {
> .l3proto = PF_INET,
> @@ -673,14 +675,6 @@ static struct nf_conntrack_l4proto nf_co
> .nlattr_to_tuple = nf_ct_port_nlattr_to_tuple,
> .nla_policy = nf_ct_port_nla_policy,
> #endif
> -#ifdef CONFIG_SYSCTL
> - .ctl_table_users = &sctp_sysctl_table_users,
> - .ctl_table_header = &sctp_sysctl_header,
> - .ctl_table = sctp_sysctl_table,
> -#ifdef CONFIG_NF_CONNTRACK_PROC_COMPAT
> - .ctl_compat_table = sctp_compat_sysctl_table,
> -#endif
> -#endif
> };
>
> static struct nf_conntrack_l4proto nf_conntrack_l4proto_sctp6 __read_mostly = {
> @@ -701,21 +695,123 @@ static struct nf_conntrack_l4proto nf_co
> .nlattr_to_tuple = nf_ct_port_nlattr_to_tuple,
> .nla_policy = nf_ct_port_nla_policy,
> #endif
> +};
> +
> +static __net_init int sctp_net_init(struct net *net)
> +{
> + struct sctp_net *sn;
> + int err;
> +
> + sn = kmalloc(sizeof(*sn), GFP_KERNEL);
> + if (!sn)
> + return -ENOMEM;
> +
> + /* default values */
> + sn->sctp_timeouts[SCTP_CONNTRACK_CLOSED] = 10 SECS;
> + sn->sctp_timeouts[SCTP_CONNTRACK_COOKIE_WAIT] = 3 SECS;
> + sn->sctp_timeouts[SCTP_CONNTRACK_COOKIE_ECHOED] = 3 SECS;
> + sn->sctp_timeouts[SCTP_CONNTRACK_ESTABLISHED] = 5 DAYS;
> + sn->sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_SENT] = 300 SECS / 1000;
> + sn->sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_RECD] = 300 SECS / 1000;
> + sn->sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_ACK_SENT] = 3 SECS;
> +
> + err = net_assign_generic(net, sctp_net_id, sn);
> + if (err)
> + goto out;
> +
> #ifdef CONFIG_SYSCTL
> - .ctl_table_users = &sctp_sysctl_table_users,
> - .ctl_table_header = &sctp_sysctl_header,
> - .ctl_table = sctp_sysctl_table,
> + err = -ENOMEM;
> + sn->sysctl_table = kmemdup(sctp_sysctl_table,
> + sizeof(sctp_sysctl_table), GFP_KERNEL);
> + if (!sn->sysctl_table)
> + goto out;
> +
> + sn->sysctl_table[0].data = &sn->sctp_timeouts[SCTP_CONNTRACK_CLOSED];
> + sn->sysctl_table[1].data = &sn->sctp_timeouts[SCTP_CONNTRACK_COOKIE_WAIT];
> + sn->sysctl_table[2].data = &sn->sctp_timeouts[SCTP_CONNTRACK_COOKIE_ECHOED];
> + sn->sysctl_table[3].data = &sn->sctp_timeouts[SCTP_CONNTRACK_ESTABLISHED];
> + sn->sysctl_table[4].data = &sn->sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_SENT];
> + sn->sysctl_table[5].data = &sn->sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_RECD];
> + sn->sysctl_table[6].data = &sn->sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_ACK_SENT];
> +
> + sn->sysctl_header = register_net_sysctl_table(net,
> + nf_net_netfilter_sysctl_path, sn->sysctl_table);
> + if (!sn->sysctl_header)
> + goto out_free;
> +
> +#ifdef CONFIG_NF_CONNTRACK_PROC_COMPAT
> + sn->compat_sysctl_table = kmemdup(sctp_compat_sysctl_table,
> + sizeof(sctp_compat_sysctl_table), GFP_KERNEL);
> + if (!sn->compat_sysctl_table)
> + goto out_sysctl;
> +
> + sn->compat_sysctl_table[0].data = &sn->sctp_timeouts[SCTP_CONNTRACK_CLOSED];
> + sn->compat_sysctl_table[1].data = &sn->sctp_timeouts[SCTP_CONNTRACK_COOKIE_WAIT];
> + sn->compat_sysctl_table[2].data = &sn->sctp_timeouts[SCTP_CONNTRACK_COOKIE_ECHOED];
> + sn->compat_sysctl_table[3].data = &sn->sctp_timeouts[SCTP_CONNTRACK_ESTABLISHED];
> + sn->compat_sysctl_table[4].data = &sn->sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_SENT];
> + sn->compat_sysctl_table[5].data = &sn->sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_RECD];
> + sn->compat_sysctl_table[6].data = &sn->sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_ACK_SENT];
> +
> + sn->compat_sysctl_header = register_net_sysctl_table(net,
> + nf_net_ipv4_netfilter_sysctl_path, sn->compat_sysctl_table);
> + if (!sn->compat_sysctl_header)
> + goto out_free_compat;
> +#endif /* CONFIG_NF_CONNTRACK_PROC_COMPAT */
> +#endif /* CONFIG_SYSCTL */
> +
> + return 0;
> +
> +#ifdef CONFIG_SYSCTL
> +
> +#ifdef CONFIG_NF_CONNTRACK_PROC_COMPAT
> +out_free_compat:
> + kfree(sn->compat_sysctl_table);
> +#endif
> +out_sysctl:
> + unregister_net_sysctl_table(sn->sysctl_header);
> +out_free:
> + kfree(sn->sysctl_table);
> +#endif
> +
> +out:
> + kfree(sn);
> + return err;
> +}
> +
> +static __net_exit void sctp_net_exit(struct net *net)
> +{
> + struct sctp_net *sn = sctp_pernet(net);
> +#ifdef CONFIG_SYSCTL
> + unregister_net_sysctl_table(sn->sysctl_header);
> +#ifdef CONFIG_NF_CONNTRACK_PROC_COMPAT
> + unregister_net_sysctl_table(sn->compat_sysctl_header);
> + kfree(sn->compat_sysctl_table);
> +#endif
> + kfree(sn->sysctl_table);
> #endif
> + kfree(sn);
> +
> + net_assign_generic(net, sctp_net_id, NULL);
> +}
> +
> +static struct pernet_operations sctp_net_ops = {
> + .init = sctp_net_init,
> + .exit = sctp_net_exit,
> };
>
> static int __init nf_conntrack_proto_sctp_init(void)
> {
> int ret;
>
> + ret = register_pernet_gen_device(&sctp_net_id, &sctp_net_ops);
>
register_pernet_gen_subsys ?
> + if (ret < 0)
> + goto out;
> +
> ret = nf_conntrack_l4proto_register(&nf_conntrack_l4proto_sctp4);
> if (ret) {
> printk("nf_conntrack_l4proto_sctp4: protocol register failed\n");
> - goto out;
> + goto cleanup_net;
> }
> ret = nf_conntrack_l4proto_register(&nf_conntrack_l4proto_sctp6);
> if (ret) {
> @@ -727,12 +823,15 @@ static int __init nf_conntrack_proto_sct
>
> cleanup_sctp4:
> nf_conntrack_l4proto_unregister(&nf_conntrack_l4proto_sctp4);
> + cleanup_net:
> + unregister_pernet_gen_device(sctp_net_id, &sctp_net_ops);
> out:
> return ret;
> }
>
> static void __exit nf_conntrack_proto_sctp_fini(void)
> {
> + unregister_pernet_gen_device(sctp_net_id, &sctp_net_ops);
> nf_conntrack_l4proto_unregister(&nf_conntrack_l4proto_sctp6);
> nf_conntrack_l4proto_unregister(&nf_conntrack_l4proto_sctp4);
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply
* Re: linux-next: Tree for March 10
From: Wim Van Sebroeck @ 2009-03-10 9:33 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML
In-Reply-To: <20090310195534.8f8f3c7a.sfr@canb.auug.org.au>
Hi Stephen,
> Merging watchdog/master
> CONFLICT (content): Merge conflict in drivers/watchdog/orion5x_wdt.c
> CONFLICT (content): Merge conflict in drivers/watchdog/rc32434_wdt.c
I redid the linux-2.6-watchdog-next tree. Should be fixed next time.
Kind regards,
Wim.
^ permalink raw reply
* Re: linux-next: tracing tree build failure
From: Ingo Molnar @ 2009-03-10 9:10 UTC (permalink / raw)
To: Tejun Heo
Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, linux-next,
KOSAKI Motohiro
In-Reply-To: <49B5C733.6080005@kernel.org>
* Tejun Heo <tj@kernel.org> wrote:
> Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> >
> > kernel/trace/trace_functions_graph.c: In function 'graph_trace_close':
> > kernel/trace/trace_functions_graph.c:836: error: implicit declaration of function 'percpu_free'
> >
> > The direct cause is commit 422d3c7a577b15e1384c9d4e72a9540896b685fa
> > ("tracing: current tip/master can't enable ftrace") from the tracing tree
> > which exposed an interaction between commit
> > f2a8205c4ef1af917d175c36a4097ae5587791c8 ("percpu: kill percpu_alloc()
> > and friends") from the tip-core tree and commit
> > 9005f3ebebfcfe9ccd731d16c468907a35ac1f9a ("tracing/function-graph-tracer:
> > various fixes and features") from the tracing tree.
> >
> > I have reverted commit 422d3c7a577b15e1384c9d4e72a9540896b685fa for
> > today. (As a side note, that commit has no Signed-off-by ...)
>
> Just in case someone doesn't know yet. The remedy is using
> free_percpu() instead of percpu_free().
That's exactly how it was resolved more than two weeks ago in
tip:master - and has been resolved in tip:master since then.
I'm glad to hear about new bugs, but the amount of false
positives from linux-next is wasting a lot of time - the
duplication rate is above 90% which is way too much.
tip:master is a full, well-tested integration of all those
branches. It would be nice if Stephen investigated tip:master
before reporting such solved-long-ago interactions.
Ingo
^ permalink raw reply
* linux-next: Tree for March 10
From: Stephen Rothwell @ 2009-03-10 8:55 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 11545 bytes --]
Hi all,
Changes since 20090306:
Moved trees:
I have the driver-core tree (and the usb tree that depends
on it) to near the end of the merge list to see if it accumulates many
conflicts (since it contains infrastructure changes). It seems to have
inherited 2 conflicts (v4l-dvb, net) and a build failure (acpi).
Undropped tree:
rr
The tracing tree gained build failure for which I reverted a commit.
The xfs tree gained a build failure, so I have used the version from
next-20090306.
The ieee1394 tree lost its conflict.
The sound tree gained a conflict against the arm tree.
The rr tree lost a conflict and build failures.
The input tree gained build failure, so I used the version from
next-20090306.
The md tree gained a conflict against Linus' tree and a build failure, so
I used the version from next-20090306.
The lblnet tree gained a conflict against Linus' tree.
The driver-core tree gained a build failure due to a conflict with the
crypto tree. I have applied a patch to the crypto tree for today.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (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 133 trees (counting Linus' and 18 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging dwmw2/master
Merging arm/devel
CONFLICT (content): Merge conflict in arch/arm/mach-at91/gpio.c
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging mips/mips-for-linux-next
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging pxa/for-next
CONFLICT (rename/modify): Merge conflict in arch/arm/plat-pxa/dma.c
Merging s390/features
Merging sh/master
Merging sparc/master
Merging x86/auto-x86-next
CONFLICT (content): Merge conflict in arch/powerpc/include/asm/elf.h
Merging xtensa/master
Merging tip-core/auto-core-next
CONFLICT (content): Merge conflict in lib/Kconfig.debug
Merging cpus4096/auto-cpus4096-next
Merging tracing/auto-tracing-next
CONFLICT (content): Merge conflict in arch/x86/Kconfig
CONFLICT (delete/modify): block/blktrace.c deleted in tracing/auto-tracing-next and modified in HEAD. Version HEAD of block/blktrace.c left in tree.
CONFLICT (content): Merge conflict in kernel/irq/handle.c
$ git rm -f block/blktrace.c
Applying: tracing: blktrace merge fix
Merging genirq/auto-genirq-next
CONFLICT (content): Merge conflict in kernel/irq/handle.c
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
CONFLICT (content): Merge conflict in lib/Makefile
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
[master]: created 2747afb: "Revert "tracing: current tip/master can't enable ftrace""
Merging pci/linux-next
CONFLICT (content): Merge conflict in drivers/pci/pcie/portdrv_pci.c
Merging quilt/device-mapper
Merging hid/for-next
Merging quilt/i2c
CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-mpc.c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
CONFLICT (content): Merge conflict in Documentation/kernel-parameters.txt
Merging v4l-dvb/master
Merging quota/for_next
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
Merging libata/NEXT
Merging nfs/linux-next
Merging xfs/master
$ git reset --hard HEAD^
Merging xfs/master from next-20090306
Merging infiniband/for-next
Merging acpi/test
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging ocfs2/linux-next
Merging ext4/next
CONFLICT (content): Merge conflict in fs/ext4/inode.c
Merging async_tx/next
Merging udf/for_next
Merging net/master
CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl3945-base.c
CONFLICT (content): Merge conflict in drivers/net/wireless/rt2x00/rt73usb.c
Merging wireless/master
Merging mtd/master
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-shark/include/mach/io.h
CONFLICT (content): Merge conflict in sound/soc/pxa/pxa2xx-i2s.c
Merging cpufreq/next
CONFLICT (content): Merge conflict in arch/x86/include/asm/timer.h
Merging v9fs/for-next
CONFLICT (content): Merge conflict in net/9p/protocol.c
Merging quilt/rr
CONFLICT (content): Merge conflict in arch/powerpc/kernel/irq.c
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/cpufreq/powernow-k8.c
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/cpufreq/speedstep-ich.c
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/cpufreq/speedstep-lib.c
CONFLICT (delete/modify): arch/x86/mach-default/setup.c deleted in HEAD and modified in quilt/rr. Version quilt/rr of arch/x86/mach-default/setup.c left in tree.
CONFLICT (delete/modify): arch/x86/mach-voyager/setup.c deleted in HEAD and modified in quilt/rr. Version quilt/rr of arch/x86/mach-voyager/setup.c left in tree.
CONFLICT (content): Merge conflict in drivers/firmware/dcdbas.c
CONFLICT (content): Merge conflict in drivers/hid/hid-core.c
CONFLICT (content): Merge conflict in drivers/media/video/saa7134/saa7134-core.c
CONFLICT (content): Merge conflict in drivers/media/video/saa7134/saa7134.h
CONFLICT (content): Merge conflict in drivers/net/virtio_net.c
CONFLICT (content): Merge conflict in kernel/module.c
$ git rm -f arch/x86/mach-default/setup.c
$ git rm -f arch/x86/mach-voyager/setup.c
Applying: rr: x86 irqaction merge fixup
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
$ git reset --hard HEAD^
Merging input/next from next-20090306
Merging bkl-removal/bkl-removal
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in firmware/Makefile
CONFLICT (content): Merge conflict in firmware/WHENCE
CONFLICT (content): Merge conflict in sound/isa/Kconfig
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
CONFLICT (content): Merge conflict in include/linux/rcupdate.h
CONFLICT (content): Merge conflict in include/linux/slub_def.h
CONFLICT (content): Merge conflict in mm/slob.c
CONFLICT (content): Merge conflict in mm/slub.c
Merging uclinux/for-next
Merging md/for-next
CONFLICT (content): Merge conflict in include/linux/dmaengine.h
$ git reset --hard HEAD^
Merging md/for-next from next-20090306
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
CONFLICT (content): Merge conflict in drivers/gpu/drm/drm_proc.c
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
Merging quilt/ttydev
Merging agp/agp-next
Merging kmemcheck/auto-kmemcheck-next
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (content): Merge conflict in arch/x86/Kconfig
CONFLICT (content): Merge conflict in arch/x86/mm/init_32.c
CONFLICT (content): Merge conflict in arch/x86/mm/init_64.c
CONFLICT (content): Merge conflict in kernel/trace/ring_buffer.c
CONFLICT (content): Merge conflict in mm/Makefile
Merging generic-ipi/auto-generic-ipi-next
Merging oprofile/auto-oprofile-next
Merging fastboot/auto-fastboot-next
Merging sparseirq/auto-sparseirq-next
Merging iommu/auto-iommu-next
Merging uwb/for-upstream
Merging watchdog/master
CONFLICT (content): Merge conflict in drivers/watchdog/orion5x_wdt.c
CONFLICT (content): Merge conflict in drivers/watchdog/rc32434_wdt.c
Merging proc/proc
CONFLICT (content): Merge conflict in security/selinux/hooks.c
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
CONFLICT (add/add): Merge conflict in drivers/scsi/osd/osd_initiator.c
Merging fatfs/master
Merging fuse/for-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging squashfs/master
Merging omap/for-next
Merging quilt/aoe
Merging kmemleak/kmemleak
CONFLICT (content): Merge conflict in Documentation/kernel-parameters.txt
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (content): Merge conflict in include/linux/percpu.h
CONFLICT (content): Merge conflict in include/linux/slab.h
CONFLICT (content): Merge conflict in init/main.c
CONFLICT (content): Merge conflict in kernel/module.c
CONFLICT (content): Merge conflict in lib/Kconfig.debug
CONFLICT (content): Merge conflict in mm/slab.c
CONFLICT (content): Merge conflict in mm/slob.c
CONFLICT (content): Merge conflict in mm/slub.c
CONFLICT (content): Merge conflict in mm/vmalloc.c
Merging quilt/driver-core
CONFLICT (content): Merge conflict in drivers/media/video/v4l2-device.c
CONFLICT (content): Merge conflict in drivers/net/wimax/i2400m/usb-notif.c
CONFLICT (content): Merge conflict in drivers/sh/maple/maple.c
Applying: acpi: update thermal for bus_id removal
Applying: crypto: remove pr_fmt for now
Merging quilt/usb
Merging quilt/staging
Merging scsi-post-merge/master
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: driver-core tree build failure
From: Stephen Rothwell @ 2009-03-10 8:24 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, Jason Baron, Greg Banks, Geert Uytterhoeven,
Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]
Hi Greg,
Today's linux-next build (x86_64 allmodconfig) failed like this:
crypto/zlib.c: In function 'zlib_compress_update':
crypto/zlib.c:148: warning: initialization makes integer from pointer without a cast
crypto/zlib.c:148: error: initializer element is not computable at load time
crypto/zlib.c:148: error: (near initialization for 'descriptor.primary_hash')
crypto/zlib.c:148: warning: excess elements in struct initializer
crypto/zlib.c:148: warning: (near initialization for 'descriptor')
And many more similar. This line is a pr_debug() statement, so the
finger points at commit 25b67b75587d43ff3f09ad88c03c70a38372d95d
("dynamic debug: combine dprintk and dynamic printk") from the
driver-core tree.
The preprocessed code looks like this:
static int zlib_compress_update(struct crypto_pcomp *tfm,
struct comp_request *req)
{
int ret;
struct zlib_ctx *dctx = crypto_tfm_ctx(crypto_pcomp_tfm(tfm));
struct z_stream_s *stream = &dctx->comp_stream;
do { do { static struct _ddebug descriptor __attribute__((__used__)) __attribute__((section("__verbose"), aligned(8))) = { "zlib", __func__, "/scratch/sfr/next/crypto/zlib.c", "%s: " "avail_in %u, avail_out %u\n", __func__, 55, 33, 148, 0 }; if (({ int __ret = 0; if (__builtin_expect(!!((dynamic_debug_enabled & (1LL << 55)) && (dynamic_debug_enabled2 & (1LL << 33))), 0)) if (__builtin_expect(!!(descriptor.flags), 0)) __ret = 1; __ret; })) printk("<7>" "zlib" ":" "%s: " "avail_in %u, avail_out %u\n", __func__, req->avail_in, req->avail_out); } while (0); } while (0);
The problem is the line:
#define pr_fmt(fmt) "%s: " fmt, __func__
in crypto/zlib.c which was introduced by commit
bf68e65ec9ea61e32ab71bef59aa5d24d255241f ("crypto: zlib - New zlib crypto
module, using pcomp") from the crypto tree.
For today, I have removed the above line from crypto/zlib.c, but
something better needs to be done for tomorrow!
--
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 md tree with the tree
From: Stephen Rothwell @ 2009-03-10 6:49 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-next, Johannes Weiner, Dan Williams
In-Reply-To: <ad338337833c61261ca27f348033e83d.squirrel@neil.brown.name>
[-- Attachment #1: Type: text/plain, Size: 301 bytes --]
Hi Neil,
On Tue, 10 Mar 2009 17:40:20 +1100 (EST) "NeilBrown" <neilb@suse.de> wrote:
>
> I've resolved this i my tree so you don't need to carry the fix any
> further.
Thanks again.
--
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: md tree build failure
From: Stephen Rothwell @ 2009-03-10 6:48 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-next
In-Reply-To: <d7e2f37be5a29b90440a7a4780327b0f.squirrel@neil.brown.name>
[-- Attachment #1: Type: text/plain, Size: 283 bytes --]
Hi Neil,
On Tue, 10 Mar 2009 17:38:19 +1100 (EST) "NeilBrown" <neilb@suse.de> wrote:
>
> I've fixed this now so you should get more happiness next time.
OK, 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 md tree with the tree
From: NeilBrown @ 2009-03-10 6:40 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Johannes Weiner, Dan Williams
In-Reply-To: <20090310163302.874a669c.sfr@canb.auug.org.au>
On Tue, March 10, 2009 4:33 pm, Stephen Rothwell wrote:
> Hi Neil,
>
> Today's linux-next merge of the md tree got a conflict in
> include/linux/dmaengine.h between commit
> 1d93e52eb48df986a3c4d5ad8a520bf1f6837367 ("dmaengine: update kerneldoc")
> from Linus' tree and commit a23742cb3c1ca5d412dea09de452c9d173b80afd
> ("async_tx: add support for asynchronous GF multiplication") from the md
> tree.
>
> I fixed it up (see below) and can carry the fix for a while.
Thanks.
I've resolved this i my tree so you don't need to carry the fix any
further.
I suspect Dan will give an updates set of async-raid6 patches some time
in the next few days....
NeilBrown
^ permalink raw reply
* Re: linux-next: md tree build failure
From: NeilBrown @ 2009-03-10 6:38 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next
In-Reply-To: <20090310164750.affe762c.sfr@canb.auug.org.au>
On Tue, March 10, 2009 4:47 pm, Stephen Rothwell wrote:
> Hi Neil,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> drivers/md/raid10.c: In function 'sync_request':
> drivers/md/raid10.c:1753: error: implicit declaration of function
> 'msleep_interruptible'
>
> Caused by commit 10d4564a71c58e89ddee656eb6cb0fecf5ac4b3c ("md: move lots
> of #include lines out of .h files and into .c").
>
> I have merged the version of the md tree fomr next-20090306 instead of
> today's.
Thanks.
I've fixed this now so you should get more happiness next time.
NeilBrown
^ permalink raw reply
* linux-next: manual merge of the lblnet tree with Linus' tree
From: Stephen Rothwell @ 2009-03-10 6:13 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-next, Dave Jones, Matthew Garrett
Hi Paul,
Today's linux-next merge of the lblnet tree got a conflict in
Documentation/feature-removal-schedule.txt between commit
753b7aea8e4611433c13ac157f944d8b4bf42482 ("[CPUFREQ] Add p4-clockmod
sysfs-ui removal to feature-removal schedule") from Linus' tree and
commit 4c7098cc3b1ccf2930bfb866e108e6cd10f4b2f3 ("selinux: Remove the
"compat_net" compatibility code") from the lblnet tree.
Just overlapping additions/removal. I fixed it up (see below) and can
carry the fix for a while.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc Documentation/feature-removal-schedule.txt
index 72da982,d6b6dc07..0000000
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@@ -333,24 -323,3 +333,13 @@@ When: June 200
Why: Deprecated by the new fschmd driver.
Who: Hans de Goede <hdegoede@redhat.com>
Jean Delvare <khali@linux-fr.org>
+
+---------------------------
+
- What: SELinux "compat_net" functionality
- When: 2.6.30 at the earliest
- Why: In 2.6.18 the Secmark concept was introduced to replace the "compat_net"
- network access control functionality of SELinux. Secmark offers both
- better performance and greater flexibility than the "compat_net"
- mechanism. Now that the major Linux distributions have moved to
- Secmark, it is time to deprecate the older mechanism and start the
- process of removing the old code.
- Who: Paul Moore <paul.moore@hp.com>
- ---------------------------
-
+What: sysfs ui for changing p4-clockmod parameters
+When: September 2009
+Why: See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and
+ e088e4c9cdb618675874becb91b2fd581ee707e6.
+ Removal is subject to fixing any remaining bugs in ACPI which may
+ cause the thermal throttling not to happen at the right time.
+Who: Dave Jones <davej@redhat.com>, Matthew Garrett <mjg@redhat.com>
^ permalink raw reply
* linux-next: md tree build failure
From: Stephen Rothwell @ 2009-03-10 5:47 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-next
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
Hi Neil,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
drivers/md/raid10.c: In function 'sync_request':
drivers/md/raid10.c:1753: error: implicit declaration of function 'msleep_interruptible'
Caused by commit 10d4564a71c58e89ddee656eb6cb0fecf5ac4b3c ("md: move lots
of #include lines out of .h files and into .c").
I have merged the version of the md tree fomr next-20090306 instead of
today's.
--
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 March 6
From: Stephen Rothwell @ 2009-03-10 5:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-next, linux-kernel, Rusty Russell
In-Reply-To: <20090306112450.12901a19.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 944 bytes --]
Hi Andrew,
On Fri, 6 Mar 2009 11:24:50 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Fri, 6 Mar 2009 19:13:11 +1100
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Dropped trees (temporary):
> > rr (build problem)
>
> It's quite irritating and somewhat risky when this happens. It means
> that I have to teporarily drop or rework patches to fix things up.
> Then the patch needs to be undropped or unreworked when the offending
> tree gets restored.
>
> Is it possible to just drop back to the previous day's version when
> something gets screwed up?
I will try this and see how hard it is. I have done a few today with no
ill effects (that I have seen yet).
The other side of the coin is that there are some dependencies between
some of the trees that are included in linux-next.
--
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 md tree with the tree
From: Stephen Rothwell @ 2009-03-10 5:33 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-next, Johannes Weiner, Dan Williams
Hi Neil,
Today's linux-next merge of the md tree got a conflict in
include/linux/dmaengine.h between commit
1d93e52eb48df986a3c4d5ad8a520bf1f6837367 ("dmaengine: update kerneldoc")
from Linus' tree and commit a23742cb3c1ca5d412dea09de452c9d173b80afd
("async_tx: add support for asynchronous GF multiplication") from the md
tree.
I fixed it up (see below) and can carry the fix for a while.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc include/linux/dmaengine.h
index 1956c8d,f9280b8..0000000
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@@ -209,6 -240,9 +236,7 @@@ struct dma_async_tx_descriptor
* @global_node: list_head for global dma_device_list
* @cap_mask: one or more dma_capability flags
* @max_xor: maximum number of xor sources, 0 if no capability
+ * @max_pq: maximum number of PQ sources and PQ-continue capability
- * @refcount: reference count
- * @done: IO completion struct
* @dev_id: unique device ID
* @dev: struct device reference for dma mapping api
* @device_alloc_chan_resources: allocate resources and return the
^ permalink raw reply
* Re: linux-next: input tree build failure
From: Stephen Rothwell @ 2009-03-10 5:14 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-next, Henrik Rydberg
In-Reply-To: <20090310050250.GB18546@dtor-d630.eng.vmware.com>
[-- Attachment #1: Type: text/plain, Size: 363 bytes --]
Hi Dmitry,
On Mon, 9 Mar 2009 22:02:51 -0700 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
> I just noticed the failure and rebuilt the tree without that patch as
> it was dependent upon another bcm change. Sorry about that.
OK, 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: input tree build failure
From: Dmitry Torokhov @ 2009-03-10 5:02 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Henrik Rydberg
In-Reply-To: <20090310154919.31f45de6.sfr@canb.auug.org.au>
Hi Stephen,
On Tue, Mar 10, 2009 at 03:49:19PM +1100, Stephen Rothwell wrote:
> Hi Dmitry,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> drivers/input/mouse/bcm5974.c: In function 'report_tp_state':
> drivers/input/mouse/bcm5974.c:301: error: 'raw_n' undeclared (first use in this function)
> drivers/input/mouse/bcm5974.c:341: error: 'ibt' undeclared (first use in this function)
>
> Caused by commit d86c56b75718295025be895a0f7a157298c84491 ("Input:
> bcm5974 - augment debug information").
>
> I have merged the version of the input tree from next-20090306 instead of
> today's.
I just noticed the failure and rebuilt the tree without that patch as
it was dependent upon another bcm change. Sorry about that.
--
Dmitry
^ permalink raw reply
* linux-next: input tree build failure
From: Stephen Rothwell @ 2009-03-10 4:49 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-next, Henrik Rydberg
[-- Attachment #1: Type: text/plain, Size: 629 bytes --]
Hi Dmitry,
Today's linux-next build (x86_64 allmodconfig) failed like this:
drivers/input/mouse/bcm5974.c: In function 'report_tp_state':
drivers/input/mouse/bcm5974.c:301: error: 'raw_n' undeclared (first use in this function)
drivers/input/mouse/bcm5974.c:341: error: 'ibt' undeclared (first use in this function)
Caused by commit d86c56b75718295025be895a0f7a157298c84491 ("Input:
bcm5974 - augment debug information").
I have merged the version of the input tree from next-20090306 instead of
today's.
--
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 sound tree with the arm tree
From: Stephen Rothwell @ 2009-03-10 3:45 UTC (permalink / raw)
To: Takashi Iwai
Cc: linux-next, Ben Dooks, Mark Brown, Alexander Schulz, Russell King
Hi Takashi,
Today's linux-next merge of the sound tree got a conflict in
arch/arm/mach-shark/include/mach/io.h between commit
eab184c2362567f2b2e951b7bd0e0d353a7e5091 ("[ARM] 5363/1: Shark cleanup
and new defconfig") from the arm tree and commit
8150bc886be5ce3cc301a2baca1fcf2cf7bd7f39 ("S3C24XX: Move and update IIS
headers") from the sound 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 arch/arm/mach-shark/include/mach/io.h
index 9ccbcec,8ca7d7f..0000000
--- a/arch/arm/mach-shark/include/mach/io.h
+++ b/arch/arm/mach-shark/include/mach/io.h
@@@ -11,10 -11,10 +11,10 @@@
#ifndef __ASM_ARM_ARCH_IO_H
#define __ASM_ARM_ARCH_IO_H
-#define PCIO_BASE 0xe0000000
-#define IO_SPACE_LIMIT 0xffffffff
+#define IO_SPACE_LIMIT 0xffffffff
- #define __io(a) ((void __iomem *)(0xe0000000 + (a)))
-#define __io(a) __typesafe_io(PCIO_BASE + (a))
-#define __mem_pci(addr) (addr)
++#define __io(a) __typesafe_io(0xe0000000 + (a))
+
+#define __mem_pci(addr) (addr)
#endif
^ permalink raw reply
* linux-next: xfs tree build failure
From: Stephen Rothwell @ 2009-03-10 2:45 UTC (permalink / raw)
To: David Chinner, xfs-masters; +Cc: linux-next
[-- Attachment #1: Type: text/plain, Size: 596 bytes --]
Hi David,
Today's linux-next build (x86_64 allmodconfig) failed like this:
In file included from fs/xfs/support/debug.c:21:
fs/xfs/xfs_error.h:137: error: expected declaration specifiers or '...' before 'xfs_mount_t'
fs/xfs/xfs_error.h:138: error: expected ')' before '*' token
Immediate cause is commit 7bf446f8b581cef434f5ff05e8a791563bc09b7f ("xfs:
include header files for prototypes").
I have merged the version of the xfs tree from next-20090306 instead of
today's.
--
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: tracing tree build failure
From: KOSAKI Motohiro @ 2009-03-10 2:16 UTC (permalink / raw)
To: Stephen Rothwell
Cc: kosaki.motohiro, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
linux-next, Tejun Heo
In-Reply-To: <20090310115509.328da465.sfr@canb.auug.org.au>
Hi Stephen,
> Hi all,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> kernel/trace/trace_functions_graph.c: In function 'graph_trace_close':
> kernel/trace/trace_functions_graph.c:836: error: implicit declaration of function 'percpu_free'
>
> The direct cause is commit 422d3c7a577b15e1384c9d4e72a9540896b685fa
> ("tracing: current tip/master can't enable ftrace") from the tracing tree
> which exposed an interaction between commit
> f2a8205c4ef1af917d175c36a4097ae5587791c8 ("percpu: kill percpu_alloc()
> and friends") from the tip-core tree and commit
> 9005f3ebebfcfe9ccd731d16c468907a35ac1f9a ("tracing/function-graph-tracer:
> various fixes and features") from the tracing tree.
>
> I have reverted commit 422d3c7a577b15e1384c9d4e72a9540896b685fa for
> today. (As a side note, that commit has no Signed-off-by ...)
I checked latest -tip tree and I found Ingo fixed this issue by following commit.
Could you please try to pull latest tip tree?
commit 56bc29b4b8e188275f52cd5270bcf54f22cfc92b
Author: Ingo Molnar <mingo@elte.hu>
Date: Thu Mar 5 22:04:39 2009 +0100
merge conflict resolutions
^ permalink raw reply
* Re: linux-next: tracing tree build failure
From: Tejun Heo @ 2009-03-10 1:49 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next,
KOSAKI Motohiro
In-Reply-To: <20090310115509.328da465.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> kernel/trace/trace_functions_graph.c: In function 'graph_trace_close':
> kernel/trace/trace_functions_graph.c:836: error: implicit declaration of function 'percpu_free'
>
> The direct cause is commit 422d3c7a577b15e1384c9d4e72a9540896b685fa
> ("tracing: current tip/master can't enable ftrace") from the tracing tree
> which exposed an interaction between commit
> f2a8205c4ef1af917d175c36a4097ae5587791c8 ("percpu: kill percpu_alloc()
> and friends") from the tip-core tree and commit
> 9005f3ebebfcfe9ccd731d16c468907a35ac1f9a ("tracing/function-graph-tracer:
> various fixes and features") from the tracing tree.
>
> I have reverted commit 422d3c7a577b15e1384c9d4e72a9540896b685fa for
> today. (As a side note, that commit has no Signed-off-by ...)
Just in case someone doesn't know yet. The remedy is using
free_percpu() instead of percpu_free().
Thanks.
--
tejun
^ permalink raw reply
* linux-next: tracing tree build failure
From: Stephen Rothwell @ 2009-03-10 0:55 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
Cc: linux-next, Tejun Heo, KOSAKI Motohiro
[-- Attachment #1: Type: text/plain, Size: 932 bytes --]
Hi all,
Today's linux-next build (x86_64 allmodconfig) failed like this:
kernel/trace/trace_functions_graph.c: In function 'graph_trace_close':
kernel/trace/trace_functions_graph.c:836: error: implicit declaration of function 'percpu_free'
The direct cause is commit 422d3c7a577b15e1384c9d4e72a9540896b685fa
("tracing: current tip/master can't enable ftrace") from the tracing tree
which exposed an interaction between commit
f2a8205c4ef1af917d175c36a4097ae5587791c8 ("percpu: kill percpu_alloc()
and friends") from the tip-core tree and commit
9005f3ebebfcfe9ccd731d16c468907a35ac1f9a ("tracing/function-graph-tracer:
various fixes and features") from the tracing tree.
I have reverted commit 422d3c7a577b15e1384c9d4e72a9540896b685fa for
today. (As a side note, that commit has no Signed-off-by ...)
--
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: [RFC 0/4] netfilter conntrack sysctls pernet support
From: Cyrill Gorcunov @ 2009-03-09 21:08 UTC (permalink / raw)
To: Patrick McHardy, davem, netdev, linux-next, xemul, adobriyan,
Netfilter
In-Reply-To: <20090309190744.GA18357@localhost>
[Cyrill Gorcunov - Mon, Mar 09, 2009 at 10:07:44PM +0300]
...
| >> + sn->sysctl_table[0].data = &sn->sctp_timeouts[SCTP_CONNTRACK_CLOSED];
| >> + sn->sysctl_table[1].data = &sn->sctp_timeouts[SCTP_CONNTRACK_COOKIE_WAIT];
| >> + sn->sysctl_table[2].data = &sn->sctp_timeouts[SCTP_CONNTRACK_COOKIE_ECHOED];
| >> + sn->sysctl_table[3].data = &sn->sctp_timeouts[SCTP_CONNTRACK_ESTABLISHED];
| >> + sn->sysctl_table[4].data = &sn->sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_SENT];
| >> + sn->sysctl_table[5].data = &sn->sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_RECD];
| >> + sn->sysctl_table[6].data = &sn->sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_ACK_SENT];
| >
| > Please use an iteration to avoid these repetitve overly long lines.
| >
|
| Ah, thanks a lot! Indeed.
|
| - Cyrill -
Patrick, if I make it like that (iterations)
...
BUILD_BUG_ON(ARRAY_SIZE(sctp_compat_sysctl_table) != SCTP_CONNTRACK_MAX);
for (i = 0; i < ARRAY_SIZE(sctp_compat_sysctl_table) - 1; i++)
sn->compat_sysctl_table[i].data = &sn->sctp_timeouts[i + 1];
...
it seems the code become hard to follow. Yes it was long (repetitive) lines
but it was obvious what is set for every table entry and easy to find what
should be changed if SCTP_ enumeration is changed or table entry removed
(for some reason). I could make it shorter in length but remain the same
explicit assignment. How do you think?
- Cyrill -
^ permalink raw reply
* Re: [RFC 0/4] netfilter conntrack sysctls pernet support
From: Cyrill Gorcunov @ 2009-03-09 19:07 UTC (permalink / raw)
To: Patrick McHardy
Cc: davem, netdev, linux-next, xemul, adobriyan,
Netfilter Development Mailinglist
In-Reply-To: <49B56440.2010404@trash.net>
[Patrick McHardy - Mon, Mar 09, 2009 at 07:47:28PM +0100]
> First off, *please* CC netfilter-devel on patches relating to netfilter.
> I've said this a hundred times in direction of the container guys
> (not sure whether you specifically) and it keeps getting ignored.
Ugh... sorry Patrick, my fault, I've noticed this address in
MAINTEINERS but NETFILTER section contains 3 list so I messed
in which one I should choose. Sorry again.
>
> Cyrill Gorcunov wrote:
>> Hi here are a few patches to bring in per-net functionality
>> for several conntrack protocols: DCCP, SCTP, UDPlite.
>>
>> Since these protos could be built as modules I've put
>> per-net operations to module init/exit routines. The change
>> I would like you point the attention is that module static
>> variables being marked as __read_mostly become now as dynamically
>> allocated -- is it acceptable trade off?
>
> Well, there's no other choice I guess.
Actually, the possibility I see is to make some union on _all_
structures I put in pernet section so this union will contain
max possible size of structure allocated and then create one
global slab for this (HW cache aligned). But it would be ugly hack I
believe and until we have no other choise I would prefer to not
play with this idea :)
>
>> For protocols being built in (like TCP, UDP, ICMP) for which I made
>> patches too but they are in a bit 'rought' state: in original
>> code there some kind of reference counter to sysctl tables being
>> registered (and they don't have any kind of mb, didn't check if it
>> could be a problem for SMP since they are mostly __init functions)
>> so I need some kind of same functionality to count per-net calls.
>
> The tables are shared between IPv4 and IPv6, this keeps track of the
> number of current users to avoid unregistering it while the AF-specific
> module for either one is loaded. This would still be a global counter
> with containers I think since module loading is global and they should
> be visible in all containers if IPv4 or IPv6 conntrack is loaded.
Yes, I even thought about kref usage here but kref doesn't have a few
function I need.
>
>> Will send RFC for these protocols soon.
>>
>> So eventually I would like to hear some kind of feedback on this.
>> Ideas and any kind of comments are highly appreciated.
>
>> + sn->sysctl_table[0].data = &sn->sctp_timeouts[SCTP_CONNTRACK_CLOSED];
>> + sn->sysctl_table[1].data = &sn->sctp_timeouts[SCTP_CONNTRACK_COOKIE_WAIT];
>> + sn->sysctl_table[2].data = &sn->sctp_timeouts[SCTP_CONNTRACK_COOKIE_ECHOED];
>> + sn->sysctl_table[3].data = &sn->sctp_timeouts[SCTP_CONNTRACK_ESTABLISHED];
>> + sn->sysctl_table[4].data = &sn->sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_SENT];
>> + sn->sysctl_table[5].data = &sn->sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_RECD];
>> + sn->sysctl_table[6].data = &sn->sctp_timeouts[SCTP_CONNTRACK_SHUTDOWN_ACK_SENT];
>
> Please use an iteration to avoid these repetitve overly long lines.
>
Ah, thanks a lot! Indeed.
- Cyrill -
^ 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