* Re: [PATCH net-next #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: David Miller @ 2012-04-10 23:30 UTC (permalink / raw)
To: thockin; +Cc: romieu, netdev
In-Reply-To: <CAAAKZwu4D6QZ02gaRQ2pmF=tLyxjefu1c=H83cxAJq2TTgdxmA@mail.gmail.com>
From: Tim Hockin <thockin@hockin.org>
Date: Tue, 10 Apr 2012 15:53:53 -0700
> First, because I am not so involved any more, I can't say with
> certainty that these fields of struct net_device are not needed.
It's the whole basis of this patch set, and described neatly
in his "00/39" posting.
^ permalink raw reply
* Re: [PATCH net-next #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: Tim Hockin @ 2012-04-10 23:39 UTC (permalink / raw)
To: David Miller; +Cc: romieu, netdev
In-Reply-To: <20120410.193042.1153959183942458232.davem@davemloft.net>
OK, so that addresses that concern. :) Thanks.
Overall nothing in the CL stands out as bad, except for the IO vs MMIO
BAR thing, which I can not answer with certainty any more.
On Tue, Apr 10, 2012 at 4:30 PM, David Miller <davem@davemloft.net> wrote:
> From: Tim Hockin <thockin@hockin.org>
> Date: Tue, 10 Apr 2012 15:53:53 -0700
>
>> First, because I am not so involved any more, I can't say with
>> certainty that these fields of struct net_device are not needed.
>
> It's the whole basis of this patch set, and described neatly
> in his "00/39" posting.
^ permalink raw reply
* Re: [v2] Re: [RFC] l2tp/ipv6: support for L2TPv2 over UDP over IPv6
From: Benjamin LaHaise @ 2012-04-10 23:40 UTC (permalink / raw)
To: James Chapman; +Cc: Eric Dumazet, netdev
In-Reply-To: <20120410184916.GE24092@kvack.org>
On Tue, Apr 10, 2012 at 02:49:16PM -0400, Benjamin LaHaise wrote:
...
> Also, I found a bug in OpenL2TPd (1.8 I think): certain types of AVPs are
> not accepted if they are hidden, despite the fact that RFC 2661 permits
> hiding these AVPs. The AVPs in question are: Assigned Tunnel ID, Challege,
> Challenge Response and Assigned Session ID.
Here's the fix for OpenL2TPd 1.8. The use-after-realloc() in l2tp_avp_hide()
doesn't always work if the memory gets moved and glibc scribbles on
orig_buffer. There's also an interesting typo in l2tp_avp_message_decode().
-ben
--
"Thought is the essence of where you are now."
--- openl2tp-1.8/l2tp_avp.c.xxx 2008-05-08 15:05:26.000000000 -0400
+++ openl2tp-1.8/l2tp_avp.c 2012-04-10 18:07:05.866208480 -0400
@@ -535,16 +535,18 @@ static int l2tp_avp_hide(void **buffer,
* and we just need to shift the data up 2 bytes.
*/
new_buffer_len = orig_buffer_len + 2 + pad + 16;
- new_buffer = realloc(orig_buffer, new_buffer_len + L2TP_AVP_HEADER_LEN);
+ new_buffer = malloc(new_buffer_len + L2TP_AVP_HEADER_LEN);
if (new_buffer == NULL) {
return -ENOMEM;
}
- memmove(new_buffer + L2TP_AVP_HEADER_LEN + 2, orig_buffer + L2TP_AVP_HEADER_LEN, orig_buffer_len - L2TP_AVP_HEADER_LEN);
+ memcpy(new_buffer, orig_buffer, L2TP_AVP_HEADER_LEN);
+ memcpy(new_buffer + L2TP_AVP_HEADER_LEN + 2, orig_buffer + L2TP_AVP_HEADER_LEN, orig_buffer_len - L2TP_AVP_HEADER_LEN);
orig_len = new_buffer + L2TP_AVP_HEADER_LEN;
*orig_len = htons(orig_buffer_len - L2TP_AVP_HEADER_LEN);
if (new_buffer != orig_buffer) {
*buffer = new_buffer;
}
+ free(orig_buffer);
flag_len = new_buffer;
tmp = ntohs(*flag_len);
*flag_len = htons(tmp + 2 + pad);
@@ -1995,7 +1997,7 @@ int l2tp_avp_message_decode(int msg_len,
result = l2tp_avp_unhide(avp, &unhidden_avp_len,
(unsigned char *const) secret, secret_len,
(unsigned char *const) data[TYPE(RANDOM_VECTOR)].value,
- data[TYPE(RANDOM_VECTOR].value_len));
+ data[TYPE(RANDOM_VECTOR)].value_len);
if (result < 0) {
l2tp_tunnel_log(tunnel, L2TP_AVPHIDE, LOG_ERR, "AVPHIDE: tunl %hu: avp unhide error: %s",
l2tp_tunnel_id(tunnel), l2tp_strerror(-result));
^ permalink raw reply
* Re: via-rhine: Problem with lost link after a while
From: Bjarke Istrup Pedersen @ 2012-04-10 23:58 UTC (permalink / raw)
To: Francois Romieu
Cc: linux-kernel, netdev, Svenning Sørensen, Andreas Mohr
In-Reply-To: <20120410225534.GA28480@electric-eye.fr.zoreil.com>
11. apr. 2012 00.55 skrev Francois Romieu <romieu@fr.zoreil.com>:
> Bjarke Istrup Pedersen <gurligebis@gentoo.org> :
>> 10. apr. 2012 22.42 skrev Francois Romieu <romieu@fr.zoreil.com>:
> [...]
>> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;h=3f8c91a7398b9266fbe7abcbe4bd5dffef907643
> [...]
>> Great, I'll try a 3.4-rc2 kernel, and see how it runs.
>>
>> The thread I was talking about earlier is here:
>> http://lists.soekris.com/pipermail/soekris-tech/2012-April/018318.html
>> Is there any of the changes he has there, that makes sense in the new
>> driver you wrote ?
>
> (I did not write a new driver)
Sorry, bad choice of words, meant fixed some issues with the driver :)
> Regarding Svenning's patch:
> - the wmb in alloc_rbufs may help rhine_reset_task().
> - one should probably add one in rhine_rx() as well.
> - rhine_start_tx() is supposed to stop queueing when there is no room left.
> I'm curious to know if the "Tx descriptor busy" test triggered.
> - the rmb() in rhine_tx() will not make a difference for a single core but
> it's a good reminder that I should not have forgotten to propagate the
> xmit / Tx completion fix back from the r8169 driver to the via-rhine one
> (sigh)
>
> mmiowb is probably missing. I doubt it hits hard right now.
I'll give it a spin tomorrow, and see how it runs :)
> I have not checked if MMIO flushes are missing. Actually I need some sleep.
>
> diff --git a/drivers/net/ethernet/via/via-rhine.c b/drivers/net/ethernet/via/via-rhine.c
> index fcfa01f..dfa9fc0 100644
> --- a/drivers/net/ethernet/via/via-rhine.c
> +++ b/drivers/net/ethernet/via/via-rhine.c
> @@ -1163,6 +1163,7 @@ static void alloc_rbufs(struct net_device *dev)
> PCI_DMA_FROMDEVICE);
>
> rp->rx_ring[i].addr = cpu_to_le32(rp->rx_skbuff_dma[i]);
> + wmb();
> rp->rx_ring[i].rx_status = cpu_to_le32(DescOwn);
> }
> rp->dirty_rx = (unsigned int)(i - RX_RING_SIZE);
> @@ -1709,8 +1710,13 @@ static netdev_tx_t rhine_start_tx(struct sk_buff *skb,
> ioaddr + ChipCmd1);
> IOSYNC;
>
> - if (rp->cur_tx == rp->dirty_tx + TX_QUEUE_LEN)
> + if (rp->cur_tx == rp->dirty_tx + TX_QUEUE_LEN) {
> + smp_wmb();
> netif_stop_queue(dev);
> + smp_mb();
> + if (rp->cur_tx != rp->dirty_tx + TX_QUEUE_LEN)
> + netif_wake_queue(dev);
> + }
>
> netif_dbg(rp, tx_queued, dev, "Transmit frame #%d queued in slot %d\n",
> rp->cur_tx - 1, entry);
> @@ -1759,6 +1765,7 @@ static void rhine_tx(struct net_device *dev)
> struct rhine_private *rp = netdev_priv(dev);
> int txstatus = 0, entry = rp->dirty_tx % TX_RING_SIZE;
>
> + smp_rmb();
> /* find and cleanup dirty tx descriptors */
> while (rp->dirty_tx != rp->cur_tx) {
> txstatus = le32_to_cpu(rp->tx_ring[entry].tx_status);
> @@ -1806,8 +1813,12 @@ static void rhine_tx(struct net_device *dev)
> rp->tx_skbuff[entry] = NULL;
> entry = (++rp->dirty_tx) % TX_RING_SIZE;
> }
> - if ((rp->cur_tx - rp->dirty_tx) < TX_QUEUE_LEN - 4)
> +
> + smp_mb();
> + if (netif_queue_stopped(dev) &&
> + (rp->cur_tx - rp->dirty_tx) < TX_QUEUE_LEN - 4) {
> netif_wake_queue(dev);
> + }
> }
>
> /**
> @@ -1947,6 +1958,7 @@ static int rhine_rx(struct net_device *dev, int limit)
> PCI_DMA_FROMDEVICE);
> rp->rx_ring[entry].addr = cpu_to_le32(rp->rx_skbuff_dma[entry]);
> }
> + wmb();
> rp->rx_ring[entry].rx_status = cpu_to_le32(DescOwn);
> }
>
> --
> Ueimor
>
> Will code drivers for food.
> --
> 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 #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: David Miller @ 2012-04-11 0:02 UTC (permalink / raw)
To: thockin; +Cc: romieu, netdev
In-Reply-To: <CAAAKZwvRvc=6qwainJAkHCUEme+PsFY-s0PWxj9tYXwSmBcYJA@mail.gmail.com>
From: Tim Hockin <thockin@hockin.org>
Date: Tue, 10 Apr 2012 16:39:31 -0700
> OK, so that addresses that concern. :) Thanks.
>
> Overall nothing in the CL stands out as bad, except for the IO vs MMIO
> BAR thing, which I can not answer with certainty any more.
If you capacity to review patches to the driver for anything other
than trivial changes is close to zero, which it appears to be, you
might consider whether you should be listed in MAINTAINERS for it any
long. And also, therefore, whether this driver should be marked
as Maintained.
^ permalink raw reply
* Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
From: Arvid Brodin @ 2012-04-11 0:00 UTC (permalink / raw)
To: Stephen Hemminger, Ben Hutchings, David Miller
Cc: netdev@vger.kernel.org, balferreira@googlemail.com
In-Reply-To: <20120406111912.172bb1fb@nehalam.linuxnetplumber.net>
On 2012-04-06 20:19, Stephen Hemminger wrote:
> On Fri, 6 Apr 2012 18:06:31 +0100
> Ben Hutchings <bhutchings@solarflare.com> wrote:
>
>> On Fri, 2012-04-06 at 17:51 +0200, Arvid Brodin wrote:
>>> David Miller wrote:
>>>> From: Stephen Hemminger <shemminger@vyatta.com>
>>>> Date: Wed, 4 Apr 2012 16:55:59 -0700
>>>>
>>>>> That isn't so bad, doing a memcpy versus a structure copy.
>>>>
>>>> GCC is going to inline the memcpy and thus we'll still do the
>>>> unaligned accesses. This change therefore won't fix the problem.
>>>
>>> Well, it does work for me, with gcc-4.2.2-compiled linux-2.6.37 running
>>> on an AVR32 board.
>>>
>>> Just out of curiosity, what's the mechanism behind this inline
>>> assignment that turns the memcpy into an unaligned access? If gcc is
>>> "smart" enough to detect a bunch of char * accesses and turn them
>>> into unaligned 32-bit accesses, isn't that a bug in gcc?
>>
>> If I remember correctly, casting a char* pointer to foo* where the
>> original pointer isn't properly aligned for type foo results in
>> undefined behaviour. And that is what icmp_hdr() is doing, so there is
>> no requirement that the compiler does anything reasonable with the
>> result. Removing that cast (using skb_transport_header() instead of
>> icmp_hdr()) should avoid that.
>>
>> (We do generally assume, however, that if the processor can handle
>> unaligned accesses in a useful way then the compiler will be reasonable
>> and not break them.)
>>
>> Ben.
>>
>>> Or will this only happen on archs which __HAVE_ARCH_MEMCPY? (But looking
>>> at a couple of arch/xxx/lib/string.c, these too seem to take alignment
>>> into account.)
>>>
>>
>
> Since icmp_hdr is 64 bits you might be able to use get_unaligned64
> in some way.
>
I'm sorry, I have no idea how to do this. Besides, get_unaligned64 seems to be implemented
for the "c6x" arch only?
So far we have:
1) icmp_hdr() casts an unaligned char * to a wider type, which is bad (undefined).
2) We cannot use skb_transport_header():
On 2012-04-06 00:31, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Thu, 5 Apr 2012 20:21:08 +0100
>>
>> So presumably icmp_hdr() should be changed to skb_transport_header().
>
> I would not say so. Otherwise we introduce ugly casts everywhere.
>
3) My feeble suggestion to cast icmp_hdr() to (char *) is of course even worse (it doesn't
even avoid the erroneous cast in the first place).
So what do we do?
--
Arvid Brodin
Enea Services Stockholm AB - since February 16 a part of Xdin in the Alten Group. Soon we
will be working under the common brand name Xdin. Read more at www.xdin.com.
^ permalink raw reply
* Re: [PATCH net-next #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: Tim Hockin @ 2012-04-11 0:19 UTC (permalink / raw)
To: David Miller; +Cc: romieu, netdev
In-Reply-To: <20120410.200212.1031414009653598743.davem@davemloft.net>
I agree. The patches to this driver have been very few and far
between, but even those I am largely unable to review any more.
I'm more than willing to hand it off to someone who can do a better job of it
Tim
On Tue, Apr 10, 2012 at 5:02 PM, David Miller <davem@davemloft.net> wrote:
> From: Tim Hockin <thockin@hockin.org>
> Date: Tue, 10 Apr 2012 16:39:31 -0700
>
>> OK, so that addresses that concern. :) Thanks.
>>
>> Overall nothing in the CL stands out as bad, except for the IO vs MMIO
>> BAR thing, which I can not answer with certainty any more.
>
> If you capacity to review patches to the driver for anything other
> than trivial changes is close to zero, which it appears to be, you
> might consider whether you should be listed in MAINTAINERS for it any
> long. And also, therefore, whether this driver should be marked
> as Maintained.
>
^ permalink raw reply
* Re: [PATCH net-next #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: David Miller @ 2012-04-11 0:42 UTC (permalink / raw)
To: thockin; +Cc: romieu, netdev
In-Reply-To: <CAAAKZwt9TUdDS6-pQ_aDAMxJ+MRTNnHxC0Fuajm_WsqjUED6wg@mail.gmail.com>
From: Tim Hockin <thockin@hockin.org>
Date: Tue, 10 Apr 2012 17:19:42 -0700
> I agree. The patches to this driver have been very few and far
> between, but even those I am largely unable to review any more.
>
> I'm more than willing to hand it off to someone who can do a better job of it
My inclination was the mark the driver Orphan'd, which represents
the current state of affairs quite accurately.
^ permalink raw reply
* Re: [net-next PATCH v1 7/7] macvlan: add FDB bridge ops and new macvlan mode
From: Sridhar Samudrala @ 2012-04-11 0:46 UTC (permalink / raw)
To: John Fastabend
Cc: Michael S. Tsirkin, roprabhu, stephen.hemminger, davem, hadi,
bhutchings, jeffrey.t.kirsher, netdev, gregory.v.rose, krkumar2
In-Reply-To: <4F845345.8090601@intel.com>
On 4/10/2012 8:35 AM, John Fastabend wrote:
> On 4/10/2012 8:30 AM, Michael S. Tsirkin wrote:
>> On Tue, Apr 10, 2012 at 08:26:21AM -0700, John Fastabend wrote:
>>> On 4/10/2012 7:35 AM, Michael S. Tsirkin wrote:
>>>> On Tue, Apr 10, 2012 at 07:25:58AM -0700, John Fastabend wrote:
>>>>>> Hmm okay, but this would mean we should convert
>>>>>> MACVLAN_MODE_PASSTHRU_NOPROMISC to something
>>>>>> that can combined with all modes. E.g.
>>>>>> MACVLAN_MODE_BRIDGE | MACVLAN_MODE_FLAG_XXXXX
>>>>>>
>>>>>> and document that it does not promise to flood
>>>>>> multicast.
>>>>>>
>>>>> How about changing MACVLAN_MODE_PASSTHRU_NOPROMISC -> MACVLAN_MODE_NOPORMISC
>>>>> for this patch. Then a follow on series can rework bridge
>>>>> and VEPA to use it as well.
>>>> Right. We probably need a better name if it's going to
>>>> affect other things besides promisc though.
>>>>
>>> how about MACVLAN_MODE_FDBFLAG?
>> The idea being that no one figures out what this means so
>> no one will make any wrong assumptions? ;)
>>
> Well its a flag to enable the FDB (forwarding database) ops
> and skip dev_set_promisc() on passthru mode. Any better ideas?
> Maybe MACVLAN_MODE_FDBENABLE or MACVLAN_MODE_MANAGE_FDB?
Do we need to introduce another mode? I think this patch is enabling
passthru mode without the need
to put the underlying device in promiscuous mode. So basically we can
consider this patch as
an optimization.
Thanks
Sridhar
^ permalink raw reply
* [PATCH 05/11] broadcom: replace open-coded ARRAY_SIZE with macro
From: Jim Cromie @ 2012-04-11 0:56 UTC (permalink / raw)
To: netdev; +Cc: trivial, Jim Cromie
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
drivers/net/ethernet/broadcom/bnx2.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c
index 8297e28..0552168 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -7343,8 +7343,7 @@ static struct {
{ "rx_fw_discards" },
};
-#define BNX2_NUM_STATS (sizeof(bnx2_stats_str_arr)/\
- sizeof(bnx2_stats_str_arr[0]))
+#define BNX2_NUM_STATS ARRAY_SIZE(bnx2_stats_str_arr)
#define STATS_OFFSET32(offset_name) (offsetof(struct statistics_block, offset_name) / 4)
--
1.7.8.1
^ permalink raw reply related
* [PATCH 06/11] enic: replace open-coded ARRAY_SIZE with macro
From: Jim Cromie @ 2012-04-11 0:56 UTC (permalink / raw)
To: netdev; +Cc: trivial, Jim Cromie
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
drivers/net/ethernet/cisco/enic/enic_pp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/cisco/enic/enic_pp.c b/drivers/net/ethernet/cisco/enic/enic_pp.c
index dafea1e..43464f0 100644
--- a/drivers/net/ethernet/cisco/enic/enic_pp.c
+++ b/drivers/net/ethernet/cisco/enic/enic_pp.c
@@ -184,7 +184,7 @@ static int (*enic_pp_handlers[])(struct enic *enic, int vf,
};
static const int enic_pp_handlers_count =
- sizeof(enic_pp_handlers)/sizeof(*enic_pp_handlers);
+ ARRAY_SIZE(enic_pp_handlers);
static int enic_pp_preassociate(struct enic *enic, int vf,
struct enic_port_profile *prev_pp, int *restore_pp)
--
1.7.8.1
^ permalink raw reply related
* [PATCH 07/11] ethernet: replace open-coded ARRAY_SIZE with macro
From: Jim Cromie @ 2012-04-11 0:56 UTC (permalink / raw)
To: netdev, davem, jeffrey.t.kirsher, joe, florian, netdev
Cc: trivial, Jim Cromie
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
drivers/net/ethernet/s6gmac.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/s6gmac.c b/drivers/net/ethernet/s6gmac.c
index 1895605..8e9fda0 100644
--- a/drivers/net/ethernet/s6gmac.c
+++ b/drivers/net/ethernet/s6gmac.c
@@ -937,7 +937,7 @@ static struct net_device_stats *s6gmac_stats(struct net_device *dev)
do {
unsigned long flags;
spin_lock_irqsave(&pd->lock, flags);
- for (i = 0; i < sizeof(pd->stats) / sizeof(unsigned long); i++)
+ for (i = 0; i < ARRAY_SIZE(pd->stats); i++)
pd->stats[i] =
pd->carry[i] << (S6_GMAC_STAT_SIZE_MIN - 1);
s6gmac_stats_collect(pd, &statinf[0][0]);
--
1.7.8.1
^ permalink raw reply related
* Re: [PATCH net-next #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: Tim Hockin @ 2012-04-11 0:59 UTC (permalink / raw)
To: David Miller; +Cc: romieu, netdev
In-Reply-To: <20120410.204202.923592889066244236.davem@davemloft.net>
On Tue, Apr 10, 2012 at 5:42 PM, David Miller <davem@davemloft.net> wrote:
> From: Tim Hockin <thockin@hockin.org>
> Date: Tue, 10 Apr 2012 17:19:42 -0700
>
>> I agree. The patches to this driver have been very few and far
>> between, but even those I am largely unable to review any more.
>>
>> I'm more than willing to hand it off to someone who can do a better job of it
>
> My inclination was the mark the driver Orphan'd, which represents
> the current state of affairs quite accurately.
I'm OK with that. As much as I don't like being a deadbeat, it's a
more accurate snapshot of this driver today.
Tim
^ permalink raw reply
* Re: [PATCH net-next #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: David Miller @ 2012-04-11 1:11 UTC (permalink / raw)
To: thockin; +Cc: romieu, netdev
In-Reply-To: <CAAAKZwsVA7XxbbUfYRdC20Z0gjTG-3vAmQibA1Z5yaFdpa9jgA@mail.gmail.com>
From: Tim Hockin <thockin@hockin.org>
Date: Tue, 10 Apr 2012 17:59:40 -0700
> On Tue, Apr 10, 2012 at 5:42 PM, David Miller <davem@davemloft.net> wrote:
>> From: Tim Hockin <thockin@hockin.org>
>> Date: Tue, 10 Apr 2012 17:19:42 -0700
>>
>>> I agree. The patches to this driver have been very few and far
>>> between, but even those I am largely unable to review any more.
>>>
>>> I'm more than willing to hand it off to someone who can do a better job of it
>>
>> My inclination was the mark the driver Orphan'd, which represents
>> the current state of affairs quite accurately.
>
> I'm OK with that. As much as I don't like being a deadbeat, it's a
> more accurate snapshot of this driver today.
Ok, I'll push that MAINTAINERS change, thanks Tim.
^ permalink raw reply
* Re: [PATCH net-next #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: Tim Hockin @ 2012-04-11 1:16 UTC (permalink / raw)
To: David Miller; +Cc: romieu, netdev
In-Reply-To: <20120410.211114.643908401942868800.davem@davemloft.net>
On Tue, Apr 10, 2012 at 6:11 PM, David Miller <davem@davemloft.net> wrote:
> From: Tim Hockin <thockin@hockin.org>
> Date: Tue, 10 Apr 2012 17:59:40 -0700
>
>> On Tue, Apr 10, 2012 at 5:42 PM, David Miller <davem@davemloft.net> wrote:
>>> From: Tim Hockin <thockin@hockin.org>
>>> Date: Tue, 10 Apr 2012 17:19:42 -0700
>>>
>>>> I agree. The patches to this driver have been very few and far
>>>> between, but even those I am largely unable to review any more.
>>>>
>>>> I'm more than willing to hand it off to someone who can do a better job of it
>>>
>>> My inclination was the mark the driver Orphan'd, which represents
>>> the current state of affairs quite accurately.
>>
>> I'm OK with that. As much as I don't like being a deadbeat, it's a
>> more accurate snapshot of this driver today.
>
> Ok, I'll push that MAINTAINERS change, thanks Tim.
I wish there were a way to say "I know a fair amount about this
device" without claiming an "M" line (send patches here).
Tim
^ permalink raw reply
* Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
From: Stephen Hemminger @ 2012-04-11 1:28 UTC (permalink / raw)
To: Arvid Brodin
Cc: Ben Hutchings, David Miller, netdev@vger.kernel.org,
balferreira@googlemail.com
In-Reply-To: <4F84CA36.7020209@xdin.com>
> 3) My feeble suggestion to cast icmp_hdr() to (char *) is of course even worse (it doesn't
> even avoid the erroneous cast in the first place).
>
> So what do we do?
>
Reading Documentation/unalgined-memory-access.txt suggests that you
probably should copy the skb before passing up the stack (if necessary).
That is safe (but slightly slower).
^ permalink raw reply
* Re: [net-next PATCH v1 7/7] macvlan: add FDB bridge ops and new macvlan mode
From: John Fastabend @ 2012-04-11 1:42 UTC (permalink / raw)
To: Sridhar Samudrala, Michael S. Tsirkin
Cc: roprabhu, stephen.hemminger, davem, hadi, bhutchings,
jeffrey.t.kirsher, netdev, gregory.v.rose, krkumar2
In-Reply-To: <4F84D472.8090602@us.ibm.com>
On 4/10/2012 5:46 PM, Sridhar Samudrala wrote:
> On 4/10/2012 8:35 AM, John Fastabend wrote:
>> On 4/10/2012 8:30 AM, Michael S. Tsirkin wrote:
>>> On Tue, Apr 10, 2012 at 08:26:21AM -0700, John Fastabend wrote:
>>>> On 4/10/2012 7:35 AM, Michael S. Tsirkin wrote:
>>>>> On Tue, Apr 10, 2012 at 07:25:58AM -0700, John Fastabend wrote:
>>>>>>> Hmm okay, but this would mean we should convert
>>>>>>> MACVLAN_MODE_PASSTHRU_NOPROMISC to something
>>>>>>> that can combined with all modes. E.g.
>>>>>>> MACVLAN_MODE_BRIDGE | MACVLAN_MODE_FLAG_XXXXX
>>>>>>>
>>>>>>> and document that it does not promise to flood
>>>>>>> multicast.
>>>>>>>
>>>>>> How about changing MACVLAN_MODE_PASSTHRU_NOPROMISC -> MACVLAN_MODE_NOPORMISC
>>>>>> for this patch. Then a follow on series can rework bridge
>>>>>> and VEPA to use it as well.
>>>>> Right. We probably need a better name if it's going to
>>>>> affect other things besides promisc though.
>>>>>
>>>> how about MACVLAN_MODE_FDBFLAG?
>>> The idea being that no one figures out what this means so
>>> no one will make any wrong assumptions? ;)
>>>
>> Well its a flag to enable the FDB (forwarding database) ops
>> and skip dev_set_promisc() on passthru mode. Any better ideas?
>> Maybe MACVLAN_MODE_FDBENABLE or MACVLAN_MODE_MANAGE_FDB?
> Do we need to introduce another mode? I think this patch is enabling passthru mode without the need
> to put the underlying device in promiscuous mode. So basically we can consider this patch as
> an optimization.
>
> Thanks
> Sridhar
>
Sridhar, Michael,
After thinking about this a bit I would propose keeping this
patch as is. Or if we prefer I can make this a flag but I don't
think that helps much. passthru mode is the only macvlan mode
that calls dev_set_promiscuity(). Either way I think this mode
or flag should _only_ toggle the call to dev_set_promiscuity().
Setting multicast dev->flag IFF_ALLMULTI seems to be a completely
separate optimization that we can work with a follow up patch.
Any thoughts?
Thanks for the feedback,
John
^ permalink raw reply
* rcu_sched_state detected stall, no stack trace
From: Prashant Batra (prbatra) @ 2012-04-11 2:20 UTC (permalink / raw)
To: netdev
Hi,
I am running vanilla kernel 3.0.23 . I am trying to add some 6K and more
IPv6 IPSec tunnels.
I am getting these warnings in dmesg close to 6k tunnels, after which
the kernel hangs and have to reboot the kernel.
[ 1511.045261] INFO: rcu_sched_state detected stall on CPU 4 (t=300000
jiffies) [ 1534.736899] INFO: rcu_bh_state detected stalls on
CPUs/tasks: { 4} (detected by 13, t=300002 jiffies)
I am not getting any back-trace also, to figure out what is actually
causing the stall to happen.
Could someone help to figure out the issue.
Regards,
Prashant
^ permalink raw reply
* [PATCH net-next 1/2] net/ipv6/udp: Add encap_rcv support to IPv6 UDP
From: Benjamin LaHaise @ 2012-04-11 2:20 UTC (permalink / raw)
To: David S. Miller, James Chapman; +Cc: netdev
At present, UDP encapsulated protocols (like L2TP) are only able to use the
encap_rcv hook with UDP over IPv4. This patch adds the same support for use
with UDP over IPv6.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
---
net/ipv6/udp.c | 31 +++++++++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 37b0699..4d7cd72 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -515,6 +515,37 @@ int udpv6_queue_rcv_skb(struct sock * sk, struct sk_buff *skb)
if (!xfrm6_policy_check(sk, XFRM_POLICY_IN, skb))
goto drop;
+ if (up->encap_type) {
+ int (*encap_rcv)(struct sock *sk, struct sk_buff *skb);
+
+ /*
+ * This is an encapsulation socket so pass the skb to
+ * the socket's udp_encap_rcv() hook. Otherwise, just
+ * fall through and pass this up the UDP socket.
+ * up->encap_rcv() returns the following value:
+ * =0 if skb was successfully passed to the encap
+ * handler or was discarded by it.
+ * >0 if skb should be passed on to UDP.
+ * <0 if skb should be resubmitted as proto -N
+ */
+
+ /* if we're overly short, let UDP handle it */
+ encap_rcv = ACCESS_ONCE(up->encap_rcv);
+ if (skb->len > sizeof(struct udphdr) && encap_rcv != NULL) {
+ int ret;
+
+ ret = encap_rcv(sk, skb);
+ if (ret <= 0) {
+ UDP6_INC_STATS_BH(sock_net(sk),
+ UDP_MIB_INDATAGRAMS,
+ is_udplite);
+ return -ret;
+ }
+ }
+
+ /* FALLTHROUGH -- it's a UDP Packet */
+ }
+
/*
* UDP-Lite specific tests, ignored on UDP sockets (see net/ipv4/udp.c).
*/
--
1.7.4.1
--
"Thought is the essence of where you are now."
^ permalink raw reply related
* [net-next PATCH 2/2] net/l2tp: add support for L2TP over IPv6 UDP
From: Benjamin LaHaise @ 2012-04-11 2:21 UTC (permalink / raw)
To: David S. Miller, James Chapman; +Cc: netdev
This patch adds support for carrying L2TP frames over UDP on top of IPv6 in
addition to the existing UDP on IPv4. Support has been tested with both hw
accelerated ethernet drivers, as well as dumb interfaces.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
---
include/linux/if_pppol2tp.h | 28 ++++++++++++++-
include/linux/if_pppox.h | 12 ++++++
net/l2tp/l2tp_core.c | 84 ++++++++++++++++++++++++++++++++++++------
net/l2tp/l2tp_ppp.c | 42 +++++++++++++++++++++-
4 files changed, 152 insertions(+), 14 deletions(-)
diff --git a/include/linux/if_pppol2tp.h b/include/linux/if_pppol2tp.h
index 23cefa1..b477541 100644
--- a/include/linux/if_pppol2tp.h
+++ b/include/linux/if_pppol2tp.h
@@ -19,10 +19,11 @@
#ifdef __KERNEL__
#include <linux/in.h>
+#include <linux/in6.h>
#endif
/* Structure used to connect() the socket to a particular tunnel UDP
- * socket.
+ * socket over IPv4.
*/
struct pppol2tp_addr {
__kernel_pid_t pid; /* pid that owns the fd.
@@ -35,6 +36,20 @@ struct pppol2tp_addr {
__u16 d_tunnel, d_session; /* For sending outgoing packets */
};
+/* Structure used to connect() the socket to a particular tunnel UDP
+ * socket over IPv6.
+ */
+struct pppol2tpin6_addr {
+ __kernel_pid_t pid; /* pid that owns the fd.
+ * 0 => current */
+ int fd; /* FD of UDP socket to use */
+
+ __u16 s_tunnel, s_session; /* For matching incoming packets */
+ __u16 d_tunnel, d_session; /* For sending outgoing packets */
+
+ struct sockaddr_in6 addr; /* IP address and port to send to */
+};
+
/* The L2TPv3 protocol changes tunnel and session ids from 16 to 32
* bits. So we need a different sockaddr structure.
*/
@@ -49,6 +64,17 @@ struct pppol2tpv3_addr {
__u32 d_tunnel, d_session; /* For sending outgoing packets */
};
+struct pppol2tpv3in6_addr {
+ __kernel_pid_t pid; /* pid that owns the fd.
+ * 0 => current */
+ int fd; /* FD of UDP or IP socket to use */
+
+ __u32 s_tunnel, s_session; /* For matching incoming packets */
+ __u32 d_tunnel, d_session; /* For sending outgoing packets */
+
+ struct sockaddr_in6 addr; /* IP address and port to send to */
+};
+
/* Socket options:
* DEBUG - bitmask of debug message categories
* SENDSEQ - 0 => don't send packets with sequence numbers
diff --git a/include/linux/if_pppox.h b/include/linux/if_pppox.h
index b5f927f..6720d57 100644
--- a/include/linux/if_pppox.h
+++ b/include/linux/if_pppox.h
@@ -83,6 +83,12 @@ struct sockaddr_pppol2tp {
struct pppol2tp_addr pppol2tp;
} __attribute__((packed));
+struct sockaddr_pppol2tpin6 {
+ __kernel_sa_family_t sa_family; /* address family, AF_PPPOX */
+ unsigned int sa_protocol; /* protocol identifier */
+ struct pppol2tpin6_addr pppol2tp;
+} __attribute__((packed));
+
/* The L2TPv3 protocol changes tunnel and session ids from 16 to 32
* bits. So we need a different sockaddr structure.
*/
@@ -92,6 +98,12 @@ struct sockaddr_pppol2tpv3 {
struct pppol2tpv3_addr pppol2tp;
} __attribute__((packed));
+struct sockaddr_pppol2tpv3in6 {
+ __kernel_sa_family_t sa_family; /* address family, AF_PPPOX */
+ unsigned int sa_protocol; /* protocol identifier */
+ struct pppol2tpv3in6_addr pppol2tp;
+} __attribute__((packed));
+
/*********************************************************************
*
* ioctl interface for defining forwarding of connections
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index 89ff8c6..ef024a4 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -53,6 +53,9 @@
#include <net/inet_common.h>
#include <net/xfrm.h>
#include <net/protocol.h>
+#include <net/inet6_connection_sock.h>
+#include <net/inet_ecn.h>
+#include <net/ip6_route.h>
#include <asm/byteorder.h>
#include <linux/atomic.h>
@@ -446,21 +449,43 @@ static inline int l2tp_verify_udp_checksum(struct sock *sk,
{
struct udphdr *uh = udp_hdr(skb);
u16 ulen = ntohs(uh->len);
- struct inet_sock *inet;
__wsum psum;
- if (sk->sk_no_check || skb_csum_unnecessary(skb) || !uh->check)
- return 0;
-
- inet = inet_sk(sk);
- psum = csum_tcpudp_nofold(inet->inet_saddr, inet->inet_daddr, ulen,
- IPPROTO_UDP, 0);
-
- if ((skb->ip_summed == CHECKSUM_COMPLETE) &&
- !csum_fold(csum_add(psum, skb->csum)))
+ if (sk->sk_no_check || skb_csum_unnecessary(skb))
return 0;
- skb->csum = psum;
+#if IS_ENABLED(CONFIG_IPV6)
+ if (sk->sk_family == PF_INET6) {
+ if (!uh->check) {
+ LIMIT_NETDEBUG(KERN_INFO "L2TP: IPv6: checksum is 0\n");
+ return 1;
+ }
+ if ((skb->ip_summed == CHECKSUM_COMPLETE) &&
+ !csum_ipv6_magic(&ipv6_hdr(skb)->saddr,
+ &ipv6_hdr(skb)->daddr, ulen,
+ IPPROTO_UDP, skb->csum)) {
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
+ return 0;
+ }
+ skb->csum = ~csum_unfold(csum_ipv6_magic(&ipv6_hdr(skb)->saddr,
+ &ipv6_hdr(skb)->daddr,
+ skb->len, IPPROTO_UDP,
+ 0));
+ } else
+#endif
+ {
+ struct inet_sock *inet;
+ if (!uh->check)
+ return 0;
+ inet = inet_sk(sk);
+ psum = csum_tcpudp_nofold(inet->inet_saddr, inet->inet_daddr,
+ ulen, IPPROTO_UDP, 0);
+
+ if ((skb->ip_summed == CHECKSUM_COMPLETE) &&
+ !csum_fold(csum_add(psum, skb->csum)))
+ return 0;
+ skb->csum = psum;
+ }
return __skb_checksum_complete(skb);
}
@@ -988,7 +1013,12 @@ static int l2tp_xmit_core(struct l2tp_session *session, struct sk_buff *skb,
/* Queue the packet to IP for output */
skb->local_df = 1;
- error = ip_queue_xmit(skb, fl);
+#if IS_ENABLED(CONFIG_IPV6)
+ if (skb->sk->sk_family == PF_INET6)
+ error = inet6_csk_xmit(skb, NULL);
+ else
+#endif
+ error = ip_queue_xmit(skb, fl);
/* Update stats */
if (error >= 0) {
@@ -1021,6 +1051,31 @@ static inline void l2tp_skb_set_owner_w(struct sk_buff *skb, struct sock *sk)
skb->destructor = l2tp_sock_wfree;
}
+#if IS_ENABLED(CONFIG_IPV6)
+static void l2tp_xmit_ipv6_csum(struct sock *sk, struct sk_buff *skb,
+ int udp_len)
+{
+ struct ipv6_pinfo *np = inet6_sk(sk);
+ struct udphdr *uh = udp_hdr(skb);
+
+ if (!skb_dst(skb) || !skb_dst(skb)->dev ||
+ !(skb_dst(skb)->dev->features & NETIF_F_IPV6_CSUM)) {
+ skb->ip_summed = CHECKSUM_COMPLETE;
+ skb->csum = skb_checksum(skb, 0, udp_len, 0);
+ uh->check = csum_ipv6_magic(&np->saddr, &np->daddr, udp_len,
+ IPPROTO_UDP, skb->csum);
+ if (uh->check == 0)
+ uh->check = CSUM_MANGLED_0;
+ } else {
+ skb->ip_summed = CHECKSUM_PARTIAL;
+ skb->csum_start = skb_transport_header(skb) - skb->head;
+ skb->csum_offset = offsetof(struct udphdr, check);
+ uh->check = ~csum_ipv6_magic(&np->saddr, &np->daddr,
+ udp_len, IPPROTO_UDP, 0);
+ }
+}
+#endif
+
/* If caller requires the skb to have a ppp header, the header must be
* inserted in the skb data before calling this function.
*/
@@ -1089,6 +1144,11 @@ int l2tp_xmit_skb(struct l2tp_session *session, struct sk_buff *skb, int hdr_len
uh->check = 0;
/* Calculate UDP checksum if configured to do so */
+#if IS_ENABLED(CONFIG_IPV6)
+ if (sk->sk_family == PF_INET6)
+ l2tp_xmit_ipv6_csum(sk, skb, udp_len);
+ else
+#endif
if (sk->sk_no_check == UDP_CSUM_NOXMIT)
skb->ip_summed = CHECKSUM_NONE;
else if ((skb_dst(skb) && skb_dst(skb)->dev) &&
diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
index 1addd9f..27b9dec 100644
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -916,7 +916,7 @@ static int pppol2tp_getname(struct socket *sock, struct sockaddr *uaddr,
}
inet = inet_sk(tunnel->sock);
- if (tunnel->version == 2) {
+ if ((tunnel->version == 2) && (tunnel->sock->sk_family == AF_INET)) {
struct sockaddr_pppol2tp sp;
len = sizeof(sp);
memset(&sp, 0, len);
@@ -932,6 +932,46 @@ static int pppol2tp_getname(struct socket *sock, struct sockaddr *uaddr,
sp.pppol2tp.addr.sin_port = inet->inet_dport;
sp.pppol2tp.addr.sin_addr.s_addr = inet->inet_daddr;
memcpy(uaddr, &sp, len);
+#if IS_ENABLED(CONFIG_IPV6)
+ } else if ((tunnel->version == 2) &&
+ (tunnel->sock->sk_family == AF_INET6)) {
+ struct ipv6_pinfo *np = inet6_sk(tunnel->sock);
+ struct sockaddr_pppol2tpin6 sp;
+ len = sizeof(sp);
+ memset(&sp, 0, len);
+ sp.sa_family = AF_PPPOX;
+ sp.sa_protocol = PX_PROTO_OL2TP;
+ sp.pppol2tp.fd = tunnel->fd;
+ sp.pppol2tp.pid = pls->owner;
+ sp.pppol2tp.s_tunnel = tunnel->tunnel_id;
+ sp.pppol2tp.d_tunnel = tunnel->peer_tunnel_id;
+ sp.pppol2tp.s_session = session->session_id;
+ sp.pppol2tp.d_session = session->peer_session_id;
+ sp.pppol2tp.addr.sin6_family = AF_INET6;
+ sp.pppol2tp.addr.sin6_port = inet->inet_dport;
+ memcpy(&sp.pppol2tp.addr.sin6_addr, &np->daddr,
+ sizeof(np->daddr));
+ memcpy(uaddr, &sp, len);
+ } else if ((tunnel->version == 3) &&
+ (tunnel->sock->sk_family == AF_INET6)) {
+ struct ipv6_pinfo *np = inet6_sk(tunnel->sock);
+ struct sockaddr_pppol2tpv3in6 sp;
+ len = sizeof(sp);
+ memset(&sp, 0, len);
+ sp.sa_family = AF_PPPOX;
+ sp.sa_protocol = PX_PROTO_OL2TP;
+ sp.pppol2tp.fd = tunnel->fd;
+ sp.pppol2tp.pid = pls->owner;
+ sp.pppol2tp.s_tunnel = tunnel->tunnel_id;
+ sp.pppol2tp.d_tunnel = tunnel->peer_tunnel_id;
+ sp.pppol2tp.s_session = session->session_id;
+ sp.pppol2tp.d_session = session->peer_session_id;
+ sp.pppol2tp.addr.sin6_family = AF_INET6;
+ sp.pppol2tp.addr.sin6_port = inet->inet_dport;
+ memcpy(&sp.pppol2tp.addr.sin6_addr, &np->daddr,
+ sizeof(np->daddr));
+ memcpy(uaddr, &sp, len);
+#endif
} else if (tunnel->version == 3) {
struct sockaddr_pppol2tpv3 sp;
len = sizeof(sp);
--
1.7.4.1
--
"Thought is the essence of where you are now."
^ permalink raw reply related
* Re: [PATCH] memcg/tcp: fix warning caused b res->usage go to negative.
From: Glauber Costa @ 2012-04-11 2:22 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: netdev, David Miller, Andrew Morton
In-Reply-To: <4F83B3FD.4010107@jp.fujitsu.com>
>
> The problem is that jump_label updating is not atomic_ops.
That's indeed really bad.
You seem to be right about that... I wonder, however, if we should
prevent anything to run in any cpu during the jump_label update?
The update can be slow, sure, but it is not expected to be frequent...
> I'm _not_ sure the update order of the jump_label in sock_update_memcg()
> and other jump instructions inserted at accounting.
Any ordering assumptions here would be extremely fragile, even if we
could make one.
> For example, if the jump instruction in sock_update_memcg() is updated 1st
> and others are updated later, it's unclear whether sockets which has _valid_
> sock->sk_cgrp will be accounted or not because accounting jump instruction
> may not be updated yet.
>
> Hopefully, label in sock_update_memcg should be updated last...
>
> Hm. If I do, I'll add one more key as:
>
> atomic_t sock_should_memcg_aware;
>
> And update 2 keys in following order.
>
> At enable
> static_key_slow_inc(&memcg_socket_limit_enabled)
> atomic_inc(&sock_should_memcg_aware);
>
> At disable
> atomic_dec(&sock_should_memcg_aware);
> static_key_slow_dec(&memcg_socket_limit_enabled)
>
> And
> ==
> void sock_update_memcg(struct sock *sk)
> {
> if (atomic_read(&sock_should_memcg_aware)) {
>
> ==
Problem here is that having an atomic variable here defeats a bit the
purpose of the jump labels.
If it is just in the update path, it is not *that* bad.
But unless we go fix the jump labels to prevent such thing from
happening, maybe it would be better to have two jump labels here?
One for the writer, that is updated last, and one from the readers.
This way we can force the ordering the way we want.
^ permalink raw reply
* linux-next: manual merge of the wireless-next tree with the net-next tree
From: Stephen Rothwell @ 2012-04-11 2:56 UTC (permalink / raw)
To: John W. Linville
Cc: linux-next, linux-kernel, David Miller, netdev, Javier Cardona,
Marco Porsch, Pavel Zubarev
[-- Attachment #1: Type: text/plain, Size: 6481 bytes --]
Hi John,
Today's linux-next merge of the wireless-next tree got a conflict in
net/wireless/nl80211.c between commit 9360ffd18597 ("wireless: Stop using
NLA_PUT*()") from the net-next tree and commit d299a1f21ea7 ("{nl,cfg}
80211: Support for mesh synchronization") from the wireless-next tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc net/wireless/nl80211.c
index 65622e9,b12a052..0000000
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@@ -2540,17 -2486,18 +2543,20 @@@ static int nl80211_send_station(struct
nla_nest_end(msg, bss_param);
}
- if (sinfo->filled & STATION_INFO_STA_FLAGS)
- NLA_PUT(msg, NL80211_STA_INFO_STA_FLAGS,
- sizeof(struct nl80211_sta_flag_update),
- &sinfo->sta_flags);
- if (sinfo->filled & STATION_INFO_T_OFFSET)
- NLA_PUT_U64(msg, NL80211_STA_INFO_T_OFFSET,
- sinfo->t_offset);
+ if ((sinfo->filled & STATION_INFO_STA_FLAGS) &&
+ nla_put(msg, NL80211_STA_INFO_STA_FLAGS,
+ sizeof(struct nl80211_sta_flag_update),
+ &sinfo->sta_flags))
+ goto nla_put_failure;
++ if ((sinfo->filled & STATION_INFO_T_OFFSET) &&
++ nla_put_u64(msg, NL80211_STA_INFO_T_OFFSET, sinfo->t_offset))
++ goto nla_put_failure;
nla_nest_end(msg, sinfoattr);
- if (sinfo->filled & STATION_INFO_ASSOC_REQ_IES)
- NLA_PUT(msg, NL80211_ATTR_IE, sinfo->assoc_req_ies_len,
- sinfo->assoc_req_ies);
+ if ((sinfo->filled & STATION_INFO_ASSOC_REQ_IES) &&
+ nla_put(msg, NL80211_ATTR_IE, sinfo->assoc_req_ies_len,
+ sinfo->assoc_req_ies))
+ goto nla_put_failure;
return genlmsg_end(msg, hdr);
@@@ -3328,48 -3274,49 +3334,50 @@@ static int nl80211_get_mesh_config(stru
pinfoattr = nla_nest_start(msg, NL80211_ATTR_MESH_CONFIG);
if (!pinfoattr)
goto nla_put_failure;
- NLA_PUT_U32(msg, NL80211_ATTR_IFINDEX, dev->ifindex);
- NLA_PUT_U16(msg, NL80211_MESHCONF_RETRY_TIMEOUT,
- cur_params.dot11MeshRetryTimeout);
- NLA_PUT_U16(msg, NL80211_MESHCONF_CONFIRM_TIMEOUT,
- cur_params.dot11MeshConfirmTimeout);
- NLA_PUT_U16(msg, NL80211_MESHCONF_HOLDING_TIMEOUT,
- cur_params.dot11MeshHoldingTimeout);
- NLA_PUT_U16(msg, NL80211_MESHCONF_MAX_PEER_LINKS,
- cur_params.dot11MeshMaxPeerLinks);
- NLA_PUT_U8(msg, NL80211_MESHCONF_MAX_RETRIES,
- cur_params.dot11MeshMaxRetries);
- NLA_PUT_U8(msg, NL80211_MESHCONF_TTL,
- cur_params.dot11MeshTTL);
- NLA_PUT_U8(msg, NL80211_MESHCONF_ELEMENT_TTL,
- cur_params.element_ttl);
- NLA_PUT_U8(msg, NL80211_MESHCONF_AUTO_OPEN_PLINKS,
- cur_params.auto_open_plinks);
- NLA_PUT_U32(msg, NL80211_MESHCONF_SYNC_OFFSET_MAX_NEIGHBOR,
- cur_params.dot11MeshNbrOffsetMaxNeighbor);
- NLA_PUT_U8(msg, NL80211_MESHCONF_HWMP_MAX_PREQ_RETRIES,
- cur_params.dot11MeshHWMPmaxPREQretries);
- NLA_PUT_U32(msg, NL80211_MESHCONF_PATH_REFRESH_TIME,
- cur_params.path_refresh_time);
- NLA_PUT_U16(msg, NL80211_MESHCONF_MIN_DISCOVERY_TIMEOUT,
- cur_params.min_discovery_timeout);
- NLA_PUT_U32(msg, NL80211_MESHCONF_HWMP_ACTIVE_PATH_TIMEOUT,
- cur_params.dot11MeshHWMPactivePathTimeout);
- NLA_PUT_U16(msg, NL80211_MESHCONF_HWMP_PREQ_MIN_INTERVAL,
- cur_params.dot11MeshHWMPpreqMinInterval);
- NLA_PUT_U16(msg, NL80211_MESHCONF_HWMP_PERR_MIN_INTERVAL,
- cur_params.dot11MeshHWMPperrMinInterval);
- NLA_PUT_U16(msg, NL80211_MESHCONF_HWMP_NET_DIAM_TRVS_TIME,
- cur_params.dot11MeshHWMPnetDiameterTraversalTime);
- NLA_PUT_U8(msg, NL80211_MESHCONF_HWMP_ROOTMODE,
- cur_params.dot11MeshHWMPRootMode);
- NLA_PUT_U16(msg, NL80211_MESHCONF_HWMP_RANN_INTERVAL,
- cur_params.dot11MeshHWMPRannInterval);
- NLA_PUT_U8(msg, NL80211_MESHCONF_GATE_ANNOUNCEMENTS,
- cur_params.dot11MeshGateAnnouncementProtocol);
- NLA_PUT_U8(msg, NL80211_MESHCONF_FORWARDING,
- cur_params.dot11MeshForwarding);
- NLA_PUT_U32(msg, NL80211_MESHCONF_RSSI_THRESHOLD,
- cur_params.rssi_threshold);
+ if (nla_put_u32(msg, NL80211_ATTR_IFINDEX, dev->ifindex) ||
+ nla_put_u16(msg, NL80211_MESHCONF_RETRY_TIMEOUT,
+ cur_params.dot11MeshRetryTimeout) ||
+ nla_put_u16(msg, NL80211_MESHCONF_CONFIRM_TIMEOUT,
+ cur_params.dot11MeshConfirmTimeout) ||
+ nla_put_u16(msg, NL80211_MESHCONF_HOLDING_TIMEOUT,
+ cur_params.dot11MeshHoldingTimeout) ||
+ nla_put_u16(msg, NL80211_MESHCONF_MAX_PEER_LINKS,
+ cur_params.dot11MeshMaxPeerLinks) ||
+ nla_put_u8(msg, NL80211_MESHCONF_MAX_RETRIES,
+ cur_params.dot11MeshMaxRetries) ||
+ nla_put_u8(msg, NL80211_MESHCONF_TTL,
+ cur_params.dot11MeshTTL) ||
+ nla_put_u8(msg, NL80211_MESHCONF_ELEMENT_TTL,
+ cur_params.element_ttl) ||
+ nla_put_u8(msg, NL80211_MESHCONF_AUTO_OPEN_PLINKS,
+ cur_params.auto_open_plinks) ||
++ nla_put_u32(msg, NL80211_MESHCONF_SYNC_OFFSET_MAX_NEIGHBOR,
++ cur_params.dot11MeshNbrOffsetMaxNeighbor) ||
+ nla_put_u8(msg, NL80211_MESHCONF_HWMP_MAX_PREQ_RETRIES,
+ cur_params.dot11MeshHWMPmaxPREQretries) ||
+ nla_put_u32(msg, NL80211_MESHCONF_PATH_REFRESH_TIME,
+ cur_params.path_refresh_time) ||
+ nla_put_u16(msg, NL80211_MESHCONF_MIN_DISCOVERY_TIMEOUT,
+ cur_params.min_discovery_timeout) ||
+ nla_put_u32(msg, NL80211_MESHCONF_HWMP_ACTIVE_PATH_TIMEOUT,
+ cur_params.dot11MeshHWMPactivePathTimeout) ||
+ nla_put_u16(msg, NL80211_MESHCONF_HWMP_PREQ_MIN_INTERVAL,
+ cur_params.dot11MeshHWMPpreqMinInterval) ||
+ nla_put_u16(msg, NL80211_MESHCONF_HWMP_PERR_MIN_INTERVAL,
+ cur_params.dot11MeshHWMPperrMinInterval) ||
+ nla_put_u16(msg, NL80211_MESHCONF_HWMP_NET_DIAM_TRVS_TIME,
+ cur_params.dot11MeshHWMPnetDiameterTraversalTime) ||
+ nla_put_u8(msg, NL80211_MESHCONF_HWMP_ROOTMODE,
+ cur_params.dot11MeshHWMPRootMode) ||
+ nla_put_u16(msg, NL80211_MESHCONF_HWMP_RANN_INTERVAL,
+ cur_params.dot11MeshHWMPRannInterval) ||
+ nla_put_u8(msg, NL80211_MESHCONF_GATE_ANNOUNCEMENTS,
+ cur_params.dot11MeshGateAnnouncementProtocol) ||
+ nla_put_u8(msg, NL80211_MESHCONF_FORWARDING,
+ cur_params.dot11MeshForwarding) ||
+ nla_put_u32(msg, NL80211_MESHCONF_RSSI_THRESHOLD,
+ cur_params.rssi_threshold))
+ goto nla_put_failure;
nla_nest_end(msg, pinfoattr);
genlmsg_end(msg, hdr);
return genlmsg_reply(msg, info);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: Expose ltr/obff interface by sysfs
From: Hao, Xudong @ 2012-04-11 3:02 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: linux-pci@vger.kernel.org, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net, Jesse Barnes
In-Reply-To: <20120406183932.GB13473@phenom.dumpdata.com>
> But a better question is - why should this be done - especially from the guest
> which has a limited view of the machine? The machine might be running a lot of
> other requests so the OBFF inside the guest could be invalid.
>
Maybe I did not describe it clearly, the original idea is host admin can control the inode interface but not guest.
> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Saturday, April 07, 2012 2:40 AM
> To: Hao, Xudong
> Cc: linux-pci@vger.kernel.org; netdev@vger.kernel.org;
> e1000-devel@lists.sourceforge.net; Jesse Barnes
> Subject: Re: Expose ltr/obff interface by sysfs
>
> On Fri, Apr 06, 2012 at 02:43:59AM +0000, Hao, Xudong wrote:
> > Hi,
> >
> > I'm working on virtualization Xen/KVM. I saw there are ltr/obff
> enabling/disabling function in pci.c, but no called till now. I want to know if
> anybody(driver developer) are working for using it? Can driver change the LTR
> latency value dynamically?
> >
> > /*
> > LTR(Latency tolerance reporting) allows devices to send messages to the root
> complex indicating their latency tolerance for snooped & unsnooped memory
> transactions.
> > OBFF (optimized buffer flush/fill), where supported, can help improve energy
> efficiency by giving devices information about when interrupts and other
> activity will have a reduced power impact.
> > */
> >
> > One way to control ltr/obff is used by driver, however, I'm considering that in
> virtualization, how guest OS driver control them. I have an idea that expose an
> inode interface by sysfs, like "reset" inode implemented in pci-sysfs.c, so that
> system user/administrator can enable/disable ltr/obff or set latency value on
> userspace, but not limited on driver. Comments?
>
> So right now the driver inside the guest can probably see it, but can't change
> them.
> (As those requests end up being filtered).
>
> But there is nothing wrong with your changing those values from within the
> host.
>
> But a better question is - why should this be done - especially from the guest
> which has a limited view of the machine? The machine might be running a lot of
> other requests so the OBFF inside the guest could be invalid.
>
>
> >
> > < pls CC me when reply this mail, thanks >
> >
> > Best Regards,
> > Xudong Hao
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci"
> > 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 v15 04/13] arch/x86: add syscall_get_arch to syscall.h
From: Will Drewry @ 2012-04-11 3:13 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-kernel, linux-arch, linux-doc, kernel-hardening, netdev,
x86, arnd, davem, mingo, oleg, peterz, rdunlap, mcgrathr, tglx,
luto, eparis, serge.hallyn, djm, scarybeasts, indan, pmoore, akpm,
corbet, eric.dumazet, markus, coreyb, keescook
In-Reply-To: <4F6F7362.6030402@zytor.com>
On Sun, Mar 25, 2012 at 2:34 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 03/14/2012 08:11 PM, Will Drewry wrote:
>>
>> +static inline int syscall_get_arch(struct task_struct *task,
>> + struct pt_regs *regs)
>> +{
>> +#ifdef CONFIG_IA32_EMULATION
>> + /*
>> + * TS_COMPAT is set for 32-bit syscall entries and then
>> + * remains set until we return to user mode.
>> + *
>> + * TIF_IA32 tasks should always have TS_COMPAT set at
>> + * system call time.
>> + */
>> + if (task_thread_info(task)->status & TS_COMPAT)
>> + return AUDIT_ARCH_I386;
>> +#endif
>> + return AUDIT_ARCH_X86_64;
>> +}
>> #endif /* CONFIG_X86_32 */
>>
>> #endif /* _ASM_X86_SYSCALL_H */
>
> Just one FYI on this: after the x32 changes are upstream this can be
> implemented in terms of is_ia32_task().
Now that I've seen is_ia32_task(), it appears to be exactly the same as above:
(1) If we're x86_32, it's ia32
(2) If we're x86_64, ia32 == !!(status & TS_COMPAT)
(3) Otherwise, it's x86_64, including x32
Am I missing something? Should is_ia32_task(void) take a task_struct?
Right now, I don't see any reason to change the code, as posted, but
maybe I am mis-reading?
thanks!
will
^ permalink raw reply
* Re: [PATCH v15 04/13] arch/x86: add syscall_get_arch to syscall.h
From: H. Peter Anvin @ 2012-04-11 3:16 UTC (permalink / raw)
To: Will Drewry
Cc: linux-kernel, linux-arch, linux-doc, kernel-hardening, netdev,
x86, arnd, davem, mingo, oleg, peterz, rdunlap, mcgrathr, tglx,
luto, eparis, serge.hallyn, djm, scarybeasts, indan, pmoore, akpm,
corbet, eric.dumazet, markus, coreyb, keescook
In-Reply-To: <CABqD9hZgnrKFY_Wei-ysU=Dy7Og2iEemnqPvcQ14M0+vL65gHQ@mail.gmail.com>
On 04/10/2012 08:13 PM, Will Drewry wrote:
>
> Now that I've seen is_ia32_task(), it appears to be exactly the same as above:
> (1) If we're x86_32, it's ia32
> (2) If we're x86_64, ia32 == !!(status & TS_COMPAT)
> (3) Otherwise, it's x86_64, including x32
>
> Am I missing something? Should is_ia32_task(void) take a task_struct?
> Right now, I don't see any reason to change the code, as posted, but
> maybe I am mis-reading?
>
is_compat_task() is true for x32, is_ia32_task() is false.
-hpa
^ 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