* Re: extending ndo_add_rx_vxlan_port
From: Joseph Gasparakis @ 2013-10-28 21:13 UTC (permalink / raw)
To: Joseph Gasparakis
Cc: Or Gerlitz, Or Gerlitz, John Fastabend, Yan Burman, netdev,
Stephen Hemminger
In-Reply-To: <alpine.LFD.2.03.1310281322500.10719@intel.com>
On Mon, 28 Oct 2013, Joseph Gasparakis wrote:
>
>
> On Mon, 28 Oct 2013, Or Gerlitz wrote:
>
> > On Mon, Oct 28, 2013 at 7:59 PM, Joseph Gasparakis
> > > On Mon, 28 Oct 2013, Or Gerlitz wrote:
> > >> On Mon, Oct 28, 2013 at 1:44 AM, Joseph Gasparakis wrote:
> >
> > >> > VXLAN implementation is not done like VLAN. VLANs are stacked on top of
> > >> > real interfaces and what you are saying makes sense. VXLAN however is
> > >> > using ip[6]_tunnel_xmit, and this is why we need to notify all the
> > >>
> > >> As the name of the ndo you added ndo_add_rx_vxlan_port suggests -- HW
> > >> needs that for RX offloads. So basically, what I am saying is: in a
> > >> similar manner that we already program the NIC "over which" the vxlan
> > >> instance is set to listen on the multicast address which is associated
> > >> with that vxlan segement, lets give them a hint that packets arriving
> > >> on this group are vxlan ones, so they can use it for programming
> > >> steering rules.
> > >
> > > Why don't you write up some code so everyone has something to look at?
> > > Then we can see what makes sense to do in terms of the existing or new ndos.
> >
> > sure, code talks, indeed, still, looking on net-next, for the current
> > ndo there's no in tree consumer unless I miss anything, did I?
> >
> > Or.
> >
>
> I don't think you missed anything. My patches for the i40e are currently
> in our trees and making their way to netdev. It will be very soon.
>
>
Oh! And I also forgot to mention that if you want to see how it
will be used, together with the patch mentioned above that introduces
the ndos, I had added an RFC patch against ixgbe that showcases how the
driver could use them. The RFC patch was just loging the info, but the
actual talking to the HW would be vendor specific anyway.
^ permalink raw reply
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: David Miller @ 2013-10-28 21:17 UTC (permalink / raw)
To: hannes
Cc: jiri, vyasevich, netdev, kuznet, jmorris, yoshfuji, kaber,
thaller, stephen
In-Reply-To: <20131027164835.GB4714@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Sun, 27 Oct 2013 17:48:35 +0100
> A temporary address is also bound to a non-privacy public address so
> it's lifetime is determined by its lifetime (e.g. if you switch the
> network and don't receive on-link information for that prefix any
> more). NetworkManager would have to take care about that, too. It is
> just a question of what NetworkManager wants to handle itself or lets
> the kernel handle for it.
How much really needs to be in userspace to implement RFC4941?
I don't like the idea that even for a fully up and properly
functioning link, if NetworkManager wedges then critical things like
temporary address (re-)generation, will cease.
All that seems to matter is the secret used to generate the temporary
address sequence, and perhaps things like site specific lifetime
parameters. These are things userland can send to the kernel in
netlink messages.
Full disclosure that I am saying this from the perspective of someone
who believes that one of the biggest mistakes ever was allowing the
core of DHCP to be done in userspace.
Right now every ipv4 DHCP user ends up with their interface in
promiscuous mode. The DHCP client implementations are huge non-
trivial bodies of code, and getting them to adopt the changes necessary
to not put the interface in promiscuous mode is harder than pulling
teeth.
If at least the DHCP protocol communications part were in the kernel,
on the other hand, we could remove the problem quite swiftly.
This problem has existed for more than a decade, btw. There simply
exists no will to fix it properly, even after all this time, because
breaking the ice on those DHCP client code bases in userbase is hard.
So I want to see less fundamental stuff about interface configuration
and address assignment in userland, not more.
^ permalink raw reply
* Re: [PATCH 1/4 net-next] net: phy: add Generic Netlink Ethernet switch configuration API
From: Jamal Hadi Salim @ 2013-10-28 22:29 UTC (permalink / raw)
To: Florian Fainelli
Cc: Felix Fietkau, Neil Horman, John Fastabend, netdev, David Miller,
Sascha Hauer, John Crispin, Jonas Gorski, Gary Thomas,
Vlad Yasevich, Stephen Hemminger
In-Reply-To: <CAGVrzcbmsMjB78_x8MoOf4C34OMMZ-+3RBbheA0bG=r5VUi4EQ@mail.gmail.com>
On 10/27/13 14:14, Florian Fainelli wrote:
> 2013/10/27 Jamal Hadi Salim <jhs@mojatatu.com>:
>> On 10/25/13 09:01, Felix Fietkau wrote:
>>>
>
> They are yes, the only "fancy" features these switches allow is
> basically to set a given's port vlan id, which is already a huge
> improvement compared to the vendor provided firmware.
>
Nice to know that you have something better than the vendor provided
stuff.
>
> The switch does have an address learning process which is usually not
> controlled by software at all, so yes, flooding is usually the way to
> get it to the CPU.
>
Ok.
> Which exact drivers are you refering to? If we are talking about DSA
> then yes, this is correct, but it is completely Ethernet MAC driver
> agnostic.
>
Sorry - cant point you to an exact one; one that i tried to convert to
NAPI and found these issues was from Netlogic (embedded 64 bit mips),
that i think now is in the kernel proper (and someone had converted to
NAPI as well). Let me get back to you with some sample examples..
> Why would we expose the hardware switch physical ports as netdevs if
> we cannot even any control over their data-path? Unlike these
> multiport NICs, the only traffic you see and you can control is the
> one from your CPU port.
>
Not necessarily for datapath, rather for control path. If i can
pull the stats, ifconfig up/down the port, set flow control
etc - then that is a good reason to expose them.
>
> I do not really see how we could bend the existing interface (is it
> rtnetlink we are talking about or something else btw?) to expose these
> switches, maybe we could with iproute2, but still, the user-space
> interface/tool is far from being the problem here.
>
Look at the FDB API.
The user space interface as well as reusing kernel interfaces is my main
arguement.
> I don't think at any point in this discussion there was a mention that
> we do not want to change the user or kernel interface in OpenWrt
> because we have been using this for the past 5 years, on the contrary,
> if we are bringing this to a wide audience, this is to get some proper
> review and eventually change it.
>
Ok, sorry - I misinterpreted you and Felix. Like i said, if you gave me
that reason I would understand.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 4/4] wl1251: spi: add device tree support
From: Tomasz Figa @ 2013-10-28 22:38 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Kumar Gala, Sebastian Reichel, Mark Rutland, linux-doc,
Tony Lindgren, Russell King, Sachin Kamat, Ian Campbell,
Sebastian Reichel, Luciano Coelho, devicetree, Pawel Moll,
Stephen Warren, John W. Linville, Rob Herring, Bill Pemberton,
linux-omap, Greg Kroah-Hartman, linux-wireless, linux-kernel,
Felipe Balbi, Rob Landley, netdev
In-Reply-To: <FF34C626-4A49-43B1-B0AD-DC6146ABBB11@codeaurora.org>
On Monday 28 of October 2013 01:37:34 Kumar Gala wrote:
> On Oct 27, 2013, at 11:14 AM, Sebastian Reichel wrote:
> > Add device tree support for the spi variant of wl1251
> > and document the binding.
> >
> > Signed-off-by: Sebastian Reichel <sre@debian.org>
> > ---
> > .../devicetree/bindings/net/wireless/ti,wl1251.txt | 36
> > ++++++++++++++++++++++ drivers/net/wireless/ti/wl1251/spi.c
> > | 23 ++++++++++---- 2 files changed, 53 insertions(+), 6
> > deletions(-)
> > create mode 100644
> > Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
> > b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt new
> > file mode 100644
> > index 0000000..5f8a154
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
> > @@ -0,0 +1,36 @@
> > +* Texas Instruments wl1251 controller
> > +
> > +The wl1251 chip can be connected via SPI or via SDIO. The linux
> > +kernel currently only supports device tree for the SPI variant.
> > +
>
> From the binding I have no idea what this chip actually does, also we
> don't normally reference linux kernel support in bindings specs (so
> please remove it).
>
> However, what would expect the SDIO binding to look like? Or more
> specifically, how would you distinguish the SPI vs SDIO
> binding/connection? I'm wondering if the compatible should be
> something like "ti,wl1251-spi" and than the sdio can be
> "ti,wl1251-sdio"
Well, you can easily distinguish an SDIO device from an SPI device by its
parent node, but...
The binding for SDIO might require different set of properties (other than
ones inherited from generic SDIO or SPI bindings) than one for SPI. So
probably different compatible values might be justified.
Did we already have such case before? (maybe some I2C + SPI devices?)
> > +Required properties:
> > +- compatible : Should be "ti,wl1251"
>
> reg is not listed as a required prop.
It is implied by SPI bindings, but it might be a good idea to have this
stated here as well.
>
> > +- interrupts : Should contain interrupt line
> > +- interrupt-parent : Should be the phandle for the interrupt
> > + controller that services interrupts for this device
> > +- vio-supply : phandle to regulator providing VIO
> > +- power-gpio : GPIO connected to chip's PMEN pin
>
> should be vendor prefixed: ti,power-gpio
Hmm, out of curiosity, is it a rule for this kind of properties? I can see
both cases with and without prefixes when grepping for "-gpios" in
Documentation/devicetree/bindings. We should really have such things
written down somewhere.
>
> > +- For additional required properties on SPI, please consult
> > + Documentation/devicetree/bindings/spi/spi-bus.txt
> > +
> > +Optional properties:
> > +- ti,use-eeprom : If found, configuration will be loaded from eeprom.
>
> can you be a bit more specific on what cfg will be loaded. Also, is
> this property a boolean, if so how do I know which eeprom the cfg is
> loaded from (is it one that is directly connected to the wl1251?
Maybe one from ti,has-eeprom or ti,config-eeprom would be better name for
this property?
Best regards,
Tomasz
^ permalink raw reply
* [PATCH net-next] virtio_net: migrate mergeable rx buffers to page frag allocators
From: Michael Dalton @ 2013-10-28 22:44 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Eric Dumazet, Rusty Russell, Michael S. Tsirkin,
Daniel Borkmann, virtualization, Michael Dalton
The virtio_net driver's mergeable receive buffer allocator
uses 4KB packet buffers. For MTU-sized traffic, SKB truesize
is > 4KB but only ~1500 bytes of the buffer is used to store
packet data, reducing the effective TCP window size
substantially. This patch addresses the performance concerns
with mergeable receive buffers by allocating MTU-sized packet
buffers using page frag allocators. If more than MAX_SKB_FRAGS
buffers are needed, the SKB frag_list is used.
Signed-off-by: Michael Dalton <mwdalton@google.com>
---
drivers/net/virtio_net.c | 164 ++++++++++++++++++++++++++++++-----------------
1 file changed, 106 insertions(+), 58 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 9fbdfcd..113ee93 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -124,6 +124,11 @@ struct virtnet_info {
/* Lock for config space updates */
struct mutex config_lock;
+ /* Page_frag for GFP_KERNEL packet buffer allocation when we run
+ * low on memory.
+ */
+ struct page_frag alloc_frag;
+
/* Does the affinity hint is set for virtqueues? */
bool affinity_hint_set;
@@ -217,33 +222,18 @@ static void skb_xmit_done(struct virtqueue *vq)
netif_wake_subqueue(vi->dev, vq2txq(vq));
}
-static void set_skb_frag(struct sk_buff *skb, struct page *page,
- unsigned int offset, unsigned int *len)
-{
- int size = min((unsigned)PAGE_SIZE - offset, *len);
- int i = skb_shinfo(skb)->nr_frags;
-
- __skb_fill_page_desc(skb, i, page, offset, size);
-
- skb->data_len += size;
- skb->len += size;
- skb->truesize += PAGE_SIZE;
- skb_shinfo(skb)->nr_frags++;
- skb_shinfo(skb)->tx_flags |= SKBTX_SHARED_FRAG;
- *len -= size;
-}
-
/* Called from bottom half context */
static struct sk_buff *page_to_skb(struct receive_queue *rq,
- struct page *page, unsigned int len)
+ struct page *page, unsigned int offset,
+ unsigned int len, unsigned int truesize)
{
struct virtnet_info *vi = rq->vq->vdev->priv;
struct sk_buff *skb;
struct skb_vnet_hdr *hdr;
- unsigned int copy, hdr_len, offset;
+ unsigned int copy, hdr_len, hdr_padded_len;
char *p;
- p = page_address(page);
+ p = page_address(page) + offset;
/* copy small packet so we can reuse these pages for small data */
skb = netdev_alloc_skb_ip_align(vi->dev, GOOD_COPY_LEN);
@@ -254,16 +244,17 @@ static struct sk_buff *page_to_skb(struct receive_queue *rq,
if (vi->mergeable_rx_bufs) {
hdr_len = sizeof hdr->mhdr;
- offset = hdr_len;
+ hdr_padded_len = sizeof hdr->mhdr;
} else {
hdr_len = sizeof hdr->hdr;
- offset = sizeof(struct padded_vnet_hdr);
+ hdr_padded_len = sizeof(struct padded_vnet_hdr);
}
memcpy(hdr, p, hdr_len);
len -= hdr_len;
- p += offset;
+ offset += hdr_padded_len;
+ p += hdr_padded_len;
copy = len;
if (copy > skb_tailroom(skb))
@@ -273,6 +264,14 @@ static struct sk_buff *page_to_skb(struct receive_queue *rq,
len -= copy;
offset += copy;
+ if (vi->mergeable_rx_bufs) {
+ if (len)
+ skb_add_rx_frag(skb, 0, page, offset, len, truesize);
+ else
+ put_page(page);
+ return skb;
+ }
+
/*
* Verify that we can indeed put this data into a skb.
* This is here to handle cases when the device erroneously
@@ -284,9 +283,12 @@ static struct sk_buff *page_to_skb(struct receive_queue *rq,
dev_kfree_skb(skb);
return NULL;
}
-
+ BUG_ON(offset >= PAGE_SIZE);
while (len) {
- set_skb_frag(skb, page, offset, &len);
+ unsigned int frag_size = min((unsigned)PAGE_SIZE - offset, len);
+ skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, page, offset,
+ frag_size, truesize);
+ len -= frag_size;
page = (struct page *)page->private;
offset = 0;
}
@@ -297,33 +299,52 @@ static struct sk_buff *page_to_skb(struct receive_queue *rq,
return skb;
}
-static int receive_mergeable(struct receive_queue *rq, struct sk_buff *skb)
+static int receive_mergeable(struct receive_queue *rq, struct sk_buff *head_skb)
{
- struct skb_vnet_hdr *hdr = skb_vnet_hdr(skb);
+ struct skb_vnet_hdr *hdr = skb_vnet_hdr(head_skb);
+ struct sk_buff *curr_skb = head_skb;
+ char *buf;
struct page *page;
- int num_buf, i, len;
+ int num_buf, len;
num_buf = hdr->mhdr.num_buffers;
while (--num_buf) {
- i = skb_shinfo(skb)->nr_frags;
- if (i >= MAX_SKB_FRAGS) {
- pr_debug("%s: packet too long\n", skb->dev->name);
- skb->dev->stats.rx_length_errors++;
- return -EINVAL;
- }
- page = virtqueue_get_buf(rq->vq, &len);
- if (!page) {
+ int num_skb_frags = skb_shinfo(curr_skb)->nr_frags;
+ buf = virtqueue_get_buf(rq->vq, &len);
+ if (unlikely(!buf)) {
pr_debug("%s: rx error: %d buffers missing\n",
- skb->dev->name, hdr->mhdr.num_buffers);
- skb->dev->stats.rx_length_errors++;
+ head_skb->dev->name, hdr->mhdr.num_buffers);
+ head_skb->dev->stats.rx_length_errors++;
return -EINVAL;
}
-
- if (len > PAGE_SIZE)
- len = PAGE_SIZE;
-
- set_skb_frag(skb, page, 0, &len);
-
+ if (unlikely(len > MAX_PACKET_LEN)) {
+ pr_debug("%s: rx error: merge buffer too long\n",
+ head_skb->dev->name);
+ len = MAX_PACKET_LEN;
+ }
+ if (unlikely(num_skb_frags == MAX_SKB_FRAGS)) {
+ struct sk_buff *nskb = alloc_skb(0, GFP_ATOMIC);
+ if (unlikely(!nskb)) {
+ head_skb->dev->stats.rx_dropped++;
+ return -ENOMEM;
+ }
+ if (curr_skb == head_skb)
+ skb_shinfo(curr_skb)->frag_list = nskb;
+ else
+ curr_skb->next = nskb;
+ curr_skb = nskb;
+ head_skb->truesize += nskb->truesize;
+ num_skb_frags = 0;
+ }
+ if (curr_skb != head_skb) {
+ head_skb->data_len += len;
+ head_skb->len += len;
+ head_skb->truesize += MAX_PACKET_LEN;
+ }
+ page = virt_to_head_page(buf);
+ skb_add_rx_frag(curr_skb, num_skb_frags, page,
+ buf - (char *)page_address(page), len,
+ MAX_PACKET_LEN);
--rq->num;
}
return 0;
@@ -341,8 +362,10 @@ static void receive_buf(struct receive_queue *rq, void *buf, unsigned int len)
if (unlikely(len < sizeof(struct virtio_net_hdr) + ETH_HLEN)) {
pr_debug("%s: short packet %i\n", dev->name, len);
dev->stats.rx_length_errors++;
- if (vi->mergeable_rx_bufs || vi->big_packets)
+ if (vi->big_packets)
give_pages(rq, buf);
+ else if (vi->mergeable_rx_bufs)
+ put_page(virt_to_head_page(buf));
else
dev_kfree_skb(buf);
return;
@@ -352,19 +375,28 @@ static void receive_buf(struct receive_queue *rq, void *buf, unsigned int len)
skb = buf;
len -= sizeof(struct virtio_net_hdr);
skb_trim(skb, len);
+ } else if (vi->mergeable_rx_bufs) {
+ struct page *page = virt_to_head_page(buf);
+ skb = page_to_skb(rq, page,
+ (char *)buf - (char *)page_address(page),
+ len, MAX_PACKET_LEN);
+ if (unlikely(!skb)) {
+ dev->stats.rx_dropped++;
+ put_page(page);
+ return;
+ }
+ if (receive_mergeable(rq, skb)) {
+ dev_kfree_skb(skb);
+ return;
+ }
} else {
page = buf;
- skb = page_to_skb(rq, page, len);
+ skb = page_to_skb(rq, page, 0, len, PAGE_SIZE);
if (unlikely(!skb)) {
dev->stats.rx_dropped++;
give_pages(rq, page);
return;
}
- if (vi->mergeable_rx_bufs)
- if (receive_mergeable(rq, skb)) {
- dev_kfree_skb(skb);
- return;
- }
}
hdr = skb_vnet_hdr(skb);
@@ -501,18 +533,28 @@ static int add_recvbuf_big(struct receive_queue *rq, gfp_t gfp)
static int add_recvbuf_mergeable(struct receive_queue *rq, gfp_t gfp)
{
- struct page *page;
+ struct virtnet_info *vi = rq->vq->vdev->priv;
+ char *buf = NULL;
int err;
- page = get_a_page(rq, gfp);
- if (!page)
+ if (gfp & __GFP_WAIT) {
+ if (skb_page_frag_refill(MAX_PACKET_LEN, &vi->alloc_frag,
+ gfp)) {
+ buf = (char *)page_address(vi->alloc_frag.page) +
+ vi->alloc_frag.offset;
+ get_page(vi->alloc_frag.page);
+ vi->alloc_frag.offset += MAX_PACKET_LEN;
+ }
+ } else {
+ buf = netdev_alloc_frag(MAX_PACKET_LEN);
+ }
+ if (!buf)
return -ENOMEM;
- sg_init_one(rq->sg, page_address(page), PAGE_SIZE);
-
- err = virtqueue_add_inbuf(rq->vq, rq->sg, 1, page, gfp);
+ sg_init_one(rq->sg, buf, MAX_PACKET_LEN);
+ err = virtqueue_add_inbuf(rq->vq, rq->sg, 1, buf, gfp);
if (err < 0)
- give_pages(rq, page);
+ put_page(virt_to_head_page(buf));
return err;
}
@@ -1343,8 +1385,10 @@ static void free_unused_bufs(struct virtnet_info *vi)
struct virtqueue *vq = vi->rq[i].vq;
while ((buf = virtqueue_detach_unused_buf(vq)) != NULL) {
- if (vi->mergeable_rx_bufs || vi->big_packets)
+ if (vi->big_packets)
give_pages(&vi->rq[i], buf);
+ else if (vi->mergeable_rx_bufs)
+ put_page(virt_to_head_page(buf));
else
dev_kfree_skb(buf);
--vi->rq[i].num;
@@ -1650,6 +1694,8 @@ free_recv_bufs:
free_vqs:
cancel_delayed_work_sync(&vi->refill);
virtnet_del_vqs(vi);
+ if (vi->alloc_frag.page)
+ put_page(vi->alloc_frag.page);
free_index:
free_percpu(vi->vq_index);
free_stats:
@@ -1685,6 +1731,8 @@ static void virtnet_remove(struct virtio_device *vdev)
unregister_netdev(vi->dev);
remove_vq_common(vi);
+ if (vi->alloc_frag.page)
+ put_page(vi->alloc_frag.page);
flush_work(&vi->config_work);
--
1.8.4.1
^ permalink raw reply related
* Re: [PATCH 1/4 net-next] net: phy: add Generic Netlink Ethernet switch configuration API
From: Jamal Hadi Salim @ 2013-10-28 22:53 UTC (permalink / raw)
To: Felix Fietkau, Florian Fainelli, Neil Horman
Cc: John Fastabend, netdev, David Miller, Sascha Hauer, John Crispin,
Jonas Gorski, Gary Thomas, Vlad Yasevich, Stephen Hemminger,
Lennert Buytenhek
In-Reply-To: <526D6EBA.3020903@openwrt.org>
On 10/27/13 15:51, Felix Fietkau wrote:
> On 2013-10-27 6:19 PM, Jamal Hadi Salim wrote:
> That question does not make any sense to me. Aside from low level
> control frames like pause frames for flow control, the switch has no
> need to send packets to the CPU port on its own.
> Remember what I told you about the switch being a *separate* entity from
> the NIC that connects it to the CPU.
>
I am assuming there is a MAC address which is identified to be that of a
switch. Something responds to ARP for example for that MAC. I think
you are saying that for a certain class of switch chips, there is no
concept of "cpu port" - therefore there cannot be unicast from the
chip to the cpu.
> DSA does this, and last time I looked, it pushes *all* bridge traffic
> through the CPU, making it completely unusable for slower embedded CPUs.
>
I wasnt thinking DSA (rather some MIPS based embedded boards)- but now
that you bring it up, lets Cc Lennert.
> If I remember correctly, adding support 'bridge acceleration' was left
> as an exercise for the reader and never actually implemented.
>
From talking to you, I realize there are things that are dumb and
cant be "accelerated". The scenarios so far have been for accelaration
(or to be correct: offloading).
And my contention is - this is a matter of capability discovery as
advertised by the driver and as used by the user tools.
> Sure, this could be fixed somehow, but even then the model and
> assumptions that DSA is built on simply don't work for some of the
> dumber switches that we support.
>
Agreed.
[.. content removed for brevity, dont think we have disagreements ..]
> One of the currently very common switches in many embedded devices is
> the RTL8366/RTL8367. It has some flexibility when it comes to
> configuring VLANs, and it's one of the few ones where you can configure
> a forwarding table for a VLAN (which spans multiple ports), which allows
> software bridging between multiple VLANs.
> However, what this switch does *not* support is adding a header/trailer
> to packets to indicate the originating port.
> This means that all per-port netdevs will be dummy ports which don't
> include the data path.
>
My view is that netdevs are still valuable even if only they get used
for control path. Like you said earlier - you can still pull stats, flow
control messages still make it through etc. They provide you
the consistent api to configure the switch above, ex:
If i was to use the FDB api for this switch as long as i can
abstract it in software as a bridge, I could send it a switch config
via its ops which says:
"I am giving you this entry with vland 400 for port 2, but i want you to
send it to the hardware not to your local entry"
> So let's say you have a configuration where you're using VLAN ID 4 on
> port 1, and you want to bridge it to VLAN ID 400 on port 2.
>
> Sounds easy enough, you can easily create a bridge that spans port1.4
> and port2.400. Except, this particular switch (like pretty much any
> other switch supported by swconfig) isn't actually able to handle such a
> configuration on its own.
Makes sense.
Let me point that even the Linux bridge cant handle this on its own
either.
You would need two bridges instantiated. The "cpu port" (we should call
it the "L3 port" really) is implicit in the case of the bridge i.e it
is the Linux network stack.
You would need to set the vlan filters on the bridge to strip the vlan
on egress of the first bridge etc ..
> It needs two VLAN configurations, with different forwarding table IDs,
> and then the software bridge on the CPU port needs to forward between
> the two different VLANs.
> To be able to handle such a configuration, the code would have to detect
> this kind of special case scenario, somehow hook itself via rx handler
> into the NIC connected to the CPU port and emulate that VLAN ID
> replacement behavior.
>
IMO: You dont need to muck with rx handler if you used bridge
abstraction. It becomes a config issue.
> With swconfig, you create two VLANs: VLAN 4, containing CPU and port1;
> VLAN 400, containing CPU and port2. You then create a software bridge
> between eth0.4 and eth0.400 (assuming eth0 is the NIC connected to the
> switch).
>
Can we call that "L3" instead of software bridge?
It can be done if you create a Linux bridge in software per L2 table id
in your chip. Then you attach the bridge ports.
A linux bridge of the sort, assuming there's a subnet per bridge is
configured thus:
bridge-tab1: link ports {eth0:vlan4, eth1:vlan4}, subnet 1
bridge-tab2: link ports {eth0:vlan400, eth1:vlan400}, subnet 2
> In a different scenario, the code would also have to detect
> configurations that the switch isn't able to handle, e.g.: bridging
> port1.4 to eth1 and port2.4 to eth2.
> Such a configuration wouldn't work at all with such a switch, because
> the CPU isn't able to tell apart traffic from port1 and port2, and
> there's no way to tell the switch that port1.4 and port2.4 should not be
> connected to each other, but both should go to the CPU.
>
Understood.
I think that discovery is a must - so you can apply different behavior
to different switches.
But you seem to have solved this already. Linux as is does not.
You can either have the driver tell you what it can/cant do or you
can attempt to fire and miss and get a return code that will tell
you that it cant achieve what you are asking it to do. I prefer the
former.
>
> Those are just two simple scenarios from the top of my head - I'm pretty
> sure I could come up with a long list of further corner cases and
> quirks, which are simply either difficult to deal with, or completely
> unnatural in the model that you're describing.
>
I think these are the kind of things that need to be enumerated to come
to some conclusion.
> Trying to make all of these cases work in the code will make the whole
> thing a lot more difficult to deal with and maintain. It will also make
> it much harder for the user to figure out, what configurations work, and
> what configurations don't.
>
>
> Especially the case with reusing VLANs on different ports (but not
> connecting them to each other) is something that can easily work with
> software devices, but cannot be emulated on most embedded device
> switches. The software bridge configuration model raises a lot of
> expectations that these switches simply cannot meet.
>
I wouldnt expect every thing a software bridge does would be met by
a random switch.S/w bridge would be the super-set. But this is
not a new concept, example: Netdev itself is an abstraction - we have
USB, ethernet, wireless, variety of virtual interfaces etc.
Sometimes we dont even have the concept of a "link" in some of these
devices; infiniband would have a huge MAC address but i can still
use ifconfig on it etc.
> If you look at the swconfig model, you will see that the abstraction
> clearly communicates the limitations of these typical switches.
>
I will have to go back and look - but like i said earlier seems to me
you have solved this problem. Of the switch hardware i am familiar with
(high end pricey stuff), the capabilities tend to fall into the
following components:
-flooding control (i.e what should happen on destination failure)
-learning control (i.e what should happen on the source lookup failure)
(Ive seen knobs for "drop", "send to portX" where "X" could be cpu etc)
-fdb capacity
-whether it can do vlans, filtering pvids etc
-multicast snooping capability
To add to the above a few more based on talking to you:
- cpu port (in what ive come across this is always present, but
as you point out this cannot be assumed)
- ingress port tag (you point out that some cases this may never be
present even when the cpu port is present)
- ive never seen table id, but i think this is another one; in which
case the number of table ids becomes something one needs to discover..
cheers,
jamal
> The configuration model simply doesn't even let you express these kinds
> of unsuppported configurations that seem normal in the tools used to set
> up software bridges/vlans.
> At the same time, it's fairly consistent across the range of different
> chips that we have drivers for. That certainly leaves a much smaller
> amount of traps and surprises for users, compared to trying to emulate
> the software bridge model by hacking through the layers.
>
> Hopefully this will clear a few things up for you.
>
> - Felix
>
^ permalink raw reply
* Re: [PATCH 0/2] net_sched: Remove broken tc actions
From: Jamal Hadi Salim @ 2013-10-28 22:57 UTC (permalink / raw)
To: Alexander Duyck
Cc: Eric W. Biederman, David Miller, netdev, alexander.h.duyck
In-Reply-To: <526D799C.9050905@gmail.com>
On 10/27/13 16:37, Alexander Duyck wrote:
> The primary use case for act_skbedit was to have it associated with a
> filter. I based it off of act_simple so it isn't surprising that it
> inherited this issue.
Thats almost 100% of the use cases.
>
> From what I can tell all of the other actions are just using
> tcf_hash_search for lookup. Is there anything special that is needed in
> order to add the lookup call, or could we just add a one liner
> associating simple and skbedit lookup with tcf_hash_search?
>
Yes, that would do it. But dont bother - let me just send a generic
patch that will assume that for any other action that doesnt do it.
Will do it likely tomorow.
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: Dan Williams @ 2013-10-28 23:16 UTC (permalink / raw)
To: David Miller
Cc: hannes, jiri, vyasevich, netdev, kuznet, jmorris, yoshfuji, kaber,
thaller, stephen
In-Reply-To: <20131028.171725.1076499130782328273.davem@davemloft.net>
On Mon, 2013-10-28 at 17:17 -0400, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Sun, 27 Oct 2013 17:48:35 +0100
>
> > A temporary address is also bound to a non-privacy public address so
> > it's lifetime is determined by its lifetime (e.g. if you switch the
> > network and don't receive on-link information for that prefix any
> > more). NetworkManager would have to take care about that, too. It is
> > just a question of what NetworkManager wants to handle itself or lets
> > the kernel handle for it.
>
> How much really needs to be in userspace to implement RFC4941?
>
> I don't like the idea that even for a fully up and properly
> functioning link, if NetworkManager wedges then critical things like
> temporary address (re-)generation, will cease.
Honestly, I'd be completely happy to leave temporary address handling up
to the kernel and *not* do it in userspace; the kernel already has all
the code. There are two problems with that though, (a) it's tied to
in-kernel RA handling, and (b) it's controlled by a CONFIG option. Both
these are solvable.
First off, what's the reasoning behind having IPv6 privacy as a config
option? It's off-by-default and must be explicitly turned on, so is
there any harm in removing the config? Or is it just for
smallest-kernel-ever folks?
Would a new IFA_F_MANAGE_TEMP (or better name) work here, indicating
that for some new static address, that the kernel should create and
manage the temporary privacy addresses associated with its prefix?
Dan
> All that seems to matter is the secret used to generate the temporary
> address sequence, and perhaps things like site specific lifetime
> parameters. These are things userland can send to the kernel in
> netlink messages.
>
> Full disclosure that I am saying this from the perspective of someone
> who believes that one of the biggest mistakes ever was allowing the
> core of DHCP to be done in userspace.
>
> Right now every ipv4 DHCP user ends up with their interface in
> promiscuous mode. The DHCP client implementations are huge non-
> trivial bodies of code, and getting them to adopt the changes necessary
> to not put the interface in promiscuous mode is harder than pulling
> teeth.
>
> If at least the DHCP protocol communications part were in the kernel,
> on the other hand, we could remove the problem quite swiftly.
>
> This problem has existed for more than a decade, btw. There simply
> exists no will to fix it properly, even after all this time, because
> breaking the ice on those DHCP client code bases in userbase is hard.
>
> So I want to see less fundamental stuff about interface configuration
> and address assignment in userland, not more.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: migrate mergeable rx buffers to page frag allocators
From: Eric Dumazet @ 2013-10-28 23:19 UTC (permalink / raw)
To: Michael Dalton
Cc: Francesco Fusco, Michael S. Tsirkin, netdev, Daniel Borkmann,
virtualization, Eric Dumazet, David S. Miller
In-Reply-To: <1383000258-1458-1-git-send-email-mwdalton@google.com>
On Mon, 2013-10-28 at 15:44 -0700, Michael Dalton wrote:
> The virtio_net driver's mergeable receive buffer allocator
> uses 4KB packet buffers. For MTU-sized traffic, SKB truesize
> is > 4KB but only ~1500 bytes of the buffer is used to store
> packet data, reducing the effective TCP window size
> substantially. This patch addresses the performance concerns
> with mergeable receive buffers by allocating MTU-sized packet
> buffers using page frag allocators. If more than MAX_SKB_FRAGS
> buffers are needed, the SKB frag_list is used.
>
> Signed-off-by: Michael Dalton <mwdalton@google.com>
> ---
Signed-off-by: Eric Dumazet <edumazet@google.com>
Daniel & Francesco, this should address the performance problem you
tried to address with ("tcp: rcvbuf autotuning improvements")
( http://www.spinics.net/lists/netdev/msg252642.html )
Thanks !
^ permalink raw reply
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: Dan Williams @ 2013-10-28 23:23 UTC (permalink / raw)
To: David Miller
Cc: hannes, jiri, vyasevich, netdev, kuznet, jmorris, yoshfuji, kaber,
thaller, stephen
In-Reply-To: <1383002179.28991.14.camel@dcbw.foobar.com>
On Mon, 2013-10-28 at 18:16 -0500, Dan Williams wrote:
> On Mon, 2013-10-28 at 17:17 -0400, David Miller wrote:
> > From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > Date: Sun, 27 Oct 2013 17:48:35 +0100
> >
> > > A temporary address is also bound to a non-privacy public address so
> > > it's lifetime is determined by its lifetime (e.g. if you switch the
> > > network and don't receive on-link information for that prefix any
> > > more). NetworkManager would have to take care about that, too. It is
> > > just a question of what NetworkManager wants to handle itself or lets
> > > the kernel handle for it.
> >
> > How much really needs to be in userspace to implement RFC4941?
> >
> > I don't like the idea that even for a fully up and properly
> > functioning link, if NetworkManager wedges then critical things like
> > temporary address (re-)generation, will cease.
>
> Honestly, I'd be completely happy to leave temporary address handling up
> to the kernel and *not* do it in userspace; the kernel already has all
> the code. There are two problems with that though, (a) it's tied to
> in-kernel RA handling, and (b) it's controlled by a CONFIG option. Both
> these are solvable.
>
> First off, what's the reasoning behind having IPv6 privacy as a config
> option? It's off-by-default and must be explicitly turned on, so is
> there any harm in removing the config? Or is it just for
> smallest-kernel-ever folks?
>
> Would a new IFA_F_MANAGE_TEMP (or better name) work here, indicating
> that for some new static address, that the kernel should create and
> manage the temporary privacy addresses associated with its prefix?
Except that we've run out of IFA_F_* flags already, since it's a u8 and
there are already 8 flags. What to do?
Dan
> Dan
>
> > All that seems to matter is the secret used to generate the temporary
> > address sequence, and perhaps things like site specific lifetime
> > parameters. These are things userland can send to the kernel in
> > netlink messages.
> >
> > Full disclosure that I am saying this from the perspective of someone
> > who believes that one of the biggest mistakes ever was allowing the
> > core of DHCP to be done in userspace.
> >
> > Right now every ipv4 DHCP user ends up with their interface in
> > promiscuous mode. The DHCP client implementations are huge non-
> > trivial bodies of code, and getting them to adopt the changes necessary
> > to not put the interface in promiscuous mode is harder than pulling
> > teeth.
> >
> > If at least the DHCP protocol communications part were in the kernel,
> > on the other hand, we could remove the problem quite swiftly.
> >
> > This problem has existed for more than a decade, btw. There simply
> > exists no will to fix it properly, even after all this time, because
> > breaking the ice on those DHCP client code bases in userbase is hard.
> >
> > So I want to see less fundamental stuff about interface configuration
> > and address assignment in userland, not more.
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/4] wl1251: move power GPIO handling into the driver
From: Sebastian Reichel @ 2013-10-28 23:26 UTC (permalink / raw)
To: Mark Brown
Cc: Grazvydas Ignotas, Alexander Shiyan, Luciano Coelho, Mark Rutland,
devicetree, Russell King, Pawel Moll, Ian Campbell, Tony Lindgren,
Greg Kroah-Hartman, Stephen Warren, linux-doc, John W. Linville,
Rob Herring, linux-kernel@vger.kernel.org, Sachin Kamat,
Bill Pemberton, Felipe Balbi, Rob Landley, netdev,
linux-wireless@vger.kernel.org, linux-omap@vger.kernel.org
In-Reply-To: <20131028192354.GA18208@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]
Hi,
On Mon, Oct 28, 2013 at 12:23:54PM -0700, Mark Brown wrote:
> On Mon, Oct 28, 2013 at 07:29:52PM +0200, Grazvydas Ignotas wrote:
>
> > When wl12xx family of chips is connected through SDIO, we already have
> > that pin set up as a regulator controlled with the help of mmc
> > subsystem. When time comes to communicate with the chip, mmc subsystem
> > sees this as yet another SD card and looks for associated regulator
> > for it, and the board file has that set up as a fixed regulator
> > controlling that pin (see pandora_vmmc3 in
> > arch/arm/mach-omap2/board-omap3pandora.c). To prevent poweroff after
> > first SDIO communications are over, pm_runtime calls are used in
> > drivers/net/wireless/ti/wl1251/sdio.c .
>
> Is this actually controlling VMMC though, or is it some other control?
> If it's not controlling VMMC then it shouldn't say that it is.
>
> > I don't know if something similar can be done done in SPI case, but
> > I'm sure this is not the first your-so-called regulator misuse.
>
> It's not the first but that doesn't make controlling something other
> than a regulator through the regulator API any less broken.
I gave it a second try to find out details for this pin:
1. The pin is named PMEN in the Nokia N900 schematics
2. PMEN is described as "Power management enable - system shutdown"
in a crippled datasheet of the wl1253, which I found in the internet.
I don't think this is supposed to be handled by the regulator API.
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH NEXT] rtlwifi: Fix endian error in extracting packet type
From: Larry Finger @ 2013-10-28 23:28 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Mark Cave-Ayland, netdev, Larry Finger, Stable
From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
All of the rtlwifi drivers have an error in the routine that tests if
the received data is "special". The 16-bit quantity is big-endian, but
was being extracted in native CPU mode. One of the effects of this bug
is to inhibit association under some conditions.
A statement that would have made the code correct had been changed to
a comment. Rather than just reinstating that code, the fix here passes
sparse tests.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: Stable <stable@vger.kernel.org> [2.6.38+]
---
drivers/net/wireless/rtlwifi/base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/base.c b/drivers/net/wireless/rtlwifi/base.c
index 9a78e3d..1efde7f 100644
--- a/drivers/net/wireless/rtlwifi/base.c
+++ b/drivers/net/wireless/rtlwifi/base.c
@@ -1077,8 +1077,8 @@ u8 rtl_is_special_data(struct ieee80211_hw *hw, struct sk_buff *skb, u8 is_tx)
ip = (struct iphdr *)((u8 *) skb->data + mac_hdr_len +
SNAP_SIZE + PROTOC_TYPE_SIZE);
- ether_type = *(u16 *) ((u8 *) skb->data + mac_hdr_len + SNAP_SIZE);
- /* ether_type = ntohs(ether_type); */
+ ether_type = be16_to_cpu(*(__be16 *)((u8 *)skb->data + mac_hdr_len +
+ SNAP_SIZE));
if (ETH_P_IP == ether_type) {
if (IPPROTO_UDP == ip->protocol) {
--
1.8.4
^ permalink raw reply related
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: Hannes Frederic Sowa @ 2013-10-28 23:31 UTC (permalink / raw)
To: David Miller
Cc: jiri, vyasevich, netdev, kuznet, jmorris, yoshfuji, kaber,
thaller, stephen
In-Reply-To: <20131028.171725.1076499130782328273.davem@davemloft.net>
On Mon, Oct 28, 2013 at 05:17:25PM -0400, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Sun, 27 Oct 2013 17:48:35 +0100
>
> > A temporary address is also bound to a non-privacy public address so
> > it's lifetime is determined by its lifetime (e.g. if you switch the
> > network and don't receive on-link information for that prefix any
> > more). NetworkManager would have to take care about that, too. It is
> > just a question of what NetworkManager wants to handle itself or lets
> > the kernel handle for it.
>
> How much really needs to be in userspace to implement RFC4941?
First off, I am not part of the NetworkManager community and don't know
their plans how and what features they want to implement. But I researched
and guess a bit. Maybe Jiri can jump in and provide links and details?
Currently we are pretty fine with our in-kernel implementation of RFC
4941. We may not have some features the RFC requires, like choosing if
we use the privacy address on a per-prefix basis. We only distinguish
per interface. But it is used by people and doing fine, I guess.
> I don't like the idea that even for a fully up and properly
> functioning link, if NetworkManager wedges then critical things like
> temporary address (re-)generation, will cease.
I am totally d'accord. It is essential that regeneration does not stop
under any circumstances.
> All that seems to matter is the secret used to generate the temporary
> address sequence, and perhaps things like site specific lifetime
> parameters. These are things userland can send to the kernel in
> netlink messages.
RFC 4941 does not dictate per se the use of a stable secret key. It is
currently generated in the kernel. If NM wants to provide a way to have
a stable key, I agree, it should be provided via netlink (maybe Nicolas
work on the netconf api could be extended for that).
I found this bug: <https://bugzilla.gnome.org/show_bug.cgi?id=705170#c2>
It does not seem to mention stable keys, so I guess it is not on
their radar. The comment I referenced talked about fixing the kernel
interface but I did not find any pointers what is wrong with it? There was
discussion that the /all/use_tempaddr should enable privacy extensions
globally on all interfaces even if they were running at that point:
http://patchwork.ozlabs.org/patch/131911/ (it got rejected). If something
like this is needed I guess we could provide such a setting. But as
NM has to have state on all interfaces I don't see a particular reason
they would need this.
I don't follow netdev closely that long so maybe I missed a lot of the
discussions that maybe took place about this.
> Full disclosure that I am saying this from the perspective of someone
> who believes that one of the biggest mistakes ever was allowing the
> core of DHCP to be done in userspace.
*nod*
> Right now every ipv4 DHCP user ends up with their interface in
> promiscuous mode. The DHCP client implementations are huge non-
> trivial bodies of code, and getting them to adopt the changes necessary
> to not put the interface in promiscuous mode is harder than pulling
> teeth.
> If at least the DHCP protocol communications part were in the kernel,
> on the other hand, we could remove the problem quite swiftly.
>
> This problem has existed for more than a decade, btw. There simply
> exists no will to fix it properly, even after all this time, because
> breaking the ice on those DHCP client code bases in userbase is hard.
I wonder why NetworkManager rewrote IPv6 router discovery but not IPv4
DHCP client stuff. It could have been a good moment to introduce something
like PROT_DHCP sockets. Maybe it is not too late... ;)
> So I want to see less fundamental stuff about interface configuration
> and address assignment in userland, not more.
I agree and don't think the kernel is that bad at it. If bugs pop up I'll
certainly will have a look at them. ;-)
Off-topic:
Down the road there may be the deprecation of EUI-64 (ipv6 address generation
based on the MAC address). It will be replaced by an approach to have an
install-time secret key which will used like this:
RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, stable_secret_key)
(network_id is something like the essid of the wlan etc.; F some hashing
function)
It should be used for link-local addresses as well as SLAAC:
<http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-14>
So we should design the interfaces generic enough to cope with that. This
will have some implications: we need link-local address early in boot-up
because of the bind() of early boot-up daemons or even network booting,
mld etc.
My current idea to handle this, is that a kernel boot parameter is
provided to stop the generation of link-local addresses and that we kick
off address configuration from user-space at early as the secret key is
provided, which may well be from the initramfs. I'll send a RFC as soon
as I can find some time to clean it up and have it actually tested.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH 03/16] wl1251: add sysfs interface for bluetooth coexistence mode configuration
From: Ben Hutchings @ 2013-10-28 23:39 UTC (permalink / raw)
To: Pali Rohár
Cc: Luciano Coelho, John W. Linville, Johannes Berg, David S. Miller,
linux-wireless, netdev, linux-kernel, freemangordon,
aaro.koskinen, pavel, sre, joni.lapilainen, David Gnedt
In-Reply-To: <1382819655-30430-4-git-send-email-pali.rohar@gmail.com>
On Sat, 2013-10-26 at 22:34 +0200, Pali Rohár wrote:
> From: David Gnedt <david.gnedt@davizone.at>
>
> Port the bt_coex_mode sysfs interface from wl1251 driver version included
> in the Maemo Fremantle kernel to allow bt-coexistence mode configuration.
> This enables userspace applications to set one of the modes
> WL1251_BT_COEX_OFF, WL1251_BT_COEX_ENABLE and WL1251_BT_COEX_MONOAUDIO.
> The default mode is WL1251_BT_COEX_OFF.
> It should be noted that this driver always enabled bt-coexistence before
> and enabled bt-coexistence directly affects the receiving performance,
> rendering it unusable in some low-signal situations. Especially monitor
> mode is affected very badly with bt-coexistence enabled.
[...]
This should be implemented consistently with other drivers:
drivers/net/wireless/ath/ath9k/htc_drv_init.c:module_param_named(btcoex_enable, ath9k_htc_btcoex_enable, int, 0444);
drivers/net/wireless/ath/ath9k/init.c:module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444);
drivers/net/wireless/b43/main.c:module_param_named(btcoex, modparam_btcoex, int, 0444);
drivers/net/wireless/ipw2x00/ipw2200.c:module_param(bt_coexist, int, 0444);
drivers/net/wireless/iwlegacy/common.c:module_param(bt_coex_active, bool, S_IRUGO);
drivers/net/wireless/iwlwifi/iwl-drv.c:module_param_named(bt_coex_active, iwlwifi_mod_params.bt_coex_active,
drivers/net/wireless/ti/wlcore/sysfs.c:static DEVICE_ATTR(bt_coex_state, S_IRUGO | S_IWUSR,
Oh, hmm, I see a problem here.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
From: Laurent Pinchart @ 2013-10-28 23:46 UTC (permalink / raw)
To: linux-sh
Cc: linux-fbdev, Wolfram Sang, Linus Walleij, Guennadi Liakhovetski,
Thierry Reding, linux-mtd, linux-i2c, Vinod Koul, Joerg Roedel,
Magnus Damm, Eduardo Valentin, Tomi Valkeinen, linux-serial,
linux-input, Zhang Rui, Chris Ball,
Jean-Christophe Plagniol-Villard, linux-media, linux-pwm,
Samuel Ortiz, linux-pm, Ian Molton, Mark Brown, linux-arm-kernel,
Sergei Shtylyov <sergei.shtyly
Hello,
This patch series, based on v3.12-rc7, prepares various Renesas drivers
for migration to multiplatform kernels by enabling their compilation or
otherwise fixing them on all ARM platforms. The patches are pretty
straightforward and are described in their commit message.
I'd like to get all these patches merged in v3.14. As they will need to go
through their respective subsystems' trees, I would appreciate if all
maintainers involved could notify me when they merge patches from this series
in their tree to help me tracking the merge status. I don't plan to send pull
requests individually for these patches, and I will repost patches
individually if changes are requested during review.
If you believe the issue should be solved in a different way (for instance by
removing the architecture dependency completely) please reply to the cover
letter to let other maintainers chime in.
Cc: Chris Ball <cjb@laptop.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: dmaengine@vger.kernel.org
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Eduardo Valentin <eduardo.valentin@ti.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
Cc: Ian Molton <ian@mnementh.co.uk>
Cc: iommu@lists.linux-foundation.org
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-i2c@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-media@vger.kernel.org
Cc: linux-mmc@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-pm@vger.kernel.org
Cc: linux-pwm@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-spi@vger.kernel.org
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: netdev@vger.kernel.org
Cc: Samuel Ortiz <samuel@sortiz.org>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Zhang Rui <rui.zhang@intel.com>
Laurent Pinchart (19):
serial: sh-sci: Enable the driver on all ARM platforms
DMA: shdma: Enable the driver on all ARM platforms
i2c: sh_mobile: Enable the driver on all ARM platforms
input: sh_keysc: Enable the driver on all ARM platforms
iommu: shmobile: Enable the driver on all ARM platforms
i2c: rcar: Enable the driver on all ARM platforms
v4l: sh_vou: Enable the driver on all ARM platforms
mmc: sdhi: Enable the driver on all ARM platforms
mmc: sh_mmcif: Enable the driver on all ARM platforms
mtd: sh_flctl: Enable the driver on all ARM platforms
net: sh_eth: Set receive alignment correctly on all ARM platforms
irda: sh_irda: Enable the driver on all ARM platforms
pinctrl: sh-pfc: Enable the driver on all ARM platforms
pwm: pwm-renesas-tpu: Enable the driver on all ARM platforms
sh: intc: Enable the driver on all ARM platforms
spi: sh_msiof: Enable the driver on all ARM platforms
spi: sh_hspi: Enable the driver on all ARM platforms
thermal: rcar-thermal: Enable the driver on all ARM platforms
fbdev: sh-mobile-lcdcfb: Enable the driver on all ARM platforms
drivers/dma/sh/Kconfig | 2 +-
drivers/dma/sh/shdmac.c | 6 +++---
drivers/i2c/busses/Kconfig | 4 ++--
drivers/input/keyboard/Kconfig | 2 +-
drivers/iommu/Kconfig | 2 +-
drivers/media/platform/Kconfig | 2 +-
drivers/mmc/host/Kconfig | 4 ++--
drivers/mmc/host/tmio_mmc_dma.c | 2 +-
drivers/mtd/nand/Kconfig | 2 +-
drivers/net/ethernet/renesas/sh_eth.c | 2 +-
drivers/net/ethernet/renesas/sh_eth.h | 2 +-
drivers/net/irda/Kconfig | 2 +-
drivers/pinctrl/Makefile | 2 +-
drivers/pinctrl/sh-pfc/Kconfig | 2 +-
drivers/pwm/Kconfig | 2 +-
drivers/sh/intc/Kconfig | 2 +-
drivers/spi/Kconfig | 4 ++--
drivers/thermal/Kconfig | 2 +-
drivers/tty/serial/Kconfig | 2 +-
drivers/video/Kconfig | 6 +++---
20 files changed, 27 insertions(+), 27 deletions(-)
--
Regards,
Laurent Pinchart
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [PATCH 11/19] net: sh_eth: Set receive alignment correctly on all ARM platforms
From: Laurent Pinchart @ 2013-10-28 23:46 UTC (permalink / raw)
To: linux-sh; +Cc: linux-arm-kernel, David S. Miller, Sergei Shtylyov, netdev
In-Reply-To: <1383004027-25036-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Renesas ARM platforms are transitioning from single-platform to
multi-platform kernels using the new ARCH_SHMOBILE_MULTI. Configure the
receive alignement correctly on all ARM platforms to enable the driver
on both ARCH_SHMOBILE and ARCH_SHMOBILE_MULTI.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 2 +-
drivers/net/ethernet/renesas/sh_eth.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index b57c278..990fd5b 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -809,7 +809,7 @@ out:
return ret;
}
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
+#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARM)
static void sh_eth_set_receive_align(struct sk_buff *skb)
{
int reserve;
diff --git a/drivers/net/ethernet/renesas/sh_eth.h b/drivers/net/ethernet/renesas/sh_eth.h
index a0db02c..41509f7 100644
--- a/drivers/net/ethernet/renesas/sh_eth.h
+++ b/drivers/net/ethernet/renesas/sh_eth.h
@@ -165,7 +165,7 @@ enum {
};
/* Driver's parameters */
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
+#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARM)
#define SH4_SKB_RX_ALIGN 32
#else
#define SH2_SH3_SKB_RX_ALIGN 2
--
1.8.1.5
^ permalink raw reply related
* [PATCH 12/19] irda: sh_irda: Enable the driver on all ARM platforms
From: Laurent Pinchart @ 2013-10-28 23:47 UTC (permalink / raw)
To: linux-sh; +Cc: linux-arm-kernel, Samuel Ortiz, netdev
In-Reply-To: <1383004027-25036-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Renesas ARM platforms are transitioning from single-platform to
multi-platform kernels using the new ARCH_SHMOBILE_MULTI. Make the
driver available on all ARM platforms to enable it on both ARCH_SHMOBILE
and ARCH_SHMOBILE_MULTI and increase build testing coverage.
Cc: Samuel Ortiz <samuel@sortiz.org>
Cc: netdev@vger.kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
drivers/net/irda/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/irda/Kconfig b/drivers/net/irda/Kconfig
index 2a30193..54b4101 100644
--- a/drivers/net/irda/Kconfig
+++ b/drivers/net/irda/Kconfig
@@ -403,7 +403,7 @@ config MCS_FIR
config SH_IRDA
tristate "SuperH IrDA driver"
- depends on IRDA && ARCH_SHMOBILE
+ depends on IRDA && ARM
help
Say Y here if your want to enable SuperH IrDA devices.
--
1.8.1.5
^ permalink raw reply related
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: Hannes Frederic Sowa @ 2013-10-28 23:48 UTC (permalink / raw)
To: Dan Williams
Cc: David Miller, jiri, vyasevich, netdev, kuznet, jmorris, yoshfuji,
kaber, thaller, stephen
In-Reply-To: <1383002179.28991.14.camel@dcbw.foobar.com>
On Mon, Oct 28, 2013 at 06:16:19PM -0500, Dan Williams wrote:
> On Mon, 2013-10-28 at 17:17 -0400, David Miller wrote:
> > From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > Date: Sun, 27 Oct 2013 17:48:35 +0100
> >
> > > A temporary address is also bound to a non-privacy public address so
> > > it's lifetime is determined by its lifetime (e.g. if you switch the
> > > network and don't receive on-link information for that prefix any
> > > more). NetworkManager would have to take care about that, too. It is
> > > just a question of what NetworkManager wants to handle itself or lets
> > > the kernel handle for it.
> >
> > How much really needs to be in userspace to implement RFC4941?
> >
> > I don't like the idea that even for a fully up and properly
> > functioning link, if NetworkManager wedges then critical things like
> > temporary address (re-)generation, will cease.
>
> Honestly, I'd be completely happy to leave temporary address handling up
> to the kernel and *not* do it in userspace; the kernel already has all
> the code. There are two problems with that though, (a) it's tied to
> in-kernel RA handling, and (b) it's controlled by a CONFIG option. Both
> these are solvable.
Ah, (a) does complicate things, I agree. But the tieing is essential
currently. So it seems a netlink interface would be needed to tie a new
address to an already installed one, if the kernel should still deal
with the regeneration?
> First off, what's the reasoning behind having IPv6 privacy as a config
> option? It's off-by-default and must be explicitly turned on, so is
> there any harm in removing the config? Or is it just for
> smallest-kernel-ever folks?
I don't know about the policy. Does it really matter as distributions
normally switch it on? But I would not like to see the option removed
entirly, maybe the default could be changed.
> Would a new IFA_F_MANAGE_TEMP (or better name) work here, indicating
> that for some new static address, that the kernel should create and
> manage the temporary privacy addresses associated with its prefix?
But this would only be needed if they were managed in user-space, no?
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH net-next v3 0/5] 6lowpan: trivial changes
From: David Miller @ 2013-10-28 23:48 UTC (permalink / raw)
To: alex.aring
Cc: alex.bluesman.smirnov, linux-zigbee-devel, werner, dbaryshkov,
netdev
In-Reply-To: <1382952260-23174-1-git-send-email-alex.aring@gmail.com>
From: Alexander Aring <alex.aring@gmail.com>
Date: Mon, 28 Oct 2013 10:24:15 +0100
> This patch series includes some trivial changes to prepare the 6lowpan stack
> for upcomming patch-series which mainly fix fragmentation according to rfc4944
> and udp handling(which is currently broken).
>
> Changes since v3:
> - really fix intendation in patch 3/5
>
> Changes since v2:
> - change intendation in patch 3/5
> - fix typo in 5/5 unecessary -> unnecessary
> - add missing 6lowpan tag in cover-letter
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 16/16] wl1251: Add sysfs file address for setting permanent mac address
From: Ben Hutchings @ 2013-10-28 23:50 UTC (permalink / raw)
To: Pali Rohár
Cc: Luciano Coelho, John W. Linville, Johannes Berg, David S. Miller,
linux-wireless, netdev, linux-kernel, freemangordon,
aaro.koskinen, pavel, sre, joni.lapilainen
In-Reply-To: <1382819655-30430-17-git-send-email-pali.rohar@gmail.com>
On Sat, 2013-10-26 at 22:34 +0200, Pali Rohár wrote:
> Driver wl1251 generating mac address randomly at startup and there is no way to
> set permanent mac address via SET_IEEE80211_PERM_ADDR. This patch export sysfs
> file which can set permanent mac address by userspace helper program. Patch is
> needed for devices which do not store mac address in internal wl1251 eeprom.
[...]
This belongs in struct wl12xx_platform_data or (better) Device Tree
properties. It definitely should not be settable once the device is
registered.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH NEXT] rtlwifi: Fix endian error in extracting packet type
From: Ben Hutchings @ 2013-10-29 0:07 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless, Mark Cave-Ayland, netdev, Stable
In-Reply-To: <1383002903-8746-1-git-send-email-Larry.Finger@lwfinger.net>
On Mon, 2013-10-28 at 18:28 -0500, Larry Finger wrote:
> From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
>
> All of the rtlwifi drivers have an error in the routine that tests if
> the received data is "special". The 16-bit quantity is big-endian, but
> was being extracted in native CPU mode. One of the effects of this bug
> is to inhibit association under some conditions.
>
> A statement that would have made the code correct had been changed to
> a comment. Rather than just reinstating that code, the fix here passes
> sparse tests.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
> Cc: Stable <stable@vger.kernel.org> [2.6.38+]
> ---
> drivers/net/wireless/rtlwifi/base.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> diff --git a/drivers/net/wireless/rtlwifi/base.c b/drivers/net/wireless/rtlwifi/base.c
> index 9a78e3d..1efde7f 100644
> --- a/drivers/net/wireless/rtlwifi/base.c
> +++ b/drivers/net/wireless/rtlwifi/base.c
> @@ -1077,8 +1077,8 @@ u8 rtl_is_special_data(struct ieee80211_hw *hw, struct sk_buff *skb, u8 is_tx)
>
> ip = (struct iphdr *)((u8 *) skb->data + mac_hdr_len +
> SNAP_SIZE + PROTOC_TYPE_SIZE);
> - ether_type = *(u16 *) ((u8 *) skb->data + mac_hdr_len + SNAP_SIZE);
> - /* ether_type = ntohs(ether_type); */
> + ether_type = be16_to_cpu(*(__be16 *)((u8 *)skb->data + mac_hdr_len +
> + SNAP_SIZE));
>
> if (ETH_P_IP == ether_type) {
> if (IPPROTO_UDP == ip->protocol) {
This crazy function also says that *all* IPv6 frames are special, which
apparently means that on TX they should get sent at the lowest possible
bit rate. So I think this is going to cause a regression for IPv6
throughput unless you remove that case.
The DHCP case is also not validating IP and UDP header lengths against
the packet length, though this may be harmless in practice.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: David Miller @ 2013-10-29 0:08 UTC (permalink / raw)
To: dcbw
Cc: hannes, jiri, vyasevich, netdev, kuznet, jmorris, yoshfuji, kaber,
thaller, stephen
In-Reply-To: <1383002179.28991.14.camel@dcbw.foobar.com>
From: Dan Williams <dcbw@redhat.com>
Date: Mon, 28 Oct 2013 18:16:19 -0500
> On Mon, 2013-10-28 at 17:17 -0400, David Miller wrote:
> First off, what's the reasoning behind having IPv6 privacy as a config
> option? It's off-by-default and must be explicitly turned on, so is
> there any harm in removing the config? Or is it just for
> smallest-kernel-ever folks?
I think it's for "smallest kernel ever" stuff. Even every arch
defconfig that mentions it has it enabled :-)
Maybe it was optional initially because the code was new and
experimental'ish. I don't know.
Regardless of the reason I think it only obfuscates the code with
ifdefs right now and I would be happy to see it disappear.
Any objections to this patch?
====================
[PATCH] ipv6: Remove privacy config option.
The code for privacy extentions is very mature, and making it
configurable only gives marginal memory/code savings in exchange
for obfuscation and hard to read code via CPP ifdef'ery.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/linux/ipv6.h | 2 --
include/net/if_inet6.h | 5 +----
net/ipv6/Kconfig | 18 ------------------
net/ipv6/addrconf.c | 41 +++--------------------------------------
4 files changed, 4 insertions(+), 62 deletions(-)
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index a80a63c..5d89d1b 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -21,13 +21,11 @@ struct ipv6_devconf {
__s32 force_mld_version;
__s32 mldv1_unsolicited_report_interval;
__s32 mldv2_unsolicited_report_interval;
-#ifdef CONFIG_IPV6_PRIVACY
__s32 use_tempaddr;
__s32 temp_valid_lft;
__s32 temp_prefered_lft;
__s32 regen_max_retry;
__s32 max_desync_factor;
-#endif
__s32 max_addresses;
__s32 accept_ra_defrtr;
__s32 accept_ra_pinfo;
diff --git a/include/net/if_inet6.h b/include/net/if_inet6.h
index 02ef772..76d5427 100644
--- a/include/net/if_inet6.h
+++ b/include/net/if_inet6.h
@@ -66,11 +66,10 @@ struct inet6_ifaddr {
struct hlist_node addr_lst;
struct list_head if_list;
-#ifdef CONFIG_IPV6_PRIVACY
struct list_head tmp_list;
struct inet6_ifaddr *ifpub;
int regen_count;
-#endif
+
bool tokenized;
struct rcu_head rcu;
@@ -192,11 +191,9 @@ struct inet6_dev {
__u32 if_flags;
int dead;
-#ifdef CONFIG_IPV6_PRIVACY
u8 rndid[8];
struct timer_list regen_timer;
struct list_head tempaddr_list;
-#endif
struct in6_addr token;
diff --git a/net/ipv6/Kconfig b/net/ipv6/Kconfig
index e1a8d90..d92e558 100644
--- a/net/ipv6/Kconfig
+++ b/net/ipv6/Kconfig
@@ -21,24 +21,6 @@ menuconfig IPV6
if IPV6
-config IPV6_PRIVACY
- bool "IPv6: Privacy Extensions (RFC 3041) support"
- ---help---
- Privacy Extensions for Stateless Address Autoconfiguration in IPv6
- support. With this option, additional periodically-altered
- pseudo-random global-scope unicast address(es) will be assigned to
- your interface(s).
-
- We use our standard pseudo-random algorithm to generate the
- randomized interface identifier, instead of one described in RFC 3041.
-
- By default the kernel does not generate temporary addresses.
- To use temporary addresses, do
-
- echo 2 >/proc/sys/net/ipv6/conf/all/use_tempaddr
-
- See <file:Documentation/networking/ip-sysctl.txt> for details.
-
config IPV6_ROUTER_PREF
bool "IPv6: Router Preference (RFC 4191) support"
---help---
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index cd3fb30..542d095 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -83,11 +83,7 @@
#include <linux/if_tunnel.h>
#include <linux/rtnetlink.h>
#include <linux/netconf.h>
-
-#ifdef CONFIG_IPV6_PRIVACY
#include <linux/random.h>
-#endif
-
#include <linux/uaccess.h>
#include <asm/unaligned.h>
@@ -124,11 +120,9 @@ static inline void addrconf_sysctl_unregister(struct inet6_dev *idev)
}
#endif
-#ifdef CONFIG_IPV6_PRIVACY
static void __ipv6_regen_rndid(struct inet6_dev *idev);
static void __ipv6_try_regen_rndid(struct inet6_dev *idev, struct in6_addr *tmpaddr);
static void ipv6_regen_rndid(unsigned long data);
-#endif
static int ipv6_generate_eui64(u8 *eui, struct net_device *dev);
static int ipv6_count_addresses(struct inet6_dev *idev);
@@ -183,13 +177,11 @@ static struct ipv6_devconf ipv6_devconf __read_mostly = {
.rtr_solicits = MAX_RTR_SOLICITATIONS,
.rtr_solicit_interval = RTR_SOLICITATION_INTERVAL,
.rtr_solicit_delay = MAX_RTR_SOLICITATION_DELAY,
-#ifdef CONFIG_IPV6_PRIVACY
.use_tempaddr = 0,
.temp_valid_lft = TEMP_VALID_LIFETIME,
.temp_prefered_lft = TEMP_PREFERRED_LIFETIME,
.regen_max_retry = REGEN_MAX_RETRY,
.max_desync_factor = MAX_DESYNC_FACTOR,
-#endif
.max_addresses = IPV6_MAX_ADDRESSES,
.accept_ra_defrtr = 1,
.accept_ra_pinfo = 1,
@@ -221,13 +213,11 @@ static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
.rtr_solicits = MAX_RTR_SOLICITATIONS,
.rtr_solicit_interval = RTR_SOLICITATION_INTERVAL,
.rtr_solicit_delay = MAX_RTR_SOLICITATION_DELAY,
-#ifdef CONFIG_IPV6_PRIVACY
.use_tempaddr = 0,
.temp_valid_lft = TEMP_VALID_LIFETIME,
.temp_prefered_lft = TEMP_PREFERRED_LIFETIME,
.regen_max_retry = REGEN_MAX_RETRY,
.max_desync_factor = MAX_DESYNC_FACTOR,
-#endif
.max_addresses = IPV6_MAX_ADDRESSES,
.accept_ra_defrtr = 1,
.accept_ra_pinfo = 1,
@@ -371,7 +361,6 @@ static struct inet6_dev *ipv6_add_dev(struct net_device *dev)
}
#endif
-#ifdef CONFIG_IPV6_PRIVACY
INIT_LIST_HEAD(&ndev->tempaddr_list);
setup_timer(&ndev->regen_timer, ipv6_regen_rndid, (unsigned long)ndev);
if ((dev->flags&IFF_LOOPBACK) ||
@@ -384,7 +373,7 @@ static struct inet6_dev *ipv6_add_dev(struct net_device *dev)
in6_dev_hold(ndev);
ipv6_regen_rndid((unsigned long) ndev);
}
-#endif
+
ndev->token = in6addr_any;
if (netif_running(dev) && addrconf_qdisc_ok(dev))
@@ -865,12 +854,10 @@ ipv6_add_addr(struct inet6_dev *idev, const struct in6_addr *addr,
/* Add to inet6_dev unicast addr list. */
ipv6_link_dev_addr(idev, ifa);
-#ifdef CONFIG_IPV6_PRIVACY
if (ifa->flags&IFA_F_TEMPORARY) {
list_add(&ifa->tmp_list, &idev->tempaddr_list);
in6_ifa_hold(ifa);
}
-#endif
in6_ifa_hold(ifa);
write_unlock(&idev->lock);
@@ -913,7 +900,7 @@ static void ipv6_del_addr(struct inet6_ifaddr *ifp)
spin_unlock_bh(&addrconf_hash_lock);
write_lock_bh(&idev->lock);
-#ifdef CONFIG_IPV6_PRIVACY
+
if (ifp->flags&IFA_F_TEMPORARY) {
list_del(&ifp->tmp_list);
if (ifp->ifpub) {
@@ -922,7 +909,6 @@ static void ipv6_del_addr(struct inet6_ifaddr *ifp)
}
__in6_ifa_put(ifp);
}
-#endif
list_for_each_entry_safe(ifa, ifn, &idev->addr_list, if_list) {
if (ifa == ifp) {
@@ -1013,7 +999,6 @@ out:
in6_ifa_put(ifp);
}
-#ifdef CONFIG_IPV6_PRIVACY
static int ipv6_create_tempaddr(struct inet6_ifaddr *ifp, struct inet6_ifaddr *ift)
{
struct inet6_dev *idev = ifp->idev;
@@ -1116,7 +1101,6 @@ retry:
out:
return ret;
}
-#endif
/*
* Choose an appropriate source address (RFC3484)
@@ -1131,9 +1115,7 @@ enum {
#endif
IPV6_SADDR_RULE_OIF,
IPV6_SADDR_RULE_LABEL,
-#ifdef CONFIG_IPV6_PRIVACY
IPV6_SADDR_RULE_PRIVACY,
-#endif
IPV6_SADDR_RULE_ORCHID,
IPV6_SADDR_RULE_PREFIX,
IPV6_SADDR_RULE_MAX
@@ -1247,7 +1229,6 @@ static int ipv6_get_saddr_eval(struct net *net,
&score->ifa->addr, score->addr_type,
score->ifa->idev->dev->ifindex) == dst->label;
break;
-#ifdef CONFIG_IPV6_PRIVACY
case IPV6_SADDR_RULE_PRIVACY:
{
/* Rule 7: Prefer public address
@@ -1259,7 +1240,6 @@ static int ipv6_get_saddr_eval(struct net *net,
ret = (!(score->ifa->flags & IFA_F_TEMPORARY)) ^ preftmp;
break;
}
-#endif
case IPV6_SADDR_RULE_ORCHID:
/* Rule 8-: Prefer ORCHID vs ORCHID or
* non-ORCHID vs non-ORCHID
@@ -1588,7 +1568,6 @@ static void addrconf_dad_stop(struct inet6_ifaddr *ifp, int dad_failed)
if (dad_failed)
ipv6_ifa_notify(0, ifp);
in6_ifa_put(ifp);
-#ifdef CONFIG_IPV6_PRIVACY
} else if (ifp->flags&IFA_F_TEMPORARY) {
struct inet6_ifaddr *ifpub;
spin_lock_bh(&ifp->lock);
@@ -1602,7 +1581,6 @@ static void addrconf_dad_stop(struct inet6_ifaddr *ifp, int dad_failed)
spin_unlock_bh(&ifp->lock);
}
ipv6_del_addr(ifp);
-#endif
} else
ipv6_del_addr(ifp);
}
@@ -1851,7 +1829,6 @@ static int ipv6_inherit_eui64(u8 *eui, struct inet6_dev *idev)
return err;
}
-#ifdef CONFIG_IPV6_PRIVACY
/* (re)generation of randomized interface identifier (RFC 3041 3.2, 3.5) */
static void __ipv6_regen_rndid(struct inet6_dev *idev)
{
@@ -1919,7 +1896,6 @@ static void __ipv6_try_regen_rndid(struct inet6_dev *idev, struct in6_addr *tmp
if (tmpaddr && memcmp(idev->rndid, &tmpaddr->s6_addr[8], 8) == 0)
__ipv6_regen_rndid(idev);
}
-#endif
/*
* Add prefix route.
@@ -2207,9 +2183,7 @@ ok:
if (ifp) {
int flags;
unsigned long now;
-#ifdef CONFIG_IPV6_PRIVACY
struct inet6_ifaddr *ift;
-#endif
u32 stored_lft;
/* update lifetime (RFC2462 5.5.3 e) */
@@ -2250,7 +2224,6 @@ ok:
} else
spin_unlock(&ifp->lock);
-#ifdef CONFIG_IPV6_PRIVACY
read_lock_bh(&in6_dev->lock);
/* update all temporary addresses in the list */
list_for_each_entry(ift, &in6_dev->tempaddr_list,
@@ -2315,7 +2288,7 @@ ok:
} else {
read_unlock_bh(&in6_dev->lock);
}
-#endif
+
in6_ifa_put(ifp);
addrconf_verify(0);
}
@@ -2995,7 +2968,6 @@ static int addrconf_ifdown(struct net_device *dev, int how)
if (!how)
idev->if_flags &= ~(IF_RS_SENT|IF_RA_RCVD|IF_READY);
-#ifdef CONFIG_IPV6_PRIVACY
if (how && del_timer(&idev->regen_timer))
in6_dev_put(idev);
@@ -3015,7 +2987,6 @@ static int addrconf_ifdown(struct net_device *dev, int how)
in6_ifa_put(ifa);
write_lock_bh(&idev->lock);
}
-#endif
while (!list_empty(&idev->addr_list)) {
ifa = list_first_entry(&idev->addr_list,
@@ -3528,7 +3499,6 @@ restart:
in6_ifa_put(ifp);
goto restart;
}
-#ifdef CONFIG_IPV6_PRIVACY
} else if ((ifp->flags&IFA_F_TEMPORARY) &&
!(ifp->flags&IFA_F_TENTATIVE)) {
unsigned long regen_advance = ifp->idev->cnf.regen_max_retry *
@@ -3556,7 +3526,6 @@ restart:
} else if (time_before(ifp->tstamp + ifp->prefered_lft * HZ - regen_advance * HZ, next))
next = ifp->tstamp + ifp->prefered_lft * HZ - regen_advance * HZ;
spin_unlock(&ifp->lock);
-#endif
} else {
/* ifp->prefered_lft <= ifp->valid_lft */
if (time_before(ifp->tstamp + ifp->prefered_lft * HZ, next))
@@ -4128,13 +4097,11 @@ static inline void ipv6_store_devconf(struct ipv6_devconf *cnf,
jiffies_to_msecs(cnf->mldv1_unsolicited_report_interval);
array[DEVCONF_MLDV2_UNSOLICITED_REPORT_INTERVAL] =
jiffies_to_msecs(cnf->mldv2_unsolicited_report_interval);
-#ifdef CONFIG_IPV6_PRIVACY
array[DEVCONF_USE_TEMPADDR] = cnf->use_tempaddr;
array[DEVCONF_TEMP_VALID_LFT] = cnf->temp_valid_lft;
array[DEVCONF_TEMP_PREFERED_LFT] = cnf->temp_prefered_lft;
array[DEVCONF_REGEN_MAX_RETRY] = cnf->regen_max_retry;
array[DEVCONF_MAX_DESYNC_FACTOR] = cnf->max_desync_factor;
-#endif
array[DEVCONF_MAX_ADDRESSES] = cnf->max_addresses;
array[DEVCONF_ACCEPT_RA_DEFRTR] = cnf->accept_ra_defrtr;
array[DEVCONF_ACCEPT_RA_PINFO] = cnf->accept_ra_pinfo;
@@ -4828,7 +4795,6 @@ static struct addrconf_sysctl_table
.mode = 0644,
.proc_handler = proc_dointvec_ms_jiffies,
},
-#ifdef CONFIG_IPV6_PRIVACY
{
.procname = "use_tempaddr",
.data = &ipv6_devconf.use_tempaddr,
@@ -4864,7 +4830,6 @@ static struct addrconf_sysctl_table
.mode = 0644,
.proc_handler = proc_dointvec,
},
-#endif
{
.procname = "max_addresses",
.data = &ipv6_devconf.max_addresses,
--
1.7.11.7
^ permalink raw reply related
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: David Miller @ 2013-10-29 0:12 UTC (permalink / raw)
To: dcbw
Cc: hannes, jiri, vyasevich, netdev, kuznet, jmorris, yoshfuji, kaber,
thaller, stephen
In-Reply-To: <1383002583.28991.19.camel@dcbw.foobar.com>
From: Dan Williams <dcbw@redhat.com>
Date: Mon, 28 Oct 2013 18:23:03 -0500
> Except that we've run out of IFA_F_* flags already, since it's a u8 and
> there are already 8 flags. What to do?
That's not a problem, just add a new netlink attribute "extended
flags" that can be passed in with address netlink messages.
^ permalink raw reply
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: Hannes Frederic Sowa @ 2013-10-29 0:13 UTC (permalink / raw)
To: David Miller
Cc: dcbw, jiri, vyasevich, netdev, kuznet, jmorris, yoshfuji, kaber,
thaller, stephen
In-Reply-To: <20131028.200810.66180312939474324.davem@davemloft.net>
On Mon, Oct 28, 2013 at 08:08:10PM -0400, David Miller wrote:
> From: Dan Williams <dcbw@redhat.com>
> Date: Mon, 28 Oct 2013 18:16:19 -0500
>
> > On Mon, 2013-10-28 at 17:17 -0400, David Miller wrote:
> > First off, what's the reasoning behind having IPv6 privacy as a config
> > option? It's off-by-default and must be explicitly turned on, so is
> > there any harm in removing the config? Or is it just for
> > smallest-kernel-ever folks?
>
> I think it's for "smallest kernel ever" stuff. Even every arch
> defconfig that mentions it has it enabled :-)
>
> Maybe it was optional initially because the code was new and
> experimental'ish. I don't know.
>
> Regardless of the reason I think it only obfuscates the code with
> ifdefs right now and I would be happy to see it disappear.
>
> Any objections to this patch?
Yeah, I changed my mind. The ifdefs are really hideous. Fine for me.
Greetings,
Hannes
^ permalink raw reply
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: David Miller @ 2013-10-29 0:43 UTC (permalink / raw)
To: hannes
Cc: jiri, vyasevich, netdev, kuznet, jmorris, yoshfuji, kaber,
thaller, stephen
In-Reply-To: <20131028233158.GA26185@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Tue, 29 Oct 2013 00:31:58 +0100
> I wonder why NetworkManager rewrote IPv6 router discovery but not IPv4
> DHCP client stuff. It could have been a good moment to introduce something
> like PROT_DHCP sockets. Maybe it is not too late... ;)
Note that you don't even need to put the DHCP protocol core into the
kernel to fix the promiscuous problem. You just have to use the
current kernel interfaces correctly.
It used to be the case a very long time ago that you couldn't even
receive broadcast UDP datagrams on a socket until an address was
configured on it.
So everyone turns on promiscuous mode and uses RAW sockets or
AF_PACKET.
Stupid? yes.
But now the kernel will receive broadcast UDP datagrams just fine even
if there are no ipv4 addresses assigned yet.
I did a mock-up simple ipv4 DHCP client implementation just to test it
out, and it did work just fine. Unfortunately, I can't find it at the
moment, I hope I didn't just delete it in frustration. :-)
> My current idea to handle this, is that a kernel boot parameter is
> provided to stop the generation of link-local addresses and that we kick
> off address configuration from user-space at early as the secret key is
> provided, which may well be from the initramfs. I'll send a RFC as soon
> as I can find some time to clean it up and have it actually tested.
I guess I'm ok with this, as I can't come up with any reasonable
alternative scheme.
^ 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