* Re: [PATCH] rds: Don't disable BH on BH context
From: David Miller @ 2012-08-23 5:52 UTC (permalink / raw)
To: ying.xue; +Cc: venkat.x.venkatsubra, netdev
In-Reply-To: <1345448648-30449-1-git-send-email-ying.xue@windriver.com>
From: Ying Xue <ying.xue@windriver.com>
Date: Mon, 20 Aug 2012 15:44:08 +0800
> Since we have already in BH context when *_write_space(),
> *_data_ready() as well as *_state_change() are called, it's
> unnecessary to disable BH.
>
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH v8] bonding: support for IPv6 transmit hashing
From: David Miller @ 2012-08-23 5:49 UTC (permalink / raw)
To: linux; +Cc: netdev
In-Reply-To: <2e01d8f94c42c61af9886683a4c35caf6816bc3d.1345615999.git.linux@8192.net>
From: John Eaglesham <linux@8192.net>
Date: Tue, 21 Aug 2012 23:43:35 -0700
> From: John Eaglesham <linux@8192.net>
>
> Currently the "bonding" driver does not support load balancing outgoing
> traffic in LACP mode for IPv6 traffic. IPv4 (and TCP or UDP over IPv4)
> are currently supported; this patch adds transmit hashing for IPv6 (and
> TCP or UDP over IPv6), bringing IPv6 up to par with IPv4 support in the
> bonding driver. In addition, bounds checking has been added to all
> transmit hashing functions.
>
> The algorithm chosen (xor'ing the bottom three quads of the source and
> destination addresses together, then xor'ing each byte of that result into
> the bottom byte, finally xor'ing with the last bytes of the MAC addresses)
> was selected after testing almost 400,000 unique IPv6 addresses harvested
> from server logs. This algorithm had the most even distribution for both
> big- and little-endian architectures while still using few instructions. Its
> behavior also attempts to closely match that of the IPv4 algorithm.
>
> The IPv6 flow label was intentionally not included in the hash as it appears
> to be unset in the vast majority of IPv6 traffic sampled, and the current
> algorithm not using the flow label already offers a very even distribution.
>
> Fragmented IPv6 packets are handled the same way as fragmented IPv4 packets,
> ie, they are not balanced based on layer 4 information. Additionally,
> IPv6 packets with intermediate headers are not balanced based on layer
> 4 information. In practice these intermediate headers are not common and
> this should not cause any problems, and the alternative (a packet-parsing
> loop and look-up table) seemed slow and complicated for little gain.
>
> Tested-by: John Eaglesham <linux@8192.net>
> Signed-off-by: John Eaglesham <linux@8192.net>
Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: gre: fix ip6gre_err()
From: David Miller @ 2012-08-23 5:48 UTC (permalink / raw)
To: eric.dumazet; +Cc: xeb, netdev
In-Reply-To: <1345384050.5158.208.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 19 Aug 2012 15:47:30 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> ip6gre_err() miscomputes grehlen (sizeof(ipv6h) is 4 or 8,
> not 40 as expected), and should take into account 'offset' parameter.
>
> Also uses pskb_may_pull() to cope with some fragged skbs
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Dmitry Kozlov <xeb@mail.ru>
Applied, thanks Eric.
^ permalink raw reply
* Re: [RFC] Interface for TCP Metrics
From: David Miller @ 2012-08-23 5:47 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <alpine.LFD.2.00.1208191402560.1893@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Sun, 19 Aug 2012 14:42:15 +0300 (EEST)
> - will use genl with TCP_METRICS_GENL_NAME "tcp_metrics",
> TCP_METRICS_GENL_VERSION 0x01
Sounds good.
> - provide dumpit method and one cmd to read metrics by exact addr,
> will use TCP_METRICS_CMD_{GET,...} and TCP_METRICS_ATTR_xxx in
> new file include/linux/tcp_metrics.h
Ok.
Eric thinks we can filter in userspace, but since it's so easy to
lookup entries in the kernel and the demux for that is already there,
I have no objections to have a bonafide netlink operation for
getting a single entry.
> - Is command to delete cached entry needed? Delete will need
> new rcu_head. Useful to flush the cache or to delete entries
> with filter.
Having a way to flush the entire table is useful. Specific entries,
is less useful.
> - without support for delete cmd, may be we can add command to
> reset entry with default values from dst?
>
> - Where to put the new netlink code?
> tcp_metrics_netlink.c
> tcp_metrics_nl.c
> or just in current tcp_metrics.c ?
Put it in tcp_metrics.c, that way we don't need to export any
internals.
> - command to modify specific metric for addr, by name? Only
> for tcpm_vals? If not locked?
>
> Do we need modify/delete/reset support or just read
> support is enough? Comments?
I would say that you can support fancy things as long as new
locking constraints are not added.
^ permalink raw reply
* Re: [PATCH net-next] xfrm: fix RCU bugs
From: David Miller @ 2012-08-23 5:40 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, fan.du, fengguang.wu, Priyanka.Jain
In-Reply-To: <1345372308.5158.54.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 19 Aug 2012 12:31:48 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> This patch reverts commit 56892261ed1a (xfrm: Use rcu_dereference_bh to
> deference pointer protected by rcu_read_lock_bh), and fixes bugs
> introduced in commit 418a99ac6ad ( Replace rwlock on xfrm_policy_afinfo
> with rcu )
>
> 1) We properly use RCU variant in this file, not a mix of RCU/RCU_BH
>
> 2) We must defer some writes after the synchronize_rcu() call or a reader
> can crash dereferencing NULL pointer.
>
> 3) Now we use the xfrm_policy_afinfo_lock spinlock only from process
> context, we no longer need to block BH in xfrm_policy_register_afinfo()
> and xfrm_policy_unregister_afinfo()
>
> 4) Can use RCU_INIT_POINTER() instead of rcu_assign_pointer() in
> xfrm_policy_unregister_afinfo()
>
> 5) Remove a forward inline declaration (xfrm_policy_put_afinfo()),
> and also move xfrm_policy_get_afinfo() declaration.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 2/2] [RFC] netlink: fix possible spoofing from non-root processes
From: David Miller @ 2012-08-23 4:53 UTC (permalink / raw)
To: pablo; +Cc: netdev
In-Reply-To: <20120820190915.GA3727@1984>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 20 Aug 2012 21:09:15 +0200
> On Sun, Aug 19, 2012 at 11:23:27PM +0200, Pablo Neira Ayuso wrote:
>> On Fri, Aug 17, 2012 at 07:22:29PM +0200, pablo@netfilter.org wrote:
>> [...]
>> > [ I don't know any FOSS program making use of Netlink to communicate
>> > to processes, please, let me know if I'm missing anyone important ]
>>
>> Patrick pinged me for little reminder on NETLINK_USERSOCK. We still
>> have to allow netlink-to-netlink userspace communication for it.
>>
>> So, please find a new version of this patch that allows non-root
>> processes for that Netlink bus. For others, my patch restricts to root
>> processes the ability of sending messages with dst_pid != 0.
>
> Sorry, I just noticed that you cannot apply this to your net tree
> since it depends on patch 1/2 which is not a fix.
>
> I'll get back to you with one path that you can apply to your net
> tree.
>
> I'll resend 1/2 later to net-next once this has been sorted out.
Ok, waiting for new versions of these patches, thanks.
^ permalink raw reply
* wireless router performance differ with 2.4Ghz vs 5.0Ghz frequency
From: Lin Ming @ 2012-08-23 4:50 UTC (permalink / raw)
To: linux-wireless; +Cc: networking
Hi list,
I have a wireless router with 2 wireless cards: 2.4Ghz and 5.0Ghz frequency.
The performance for 2.4Ghz is much worse than 5.0Ghz.
Does the frequency affect performance so much?
Thanks,
Lin Ming
^ permalink raw reply
* Re: [PATCH net-next v3] net: remove delay at device dismantle
From: David Miller @ 2012-08-23 4:50 UTC (permalink / raw)
To: gaofeng; +Cc: eric.dumazet, netdev, maheshb, therbert, ebiederm
In-Reply-To: <5035B27F.9060002@cn.fujitsu.com>
From: Gao feng <gaofeng@cn.fujitsu.com>
Date: Thu, 23 Aug 2012 12:33:03 +0800
> 于 2012年08月23日 11:19, Eric Dumazet 写道:
>> From: Eric Dumazet <edumazet@google.com>
>>
>> I noticed extra one second delay in device dismantle, tracked down to
>> a call to dst_dev_event() while some call_rcu() are still in RCU queues.
>>
>> These call_rcu() were posted by rt_free(struct rtable *rt) calls.
>>
>> We then wait a little (but one second) in netdev_wait_allrefs() before
>> kicking again NETDEV_UNREGISTER.
>>
>> As the call_rcu() are now completed, dst_dev_event() can do the needed
>> device swap on busy dst.
>>
>> To solve this problem, add a new NETDEV_UNREGISTER_FINAL, called
>> after a rcu_barrier(), but outside of RTNL lock.
>>
>> Use NETDEV_UNREGISTER_FINAL with care !
>>
>> Change dst_dev_event() handler to react to NETDEV_UNREGISTER_FINAL
>>
>> Also remove NETDEV_UNREGISTER_BATCH, as its not used anymore after
>> IP cache removal.
>>
>> With help from Gao feng
>>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Cc: Tom Herbert <therbert@google.com>
>> Cc: Mahesh Bandewar <maheshb@google.com>
>> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
>> Cc: Gao feng <gaofeng@cn.fujitsu.com>
>
> looks good to me, the lockdep warning message disappeared.
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-next v3] net: remove delay at device dismantle
From: Gao feng @ 2012-08-23 4:33 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, maheshb, therbert, ebiederm
In-Reply-To: <1345691986.5904.40.camel@edumazet-glaptop>
于 2012年08月23日 11:19, Eric Dumazet 写道:
> From: Eric Dumazet <edumazet@google.com>
>
> I noticed extra one second delay in device dismantle, tracked down to
> a call to dst_dev_event() while some call_rcu() are still in RCU queues.
>
> These call_rcu() were posted by rt_free(struct rtable *rt) calls.
>
> We then wait a little (but one second) in netdev_wait_allrefs() before
> kicking again NETDEV_UNREGISTER.
>
> As the call_rcu() are now completed, dst_dev_event() can do the needed
> device swap on busy dst.
>
> To solve this problem, add a new NETDEV_UNREGISTER_FINAL, called
> after a rcu_barrier(), but outside of RTNL lock.
>
> Use NETDEV_UNREGISTER_FINAL with care !
>
> Change dst_dev_event() handler to react to NETDEV_UNREGISTER_FINAL
>
> Also remove NETDEV_UNREGISTER_BATCH, as its not used anymore after
> IP cache removal.
>
> With help from Gao feng
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Tom Herbert <therbert@google.com>
> Cc: Mahesh Bandewar <maheshb@google.com>
> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> Cc: Gao feng <gaofeng@cn.fujitsu.com>
looks good to me, the lockdep warning message disappeared.
^ permalink raw reply
* [PATCH net-next v3] net: remove delay at device dismantle
From: Eric Dumazet @ 2012-08-23 3:19 UTC (permalink / raw)
To: David Miller; +Cc: gaofeng, netdev, maheshb, therbert, ebiederm
From: Eric Dumazet <edumazet@google.com>
I noticed extra one second delay in device dismantle, tracked down to
a call to dst_dev_event() while some call_rcu() are still in RCU queues.
These call_rcu() were posted by rt_free(struct rtable *rt) calls.
We then wait a little (but one second) in netdev_wait_allrefs() before
kicking again NETDEV_UNREGISTER.
As the call_rcu() are now completed, dst_dev_event() can do the needed
device swap on busy dst.
To solve this problem, add a new NETDEV_UNREGISTER_FINAL, called
after a rcu_barrier(), but outside of RTNL lock.
Use NETDEV_UNREGISTER_FINAL with care !
Change dst_dev_event() handler to react to NETDEV_UNREGISTER_FINAL
Also remove NETDEV_UNREGISTER_BATCH, as its not used anymore after
IP cache removal.
With help from Gao feng
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Tom Herbert <therbert@google.com>
Cc: Mahesh Bandewar <maheshb@google.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Gao feng <gaofeng@cn.fujitsu.com>
---
v3: Gao Feng reported a lockdep issue.
I had to change some notifiers to check NETDEV_UNREGISTER_FINAL
v2: NETDEV_UNREGISTER_FINAL called outside of rtnl lock
as its more risky, base this patch on net-next
include/linux/netdevice.h | 2 +-
net/core/dev.c | 22 ++++++++--------------
net/core/dst.c | 2 +-
net/core/fib_rules.c | 3 ++-
net/core/rtnetlink.c | 2 +-
net/ipv4/devinet.c | 6 +++++-
net/ipv4/fib_frontend.c | 8 ++++----
net/ipv6/addrconf.c | 6 +++++-
8 files changed, 27 insertions(+), 24 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 4936f09..9ad7fa8 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1553,7 +1553,7 @@ struct packet_type {
#define NETDEV_PRE_TYPE_CHANGE 0x000E
#define NETDEV_POST_TYPE_CHANGE 0x000F
#define NETDEV_POST_INIT 0x0010
-#define NETDEV_UNREGISTER_BATCH 0x0011
+#define NETDEV_UNREGISTER_FINAL 0x0011
#define NETDEV_RELEASE 0x0012
#define NETDEV_NOTIFY_PEERS 0x0013
#define NETDEV_JOIN 0x0014
diff --git a/net/core/dev.c b/net/core/dev.c
index 088923f..0640d2a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1406,7 +1406,6 @@ rollback:
nb->notifier_call(nb, NETDEV_DOWN, dev);
}
nb->notifier_call(nb, NETDEV_UNREGISTER, dev);
- nb->notifier_call(nb, NETDEV_UNREGISTER_BATCH, dev);
}
}
@@ -1448,7 +1447,6 @@ int unregister_netdevice_notifier(struct notifier_block *nb)
nb->notifier_call(nb, NETDEV_DOWN, dev);
}
nb->notifier_call(nb, NETDEV_UNREGISTER, dev);
- nb->notifier_call(nb, NETDEV_UNREGISTER_BATCH, dev);
}
}
unlock:
@@ -1468,7 +1466,8 @@ EXPORT_SYMBOL(unregister_netdevice_notifier);
int call_netdevice_notifiers(unsigned long val, struct net_device *dev)
{
- ASSERT_RTNL();
+ if (val != NETDEV_UNREGISTER_FINAL)
+ ASSERT_RTNL();
return raw_notifier_call_chain(&netdev_chain, val, dev);
}
EXPORT_SYMBOL(call_netdevice_notifiers);
@@ -5331,10 +5330,6 @@ static void rollback_registered_many(struct list_head *head)
netdev_unregister_kobject(dev);
}
- /* Process any work delayed until the end of the batch */
- dev = list_first_entry(head, struct net_device, unreg_list);
- call_netdevice_notifiers(NETDEV_UNREGISTER_BATCH, dev);
-
synchronize_net();
list_for_each_entry(dev, head, unreg_list)
@@ -5787,9 +5782,8 @@ static void netdev_wait_allrefs(struct net_device *dev)
/* Rebroadcast unregister notification */
call_netdevice_notifiers(NETDEV_UNREGISTER, dev);
- /* don't resend NETDEV_UNREGISTER_BATCH, _BATCH users
- * should have already handle it the first time */
-
+ rcu_barrier();
+ call_netdevice_notifiers(NETDEV_UNREGISTER_FINAL, dev);
if (test_bit(__LINK_STATE_LINKWATCH_PENDING,
&dev->state)) {
/* We must not have linkwatch events
@@ -5851,9 +5845,8 @@ void netdev_run_todo(void)
__rtnl_unlock();
- /* Wait for rcu callbacks to finish before attempting to drain
- * the device list. This usually avoids a 250ms wait.
- */
+
+ /* Wait for rcu callbacks to finish before next phase */
if (!list_empty(&list))
rcu_barrier();
@@ -5862,6 +5855,8 @@ void netdev_run_todo(void)
= list_first_entry(&list, struct net_device, todo_list);
list_del(&dev->todo_list);
+ call_netdevice_notifiers(NETDEV_UNREGISTER_FINAL, dev);
+
if (unlikely(dev->reg_state != NETREG_UNREGISTERING)) {
pr_err("network todo '%s' but state %d\n",
dev->name, dev->reg_state);
@@ -6256,7 +6251,6 @@ int dev_change_net_namespace(struct net_device *dev, struct net *net, const char
the device is just moving and can keep their slaves up.
*/
call_netdevice_notifiers(NETDEV_UNREGISTER, dev);
- call_netdevice_notifiers(NETDEV_UNREGISTER_BATCH, dev);
rtmsg_ifinfo(RTM_DELLINK, dev, ~0U);
/*
diff --git a/net/core/dst.c b/net/core/dst.c
index 56d6361..f6593d2 100644
--- a/net/core/dst.c
+++ b/net/core/dst.c
@@ -374,7 +374,7 @@ static int dst_dev_event(struct notifier_block *this, unsigned long event,
struct dst_entry *dst, *last = NULL;
switch (event) {
- case NETDEV_UNREGISTER:
+ case NETDEV_UNREGISTER_FINAL:
case NETDEV_DOWN:
mutex_lock(&dst_gc_mutex);
for (dst = dst_busy_list; dst; dst = dst->next) {
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index ab7db83..5850937 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -711,15 +711,16 @@ static int fib_rules_event(struct notifier_block *this, unsigned long event,
struct net *net = dev_net(dev);
struct fib_rules_ops *ops;
- ASSERT_RTNL();
switch (event) {
case NETDEV_REGISTER:
+ ASSERT_RTNL();
list_for_each_entry(ops, &net->rules_ops, list)
attach_rules(&ops->rules_list, dev);
break;
case NETDEV_UNREGISTER:
+ ASSERT_RTNL();
list_for_each_entry(ops, &net->rules_ops, list)
detach_rules(&ops->rules_list, dev);
break;
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 34d975b..c64efcf 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2358,7 +2358,7 @@ static int rtnetlink_event(struct notifier_block *this, unsigned long event, voi
case NETDEV_PRE_TYPE_CHANGE:
case NETDEV_GOING_DOWN:
case NETDEV_UNREGISTER:
- case NETDEV_UNREGISTER_BATCH:
+ case NETDEV_UNREGISTER_FINAL:
case NETDEV_RELEASE:
case NETDEV_JOIN:
break;
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index adf273f..6a5e6e4 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1147,8 +1147,12 @@ static int inetdev_event(struct notifier_block *this, unsigned long event,
void *ptr)
{
struct net_device *dev = ptr;
- struct in_device *in_dev = __in_dev_get_rtnl(dev);
+ struct in_device *in_dev;
+ if (event == NETDEV_UNREGISTER_FINAL)
+ goto out;
+
+ in_dev = __in_dev_get_rtnl(dev);
ASSERT_RTNL();
if (!in_dev) {
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 7f073a3..fd7d9ae 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -1041,7 +1041,7 @@ static int fib_inetaddr_event(struct notifier_block *this, unsigned long event,
static int fib_netdev_event(struct notifier_block *this, unsigned long event, void *ptr)
{
struct net_device *dev = ptr;
- struct in_device *in_dev = __in_dev_get_rtnl(dev);
+ struct in_device *in_dev;
struct net *net = dev_net(dev);
if (event == NETDEV_UNREGISTER) {
@@ -1050,9 +1050,11 @@ static int fib_netdev_event(struct notifier_block *this, unsigned long event, vo
return NOTIFY_DONE;
}
- if (!in_dev)
+ if (event == NETDEV_UNREGISTER_FINAL)
return NOTIFY_DONE;
+ in_dev = __in_dev_get_rtnl(dev);
+
switch (event) {
case NETDEV_UP:
for_ifa(in_dev) {
@@ -1071,8 +1073,6 @@ static int fib_netdev_event(struct notifier_block *this, unsigned long event, vo
case NETDEV_CHANGE:
rt_cache_flush(dev_net(dev), 0);
break;
- case NETDEV_UNREGISTER_BATCH:
- break;
}
return NOTIFY_DONE;
}
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 6bc85f7..e581009 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2566,10 +2566,14 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event,
void *data)
{
struct net_device *dev = (struct net_device *) data;
- struct inet6_dev *idev = __in6_dev_get(dev);
+ struct inet6_dev *idev;
int run_pending = 0;
int err;
+ if (event == NETDEV_UNREGISTER_FINAL)
+ return NOTIFY_DONE;
+
+ idev = __in6_dev_get(dev);
switch (event) {
case NETDEV_REGISTER:
if (!idev && dev->mtu >= IPV6_MIN_MTU) {
^ permalink raw reply related
* Re: [PATCH] net: dev: fix the incorrect hold of net namespace's lo device
From: Eric Dumazet @ 2012-08-23 3:13 UTC (permalink / raw)
To: Gao feng; +Cc: ebiederm, davem, netdev
In-Reply-To: <1345624786.5158.759.camel@edumazet-glaptop>
On Wed, 2012-08-22 at 10:39 +0200, Eric Dumazet wrote:
> rcu_barrier() at this place will kill some workloads.
For example, I tested the following one :
modprobe dummy numdummies=1000
time rmmod dummy
-> 16.5 seconds instead of 0.4 second
^ permalink raw reply
* Re: [PATCH] net: dev: fix the incorrect hold of net namespace's lo device
From: Gao feng @ 2012-08-23 3:09 UTC (permalink / raw)
To: Eric Dumazet; +Cc: ebiederm, davem, netdev
In-Reply-To: <1345634667.5158.1114.camel@edumazet-glaptop>
于 2012年08月22日 19:24, Eric Dumazet 写道:
> On Wed, 2012-08-22 at 19:00 +0800, Gao feng wrote:
>
>> Hi Eric
>>
>> I saw your patch and think this patch is clear and doesn't change too much logic.
>>
>> I test your patch, it not fix this problem.
>>
>> In my test case,when moving a net device to another net namespace,
>> Because you patch delete NETDEV_UNREGISTER event from dst_dev_event,
>> we will just put dst entries into the dst garbage list in event
>> NETDEV_DOWN,without call dst_ifdown to change these dst entries' device
>> to the lo device,and now this net device belongs to the new net namespace.
>>
>
> Then fix the "moving a net device to another net namespace", instead
> of slowing down other common operations.
>
okay, I will send a patch to fix this problem after your patch beeing applied.
> dev_change_net_namespace() is probably a better place to put your patch
>
>> After the net device beeing moved to another net namespace, I rmmod this
>> net device's driver,this will trigger the new added event NETDEV_UNREGISTER_FINISH,
>> so in dst_dev_event,we will change these dst entries's device to the new net
>> namespace's lo device,and this will make the referenct count of the new net namespace's
>> lo device incorrect. when we exit the new net namespace,this emg message is still exist.
>>
>> Message from syslogd@Donkey at Aug 22 18:50:13 ...
>> kernel:[ 1161.979036] unregister_netdevice: waiting for lo to become free. Usage count = 1
>>
>> And because net_mutex is locked here,so we can't create new net namespace.
>>
>>> rcu_barrier() at this place will kill some workloads.
>>>
>>
>> I think this will only add some workloads when unregister a net device.
>> Do I miss something?
>
> Yes, rcu_barrier() at this point is killing performance, because we hold
> RTNL.
>
> We worked hard to batch things, your patch is a huge step backward.
>
Get it,thanks for your explanation.
^ permalink raw reply
* Re: [PATCH net-next v2] net: remove delay at device dismantle
From: Eric Dumazet @ 2012-08-23 2:58 UTC (permalink / raw)
To: David Miller; +Cc: gaofeng, netdev, therbert, maheshb, ebiederm
In-Reply-To: <20120822.195111.765545116604962053.davem@davemloft.net>
On Wed, 2012-08-22 at 19:51 -0700, David Miller wrote:
> From: Gao feng <gaofeng@cn.fujitsu.com>
> > Hi Eric
> >
> > I got this warning message with your patch applied.
>
> Ok I won't push this out until this is resolved.
Thanks, I'll send a v2
^ permalink raw reply
* Re: [PATCH net-next v2] net: remove delay at device dismantle
From: David Miller @ 2012-08-23 2:51 UTC (permalink / raw)
To: gaofeng; +Cc: eric.dumazet, netdev, therbert, maheshb, ebiederm
In-Reply-To: <5035947C.8090609@cn.fujitsu.com>
From: Gao feng <gaofeng@cn.fujitsu.com>
Date: Thu, 23 Aug 2012 10:25:00 +0800
> 于 2012年08月11日 13:54, Eric Dumazet 写道:
>> On Fri, 2012-08-10 at 17:42 +0200, Eric Dumazet wrote:
>>> From: Eric Dumazet <edumazet@google.com>
>>>
>>> I noticed extra one second delay in device dismantle, tracked down to
>>> a call to dst_dev_event() while some call_rcu() are still in RCU queues.
>>>
>> ...
>>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>>> Cc: Tom Herbert <therbert@google.com>
>>> Cc: Mahesh Bandewar <maheshb@google.com>
>>> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
>>> ---
>>> v2: NETDEV_UNREGISTER_FINAL called outside of rtnl lock
>>> as its more risky, base this patch on net-next
>>
>> Also I am leaving for a one week vacation with no access to the
>> Internet, so better hold this patch until my return ;)
>>
>
> Hi Eric
>
> I got this warning message with your patch applied.
Ok I won't push this out until this is resolved.
^ permalink raw reply
* Re: [PATCH net-next v2] net: remove delay at device dismantle
From: Gao feng @ 2012-08-23 2:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Tom Herbert, Mahesh Bandewar,
Eric W. Biederman
In-Reply-To: <1344664487.5158.1.camel@edumazet-glaptop>
于 2012年08月11日 13:54, Eric Dumazet 写道:
> On Fri, 2012-08-10 at 17:42 +0200, Eric Dumazet wrote:
>> From: Eric Dumazet <edumazet@google.com>
>>
>> I noticed extra one second delay in device dismantle, tracked down to
>> a call to dst_dev_event() while some call_rcu() are still in RCU queues.
>>
> ...
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Cc: Tom Herbert <therbert@google.com>
>> Cc: Mahesh Bandewar <maheshb@google.com>
>> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
>> ---
>> v2: NETDEV_UNREGISTER_FINAL called outside of rtnl lock
>> as its more risky, base this patch on net-next
>
> Also I am leaving for a one week vacation with no access to the
> Internet, so better hold this patch until my return ;)
>
Hi Eric
I got this warning message with your patch applied.
Aug 22 18:32:56 Donkey kernel: [ 124.733048] ===============================
Aug 22 18:32:56 Donkey kernel: [ 124.733051] [ INFO: suspicious RCU usage. ]
Aug 22 18:32:56 Donkey kernel: [ 124.733054] 3.6.0-rc1+ #14 Not tainted
Aug 22 18:32:56 Donkey kernel: [ 124.733057] -------------------------------
Aug 22 18:32:56 Donkey kernel: [ 124.733060] include/linux/inetdevice.h:229 suspicious rcu_dereference_protected() usage!
Aug 22 18:32:56 Donkey kernel: [ 124.733062]
Aug 22 18:32:56 Donkey kernel: [ 124.733062] other info that might help us debug this:
Aug 22 18:32:56 Donkey kernel: [ 124.733062]
Aug 22 18:32:56 Donkey kernel: [ 124.733066]
Aug 22 18:32:56 Donkey kernel: [ 124.733066] rcu_scheduler_active = 1, debug_locks = 1
Aug 22 18:32:56 Donkey kernel: [ 124.733069] 3 locks held by kworker/u:1/39:
Aug 22 18:32:56 Donkey kernel: [ 124.733072] #0: (netns){.+.+.+}, at: [<ffffffff8107e117>] process_one_work+0x137/0x5d0
Aug 22 18:32:56 Donkey kernel: [ 124.733086] #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff8107e117>] process_one_work+0x137/0x5d0
Aug 22 18:32:56 Donkey kernel: [ 124.733095] #2: (net_mutex){+.+.+.}, at: [<ffffffff81542fd5>] cleanup_net+0x85/0x1a0
Aug 22 18:32:56 Donkey kernel: [ 124.733106]
Aug 22 18:32:56 Donkey kernel: [ 124.733106] stack backtrace:
Aug 22 18:32:56 Donkey kernel: [ 124.733110] Pid: 39, comm: kworker/u:1 Not tainted 3.6.0-rc1+ #14
Aug 22 18:32:56 Donkey kernel: [ 124.733112] Call Trace:
Aug 22 18:32:56 Donkey kernel: [ 124.733120] [<ffffffff810c2312>] lockdep_rcu_suspicious+0xe2/0x130
Aug 22 18:32:56 Donkey kernel: [ 124.733127] [<ffffffff815d35d4>] fib_netdev_event+0x114/0x180
Aug 22 18:32:56 Donkey kernel: [ 124.733133] [<ffffffff816914cc>] notifier_call_chain+0x5c/0x120
Aug 22 18:32:56 Donkey kernel: [ 124.733139] [<ffffffff8108d6b6>] raw_notifier_call_chain+0x16/0x20
Aug 22 18:32:56 Donkey kernel: [ 124.733144] [<ffffffff8154585c>] call_netdevice_notifiers+0x3c/0x70
Aug 22 18:32:56 Donkey kernel: [ 124.733149] [<ffffffff8154f88c>] netdev_run_todo+0x8c/0x280
Aug 22 18:32:56 Donkey kernel: [ 124.733154] [<ffffffff81544c9d>] ? synchronize_net+0x2d/0x40
Aug 22 18:32:56 Donkey kernel: [ 124.733159] [<ffffffff8155b90e>] rtnl_unlock+0xe/0x10
Aug 22 18:32:56 Donkey kernel: [ 124.733164] [<ffffffff81546c1a>] default_device_exit_batch+0xba/0xd0
Aug 22 18:32:56 Donkey kernel: [ 124.733170] [<ffffffff81542275>] ops_exit_list+0x55/0x60
Aug 22 18:32:56 Donkey kernel: [ 124.733175] [<ffffffff8154304b>] cleanup_net+0xfb/0x1a0
Aug 22 18:32:56 Donkey kernel: [ 124.733180] [<ffffffff8107e178>] process_one_work+0x198/0x5d0
Aug 22 18:32:56 Donkey kernel: [ 124.733185] [<ffffffff8107e117>] ? process_one_work+0x137/0x5d0
Aug 22 18:32:56 Donkey kernel: [ 124.733191] [<ffffffff8168b2b8>] ? __schedule+0x428/0x910
Aug 22 18:32:56 Donkey kernel: [ 124.733196] [<ffffffff81080951>] ? worker_thread+0x2a1/0x4b0
Aug 22 18:32:56 Donkey kernel: [ 124.733201] [<ffffffff81542f50>] ? net_drop_ns+0x50/0x50
Aug 22 18:32:56 Donkey kernel: [ 124.733207] [<ffffffff8108083a>] worker_thread+0x18a/0x4b0
Aug 22 18:32:56 Donkey kernel: [ 124.733212] [<ffffffff810806b0>] ? manage_workers+0x2a0/0x2a0
Aug 22 18:32:56 Donkey kernel: [ 124.733217] [<ffffffff810867de>] kthread+0xae/0xc0
Aug 22 18:32:56 Donkey kernel: [ 124.733222] [<ffffffff810c39cd>] ? trace_hardirqs_on+0xd/0x10
Aug 22 18:32:56 Donkey kernel: [ 124.733227] [<ffffffff81697044>] kernel_thread_helper+0x4/0x10
Aug 22 18:32:56 Donkey kernel: [ 124.733233] [<ffffffff8168d570>] ? retint_restore_args+0x13/0x13
Aug 22 18:32:56 Donkey kernel: [ 124.733237] [<ffffffff81086730>] ? flush_kthread_work+0x1a0/0x1a0
Aug 22 18:32:56 Donkey kernel: [ 124.733242] [<ffffffff81697040>] ? gs_change+0x13/0x13
Aug 22 18:32:56 Donkey kernel: [ 124.733248]
Aug 22 18:32:56 Donkey kernel: [ 124.733250] ===============================
^ permalink raw reply
* Re: [PATCH net-next v2] net: remove delay at device dismantle
From: David Miller @ 2012-08-23 2:18 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, therbert, maheshb, ebiederm
In-Reply-To: <1344664487.5158.1.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 11 Aug 2012 07:54:47 +0200
> On Fri, 2012-08-10 at 17:42 +0200, Eric Dumazet wrote:
>> From: Eric Dumazet <edumazet@google.com>
>>
>> I noticed extra one second delay in device dismantle, tracked down to
>> a call to dst_dev_event() while some call_rcu() are still in RCU queues.
>>
> ...
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Cc: Tom Herbert <therbert@google.com>
>> Cc: Mahesh Bandewar <maheshb@google.com>
>> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
>> ---
>> v2: NETDEV_UNREGISTER_FINAL called outside of rtnl lock
>> as its more risky, base this patch on net-next
>
> Also I am leaving for a one week vacation with no access to the
> Internet, so better hold this patch until my return ;)
Since you're back, I've applied this now.
Thanks.
^ permalink raw reply
* Re: [PATCH 0/8] netdev/MIPS: Improvements to octeon_mgmt Ethernet driver.
From: David Miller @ 2012-08-23 2:16 UTC (permalink / raw)
To: ddaney.cavm; +Cc: linux-mips, ralf, netdev, linux-kernel, david.daney
In-Reply-To: <1345574712-21444-1-git-send-email-ddaney.cavm@gmail.com>
From: David Daney <ddaney.cavm@gmail.com>
Date: Tue, 21 Aug 2012 11:45:04 -0700
> From: David Daney <david.daney@cavium.com>
>
> Recent additions to the OCTEON SoC family have included enhancements
> to the MIX (octeon_mgmt) Ethernet hardware. These include:
>
> o 1Gig support (up from 100M).
>
> o Hardware timestamping for PTP.
>
> Here we add support for these two features as well as some ethtool
> improvements and cleanup of the MAC address handling.
>
> Patch 1/8 is a prerequisite for the rest, and lives in the MIPS
> architecture part of the tree. Since octeon_mgmt devices are only
> found in OCTEON SoCs we could merge the whole set via Ralf's tree, or
> get Ralf to affix his Acked-by and have it go via the netdev tree.
You can send this all via the MIPS tree, and feel free to add my:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] ipv4: properly update pmtu
From: David Miller @ 2012-08-23 2:15 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ja, s.munaut
In-Reply-To: <1345618109.5158.599.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 22 Aug 2012 08:48:29 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Sylvain Munault reported following info :
>
> - TCP connection get "stuck" with data in send queue when doing
> "large" transfers ( like typing 'ps ax' on a ssh connection )
> - Only happens on path where the PMTU is lower than the MTU of
> the interface
> - Is not present right after boot, it only appears 10-20min after
> boot or so. (and that's inside the _same_ TCP connection, it works
> fine at first and then in the same ssh session, it'll get stuck)
> - Definitely seems related to fragments somehow since I see a router
> sending ICMP message saying fragmentation is needed.
> - Exact same setup works fine with kernel 3.5.1
>
> Problem happens when the 10 minutes (ip_rt_mtu_expires) expiration
> period is over.
>
> ip_rt_update_pmtu() calls dst_set_expires() to rearm a new expiration,
> but dst_set_expires() does nothing because dst.expires is already set.
>
> It seems we want to set the expires field to a new value, regardless
> of prior one.
>
> With help from Julian Anastasov.
>
> Reported-by: Sylvain Munaut <s.munaut@whatever-company.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> CC: Julian Anastasov <ja@ssi.bg>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH (net.git) 2/2] stmmac: fix a typo in the macro used to mask the mmc irq
From: David Miller @ 2012-08-23 2:14 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1345631176-29494-2-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Wed, 22 Aug 2012 12:26:16 +0200
> This patch fixes the name of the macro used to mask the
> mmc interrupt: erroneously it was used: MMC_DEFAUL_MASK.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH (net.git) 1/2] stmmac: fix GMAC syn ID
From: David Miller @ 2012-08-23 2:14 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev, gianni.antoniazzi-ext
In-Reply-To: <1345631176-29494-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Wed, 22 Aug 2012 12:26:15 +0200
> Erroneously the DWMAC_CORE_3_40 was set to 34 instead of 0x34.
> This can generate problems when run on old chips because
> the driver assumes that there are the extra 16 regs available
> for perfect filtering.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Gianni Antoniazzi <gianni.antoniazzi-ext@st.com>
Applied.
^ permalink raw reply
* [PATCH v3] serial: add a new helper function
From: Huang Shijie @ 2012-08-23 2:13 UTC (permalink / raw)
To: gregkh; +Cc: alan, linux-kernel, linux-serial, netdev, b32955, Huang Shijie
In most of the time, the driver needs to check if the cts flow control
is enabled. But now, the driver checks the ASYNC_CTS_FLOW flag manually,
which is not a grace way. So add a new wraper function to make the code
tidy and clean.
Signed-off-by: Huang Shijie <shijie8@gmail.com>
---
v2 --> v3:
this patch is based on Alan's "tty: move the async flags from the seria.."
v1 --> v2:
move the function tty.h to serial.h
---
drivers/char/pcmcia/synclink_cs.c | 2 +-
drivers/tty/amiserial.c | 2 +-
drivers/tty/cyclades.c | 2 +-
drivers/tty/isicom.c | 2 +-
drivers/tty/mxser.c | 2 +-
drivers/tty/serial/mxs-auart.c | 2 +-
drivers/tty/serial/serial_core.c | 4 ++--
drivers/tty/synclink.c | 2 +-
drivers/tty/synclink_gt.c | 2 +-
drivers/tty/synclinkmp.c | 2 +-
include/linux/tty.h | 6 ++++++
net/irda/ircomm/ircomm_tty.c | 4 ++--
net/irda/ircomm/ircomm_tty_attach.c | 2 +-
13 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/char/pcmcia/synclink_cs.c b/drivers/char/pcmcia/synclink_cs.c
index 5db08c7..3f57d5de 100644
--- a/drivers/char/pcmcia/synclink_cs.c
+++ b/drivers/char/pcmcia/synclink_cs.c
@@ -1050,7 +1050,7 @@ static void cts_change(MGSLPC_INFO *info, struct tty_struct *tty)
wake_up_interruptible(&info->status_event_wait_q);
wake_up_interruptible(&info->event_wait_q);
- if (info->port.flags & ASYNC_CTS_FLOW) {
+ if (tty_port_cts_enabled(&info->port)) {
if (tty->hw_stopped) {
if (info->serial_signals & SerialSignal_CTS) {
if (debug_level >= DEBUG_LEVEL_ISR)
diff --git a/drivers/tty/amiserial.c b/drivers/tty/amiserial.c
index 2b7535d..42d0a25 100644
--- a/drivers/tty/amiserial.c
+++ b/drivers/tty/amiserial.c
@@ -420,7 +420,7 @@ static void check_modem_status(struct serial_state *info)
tty_hangup(port->tty);
}
}
- if (port->flags & ASYNC_CTS_FLOW) {
+ if (tty_port_cts_enabled(port)) {
if (port->tty->hw_stopped) {
if (!(status & SER_CTS)) {
#if (defined(SERIAL_DEBUG_INTR) || defined(SERIAL_DEBUG_FLOW))
diff --git a/drivers/tty/cyclades.c b/drivers/tty/cyclades.c
index e3954da..0a6a0bc 100644
--- a/drivers/tty/cyclades.c
+++ b/drivers/tty/cyclades.c
@@ -727,7 +727,7 @@ static void cyy_chip_modem(struct cyclades_card *cinfo, int chip,
else
tty_hangup(tty);
}
- if ((mdm_change & CyCTS) && (info->port.flags & ASYNC_CTS_FLOW)) {
+ if ((mdm_change & CyCTS) && tty_port_cts_enabled(&info->port)) {
if (tty->hw_stopped) {
if (mdm_status & CyCTS) {
/* cy_start isn't used
diff --git a/drivers/tty/isicom.c b/drivers/tty/isicom.c
index 99cf22e..d7492e1 100644
--- a/drivers/tty/isicom.c
+++ b/drivers/tty/isicom.c
@@ -600,7 +600,7 @@ static irqreturn_t isicom_interrupt(int irq, void *dev_id)
port->status &= ~ISI_DCD;
}
- if (port->port.flags & ASYNC_CTS_FLOW) {
+ if (tty_port_cts_enabled(&port->port)) {
if (tty->hw_stopped) {
if (header & ISI_CTS) {
port->port.tty->hw_stopped = 0;
diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c
index bb2da4c..cfda47d 100644
--- a/drivers/tty/mxser.c
+++ b/drivers/tty/mxser.c
@@ -830,7 +830,7 @@ static void mxser_check_modem_status(struct tty_struct *tty,
wake_up_interruptible(&port->port.open_wait);
}
- if (port->port.flags & ASYNC_CTS_FLOW) {
+ if (tty_port_cts_enabled(&port->port)) {
if (tty->hw_stopped) {
if (status & UART_MSR_CTS) {
tty->hw_stopped = 0;
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 3a667ee..dafeef2 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -262,7 +262,7 @@ static void mxs_auart_set_mctrl(struct uart_port *u, unsigned mctrl)
ctrl &= ~AUART_CTRL2_RTSEN;
if (mctrl & TIOCM_RTS) {
- if (u->state->port.flags & ASYNC_CTS_FLOW)
+ if (tty_port_cts_enabled(&u->state->port))
ctrl |= AUART_CTRL2_RTSEN;
}
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 5b308c8..1920e5c 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -176,7 +176,7 @@ static int uart_port_startup(struct tty_struct *tty, struct uart_state *state,
uart_set_mctrl(uport, TIOCM_RTS | TIOCM_DTR);
}
- if (port->flags & ASYNC_CTS_FLOW) {
+ if (tty_port_cts_enabled(port)) {
spin_lock_irq(&uport->lock);
if (!(uport->ops->get_mctrl(uport) & TIOCM_CTS))
tty->hw_stopped = 1;
@@ -2493,7 +2493,7 @@ void uart_handle_cts_change(struct uart_port *uport, unsigned int status)
uport->icount.cts++;
- if (port->flags & ASYNC_CTS_FLOW) {
+ if (tty_port_cts_enabled(port)) {
if (tty->hw_stopped) {
if (status) {
tty->hw_stopped = 0;
diff --git a/drivers/tty/synclink.c b/drivers/tty/synclink.c
index 666aa14..70e3a52 100644
--- a/drivers/tty/synclink.c
+++ b/drivers/tty/synclink.c
@@ -1359,7 +1359,7 @@ static void mgsl_isr_io_pin( struct mgsl_struct *info )
}
}
- if ( (info->port.flags & ASYNC_CTS_FLOW) &&
+ if (tty_port_cts_enabled(&info->port) &&
(status & MISCSTATUS_CTS_LATCHED) ) {
if (info->port.tty->hw_stopped) {
if (status & MISCSTATUS_CTS) {
diff --git a/drivers/tty/synclink_gt.c b/drivers/tty/synclink_gt.c
index 45f6136..b38e954 100644
--- a/drivers/tty/synclink_gt.c
+++ b/drivers/tty/synclink_gt.c
@@ -2053,7 +2053,7 @@ static void cts_change(struct slgt_info *info, unsigned short status)
wake_up_interruptible(&info->event_wait_q);
info->pending_bh |= BH_STATUS;
- if (info->port.flags & ASYNC_CTS_FLOW) {
+ if (tty_port_cts_enabled(&info->port)) {
if (info->port.tty) {
if (info->port.tty->hw_stopped) {
if (info->signals & SerialSignal_CTS) {
diff --git a/drivers/tty/synclinkmp.c b/drivers/tty/synclinkmp.c
index 53429c8..f17d9f3 100644
--- a/drivers/tty/synclinkmp.c
+++ b/drivers/tty/synclinkmp.c
@@ -2500,7 +2500,7 @@ static void isr_io_pin( SLMP_INFO *info, u16 status )
}
}
- if ( (info->port.flags & ASYNC_CTS_FLOW) &&
+ if (tty_port_cts_enabled(&info->port) &&
(status & MISCSTATUS_CTS_LATCHED) ) {
if ( info->port.tty ) {
if (info->port.tty->hw_stopped) {
diff --git a/include/linux/tty.h b/include/linux/tty.h
index dbebd1e..9892121 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -514,6 +514,12 @@ static inline struct tty_port *tty_port_get(struct tty_port *port)
return port;
}
+/* If the cts flow control is enabled, return true. */
+static inline bool tty_port_cts_enabled(struct tty_port *port)
+{
+ return port->flags & ASYNC_CTS_FLOW;
+}
+
extern struct tty_struct *tty_port_tty_get(struct tty_port *port);
extern void tty_port_tty_set(struct tty_port *port, struct tty_struct *tty);
extern int tty_port_carrier_raised(struct tty_port *port);
diff --git a/net/irda/ircomm/ircomm_tty.c b/net/irda/ircomm/ircomm_tty.c
index 9668990..95a3a7a 100644
--- a/net/irda/ircomm/ircomm_tty.c
+++ b/net/irda/ircomm/ircomm_tty.c
@@ -1070,7 +1070,7 @@ void ircomm_tty_check_modem_status(struct ircomm_tty_cb *self)
goto put;
}
}
- if (tty && self->port.flags & ASYNC_CTS_FLOW) {
+ if (tty && tty_port_cts_enabled(&self->port)) {
if (tty->hw_stopped) {
if (status & IRCOMM_CTS) {
IRDA_DEBUG(2,
@@ -1313,7 +1313,7 @@ static void ircomm_tty_line_info(struct ircomm_tty_cb *self, struct seq_file *m)
seq_puts(m, "Flags:");
sep = ' ';
- if (self->port.flags & ASYNC_CTS_FLOW) {
+ if (tty_port_cts_enabled(&self->port)) {
seq_printf(m, "%cASYNC_CTS_FLOW", sep);
sep = '|';
}
diff --git a/net/irda/ircomm/ircomm_tty_attach.c b/net/irda/ircomm/ircomm_tty_attach.c
index 3ab70e7..edab393 100644
--- a/net/irda/ircomm/ircomm_tty_attach.c
+++ b/net/irda/ircomm/ircomm_tty_attach.c
@@ -578,7 +578,7 @@ void ircomm_tty_link_established(struct ircomm_tty_cb *self)
* will have to wait for the peer device (DCE) to raise the CTS
* line.
*/
- if ((self->port.flags & ASYNC_CTS_FLOW) &&
+ if (tty_port_cts_enabled(&self->port) &&
((self->settings.dce & IRCOMM_CTS) == 0)) {
IRDA_DEBUG(0, "%s(), waiting for CTS ...\n", __func__ );
goto put;
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH 00/10] netfilter updates for net-next (batch 1)
From: David Miller @ 2012-08-23 2:10 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1345678726-3109-1-git-send-email-pablo@netfilter.org>
From: pablo@netfilter.org
Date: Thu, 23 Aug 2012 01:38:36 +0200
> This is the first batch of Netfilter and IPVS updates for your
> net-next tree. Mostly cleanups for the Netfilter side. They are:
Pulled, thanks a lot Pablo.
^ permalink raw reply
* (unknown),
From: Johnson Helen @ 2012-08-23 1:19 UTC (permalink / raw)
Your email address has won the QATAR Foundation Funds In Conjunction with (UNICEF)for International Development to receive a grant sponsorship of $ 2,500,000 USD For details of this free E-Lotto and directives on processing your funds with your claims identification # - G20-9012-747; EU-162-0234, Contact The regional verification and claims office:
Qatar Claims Official: Mohammad Fathy (Mr.)
Email: qataronlinedonation@qatar.io
Direct Lines: +447035941132
Courtesy,
QATAR FOUNDATION: FUNDS FOR INTERNATIONAL DEVELOPMENT
www.qf.org.qa
^ permalink raw reply
* Re: [PATCH v3 01/17] hashtable: introduce a small and naive hashtable
From: Sasha Levin @ 2012-08-23 0:24 UTC (permalink / raw)
To: Tejun Heo
Cc: torvalds, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev, josh,
eric.dumazet, mathieu.desnoyers, axboe, agk, dm-devel, neilb,
ccaulfie, teigland, Trond.Myklebust, bfields, fweisbec, jesse,
venkat.x.venkatsubra, ejt, snitzer, edumazet, linux-nfs, dev,
rds-devel, lw
In-Reply-To: <20120822180138.GA19212@google.com>
Hi Tejun,
On 08/22/2012 08:01 PM, Tejun Heo wrote:
> Hello, Sasha.
>
> On Wed, Aug 22, 2012 at 04:26:56AM +0200, Sasha Levin wrote:
>> +#define DEFINE_HASHTABLE(name, bits) \
>> + struct hlist_head name[HASH_SIZE(bits)];
>
> Shouldn't this be something like the following?
>
> #define DEFINE_HASHTABLE(name, bits) \
> struct hlist_head name[HASH_SIZE(bits)] = \
> { [0 ... HASH_SIZE(bits) - 1] = HLIST_HEAD_INIT };
>
> Also, given that the declaration isn't non-trivial, you'll probably
> want a matching DECLARE_HASHTABLE() macro too.
I figured we might do a DEFINE_HASHTABLE() to prevent the need from using
hash_init() on hashtables defined this way, but I preferred not to since we may
end up wanting a more complex initialization (I'll explain why extensively below).
>> +/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit kernels. */
>> +#define hash_min(val, bits) ((sizeof(val)==4) ? hash_32((val), (bits)) : hash_long((val), (bits)))
>
> Why is the branching condition sizeof(val) == 4 instead of <= 4?
No reason, will fix.
> Also, no biggie but why isn't this macro in caps?
I had this plan in my mind to move it into linux/hash.h at some stage later, and
the API there uses low caps even for macros (hash_long()).
>> +/**
>> + * hash_add_rcu_size - add an object to a rcu enabled hashtable
>> + * @hashtable: hashtable to add to
>> + * @bits: bit count used for hashing
>> + * @node: the &struct hlist_node of the object to be added
>> + * @key: the key of the object to be added
>> + */
>> +#define hash_add_rcu_size(hashtable, bits, node, key) \
>> + hlist_add_head_rcu(node, &hashtable[hash_min(key, bits)]);
>> +
>> +/**
>> + * hash_add_rcu - add an object to a rcu enabled hashtable
>> + * @hashtable: hashtable to add to
>> + * @node: the &struct hlist_node of the object to be added
>> + * @key: the key of the object to be added
>> + */
>> +#define hash_add_rcu(hashtable, node, key) \
>> + hash_add_rcu_size(hashtable, HASH_BITS(hashtable), node, key)
>
> Or maybe we're better off with hash_head_size() and hash_head()? I'll
> expand on it later. Please bear with me.
>
>> +/**
>> + * hash_hashed - check whether an object is in any hashtable
>> + * @node: the &struct hlist_node of the object to be checked
>> + */
>> +#define hash_hashed(node) (!hlist_unhashed(node))
>
> As the 'h' in hlist* stand for hash anyway and I think this type of
> thin wrappers tend to obfuscate more than anything else.
>
>> +/**
>> + * hash_del - remove an object from a hashtable
>> + * @node: &struct hlist_node of the object to remove
>> + */
>> +static inline void hash_del(struct hlist_node *node)
>> +{
>> + hlist_del_init(node);
>> +}
>> +
>> +/**
>> + * hash_del_rcu - remove an object from a rcu enabled hashtable
>> + * @node: &struct hlist_node of the object to remove
>> + */
>> +static inline void hash_del_rcu(struct hlist_node *node)
>> +{
>> + hlist_del_init_rcu(node);
>> +}
>
> If we do that, we can remove all these thin wrappers.
>
>> +#define hash_for_each_size(name, bits, bkt, node, obj, member) \
>> + for (bkt = 0; bkt < HASH_SIZE(bits); bkt++) \
>> + hlist_for_each_entry(obj, node, &name[bkt], member)
> ..
>> +#define hash_for_each(name, bkt, node, obj, member) \
>> + hash_for_each_size(name, HASH_BITS(name), bkt, node, obj, member)
> ...
>> +#define hash_for_each_rcu_size(name, bits, bkt, node, obj, member) \
>> + for (bkt = 0; bkt < HASH_SIZE(bits); bkt++) \
>> + hlist_for_each_entry_rcu(obj, node, &name[bkt], member)
> ...
>> +#define hash_for_each_rcu(name, bkt, node, obj, member) \
>> + hash_for_each_rcu_size(name, HASH_BITS(name), bkt, node, obj, member)
> ...
>> +#define hash_for_each_safe_size(name, bits, bkt, node, tmp, obj, member) \
>> + for (bkt = 0; bkt < HASH_SIZE(bits); bkt++) \
>> + hlist_for_each_entry_safe(obj, node, tmp, &name[bkt], member)
> ...
>> +#define hash_for_each_safe(name, bkt, node, tmp, obj, member) \
>> + hash_for_each_safe_size(name, HASH_BITS(name), bkt, node, \
>> + tmp, obj, member)
> ...
>> +#define hash_for_each_possible_size(name, obj, bits, node, member, key) \
>> + hlist_for_each_entry(obj, node, &name[hash_min(key, bits)], member)
> ...
>> +#define hash_for_each_possible(name, obj, node, member, key) \
>> + hash_for_each_possible_size(name, obj, HASH_BITS(name), node, member, key)
> ...
>> +#define hash_for_each_possible_rcu_size(name, obj, bits, node, member, key) \
>> + hlist_for_each_entry_rcu(obj, node, &name[hash_min(key, bits)], member)
> ...
>> +#define hash_for_each_possible_rcu(name, obj, node, member, key) \
>> + hash_for_each_possible_rcu_size(name, obj, HASH_BITS(name), \
> ...
>> +#define hash_for_each_possible_safe_size(name, obj, bits, node, tmp, member, key)\
>> + hlist_for_each_entry_safe(obj, node, tmp, \
>> + &name[hash_min(key, bits)], member)
> ...
>> +#define hash_for_each_possible_safe(name, obj, node, tmp, member, key) \
>> + hash_for_each_possible_safe_size(name, obj, HASH_BITS(name), \
>
> And also all these. We'd only need hash_for_each_head() and
> hash_head(). hash_for_each_possible*() could be nice for convenience,
> I suppose.
>
> I think the almost trivial nature of hlist hashtables makes this a bit
> tricky and I'm not very sure but having this combinatory explosion is
> a bit dazzling when the same functionality can be achieved by simply
> combining operations which are already defined and named considering
> hashtable. I'm not feeling too strong about this tho. What do others
> think?
I'm thinking that this hashtable API will have 2 purposes: First, it would
prevent the excessive duplication of hashtable implementations all around the code.
Second, it will allow more easily interchangeable hashtable implementations to
find their way into the kernel. There are several maintainers who would be happy
to see dynamically sized RCU hashtable, and I'm guessing that several more
variants could be added based on needs in specific modules.
The second reason is why several things you've mentioned look the way they are:
- No DEFINE_HASHTABLE(): I wanted to force the use of hash_init() since
initialization for other hashtables may be more complicated than the static
initialization for this implementation, which means that any place that used
DEFINE_HASHTABLE() and didn't do hash_init() will be buggy.
- hash_hashed(): Different hashtable implementations may not use hlist, so
letting them assume that doing hlist operations on hashtable objects is wrong.
- Lack of hash_head(): I didn't want to expose the internal structure of the
hashtable to the user. This might make it hard to implement hashtables that
resize themselves if we let the user hold a bucket in his hands.
I'm actually tempted in hiding hlist completely from hashtable users, probably
by simply defining a hash_head/hash_node on top of the hlist_ counterparts.
Now, I know that I mention a lot of these hashtables that might or might not be
added later on in the kernel, this is mostly due to the interest in dynamic
resizable hashtables which was shown during the RFC, and the fact that there is
a solid implementation of a dynamic RCU hashtable in urcu which might be a great
benefit in the kernel as well (I'm also looking at it while working on this
hashtable to verify that both could share an API in the future).
Regarding the amount of new macros, we can address this by splitting off any
dynamic elements into a new hashtable type. This will let us reduce quite a lot
of macros (removing all the _size() ones at least).
> Also, can you please audit the comments on top of each macro? They
> have wrong names and don't differentiate the different variants very
> well.
Sure, sorry about that.
Thanks,
Sasha
> Thanks.
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH 08/10] netfilter: nf_conntrack: remove unnecessary RTNL locking
From: pablo @ 2012-08-22 23:38 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1345678726-3109-1-git-send-email-pablo@netfilter.org>
From: Patrick McHardy <kaber@trash.net>
Locking the rtnl was added to nf_conntrack_l{3,4}_proto_unregister()
for walking the network namespace list. This is not done anymore since
we have proper namespace support in the protocols now, so we don't
need to take the RTNL anymore.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_conntrack_proto.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/net/netfilter/nf_conntrack_proto.c b/net/netfilter/nf_conntrack_proto.c
index 0dc6385..51e928d 100644
--- a/net/netfilter/nf_conntrack_proto.c
+++ b/net/netfilter/nf_conntrack_proto.c
@@ -21,7 +21,6 @@
#include <linux/notifier.h>
#include <linux/kernel.h>
#include <linux/netdevice.h>
-#include <linux/rtnetlink.h>
#include <net/netfilter/nf_conntrack.h>
#include <net/netfilter/nf_conntrack_l3proto.h>
@@ -294,9 +293,7 @@ void nf_conntrack_l3proto_unregister(struct net *net,
nf_ct_l3proto_unregister_sysctl(net, proto);
/* Remove all contrack entries for this protocol */
- rtnl_lock();
nf_ct_iterate_cleanup(net, kill_l3proto, proto);
- rtnl_unlock();
}
EXPORT_SYMBOL_GPL(nf_conntrack_l3proto_unregister);
@@ -502,9 +499,7 @@ void nf_conntrack_l4proto_unregister(struct net *net,
nf_ct_l4proto_unregister_sysctl(net, pn, l4proto);
/* Remove all contrack entries for this protocol */
- rtnl_lock();
nf_ct_iterate_cleanup(net, kill_l4proto, l4proto);
- rtnl_unlock();
}
EXPORT_SYMBOL_GPL(nf_conntrack_l4proto_unregister);
--
1.7.10.4
^ permalink raw reply related
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