* Re: [PATCH]: Add Network Sysrq Support
From: Prarit Bhargava @ 2011-06-22 17:39 UTC (permalink / raw)
To: David Miller
Cc: John Haxby, Florian Westphal, fbl, netdev, agospoda, nhorman,
lwoodman
In-Reply-To: <4E01E1FD.8010802@oracle.com>
> Although I wasn't sure that it could happen, it's also possible that the
> cryptographic functions can get in your way. xt_SYSRQ does its best to
> avoid problems by pre-allocating everything it can so there is as little
> as possible to do when it is needed, but it is possible for it to fail.
>
>
My running theory as to the failure is that the CPU that took the sysrq
is also the CPU that was having problems that resulted in the "slow
down" of the system.
On a known-good system, xt_SYSRQ behaves properly AFAICT. It functions
exactly the way we want it to.
So ... I read the following discussion of xt_SYSRQ from last year:
http://www.kerneltrap.com/mailarchive/linux-netdev/2010/4/21/6275199/thread
And it seems there were no technical objections to the code, but there
were other concerns.
davem -- as I don't monitor this list, are you indicating that you are
more amenable to this code being accepted upstream? Or is that part of
the debate still ongoing?
P.
^ permalink raw reply
* [PATCH net-next] bonding: add min links parameter to 802.3ad
From: Stephen Hemminger @ 2011-06-22 17:54 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek, David Miller; +Cc: netdev
This adds support for a configuring the minimum number of links that
must be active before asserting carrier. It is similar to the Cisco
EtherChannel min-links feature. This allows setting the minimum number
of member ports that must be up (link-up state) before marking the
bond device as up (carrier on). This is useful for situations where
higher level services such as clustering want to ensure a minimum
number of low bandwidth links are active before switchover.
This is a prototype, did some basic testing but has not been
tested with other switches.
See:
http://bugzilla.vyatta.com/show_bug.cgi?id=7196
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
drivers/net/bonding/bond_3ad.c | 8 ++++++--
drivers/net/bonding/bond_main.c | 5 +++++
drivers/net/bonding/bond_procfs.c | 1 +
drivers/net/bonding/bond_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
drivers/net/bonding/bonding.h | 1 +
5 files changed, 48 insertions(+), 2 deletions(-)
--- a/drivers/net/bonding/bond_main.c 2011-06-22 09:06:40.895998636 -0700
+++ b/drivers/net/bonding/bond_main.c 2011-06-22 10:11:52.855974841 -0700
@@ -98,6 +98,7 @@ static char *mode;
static char *primary;
static char *primary_reselect;
static char *lacp_rate;
+static int min_links;
static char *ad_select;
static char *xmit_hash_policy;
static int arp_interval = BOND_LINK_ARP_INTERV;
@@ -150,6 +151,9 @@ module_param(ad_select, charp, 0);
MODULE_PARM_DESC(ad_select, "803.ad aggregation selection logic; "
"0 for stable (default), 1 for bandwidth, "
"2 for count");
+module_param(min_links, int, 0);
+MODULE_PARM_DESC(min_links, "Minimum number of available links before turning on carrier");
+
module_param(xmit_hash_policy, charp, 0);
MODULE_PARM_DESC(xmit_hash_policy, "balance-xor and 802.3ad hashing method; "
"0 for layer 2 (default), 1 for layer 3+4, "
@@ -4798,6 +4802,7 @@ static int bond_check_params(struct bond
params->tx_queues = tx_queues;
params->all_slaves_active = all_slaves_active;
params->resend_igmp = resend_igmp;
+ params->min_links = min_links;
if (primary) {
strncpy(params->primary, primary, IFNAMSIZ);
--- a/drivers/net/bonding/bond_procfs.c 2011-06-22 09:17:04.391998454 -0700
+++ b/drivers/net/bonding/bond_procfs.c 2011-06-22 09:27:09.815997950 -0700
@@ -125,6 +125,7 @@ static void bond_info_show_master(struct
seq_puts(seq, "\n802.3ad info\n");
seq_printf(seq, "LACP rate: %s\n",
(bond->params.lacp_fast) ? "fast" : "slow");
+ seq_printf(seq, "Min links: %d\n", bond->params.min_links);
seq_printf(seq, "Aggregator selection policy (ad_select): %s\n",
ad_select_tbl[bond->params.ad_select].modename);
--- a/drivers/net/bonding/bond_sysfs.c 2011-06-22 09:04:50.295998865 -0700
+++ b/drivers/net/bonding/bond_sysfs.c 2011-06-22 10:24:11.287947057 -0700
@@ -819,6 +819,39 @@ out:
static DEVICE_ATTR(lacp_rate, S_IRUGO | S_IWUSR,
bonding_show_lacp, bonding_store_lacp);
+
+static ssize_t bonding_show_min_links(struct device *d,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct bonding *bond = to_bond(d);
+
+ return sprintf(buf, "%d\n", bond->params.min_links);
+}
+
+static ssize_t bonding_store_min_links(struct device *d,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct bonding *bond = to_bond(d);
+ int ret;
+ unsigned int new_value;
+
+ ret = kstrtouint(buf, 0, &new_value);
+ if (ret < 0) {
+ pr_err("%s: Ignoring invalid min links value %s.\n",
+ bond->dev->name, buf);
+ return ret;
+ }
+
+ pr_info("%s: Setting min links value to %u\n",
+ bond->dev->name, new_value);
+ bond->params.min_links = new_value;
+ return count;
+}
+static DEVICE_ATTR(min_links, S_IRUGO | S_IWUSR,
+ bonding_show_min_links, bonding_store_min_links);
+
static ssize_t bonding_show_ad_select(struct device *d,
struct device_attribute *attr,
char *buf)
@@ -863,6 +896,7 @@ out:
static DEVICE_ATTR(ad_select, S_IRUGO | S_IWUSR,
bonding_show_ad_select, bonding_store_ad_select);
+
/*
* Show and set the number of peer notifications to send after a failover event.
*/
@@ -1601,6 +1635,7 @@ static struct attribute *per_bond_attrs[
&dev_attr_queue_id.attr,
&dev_attr_all_slaves_active.attr,
&dev_attr_resend_igmp.attr,
+ &dev_attr_min_links.attr,
NULL,
};
--- a/drivers/net/bonding/bonding.h 2011-06-22 09:05:32.351998841 -0700
+++ b/drivers/net/bonding/bonding.h 2011-06-22 09:27:23.959999290 -0700
@@ -147,6 +147,7 @@ struct bond_params {
int updelay;
int downdelay;
int lacp_fast;
+ unsigned int min_links;
int ad_select;
char primary[IFNAMSIZ];
int primary_reselect;
--- a/drivers/net/bonding/bond_3ad.c 2011-06-22 08:43:25.599999586 -0700
+++ b/drivers/net/bonding/bond_3ad.c 2011-06-22 09:44:11.815997557 -0700
@@ -2342,8 +2342,12 @@ void bond_3ad_handle_link_change(struct
*/
int bond_3ad_set_carrier(struct bonding *bond)
{
- if (__get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator))) {
- if (!netif_carrier_ok(bond->dev)) {
+ struct aggregator *active;
+
+ active = __get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator));
+ if (active) {
+ if (active->num_of_ports >= bond->params.min_links &&
+ !netif_carrier_ok(bond->dev)) {
netif_carrier_on(bond->dev);
return 1;
}
^ permalink raw reply
* Re: Reported regression against commit a05d2ad
From: Eric W. Biederman @ 2011-06-22 18:00 UTC (permalink / raw)
To: tim.gardner; +Cc: Herton Ronaldo Krzesinski, lamont, sconklin, netdev
In-Reply-To: <4E02273E.2080000@canonical.com>
Tim Gardner <tim.gardner@canonical.com> writes:
> On 06/21/2011 02:49 PM, Eric W. Biederman wrote:
> <snip>
>> I respectfully suggest that the bug is elsewhere perhaps a broken user
>> space application out there that needs to be fixed, or you have a kernel
>> memory stomp that removing patch a05d2ad happens to shift the memory
>> layout to be harmful in a different way.
>>
>
> OK, I'm remembering how PF_UNIX Unix domain sockets are used, so I think your
> theory about a misbehaving user space application is more likely. However, I am
> a bit confused about how an application can attempt to receive before the socket
> is fully opened. Some kind of race condition with socketpair() ?
The case that is relevant is a listening SOCK_SEQPACKET socket.
The case that is affected is when you call receive on a listening
socket.
It isn't that the socket isn't fully opened. It is that accept is the
only legitimate operation at that point.
It took a mistake while someone was developing an application for this
kernel bug to be found.
Eric
^ permalink raw reply
* [PATCH] net: wimax: Remove of unused 'rfkill_input' pointer
From: Vitaliy Ivanov @ 2011-06-22 18:06 UTC (permalink / raw)
To: David S. Miller, Inaky Perez-Gonzalez, Johannes Berg
Cc: netdev, LKML, Alan Jenkins, Henrique de Moraes Holschuh,
John W. Linville
David,
Please apply.
I added here all the peoples who took part in
19d337dff95cbf76edd3ad95c0cee2732c3e1ec5 commit for any comments.
Also performed all yes/no/mod config builds w/ no issues.
>From b93ca8947e85e4ff7e9f314675d4770b90b77548 Mon Sep 17 00:00:00 2001
From: Vitaliy Ivanov <vitalivanov@gmail.com>
Date: Wed, 22 Jun 2011 20:57:49 +0300
Subject: [PATCH] net: wimax: Remove of unused 'rfkill_input' pointer
Seems like this was not cleaned during the 'rfkill: rewrite' checkin
19d337dff95cbf76edd3ad95c0cee2732c3e1ec5.
Signed-off-by: Vitaliy Ivanov <vitalivanov@gmail.com>
---
include/net/wimax.h | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/include/net/wimax.h b/include/net/wimax.h
index 7328d50..322ff4f 100644
--- a/include/net/wimax.h
+++ b/include/net/wimax.h
@@ -423,7 +423,6 @@ struct wimax_dev {
int (*op_reset)(struct wimax_dev *wimax_dev);
struct rfkill *rfkill;
- struct input_dev *rfkill_input;
unsigned rf_hw;
unsigned rf_sw;
char name[32];
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH]: Add Network Sysrq Support
From: John Haxby @ 2011-06-22 18:46 UTC (permalink / raw)
To: Prarit Bhargava
Cc: David Miller, Florian Westphal, fbl, netdev, agospoda, nhorman,
lwoodman
In-Reply-To: <4E0228C3.8090402@redhat.com>
On 22 Jun 2011, at 18:39, Prarit Bhargava wrote:
>
>> Although I wasn't sure that it could happen, it's also possible that the
>> cryptographic functions can get in your way. xt_SYSRQ does its best to
>> avoid problems by pre-allocating everything it can so there is as little
>> as possible to do when it is needed, but it is possible for it to fail.
>>
>>
>
> My running theory as to the failure is that the CPU that took the sysrq
> is also the CPU that was having problems that resulted in the "slow
> down" of the system.
>
> On a known-good system, xt_SYSRQ behaves properly AFAICT. It functions
> exactly the way we want it to.
>
> So ... I read the following discussion of xt_SYSRQ from last year:
>
> http://www.kerneltrap.com/mailarchive/linux-netdev/2010/4/21/6275199/thread
>
> And it seems there were no technical objections to the code, but there
> were other concerns.
>
> davem -- as I don't monitor this list, are you indicating that you are
> more amenable to this code being accepted upstream? Or is that part of
> the debate still ongoing?
>
>
I've just re-read the thread and I'm reminded that I never did submit the xt_SYSRQ hash update I mentioned at the end of the thread.
davem: I'm more than happy to push that patch through if it will make xt_SYSRQ more acceptable.
jch
^ permalink raw reply
* Re: [PATCH]: Add Network Sysrq Support
From: John Haxby @ 2011-06-22 18:57 UTC (permalink / raw)
To: Prarit Bhargava
Cc: David Miller, Florian Westphal, fbl, netdev, agospoda, nhorman,
lwoodman
In-Reply-To: <4E0228C3.8090402@redhat.com>
On 22 Jun 2011, at 18:39, Prarit Bhargava wrote:
>
>> Although I wasn't sure that it could happen, it's also possible that the
>> cryptographic functions can get in your way. xt_SYSRQ does its best to
>> avoid problems by pre-allocating everything it can so there is as little
>> as possible to do when it is needed, but it is possible for it to fail.
>>
>>
>
> My running theory as to the failure is that the CPU that took the sysrq
> is also the CPU that was having problems that resulted in the "slow
> down" of the system.
>
> On a known-good system, xt_SYSRQ behaves properly AFAICT. It functions
> exactly the way we want it to.
>
> So ... I read the following discussion of xt_SYSRQ from last year:
>
> http://www.kerneltrap.com/mailarchive/linux-netdev/2010/4/21/6275199/thread
>
> And it seems there were no technical objections to the code, but there
> were other concerns.
>
> davem -- as I don't monitor this list, are you indicating that you are
> more amenable to this code being accepted upstream? Or is that part of
> the debate still ongoing?
>
>
I've just re-read the thread and I'm reminded that I never did submit the xt_SYSRQ hash update I mentioned at the end of the thread.
^ permalink raw reply
* Re: [PATCH net-next] bonding: add min links parameter to 802.3ad
From: Flavio Leitner @ 2011-06-22 19:40 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jay Vosburgh, Andy Gospodarek, David Miller, netdev
In-Reply-To: <20110622105408.06fd4788@nehalam.ftrdhcpuser.net>
On 06/22/2011 02:54 PM, Stephen Hemminger wrote:
> This adds support for a configuring the minimum number of links that
> must be active before asserting carrier. It is similar to the Cisco
> EtherChannel min-links feature. This allows setting the minimum number
> of member ports that must be up (link-up state) before marking the
> bond device as up (carrier on). This is useful for situations where
> higher level services such as clustering want to ensure a minimum
> number of low bandwidth links are active before switchover.
>
> This is a prototype, did some basic testing but has not been
> tested with other switches.
>
> See:
> http://bugzilla.vyatta.com/show_bug.cgi?id=7196
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> ---
> drivers/net/bonding/bond_3ad.c | 8 ++++++--
> drivers/net/bonding/bond_main.c | 5 +++++
> drivers/net/bonding/bond_procfs.c | 1 +
> drivers/net/bonding/bond_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
> drivers/net/bonding/bonding.h | 1 +
> 5 files changed, 48 insertions(+), 2 deletions(-)
>
> --- a/drivers/net/bonding/bond_main.c 2011-06-22 09:06:40.895998636 -0700
> +++ b/drivers/net/bonding/bond_main.c 2011-06-22 10:11:52.855974841 -0700
> @@ -98,6 +98,7 @@ static char *mode;
> static char *primary;
> static char *primary_reselect;
> static char *lacp_rate;
> +static int min_links;
> static char *ad_select;
> static char *xmit_hash_policy;
> static int arp_interval = BOND_LINK_ARP_INTERV;
> @@ -150,6 +151,9 @@ module_param(ad_select, charp, 0);
> MODULE_PARM_DESC(ad_select, "803.ad aggregation selection logic; "
> "0 for stable (default), 1 for bandwidth, "
> "2 for count");
> +module_param(min_links, int, 0);
> +MODULE_PARM_DESC(min_links, "Minimum number of available links before turning on carrier");
> +
> module_param(xmit_hash_policy, charp, 0);
> MODULE_PARM_DESC(xmit_hash_policy, "balance-xor and 802.3ad hashing method; "
> "0 for layer 2 (default), 1 for layer 3+4, "
> @@ -4798,6 +4802,7 @@ static int bond_check_params(struct bond
> params->tx_queues = tx_queues;
> params->all_slaves_active = all_slaves_active;
> params->resend_igmp = resend_igmp;
> + params->min_links = min_links;
>
> if (primary) {
> strncpy(params->primary, primary, IFNAMSIZ);
> --- a/drivers/net/bonding/bond_procfs.c 2011-06-22 09:17:04.391998454 -0700
> +++ b/drivers/net/bonding/bond_procfs.c 2011-06-22 09:27:09.815997950 -0700
> @@ -125,6 +125,7 @@ static void bond_info_show_master(struct
> seq_puts(seq, "\n802.3ad info\n");
> seq_printf(seq, "LACP rate: %s\n",
> (bond->params.lacp_fast) ? "fast" : "slow");
> + seq_printf(seq, "Min links: %d\n", bond->params.min_links);
> seq_printf(seq, "Aggregator selection policy (ad_select): %s\n",
> ad_select_tbl[bond->params.ad_select].modename);
>
> --- a/drivers/net/bonding/bond_sysfs.c 2011-06-22 09:04:50.295998865 -0700
> +++ b/drivers/net/bonding/bond_sysfs.c 2011-06-22 10:24:11.287947057 -0700
> @@ -819,6 +819,39 @@ out:
> static DEVICE_ATTR(lacp_rate, S_IRUGO | S_IWUSR,
> bonding_show_lacp, bonding_store_lacp);
>
> +
Other similar parts uses just one blank line.
> +static ssize_t bonding_show_min_links(struct device *d,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct bonding *bond = to_bond(d);
> +
> + return sprintf(buf, "%d\n", bond->params.min_links);
> +}
> +
> +static ssize_t bonding_store_min_links(struct device *d,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct bonding *bond = to_bond(d);
> + int ret;
> + unsigned int new_value;
> +
> + ret = kstrtouint(buf, 0, &new_value);
> + if (ret < 0) {
> + pr_err("%s: Ignoring invalid min links value %s.\n",
> + bond->dev->name, buf);
> + return ret;
> + }
> +
> + pr_info("%s: Setting min links value to %u\n",
> + bond->dev->name, new_value);
> + bond->params.min_links = new_value;
> + return count;
> +}
> +static DEVICE_ATTR(min_links, S_IRUGO | S_IWUSR,
> + bonding_show_min_links, bonding_store_min_links);
> +
> static ssize_t bonding_show_ad_select(struct device *d,
> struct device_attribute *attr,
> char *buf)
> @@ -863,6 +896,7 @@ out:
> static DEVICE_ATTR(ad_select, S_IRUGO | S_IWUSR,
> bonding_show_ad_select, bonding_store_ad_select);
>
> +
Same here.
> /*
> * Show and set the number of peer notifications to send after a failover event.
> */
> @@ -1601,6 +1635,7 @@ static struct attribute *per_bond_attrs[
> &dev_attr_queue_id.attr,
> &dev_attr_all_slaves_active.attr,
> &dev_attr_resend_igmp.attr,
> + &dev_attr_min_links.attr,
> NULL,
> };
>
> --- a/drivers/net/bonding/bonding.h 2011-06-22 09:05:32.351998841 -0700
> +++ b/drivers/net/bonding/bonding.h 2011-06-22 09:27:23.959999290 -0700
> @@ -147,6 +147,7 @@ struct bond_params {
> int updelay;
> int downdelay;
> int lacp_fast;
> + unsigned int min_links;
> int ad_select;
> char primary[IFNAMSIZ];
> int primary_reselect;
> --- a/drivers/net/bonding/bond_3ad.c 2011-06-22 08:43:25.599999586 -0700
> +++ b/drivers/net/bonding/bond_3ad.c 2011-06-22 09:44:11.815997557 -0700
> @@ -2342,8 +2342,12 @@ void bond_3ad_handle_link_change(struct
> */
> int bond_3ad_set_carrier(struct bonding *bond)
> {
> - if (__get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator))) {
> - if (!netif_carrier_ok(bond->dev)) {
> + struct aggregator *active;
> +
> + active = __get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator));
> + if (active) {
> + if (active->num_of_ports >= bond->params.min_links &&
> + !netif_carrier_ok(bond->dev)) {
> netif_carrier_on(bond->dev);
> return 1;
I'm not seeing how this will handle when one interface goes down leaving
the aggregator without the minimum number of links because you still have
an aggregator and link, so the resulting link wouldn't change.
I thought in something like this:
@@ -2345,18 +2345,31 @@ void bond_3ad_handle_link_change(struct slave *slave, char link)
*/
int bond_3ad_set_carrier(struct bonding *bond)
{
- if (__get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator))) {
- if (!netif_carrier_ok(bond->dev)) {
- netif_carrier_on(bond->dev);
- return 1;
+ struct aggregator *active;
+
+ active = __get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator));
+
+ if (active) {
+ if (active->num_of_ports >= bond->params.min_links) {
+ if (!netif_carrier_ok(bond->dev)) {
+ netif_carrier_on(bond->dev);
+ return 1;
+ }
+ }
+ else {
+ /* link is up without enough slaves, disable it */
+ if (netif_carrier_ok(bond->dev)) {
+ netif_carrier_off(bond->dev);
+ return 1;
+ }
}
- return 0;
}
- if (netif_carrier_ok(bond->dev)) {
+ if (!active && netif_carrier_ok(bond->dev)) {
netif_carrier_off(bond->dev);
return 1;
}
+
return 0;
}
what you think?
thanks,
fbl
^ permalink raw reply
* Re: [PATCH 4/5] pm: move pm notifiers into suspend.h
From: Rafael J. Wysocki @ 2011-06-22 19:49 UTC (permalink / raw)
To: Amerigo Wang
Cc: linux-kernel, akpm, netdev, Chris Ball, Len Brown, Pavel Machek,
Ohad Ben-Cohen, Linus Walleij, Philip Rakity, David S. Miller,
Lucas De Marchi, Paul E. McKenney, Josh Triplett, linux-mmc,
linux-pm
In-Reply-To: <1308724522-32461-5-git-send-email-amwang@redhat.com>
On Wednesday, June 22, 2011, Amerigo Wang wrote:
> It is not necessary to share the same notifier.h.
>
> Signed-off-by: WANG Cong <amwang@redhat.com>
>
> ---
> drivers/mmc/core/core.c | 3 +++
> include/linux/notifier.h | 10 ++--------
> include/linux/suspend.h | 8 ++++++++
> 3 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 68091dd..2cd4ec5 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -23,6 +23,9 @@
> #include <linux/log2.h>
> #include <linux/regulator/consumer.h>
> #include <linux/pm_runtime.h>
> +#ifdef CONFIG_PM
> +#include <linux/suspend.h>
> +#endif
I don't think the #ifdef in necessary. Any dependencies on CONFIG_PM
(or CONFIG_SUSPEND etc.) should be taken care of inside of suspend.h.
This file should be fixed if they aren't.
> #include <linux/mmc/card.h>
> #include <linux/mmc/host.h>
> diff --git a/include/linux/notifier.h b/include/linux/notifier.h
> index 145c436..ae8f7d9 100644
> --- a/include/linux/notifier.h
> +++ b/include/linux/notifier.h
> @@ -191,15 +191,9 @@ static inline int notifier_to_errno(int ret)
>
> /* reboot notifiers are defined in include/linux/reboot.h. */
>
> -#define NETLINK_URELEASE 0x0001 /* Unicast netlink socket released */
> +/* Hibernation and suspend events are defined in include/linux/suspend.h. */
>
> -/* Hibernation and suspend events */
> -#define PM_HIBERNATION_PREPARE 0x0001 /* Going to hibernate */
> -#define PM_POST_HIBERNATION 0x0002 /* Hibernation finished */
> -#define PM_SUSPEND_PREPARE 0x0003 /* Going to suspend the system */
> -#define PM_POST_SUSPEND 0x0004 /* Suspend finished */
> -#define PM_RESTORE_PREPARE 0x0005 /* Going to restore a saved image */
> -#define PM_POST_RESTORE 0x0006 /* Restore failed */
> +#define NETLINK_URELEASE 0x0001 /* Unicast netlink socket released */
>
> /* Console keyboard events.
> * Note: KBD_KEYCODE is always sent before KBD_UNBOUND_KEYCODE, KBD_UNICODE and
> diff --git a/include/linux/suspend.h b/include/linux/suspend.h
> index 083ffea..95bc81c 100644
> --- a/include/linux/suspend.h
> +++ b/include/linux/suspend.h
> @@ -260,6 +260,14 @@ static inline int hibernate(void) { return -ENOSYS; }
> static inline bool system_entering_hibernation(void) { return false; }
> #endif /* CONFIG_HIBERNATION */
>
> +/* Hibernation and suspend events */
> +#define PM_HIBERNATION_PREPARE 0x0001 /* Going to hibernate */
> +#define PM_POST_HIBERNATION 0x0002 /* Hibernation finished */
> +#define PM_SUSPEND_PREPARE 0x0003 /* Going to suspend the system */
> +#define PM_POST_SUSPEND 0x0004 /* Suspend finished */
> +#define PM_RESTORE_PREPARE 0x0005 /* Going to restore a saved image */
> +#define PM_POST_RESTORE 0x0006 /* Restore failed */
> +
> #ifdef CONFIG_PM_SLEEP
> void save_processor_state(void);
> void restore_processor_state(void);
>
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH net-next] bonding: add min links parameter to 802.3ad
From: Andy Gospodarek @ 2011-06-22 19:50 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jay Vosburgh, Andy Gospodarek, David Miller, netdev
In-Reply-To: <20110622105408.06fd4788@nehalam.ftrdhcpuser.net>
On Wed, Jun 22, 2011 at 10:54:08AM -0700, Stephen Hemminger wrote:
> This adds support for a configuring the minimum number of links that
> must be active before asserting carrier. It is similar to the Cisco
> EtherChannel min-links feature. This allows setting the minimum number
> of member ports that must be up (link-up state) before marking the
> bond device as up (carrier on). This is useful for situations where
> higher level services such as clustering want to ensure a minimum
> number of low bandwidth links are active before switchover.
>
> This is a prototype, did some basic testing but has not been
> tested with other switches.
>
> See:
> http://bugzilla.vyatta.com/show_bug.cgi?id=7196
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
[...]
> --- a/drivers/net/bonding/bond_3ad.c 2011-06-22 08:43:25.599999586 -0700
> +++ b/drivers/net/bonding/bond_3ad.c 2011-06-22 09:44:11.815997557 -0700
> @@ -2342,8 +2342,12 @@ void bond_3ad_handle_link_change(struct
> */
> int bond_3ad_set_carrier(struct bonding *bond)
> {
> - if (__get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator))) {
> - if (!netif_carrier_ok(bond->dev)) {
> + struct aggregator *active;
> +
> + active = __get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator));
> + if (active) {
> + if (active->num_of_ports >= bond->params.min_links &&
> + !netif_carrier_ok(bond->dev)) {
> netif_carrier_on(bond->dev);
> return 1;
> }
>
I agree with Flavio that it feels like there is a problem here. I was
just wrestling with my switch and trying to get LACP working there so I
could test this.
^ permalink raw reply
* Re: [PATCH net-next] bonding: add min links parameter to 802.3ad
From: Stephen Hemminger @ 2011-06-22 19:54 UTC (permalink / raw)
To: Flavio Leitner; +Cc: Jay Vosburgh, Andy Gospodarek, David Miller, netdev
In-Reply-To: <4E02452E.2030307@redhat.com>
This adds support for a configuring the minimum number of links that
must be active before asserting carrier. It is similar to the Cisco
EtherChannel min-links feature. This allows setting the minimum number
of member ports that must be up (link-up state) before marking the
bond device as up (carrier on). This is useful for situations where
higher level services such as clustering want to ensure a minimum
number of low bandwidth links are active before switchover.
See:
http://bugzilla.vyatta.com/show_bug.cgi?id=7196
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
v2 - need to transition to carrier_off if insufficient number of links
and whitespace cleanup
drivers/net/bonding/bond_3ad.c | 8 ++++++--
drivers/net/bonding/bond_main.c | 5 +++++
drivers/net/bonding/bond_procfs.c | 1 +
drivers/net/bonding/bond_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
drivers/net/bonding/bonding.h | 1 +
5 files changed, 48 insertions(+), 2 deletions(-)
--- a/drivers/net/bonding/bond_main.c 2011-06-22 09:06:40.895998636 -0700
+++ b/drivers/net/bonding/bond_main.c 2011-06-22 10:11:52.855974841 -0700
@@ -98,6 +98,7 @@ static char *mode;
static char *primary;
static char *primary_reselect;
static char *lacp_rate;
+static int min_links;
static char *ad_select;
static char *xmit_hash_policy;
static int arp_interval = BOND_LINK_ARP_INTERV;
@@ -150,6 +151,9 @@ module_param(ad_select, charp, 0);
MODULE_PARM_DESC(ad_select, "803.ad aggregation selection logic; "
"0 for stable (default), 1 for bandwidth, "
"2 for count");
+module_param(min_links, int, 0);
+MODULE_PARM_DESC(min_links, "Minimum number of available links before turning on carrier");
+
module_param(xmit_hash_policy, charp, 0);
MODULE_PARM_DESC(xmit_hash_policy, "balance-xor and 802.3ad hashing method; "
"0 for layer 2 (default), 1 for layer 3+4, "
@@ -4798,6 +4802,7 @@ static int bond_check_params(struct bond
params->tx_queues = tx_queues;
params->all_slaves_active = all_slaves_active;
params->resend_igmp = resend_igmp;
+ params->min_links = min_links;
if (primary) {
strncpy(params->primary, primary, IFNAMSIZ);
--- a/drivers/net/bonding/bond_procfs.c 2011-06-22 09:17:04.391998454 -0700
+++ b/drivers/net/bonding/bond_procfs.c 2011-06-22 09:27:09.815997950 -0700
@@ -125,6 +125,7 @@ static void bond_info_show_master(struct
seq_puts(seq, "\n802.3ad info\n");
seq_printf(seq, "LACP rate: %s\n",
(bond->params.lacp_fast) ? "fast" : "slow");
+ seq_printf(seq, "Min links: %d\n", bond->params.min_links);
seq_printf(seq, "Aggregator selection policy (ad_select): %s\n",
ad_select_tbl[bond->params.ad_select].modename);
--- a/drivers/net/bonding/bond_sysfs.c 2011-06-22 09:04:50.295998865 -0700
+++ b/drivers/net/bonding/bond_sysfs.c 2011-06-22 12:46:57.123624800 -0700
@@ -819,6 +819,38 @@ out:
static DEVICE_ATTR(lacp_rate, S_IRUGO | S_IWUSR,
bonding_show_lacp, bonding_store_lacp);
+static ssize_t bonding_show_min_links(struct device *d,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct bonding *bond = to_bond(d);
+
+ return sprintf(buf, "%d\n", bond->params.min_links);
+}
+
+static ssize_t bonding_store_min_links(struct device *d,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct bonding *bond = to_bond(d);
+ int ret;
+ unsigned int new_value;
+
+ ret = kstrtouint(buf, 0, &new_value);
+ if (ret < 0) {
+ pr_err("%s: Ignoring invalid min links value %s.\n",
+ bond->dev->name, buf);
+ return ret;
+ }
+
+ pr_info("%s: Setting min links value to %u\n",
+ bond->dev->name, new_value);
+ bond->params.min_links = new_value;
+ return count;
+}
+static DEVICE_ATTR(min_links, S_IRUGO | S_IWUSR,
+ bonding_show_min_links, bonding_store_min_links);
+
static ssize_t bonding_show_ad_select(struct device *d,
struct device_attribute *attr,
char *buf)
@@ -1601,6 +1633,7 @@ static struct attribute *per_bond_attrs[
&dev_attr_queue_id.attr,
&dev_attr_all_slaves_active.attr,
&dev_attr_resend_igmp.attr,
+ &dev_attr_min_links.attr,
NULL,
};
--- a/drivers/net/bonding/bonding.h 2011-06-22 09:05:32.351998841 -0700
+++ b/drivers/net/bonding/bonding.h 2011-06-22 09:27:23.959999290 -0700
@@ -147,6 +147,7 @@ struct bond_params {
int updelay;
int downdelay;
int lacp_fast;
+ unsigned int min_links;
int ad_select;
char primary[IFNAMSIZ];
int primary_reselect;
--- a/drivers/net/bonding/bond_3ad.c 2011-06-22 08:43:25.599999586 -0700
+++ b/drivers/net/bonding/bond_3ad.c 2011-06-22 12:51:43.431614028 -0700
@@ -2342,8 +2342,17 @@ void bond_3ad_handle_link_change(struct
*/
int bond_3ad_set_carrier(struct bonding *bond)
{
- if (__get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator))) {
- if (!netif_carrier_ok(bond->dev)) {
+ struct aggregator *active;
+
+ active = __get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator));
+ if (active) {
+ /* are enough slaves available to consider link up? */
+ if (active->num_of_ports < bond->params.min_links) {
+ if (netif_carrier_ok(bond->dev)) {
+ netif_carrier_off(bond->dev);
+ return 1;
+ }
+ } else if (!netif_carrier_ok(bond->dev)) {
netif_carrier_on(bond->dev);
return 1;
}
^ permalink raw reply
* Re: [PATCH]: Add Network Sysrq Support
From: David Miller @ 2011-06-22 20:27 UTC (permalink / raw)
To: prarit; +Cc: john.haxby, fw, fbl, netdev, agospoda, nhorman, lwoodman
In-Reply-To: <4E0228C3.8090402@redhat.com>
From: Prarit Bhargava <prarit@redhat.com>
Date: Wed, 22 Jun 2011 13:39:15 -0400
> davem -- as I don't monitor this list, are you indicating that you are
> more amenable to this code being accepted upstream? Or is that part of
> the debate still ongoing?
I'd rather have something like xt_SYSRQ in the tree than the original
proposal in this thread.
Work it out with the netfilter developers if you want to see it
integrated.
^ permalink raw reply
* Re: [PATCH]: Add Network Sysrq Support
From: David Miller @ 2011-06-22 20:29 UTC (permalink / raw)
To: jch; +Cc: prarit, fw, fbl, netdev, agospoda, nhorman, lwoodman
In-Reply-To: <9A104657-E760-4489-A92E-7DF04CC0EE6C@oracle.com>
From: John Haxby <jch@thehaxbys.co.uk>
Date: Wed, 22 Jun 2011 19:46:20 +0100
> davem: I'm more than happy to push that patch through if it will
> make xt_SYSRQ more acceptable.
It's not me who reviews and approves netfilter patches, it's
the netfilter developers who do.
^ permalink raw reply
* Re: [PATCH] net/usb: kalmia: Various fixes for better support of non-x86 architectures.
From: David Miller @ 2011-06-22 20:41 UTC (permalink / raw)
To: marius.kotsbak; +Cc: netdev, linux-usb, marius
In-Reply-To: <1308756376-9920-1-git-send-email-marius@kotsbak.com>
From: "Marius B. Kotsbak" <marius.kotsbak@gmail.com>
Date: Wed, 22 Jun 2011 17:26:16 +0200
> -Support for big endian.
> -Do not use USB buffers at the stack.
> -Safer/more efficient code for local constants.
>
> Signed-off-by: Marius B. Kotsbak <marius@kotsbak.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Remove Sven Eckelmann from BATMAN ADVANCED
From: Sven Eckelmann @ 2011-06-22 20:58 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <20110622.011620.1019772975075064501.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3455 bytes --]
On Wednesday 22 June 2011 01:16:20 David Miller wrote:
> From: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
> Date: Wed, 22 Jun 2011 09:41:45 +0200
>
> > On Tuesday 21 June 2011 14:35:15 David Miller wrote:
> >> All of this effort was placed to get this thing merged into the
> >> main tree, and then moved out of staging.
> >
> > "Shooting the messenger" - I think that is the matching phrase. Just try
> > to grep my name in the net/batman-adv/ and you will see it nowhere.
>
> It is everywhere as far as I am concerned, because you're the only person
> actually keeping upstream maintained and in sync.
That is more related to the fact that Mareks opinion on the topic is that only
one person should be in responsible for the linux merging and this position
should not be changed each time. And I understood the names in MAINTAINERS as
the persons which feel responsible and are the right ones to contact to get
something done (whether it is merging, submitting bug reports, asking for
information, ...).
> > The problem is that I am probably the most unimportant person in the
> > whole project.
>
> From my perspective, this is not true. You are the most important
> person. And this is because the people writing the code obviously
> don't care enough about upstream to do any merges themselves. Yet
> you do.
I think that I have to adjust your perspective slightly. I would never say
that Marek doesn't care about something. Yes, he never did a pull request, but
he always comes up and try to give further insight when it was needed. He is
currently the mastermind behind batman-adv and tries to keep everything
together.
He already wrote you that he is willing to take over and I will assist him as
good as I can (but not doing pull request anymore or giving statements whether
a patch is good or bad for batman-adv/linux)
Just to give you a small overview about the stuff where currently work is done
(as far as I know). More or less the complete protocol should be rewritten and
many features should be added. You already got the first step when you merged
the translation table and roaming changes [1]. Other topics seem to be:
* multicast[2]
* splitting OGMs[3] in ELP[4], OGM and something else
* Adding support for an ARP protocol over distributed hash tables[5]
* wireless network coding[7]
* ap isolation
* mesh wide minstrel
* transmission quality calculated using the data from the wifi drivers along
the path
* redundancy bonding
* ...
Every change needs some modifications to the packet format and may make it
incompatible to the previous versions (some only add flags and some need to
modify many things and even add new packet types). They already started to
discuss[8] how they want to send those changes to you.
thanks,
Sven
[1] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2011-June/005010.html
[2] http://www.open-mesh.org/wiki/batman-adv/Multicast-ideas
[3] http://www.open-mesh.org/wiki/batman-adv/OGM
[4] http://www.open-mesh.org/wiki/batman-adv/ELP
[5] http://www.open-mesh.org/wiki/batman-adv/DAT
[6] http://www.open-mesh.org/wiki/batman-adv/MGO
[7] http://downloads.open-mesh.org/batman/misc/wbmv4-network_coding.avi
(there is a document called "Inter-Flow Network Coding for Wireless Mesh
Networks" about it, but I don't think that I am allowed to redistribute
it)
[8] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2011-June/005025.html
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* iproute correlated loss generator parts are missing
From: Hagen Paul Pfeifer @ 2011-06-22 21:07 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, stefano.salsano, fabio.ludovici
Hey Stephen,
NetemCLG (Correlated Loss Generator) patches[1] for iproute are still missing.
The kernel patch are already mainline but it falls difficult to use it. :-)
Nice add-on: they even wrote a man page for netem.
Hagen
[1] http://netgroup.uniroma2.it/twiki/bin/view.cgi/Main/NetemCLG#NetemCLGPatch
^ permalink raw reply
* Re: [PATCH net-next] bonding: add min links parameter to 802.3ad
From: Flavio Leitner @ 2011-06-22 21:35 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jay Vosburgh, Andy Gospodarek, David Miller, netdev
In-Reply-To: <20110622125439.44e47a2c@nehalam.ftrdhcpuser.net>
On 06/22/2011 04:54 PM, Stephen Hemminger wrote:
> This adds support for a configuring the minimum number of links that
> must be active before asserting carrier. It is similar to the Cisco
> EtherChannel min-links feature. This allows setting the minimum number
> of member ports that must be up (link-up state) before marking the
> bond device as up (carrier on). This is useful for situations where
> higher level services such as clustering want to ensure a minimum
> number of low bandwidth links are active before switchover.
>
> See:
> http://bugzilla.vyatta.com/show_bug.cgi?id=7196
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> ---
> v2 - need to transition to carrier_off if insufficient number of links
> and whitespace cleanup
>
> drivers/net/bonding/bond_3ad.c | 8 ++++++--
> drivers/net/bonding/bond_main.c | 5 +++++
> drivers/net/bonding/bond_procfs.c | 1 +
> drivers/net/bonding/bond_sysfs.c | 35 +++++++++++++++++++++++++++++++++++
> drivers/net/bonding/bonding.h | 1 +
> 5 files changed, 48 insertions(+), 2 deletions(-)
[...]
> --- a/drivers/net/bonding/bond_3ad.c 2011-06-22 08:43:25.599999586 -0700
> +++ b/drivers/net/bonding/bond_3ad.c 2011-06-22 12:51:43.431614028 -0700
> @@ -2342,8 +2342,17 @@ void bond_3ad_handle_link_change(struct
> */
> int bond_3ad_set_carrier(struct bonding *bond)
> {
> - if (__get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator))) {
> - if (!netif_carrier_ok(bond->dev)) {
> + struct aggregator *active;
> +
> + active = __get_active_agg(&(SLAVE_AD_INFO(bond->first_slave).aggregator));
> + if (active) {
> + /* are enough slaves available to consider link up? */
> + if (active->num_of_ports < bond->params.min_links) {
> + if (netif_carrier_ok(bond->dev)) {
> + netif_carrier_off(bond->dev);
> + return 1;
> + }
> + } else if (!netif_carrier_ok(bond->dev)) {
> netif_carrier_on(bond->dev);
> return 1;
> }
Looks good and works here, thanks!
Signed-off-by: Flavio Leitner <fbl@redhat.com>
fbl
^ permalink raw reply
* Remove IPv6 ND prefix on ethernet disconnect?
From: Harald Welte @ 2011-06-22 21:41 UTC (permalink / raw)
To: netdev
Hi all,
I know I've lost a bit touch with the Linux networking area in recent
years...
Nonetheless, there's one thing that's been bugging me for a long time
and I'm thinking of investing some time to resolve it. Before doing
that, I'm curious to see if there are existing solutions or existing
discussions that I've missed on the subject:
Imagine a setting where somebody is carrying a laptop around all day,
visiting several sites (office, customer, home,...) without rebooting
the machine (suspend to ram or disk).
You start at home in the morning, you get an IPv6 prefix via
auto-discovery, everything is fine. Now you move along to your office,
but despite the link down and link up events, the IPv6 prefix remains
configured.
You may or may not get a new prefix, but based on my experience, in both
cases you experience errors following up:
1) in the case of the new prefix, the old default route/prefix is still
used
2) in case there is no new prefix, the kernel happily sends ipv6 packets
to the non-existant router of a completely different network.
Now I presume that those things are supposedly resolved by
NetworkManager, but I don't really see why a complex and large userspace
program should be required for something as simple as removing prefixes
that have prevously been added automatically.
My point is: If it's the kernel that automatically adds it, why is it
not the kernel that automatically deletes it when it is no longer safe
to assume it is valid (such as after loosing the link)?
Any input is appreciated. Regards,
Harald
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
^ permalink raw reply
* Re: [PATCH] net: wimax: Remove of unused 'rfkill_input' pointer
From: Perez-Gonzalez, Inaky @ 2011-06-22 21:47 UTC (permalink / raw)
To: vitalivanov@gmail.com
Cc: davem@davemloft.net, johannes@sipsolutions.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
alan-jenkins@tuffmail.co.uk, hmh@hmh.eng.br,
linville@tuxdriver.com
In-Reply-To: <1308766004.13761.32.camel@vivanov>
On Wed, 2011-06-22 at 21:06 +0300, Vitaliy Ivanov wrote:
> David,
>
> Please apply.
>
> I added here all the peoples who took part in
> 19d337dff95cbf76edd3ad95c0cee2732c3e1ec5 commit for any comments.
>
> Also performed all yes/no/mod config builds w/ no issues.
> >From b93ca8947e85e4ff7e9f314675d4770b90b77548 Mon Sep 17 00:00:00 2001
> From: Vitaliy Ivanov <vitalivanov@gmail.com>
> Date: Wed, 22 Jun 2011 20:57:49 +0300
> Subject: [PATCH] net: wimax: Remove of unused 'rfkill_input' pointer
>
> Seems like this was not cleaned during the 'rfkill: rewrite' checkin
> 19d337dff95cbf76edd3ad95c0cee2732c3e1ec5.
>
> Signed-off-by: Vitaliy Ivanov <vitalivanov@gmail.com>
Acked-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
^ permalink raw reply
* Re: net/ipv4: commit d0733d2e29b breaks rtorrent
From: Fabienne Ducroquet @ 2011-06-22 23:02 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Reinhard Max, Marcus Meissner, sundell.software, David S. Miller,
netdev
In-Reply-To: <20110622085329.65c625de@nehalam.ftrdhcpuser.net>
On Wed, Jun 22, 2011 at 08:53:29AM -0700, Stephen Hemminger wrote:
> You can find code here http://libtorrent.rakshasa.no/
> but it is in C++ so there is an abnormally high indirection factor
> between reality of the bug and the code as written.
I had a look at the code, I found where bind is called, but it does not
help: it is in libtorrent/src/net/socket_fd.cc:
bool
SocketFd::bind(const rak::socket_address& sa) {
check_valid();
return !::bind(m_fd, sa.c_sockaddr(), sa.length());
}
check_valid() checks the validity of the socket FD.
It is called by the function:
bool
Listen::open(uint16_t first, uint16_t last, const rak::socket_address* bindAddress) {
close();
[ Checks that the range of the ports is OK, that the address
is an inet or inet6 address, that the socket can be
allocated.]
rak::socket_address sa;
sa.copy(*bindAddress, bindAddress->length());
for (uint16_t i = first; i <= last; ++i) {
sa.set_port(i);
if (get_fd().bind(sa) && get_fd().listen(50)) {
...
in libtorrent/src/net/listen.cc. That function was called by:
bool
ConnectionManager::listen_open(port_type begin, port_type end) {
if (!m_listen->open(begin, end, rak::socket_address::cast_from(m_bindAddress)))
return false;
m_listenPort = m_listen->port();
return true;
}
in libtorrent/src/torrent/connection_manager.cc, and it was itself
called by Manager::listen_open() in rtorrent/core/manager.cc, which
throws the error message I got because the call to
torrent::connection_manager()->listen_open(portFirst, portLast)
fails.
So the question now is to find how the m_bindAddress used in
ConnectionManager::listen_open is set, but I prefer not to do that right
now.
> Did you try contacting the developer?
I've put him in the Cc: since the first message.
Fabienne
^ permalink raw reply
* Re: [RFT PATCH v3 00/12] Cleanup and extension of netdev features
From: Ben Greear @ 2011-06-22 23:11 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev, David S. Miller, Ben Hutchings
In-Reply-To: <cover.1308758435.git.mirq-linux@rere.qmqm.pl>
On 06/22/2011 09:04 AM, Michał Mirosław wrote:
> v3 of a feature handling cleanup and extension series. For testing, you
> might want user-space ethtool patched with:
>
> http://patchwork.ozlabs.org/patch/96374/
There is a typo in one of those patches:
CC fs/quota/netlink.o
/home/greearb/git/net-next-2.6/net/core/dev.c: In function ‘__netdev_update_features’:
/home/greearb/git/net-next-2.6/net/core/dev.c:5288: warning: too many arguments for format
CC net/core/ethtool.o
netdev_dbg(dev, "Features changed: %pNF -> pNF\n",
&dev->features, &features);
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Weird locking in __release_sock()?
From: David Daney @ 2011-06-22 23:31 UTC (permalink / raw)
To: netdev
Hi,
In net/core/sock.c the function __release_sock() appears to drop the
socket lock, and then feed the backlogged skbs to sk_backlog_rcv().
In the case of an IPv4 TCP socket, sk_backlog_rcv() calls
tcp_v4_do_rcv(), which is documented like this:
/* The socket must have it's spinlock held when we get
* here.
.
.
.
*/
Q: How can this be correct?
Perhaps I am missing something. In any event, thanks in advance
shedding some light on the locking situation.
David Daney
^ permalink raw reply
* Re: Remove IPv6 ND prefix on ethernet disconnect?
From: Hagen Paul Pfeifer @ 2011-06-22 23:33 UTC (permalink / raw)
To: Harald Welte; +Cc: netdev
In-Reply-To: <20110622214129.GA30521@prithivi.gnumonks.org>
* Harald Welte | 2011-06-22 23:41:29 [+0200]:
>My point is: If it's the kernel that automatically adds it, why is it
>not the kernel that automatically deletes it when it is no longer safe
>to assume it is valid (such as after loosing the link)?
Is loosing the link a sufficient criterion to restart ND? IMHO it is superior
to keep the same IP address (I assume privacy extension enabled) in the same
network if you lose the link artificial.
Environments where the link goes down and up again may suffer from such a
behavior. Maybe a script in Network Manager may be the better place. For me it
sounds like a policy thing which should not handled in the kernel.
But yes Harald, I understand your objection! ;-)
Hagen
^ permalink raw reply
* unintended ipv4 broadcast policy change
From: David Miller @ 2011-06-22 23:39 UTC (permalink / raw)
To: herbert; +Cc: netdev
The context is that I'm looking into cleaning up up the mess we have
wrt. DHCP listening on packet sockets and (in some cases) seeing every
packet that hits the system.
Anyways, back in 2007 this commit was made:
commit 8030f54499925d073a88c09f30d5d844fb1b3190
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu Feb 22 01:53:47 2007 +0900
[IPV4] devinet: Register inetdev earlier.
So now every net device registered has inetdev_init() called on it.
This has a subtle policy side effect that has some interesting
implications. The route input slow path has this check:
/* IP on this device is disabled. */
if (!in_dev)
goto out;
But now this will never, ever, be true.
Which means that previously we would not accept even broadcast
or multicast packets on an interface that hasn't had at least
one IP address configured.
Now we will.
I think we have a hard decision to make. One option is to
fix the input routing check, by changing it to test if the
ipv4 address list is empty.
The second option is to remove the check entirely and keep the
new behavior.
This subtle new behavior is interesting because it means that
a DHCP client could be implemented entirely with plain UDP
sockets.
Contrary to previous discussions I see no code in the ISC dhcp
client that needs to get at the MAC address. It merely wants
it there so that it's packet parsing engine can skip over it
to get at the ipv4/UDP bits.
In fact the stock ISC dhcp code has a bug in that it creates
it's AF_PACKET socket with SOCK_PACKET as the type, which causes
the BPF filter it registers to never be used. It should be
using SOCK_RAW as the type. It seems to use SOCK_PACKET in
order to use the name based socket address in it's bind()
call.
As a side effect of an unrelated change, this bug got fixed in
Fedora/RHEL (it wants access to the tpacket aux data in order to see
the checksum flags, this is not available with SOCK_PACKET type
AF_PACKET sockets).
But debian definitely still has this bug. On debian, as a result,
every packet received gets parsed.
Actually this bug is more serious, since the code in ISC dhcp
elides the UDP protocol and port validation if it is compiled
with the BPF code in place (which it is). This means it's
parsing garbage most of the time.
It also creates the packet socket with ETH_P_ALL, making this
an even more severe issue.
^ permalink raw reply
* Re: Weird locking in __release_sock()?
From: David Miller @ 2011-06-22 23:42 UTC (permalink / raw)
To: ddaney; +Cc: netdev
In-Reply-To: <4E027B41.3040009@caviumnetworks.com>
From: David Daney <ddaney@caviumnetworks.com>
Date: Wed, 22 Jun 2011 16:31:13 -0700
> In the case of an IPv4 TCP socket, sk_backlog_rcv() calls
> tcp_v4_do_rcv(), which is documented like this:
>
> /* The socket must have it's spinlock held when we get
> * here.
> .
> .
> .
> */
>
> Q: How can this be correct?
sk->lock.owned will be "1" while the backlog is processed.
Exclusive access to the socket is indicated by one of the
following two conditions being true:
1) sk->lock.slock being held
2) sk->lock.owned being non-zero
^ permalink raw reply
* Re: [PATCH 07/11] fs_enet: enable transmit time stamping.
From: Matt Carlson @ 2011-06-22 23:56 UTC (permalink / raw)
To: Richard Cochran
Cc: Eric Dumazet, netdev@vger.kernel.org, David Miller,
Matthew Carlson, Michael Chan
In-Reply-To: <20110620065831.GA5771@riccoc20.at.omicron.at>
On Sun, Jun 19, 2011 at 11:58:31PM -0700, Richard Cochran wrote:
> On Sun, Jun 19, 2011 at 08:30:49PM +0200, Eric Dumazet wrote:
> > Le dimanche 19 juin 2011 ? 20:12 +0200, Richard Cochran a ?crit :
> >
> > > Thanks for your review. I have posted a fix for the first batch (since
> > > they are already in next) and reposted this series.
> > >
> > > But, considering your point, it looks like pxa168_eth and mv643xx_eth
> > > (see patches 9 and 10 of this series) already access skb->len unsafely.
> > >
> > > Would you care to comment on those spots, too?
> >
> > They certainly are buggy, at a first glance.
> >
> > Not only skb->len is unsafe, but netif_tx_stop_queue() calls are unsafe
> > too.
>
> Out of the MAC drivers in my two batches, only drivers/net/tg3.c calls
> netif_tx_stop_queue(txq);
>
> However, I don't know how to fix that. Anyone else care to take a look?
How is netif_tx_stop_queue() unsafe?
^ 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