* [PATCH 2/2] bridge: add flags to distinguish permanent mdb entires
From: Cong Wang @ 2012-12-15 8:09 UTC (permalink / raw)
To: netdev; +Cc: bridge, Cong Wang, Herbert Xu, Stephen Hemminger, David S. Miller
In-Reply-To: <1355558992-32285-1-git-send-email-amwang@redhat.com>
This patch adds a flag to each mdb entry, so that we can distinguish
permanent entries with temporary entries.
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
include/uapi/linux/if_bridge.h | 3 +++
net/bridge/br_mdb.c | 9 ++++++---
net/bridge/br_multicast.c | 8 +++++---
net/bridge/br_private.h | 4 +++-
4 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
index afbb18a..5db2975 100644
--- a/include/uapi/linux/if_bridge.h
+++ b/include/uapi/linux/if_bridge.h
@@ -163,6 +163,9 @@ struct br_port_msg {
struct br_mdb_entry {
__u32 ifindex;
+#define MDB_TEMPORARY 0
+#define MDB_PERMANENT 1
+ __u8 state;
struct {
union {
__be32 ip4;
diff --git a/net/bridge/br_mdb.c b/net/bridge/br_mdb.c
index 6f0a2ee..9cf5d2b 100644
--- a/net/bridge/br_mdb.c
+++ b/net/bridge/br_mdb.c
@@ -83,6 +83,7 @@ static int br_mdb_fill_info(struct sk_buff *skb, struct netlink_callback *cb,
if (port) {
struct br_mdb_entry e;
e.ifindex = port->dev->ifindex;
+ e.state = p->state;
e.addr.u.ip4 = p->addr.u.ip4;
#if IS_ENABLED(CONFIG_IPV6)
e.addr.u.ip6 = p->addr.u.ip6;
@@ -253,6 +254,8 @@ static bool is_valid_mdb_entry(struct br_mdb_entry *entry)
#endif
} else
return false;
+ if (entry->state != MDB_PERMANENT && entry->state != MDB_TEMPORARY)
+ return false;
return true;
}
@@ -310,7 +313,7 @@ static int br_mdb_parse(struct sk_buff *skb, struct nlmsghdr *nlh,
}
static int br_mdb_add_group(struct net_bridge *br, struct net_bridge_port *port,
- struct br_ip *group)
+ struct br_ip *group, unsigned char state)
{
struct net_bridge_mdb_entry *mp;
struct net_bridge_port_group *p;
@@ -336,7 +339,7 @@ static int br_mdb_add_group(struct net_bridge *br, struct net_bridge_port *port,
break;
}
- p = br_multicast_new_port_group(port, group, *pp);
+ p = br_multicast_new_port_group(port, group, *pp, state);
if (unlikely(!p))
return -ENOMEM;
rcu_assign_pointer(*pp, p);
@@ -373,7 +376,7 @@ static int __br_mdb_add(struct net *net, struct net_bridge *br,
#endif
spin_lock_bh(&br->multicast_lock);
- ret = br_mdb_add_group(br, p, &ip);
+ ret = br_mdb_add_group(br, p, &ip, entry->state);
spin_unlock_bh(&br->multicast_lock);
return ret;
}
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 2561af9..dce9def 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -279,7 +279,7 @@ static void br_multicast_port_group_expired(unsigned long data)
spin_lock(&br->multicast_lock);
if (!netif_running(br->dev) || timer_pending(&pg->timer) ||
- hlist_unhashed(&pg->mglist))
+ hlist_unhashed(&pg->mglist) || pg->state & MDB_PERMANENT)
goto out;
br_multicast_del_pg(br, pg);
@@ -622,7 +622,8 @@ out:
struct net_bridge_port_group *br_multicast_new_port_group(
struct net_bridge_port *port,
struct br_ip *group,
- struct net_bridge_port_group __rcu *next)
+ struct net_bridge_port_group __rcu *next,
+ unsigned char state)
{
struct net_bridge_port_group *p;
@@ -632,6 +633,7 @@ struct net_bridge_port_group *br_multicast_new_port_group(
p->addr = *group;
p->port = port;
+ p->state = state;
rcu_assign_pointer(p->next, next);
hlist_add_head(&p->mglist, &port->mglist);
setup_timer(&p->timer, br_multicast_port_group_expired,
@@ -674,7 +676,7 @@ static int br_multicast_add_group(struct net_bridge *br,
break;
}
- p = br_multicast_new_port_group(port, group, *pp);
+ p = br_multicast_new_port_group(port, group, *pp, MDB_TEMPORARY);
if (unlikely(!p))
goto err;
rcu_assign_pointer(*pp, p);
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index f21a739..49b85af4 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -83,6 +83,7 @@ struct net_bridge_port_group {
struct rcu_head rcu;
struct timer_list timer;
struct br_ip addr;
+ unsigned char state;
};
struct net_bridge_mdb_entry
@@ -443,7 +444,8 @@ extern void br_multicast_free_pg(struct rcu_head *head);
extern struct net_bridge_port_group *br_multicast_new_port_group(
struct net_bridge_port *port,
struct br_ip *group,
- struct net_bridge_port_group *next);
+ struct net_bridge_port_group *next,
+ unsigned char state);
extern void br_mdb_init(void);
extern void br_mdb_notify(struct net_device *dev, struct net_bridge_port *port,
struct br_ip *group, int type);
--
1.7.7.6
^ permalink raw reply related
* Re: Launch Time Support
From: Ulf samuelsson @ 2012-12-15 7:35 UTC (permalink / raw)
To: Vick, Matthew; +Cc: netdev@vger.kernel.org
In-Reply-To: <06DFBC1E25D8024DB214DC7F41A3CD3448973B79@ORSMSX101.amr.corp.intel.com>
15 dec 2012 kl. 01:45 skrev "Vick, Matthew" <matthew.vick@intel.com>:
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>> owner@vger.kernel.org] On Behalf Of Ulf Samuelsson
>> Sent: Wednesday, December 12, 2012 5:04 PM
>> To: netdev@vger.kernel.org
>> Subject: RFC: Launch Time Support
>>
>> Hi, I am looking for some feedback on how to implement launchtime in
>> the kernel.
>>
>> I.E: You define WHEN you want to send a packet, and the driver will
>> store the packet in a buffer and will send it out on the net when the
>> internal timestamp counter in the network controller reaches the
>> specified "launch time".
>>
>> Some Ethernet controllers like the new Intel i210 support "launch
>> time",
>>
>> Support for launch time is desirable for any isochronous connection,
>> but I am currently interested in the NTP protocol to improve the
>> timing.
>>
>> Proposed Changes to the Kernel
>> ===========================================================
>> The launchtime support will be dependent on CONFIG_NET_LAUNCHTIME If
>> this is not set, then the kernel functionality is not changed.
>>
>> My current idea is to add a new bit to the "flags" field of
>> "socket.c:sendto"
>> #define MSG_LAUNCHTIME 0x?????
>>
>> struct msghdr gets an additional launchtime field.
>>
>> sendto will check if the flags parameter contains MSG_LAUNCHTIME.
>> If it does, then the first 64 bit longword of the packet (buff)
>> contains the launchtime.
>> The launchtime from the buffer is copied to the msghdr.launchtime
>> field, and the first 64 bits of the packet is then shaved off, before
>> the address is written to the msghdr.
>>
>> Each network controller supporting launchtime needs to have an
>> alternative call to "send packet with launchtime" . This call adds the
>> launchtime parameter.
>> If launchtime is supported the exported "ops" includes the new call.
>>
>> The UDP/IP packet send will check the MSG_LAUNCHTIME and if set, it
>> will check if the "send packet with launchtime" call is available for
>> the driver and if so call it, otherwise it will call the normal send
>> packet and thus ignore the launchtime.
>>
>> Before launchtime is used, the application should send an ioctl to the
>> driver, making sure that launchtime is configured, and only if the
>> driver ACKs , the application will use launchtime.
>>
>> (Possibly the "ops" field for "send packet with launchtime" should be
>> NULL until that ioctl is complete. Comments?)
>>
>> To me, this seems to be transparent for all other network stacks so
>> protocols and drivers not supporting launchtime should still work.
>>
>> As far as I know, drivers do not support launch time today.
>> The Intel igb driver does not in the latest version on the intel web
>> site, There are some defines headers in the latest version defining
>> the registers but so far, the code is not using it.
>>
>> There is the linux_igb_avb project on sourceforge which allows use of
>> launch time for user space applications, but not as part of the kernel.
>>
>> Maybe there is more work done somewhere else, but i am not aware of
>> this, so any links to such work is appreciated.
>>
>> There are some FPGA based PCIe boards that support launchtime (Endace
>> DAG) using proprietary APIs.
>> Talked to some vendors providing TCP/IP offload engines for FPGA and
>> they do not support launchtime and liuke Endace use proprietary APIs so
>> they are only useable by custom programs. Normal networking interfaces
>> are not supported.
>>
>> Comment on above is appreciated.
>>
>> BACKGROUND
>> For those that do not know how the NTP protocol works:
>> ===================================================
>> The client sends an UDP packet to the NTP server using port 123 The NTP
>> client reads the current systime and puts that in the outgoing packet.
>> There is a delay between the time the systime is read, and the time the
>> packet actually leaves the Ethernet controller adding jitter to the NTP
>> algorithm.
>>
>> When the server receives the packet, it can be timestamped in H/W and a
>> CMSG is then created by the network stack containing that timestamp for
>> use by the server NTP daemon.
>>
>> The server generates a reply, which needs to include the client
>> transmit time, the servers receive time, and the servers transmit time.
>> Again, the transmit time needs to be written into the NTP packet, and
>> then it needs to be processed through the network stack before it is
>> leaving the ethernet controller causing more jitter.
>>
>> If launch time is supported, then the client NTP daemon would simply
>> read the systime, add a constant delay to create the transmit
>> timestamp.
>> The delay needs to be sufficiently large to ensure that all processing
>> is done,
>>
>> The server will do something similar adding a constant to the server
>> receive timestamp to create the server transmit timestamp.
>> If both the client and the server uses H/W timestamping and launch
>> time, then the the jitter ideally is reduced to zero.
>>
>> TRANSMIT TIMESTAMPING
>> ========================
>> Support for TX timestamps in H/W is not really useful, since you need
>> to provide the TX timestamp in the packet you measure on, so when you
>> know the timestamp it is too late. Server to server NTP connections
>> support sending that timestamp in a new packet, but there is no such
>> support in client server communication.
>>
>> The i210 supports putting the timestamp inside the packet as it leaves
>> the Ethernet controller, but that means that you screw up the UDP
>> checksum, so the packet will be rejected by the receiving NTP daemon.
>> In addition, the i210 timestamp measures seconds and nanoseconds which
>> is incompatible with the NTP timestamp which uses seconds and a 32 bit
>> fraction of a second so that does not work either.
>>
>> Best Regards
>> Ulf Samuelsson
>> eMagii.
>
> Ulf,
>
> I have been looking into adding launch time support as part of enabling some of the I210 functionality you have described (such as in linux_igb_avb on SourceForge) upstream--less focused on NTP and more focused on AVB, but launch time will be necessary for both. If you would like, please feel free to contact me and I would love to work with you on this.
>
> Reading your proposal, I'm a little confused by which systime you're referring to. Do you mean on the host or on the NIC? In the case of hardware timestamping today, in igb we set the SYSTIM registers to the current system time, but that doesn't mean that the host clock and the NIC clock stay synced. You would either need a mechanism such as PPS (which igb does not implement today) to sync the host clock to the NIC clock or have the NTP daemon account for the discrepancy. Off the top of my head, I want to say modern PTP daemons (such as ptp4l) account for the discrepancy in the daemon.
>
> Cheers,
> Matthew
We live in luxury, having access to a Cesium Clock ;-) and we define the time, beeing
a top-level (Stratum 1) server.
There are some I/Os on the i210 that can be used to interface to the PPS.
As for reading systime, it is done indirectly as you get the systime
as part of the NTP incoming packet. (It is timestamped at reception)
and add the constant to that value.
Best Regards
Ulf Samuelsson
>
> Matthew Vick
> Linux Development
> LAN Access Division
> Intel Corporation
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Dealing nicely with PM failure
From: Dave Wiltshire @ 2012-12-15 14:14 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Ming Lei, Steve Glendinning, netdev
In-Reply-To: <3581886.3cmiB2PA1J@linux-lqwf.site>
On Fri, Dec 14, 2012 at 03:56:26PM +0100, Oliver Neukum wrote:
> @@ -793,15 +794,15 @@ int usbnet_open (struct net_device *net)
> // delay posting reads until we're fully open
> tasklet_schedule (&dev->bh);
> if (info->manage_power) {
> - retval = info->manage_power(dev, 1);
> - if (retval < 0)
> - goto done_manage_power_error;
> - usb_autopm_put_interface(dev->intf);
> + int r;
> +
> + r = info->manage_power(dev, 1);
> + if (r < 0)
> + set_bit(EVENT_NO_RUNTIME_PM, &dev->flags);
> + else
> + usb_autopm_put_interface(dev->intf);
> }
> return retval;
Did you mean to change the return value in the successful case? This
used to return 0 on a successful call to info->manage_power(dev, 1).
This patch changes that - perhaps it's still the same (if retval is set
above).
Dave
^ permalink raw reply
* Re: netconsole fun
From: Peter Hurley @ 2012-12-15 14:13 UTC (permalink / raw)
To: Neil Horman; +Cc: Cong Wang, netdev
In-Reply-To: <20121214142018.GA24846@shamino.rdu.redhat.com>
On Fri, 2012-12-14 at 09:20 -0500, Neil Horman wrote:
> Ah! I'm sorry, I didn't realize this was really about getting netconsole up
> early in the boot, rather than just getting it up robustly using the startup
> script.
Well, it's both but I should have been clearer here. Sorry about that.
> If thats the case, then I would recommend that you modify the initramfs
> to do something simmilar to the startup script (since thats where the netconsole
> module will get loaded anyway). You can write a script there that will let you
> specify the destination ip address and figure out the output dev based on the
> routing tables. If you're using dracut to build your initramfs, then this
> should be pretty straightforward.
When I get some more free time I'll experiment with this approach.
Just to clarify something from earlier in the discussion:
On Thu, 2012-12-13 at 13:08 -0500, Neil Horman wrote:
> On Thu, Dec 13, 2012 at 09:49:31AM -0500, Peter Hurley wrote:
....
> > There is an unforeseen consequence of the patch: it breaks device
> > renaming because the device will already be in use by netconsole. Which
> > is the whole problem with userspace device renaming to begin with...
> >
> That is bad, but see above, the netconsole service can work around this for you,
> allowing you to never have to specify a particular device at all.
The breakage is a normal consequence of being able to load netconsole
before the udev rules that do device renaming. The same thing would
happen modifying initramfs.
Basically, once netconsole attaches to a device, that device cannot be
renamed. Unfortunately, the default udev behavior messes things up
further because it will try to do this:
eth0->eth1
eth1->eth0
which means neither device will be renamed.
Maybe the net core should just implement persistent device names ;)
Thanks again for all your time,
Peter Hurley
^ permalink raw reply
* Re: Dealing nicely with PM failure
From: Ming Lei @ 2012-12-15 14:33 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Steve Glendinning, netdev
In-Reply-To: <3581886.3cmiB2PA1J@linux-lqwf.site>
On Fri, Dec 14, 2012 at 10:56 PM, Oliver Neukum <oneukum@suse.de> wrote:
> Hi,
>
> this question about the smsc devices gave me an idea.
> How about this?
It is a good idea to handle remote wakeup failure, but I am wondering
if it is suitable to apply it on current smsc problem because we know
in advance if these devices can support auto suspend.
>
> From f1bdff89eea4c10102f867f9f22cb2b60519e425 Mon Sep 17 00:00:00 2001
> From: Oliver Neukum <oliver@neukum.org>
> Date: Fri, 14 Dec 2012 15:51:36 +0100
> Subject: [PATCH] usbnet: handle PM failure gracefully
>
> If a device fails to do remote wakeup, this is no reason
> to abort an open totally. This patch just continues without
> runtime PM.
>
> Signed-off-by: Oliver Neukum <oneukum@suse.de>
> ---
> drivers/net/usb/usbnet.c | 17 +++++++++--------
> include/linux/usb/usbnet.h | 1 +
> 2 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> index c04110b..2010eef 100644
> --- a/drivers/net/usb/usbnet.c
> +++ b/drivers/net/usb/usbnet.c
> @@ -719,7 +719,8 @@ int usbnet_stop (struct net_device *net)
> dev->flags = 0;
> del_timer_sync (&dev->delay);
> tasklet_kill (&dev->bh);
> - if (info->manage_power)
> + if (info->manage_power &&
> + !test_and_clear_bit(EVENT_NO_RUNTIME_PM, &dev->flags))
> info->manage_power(dev, 0);
> else
> usb_autopm_put_interface(dev->intf);
> @@ -793,15 +794,15 @@ int usbnet_open (struct net_device *net)
> // delay posting reads until we're fully open
> tasklet_schedule (&dev->bh);
> if (info->manage_power) {
> - retval = info->manage_power(dev, 1);
> - if (retval < 0)
> - goto done_manage_power_error;
> - usb_autopm_put_interface(dev->intf);
> + int r;
> +
> + r = info->manage_power(dev, 1);
> + if (r < 0)
> + set_bit(EVENT_NO_RUNTIME_PM, &dev->flags);
> + else
> + usb_autopm_put_interface(dev->intf);
> }
> return retval;
> -
> -done_manage_power_error:
> - clear_bit(EVENT_DEV_OPEN, &dev->flags);
> done:
> usb_autopm_put_interface(dev->intf);
> done_nopm:
> diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
> index 9bbeabf..288b32a 100644
> --- a/include/linux/usb/usbnet.h
> +++ b/include/linux/usb/usbnet.h
> @@ -69,6 +69,7 @@ struct usbnet {
> # define EVENT_DEV_ASLEEP 6
> # define EVENT_DEV_OPEN 7
> # define EVENT_DEVICE_REPORT_IDLE 8
> +# define EVENT_NO_RUNTIME_PM 9
> };
>
> static inline struct usb_driver *driver_of(struct usb_interface *intf)
> --
> 1.7.7
>
>
Thanks,
--
Ming Lei
^ permalink raw reply
* [PATCH] ip: add the type 'vxlan' in the output of "ip link help"
From: zwu.kernel @ 2012-12-15 16:21 UTC (permalink / raw)
To: shemminger; +Cc: netdev, linux-kernel, Zhi Yong Wu
From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
The new type 'vxlan' is added in the output of "ip link help"
Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
---
ip/iplink.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ip/iplink.c b/ip/iplink.c
index d73c705..5ff8f85 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -84,7 +84,7 @@ void iplink_usage(void)
if (iplink_have_newlink()) {
fprintf(stderr, "\n");
fprintf(stderr, "TYPE := { vlan | veth | vcan | dummy | ifb | macvlan | can |\n");
- fprintf(stderr, " bridge | ipoib | ip6tnl | ipip | sit }\n");
+ fprintf(stderr, " bridge | ipoib | ip6tnl | ipip | sit | vxlan }\n");
}
exit(-1);
}
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH net] sctp: jsctp_sf_eat_sack: fix kernel NULL ptr dereference
From: Daniel Borkmann @ 2012-12-15 19:58 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: David Miller, netdev
In-Reply-To: <CAD6jFUQtOL-4GAHvEJPw+zO1ZZ9Ay_qZGrfoirYdS3ONB0CYZA@mail.gmail.com>
On Fri, Dec 14, 2012 at 10:49 PM, Daniel Borkmann
<danborkmann@iogearbox.net> wrote:
> On Fri, Dec 14, 2012 at 5:57 PM, Daniel Borkmann <dborkman@redhat.com> wrote:
>> On 12/14/2012 04:12 PM, Vlad Yasevich wrote:
>>> On 12/14/2012 09:27 AM, Daniel Borkmann wrote:
>>>>
>>>> During debugging a sctp problem, I hit a kernel NULL pointer
>>>> dereference in the jprobes callback jsctp_sf_eat_sack(). This
>>>> small patch fixes the panic.
>>>>
>>>> Cc: Vlad Yasevich <vyasevich@gmail.com>
>>>> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
>>>> ---
>>>> net/sctp/probe.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/net/sctp/probe.c b/net/sctp/probe.c
>>>> index bc6cd75..0a4e9d6 100644
>>>> --- a/net/sctp/probe.c
>>>> +++ b/net/sctp/probe.c
>>>> @@ -134,7 +134,7 @@ sctp_disposition_t jsctp_sf_eat_sack(const struct
>>>> sctp_endpoint *ep,
>>>>
>>>> sp = asoc->peer.primary_path;
>>>>
>>>> - if ((full || sp->cwnd != lcwnd) &&
>>>> + if (sp && (full || sp->cwnd != lcwnd) &&
>>>> (!port || asoc->peer.port == port ||
>>>> ep->base.bind_addr.port == port)) {
>>>> lcwnd = sp->cwnd;
>>>
>>> Sorry, but this patch isn't making much sense. @sp points to the primary
>>> path of the association and that can not be null if we receiving
>>> SACKs on this association.
>>>
>>> sctp_sf_eat_sack_6_2(), which we are probing, is only called while the
>>> association is valid and all the transports still exist. It is also called
>>> under lock, so the transports can not go away while processing of the SACK.
>>> So unless there is some kind of jprobe issue, the pointer
>>> you are looking at should always be valid.
>>
>> Okay, I'll dig a bit deeper into that over the weekend.
>
> That's just for the record, I'll do further tests / debugging tomorrow ...
>
> I compiled the net kernel with kprobes selftest / sanity test
> (kernel/test_kprobes.c) and it passed:
>
> [ 2.978082] Kprobe smoke test started
> [ 3.034014] Kprobe smoke test passed successfully
>
> There, also jprobes are tested.
Found the problem, will send a new patch for the net tree in a couple
of minutes.
^ permalink raw reply
* [PATCH net] sctp: jsctp_sf_eat_sack: fix jprobes function signature mismatch
From: Daniel Borkmann @ 2012-12-15 20:12 UTC (permalink / raw)
To: David Miller; +Cc: Vlad Yasevich, netdev
In-Reply-To: <cover.1355602097.git.dborkman@redhat.com>
Commit 24cb81a6a (sctp: Push struct net down into all of the
state machine functions) introduced the net structure into all
state machine functions, but jsctp_sf_eat_sack was not updated,
hence when SCTP association probing is enabled in the kernel,
any simple SCTP client/server program from userspace will panic
the kernel.
Cc: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
net/sctp/probe.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/sctp/probe.c b/net/sctp/probe.c
index bc6cd75..5f7518d 100644
--- a/net/sctp/probe.c
+++ b/net/sctp/probe.c
@@ -122,7 +122,8 @@ static const struct file_operations sctpprobe_fops = {
.llseek = noop_llseek,
};
-sctp_disposition_t jsctp_sf_eat_sack(const struct sctp_endpoint *ep,
+sctp_disposition_t jsctp_sf_eat_sack(struct net *net,
+ const struct sctp_endpoint *ep,
const struct sctp_association *asoc,
const sctp_subtype_t type,
void *arg,
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH net] sctp: jsctp_sf_eat_sack: fix jprobes function signature mismatch
From: Vlad Yasevich @ 2012-12-15 20:39 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: David Miller, netdev
In-Reply-To: <a910a63d58d95aed8caeea8a43a21cab863b3bfb.1355602097.git.dborkman@redhat.com>
On 12/15/2012 03:12 PM, Daniel Borkmann wrote:
> Commit 24cb81a6a (sctp: Push struct net down into all of the
> state machine functions) introduced the net structure into all
> state machine functions, but jsctp_sf_eat_sack was not updated,
> hence when SCTP association probing is enabled in the kernel,
> any simple SCTP client/server program from userspace will panic
> the kernel.
Aha!!! That makes a lot more sense...
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Thanks
-vlad
>
> Cc: Vlad Yasevich <vyasevich@gmail.com>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> ---
> net/sctp/probe.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/sctp/probe.c b/net/sctp/probe.c
> index bc6cd75..5f7518d 100644
> --- a/net/sctp/probe.c
> +++ b/net/sctp/probe.c
> @@ -122,7 +122,8 @@ static const struct file_operations sctpprobe_fops = {
> .llseek = noop_llseek,
> };
>
> -sctp_disposition_t jsctp_sf_eat_sack(const struct sctp_endpoint *ep,
> +sctp_disposition_t jsctp_sf_eat_sack(struct net *net,
> + const struct sctp_endpoint *ep,
> const struct sctp_association *asoc,
> const sctp_subtype_t type,
> void *arg,
>
^ permalink raw reply
* Re: [PATCH 00/11] Add basic VLAN support to bridges
From: Vlad Yasevich @ 2012-12-15 20:52 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Stephen Hemminger, David Miller, or.gerlitz, netdev, mst,
john.r.fastabend
In-Reply-To: <50CBA15D.6010805@mojatatu.com>
On 12/14/2012 04:59 PM, Jamal Hadi Salim wrote:
> On 12-12-14 11:50 AM, Vlad Yasevich wrote:
>>
>> Interesting. But, but how complex would be be to configure a vlan
>> filter for say 10 different vlans,
>
> Shouldnt be hard. At the simple level you need one rule per VLAN.
> I am assuming only one vm per vlan and that you can key on something
> in the header.
>
>> each one of them only permitted
>> to be forwarded to their respective VM.
>
> Again assuming something in the header is going to say "this packet
> is allowed to go to this VM", a MAC address, an IP src/destination
> etc, correct?
The VLAN id in this case is what should decide where the packet is going.
>
> Oh, and Vlan tags should
>> be stripped when they are being forwarded.
>
> Assuming they are not already stripped at vnetx,
> you could write a very simple action (probably one page of code) to
> strip vlans and do everything at br0;
> Your filter finds them at br0, your action strips them and pipes to
> another action that redirects to the correct device. i.e in unix speak:
> filter at br0 for VMx | strip vlan tag | redirect to vnetx
So you would completely bypass the bridge? Not sure how much I like
that since what would happen if 2 VMs are to share VLAN. In such a
case, broadcasts/multicasts only should only get forwarded to both of
these VMs.
I guess we could add the filters on the vnetx interfaces (which are just
taps). Then its 2 filters per vlan (1 ingress 1 egress). Need to think
about this a bit.
Thanks
-vlad
>
> At the very minimal you need to identify those packets and that depends
> where you want to deploy the policy.
> If you deploy at the br device, you will see the raw packet i.e the vlan
> header wont be stripped.
> i.e youd have to enter some u32 rule with protocol "protocol 802.1q"
> If you deploy at each vnetx device assuming it is a vlan device, you
> wont see the vlan headers and you'll have to key on something else on
> the header "protocol ip"
>
> cheers,
> jamal
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] sctp: jsctp_sf_eat_sack: fix jprobes function signature mismatch
From: Daniel Borkmann @ 2012-12-15 21:02 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: David Miller, netdev
In-Reply-To: <50CCE017.2050407@gmail.com>
On Sat, Dec 15, 2012 at 9:39 PM, Vlad Yasevich <vyasevich@gmail.com> wrote:
> On 12/15/2012 03:12 PM, Daniel Borkmann wrote:
>>
>> Commit 24cb81a6a (sctp: Push struct net down into all of the
>> state machine functions) introduced the net structure into all
>> state machine functions, but jsctp_sf_eat_sack was not updated,
>> hence when SCTP association probing is enabled in the kernel,
>> any simple SCTP client/server program from userspace will panic
>> the kernel.
>
>
> Aha!!! That makes a lot more sense...
Indeed. ;-)
> Acked-by: Vlad Yasevich <vyasevich@gmail.com>
>
> Thanks
^ permalink raw reply
* Re: [PATCH 00/11] Add basic VLAN support to bridges
From: Jamal Hadi Salim @ 2012-12-15 21:04 UTC (permalink / raw)
To: vyasevic
Cc: Stephen Hemminger, David Miller, or.gerlitz, netdev, mst,
john.r.fastabend
In-Reply-To: <50CCE2F2.6040503@redhat.com>
sigh. Sorry Vlad - I should have made it clear that the feature
you added IS the way to go. i.e a needed missing piece with or without
VMs. I thought that part of the discussion was done and we were talking
about other things you'd like ON TOP ;->
Example to rate limit or protect the VM from other things.
Totally misunderstood you.
cheers,
jamal
^ permalink raw reply
* Re: tc ipt action
From: Jamal Hadi Salim @ 2012-12-15 21:19 UTC (permalink / raw)
To: Yury Stankevich, shemonc; +Cc: netdev@vger.kernel.org, pablo, netfilter-devel
In-Reply-To: <50C9B4BB.9060609@mojatatu.com>
Yury,
I took a brief look and run some quick tests on ubuntu 12.04. I am going
to be lazy and try and involve the netfilter folks.
It seems that if you left out the args to CONNMARK (includes other
targets like MARK etc) you will succeed - but you get default values.
Example, the following should work for
tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0
action ipt -j CONNMARK \
action mirred egress redirect dev ifb0
Here is what the output looks like when you dont pass the parameters.
-------
j@ubuntu:~$ sudo tc filter show dev eth0 parent ffff:
filter protocol ip pref 1 u32
filter protocol ip pref 1 u32 fh 800: ht divisor 1
filter protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
flowid 1:15
match 0a000015/ffffffff at 12
action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING
target MARK and 0xffffffff
index 2 ref 1 bind 1
filter protocol ip pref 49149 u32
filter protocol ip pref 49149 u32 fh 804: ht divisor 1
filter protocol ip pref 49149 u32 fh 804::800 order 2048 key ht 804 bkt
0 flowid 1:12
match 00000000/00000000 at 0
action order 33: tablename: mangle hook: NF_IP_PRE_ROUTING
target CONNMARK and 0x0
index 123 ref 1 bind 1
----------------
Pablo, Hasan Chowdhury tells me this broke after iptable 1.4.10
Hasan also sent me a small patch to fake "xt" instead of "ipt" - but i
think there's more than meets the eye here; some interface we are using
to talk to xtables on user space seems to have changed.
cheers,
jamal
On 12-12-13 05:58 AM, Jamal Hadi Salim wrote:
> Yury,
>
> This appears to be an ABI breakage on iptables/netfilter side.
> I will look at it (and hopefully fix it) over the weekend.
>
> cheers,
> jamal
>
> On 12-12-09 07:20 AM, Yury Stankevich wrote:
>> Hello,
>>
>> i not sure this is correct list, please advise if not.
>>
>> i'm trying to use ipt action, and got a problem:
>>
>> #tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0
>> action ipt -j CONNMARK --restore-mark action mirred egress redirect
>> dev ifb0
>> -> bad action type ipt
>>
>> from strace:
>> open("/usr/lib/tc//m_gact.so", O_RDONLY) = -1 ENOENT (No such file or
>> directory)
>> write(2, "bad action type ipt\n", 20bad action type ipt
>>
>> well. i'm trying to use xt:
>> #tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0
>> action xt -j CONNMARK --restore-mark action mirred egress redirect dev
>> ifb0
>> xt: unrecognized option '--restore-mark'
>>
>> from strace:
>> open("/lib/xtables/libxt_CONNMARK.so", O_RDONLY) = 4
>> read(4,
>> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\6\0\0004\0\0\0"...,
>> 512) = 512
>> fstat64(4, {st_mode=S_IFREG|0644, st_size=9756, ...}) = 0
>> mmap2(NULL, 12548, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0)
>> = 0xf76f3000
>> mmap2(0xf76f5000, 8192, PROT_READ|PROT_WRITE,
>> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1) = 0xf76f5000
>> close(4) = 0
>> mprotect(0xf76f5000, 4096, PROT_READ) = 0
>> socket(PF_INET, SOCK_RAW, IPPROTO_RAW) = 4
>> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
>> lstat64("/proc/net/ip_tables_names", {st_mode=S_IFREG|0440, st_size=0,
>> ...}) = 0
>> statfs64("/proc/net/ip_tables_names", 84, {f_type="PROC_SUPER_MAGIC",
>> f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0,
>> f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
>> getsockopt(4, SOL_IP, 0x43 /* IP_??? */,
>> "CONNMARK\0\367\f\300\0\0\0po\367l8p\367\364/p\367:}\302\1", [30]) = 0
>> close(4) = 0
>> write(2, "xt: unrecognized option '--resto"..., 41xt: unrecognized
>> option '--restore-mark'
>>
>> so... i make something wrong or this is a bug ?
>>
>> ps: 3.6.8 kernel 64 bit kernel with 32 bit userspace, iproute 20121001
>> from debian-experimental,
>> module act_ipt is loaded.
>> pps: please, cc me in reply.
>>
>>
>
^ permalink raw reply
* Re: tc ipt action
From: Jan Engelhardt @ 2012-12-15 23:06 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Yury Stankevich, shemonc, netdev@vger.kernel.org, pablo,
netfilter-devel
In-Reply-To: <50CCE961.5050204@mojatatu.com>
On Saturday 2012-12-15 22:19, Jamal Hadi Salim wrote:
>
> Example, the following should work for
> tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0
> action ipt -j CONNMARK \
> action mirred egress redirect dev ifb0
If I try that command (substituting ipt->xt and eth0->dummy0,
ifb0->dummy1), all I get is the dreaded "Invalid argument".
So the kernel rejected the command, which could indicate that
userspace construction might have been ok.
# tc filter add dev dummy0 parent ffff: protocol ip u32 match u32 0 0 \
action xt -j CONNMARK action mirred egress redirect dev dummy1
tablename: mangle hook: NF_IP_PRE_ROUTING
target: CONNMARK and 0x0 index 0
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
> Pablo, Hasan Chowdhury tells me this broke after iptable 1.4.10
> Hasan also sent me a small patch to fake "xt" instead of "ipt" - but i think
> there's more than meets the eye here; some interface we are using to talk to
> xtables on user space seems to have changed.
What was the last combination that worked?
^ permalink raw reply
* Re: tc ipt action
From: Jan Engelhardt @ 2012-12-16 0:26 UTC (permalink / raw)
To: vapier
Cc: Jamal Hadi Salim, Yury Stankevich, shemonc,
netdev@vger.kernel.org, Pablo Neira Ayuso,
Netfilter Developer Mailing List
In-Reply-To: <alpine.LNX.2.01.1212160002330.4901@nerf07.vanv.qr>
On Sunday 2012-12-16 00:06, Jan Engelhardt wrote:
>On Saturday 2012-12-15 22:19, Jamal Hadi Salim wrote:
>>
>> Example, the following should work for
>> tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0
>> action ipt -j CONNMARK \
>> action mirred egress redirect dev ifb0
>
>If I try that command (substituting ipt->xt and eth0->dummy0,
>ifb0->dummy1), all I get is the dreaded "Invalid argument".
>So the kernel rejected the command, which could indicate that
>userspace construction might have been ok.
>
># tc filter add dev dummy0 parent ffff: protocol ip u32 match u32 0 0 \
>action xt -j CONNMARK action mirred egress redirect dev dummy1
>
>tablename: mangle hook: NF_IP_PRE_ROUTING
> target: CONNMARK and 0x0 index 0
>RTNETLINK answers: Invalid argument
>We have an error talking to the kernel
>
>> Pablo, Hasan Chowdhury tells me this broke after iptable 1.4.10
>> Hasan also sent me a small patch to fake "xt" instead of "ipt" - but i think
>> there's more than meets the eye here; some interface we are using to talk to
>> xtables on user space seems to have changed.
>
>What was the last combination that worked?
For added fun, it works even less in iproute2-3.7.0.
commit e4fc4ada3317ea94452576add25981279d705b14
Author: Mike Frysinger <vapier@gentoo.org>
Date: Thu Nov 8 11:41:17 2012 -0500
allow pkg-config to be customized
Rather than hard coding `pkg-config`, use ${PKG_CONFIG} so people can
override it to their specific version (like when cross-compiling).
This is the same way the upstream pkg-config code works.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
broke it by causing tc/m_xt.so to no longer link against libxtables.so,
leading to:
# tc [above parameters]
tc: symbol lookup error: /usr/lib64/tc//m_xt.so: undefined symbol:
xtables_init_all
(Makefiles being simpler than $other_buildsys? A distant reality!)
^ permalink raw reply
* Re: tc ipt action
From: Pablo Neira Ayuso @ 2012-12-16 0:27 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Yury Stankevich, shemonc, netdev@vger.kernel.org, netfilter-devel
In-Reply-To: <50CCE961.5050204@mojatatu.com>
Hi Jamal!
On Sat, Dec 15, 2012 at 04:19:29PM -0500, Jamal Hadi Salim wrote:
> Yury,
>
> I took a brief look and run some quick tests on ubuntu 12.04. I am going
> to be lazy and try and involve the netfilter folks.
> It seems that if you left out the args to CONNMARK (includes other
> targets like MARK etc) you will succeed - but you get default
> values.
>
>
> Example, the following should work for
> tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0
> action ipt -j CONNMARK \
> action mirred egress redirect dev ifb0
>
> Here is what the output looks like when you dont pass the parameters.
>
> -------
> j@ubuntu:~$ sudo tc filter show dev eth0 parent ffff:
> filter protocol ip pref 1 u32
> filter protocol ip pref 1 u32 fh 800: ht divisor 1
> filter protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt
> 0 flowid 1:15
> match 0a000015/ffffffff at 12
> action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING
> target MARK and 0xffffffff
> index 2 ref 1 bind 1
>
> filter protocol ip pref 49149 u32
> filter protocol ip pref 49149 u32 fh 804: ht divisor 1
> filter protocol ip pref 49149 u32 fh 804::800 order 2048 key ht 804
> bkt 0 flowid 1:12
> match 00000000/00000000 at 0
> action order 33: tablename: mangle hook: NF_IP_PRE_ROUTING
> target CONNMARK and 0x0
> index 123 ref 1 bind 1
> ----------------
>
> Pablo, Hasan Chowdhury tells me this broke after iptable 1.4.10
> Hasan also sent me a small patch to fake "xt" instead of "ipt" - but
> i think there's more than meets the eye here; some interface we are
> using to talk to xtables on user space seems to have changed.
The binary interface was broken in 1.4.11 with the guided option
parser:
commit 7299fa4b615d7f7ee12cde444266f6b31f667f9f
Author: Jan Engelhardt <jengelh@medozas.de>
Date: Sun Mar 6 15:54:58 2011 +0100
libxt_CONNMARK: use guided option parser
You need a patch to use the new interface to stay in sync with current
iptables libraries. I'll make it for tc and send it to you.
BTW, I think it would be good if we find the way to check for
libxtables current version (see iptables/configure.ac), so you can
know that we broke binary compatibility again.
Cheers,
Pablo
^ permalink raw reply
* [PATCH] build: unbreak linkage of m_xt.so
From: Jan Engelhardt @ 2012-12-16 0:32 UTC (permalink / raw)
To: stephen.hemminger
Cc: vapier, netdev, jhs, urykhy, shemonc, pablo, netfilter-devel
In-Reply-To: <alpine.LNX.2.01.1212160119060.7193@nerf07.vanv.qr>
Commit v3.7.0~10 caused the variable new PKG_CONFIG variable never
to be present at the time of calling make, leading to tc/m_xt.so
not linked with -lxtables (result from pkg-config xtables --libs),
that in turn leading to
tc: symbol lookup error: /usr/lib64/tc//m_xt.so: undefined symbol:
xtables_init_all
Fixing that.
Signed-off-by: Jan Engelhardt <jengelh@inai.de>
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 9912114..573ee55 100755
--- a/configure
+++ b/configure
@@ -4,7 +4,6 @@
INCLUDE=${1:-"$PWD/include"}
: ${PKG_CONFIG:=pkg-config}
: ${CC=gcc}
-echo "PKG_CONFIG:=${PKG_CONFIG}" >>Config
# Make a temp directory in build tree.
TMPDIR=$(mktemp -d config.XXXXXX)
@@ -224,6 +223,7 @@ rm -f $TMPDIR/ipsettest.c $TMPDIR/ipsettest
}
echo "# Generated config based on" $INCLUDE >Config
+echo "PKG_CONFIG:=${PKG_CONFIG}" >>Config
echo "TC schedulers"
--
1.7.10.4
^ permalink raw reply related
* Re: tc ipt action
From: Jan Engelhardt @ 2012-12-16 0:59 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Jamal Hadi Salim, Yury Stankevich, shemonc,
netdev@vger.kernel.org, netfilter-devel
In-Reply-To: <20121216002755.GA11773@1984>
On Sunday 2012-12-16 01:27, Pablo Neira Ayuso wrote:
>On Sat, Dec 15, 2012 at 04:19:29PM -0500, Jamal Hadi Salim wrote:
>> Example, the following should work for
>> tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0
>> action ipt -j CONNMARK \
>> action mirred egress redirect dev ifb0
>>
>commit 7299fa4b615d7f7ee12cde444266f6b31f667f9f
> libxt_CONNMARK: use guided option parser
>
>BTW, I think it would be good if we find the way to check for
>libxtables current version (see iptables/configure.ac), so you can
>know that we broke binary compatibility again.
For the C level, there is XTABLES_VERSION_CODE.
#if XTABLES_VERSION_CODE >= 6
if (m != NULL && m->x6_parse != NULL)
m->x6_parse(...)
#else
else if (m != NULL && m->parse != NULL)
m->parse(...)
...
We can also export this through pkgconfig, similar to how
downstream users are to discover the plugin dir
(`pkg-config xtables --variable libdir`).
^ permalink raw reply
* [PATCH] netlink: change presentation of portid in procfs to unsigned
From: Hannes Frederic Sowa @ 2012-12-16 1:09 UTC (permalink / raw)
To: netdev
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
net/netlink/af_netlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 4da797f..fdb7494 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -2059,7 +2059,7 @@ static int netlink_seq_show(struct seq_file *seq, void *v)
struct sock *s = v;
struct netlink_sock *nlk = nlk_sk(s);
- seq_printf(seq, "%pK %-3d %-6d %08x %-8d %-8d %pK %-8d %-8d %-8lu\n",
+ seq_printf(seq, "%pK %-3d %-6u %08x %-8d %-8d %pK %-8d %-8d %-8lu\n",
s,
s->sk_protocol,
nlk->portid,
^ permalink raw reply related
* Re: [PATCH v2] can: sja1000: fix compilation on x86
From: David Miller @ 2012-12-16 1:16 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, rdunlap, andreas
In-Reply-To: <1355523912-1977-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Fri, 14 Dec 2012 23:25:12 +0100
> Since commit:
> 04df251 can: sja1000: Make sja1000_of_platform selectable and compilable on SPARC
> the driver can be activated on non powerpc platform like x86 or sparc. Without
> this patch the driver fails to compile on platform that don't define NO_IRQ,
> like x86.
>
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Andreas Larsson <andreas@gaisler.com>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Applied.
^ permalink raw reply
* Re: [PATCH] i2400m: add Intel 6150 device IDs
From: David Miller @ 2012-12-16 1:16 UTC (permalink / raw)
To: dcbw; +Cc: netdev, inaky.perez-gonzalez
In-Reply-To: <1355526650.32099.19.camel@dcbw.foobar.com>
From: Dan Williams <dcbw@redhat.com>
Date: Fri, 14 Dec 2012 17:10:50 -0600
> Add device IDs for WiMAX function of Intel 6150 cards.
>
> Signed-off-by: Dan Williams <dcbw@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] sctp: Change defaults on cookie hmac selection
From: David Miller @ 2012-12-16 1:16 UTC (permalink / raw)
To: nhorman; +Cc: netdev, torvalds, vyasevich, linux-sctp
In-Reply-To: <1355534521-32719-1-git-send-email-nhorman@tuxdriver.com>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 14 Dec 2012 20:22:01 -0500
> Recently I posted commit 3c68198e75 which made selection of the cookie hmac
> algorithm selectable. This is all well and good, but Linus noted that it
> changes the default config:
> http://marc.info/?l=linux-netdev&m=135536629004808&w=2
>
> I've modified the sctp Kconfig file to reflect the recommended way of making
> this choice, using the thermal driver example specified, and brought the
> defaults back into line with the way they were prior to my origional patch
>
> Also, on Linus' suggestion, re-adding ability to select default 'none' hmac
> algorithm, so we don't needlessly bloat the kernel by forcing a non-none
> default. This also led me to note that we won't honor the default none
> condition properly because of how sctp_net_init is encoded. Fix that up as
> well.
>
> Tested by myself (allbeit fairly quickly). All configuration combinations seems
> to work soundly.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] bridge: update selinux perm table for RTM_NEWMDB and RTM_DELMDB
From: David Miller @ 2012-12-16 1:16 UTC (permalink / raw)
To: amwang; +Cc: netdev, bridge, herbert, shemminger
In-Reply-To: <1355558992-32285-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Sat, 15 Dec 2012 16:09:50 +0800
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Stephen Hemminger <shemminger@vyatta.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] bridge: add flags to distinguish permanent mdb entires
From: David Miller @ 2012-12-16 1:16 UTC (permalink / raw)
To: amwang; +Cc: netdev, bridge, herbert, shemminger
In-Reply-To: <1355558992-32285-2-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Sat, 15 Dec 2012 16:09:51 +0800
> This patch adds a flag to each mdb entry, so that we can distinguish
> permanent entries with temporary entries.
>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Stephen Hemminger <shemminger@vyatta.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Applied, but you _really_ need to lock down the interface and
stop making changes to the user visible side of this _now_.
Thanks.
^ permalink raw reply
* Re: [PATCH net] sctp: jsctp_sf_eat_sack: fix jprobes function signature mismatch
From: David Miller @ 2012-12-16 1:17 UTC (permalink / raw)
To: dborkman; +Cc: vyasevich, netdev
In-Reply-To: <a910a63d58d95aed8caeea8a43a21cab863b3bfb.1355602097.git.dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Sat, 15 Dec 2012 21:12:43 +0100
> Commit 24cb81a6a (sctp: Push struct net down into all of the
> state machine functions) introduced the net structure into all
> state machine functions, but jsctp_sf_eat_sack was not updated,
> hence when SCTP association probing is enabled in the kernel,
> any simple SCTP client/server program from userspace will panic
> the kernel.
>
> Cc: Vlad Yasevich <vyasevich@gmail.com>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Applied.
^ 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