* Re: [PATCH linux-next 1/1] ath6k: Normalize use of FW_DIR
From: Tim Gardner @ 2012-04-16 16:42 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-kernel, John W. Linville, linux-wireless, netdev,
ath6kl-devel
In-Reply-To: <4F8BBEAD.40305@qca.qualcomm.com>
On 04/16/2012 12:39 AM, Kalle Valo wrote:
> On 04/13/2012 08:17 PM, Tim Gardner wrote:
>> Cc: Kalle Valo <kvalo@qca.qualcomm.com>
>> Cc: "John W. Linville" <linville@tuxdriver.com>
>> Cc: linux-wireless@vger.kernel.org
>> Cc: netdev@vger.kernel.org
>> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
>
> Thanks, applied to ath6kl.git. But ar6004 hw1.2 supports wasn't in
> linux-next yet so I changed it as well. If you can, please check my changes:
>
> https://github.com/kvalo/ath6kl/commit/2023dbb8310ab39ac1119a32ef52405f7a73f51f
>
> Kalle
Looks good to me.
rtg
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply
* Re: Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer address. Bug or feature?
From: Denys Fedoryshchenko @ 2012-04-16 16:48 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Stian Skjelstad, eric.dumazet, stephen.hemminger, netdev
In-Reply-To: <20120416081954.1bb994db@nehalam.linuxnetplumber.net>
On 2012-04-16 18:19, Stephen Hemminger wrote:
> On Mon, 16 Apr 2012 13:37:14 +0300
> Denys Fedoryshchenko <denys@visp.net.lb> wrote:
>
>> After digging the code, i came to conclusion:
>> fib_del_ifaddr, will check if deleted address are exist as prefsrc
>> or
>> interface are shut down, they will do fi->fib_flags |= RTNH_F_DEAD;
>> Then fib_flush -> fib_table_flush -> trie_flush_leaf ->
>> trie_flush_list
>> will delete such routes.
>> But trie_flush_list won't notify over netlink that route are
>> deleted.
>>
>> So the only solution is to fetch first, then keep full routing table
>> in
>> userspace also, and keep tracking if local addresses deleted, and do
>> the
>> same in userspace and check for prefsrc...
>>
>> Maybe it should be fixed? E.g. netlink message sent when any route
>> are
>> deleted, even over the flush
>>
>> On 2012-04-13 16:59, Stian Skjelstad wrote:
>> > I've seen the same issue, and got no response so far to that very
>> > same question. Have you tested this on older kernels? I have
>> worked
>> > around this issue by testing my local copy of routing entries that
>> > use
>> > 'via'. If they are not routable when after the RTM_DELROUTE event,
>> I
>> > autoremove them from my local copy.
>> >
>> > Stian Skjelstad
>> >
>
>
> Looking at Quagga, it knows that deleting interface address
> removes connected routes and silently cleans up.
>
> You have to be really careful here making any changes to not break
> applications that expect existing behavior.
It looks like "correct" behavior should not harm existing programs that
much (just there will be netlink message to delete route that are
already deleted by program, e.g. quagga), but looking to code,
implementing this feature will make significant overhead and in some
cases it can be harmful.
For example if full view BGP interface dropped, it is hundreds of
thousands netlink messages. So seems better i will listen to
address/link changes also and keep routing table in memory.
So better seems to keep as is.
^ permalink raw reply
* [PATCH] tcp: restore formatting of macros for tcp_skb_cb sacked field
From: Neal Cardwell @ 2012-04-16 17:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eric Dumazet, Tom Herbert, Neal Cardwell
Commit b82d1bb4 inadvertendly placed unrelated new code between
TCPCB_EVER_RETRANS and TCPCB_RETRANS and the other macros that refer
to the sacked field in the struct tcp_skb_cb (probably because there
was a misleading empty line there). This commit fixes up the
formatting so that all macros related to the sacked field are adjacent
again.
Signed-off-by: Neal Cardwell <ncardwell@google.com>
---
include/net/tcp.h | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index f75a04d..a725f2d 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -645,16 +645,17 @@ struct tcp_skb_cb {
__u32 end_seq; /* SEQ + FIN + SYN + datalen */
__u32 when; /* used to compute rtt's */
__u8 tcp_flags; /* TCP header flags. (tcp[13]) */
+
__u8 sacked; /* State flags for SACK/FACK. */
#define TCPCB_SACKED_ACKED 0x01 /* SKB ACK'd by a SACK block */
#define TCPCB_SACKED_RETRANS 0x02 /* SKB retransmitted */
#define TCPCB_LOST 0x04 /* SKB is lost */
#define TCPCB_TAGBITS 0x07 /* All tag bits */
- __u8 ip_dsfield; /* IPv4 tos or IPv6 dsfield */
- /* 1 byte hole */
#define TCPCB_EVER_RETRANS 0x80 /* Ever retransmitted frame */
#define TCPCB_RETRANS (TCPCB_SACKED_RETRANS|TCPCB_EVER_RETRANS)
+ __u8 ip_dsfield; /* IPv4 tos or IPv6 dsfield */
+ /* 1 byte hole */
__u32 ack_seq; /* Sequence number ACK'd */
};
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH 2/2] IPVS: make failure of netns init more stable
From: Hans Schillstrom @ 2012-04-16 17:16 UTC (permalink / raw)
To: Julian Anastasov
Cc: horms@verge.net.au, wensong@linux-vs.org,
lvs-devel@vger.kernel.org, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org, hans@schillstrom.com
In-Reply-To: <alpine.LFD.2.00.1204161621080.1711@ja.ssi.bg>
Hello
On Monday 16 April 2012 16:25:23 Julian Anastasov wrote:
>
> Hello,
>
> On Mon, 16 Apr 2012, Hans Schillstrom wrote:
>
> > Add a IP_VS_F_NET_INIT_OK flag
> > that other modules can use for check of a successful init of ip_vs
> >
> > Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
> > ---
>
> > diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
> > index b5a5c73..58722a2 100644
> > --- a/net/netfilter/ipvs/ip_vs_core.c
> > +++ b/net/netfilter/ipvs/ip_vs_core.c
>
> > @@ -1881,7 +1881,7 @@ static int __net_init __ip_vs_init(struct net *net)
> > return -ENOMEM;
> >
> > /* Hold the beast until a service is registerd */
> > - ipvs->enable = 0;
> > + ipvs->status = 0;
> > ipvs->net = net;
> > /* Counters used for creating unique names */
> > ipvs->gen = atomic_read(&ipvs_netns_cnt);
> > @@ -1906,6 +1906,7 @@ static int __net_init __ip_vs_init(struct net *net)
> > if (ip_vs_sync_net_init(net) < 0)
> > goto sync_fail;
> >
> > + IPVS_NETNS_OK(ipvs);
> > printk(KERN_INFO "IPVS: Creating netns size=%zu id=%d\n",
> > sizeof(struct netns_ipvs), ipvs->gen);
> > return 0;
> > @@ -1924,6 +1925,7 @@ protocol_fail:
> > control_fail:
> > ip_vs_estimator_net_cleanup(net);
> > estimator_fail:
> > + ipvs->status = 0; /* Nothing is enabled */
>
> While 1st patch looks ok, keeping net->ipvs after
> failure is not going to work. It seems you ignored the patch
> I already posted. We duplicate the pointer in net->ipvs but
> it should not be used after free.
>
Sorry, I'll revert that.
> Note that net_generic() and net->ipvs can not be
> used after ops_exit/ops_free and failed ops_init.
True, when ip_vs(.ko) fails. I missed that.
>
> But I see some inconsistency in net/core/net_namespace.c:
> __register_pernet_operations when CONFIG_NET_NS is enabled
> does not call ops_free after failed ops_init while when
> CONFIG_NET_NS is not enabled ops_free is called. The
> problem is that we leak the ops->size data allocated for the
> failed net. I think, the fix should be ops_init to free the data.
Are you sure ?
In my code it does...
static int __register_pernet_operations(struct list_head *list,
struct pernet_operations *ops)
at line 417
..
for_each_net(net) {
error = ops_init(ops, net);
if (error)
goto out_undo;
...
line 426
out_undo:
/* If I have an error cleanup all namespaces I initialized */
list_del(&ops->list);
ops_exit_list(ops, &net_exit_list);
ops_free_list(ops, &net_exit_list);
return error;
}
> The 2nd problem is that after ops_free the
> net_generic pointer remains assigned in ptr[id-1], even
> after being freed. Not sure if recent changes to net_generic()
> can deal with freed data. This BUG_ON(!ptr) can not catch
> problems if one subsys uses net_generic() for another
> subsys that can be unregistered.
>
> I'm going to test such fix for ops_init:
>
> [PATCH] netns: do not leak net_generic data on failed init
>
> ops_init should free the net_generic data on
> init failure and __register_pernet_operations should not
> call ops_free when NET_NS is not enabled.
>
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
> ---
> net/core/net_namespace.c | 33 ++++++++++++++++++---------------
> 1 files changed, 18 insertions(+), 15 deletions(-)
>
> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> index 0e950fd..31a5ae5 100644
> --- a/net/core/net_namespace.c
> +++ b/net/core/net_namespace.c
> @@ -83,21 +83,29 @@ assign:
>
> static int ops_init(const struct pernet_operations *ops, struct net *net)
> {
> - int err;
> + int err = -ENOMEM;
> + void *data = NULL;
> +
> if (ops->id && ops->size) {
> - void *data = kzalloc(ops->size, GFP_KERNEL);
> + data = kzalloc(ops->size, GFP_KERNEL);
> if (!data)
> - return -ENOMEM;
> + goto out;
>
> err = net_assign_generic(net, *ops->id, data);
> - if (err) {
> - kfree(data);
> - return err;
> - }
> + if (err)
> + goto cleanup;
> }
> + err = 0;
> if (ops->init)
> - return ops->init(net);
> - return 0;
> + err = ops->init(net);
> + if (!err)
> + return 0;
> +
> +cleanup:
> + kfree(data);
> +
> +out:
> + return err;
> }
>
> static void ops_free(const struct pernet_operations *ops, struct net *net)
> @@ -448,12 +456,7 @@ static void __unregister_pernet_operations(struct pernet_operations *ops)
> static int __register_pernet_operations(struct list_head *list,
> struct pernet_operations *ops)
> {
> - int err = 0;
> - err = ops_init(ops, &init_net);
> - if (err)
> - ops_free(ops, &init_net);
> - return err;
> -
> + return ops_init(ops, &init_net);
> }
>
> static void __unregister_pernet_operations(struct pernet_operations *ops)
--
Regards
Hans Schillstrom <hans.schillstrom@ericsson.com>
^ permalink raw reply
* Re: [PATCH 2/2] IPVS: make failure of netns init more stable
From: Julian Anastasov @ 2012-04-16 17:31 UTC (permalink / raw)
To: Hans Schillstrom
Cc: horms@verge.net.au, wensong@linux-vs.org,
lvs-devel@vger.kernel.org, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org, hans@schillstrom.com
In-Reply-To: <201204161916.33621.hans.schillstrom@ericsson.com>
Hello,
On Mon, 16 Apr 2012, Hans Schillstrom wrote:
> > But I see some inconsistency in net/core/net_namespace.c:
> > __register_pernet_operations when CONFIG_NET_NS is enabled
> > does not call ops_free after failed ops_init while when
> > CONFIG_NET_NS is not enabled ops_free is called. The
> > problem is that we leak the ops->size data allocated for the
> > failed net. I think, the fix should be ops_init to free the data.
>
> Are you sure ?
> In my code it does...
>
> static int __register_pernet_operations(struct list_head *list,
> struct pernet_operations *ops)
> at line 417
> ..
> for_each_net(net) {
> error = ops_init(ops, net);
> if (error)
> goto out_undo;
There is line here that registers current net for
cleanup only after ops_init success:
list_add_tail(&net->exit_list, &net_exit_list);
If ops_init fails for first net then net_exit_list will
be empty.
> ...
> line 426
> out_undo:
> /* If I have an error cleanup all namespaces I initialized */
> list_del(&ops->list);
> ops_exit_list(ops, &net_exit_list);
> ops_free_list(ops, &net_exit_list);
> return error;
> }
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH v3] mac80211: Support on-channel scan option.
From: Johannes Berg @ 2012-04-16 17:33 UTC (permalink / raw)
To: greearb-my8/4N5VtI7c+919tysfdA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1334248689-23018-1-git-send-email-greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
Did you test it?
> + /* If we are scanning only on the current channel, then
> + * we do not need to stop normal activities
> + */
> + unsigned long next_delay;
> +
> + __set_bit(SCAN_ONCHANNEL_SCANNING,&local->scanning);
> + ieee80211_recalc_idle(local);
> + /* Notify driver scan is starting, keep order of operations
> + * same as normal software scan, in case that matters. */
> + drv_sw_scan_start(local);
> + ieee80211_configure_filter(local); /* accept probe-responses */
> + /* We need to ensure power level is at max for scanning. */
> + ieee80211_hw_config(local, 0);
a few blank lines would be nice :)
> + if ((req->channels[0]->flags&
> + IEEE80211_CHAN_PASSIVE_SCAN) ||
> + !local->scan_req->n_ssids) {
That formatting is a bit off it seems. Or is that just my mailer?
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3] mac80211: Support on-channel scan option.
From: Ben Greear @ 2012-04-16 17:41 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4F8C57CC.4090505-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
On 04/16/2012 10:33 AM, Johannes Berg wrote:
> Did you test it?
Yes. I added my old can-scan-one patch on top of this
so that as soon as one station is associated the rest
of the hostap-generated scans can just scan the current channel. I
then bring up 100 or so virtual stations and they all scan
and do their thing...
I also tried some manual scans on a fixed frequency. Those
appeared to work, though I got scan results for APs on different
channels. Does that seem right? I can't see how my patch
would affect that sort of thing one way or another...
If you have some suggestions for other ways to test this
please let me know.
>> + /* If we are scanning only on the current channel, then
>> + * we do not need to stop normal activities
>> + */
>> + unsigned long next_delay;
>> +
>> + __set_bit(SCAN_ONCHANNEL_SCANNING,&local->scanning);
>> + ieee80211_recalc_idle(local);
>> + /* Notify driver scan is starting, keep order of operations
>> + * same as normal software scan, in case that matters. */
>> + drv_sw_scan_start(local);
>> + ieee80211_configure_filter(local); /* accept probe-responses */
>> + /* We need to ensure power level is at max for scanning. */
>> + ieee80211_hw_config(local, 0);
>
> a few blank lines would be nice :)
Sure, will do.
>> + if ((req->channels[0]->flags&
>> + IEEE80211_CHAN_PASSIVE_SCAN) ||
>> + !local->scan_req->n_ssids) {
>
> That formatting is a bit off it seems. Or is that just my mailer?
Well, it looked OK to me..though when I replied my mailer
certainly made it look funky. I'll re-run it through checkpatch
just in case.
Thanks,
Ben
--
Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] IPVS: make failure of netns init more stable
From: Hans Schillstrom @ 2012-04-16 17:45 UTC (permalink / raw)
To: Julian Anastasov
Cc: horms@verge.net.au, wensong@linux-vs.org,
lvs-devel@vger.kernel.org, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org, hans@schillstrom.com
In-Reply-To: <alpine.LFD.2.00.1204162026480.6225@ja.ssi.bg>
On Monday 16 April 2012 19:31:40 Julian Anastasov wrote:
>
> Hello,
>
> On Mon, 16 Apr 2012, Hans Schillstrom wrote:
>
> > > But I see some inconsistency in net/core/net_namespace.c:
> > > __register_pernet_operations when CONFIG_NET_NS is enabled
> > > does not call ops_free after failed ops_init while when
> > > CONFIG_NET_NS is not enabled ops_free is called. The
> > > problem is that we leak the ops->size data allocated for the
> > > failed net. I think, the fix should be ops_init to free the data.
> >
> > Are you sure ?
> > In my code it does...
> >
> > static int __register_pernet_operations(struct list_head *list,
> > struct pernet_operations *ops)
> > at line 417
> > ..
> > for_each_net(net) {
> > error = ops_init(ops, net);
> > if (error)
> > goto out_undo;
>
> There is line here that registers current net for
> cleanup only after ops_init success:
>
> list_add_tail(&net->exit_list, &net_exit_list);
>
> If ops_init fails for first net then net_exit_list will
> be empty.
Yes, you are right as allways :-)
>
> > ...
> > line 426
> > out_undo:
> > /* If I have an error cleanup all namespaces I initialized */
> > list_del(&ops->list);
> > ops_exit_list(ops, &net_exit_list);
> > ops_free_list(ops, &net_exit_list);
> > return error;
> > }
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
>
--
Regards
Hans Schillstrom <hans.schillstrom@ericsson.com>
^ permalink raw reply
* Re: [PATCH v3] mac80211: Support on-channel scan option.
From: Adrian Chadd @ 2012-04-16 18:03 UTC (permalink / raw)
To: Ben Greear
Cc: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4F8C59B2.20207-my8/4N5VtI7c+919tysfdA@public.gmane.org>
On 16 April 2012 10:41, Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org> wrote:
> I also tried some manual scans on a fixed frequency. Those
> appeared to work, though I got scan results for APs on different
> channels. Does that seem right? I can't see how my patch
> would affect that sort of thing one way or another...
You'll see off-channel beacons in 11bg mode. :-)
It's actually rather helpful, except that the RSSI reported isn't
anywhere near as valid as you'd like.
Adrian
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/9] atl1: add napi to Atheros L1 NIC
From: David Miller @ 2012-04-16 18:20 UTC (permalink / raw)
To: antonz; +Cc: netdev, jcliburn, khorenko
In-Reply-To: <4F8BC8C3.6020102@parallels.com>
From: Tony Zelenoff <antonz@parallels.com>
Date: Mon, 16 Apr 2012 11:22:43 +0400
> Also, i'm interested in what to do with Chris Nook address in contacts
> list. Reason - mailer respond that this address is not valid
> anymore. Should i remove him from contacts or leave?
>
> Mailer response:
>
> csnook@redhat.com
> SMTP error from remote mail server after RCPT TO:<csnook@redhat.com>:
> host mx1.redhat.com [209.132.183.28]: 550 5.2.1
> <csnook@redhat.com>... Mailbox disabled for this recipient
I think you should remove it.
^ permalink raw reply
* Re: [PATCH net-next] atl1: remove unused member from atl1_adapter structure
From: David Miller @ 2012-04-16 18:22 UTC (permalink / raw)
To: antonz; +Cc: netdev, jcliburn, csnook
In-Reply-To: <1334561249-84277-1-git-send-email-antonz@parallels.com>
From: Tony Zelenoff <antonz@parallels.com>
Date: Mon, 16 Apr 2012 11:27:29 +0400
> Signed-off-by: Tony Zelenoff <antonz@parallels.com>
Applied, thanks.
^ permalink raw reply
* Re: SV: Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer address. Bug or feature?
From: David Miller @ 2012-04-16 18:40 UTC (permalink / raw)
To: denys; +Cc: stian, eric.dumazet, stephen.hemminger, netdev
In-Reply-To: <3db49d4a58321a5e185cd67335a60c81@visp.net.lb>
From: Denys Fedoryshchenko <denys@visp.net.lb>
Date: Mon, 16 Apr 2012 13:37:14 +0300
> So the only solution is to fetch first, then keep full routing table
> in userspace also, and keep tracking if local addresses deleted, and
> do the same in userspace and check for prefsrc...
You don't need to keep full routing table in userspace, don't be
silly.
You only need to watch for the device down event, and purge in
userspace based upon that key.
^ permalink raw reply
* Re: [PATCH] tcp: restore formatting of macros for tcp_skb_cb sacked field
From: David Miller @ 2012-04-16 18:49 UTC (permalink / raw)
To: ncardwell; +Cc: netdev, edumazet, therbert
In-Reply-To: <1334596086-22905-1-git-send-email-ncardwell@google.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Mon, 16 Apr 2012 13:08:06 -0400
> Commit b82d1bb4 inadvertendly placed unrelated new code between
> TCPCB_EVER_RETRANS and TCPCB_RETRANS and the other macros that refer
> to the sacked field in the struct tcp_skb_cb (probably because there
> was a misleading empty line there). This commit fixes up the
> formatting so that all macros related to the sacked field are adjacent
> again.
>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
Applied to net-next, thanks Neal.
^ permalink raw reply
* Re: [PATCH 1/3] net/can: use module_pci_driver
From: Oliver Hartkopp @ 2012-04-16 18:54 UTC (permalink / raw)
To: Marc Kleine-Budde, David S. Miller
Cc: Axel Lin, netdev, Wolfgang Grandegger, linux-can
In-Reply-To: <1334378323.2862.1.camel@phoenix>
Hello Dave,
i've seen that you applied the two pci simplifications from Axel Lin to the
net-next tree
http://patchwork.ozlabs.org/patch/152473/
http://patchwork.ozlabs.org/patch/152474/
... but only this one is marked 'awaiting upstream' ?
http://patchwork.ozlabs.org/patch/152472/
What does this mean? Should Marc process this patch separately via his
can-next tree?
Regards,
Oliver
On 14.04.2012 06:38, Axel Lin wrote:
> This patch converts the drivers in drivers/net/can/* to use
> module_pci_driver() macro which makes the code smaller and a bit simpler.
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
> Cc: Wolfgang Grandegger <wg@grandegger.com>
> Cc: Marc Kleine-Budde <mkl@pengutronix.de>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: linux-can@vger.kernel.org
> ---
> drivers/net/can/pch_can.c | 12 +-----------
> drivers/net/can/sja1000/ems_pci.c | 14 +-------------
> drivers/net/can/sja1000/kvaser_pci.c | 13 +------------
> drivers/net/can/sja1000/peak_pci.c | 12 +-----------
> drivers/net/can/sja1000/plx_pci.c | 13 +------------
> 5 files changed, 5 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
> index 2bb215e..1226297 100644
> --- a/drivers/net/can/pch_can.c
> +++ b/drivers/net/can/pch_can.c
> @@ -1274,17 +1274,7 @@ static struct pci_driver pch_can_pci_driver = {
> .resume = pch_can_resume,
> };
>
> -static int __init pch_can_pci_init(void)
> -{
> - return pci_register_driver(&pch_can_pci_driver);
> -}
> -module_init(pch_can_pci_init);
> -
> -static void __exit pch_can_pci_exit(void)
> -{
> - pci_unregister_driver(&pch_can_pci_driver);
> -}
> -module_exit(pch_can_pci_exit);
> +module_pci_driver(pch_can_pci_driver);
>
> MODULE_DESCRIPTION("Intel EG20T PCH CAN(Controller Area Network) Driver");
> MODULE_LICENSE("GPL v2");
> diff --git a/drivers/net/can/sja1000/ems_pci.c b/drivers/net/can/sja1000/ems_pci.c
> index 36f4f97..5c6d412 100644
> --- a/drivers/net/can/sja1000/ems_pci.c
> +++ b/drivers/net/can/sja1000/ems_pci.c
> @@ -371,16 +371,4 @@ static struct pci_driver ems_pci_driver = {
> .remove = ems_pci_del_card,
> };
>
> -static int __init ems_pci_init(void)
> -{
> - return pci_register_driver(&ems_pci_driver);
> -}
> -
> -static void __exit ems_pci_exit(void)
> -{
> - pci_unregister_driver(&ems_pci_driver);
> -}
> -
> -module_init(ems_pci_init);
> -module_exit(ems_pci_exit);
> -
> +module_pci_driver(ems_pci_driver);
> diff --git a/drivers/net/can/sja1000/kvaser_pci.c b/drivers/net/can/sja1000/kvaser_pci.c
> index ed004ce..23ed6ea 100644
> --- a/drivers/net/can/sja1000/kvaser_pci.c
> +++ b/drivers/net/can/sja1000/kvaser_pci.c
> @@ -397,15 +397,4 @@ static struct pci_driver kvaser_pci_driver = {
> .remove = __devexit_p(kvaser_pci_remove_one),
> };
>
> -static int __init kvaser_pci_init(void)
> -{
> - return pci_register_driver(&kvaser_pci_driver);
> -}
> -
> -static void __exit kvaser_pci_exit(void)
> -{
> - pci_unregister_driver(&kvaser_pci_driver);
> -}
> -
> -module_init(kvaser_pci_init);
> -module_exit(kvaser_pci_exit);
> +module_pci_driver(kvaser_pci_driver);
> diff --git a/drivers/net/can/sja1000/peak_pci.c b/drivers/net/can/sja1000/peak_pci.c
> index 5f92b86..f0a1296 100644
> --- a/drivers/net/can/sja1000/peak_pci.c
> +++ b/drivers/net/can/sja1000/peak_pci.c
> @@ -749,14 +749,4 @@ static struct pci_driver peak_pci_driver = {
> .remove = __devexit_p(peak_pci_remove),
> };
>
> -static int __init peak_pci_init(void)
> -{
> - return pci_register_driver(&peak_pci_driver);
> -}
> -module_init(peak_pci_init);
> -
> -static void __exit peak_pci_exit(void)
> -{
> - pci_unregister_driver(&peak_pci_driver);
> -}
> -module_exit(peak_pci_exit);
> +module_pci_driver(peak_pci_driver);
> diff --git a/drivers/net/can/sja1000/plx_pci.c b/drivers/net/can/sja1000/plx_pci.c
> index a227586..8bc9598 100644
> --- a/drivers/net/can/sja1000/plx_pci.c
> +++ b/drivers/net/can/sja1000/plx_pci.c
> @@ -609,15 +609,4 @@ static struct pci_driver plx_pci_driver = {
> .remove = plx_pci_del_card,
> };
>
> -static int __init plx_pci_init(void)
> -{
> - return pci_register_driver(&plx_pci_driver);
> -}
> -
> -static void __exit plx_pci_exit(void)
> -{
> - pci_unregister_driver(&plx_pci_driver);
> -}
> -
> -module_init(plx_pci_init);
> -module_exit(plx_pci_exit);
> +module_pci_driver(plx_pci_driver);
^ permalink raw reply
* Re: [PATCH 1/3] net/can: use module_pci_driver
From: David Miller @ 2012-04-16 18:57 UTC (permalink / raw)
To: socketcan; +Cc: mkl, axel.lin, netdev, wg, linux-can
In-Reply-To: <4F8C6AFC.30601@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Mon, 16 Apr 2012 20:54:52 +0200
> Hello Dave,
>
> i've seen that you applied the two pci simplifications from Axel Lin to the
> net-next tree
>
> http://patchwork.ozlabs.org/patch/152473/
> http://patchwork.ozlabs.org/patch/152474/
>
> ... but only this one is marked 'awaiting upstream' ?
>
> http://patchwork.ozlabs.org/patch/152472/
>
> What does this mean? Should Marc process this patch separately via his
> can-next tree?
Yes.
^ permalink raw reply
* Re: [PATCH v17 01/15] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs
From: Rob Landley @ 2012-04-16 19:11 UTC (permalink / raw)
To: mtk.manpages
Cc: Jonathan Corbet, Andrew Lutomirski, Andrew Morton, Will Drewry,
linux-kernel, linux-security-module, linux-arch, linux-doc,
kernel-hardening, netdev, x86, arnd, davem, hpa, mingo, oleg,
peterz, rdunlap, mcgrathr, tglx, eparis, serge.hallyn, djm,
scarybeasts, indan, pmoore, eric.dumazet, markus, coreyb,
keescook, jmorris, Andy Lutomirski, linux-man
In-Reply-To: <CAKgNAkhhnC1+vdh7vTYKkngzxHccDwHH_aKF5wCNhga33BGhyQ@mail.gmail.com>
On 04/11/2012 02:31 PM, Michael Kerrisk (man-pages) wrote:
> On Sat, Apr 7, 2012 at 8:28 AM, Jonathan Corbet <corbet@lwn.net> wrote:
>> On Fri, 6 Apr 2012 13:01:17 -0700
>> Andrew Lutomirski <luto@mit.edu> wrote:
>>
>>> This has been bugging me for awhile. Is there any interest in moving
>>> the manpages into the kernel source tree? Then there could be a
>>> general requirement that new APIs get documented when they're written.
>>
>> Man page (or other documentation) requirements for patch acceptance are a
>> regular kernel summit feature. People seem to think it's a good idea, but
>> actual enforcement of such requirements always seems to be lacking. Lots
>> of people have kind of given up trying. I don't really see that adding
>> the man pages to the tree would help, but I could be wrong...
>
> I largely consider this (moving man pages to kernel.org) a technical
> solution to what is fundamentally a social problem (developers
> reluctant to write documentation), and doubt that the technical
> solution would make much difference.
*nod* *nod*
> I'd love to be proved wrong, but
> the experiment would require significant start-up effort. (My
> collected thoughts on this can be found here:
> http://www.kernel.org/doc/man-pages/todo.html#migrate_to_kernel_source.
> Note the alternative idea of patch tags mentioned at the end of that
> text.)
>
> Unless, or until there's a paid maintainer, I don't expect things to
> get significantly better than what they currently are.
Maintainer of which, the man pages or the kernel Documentation directory?
I just got handed the Documentation ball (right as relatives were
visiting and a couple days before buying a new house, so I've just put
_tons_ of time into it so far). I have grandiose plans for cleaning it
up, but first I need to get my kernel.org account working again.
That said, I think having man-pages in the kernel directory is a bad
idea, for reasons I already posted to this thread.
> The quite
> significant improvements in man-pages since 2004, when I became
> maintainer were in small part due to the fact that I was for a short
> period paid to do the work, but in much larger part due to a huge
> private effort over those years which over the last couple of years is
> no longer unsustainable for me (man-pages is in competition with
> requirements for my attention from family, working life, and
> (seriously!) seismic events),
Heh, I know the feeling. :)
Circa 2007 I was paid to work on documentation for half a year (hence
the http://kernel.org/doc directory I stopped being able to update when
kernel.org got hacked). These days it competes with my toybox and
aboriginal linux projects, and with my day job.
The way I'm looking at it is I'm _curating_ documentation. I'm acting
as some kind of of librarian, and my first goal is reshuffling the files
in Documentation into some semblance of order so you can see what's
there. (I've posted about that before here, moving
architecture-specific stuff under an arch subdirectory and so on.)
I do sometimes write new documentation, but no human being knows
everything there is to know about the kernel. Building expertise is
enormously time consuming,
That said, if anything was going to move into the kernel moving the
syscall info into javadoc might make sense.
Something that might help you is the syscall mining script snippet I
posted last time:
find . -name "*.c" -print0 | \
xargs -n1 -0 sed -n -e 's/.*\(SYSCALL_DEFINE[0-9](\)/\1/' \
-e 't got;d;:got;s/).*/)/p;t;N;b got'
I might be able to build a script around that which would look up the
system call number, figure out which architectures implement this call,
find any javadoc at the call site, and so on. That way we could automate
this a bit. For example, kernel/fork.c has two syscalls:
SYSCALL_DEFINE1(set_tid_address, int __user *, tidptr)
/*
* unshare allows a process to 'unshare' part of the process
* context which was originally shared using clone. copy_*
* functions used by do_fork() cannot be used here directly
* because they modify an inactive task_struct that is being
* constructed. Here we are modifying the current, active,
* task_struct.
*/
SYSCALL_DEFINE1(unshare, unsigned long, unshare_flags)
Both of these have man pages which provide way more info than the
comments (if any). Is there any sort of javadoc comment before the
syscall that might provide useful information you could automatically
harvest? Some sort of standard header briefly defining the syscall?
(P.S. Speaking of man 2 unshare, what's with the #define _GNU_SOURCE for
a new linux kernel syscall? What the heck does the FSF have to do with
anything? This didn't used to be needed in ubuntu 10.04 but then the
headers changed to match the man page, which I found sad...)
> Cheers,
>
> Michael
Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
^ permalink raw reply
* Re: SV: Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer address. Bug or feature?
From: Denys Fedoryshchenko @ 2012-04-16 19:11 UTC (permalink / raw)
To: David Miller; +Cc: stian, eric.dumazet, stephen.hemminger, netdev
In-Reply-To: <20120416.144005.2201460378756236307.davem@davemloft.net>
On 2012-04-16 21:40, David Miller wrote:
> From: Denys Fedoryshchenko <denys@visp.net.lb>
> Date: Mon, 16 Apr 2012 13:37:14 +0300
>
>> So the only solution is to fetch first, then keep full routing table
>> in userspace also, and keep tracking if local addresses deleted, and
>> do the same in userspace and check for prefsrc...
>
> You don't need to keep full routing table in userspace, don't be
> silly.
>
> You only need to watch for the device down event, and purge in
> userspace based upon that key.
In my specific case i should. Userspace should just send information
that some ip came or gone on specific access server, to central node (i
am not reinventing dynamic routing protocols, there is another reasons
for that). Central node don't know anything about interfaces. Access
server i was expecting to not keep anything, and just relay netlink
routing messages, route to specific ip are appearing and disappearing.
Because it is not possible i will just keep as you mentioned table, with
ip+device+prefsrc, and listen to other than routing netlink events.
As i mention before, it is not big deal to do that, and i understood
that it is not a "netlink/kernel bug", but a reasonable design choice.
I posted it, just to share my view, so in future people who have
similar question, as Stian Skjelstad had, will have more information.
^ permalink raw reply
* Re: Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer address. Bug or feature?
From: Stephen Hemminger @ 2012-04-16 19:29 UTC (permalink / raw)
To: David Miller; +Cc: denys, stian, eric.dumazet, stephen.hemminger, netdev
In-Reply-To: <20120416.144005.2201460378756236307.davem@davemloft.net>
On Mon, 16 Apr 2012 14:40:05 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:
> From: Denys Fedoryshchenko <denys@visp.net.lb>
> Date: Mon, 16 Apr 2012 13:37:14 +0300
>
> > So the only solution is to fetch first, then keep full routing table
> > in userspace also, and keep tracking if local addresses deleted, and
> > do the same in userspace and check for prefsrc...
>
> You don't need to keep full routing table in userspace, don't be
> silly.
Quagga does (in multiple daemons) and uses this to manage
route distribution and recursive routes.
> You only need to watch for the device down event, and purge in
> userspace based upon that key.
^ permalink raw reply
* pull request: linux-can-next 2012-04-16
From: Marc Kleine-Budde @ 2012-04-16 19:32 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-can, kernel
Hello David,
first round of linux-can updates for net-next, including a sparse warning
fix and the conversion of the pci drivers to use module_pci_driver.
The following changes since commit f4f9f6e75d67ddfcfea79a2108217bc654aef3af:
tcp: restore formatting of macros for tcp_skb_cb sacked field (2012-04-16 14:38:16 -0400)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can-next.git master
Axel Lin (1):
net/can: use module_pci_driver
Daniel Baluta (1):
can: fix sparse warning for cgw_list
drivers/net/can/pch_can.c | 12 +-----------
drivers/net/can/sja1000/ems_pci.c | 14 +-------------
drivers/net/can/sja1000/kvaser_pci.c | 13 +------------
drivers/net/can/sja1000/peak_pci.c | 12 +-----------
drivers/net/can/sja1000/plx_pci.c | 13 +------------
net/can/gw.c | 2 +-
^ permalink raw reply
* [PATCH 1/2] can: fix sparse warning for cgw_list
From: Marc Kleine-Budde @ 2012-04-16 19:32 UTC (permalink / raw)
To: davem
Cc: netdev, linux-can, kernel, Daniel Baluta, Daniel Baluta,
Marc Kleine-Budde
In-Reply-To: <1334604746-24556-1-git-send-email-mkl@pengutronix.de>
From: Daniel Baluta <daniel.baluta@gmail.com>
Make cgw_list static to remove the following sparse warning:
net/can/gw.c:69:1: warning: symbol 'cgw_list' was not declared.
Should it be static?
Signed-off-by: Daniel Baluta <dbaluta@ixiacom.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
net/can/gw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/can/gw.c b/net/can/gw.c
index 3d79b12..b41acf2 100644
--- a/net/can/gw.c
+++ b/net/can/gw.c
@@ -66,7 +66,7 @@ MODULE_LICENSE("Dual BSD/GPL");
MODULE_AUTHOR("Oliver Hartkopp <oliver.hartkopp@volkswagen.de>");
MODULE_ALIAS("can-gw");
-HLIST_HEAD(cgw_list);
+static HLIST_HEAD(cgw_list);
static struct notifier_block notifier;
static struct kmem_cache *cgw_cache __read_mostly;
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/2] net/can: use module_pci_driver
From: Marc Kleine-Budde @ 2012-04-16 19:32 UTC (permalink / raw)
To: davem
Cc: netdev, linux-can, kernel, Axel Lin, Wolfgang Grandegger,
Marc Kleine-Budde
In-Reply-To: <1334604746-24556-1-git-send-email-mkl@pengutronix.de>
From: Axel Lin <axel.lin@gmail.com>
This patch converts the drivers in drivers/net/can/* to use
module_pci_driver() macro which makes the code smaller and a bit simpler.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-can@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/pch_can.c | 12 +-----------
drivers/net/can/sja1000/ems_pci.c | 14 +-------------
drivers/net/can/sja1000/kvaser_pci.c | 13 +------------
drivers/net/can/sja1000/peak_pci.c | 12 +-----------
drivers/net/can/sja1000/plx_pci.c | 13 +------------
5 files changed, 5 insertions(+), 59 deletions(-)
diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
index 2bb215e..1226297 100644
--- a/drivers/net/can/pch_can.c
+++ b/drivers/net/can/pch_can.c
@@ -1274,17 +1274,7 @@ static struct pci_driver pch_can_pci_driver = {
.resume = pch_can_resume,
};
-static int __init pch_can_pci_init(void)
-{
- return pci_register_driver(&pch_can_pci_driver);
-}
-module_init(pch_can_pci_init);
-
-static void __exit pch_can_pci_exit(void)
-{
- pci_unregister_driver(&pch_can_pci_driver);
-}
-module_exit(pch_can_pci_exit);
+module_pci_driver(pch_can_pci_driver);
MODULE_DESCRIPTION("Intel EG20T PCH CAN(Controller Area Network) Driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/net/can/sja1000/ems_pci.c b/drivers/net/can/sja1000/ems_pci.c
index 36f4f97..5c6d412 100644
--- a/drivers/net/can/sja1000/ems_pci.c
+++ b/drivers/net/can/sja1000/ems_pci.c
@@ -371,16 +371,4 @@ static struct pci_driver ems_pci_driver = {
.remove = ems_pci_del_card,
};
-static int __init ems_pci_init(void)
-{
- return pci_register_driver(&ems_pci_driver);
-}
-
-static void __exit ems_pci_exit(void)
-{
- pci_unregister_driver(&ems_pci_driver);
-}
-
-module_init(ems_pci_init);
-module_exit(ems_pci_exit);
-
+module_pci_driver(ems_pci_driver);
diff --git a/drivers/net/can/sja1000/kvaser_pci.c b/drivers/net/can/sja1000/kvaser_pci.c
index ed004ce..23ed6ea 100644
--- a/drivers/net/can/sja1000/kvaser_pci.c
+++ b/drivers/net/can/sja1000/kvaser_pci.c
@@ -397,15 +397,4 @@ static struct pci_driver kvaser_pci_driver = {
.remove = __devexit_p(kvaser_pci_remove_one),
};
-static int __init kvaser_pci_init(void)
-{
- return pci_register_driver(&kvaser_pci_driver);
-}
-
-static void __exit kvaser_pci_exit(void)
-{
- pci_unregister_driver(&kvaser_pci_driver);
-}
-
-module_init(kvaser_pci_init);
-module_exit(kvaser_pci_exit);
+module_pci_driver(kvaser_pci_driver);
diff --git a/drivers/net/can/sja1000/peak_pci.c b/drivers/net/can/sja1000/peak_pci.c
index 5f92b86..f0a1296 100644
--- a/drivers/net/can/sja1000/peak_pci.c
+++ b/drivers/net/can/sja1000/peak_pci.c
@@ -749,14 +749,4 @@ static struct pci_driver peak_pci_driver = {
.remove = __devexit_p(peak_pci_remove),
};
-static int __init peak_pci_init(void)
-{
- return pci_register_driver(&peak_pci_driver);
-}
-module_init(peak_pci_init);
-
-static void __exit peak_pci_exit(void)
-{
- pci_unregister_driver(&peak_pci_driver);
-}
-module_exit(peak_pci_exit);
+module_pci_driver(peak_pci_driver);
diff --git a/drivers/net/can/sja1000/plx_pci.c b/drivers/net/can/sja1000/plx_pci.c
index a227586..8bc9598 100644
--- a/drivers/net/can/sja1000/plx_pci.c
+++ b/drivers/net/can/sja1000/plx_pci.c
@@ -609,15 +609,4 @@ static struct pci_driver plx_pci_driver = {
.remove = plx_pci_del_card,
};
-static int __init plx_pci_init(void)
-{
- return pci_register_driver(&plx_pci_driver);
-}
-
-static void __exit plx_pci_exit(void)
-{
- pci_unregister_driver(&plx_pci_driver);
-}
-
-module_init(plx_pci_init);
-module_exit(plx_pci_exit);
+module_pci_driver(plx_pci_driver);
--
1.7.4.1
^ permalink raw reply related
* [PATCH] can: usb: PCAN-USB Pro: fix mem leaks in pcan_usb_pro_init() on error paths
From: Marc Kleine-Budde @ 2012-04-16 19:43 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-can, kernel, Jesper Juhl, Marc Kleine-Budde
In-Reply-To: <1334605388-1549-1-git-send-email-mkl@pengutronix.de>
From: Jesper Juhl <jj@chaosbits.net>
If either call to pcan_usb_pro_send_req() in
drivers/net/can/usb/peak_usb/pcan_usb_pro.c::pcan_usb_pro_init()
fails, we'll leak the memory we allocated to 'usb_if' with kzalloc()
when the 'usb_if' variable goes out of scope without having been
assigned to anything as we 'return err;'.
Fix this by adding appropriate kfree(usb_if) calls to the error paths.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Stephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/peak_usb/pcan_usb_pro.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_pro.c b/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
index 5234586..629c4ba 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
@@ -875,6 +875,7 @@ static int pcan_usb_pro_init(struct peak_usb_device *dev)
PCAN_USBPRO_INFO_FW,
&fi, sizeof(fi));
if (err) {
+ kfree(usb_if);
dev_err(dev->netdev->dev.parent,
"unable to read %s firmware info (err %d)\n",
pcan_usb_pro.name, err);
@@ -885,6 +886,7 @@ static int pcan_usb_pro_init(struct peak_usb_device *dev)
PCAN_USBPRO_INFO_BL,
&bi, sizeof(bi));
if (err) {
+ kfree(usb_if);
dev_err(dev->netdev->dev.parent,
"unable to read %s bootloader info (err %d)\n",
pcan_usb_pro.name, err);
--
1.7.4.1
^ permalink raw reply related
* pull request: linux-can 2012-04-16
From: Marc Kleine-Budde @ 2012-04-16 19:43 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-can, kernel
Hello David,
there's a fix targetting net/master from Jesper Juhl, fixing a mem leak
in the error path of the pcan_usb_pro driver.
redards,
Marc
The following changes since commit 8a9a0ea6032186e3030419262678d652b88bf6a8:
net/ethernet: ks8851_mll fix rx frame buffer overflow (2012-04-14 15:21:27 -0400)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can.git master
Jesper Juhl (1):
can: usb: PCAN-USB Pro: fix mem leaks in pcan_usb_pro_init() on error paths
drivers/net/can/usb/peak_usb/pcan_usb_pro.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
^ permalink raw reply
* Re: [PATCH v3] mac80211: Support on-channel scan option.
From: Johannes Berg @ 2012-04-16 19:58 UTC (permalink / raw)
To: Ben Greear
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4F8C59B2.20207-my8/4N5VtI7c+919tysfdA@public.gmane.org>
On 4/16/2012 10:41 AM, Ben Greear wrote:
>>> + if ((req->channels[0]->flags&
>>> + IEEE80211_CHAN_PASSIVE_SCAN) ||
>>> + !local->scan_req->n_ssids) {
>>
>> That formatting is a bit off it seems. Or is that just my mailer?
>
> Well, it looked OK to me..though when I replied my mailer
> certainly made it look funky. I'll re-run it through checkpatch
> just in case.
It just seemed the & should have a space in front, and it could be on a
single line with the constant? Anyway, I'm using thunderbird right now
and don't know what kind of messes it makes.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Netlink, route monitoring, RTM_DELROUTE not issued for ppp peer address. Bug or feature?
From: Stian Skjelstad @ 2012-04-16 20:21 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: Stephen Hemminger, Stian Skjelstad, eric.dumazet,
stephen.hemminger, netdev
In-Reply-To: <9c375f4b88835bcde92bf3ba8f3434cc@visp.net.lb>
> It looks like "correct" behavior should not harm existing programs that
> much (just there will be netlink message to delete route that are
> already deleted by program, e.g. quagga), but looking to code,
> implementing this feature will make significant overhead and in some
> cases it can be harmful.
> For example if full view BGP interface dropped, it is hundreds of
> thousands netlink messages. So seems better i will listen to
> address/link changes also and keep routing table in memory.
> So better seems to keep as is.
If I understand correct, the "missing" RTM_DELROUTE messages actually
comes from something similar to "ip route flush dev eth0".
If the amount of traffic is a worry, couldn't there be a RTM_FLUSHROUTE or
a special RTM_DELROUTE message that tells that all routes for a given
device is removed?
Stian Skjelstad
^ 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