* [PATCH] be2net: Missing byteswap in be_get_fw_log_level causes oops on PowerPC
From: Anton Blanchard @ 2012-07-25 1:05 UTC (permalink / raw)
To: sathya.perla, subbu.seetharaman, ajit.khaparde, netdev
We are seeing an oops in be_get_fw_log_level on ppc64 where we walk
off the end of memory.
commit 941a77d582c8 (be2net: Fix to allow get/set of debug levels in
the firmware.) requires byteswapping of num_modes and num_modules.
Cc: stable@vger.kernel.org # 3.5+
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c b/drivers/net/ethernet/emulex/benet/be_ethtool.c
index 63e51d4..59ee51a 100644
--- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
+++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
@@ -910,8 +910,9 @@ static void be_set_fw_log_level(struct be_adapter *adapter, u32 level)
if (!status) {
cfgs = (struct be_fat_conf_params *)(extfat_cmd.va +
sizeof(struct be_cmd_resp_hdr));
- for (i = 0; i < cfgs->num_modules; i++) {
- for (j = 0; j < cfgs->module[i].num_modes; j++) {
+ for (i = 0; i < le32_to_cpu(cfgs->num_modules); i++) {
+ u32 num_modes = le32_to_cpu(cfgs->module[i].num_modes);
+ for (j = 0; j < num_modes; j++) {
if (cfgs->module[i].trace_lvl[j].mode ==
MODE_UART)
cfgs->module[i].trace_lvl[j].dbg_lvl =
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 501dfa9..bd5cf7e 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -3479,7 +3479,7 @@ u32 be_get_fw_log_level(struct be_adapter *adapter)
if (!status) {
cfgs = (struct be_fat_conf_params *)(extfat_cmd.va +
sizeof(struct be_cmd_resp_hdr));
- for (j = 0; j < cfgs->module[0].num_modes; j++) {
+ for (j = 0; j < le32_to_cpu(cfgs->module[0].num_modes); j++) {
if (cfgs->module[0].trace_lvl[j].mode == MODE_UART)
level = cfgs->module[0].trace_lvl[j].dbg_lvl;
}
^ permalink raw reply related
* Re: [PATCH 03/17] Drivers: hv: kvp: Cleanup error handling in KVP
From: Ben Hutchings @ 2012-07-25 1:10 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: gregkh, linux-kernel, devel, virtualization, olaf, apw, netdev
In-Reply-To: <1343145701-3691-3-git-send-email-kys@microsoft.com>
[-- Attachment #1: Type: text/plain, Size: 2800 bytes --]
On Tue, 2012-07-24 at 09:01 -0700, K. Y. Srinivasan wrote:
> In preparation to implementing IP injection, cleanup the way we propagate
> and handle errors both in the driver as well as in the user level daemon.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
> ---
> drivers/hv/hv_kvp.c | 112 +++++++++++++++++++++++++++++++++++++---------
> include/linux/hyperv.h | 17 +++++---
> tools/hv/hv_kvp_daemon.c | 70 +++++++++++++++-------------
> 3 files changed, 138 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
> index 0012eed..9b7fc4a 100644
> --- a/drivers/hv/hv_kvp.c
> +++ b/drivers/hv/hv_kvp.c
[...]
> @@ -109,27 +154,52 @@ kvp_cn_callback(struct cn_msg *msg, struct netlink_skb_parms *nsp)
> {
> struct hv_kvp_msg *message;
> struct hv_kvp_msg_enumerate *data;
> + int error = 0;
>
> message = (struct hv_kvp_msg *)msg->data;
> - switch (message->kvp_hdr.operation) {
> +
> + /*
> + * If we are negotiating the version information
> + * with the daemon; handle that first.
> + */
> +
> + if (in_hand_shake) {
> + if (kvp_handle_handshake(message))
> + in_hand_shake = false;
> + return;
> + }
> +
> + /*
> + * Based on the version of the daemon, we propagate errors from the
> + * daemon differently.
> + */
> +
> + data = &message->body.kvp_enum_data;
> +
> + switch (dm_reg_value) {
> case KVP_OP_REGISTER:
> - pr_info("KVP: user-mode registering done.\n");
> - kvp_register();
> - kvp_transaction.active = false;
> - hv_kvp_onchannelcallback(kvp_transaction.kvp_context);
> + /*
> + * Null string is used to pass back error condition.
> + */
> + if (!strlen(data->data.key))
Do we know that the key is null-terminated here? Shouldn't we just
check whether data->data.key[0] == 0?
> + error = HV_S_CONT;
> break;
>
> - default:
> - data = &message->body.kvp_enum_data;
> + case KVP_OP_REGISTER1:
> /*
> - * Complete the transaction by forwarding the key value
> - * to the host. But first, cancel the timeout.
> + * We use the message header information from
> + * the user level daemon to transmit errors.
> */
> - if (cancel_delayed_work_sync(&kvp_work))
> - kvp_respond_to_host(data->data.key,
> - data->data.value,
> - !strlen(data->data.key));
> + error = *((int *)(&message->kvp_hdr.operation));
[...]
What's with the casting (repeated in many other places)? Wouldn't it be
better to redefine struct hv_kvp_msg to start with something like:
union {
struct hv_kvp_hdr request;
int error;
} kvp_hdr;
Ben.
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 08/17] Tools: hv: Gather subnet information
From: Ben Hutchings @ 2012-07-25 1:14 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: gregkh, linux-kernel, devel, virtualization, olaf, apw, netdev
In-Reply-To: <1343145701-3691-8-git-send-email-kys@microsoft.com>
[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]
On Tue, 2012-07-24 at 09:01 -0700, K. Y. Srinivasan wrote:
> Now gather sub-net information for the specified interface.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
> ---
> tools/hv/hv_kvp_daemon.c | 31 +++++++++++++++++++++++++++++--
> 1 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
> index 79eb130..2c24ebf 100644
> --- a/tools/hv/hv_kvp_daemon.c
> +++ b/tools/hv/hv_kvp_daemon.c
> @@ -534,6 +534,7 @@ kvp_get_ip_address(int family, char *if_name, int op,
> struct ifaddrs *ifap;
> struct ifaddrs *curp;
> int offset = 0;
> + int sn_offset = 0;
> const char *str;
> int error = 0;
> char *buffer;
> @@ -594,12 +595,38 @@ kvp_get_ip_address(int family, char *if_name, int op,
> * Gather info other than the IP address.
> * IP address info will be gathered later.
> */
> - if (curp->ifa_addr->sa_family == AF_INET)
> + if (curp->ifa_addr->sa_family == AF_INET) {
> ip_buffer->addr_family |= ADDR_FAMILY_IPV4;
> - else
> + /*
> + * Get subnet info.
> + */
> + error = kvp_process_ip_address(
> + curp->ifa_netmask,
> + AF_INET,
> + (char *)
> + ip_buffer->sub_net,
> + length,
> + &sn_offset);
[...]
This is barely readable; why don't you indent the arguments by just one
extra tab?
Ben.
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 13/17] Tools: hv: Implement the KVP verb - KVP_OP_SET_IP_INFO
From: Ben Hutchings @ 2012-07-25 1:24 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: olaf, gregkh, linux-kernel, virtualization, netdev, apw, devel
In-Reply-To: <1343145701-3691-13-git-send-email-kys@microsoft.com>
[-- Attachment #1.1: Type: text/plain, Size: 3358 bytes --]
On Tue, 2012-07-24 at 09:01 -0700, K. Y. Srinivasan wrote:
> Implement the KVP verb - KVP_OP_SET_IP_INFO. This operation configures the
> specified interface based on the given configuration. Since configuring
> an interface is very distro specific, we invoke an external script to
> configure the interface.
[...]
> +static int kvp_write_file(FILE *f, char *s1, char *s2, char *s3)
> +{
> + char str[256];
> + int error;
> +
> + memset(str, 0, sizeof(str));
> + strcat(str, s1);
> + if (s2 != NULL)
> + strcat(str, s2);
> + strcat(str, "=");
> + strcat(str, s3);
> + strcat(str, "\n");
> +
> + error = fputs(str, f);
This style of string pasting is crazy; have you never heard of
fprintf()?
[...]
> + /*
> + * Set the configuration for the specified interface with
> + * the information provided. Since there is no standard
> + * way to configure an interface, we will have an external
> + * script that does the job of configuring the interface and
> + * flushing the configuration.
> + *
> + * The parameters passed to this external script are:
> + * 1. A configuration file that has the specified configuration.
> + *
> + * We will embed the name of the interface in the configuration
> + * file: ifcfg-ethx (where ethx is the interface name).
> + *
> + * Here is the format of the ip configuration file:
> + *
> + * HWADDR=macaddr
Is the interface supposed to be matched by name or by MAC address?
> + * BOOTPROTO=dhcp (dhcp enabled for the interface)
The BOOTPROTO line may or may not appear.
> + * NM_CONTROLLED=no (this interface will not be controlled by NM)
> + * PEERDNS=yes
I wonder what the point is of including constant lines in the file.
What is the external script supposed to do if it these apparent
constants change in future?
> + * IPADDR_x=ipaddr
> + * NETMASK_x=netmask
> + * GATEWAY_x=gateway
> + * DNSx=dns
A strangely familiar format...
> + * IPV6 addresses will be tagged as IPV6ADDR, IPV6 gateway will be
> + * tagged as IPV6_DEFAULTGW and IPV6 NETMASK will be tagged as
> + * IPV6NETMASK.
> + */
> +
> + memset(if_file, 0, sizeof(if_file));
> + strcat(if_file, "/var/opt/hyperv/ifcfg-");
Like I said before about the key-value files, this should be under
/var/lib if the daemon is included in a distribution. You should
perhaps use a macro for the "/var/opt" part so it can be overridden
depending on whether it's built as a distribution or add-on package.
> + strcat(if_file, if_name);
> +
> + file = fopen(if_file, "w");
> +
> + if (file == NULL) {
> + syslog(LOG_ERR, "Failed to open config file");
> + return HV_E_FAIL;
> + }
> +
> + /*
> + * First write out the MAC address.
> + */
> +
> + mac_addr = kvp_if_name_to_mac(if_name);
> + if (mac_addr == NULL) {
> + error = HV_E_FAIL;
> + goto setval_error;
> + }
> +
> + error = kvp_write_file(file, "HWADDR", NULL, mac_addr);
> + if (error)
> + goto setval_error;
> +
> + error = kvp_write_file(file, "ONBOOT", NULL, "yes");
> + if (error)
> + goto setval_error;
> +
> + error = kvp_write_file(file, "IPV6INIT", NULL, "yes");
> + if (error)
> + goto setval_error;
[...]
This line isn't mentioned in the above comment.
Ben.
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
^ permalink raw reply
* RE: [RFC] r8169 : why SG / TX checksum are default disabled
From: hayeswang @ 2012-07-25 2:10 UTC (permalink / raw)
To: 'David Miller'; +Cc: romieu, eric.dumazet, netdev, 'nic_swsd'
In-Reply-To: <20120723.235931.725099984853258732.davem@davemloft.net>
David Miller [mailto:davem@davemloft.net]
> Sent: Tuesday, July 24, 2012 3:00 PM
> To: Hayeswang
> Cc: romieu@fr.zoreil.com; eric.dumazet@gmail.com;
> netdev@vger.kernel.org
> Subject: Re: [RFC] r8169 : why SG / TX checksum are default disabled
>
[...]
>
> I still have not seen a good explanation why the chip modifies fields
> in the packet, such as the length, when we ask it only to compute the
> checksum?
I don't know the history and the detail about the bug. I think only our designer
could answer your question. I guess it is a careless mistake.
Best Regards,
Hayes
^ permalink raw reply
* Re: [PATCH] ppp: add 64 bit stats
From: Kevin Groeneveld @ 2012-07-25 2:27 UTC (permalink / raw)
To: netdev
In-Reply-To: <1343110954.2626.11040.camel@edumazet-glaptop>
On Tue, Jul 24, 2012 at 2:22 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2012-07-23 at 21:53 -0400, Kevin Groeneveld wrote:
>> On Mon, Jul 23, 2012 at 11:59 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> >> Would proper synchronization in this case just be wrapping the updates
>> >> in a spin_lock/spin_unlock?
>> >
>> > Would be fine (if the proper BH safe variant is used), or you could also
>> > use atomic64_t.
>>
>> Which would you recommend, spin locks or atomic64_t?
>>
>> atomic64_t seems like it would be simpler.
>
> Simpler but a bit more expensive when two counters are changed at the
> same time.
>
> (two atomic ops instead of a single one for the spinlock)
After looking at the existing ppp code more I wonder if I would even
need to add my own spinlocks. It seems the only spots I am updating
the 64 bit stats are already protected by either ppp->wlock or
ppp->rlock spinlocks. If I used two separate u64_stats_sync
structures, one for tx stats and one for rx stats, wouldn't the
existing spinlocks be enough?
^ permalink raw reply
* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: Xufeng Zhang @ 2012-07-25 2:28 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: xufeng zhang, sri, davem, linux-sctp, netdev, linux-kernel
In-Reply-To: <75bdd73e-1c47-4fd6-bc29-5b86ee6da69a@email.android.com>
On 7/24/12, Vlad Yasevich <vyasevich@gmail.com> wrote:
>>>> And I should clarify the above judgment code.
>>>> AFAIK, there should be two cases for the bundling when invalid
>>stream
>>>> identifier error happens:
>>>> 1). COOKIE_ACK ERROR SACK
>>>> 2). ERROR SACK
>>>> So I need to deal with the two cases differently.
>>>>
>>>>
>>> Sorry but I just don't buy that the above are the only 2 cases. What
>>if there are addip chunks as well? What if there are some other
>>extensions also. This code has to be generic enough to handle any
>>condition.
>>>
>>Aha, you are right, this may happens.
>>So I think the general solution is to fix this problem in the enqueue
>>side.
>>What do you think? any better suggestion!
>>
>
> Don't have code in front of me but what if we carry the error condition to
> where we queue the Sack and add the error side effect then?
Yes, this is the most direct way to fix this problem.
But I don't think it's the best way since we will take care of a lot
of things and
it also involves in lots of changes to side effect processing.
I prefer to Neil Horman's way for the solution since only COOKIE_ACK chunk is
allowed to place ahead of SACK chunk when bundling into one packet.
What do you think?
Thanks,
Xufeng Zhang
>
> -vlad
^ permalink raw reply
* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: Xufeng Zhang @ 2012-07-25 2:34 UTC (permalink / raw)
To: Neil Horman
Cc: xufeng zhang, vyasevich, sri, davem, linux-sctp, netdev,
linux-kernel
In-Reply-To: <20120724113802.GA30142@hmsreliant.think-freely.org>
On 7/24/12, Neil Horman <nhorman@tuxdriver.com> wrote:
> On Tue, Jul 24, 2012 at 09:50:18AM +0800, xufeng zhang wrote:
>> On 07/23/2012 08:14 PM, Neil Horman wrote:
>> >On Mon, Jul 23, 2012 at 10:30:34AM +0800, xufeng zhang wrote:
>> >>On 07/23/2012 08:49 AM, Neil Horman wrote:
>> >>>Not sure I understand how you came into this error. If we get an
>> >>> invalid
>> >>>stream, we issue an SCTP_REPORT_TSN side effect, followed by an
>> >>> SCTP_CMD_REPLY
>> >>>which sends the error chunk. The reply goes through
>> >>>sctp_outq_tail->sctp_outq_chunk->sctp_outq_transmit_chunk->sctp_outq_append_chunk.
>> >>>That last function checks to see if a sack is already part of the
>> >>> packet, and if
>> >>>there isn't one, appends one, using the updated tsn map.
>> >>Yes, you are right, but consider the invalid stream identifier's
>> >>DATA chunk is the first
>> >>DATA chunk in the association which will need SACK immediately.
>> >>Here is what I thought of the scenario:
>> >> sctp_sf_eat_data_6_2()
>> >> -->sctp_eat_data()
>> >> -->sctp_make_op_error()
>> >> -->sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>> >> SCTP_CHUNK(err))
>> >> -->sctp_outq_tail() /* First enqueue ERROR chunk
>> >> */
>> >> -->sctp_add_cmd_sf(commands, SCTP_CMD_GEN_SACK, SCTP_FORCE())
>> >> -->sctp_gen_sack()
>> >> -->sctp_make_sack()
>> >> -->sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>> >>SCTP_CHUNK(sack))
>> >> -->sctp_outq_tail() /* Then enqueue SACK chunk
>> >> */
>> >>
>> >>So SACK chunk is enqueued after ERROR chunk.
>> >Ah, I see. Since the ERROR and SACK chunks are both control chunks, and
>> > since
>> >we explicitly add the SACK to the control queue instead of going through
>> > the
>> >bundle path in sctp_packet_append_chunk the ordering gets wrong.
>> >
>> >Ok, so the problem makes sense. I think the soultion could be alot
>> > easier
>> >though. IIRC SACK chunks always live at the head of a packet, so why not
>> > just
>> >special case it in sctp_outq_tail? I.e. instead of doing a
>> > list_add_tail, in
>> >the else clause of sctp_outq_tail check the chunk_hdr->type to see if
>> > its
>> >SCTP_CID_SACK. If it is, use list_add_head rather than list_add_tail. I
>> > think
>> >that will fix up both the COOKIE_ECHO and ESTABLISHED cases, won't it?
>> > And then
>> >you won't have keep track of extra state in the packet configuration.
>> Yes, it's a good idea, but I think the premise is not correct:
>> RFC 4960 page 57:
>> "D) Upon reception of the COOKIE ECHO chunk, endpoint "Z" will reply
>> with a COOKIE ACK chunk after building a TCB and moving to the
>> ESTABLISHED state. A COOKIE ACK chunk may be bundled with any
>> pending DATA chunks (and/or SACK chunks), *but the COOKIE ACK chunk
>> MUST be the first chunk in the packet*."
>>
>> So we can't put SACK chunk always at the head of the packet.
>>
> Ok, Fair point, but that just changes the ordering a bit to:
> COOKIE_ACK
> SACK
> OTHER CONTROL CHUNKS
>
> What about something like this? Its completely untested, and I'm sure it
> can be
> cleaned up a bunch, but this keeps us from having to add additional state to
> the
> packet structure.
Yeah! I like this modification, thank you very much for your work!
I'll try to send a V2 patch based on your changes and run some tests.
Thanks,
Xufeng Zhang
>
>
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index e7aa177c..eeac32f 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -300,7 +300,7 @@ void sctp_outq_free(struct sctp_outq *q)
> int sctp_outq_tail(struct sctp_outq *q, struct sctp_chunk *chunk)
> {
> int error = 0;
> -
> + struct sctp_chunk *cptr;
> SCTP_DEBUG_PRINTK("sctp_outq_tail(%p, %p[%s])\n",
> q, chunk, chunk && chunk->chunk_hdr ?
> sctp_cname(SCTP_ST_CHUNK(chunk->chunk_hdr->type))
> @@ -344,7 +344,21 @@ int sctp_outq_tail(struct sctp_outq *q, struct
> sctp_chunk *chunk)
> break;
> }
> } else {
> - list_add_tail(&chunk->list, &q->control_chunk_list);
> + list_del_init(&chunk->list);
> + if (chunk->chunk_hdr->type == SCTP_CID_COOKIE_ACK)
> + list_add_head(&chunk->list, &q->control_chunk_list);
> + else if (!list_empty(&q->control_chunk_list) &&
> + chunk->chunk_hdr->type == SCTP_CID_SACK) {
> + list_for_each_entry(cptr, &q->control_chunk_list, list) {
> + if (cptr->chunk_hdr->type == SCTP_CID_COOKIE_ACK)
> + continue;
> + list_add(&chunk->list, &cptr->list);
> + break;
> + }
> + }
> +
> + if (list_empty(&chunk->list))
> + list_add_tail(&chunk->list, &q->control_chunk_list);
> SCTP_INC_STATS(SCTP_MIB_OUTCTRLCHUNKS);
> }
>
>>
>> Thanks,
>> Xufeng Zhang
>> >Regards
>> >Neil
>> >
>> >
>>
>
^ permalink raw reply
* Re: [PATCH] ppp: add 64 bit stats
From: Eric Dumazet @ 2012-07-25 4:04 UTC (permalink / raw)
To: Kevin Groeneveld; +Cc: netdev
In-Reply-To: <CABF+-6Wpn8yEvru1FDsaFbXYZ7tyeQqqbEU2VY8hLKvmXXFBXA@mail.gmail.com>
On Tue, 2012-07-24 at 22:27 -0400, Kevin Groeneveld wrote:
> After looking at the existing ppp code more I wonder if I would even
> need to add my own spinlocks. It seems the only spots I am updating
> the 64 bit stats are already protected by either ppp->wlock or
> ppp->rlock spinlocks. If I used two separate u64_stats_sync
> structures, one for tx stats and one for rx stats, wouldn't the
> existing spinlocks be enough?
It there are spinlocks already, why even adding u64_stats_sync ?
Just use existing spinlocks to protect your new u64 fields (in the
ngso_get_stats64())
^ permalink raw reply
* [PATCH V3] ipv6: fix incorrect route 'expires' value passed to userspace
From: Li Wei @ 2012-07-25 5:25 UTC (permalink / raw)
To: David Miller; +Cc: David.Laight, netdev, shemminger
In-Reply-To: <20120720.112241.2111041227435292899.davem@davemloft.net>
When userspace use RTM_GETROUTE to dump route table, with an already
expired route entry, we always got an 'expires' value(2147157)
calculated base on INT_MAX.
The reason of this problem is in the following satement:
rt->dst.expires - jiffies < INT_MAX
gcc promoted the type of both sides of '<' to unsigned long, thus
a small negative value would be considered greater than INT_MAX.
This patch fix this by use the same trick as time_after macro to
avoid the 'unsigned long' type promotion and deal with jiffies
wrapping.
Also we should do some fix in rtnl_put_cacheinfo() which use
jiffies_to_clock_t(which take an unsigned long as parameter) to
convert jiffies to clock_t to handle the negative expires.
With the help of David Laight, we can make the code a little clean.
Signed-off-by: Li Wei <lw@cn.fujitsu.com>
---
net/core/rtnetlink.c | 3 ++-
net/ipv6/route.c | 11 ++++++-----
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 334b930..2e96396 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -626,7 +626,8 @@ int rtnl_put_cacheinfo(struct sk_buff *skb, struct dst_entry *dst, u32 id,
};
if (expires)
- ci.rta_expires = jiffies_to_clock_t(expires);
+ ci.rta_expires = expires > 0 ? jiffies_to_clock_t(expires)
+ : -jiffies_to_clock_t(-expires);
return nla_put(skb, RTA_CACHEINFO, sizeof(ci), &ci);
}
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index cf02cb9..6efeb28 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2480,12 +2480,13 @@ static int rt6_fill_node(struct net *net,
goto nla_put_failure;
if (nla_put_u32(skb, RTA_PRIORITY, rt->rt6i_metric))
goto nla_put_failure;
- if (!(rt->rt6i_flags & RTF_EXPIRES))
+ if (!(rt->rt6i_flags & RTF_EXPIRES)) {
expires = 0;
- else if (rt->dst.expires - jiffies < INT_MAX)
- expires = rt->dst.expires - jiffies;
- else
- expires = INT_MAX;
+ } else {
+ expires = (long)rt->dst.expires - (long)jiffies;
+ if (expires != (int)expires)
+ expires = expires > 0 ? INT_MAX : INT_MIN;
+ }
if (rtnl_put_cacheinfo(skb, &rt->dst, 0, expires, rt->dst.error) < 0)
goto nla_put_failure;
--
1.7.10.1
^ permalink raw reply related
* iproute2 - IPsec ESN support
From: Geanta Neag Horia Ioan-B05471 @ 2012-07-25 6:14 UTC (permalink / raw)
To: netdev@vger.kernel.org, linux-crypto@vger.kernel.org
Cc: Stephen Hemminger, Steffen Klassert
Hello,
Is there any way to create an IPsec tunnel and indicate using
extended sequnce numbers?
It seems that currently iproute2 doesn't support this.
Grepping for "esn" reveals that XFRM_STATE_ESN shows only in kernel headers.
The only relevant thing I found was a RFC sent by Steffen (Cc-ed),
but it was never applied (don't know why):
[RFC] iproute2: Add IPsec extended sequence number support
http://patchwork.ozlabs.org/patch/85962/
Thank you,
Horia
^ permalink raw reply
* Re: [PATCH V3] ipv6: fix incorrect route 'expires' value passed to userspace
From: Eric Dumazet @ 2012-07-25 6:51 UTC (permalink / raw)
To: Li Wei; +Cc: David Miller, David.Laight, netdev, shemminger
In-Reply-To: <500F8356.5040008@cn.fujitsu.com>
On Wed, 2012-07-25 at 13:25 +0800, Li Wei wrote:
> When userspace use RTM_GETROUTE to dump route table, with an already
> expired route entry, we always got an 'expires' value(2147157)
> calculated base on INT_MAX.
>
> The reason of this problem is in the following satement:
> rt->dst.expires - jiffies < INT_MAX
> gcc promoted the type of both sides of '<' to unsigned long, thus
> a small negative value would be considered greater than INT_MAX.
>
> This patch fix this by use the same trick as time_after macro to
> avoid the 'unsigned long' type promotion and deal with jiffies
> wrapping.
>
> Also we should do some fix in rtnl_put_cacheinfo() which use
> jiffies_to_clock_t(which take an unsigned long as parameter) to
> convert jiffies to clock_t to handle the negative expires.
>
> With the help of David Laight, we can make the code a little clean.
>
> Signed-off-by: Li Wei <lw@cn.fujitsu.com>
> ---
> net/core/rtnetlink.c | 3 ++-
> net/ipv6/route.c | 11 ++++++-----
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 334b930..2e96396 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -626,7 +626,8 @@ int rtnl_put_cacheinfo(struct sk_buff *skb, struct dst_entry *dst, u32 id,
> };
>
> if (expires)
> - ci.rta_expires = jiffies_to_clock_t(expires);
> + ci.rta_expires = expires > 0 ? jiffies_to_clock_t(expires)
> + : -jiffies_to_clock_t(-expires);
>
> return nla_put(skb, RTA_CACHEINFO, sizeof(ci), &ci);
> }
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index cf02cb9..6efeb28 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -2480,12 +2480,13 @@ static int rt6_fill_node(struct net *net,
> goto nla_put_failure;
> if (nla_put_u32(skb, RTA_PRIORITY, rt->rt6i_metric))
> goto nla_put_failure;
> - if (!(rt->rt6i_flags & RTF_EXPIRES))
> + if (!(rt->rt6i_flags & RTF_EXPIRES)) {
> expires = 0;
> - else if (rt->dst.expires - jiffies < INT_MAX)
> - expires = rt->dst.expires - jiffies;
> - else
> - expires = INT_MAX;
> + } else {
> + expires = (long)rt->dst.expires - (long)jiffies;
> + if (expires != (int)expires)
> + expires = expires > 0 ? INT_MAX : INT_MIN;
> + }
>
> if (rtnl_put_cacheinfo(skb, &rt->dst, 0, expires, rt->dst.error) < 0)
> goto nla_put_failure;
All this sounds not very clean.
rtnl_put_cacheinfo( ... long expires ... )
Any out of bound checks should be done in rtnl_put_cacheinfo(), _after_
conversion to clock_t.
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 334b930..c1c950b 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -625,9 +625,13 @@ int rtnl_put_cacheinfo(struct sk_buff *skb, struct dst_entry *dst, u32 id,
.rta_id = id,
};
- if (expires)
- ci.rta_expires = jiffies_to_clock_t(expires);
+ if (expires) {
+ unsigned long clock;
+ clock = jiffies_to_clock_t(abs(expires));
+ clock = min_t(unsigned long, clock, INT_MAX);
+ ci.rta_expires = (expires > 0) ? clock : -clock;
+ }
return nla_put(skb, RTA_CACHEINFO, sizeof(ci), &ci);
}
EXPORT_SYMBOL_GPL(rtnl_put_cacheinfo);
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index cf02cb9..8e80fd2 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2480,12 +2480,8 @@ static int rt6_fill_node(struct net *net,
goto nla_put_failure;
if (nla_put_u32(skb, RTA_PRIORITY, rt->rt6i_metric))
goto nla_put_failure;
- if (!(rt->rt6i_flags & RTF_EXPIRES))
- expires = 0;
- else if (rt->dst.expires - jiffies < INT_MAX)
- expires = rt->dst.expires - jiffies;
- else
- expires = INT_MAX;
+
+ expires = (rt->rt6i_flags & RTF_EXPIRES) ? rt->dst.expires - jiffies : 0;
if (rtnl_put_cacheinfo(skb, &rt->dst, 0, expires, rt->dst.error) < 0)
goto nla_put_failure;
^ permalink raw reply related
* Share network traffic between process with respect to a priority number.
From: Sameer Rahmani @ 2012-07-25 6:51 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi guys
for years i have problems with sharing my network bandwidth between my
processes. when one of my running processes (e.g axel) start to download
data my other processes that needs bandwidth stop working (because they
can't download their data) . i know that there is some tools like lartc
but i was thinking about a priority value like NICE for this matter.
kernel will share the bandwidth between process with respect to their
network priority number let's call it NNICE ( or what ever ) . The
process with highest NNICE will use the highest bandwidth.
It's just an raw idea, i want to know your idea about the basic , and
improve it.
What do you think?
With respect
Sameer Rahmani
^ permalink raw reply
* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: Vlad Yasevich @ 2012-07-25 7:16 UTC (permalink / raw)
To: Xufeng Zhang; +Cc: xufeng zhang, sri, davem, linux-sctp, netdev, linux-kernel
In-Reply-To: <CA+=dFzg=Bpsv5bMzECoAXYVcbD95eYy6xDAzL6fwiHrunfq-tg@mail.gmail.com>
Xufeng Zhang <xufengzhang.main@gmail.com> wrote:
>On 7/24/12, Vlad Yasevich <vyasevich@gmail.com> wrote:
>>>>> And I should clarify the above judgment code.
>>>>> AFAIK, there should be two cases for the bundling when invalid
>>>stream
>>>>> identifier error happens:
>>>>> 1). COOKIE_ACK ERROR SACK
>>>>> 2). ERROR SACK
>>>>> So I need to deal with the two cases differently.
>>>>>
>>>>>
>>>> Sorry but I just don't buy that the above are the only 2 cases.
>What
>>>if there are addip chunks as well? What if there are some other
>>>extensions also. This code has to be generic enough to handle any
>>>condition.
>>>>
>>>Aha, you are right, this may happens.
>>>So I think the general solution is to fix this problem in the enqueue
>>>side.
>>>What do you think? any better suggestion!
>>>
>>
>> Don't have code in front of me but what if we carry the error
>condition to
>> where we queue the Sack and add the error side effect then?
>Yes, this is the most direct way to fix this problem.
>But I don't think it's the best way since we will take care of a lot
>of things and
>it also involves in lots of changes to side effect processing.
>I prefer to Neil Horman's way for the solution since only COOKIE_ACK
>chunk is
>allowed to place ahead of SACK chunk when bundling into one packet.
>What do you think?
>
>
Actually not true. AUTH can be before SACK. So can any addip chunks that aid in locating an association.
Now AUTH isn't a big issue since its autogenerated to the packet but ADDIP is since it could be queued up for retransmission.
There could be other extensions as well. It really needs to be done either through side effects or making error chunks go at the end of other control chunks. Need to audit the spec to see if that's ok.
-vlad
>
>Thanks,
>Xufeng Zhang
>>
>> -vlad
--
Sent from my Android phone with SkitMail. Please excuse my brevity.
^ permalink raw reply
* Re: [PATCH V3] ipv6: fix incorrect route 'expires' value passed to userspace
From: Li Wei @ 2012-07-25 7:33 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, David.Laight, netdev, shemminger
In-Reply-To: <1343199114.2626.11088.camel@edumazet-glaptop>
On 07/25/2012 02:51 PM, Eric Dumazet wrote:
> On Wed, 2012-07-25 at 13:25 +0800, Li Wei wrote:
>> When userspace use RTM_GETROUTE to dump route table, with an already
>> expired route entry, we always got an 'expires' value(2147157)
>> calculated base on INT_MAX.
>>
>> The reason of this problem is in the following satement:
>> rt->dst.expires - jiffies < INT_MAX
>> gcc promoted the type of both sides of '<' to unsigned long, thus
>> a small negative value would be considered greater than INT_MAX.
>>
>> This patch fix this by use the same trick as time_after macro to
>> avoid the 'unsigned long' type promotion and deal with jiffies
>> wrapping.
>>
>> Also we should do some fix in rtnl_put_cacheinfo() which use
>> jiffies_to_clock_t(which take an unsigned long as parameter) to
>> convert jiffies to clock_t to handle the negative expires.
>>
>> With the help of David Laight, we can make the code a little clean.
>>
>> Signed-off-by: Li Wei <lw@cn.fujitsu.com>
>> ---
>> net/core/rtnetlink.c | 3 ++-
>> net/ipv6/route.c | 11 ++++++-----
>> 2 files changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>> index 334b930..2e96396 100644
>> --- a/net/core/rtnetlink.c
>> +++ b/net/core/rtnetlink.c
>> @@ -626,7 +626,8 @@ int rtnl_put_cacheinfo(struct sk_buff *skb, struct dst_entry *dst, u32 id,
>> };
>>
>> if (expires)
>> - ci.rta_expires = jiffies_to_clock_t(expires);
>> + ci.rta_expires = expires > 0 ? jiffies_to_clock_t(expires)
>> + : -jiffies_to_clock_t(-expires);
>>
>> return nla_put(skb, RTA_CACHEINFO, sizeof(ci), &ci);
>> }
>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>> index cf02cb9..6efeb28 100644
>> --- a/net/ipv6/route.c
>> +++ b/net/ipv6/route.c
>> @@ -2480,12 +2480,13 @@ static int rt6_fill_node(struct net *net,
>> goto nla_put_failure;
>> if (nla_put_u32(skb, RTA_PRIORITY, rt->rt6i_metric))
>> goto nla_put_failure;
>> - if (!(rt->rt6i_flags & RTF_EXPIRES))
>> + if (!(rt->rt6i_flags & RTF_EXPIRES)) {
>> expires = 0;
>> - else if (rt->dst.expires - jiffies < INT_MAX)
>> - expires = rt->dst.expires - jiffies;
>> - else
>> - expires = INT_MAX;
>> + } else {
>> + expires = (long)rt->dst.expires - (long)jiffies;
>> + if (expires != (int)expires)
>> + expires = expires > 0 ? INT_MAX : INT_MIN;
>> + }
>>
>> if (rtnl_put_cacheinfo(skb, &rt->dst, 0, expires, rt->dst.error) < 0)
>> goto nla_put_failure;
>
> All this sounds not very clean.
>
> rtnl_put_cacheinfo( ... long expires ... )
>
> Any out of bound checks should be done in rtnl_put_cacheinfo(), _after_
> conversion to clock_t.
Ok, I got it.
I tested the following patch, got the correct expires value and not found
any problem.
Thanks Eric :)
>
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 334b930..c1c950b 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -625,9 +625,13 @@ int rtnl_put_cacheinfo(struct sk_buff *skb, struct dst_entry *dst, u32 id,
> .rta_id = id,
> };
>
> - if (expires)
> - ci.rta_expires = jiffies_to_clock_t(expires);
> + if (expires) {
> + unsigned long clock;
>
> + clock = jiffies_to_clock_t(abs(expires));
> + clock = min_t(unsigned long, clock, INT_MAX);
> + ci.rta_expires = (expires > 0) ? clock : -clock;
> + }
> return nla_put(skb, RTA_CACHEINFO, sizeof(ci), &ci);
> }
> EXPORT_SYMBOL_GPL(rtnl_put_cacheinfo);
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index cf02cb9..8e80fd2 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -2480,12 +2480,8 @@ static int rt6_fill_node(struct net *net,
> goto nla_put_failure;
> if (nla_put_u32(skb, RTA_PRIORITY, rt->rt6i_metric))
> goto nla_put_failure;
> - if (!(rt->rt6i_flags & RTF_EXPIRES))
> - expires = 0;
> - else if (rt->dst.expires - jiffies < INT_MAX)
> - expires = rt->dst.expires - jiffies;
> - else
> - expires = INT_MAX;
> +
> + expires = (rt->rt6i_flags & RTF_EXPIRES) ? rt->dst.expires - jiffies : 0;
>
> if (rtnl_put_cacheinfo(skb, &rt->dst, 0, expires, rt->dst.error) < 0)
> goto nla_put_failure;
>
>
>
>
^ permalink raw reply
* Re: [PATCH RESEND net-next V2] IB/ipoib: break linkage to neighbouring system
From: Roland Dreier @ 2012-07-25 7:52 UTC (permalink / raw)
To: David Miller; +Cc: ogerlitz, netdev, eric.dumazet, cl, shlomop
In-Reply-To: <20120724.140015.1545062339709165330.davem@davemloft.net>
On Tue, Jul 24, 2012 at 2:00 PM, David Miller <davem@davemloft.net> wrote:
> Looks good, Roland you got this?
Yes, I'll read it over and pick it up, thanks.
^ permalink raw reply
* Re: Share network traffic between process with respect to a priority number.
From: Eric Dumazet @ 2012-07-25 7:54 UTC (permalink / raw)
To: Sameer Rahmani; +Cc: netdev@vger.kernel.org
In-Reply-To: <500F9762.1090702@lxsameer.com>
On Wed, 2012-07-25 at 11:21 +0430, Sameer Rahmani wrote:
> Hi guys
>
> for years i have problems with sharing my network bandwidth between my
> processes. when one of my running processes (e.g axel) start to download
> data my other processes that needs bandwidth stop working (because they
> can't download their data) . i know that there is some tools like lartc
> but i was thinking about a priority value like NICE for this matter.
> kernel will share the bandwidth between process with respect to their
> network priority number let's call it NNICE ( or what ever ) . The
> process with highest NNICE will use the highest bandwidth.
>
> It's just an raw idea, i want to know your idea about the basic , and
> improve it.
> What do you think?
I think that's its hard to limit incoming data, on a general case.
Once frame is received, its too late, it already used the link
bandwidth.
A solution is to install a shaper on ingress, so that incoming tcp
frames might be delayed a bit _before_ incoming tcp stack, if they come
on a busy flow/link.
Using fq_codel sounds the right way : delay should be minimal for
interactive flows, and bigger for elephant flows.
It really should help you.
Check your kernel config has :
CONFIG_IFB=m
CONFIG_NET_SCH_INGRESS=y
CONFIG_NET_SCH_FQ_CODEL=m (or y)
CONFIG_NET_SCH_CBQ=m (or y)
Then adapt/use following script (can use HTB instead of CBQ of course)
ETH=eth0
IFB=ifb0
LOCALNETS="172.16.0.0/12 192.168.0.0/16 10.0.0.0/8"
RATE="rate 4Mbit bandwidth 4Mbit maxburst 80 minburst 40"
ALLOT="allot 8000"
modprobe ifb
ip link set dev $IFB up
tc qdisc add dev $ETH ingress 2>/dev/null
tc filter add dev $ETH parent ffff: \
protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress \
redirect dev $IFB
tc qdisc del dev $IFB root
# Lets say our NIC is 100Mbit
tc qdisc add dev $IFB root handle 1: cbq avpkt 1000 \
rate 100Mbit bandwidth 100Mbit
tc class add dev $IFB parent 1: classid 1:1 cbq allot 10000 \
mpu 64 rate 100Mbit prio 1 \
bandwidth 100Mbit maxburst 150 avpkt 1500 bounded
# Class for traffic coming from Internet : limited to X Mbits
tc class add dev $IFB parent 1:1 classid 1:11 \
cbq $ALLOT mpu 64 \
$RATE prio 2 \
avpkt 1400 bounded
tc qdisc add dev $IFB parent 1:11 handle 11: fq_codel
# Traffic from machines in our LAN : no limit
for privnet in $LOCALNETS
do
tc filter add dev $IFB parent 1: protocol ip prio 2 u32 \
match ip src $privnet flowid 1:1
done
tc filter add dev $IFB parent 1: protocol ip prio 2 u32 \
match ip protocol 0 0x00 flowid 1:11
^ permalink raw reply
* Re: [PATCH 03/17] Drivers: hv: kvp: Cleanup error handling in KVP
From: Olaf Hering @ 2012-07-25 7:59 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: gregkh, linux-kernel, devel, virtualization, apw, netdev, ben
In-Reply-To: <1343145701-3691-3-git-send-email-kys@microsoft.com>
On Tue, Jul 24, K. Y. Srinivasan wrote:
> +++ b/drivers/hv/hv_kvp.c
> @@ -48,13 +48,24 @@ static struct {
> void *kvp_context; /* for the channel callback */
> } kvp_transaction;
>
> +/*
> + * Before we can accept KVP messages from the host, we need
> + * to handshake with the user level daemon. This state tarcks
tracks
> + * if we are in the handshake phase.
> + */
> - * Something failed or the we have timedout;
> + * Something failed or we have timedout;
extra space
^ permalink raw reply
* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: Xufeng Zhang @ 2012-07-25 8:05 UTC (permalink / raw)
To: Vlad Yasevich, Neil Horman
Cc: xufeng zhang, sri, davem, linux-sctp, netdev, linux-kernel
In-Reply-To: <e7f8a685-9635-4aa9-bd67-1044e0720b29@email.android.com>
On 7/25/12, Vlad Yasevich <vyasevich@gmail.com> wrote:
>
> Actually not true. AUTH can be before SACK. So can any addip chunks that
> aid in locating an association.
>
> Now AUTH isn't a big issue since its autogenerated to the packet but ADDIP
> is since it could be queued up for retransmission.
>
> There could be other extensions as well. It really needs to be done either
> through side effects or making error chunks go at the end of other control
> chunks. Need to audit the spec to see if that's ok.
You are right, I just found SHUTDOWN chunks are also before SACK based on
your commit "[SCTP]: Fix SACK sequence during shutdown".
Maybe the only solution is to do some work on side effects just as you said.
Thanks for your explanation!
Thanks,
Xufeng Zhang
>
> -vlad
>>
>>Thanks,
>>Xufeng Zhang
>>>
>>> -vlad
>
>
> --
> Sent from my Android phone with SkitMail. Please excuse my brevity.
>
^ permalink raw reply
* [patch 3/3] [PATCH] qeth: repair crash in qeth_l3_vlan_rx_kill_vid()
From: frank.blaschka @ 2012-07-25 8:34 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, stable, Ursula Braun
In-Reply-To: <20120725083426.704834478@de.ibm.com>
[-- Attachment #1: 602-qeth-vlan-rx-kill.diff --]
[-- Type: text/plain, Size: 1358 bytes --]
Commit efc73f4b "net: Fix memory leak - vlan_info struct" adds deletion of
VLAN 0 for devices with feature NETIF_F_HW_VLAN_FILTER. For driver
qeth these are the layer 3 devices. Usually there exists no
separate vlan net_device for VLAN 0. Thus the qeth functions
qeth_l3_free_vlan_addresses4() and qeth_l3_free_vlan_addresses6()
require an extra checking if function __vlan_find_dev_deep()
returns with a net_device.
Cc: stable@vger.kernel.org
Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com>
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
---
drivers/s390/net/qeth_l3_main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/s390/net/qeth_l3_main.c b/drivers/s390/net/qeth_l3_main.c
index f0045ca..d01a617 100644
--- a/drivers/s390/net/qeth_l3_main.c
+++ b/drivers/s390/net/qeth_l3_main.c
@@ -1758,6 +1758,8 @@ static void qeth_l3_free_vlan_addresses4(struct qeth_card *card,
QETH_CARD_TEXT(card, 4, "frvaddr4");
netdev = __vlan_find_dev_deep(card->dev, vid);
+ if (!netdev)
+ return;
in_dev = in_dev_get(netdev);
if (!in_dev)
return;
@@ -1786,6 +1788,8 @@ static void qeth_l3_free_vlan_addresses6(struct qeth_card *card,
QETH_CARD_TEXT(card, 4, "frvaddr6");
netdev = __vlan_find_dev_deep(card->dev, vid);
+ if (!netdev)
+ return;
in6_dev = in6_dev_get(netdev);
if (!in6_dev)
return;
--
1.7.11.3
^ permalink raw reply related
* [patch 2/3] [PATCH] netiucv: cleanup attribute usage
From: frank.blaschka @ 2012-07-25 8:34 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, Sebastian Ott, Ursula Braun
In-Reply-To: <20120725083426.704834478@de.ibm.com>
[-- Attachment #1: 601-netiucv-attr-usage.diff --]
[-- Type: text/plain, Size: 2312 bytes --]
Let the driver core handle device attribute creation and removal. This
will simplify the code and eliminates races between attribute
availability and userspace notification via uevents.
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
Acked-by: Ursula Braun <ursula.braun@de.ibm.com>
---
drivers/s390/net/netiucv.c | 34 ++++++----------------------------
1 file changed, 6 insertions(+), 28 deletions(-)
diff --git a/drivers/s390/net/netiucv.c b/drivers/s390/net/netiucv.c
index 8160591..4ffa66c 100644
--- a/drivers/s390/net/netiucv.c
+++ b/drivers/s390/net/netiucv.c
@@ -1854,26 +1854,11 @@ static struct attribute_group netiucv_stat_attr_group = {
.attrs = netiucv_stat_attrs,
};
-static int netiucv_add_files(struct device *dev)
-{
- int ret;
-
- IUCV_DBF_TEXT(trace, 3, __func__);
- ret = sysfs_create_group(&dev->kobj, &netiucv_attr_group);
- if (ret)
- return ret;
- ret = sysfs_create_group(&dev->kobj, &netiucv_stat_attr_group);
- if (ret)
- sysfs_remove_group(&dev->kobj, &netiucv_attr_group);
- return ret;
-}
-
-static void netiucv_remove_files(struct device *dev)
-{
- IUCV_DBF_TEXT(trace, 3, __func__);
- sysfs_remove_group(&dev->kobj, &netiucv_stat_attr_group);
- sysfs_remove_group(&dev->kobj, &netiucv_attr_group);
-}
+static const struct attribute_group *netiucv_attr_groups[] = {
+ &netiucv_stat_attr_group,
+ &netiucv_attr_group,
+ NULL,
+};
static int netiucv_register_device(struct net_device *ndev)
{
@@ -1887,6 +1872,7 @@ static int netiucv_register_device(struct net_device *ndev)
dev_set_name(dev, "net%s", ndev->name);
dev->bus = &iucv_bus;
dev->parent = iucv_root;
+ dev->groups = netiucv_attr_groups;
/*
* The release function could be called after the
* module has been unloaded. It's _only_ task is to
@@ -1904,22 +1890,14 @@ static int netiucv_register_device(struct net_device *ndev)
put_device(dev);
return ret;
}
- ret = netiucv_add_files(dev);
- if (ret)
- goto out_unreg;
priv->dev = dev;
dev_set_drvdata(dev, priv);
return 0;
-
-out_unreg:
- device_unregister(dev);
- return ret;
}
static void netiucv_unregister_device(struct device *dev)
{
IUCV_DBF_TEXT(trace, 3, __func__);
- netiucv_remove_files(dev);
device_unregister(dev);
}
--
1.7.11.3
^ permalink raw reply related
* [patch 1/3] [PATCH] net: wiznet add missing HAS_IOMEM dependency
From: frank.blaschka @ 2012-07-25 8:34 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, Martin Schwidefsky
In-Reply-To: <20120725083426.704834478@de.ibm.com>
[-- Attachment #1: 600-wiznet-kconfig.diff --]
[-- Type: text/plain, Size: 705 bytes --]
The "WIZnet devices" config option should depend on HAS_IOMEM as
all wiznet drivers require it as well.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
---
drivers/net/ethernet/wiznet/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/wiznet/Kconfig b/drivers/net/ethernet/wiznet/Kconfig
index cb18043..b4d2816 100644
--- a/drivers/net/ethernet/wiznet/Kconfig
+++ b/drivers/net/ethernet/wiznet/Kconfig
@@ -4,6 +4,7 @@
config NET_VENDOR_WIZNET
bool "WIZnet devices"
+ depends on HAS_IOMEM
default y
---help---
If you have a network (Ethernet) card belonging to this class, say Y
--
1.7.11.3
^ permalink raw reply related
* [patch 0/3] s390: bug fixes for net
From: frank.blaschka @ 2012-07-25 8:34 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390
Hi Dave,
here are some bug fixes for net.
shortlog:
Martin Schwidefsky (1)
net: wiznet add missing HAS_IOMEM dependency
Sebastian Ott (1)
netiucv: cleanup attribute usage
Ursula Braun (1)
qeth: repair crash in qeth_l3_vlan_rx_kill_vid()
Thanks,
Frank
^ permalink raw reply
* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: Xufeng Zhang @ 2012-07-25 9:22 UTC (permalink / raw)
To: Vlad Yasevich, Neil Horman
Cc: xufeng zhang, sri, davem, linux-sctp, netdev, linux-kernel
In-Reply-To: <CA+=dFzifKwbiXmw=pu0+rWmz72+4jsbv6bXOBHyL0LmxaL9byg@mail.gmail.com>
On 7/25/12, Xufeng Zhang <xufengzhang.main@gmail.com> wrote:
> On 7/25/12, Vlad Yasevich <vyasevich@gmail.com> wrote:
>>
>> Actually not true. AUTH can be before SACK. So can any addip chunks
>> that
>> aid in locating an association.
>>
>> Now AUTH isn't a big issue since its autogenerated to the packet but
>> ADDIP
>> is since it could be queued up for retransmission.
>>
>> There could be other extensions as well. It really needs to be done
>> either
>> through side effects or making error chunks go at the end of other
>> control
>> chunks. Need to audit the spec to see if that's ok.
> You are right, I just found SHUTDOWN chunks are also before SACK based on
> your commit "[SCTP]: Fix SACK sequence during shutdown".
> Maybe the only solution is to do some work on side effects just as you
> said.
> Thanks for your explanation!
And after take a moment to look into the relative codes, I think we
can implement it
by below way:
1). Add a flag(isi_err_needed) in the embedded struct peer of struct
struct sctp_association
just like sack_needed flag.
2). When "invalid stream identifier" ERROR happens in sctp_eat_data()
function, we just
set isi_err_needed flag and don't create ERROR chunk and also don't
insert SCTP_CMD_REPLY command.
3). In sctp_gen_sack() function, we create ERROR chunk and also insert
SCTP_CMD_REPLY command if isi_err_needed flag is set.
Is this way proper?
Thanks,
Xufeng Zhang
>
>
>
> Thanks,
> Xufeng Zhang
>>
>> -vlad
>>>
>>>Thanks,
>>>Xufeng Zhang
>>>>
>>>> -vlad
>>
>>
>> --
>> Sent from my Android phone with SkitMail. Please excuse my brevity.
>>
>
^ permalink raw reply
* Re: iproute2 - IPsec ESN support
From: Steffen Klassert @ 2012-07-25 9:51 UTC (permalink / raw)
To: Geanta Neag Horia Ioan-B05471
Cc: netdev@vger.kernel.org, linux-crypto@vger.kernel.org,
Stephen Hemminger
In-Reply-To: <FD18E5D573A8AB48A365D4D78185DE992602BD@039-SN1MPN1-001.039d.mgd.msft.net>
On Wed, Jul 25, 2012 at 06:14:52AM +0000, Geanta Neag Horia Ioan-B05471 wrote:
> Hello,
>
> Is there any way to create an IPsec tunnel and indicate using
> extended sequnce numbers?
The strongswan ike deamon supports extended sequnce numbers.
>
> It seems that currently iproute2 doesn't support this.
> Grepping for "esn" reveals that XFRM_STATE_ESN shows only in kernel headers.
>
> The only relevant thing I found was a RFC sent by Steffen (Cc-ed),
> but it was never applied (don't know why):
> [RFC] iproute2: Add IPsec extended sequence number support
I'll take this as a reminder to respin this patch.
^ 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