* Re: [PATCH] force dentry revalidation after namespace change
From: Eric W. Biederman @ 2012-07-05 23:31 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, netdev, Andrew Morton, Tejun Heo,
Greg Kroah-Hartman
In-Reply-To: <1341496805-26394-1-git-send-email-glommer@parallels.com>
Glauber Costa <glommer@parallels.com> writes:
> When we change the namespace tag of a sysfs entry, the associated dentry
> is still kept around. readdir() will work correctly and not display the
> old entries, but open() will still succeed, so will reads and writes.
>
> This will no longer happen if sysfs is remounted, hinting that this is a
> cache-related problem.
Equalivalently to remounting you can do
echo 3 > /proc/sys/vm/drop_caches.
> I am using the following sequence to demonstrate that:
>
> shell1:
> ip link add type veth
> unshare -nm
>
> shell2:
> ip link set veth1 <pid_of_shell_1>
> cat /sys/devices/virtual/net/veth1/ifindex
>
> Before that patch, this will succeed (fail to fail). After it, it will
> correctly return an error. Differently from a normal rename, which we
> handle fine, changing the object namespace will keep it's path intact.
> So this check seems necessary as well.
Overall good bug spotting, and good spotting of where the fix should
live.
Your summary should have said:
[PATCH] fail dentry revalidation after namespace change
And you have the test slightly wrong below.
> Signed-off-by: Glauber Costa <glommer@parallels.com>
> CC: Tejun Heo <tj@kernel.org>
> CC: Eric W. Biederman <ebiederm@xmission.com>
> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> fs/sysfs/dir.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
> index e6bb9b2..c24bdd9 100644
> --- a/fs/sysfs/dir.c
> +++ b/fs/sysfs/dir.c
> @@ -307,6 +307,7 @@ static int sysfs_dentry_revalidate(struct dentry *dentry, struct nameidata *nd)
> {
> struct sysfs_dirent *sd;
> int is_dir;
> + int type;
>
> if (nd->flags & LOOKUP_RCU)
> return -ECHILD;
> @@ -314,6 +315,10 @@ static int sysfs_dentry_revalidate(struct dentry *dentry, struct nameidata *nd)
> sd = dentry->d_fsdata;
> mutex_lock(&sysfs_mutex);
>
> + type = sysfs_ns_type(sd);
> + if (sd->s_ns && (sysfs_info(dentry->d_sb)->ns[type] != sd->s_ns))
> + goto out_bad;
> +
First this check should be down below with after the other rename
checks.
Second the test should be:
type = KOBJ_NS_TYPE_NONE;
if (sd->s_parent)
type = sysfs_ns_type(sd->s_parent);
if (type && (sysfs_info(dentry->d_sb)->ns[type] != sd->s_ns))
goto out_bad;
The important difference there it is the directory that the dirent is
in that the type comes from. Not the dirent itself.
> /* The sysfs dirent has been deleted */
> if (sd->s_flags & SYSFS_FLAG_REMOVED)
> goto out_bad;
Glauber. Do you think you can fix your patch and resubmit.
Eric
^ permalink raw reply
* Re: [iproute2] display vlan configuration
From: John Fastabend @ 2012-07-05 23:20 UTC (permalink / raw)
To: Fabien C.; +Cc: netdev
In-Reply-To: <4FF61DE9.7000507@jetable.org>
On 7/5/2012 4:06 PM, Fabien C. wrote:
> Hello,
>
> it looks like there is no way to show the vlan configuration with iproute (nor with any other tool apparently).
>
> This can lead to trouble since :
> # ip link add link eth0 name eth2.333 type vlan id 444
>
> will create an interface that will show up like this with "ip link show" :
> 51: eth2.333@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
>
> The only hint we have is the interface name, which may not be related to the vlan id we set earlier.
Here you need to show the details,
#ip -d link show dev eth2.333
From my current setup,
# ip -d link show dev vlan0
33: vlan0@eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
link/ether 00:1b:21:55:23:59 brd ff:ff:ff:ff:ff:ff
vlan id 101 <REORDER_HDR>
^ permalink raw reply
* [iproute2] display vlan configuration
From: Fabien C. @ 2012-07-05 23:06 UTC (permalink / raw)
To: netdev
Hello,
it looks like there is no way to show the vlan configuration with iproute (nor with any other tool apparently).
This can lead to trouble since :
# ip link add link eth0 name eth2.333 type vlan id 444
will create an interface that will show up like this with "ip link show" :
51: eth2.333@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
The only hint we have is the interface name, which may not be related to the vlan id we set earlier.
Is there any way to get that information?
Thanks,
Fabien
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCH net] Bug fix for batman-adv 2012-07-06
From: Antonio Quartulli @ 2012-07-05 22:51 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <1341528514-27906-1-git-send-email-ordex@autistici.org>
[-- Attachment #1: Type: text/plain, Size: 4380 bytes --]
On Fri, Jul 06, 2012 at 12:48:33 +0200, Antonio Quartulli wrote:
> here I have a fix intended for net/linux-3.5.
...
Hello David,
here you have our instructions to resolve the conflicts that you will hit while
merging net into net-next:
Conflict 1 (bridge_loop_avoidance.c):
<<<<<<<
int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid)
=======
int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid,
bool is_bcast)
>>>>>>>
resolves to:
int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid,
bool is_bcast)
Conflict 2 (bridge_loop_avoidance.h):
<<<<<<<
int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid);
int batadv_bla_tx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid);
int batadv_bla_is_backbone_gw(struct sk_buff *skb,
struct batadv_orig_node *orig_node, int hdr_size);
int batadv_bla_claim_table_seq_print_text(struct seq_file *seq, void *offset);
int batadv_bla_is_backbone_gw_orig(struct batadv_priv *bat_priv, uint8_t *orig);
int batadv_bla_check_bcast_duplist(struct batadv_priv *bat_priv,
struct batadv_bcast_packet *bcast_packet,
int hdr_size);
void batadv_bla_update_orig_address(struct batadv_priv *bat_priv,
struct batadv_hard_iface *primary_if,
struct batadv_hard_iface *oldif);
int batadv_bla_init(struct batadv_priv *bat_priv);
void batadv_bla_free(struct batadv_priv *bat_priv);
=======
int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid,
bool is_bcast);
int bla_tx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid);
int bla_is_backbone_gw(struct sk_buff *skb,
struct orig_node *orig_node, int hdr_size);
int bla_claim_table_seq_print_text(struct seq_file *seq, void *offset);
int bla_is_backbone_gw_orig(struct bat_priv *bat_priv, uint8_t *orig);
int bla_check_bcast_duplist(struct bat_priv *bat_priv,
struct bcast_packet *bcast_packet, int hdr_size);
void bla_update_orig_address(struct bat_priv *bat_priv,
struct hard_iface *primary_if,
struct hard_iface *oldif);
int bla_init(struct bat_priv *bat_priv);
void bla_free(struct bat_priv *bat_priv);
>>>>>>>
resolves to:
int batadv_bla_rx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid,
bool is_bcast);
int batadv_bla_tx(struct batadv_priv *bat_priv, struct sk_buff *skb, short vid);
int batadv_bla_is_backbone_gw(struct sk_buff *skb,
struct batadv_orig_node *orig_node, int hdr_size);
int batadv_bla_claim_table_seq_print_text(struct seq_file *seq, void *offset);
int batadv_bla_is_backbone_gw_orig(struct batadv_priv *bat_priv, uint8_t *orig);
int batadv_bla_check_bcast_duplist(struct batadv_priv *bat_priv,
struct batadv_bcast_packet *bcast_packet,
int hdr_size);
void batadv_bla_update_orig_address(struct batadv_priv *bat_priv,
struct batadv_hard_iface *primary_if,
struct batadv_hard_iface *oldif);
int batadv_bla_init(struct batadv_priv *bat_priv);
void batadv_bla_free(struct batadv_priv *bat_priv);
Conflict 3 (bridge_loop_avoidance.h):
<<<<<<<
static inline int batadv_bla_rx(struct batadv_priv *bat_priv,
struct sk_buff *skb, short vid)
=======
static inline int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb,
short vid, bool is_bcast)
>>>>>>>
resolves to:
static inline int batadv_bla_rx(struct batadv_priv *bat_priv,
struct sk_buff *skb, short vid, bool is_bcast)
Conflict 4 (soft-interface.c):
<<<<<<<
__be16 ethertype = __constant_htons(BATADV_ETH_P_BATMAN);
=======
bool is_bcast;
is_bcast = (batadv_header->packet_type == BAT_BCAST);
>>>>>>>
resolves to:
bool is_bcast;
__be16 ethertype = __constant_htons(BATADV_ETH_P_BATMAN);
is_bcast = (batadv_header->packet_type == BATADV_BCAST);
Conflict 5 (soft-interface.c):
<<<<<<<
if (batadv_bla_rx(bat_priv, skb, vid))
=======
if (bla_rx(bat_priv, skb, vid, is_bcast))
>>>>>>>
resolves to:
if (batadv_bla_rx(bat_priv, skb, vid, is_bcast))
Wrong merge by git (soft-interface.c):
line 270 must look like this:
struct batadv_header *batadv_header = (struct batadv_header *)skb->data;
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH net] batman-adv: check incoming packet type for bla
From: Antonio Quartulli @ 2012-07-05 22:48 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n, Simon Wunderlich, Simon Wunderlich
In-Reply-To: <1341528514-27906-1-git-send-email-ordex@autistici.org>
From: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
If the gateway functionality is used, some broadcast packets (DHCP
requests) may be transmitted as unicast packets. As the bridge loop
avoidance code now only considers the payload Ethernet destination,
it may drop the DHCP request for clients which are claimed by other
backbone gateways, because it falsely infers from the broadcast address
that the right backbone gateway should havehandled the broadcast.
Fix this by checking and delegating the batman-adv packet type used
for transmission.
Reported-by: Guido Iribarren <guidoiribarren@buenosaireslibre.org>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
---
net/batman-adv/bridge_loop_avoidance.c | 15 +++++++++++----
net/batman-adv/bridge_loop_avoidance.h | 5 +++--
net/batman-adv/soft-interface.c | 6 +++++-
3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/net/batman-adv/bridge_loop_avoidance.c b/net/batman-adv/bridge_loop_avoidance.c
index 8bf9751..c5863f4 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -1351,6 +1351,7 @@ void bla_free(struct bat_priv *bat_priv)
* @bat_priv: the bat priv with all the soft interface information
* @skb: the frame to be checked
* @vid: the VLAN ID of the frame
+ * @is_bcast: the packet came in a broadcast packet type.
*
* bla_rx avoidance checks if:
* * we have to race for a claim
@@ -1361,7 +1362,8 @@ void bla_free(struct bat_priv *bat_priv)
* process the skb.
*
*/
-int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid)
+int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid,
+ bool is_bcast)
{
struct ethhdr *ethhdr;
struct claim search_claim, *claim = NULL;
@@ -1380,7 +1382,7 @@ int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid)
if (unlikely(atomic_read(&bat_priv->bla_num_requests)))
/* don't allow broadcasts while requests are in flight */
- if (is_multicast_ether_addr(ethhdr->h_dest))
+ if (is_multicast_ether_addr(ethhdr->h_dest) && is_bcast)
goto handled;
memcpy(search_claim.addr, ethhdr->h_source, ETH_ALEN);
@@ -1406,8 +1408,13 @@ int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid)
}
/* if it is a broadcast ... */
- if (is_multicast_ether_addr(ethhdr->h_dest)) {
- /* ... drop it. the responsible gateway is in charge. */
+ if (is_multicast_ether_addr(ethhdr->h_dest) && is_bcast) {
+ /* ... drop it. the responsible gateway is in charge.
+ *
+ * We need to check is_bcast because with the gateway
+ * feature, broadcasts (like DHCP requests) may be sent
+ * using a unicast packet type.
+ */
goto handled;
} else {
/* seems the client considers us as its best gateway.
diff --git a/net/batman-adv/bridge_loop_avoidance.h b/net/batman-adv/bridge_loop_avoidance.h
index e39f93a..dc5227b 100644
--- a/net/batman-adv/bridge_loop_avoidance.h
+++ b/net/batman-adv/bridge_loop_avoidance.h
@@ -23,7 +23,8 @@
#define _NET_BATMAN_ADV_BLA_H_
#ifdef CONFIG_BATMAN_ADV_BLA
-int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid);
+int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid,
+ bool is_bcast);
int bla_tx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid);
int bla_is_backbone_gw(struct sk_buff *skb,
struct orig_node *orig_node, int hdr_size);
@@ -41,7 +42,7 @@ void bla_free(struct bat_priv *bat_priv);
#else /* ifdef CONFIG_BATMAN_ADV_BLA */
static inline int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb,
- short vid)
+ short vid, bool is_bcast)
{
return 0;
}
diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c
index 6e2530b..a0ec0e4 100644
--- a/net/batman-adv/soft-interface.c
+++ b/net/batman-adv/soft-interface.c
@@ -256,7 +256,11 @@ void interface_rx(struct net_device *soft_iface,
struct bat_priv *bat_priv = netdev_priv(soft_iface);
struct ethhdr *ethhdr;
struct vlan_ethhdr *vhdr;
+ struct batman_header *batadv_header = (struct batman_header *)skb->data;
short vid __maybe_unused = -1;
+ bool is_bcast;
+
+ is_bcast = (batadv_header->packet_type == BAT_BCAST);
/* check if enough space is available for pulling, and pull */
if (!pskb_may_pull(skb, hdr_size))
@@ -302,7 +306,7 @@ void interface_rx(struct net_device *soft_iface,
/* Let the bridge loop avoidance check the packet. If will
* not handle it, we can safely push it up.
*/
- if (bla_rx(bat_priv, skb, vid))
+ if (bla_rx(bat_priv, skb, vid, is_bcast))
goto out;
netif_rx(skb);
--
1.7.9.4
^ permalink raw reply related
* [PATCH net] Bug fix for batman-adv 2012-07-06
From: Antonio Quartulli @ 2012-07-05 22:48 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n
here I have a fix intended for net/linux-3.5.
The bug, discovered by Guido Iribarren and fixed by Simon Wunderlich, is caused
by the wrong interaction between the Bridge Loop Avoidance and the Gateway
feature of batman-adv.
Let me know if there are problems.
Thank you,
Antonio
The following changes since commit 9e85a6f9dc231f3ed3c1dc1b12217505d970142a:
Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux (2012-07-03 18:06:49 -0700)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git tags/batman-adv-fix-for-davem
for you to fetch changes up to 2d3f6ccc4ea5c74d4b4af1b47c56b4cff4bbfcb7:
batman-adv: check incoming packet type for bla (2012-07-06 00:08:46 +0200)
----------------------------------------------------------------
Included changes:
- fix a bug generated by the wrong interaction between the GW feature and the
Bridge Loop Avoidance
----------------------------------------------------------------
Simon Wunderlich (1):
batman-adv: check incoming packet type for bla
net/batman-adv/bridge_loop_avoidance.c | 15 +++++++++++----
net/batman-adv/bridge_loop_avoidance.h | 5 +++--
net/batman-adv/soft-interface.c | 6 +++++-
3 files changed, 19 insertions(+), 7 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next] cnic: Fix mmap regression.
From: David Miller @ 2012-07-05 22:36 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1341525586.7472.25.camel@LTIRV-MCHAN1.corp.ad.broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Thu, 5 Jul 2012 14:59:46 -0700
> Or you want me to send you the equivalent patches for net.
Please do so.
^ permalink raw reply
* Re: [PATCH] force dentry revalidation after namespace change
From: Serge E. Hallyn @ 2012-07-05 22:17 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, netdev, Andrew Morton, Tejun Heo, Eric W. Biederman,
Greg Kroah-Hartman
In-Reply-To: <1341496805-26394-1-git-send-email-glommer@parallels.com>
Quoting Glauber Costa (glommer@parallels.com):
> When we change the namespace tag of a sysfs entry, the associated dentry
> is still kept around. readdir() will work correctly and not display the
> old entries, but open() will still succeed, so will reads and writes.
>
> This will no longer happen if sysfs is remounted, hinting that this is a
> cache-related problem.
>
> I am using the following sequence to demonstrate that:
>
> shell1:
> ip link add type veth
> unshare -nm
>
> shell2:
> ip link set veth1 <pid_of_shell_1>
> cat /sys/devices/virtual/net/veth1/ifindex
>
> Before that patch, this will succeed (fail to fail). After it, it will
Confirmed that it currently fails to fail :)
> correctly return an error. Differently from a normal rename, which we
> handle fine, changing the object namespace will keep it's path intact.
> So this check seems necessary as well.
>
> Signed-off-by: Glauber Costa <glommer@parallels.com>
Haven't run it, but the patch looks good. Thanks, Glauber.
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
> CC: Tejun Heo <tj@kernel.org>
> CC: Eric W. Biederman <ebiederm@xmission.com>
> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> fs/sysfs/dir.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
> index e6bb9b2..c24bdd9 100644
> --- a/fs/sysfs/dir.c
> +++ b/fs/sysfs/dir.c
> @@ -307,6 +307,7 @@ static int sysfs_dentry_revalidate(struct dentry *dentry, struct nameidata *nd)
> {
> struct sysfs_dirent *sd;
> int is_dir;
> + int type;
>
> if (nd->flags & LOOKUP_RCU)
> return -ECHILD;
> @@ -314,6 +315,10 @@ static int sysfs_dentry_revalidate(struct dentry *dentry, struct nameidata *nd)
> sd = dentry->d_fsdata;
> mutex_lock(&sysfs_mutex);
>
> + type = sysfs_ns_type(sd);
> + if (sd->s_ns && (sysfs_info(dentry->d_sb)->ns[type] != sd->s_ns))
> + goto out_bad;
> +
> /* The sysfs dirent has been deleted */
> if (sd->s_flags & SYSFS_FLAG_REMOVED)
> goto out_bad;
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH net-next] cnic: Fix mmap regression.
From: Michael Chan @ 2012-07-05 21:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120629.153425.24594752441419170.davem@davemloft.net>
On Fri, 2012-06-29 at 15:34 -0700, David Miller wrote:
> From: "Michael Chan" <mchan@broadcom.com>
> Date: Fri, 29 Jun 2012 12:32:45 -0700
>
> > commit 1f85d58cdf15354a7120fc9ccc9bb9c45b53af88
> > cnic: Remove uio mem[0].
> >
> > introduced a regression as older versions of userspace app still rely
> > on this mmap. Restore the mmap functionality and get the base address
> > from pci_resource_start() as the nedev->base_addr has been deprecated for
> > PCI devices.
> >
> > Update version to 2.5.12.
> >
> > Signed-off-by: Michael Chan <mchan@broadocm.com>
>
> I really couldn't believe what you guys were doing in the original
> commit, but I decided to let you do stupid things and find out the
> hard way that removing any user visible interface is basically
> impossible.
>
> Applied, thanks.
>
David, this patch plus the earlier commit are also needed for the net
tree because netdev->base_addr was removed there. Can you apply these
directly to the net tree? Or you want me to send you the equivalent
patches for net. Thanks.
^ permalink raw reply
* [PATCH] gianfar: fix potential sk_wmem_alloc imbalance
From: Eric Dumazet @ 2012-07-05 21:45 UTC (permalink / raw)
To: David Miller
Cc: netdev, Manfred Rudigier, Claudiu Manoil, Jiajun Wu,
Paul Gortmaker, Andy Fleming
From: Eric Dumazet <edumazet@google.com>
commit db83d136d7f753 (gianfar: Fix missing sock reference when
processing TX time stamps) added a potential sk_wmem_alloc imbalance
If the new skb has a different truesize than old one, we can get a
negative sk_wmem_alloc once new skb is orphaned at TX completion.
Now we no longer early orphan skbs in dev_hard_start_xmit(), this
probably can lead to fatal bugs.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Manfred Rudigier <manfred.rudigier@omicron.at>
Cc: Claudiu Manoil <claudiu.manoil@freescale.com>
Cc: Jiajun Wu <b06378@freescale.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Andy Fleming <afleming@freescale.com>
---
Note : I don't have the hardware and discovered this problem by code
analysis. So please compile and run this patch before Acking it,
thanks !
BTW, dev->needed_headroom should be set to GMAC_FCB_LEN + GMAC_TXPAL_LEN
to avoid reallocations...
drivers/net/ethernet/freescale/gianfar.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index f2db8fc..ab1d80f 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -2063,10 +2063,9 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
return NETDEV_TX_OK;
}
- /* Steal sock reference for processing TX time stamps */
- swap(skb_new->sk, skb->sk);
- swap(skb_new->destructor, skb->destructor);
- kfree_skb(skb);
+ if (skb->sk)
+ skb_set_owner_w(skb_new, skb->sk);
+ consume_skb(skb);
skb = skb_new;
}
^ permalink raw reply related
* Re: [PATCH 0/5] rtcache remove respin
From: David Miller @ 2012-07-05 21:32 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1341515017.3265.6.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 05 Jul 2012 21:03:37 +0200
> If route cache is removed, I believe we can remove all paddings.
>
> Each tcp session will have its own dst_entry, instead of being shared.
Not really, the routing cache removal patches have poor performance
and won't go-in as-is. :-) Once PMTU/redirect/TCP-metrics are reworked
I plan to do things like the patch below to make the performance loss
more acceptable.
And then I'll do the same for input routes too, at which point your
'noref' case can be put back.
So really, we have to consider how to rework the layout of this
structure.
Thanks.
====================
ipv4: Cache output routes in fib_info nexthops.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/net/ip_fib.h | 3 +++
net/ipv4/fib_semantics.c | 2 ++
net/ipv4/route.c | 9 +++++++++
3 files changed, 14 insertions(+)
diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
index 3dc7c96..ff9f0c4 100644
--- a/include/net/ip_fib.h
+++ b/include/net/ip_fib.h
@@ -45,6 +45,7 @@ struct fib_config {
};
struct fib_info;
+struct rtable;
struct fib_nh {
struct net_device *nh_dev;
@@ -63,6 +64,8 @@ struct fib_nh {
__be32 nh_gw;
__be32 nh_saddr;
int nh_saddr_genid;
+
+ struct rtable *rth;
};
/*
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index c46c20b..f3ada74 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -148,6 +148,8 @@ static void free_fib_info_rcu(struct rcu_head *head)
change_nexthops(fi) {
if (nexthop_nh->nh_dev)
dev_put(nexthop_nh->nh_dev);
+ if (nexthop_nh->rth)
+ dst_release(&nexthop_nh->rth->dst);
} endfor_nexthops(fi);
release_net(fi->fib_net);
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 9f68f74..35bfd98 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -914,6 +914,8 @@ static void rt_set_nexthop(struct rtable *rt, const struct flowi4 *fl4,
#ifdef CONFIG_IP_ROUTE_CLASSID
dst->tclassid = FIB_RES_NH(*res).nh_tclassid;
#endif
+ FIB_RES_NH(*res).rth = rt;
+ dst_clone(&rt->dst);
}
if (dst_mtu(dst) > IP_MAX_MTU)
@@ -1399,6 +1401,13 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
fi = NULL;
}
+ if (fi) {
+ rth = FIB_RES_NH(*res).rth;
+ if (rth) {
+ dst_use(&rth->dst, jiffies);
+ return rth;
+ }
+ }
rth = rt_dst_alloc(dev_out,
IN_DEV_CONF_GET(in_dev, NOPOLICY),
IN_DEV_CONF_GET(in_dev, NOXFRM));
--
1.7.10
^ permalink raw reply related
* Re: ipv6 problem with 6lowpan
From: David Miller @ 2012-07-05 21:22 UTC (permalink / raw)
To: alex.bluesman.smirnov; +Cc: netdev
In-Reply-To: <CAJmB2rD8U1ihy4Ai6y5QGjj4f7txDabszesrNrQ=pgEbscePqQ@mail.gmail.com>
Should be fixed by Steffen Kassert's patch which I just pushed into net-next
^ permalink raw reply
* Re: [net-next:master] general protection fault in __nla_put()
From: David Miller @ 2012-07-05 21:22 UTC (permalink / raw)
To: wfg; +Cc: netdev
In-Reply-To: <20120705134857.GA14643@localhost>
Steffen Klassert posted a patch which fixes this.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: Initialize the neighbour pointer of rt6_info on allocation
From: David Miller @ 2012-07-05 21:21 UTC (permalink / raw)
To: steffen.klassert; +Cc: netdev
In-Reply-To: <20120705131828.GE1869@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Thu, 5 Jul 2012 15:18:28 +0200
> git commit 97cac082 (ipv6: Store route neighbour in rt6_info struct)
> added a neighbour pointer to rt6_info. Currently we don't initialize
> this pointer at allocation time. We assume this pointer to be valid
> if it is not a null pointer, so initialize it on allocation.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Applied, but as Eric said we need to find a way to avoid having to
make changes like this every time we simply want to add a struct
member to rt6_info.
^ permalink raw reply
* Re: AF_BUS socket address family
From: Jan Engelhardt @ 2012-07-05 21:06 UTC (permalink / raw)
To: Vincent Sanders; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <20120629231236.GA28593@mail.collabora.co.uk>
On Saturday 2012-06-30 01:12, Vincent Sanders wrote:
>
>Firstly it is intended is an interprocess mechanism and not to rely on
>a configured IP system, indeed one of its primary usages is to
>provide mechanism for various tools to set up IP networking.
Using IP as a localhost IPC is not uncommon (independent of
software preferring AF_UNIX, if so available). Distro boot
scripts have been running `ip addr add ::1/128 dev lo`
all these years along.
And now we suddently need a DBUS program just to configure
IP-based localhost IPC? I can see the flaw in that.
^ permalink raw reply
* Re: [net-next RFC V5 5/5] virtio_net: support negotiating the number of queues through ctrl vq
From: Amos Kong @ 2012-07-05 20:07 UTC (permalink / raw)
To: Sasha Levin
Cc: krkumar2, habanero, kvm, mst, netdev, mashirle, linux-kernel,
virtualization, edumazet, tahm, jwhan, davem, sri
In-Reply-To: <1341492679.18786.18.camel@lappy>
On 07/05/2012 08:51 PM, Sasha Levin wrote:
> On Thu, 2012-07-05 at 18:29 +0800, Jason Wang wrote:
>> @@ -1387,6 +1404,10 @@ static int virtnet_probe(struct virtio_device *vdev)
>> if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
>> vi->has_cvq = true;
>>
>> + /* Use single tx/rx queue pair as default */
>> + vi->num_queue_pairs = 1;
>> + vi->total_queue_pairs = num_queue_pairs;
vi->total_queue_pairs also should be set to 1
vi->total_queue_pairs = 1;
>
> The code is using this "default" even if the amount of queue pairs it
> wants was specified during initialization. This basically limits any
> device to use 1 pair when starting up.
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Amos.
^ permalink raw reply
* Re: [net-next RFC V5 4/5] virtio_net: multiqueue support
From: Amos Kong @ 2012-07-05 20:02 UTC (permalink / raw)
To: Jason Wang
Cc: krkumar2, habanero, mashirle, kvm, mst, netdev, linux-kernel,
virtualization, edumazet, tahm, jwhan, davem, sri
In-Reply-To: <1341484194-8108-5-git-send-email-jasowang@redhat.com>
On 07/05/2012 06:29 PM, Jason Wang wrote:
> This patch converts virtio_net to a multi queue device. After negotiated
> VIRTIO_NET_F_MULTIQUEUE feature, the virtio device has many tx/rx queue pairs,
> and driver could read the number from config space.
>
> The driver expects the number of rx/tx queue paris is equal to the number of
> vcpus. To maximize the performance under this per-cpu rx/tx queue pairs, some
> optimization were introduced:
>
> - Txq selection is based on the processor id in order to avoid contending a lock
> whose owner may exits to host.
> - Since the txq/txq were per-cpu, affinity hint were set to the cpu that owns
> the queue pairs.
>
> Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
...
>
> static int virtnet_probe(struct virtio_device *vdev)
> {
> - int err;
> + int i, err;
> struct net_device *dev;
> struct virtnet_info *vi;
> + u16 num_queues, num_queue_pairs;
> +
> + /* Find if host supports multiqueue virtio_net device */
> + err = virtio_config_val(vdev, VIRTIO_NET_F_MULTIQUEUE,
> + offsetof(struct virtio_net_config,
> + num_queues), &num_queues);
> +
> + /* We need atleast 2 queue's */
s/atleast/at least/
> + if (err || num_queues < 2)
> + num_queues = 2;
> + if (num_queues > MAX_QUEUES * 2)
> + num_queues = MAX_QUEUES;
num_queues = MAX_QUEUES * 2;
MAX_QUEUES is the limitation of RX or TX.
> +
> + num_queue_pairs = num_queues / 2;
...
--
Amos.
^ permalink raw reply
* Re: [PATCH 0/5] rtcache remove respin
From: Eric Dumazet @ 2012-07-05 19:03 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120705.031539.2275742387594459652.davem@davemloft.net>
On Thu, 2012-07-05 at 03:15 -0700, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 02 Jul 2012 12:44:01 +0200
>
> > If we still want __refcnt being on cache line boundary, we might find a
> > better way to accomplish this.
>
> Back to this issue again.
>
> Eric, if you take a look at net-next right now, I left a dummy padding
> in dst_entry where the neighbour pointer used to be.
>
> Can you come up with some way to make use of that new space?
>
If route cache is removed, I believe we can remove all paddings.
Each tcp session will have its own dst_entry, instead of being shared.
^ permalink raw reply
* Re: [PATCH net-next 13/15] netfilter: nfdbus: Add D-bus message parsing
From: Javier Martinez Canillas @ 2012-07-05 17:54 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Javier Martinez Canillas, Vincent Sanders, netdev, linux-kernel,
David S. Miller, Alban Crequy
In-Reply-To: <20120704173047.GA8864@1984>
On Wed, Jul 4, 2012 at 7:30 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Mon, Jul 02, 2012 at 05:43:43PM +0200, Javier Martinez Canillas wrote:
>> On 06/29/2012 07:11 PM, Pablo Neira Ayuso wrote:
>> > On Fri, Jun 29, 2012 at 05:45:52PM +0100, Vincent Sanders wrote:
>> >> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> >>
>> >> The netfilter D-Bus module needs to parse D-bus messages sent by
>> >> applications to decide whether a peer can receive or not a D-Bus
>> >> message. Add D-bus message parsing logic to be able to analyze.
>> >
>> > Not talking about the entire patchset, only about the part I'm
>> > responsible for.
>> >
>> > I don't see why you think this belong to netfilter at all.
>> >
>> > This doesn't integrate into the existing filtering infrastructure,
>> > neither it extends it in any way.
>> >
>>
>> Hello Pablo,
>>
>> Thanks a lot for your feedback.
>>
>> This is the first of a set of patches that adds a netfilter module to parse
>> D-Bus messages, the complete patch-set is:
>>
>> [PATCH 13/15] netfilter: nfdbus: Add D-bus message parsing
>> [PATCH 14/15] netfilter: nfdbus: Add D-bus match rule implementation
>> [PATCH 15/15] netfilter: add netfilter D-Bus module
>>
>> patches 13 and 14 just include D-Bus helper code to be used by the netfilter
>> module (added on patch 15) and specially the dbus_filter netfilter hook function.
>
> I see, the use of the netfilter hooks seems to be the only reason why
> you consider these chunks belong to netfilter.
>
>> For the next post version we will reorganize the patches so first the D-Bus
>> netfilter module is added with an empty dbus_filter function and then added the
>> D-Bus helper code.
>>
>> Also, we will move the nfdbus netfilter module to net/bus so is not inside the
>> netfilter core code.
>
> Yes, please, remove this stuff from my directory tree, I believe this
> filtering infrastructure has not much to do with Netfilter itself.
>
> It uses the connector to communicate kernel <-> userspace instead of
> nfnetlink and, as said, it does neither integrate into existing
> filtering kernel/userspace infrastructure nor integrates into it.
>
> So, please, if you plan to give another try to this patchset, move
> this to your net/bus directory as you propose and find a different
> (better) name for the filtering part (just to avoid confusion in the
> future).
>
> Thanks.
Hi Pablo,
Thanks a lot for your feedback and comments.
On a next patch-set post I'll move to net/bus and change the name as
you suggest.
Best regards,
--
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
^ permalink raw reply
* Re: [net-next RFC V5 0/5] Multiqueue virtio-net
From: Rick Jones @ 2012-07-05 17:45 UTC (permalink / raw)
To: Jason Wang
Cc: krkumar2, habanero, mashirle, kvm, mst, netdev, linux-kernel,
virtualization, edumazet, tahm, jwhan, davem, sri
In-Reply-To: <1341484194-8108-1-git-send-email-jasowang@redhat.com>
On 07/05/2012 03:29 AM, Jason Wang wrote:
>
> Test result:
>
> 1) 1 vm 2 vcpu 1q vs 2q, 1 - 1q, 2 - 2q, no pinning
>
> - Guest to External Host TCP STREAM
> sessions size throughput1 throughput2 norm1 norm2
> 1 64 650.55 655.61 100% 24.88 24.86 99%
> 2 64 1446.81 1309.44 90% 30.49 27.16 89%
> 4 64 1430.52 1305.59 91% 30.78 26.80 87%
> 8 64 1450.89 1270.82 87% 30.83 25.95 84%
Was the -D test-specific option used to set TCP_NODELAY? I'm guessing
from your description of how packet sizes were smaller with multiqueue
and your need to hack tcp_write_xmit() it wasn't but since we don't have
the specific netperf command lines (hint hint :) I wanted to make certain.
Instead of calling them throughput1 and throughput2, it might be more
clear in future to identify them as singlequeue and multiqueue.
Also, how are you combining the concurrent netperf results? Are you
taking sums of what netperf reports, or are you gathering statistics
outside of netperf?
> - TCP RR
> sessions size throughput1 throughput2 norm1 norm2
> 50 1 54695.41 84164.98 153% 1957.33 1901.31 97%
A single instance TCP_RR test would help confirm/refute any non-trivial
change in (effective) path length between the two cases.
happy benchmarking,
rick jones
^ permalink raw reply
* RE: [PATCH net 3/7] qlge: Garbage values shown in extra info during selftest.
From: Jitendra Kalsaria @ 2012-07-05 17:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Ron Mercer, Dept-NX Linux NIC Driver
In-Reply-To: <20120705.002341.316014337743384600.davem@davemloft.net>
-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Thursday, July 05, 2012 12:24 AM
>To: Jitendra Kalsaria
>Cc: netdev; Ron Mercer; Dept-NX Linux NIC Driver
>Subject: Re: [PATCH net 3/7] qlge: Garbage values shown in extra info during selftest.
>
>
>Why are you posting an arbitrary patch from a patch series,
>yet not the rest of that series?
>
>This needs to be sent alongside the rest of the series.
I haven't sent any arbitrary patch, seems like something wrong with mail server.
Thanks for letting me know about this will get it fixed.
^ permalink raw reply
* Re: AF_BUS socket address family
From: Daniel Walker @ 2012-07-05 16:01 UTC (permalink / raw)
To: Linus Walleij
Cc: Vincent Sanders, netdev, linux-kernel, David S. Miller,
Arve Hjønnevåg, John Stultz, Anton Vorontsov,
Greg Kroah-Hartman
In-Reply-To: <CAKnu2Mr_TWvBXmL+ORfddpEgPdPxPXFpJdCtvPe+imj6o6Y+1w@mail.gmail.com>
On Thu, Jul 05, 2012 at 09:59:53AM +0200, Linus Walleij wrote:
> 2012/6/29 Vincent Sanders <vincent.sanders@collabora.co.uk>:
>
> > AF_BUS is a message oriented inter process communication system.
>
> We have a very huge and important in-kernel IPC message passer
> in drivers/staging/android/binder.c
>
> It's deployed in some 400 million devices according to latest reports.
> John Stultz & Anton Vorontsov are trying to look after these Android
> drivers a bit...
>
> I and others discussed this in the past with the Android folks. Dianne
> makes an excellent summary of how it works here:
> https://lkml.org/lkml/2009/6/25/3
>
> If we could all be convinced that this thing also fulfills the needs
> of what binder does, this is a pretty solid case for it too. I can
> sure see that some of the shortcuts that Android is taking with
> binder try to address the same issue of high-speed IPC loopholes
> through the kernel and some kind of security model.
>
> Whether Android would actually use it (or wrap it) is a totally
> different question, but what I think we need to know is whether it
> *could*. And staging code has to move forward, maybe this
> is the direction it should move?
I'm all for alternatives.. I haven't read this thread at all, but I read an LWN
article comparing Binder and other implementations .. So there are for sure
alternatives. It would be nice if things were included that did whatever binder
needs .. Since I did the logger performance analysis the big questions to me is
if Binder is actually fast (or faster than the alternatives). Whatever this
AF_BUS things is reviewing the performance of the major alternative(s) is probably a
good idea.
In terms of Android using anything we produce or incorporate, don't get
your hopes up .. They will always just use Binder .. (John is good cop, I'm bad
cop)
Daniel
^ permalink raw reply
* Re: [PATCH] NFC: Don't warn when closing uninitialized socket
From: Samuel Ortiz @ 2012-07-05 15:45 UTC (permalink / raw)
To: Sasha Levin
Cc: lauro.venancio, aloisio.almeida, linville, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1341228702-9924-1-git-send-email-levinsasha928@gmail.com>
Hi Sasha,
On Mon, Jul 02, 2012 at 01:31:42PM +0200, Sasha Levin wrote:
> It is possible to close a NFC socket without initializing it first,
> there's no need to warn about it.
>
> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> ---
> net/nfc/llcp/llcp.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
I already fixed this one, with your reported-by.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: [PATCH] NFC: Prevent NULL deref when getting socket name
From: Samuel Ortiz @ 2012-07-05 15:42 UTC (permalink / raw)
To: John W. Linville
Cc: Sasha Levin, lauro.venancio, aloisio.almeida, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20120702182438.GB2010@tuxdriver.com>
Hi John,
On Mon, Jul 02, 2012 at 02:24:38PM -0400, John W. Linville wrote:
> On Sat, Jun 30, 2012 at 11:56:47AM +0200, Sasha Levin wrote:
> > llcp_sock_getname can be called without a device attached to the nfc_llcp_sock.
> >
> > This would lead to the following BUG:
> >
> > [ 362.341807] BUG: unable to handle kernel NULL pointer dereference at (null)
> > [ 362.341815] IP: [<ffffffff836258e5>] llcp_sock_getname+0x75/0xc0
> > [ 362.341818] PGD 31b35067 PUD 30631067 PMD 0
> > [ 362.341821] Oops: 0000 [#627] PREEMPT SMP DEBUG_PAGEALLOC
> > [ 362.341826] CPU 3
> > [ 362.341827] Pid: 7816, comm: trinity-child55 Tainted: G D W 3.5.0-rc4-next-20120628-sasha-00005-g9f23eb7 #479
> > [ 362.341831] RIP: 0010:[<ffffffff836258e5>] [<ffffffff836258e5>] llcp_sock_getname+0x75/0xc0
> > [ 362.341832] RSP: 0018:ffff8800304fde88 EFLAGS: 00010286
> > [ 362.341834] RAX: 0000000000000000 RBX: ffff880033cb8000 RCX: 0000000000000001
> > [ 362.341835] RDX: ffff8800304fdec4 RSI: ffff8800304fdec8 RDI: ffff8800304fdeda
> > [ 362.341836] RBP: ffff8800304fdea8 R08: 7ebcebcb772b7ffb R09: 5fbfcb9c35bdfd53
> > [ 362.341838] R10: 4220020c54326244 R11: 0000000000000246 R12: ffff8800304fdec8
> > [ 362.341839] R13: ffff8800304fdec4 R14: ffff8800304fdec8 R15: 0000000000000044
> > [ 362.341841] FS: 00007effa376e700(0000) GS:ffff880035a00000(0000) knlGS:0000000000000000
> > [ 362.341843] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 362.341844] CR2: 0000000000000000 CR3: 0000000030438000 CR4: 00000000000406e0
> > [ 362.341851] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [ 362.341856] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > [ 362.341858] Process trinity-child55 (pid: 7816, threadinfo ffff8800304fc000, task ffff880031270000)
> > [ 362.341858] Stack:
> > [ 362.341862] ffff8800304fdea8 ffff880035156780 0000000000000000 0000000000001000
> > [ 362.341865] ffff8800304fdf78 ffffffff83183b40 00000000304fdec8 0000006000000000
> > [ 362.341868] ffff8800304f0027 ffffffff83729649 ffff8800304fdee8 ffff8800304fdf48
> > [ 362.341869] Call Trace:
> > [ 362.341874] [<ffffffff83183b40>] sys_getpeername+0xa0/0x110
> > [ 362.341877] [<ffffffff83729649>] ? _raw_spin_unlock_irq+0x59/0x80
> > [ 362.341882] [<ffffffff810f342b>] ? do_setitimer+0x23b/0x290
> > [ 362.341886] [<ffffffff81985ede>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> > [ 362.341889] [<ffffffff8372a539>] system_call_fastpath+0x16/0x1b
> > [ 362.341921] Code: 84 00 00 00 00 00 b8 b3 ff ff ff 48 85 db 74 54 66 41 c7 04 24 27 00 49 8d 7c 24 12 41 c7 45 00 60 00 00 00 48 8b 83 28 05 00 00 <8b> 00 41 89 44 24 04 0f b6 83 41 05 00 00 41 88 44 24 10 0f b6
> > [ 362.341924] RIP [<ffffffff836258e5>] llcp_sock_getname+0x75/0xc0
> > [ 362.341925] RSP <ffff8800304fde88>
> > [ 362.341926] CR2: 0000000000000000
> > [ 362.341928] ---[ end trace 6d450e935ee18bf3 ]---
> >
> > Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
>
> Samuel, I'm taking this one directly.
Thanks. It was already on my for-wireless branch.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: [PATCH net-next] ipv6: Initialize the neighbour pointer of rt6_info on allocation
From: Eric Dumazet @ 2012-07-05 15:16 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, netdev
In-Reply-To: <20120705131828.GE1869@secunet.com>
On Thu, 2012-07-05 at 15:18 +0200, Steffen Klassert wrote:
> git commit 97cac082 (ipv6: Store route neighbour in rt6_info struct)
> added a neighbour pointer to rt6_info. Currently we don't initialize
> this pointer at allocation time. We assume this pointer to be valid
> if it is not a null pointer, so initialize it on allocation.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
> ---
> net/ipv6/route.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index ceff71d..6cc6c88 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -273,7 +273,7 @@ static inline struct rt6_info *ip6_dst_alloc(struct net *net,
> 0, 0, flags);
>
> if (rt) {
> - memset(&rt->rt6i_table, 0,
> + memset(&rt->n, 0,
> sizeof(*rt) - sizeof(struct dst_entry));
> rt6_init_peer(rt, table ? &table->tb6_peers : net->ipv6.peers);
> }
Hmm, could we find a way to avoid this for future changes ?
We know dst_entry is the first field, so maybe :
if (rt) {
struct dst_entry *dst = (struct dst_entry *)rt;
memset(dst + 1, 0, sizeof(*rt) - sizeof(*dst));
^ 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