* Re: [PATCH net-next #2 21/39] tulip_core: stop using net_device.{base_addr, irq}.
From: Grant Grundler @ 2012-04-06 16:57 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, David Miller, Grant Grundler
In-Reply-To: <43487f61a41077ec5cf8587248eb502f5d9be785.1333704409.git.romieu@fr.zoreil.com>
On Fri, Apr 6, 2012 at 3:06 AM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> Cc: Grant Grundler <grundler@parisc-linux.org>
Ack-by: Grant Grundler <grundler@parisc-linux.org>
thanks,
grant
> ---
> drivers/net/ethernet/dec/tulip/tulip_core.c | 27 ++++++++++++++++-----------
> 1 files changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/ethernet/dec/tulip/tulip_core.c b/drivers/net/ethernet/dec/tulip/tulip_core.c
> index fea3641..25fe117 100644
> --- a/drivers/net/ethernet/dec/tulip/tulip_core.c
> +++ b/drivers/net/ethernet/dec/tulip/tulip_core.c
> @@ -328,7 +328,7 @@ static void tulip_up(struct net_device *dev)
> udelay(100);
>
> if (tulip_debug > 1)
> - netdev_dbg(dev, "tulip_up(), irq==%d\n", dev->irq);
> + netdev_dbg(dev, "tulip_up(), irq==%d\n", tp->pdev->irq);
>
> iowrite32(tp->rx_ring_dma, ioaddr + CSR3);
> iowrite32(tp->tx_ring_dma, ioaddr + CSR4);
> @@ -515,11 +515,13 @@ media_picked:
> static int
> tulip_open(struct net_device *dev)
> {
> + struct tulip_private *tp = netdev_priv(dev);
> int retval;
>
> tulip_init_ring (dev);
>
> - retval = request_irq(dev->irq, tulip_interrupt, IRQF_SHARED, dev->name, dev);
> + retval = request_irq(tp->pdev->irq, tulip_interrupt, IRQF_SHARED,
> + dev->name, dev);
> if (retval)
> goto free_ring;
>
> @@ -841,7 +843,7 @@ static int tulip_close (struct net_device *dev)
> netdev_dbg(dev, "Shutting down ethercard, status was %02x\n",
> ioread32 (ioaddr + CSR5));
>
> - free_irq (dev->irq, dev);
> + free_irq (tp->pdev->irq, dev);
>
> tulip_free_ring (dev);
>
> @@ -1489,8 +1491,6 @@ static int __devinit tulip_init_one (struct pci_dev *pdev,
>
> INIT_WORK(&tp->media_work, tulip_tbl[tp->chip_id].media_task);
>
> - dev->base_addr = (unsigned long)ioaddr;
> -
> #ifdef CONFIG_TULIP_MWI
> if (!force_csr0 && (tp->flags & HAS_PCI_MWI))
> tulip_mwi_config (pdev, dev);
> @@ -1650,7 +1650,6 @@ static int __devinit tulip_init_one (struct pci_dev *pdev,
> for (i = 0; i < 6; i++)
> last_phys_addr[i] = dev->dev_addr[i];
> last_irq = irq;
> - dev->irq = irq;
>
> /* The lower four bits are the media type. */
> if (board_idx >= 0 && board_idx < MAX_UNITS) {
> @@ -1858,7 +1857,8 @@ static int tulip_suspend (struct pci_dev *pdev, pm_message_t state)
> tulip_down(dev);
>
> netif_device_detach(dev);
> - free_irq(dev->irq, dev);
> + /* FIXME: it needlessly adds an error path. */
> + free_irq(tp->pdev->irq, dev);
>
> save_state:
> pci_save_state(pdev);
> @@ -1900,7 +1900,9 @@ static int tulip_resume(struct pci_dev *pdev)
> return retval;
> }
>
> - if ((retval = request_irq(dev->irq, tulip_interrupt, IRQF_SHARED, dev->name, dev))) {
> + retval = request_irq(pdev->irq, tulip_interrupt, IRQF_SHARED,
> + dev->name, dev);
> + if (retval < 0) {
> pr_err("request_irq failed in resume\n");
> return retval;
> }
> @@ -1960,11 +1962,14 @@ static void __devexit tulip_remove_one (struct pci_dev *pdev)
>
> static void poll_tulip (struct net_device *dev)
> {
> + struct tulip_private *tp = netdev_priv(dev);
> + const int irq = tp->pdev->irq;
> +
> /* disable_irq here is not very nice, but with the lockless
> interrupt handler we have no other choice. */
> - disable_irq(dev->irq);
> - tulip_interrupt (dev->irq, dev);
> - enable_irq(dev->irq);
> + disable_irq(irq);
> + tulip_interrupt (irq, dev);
> + enable_irq(irq);
> }
> #endif
>
> --
> 1.7.7.6
>
^ permalink raw reply
* [PATCH] net/core: Fix seeking in /proc/net/dev
From: John Keeping @ 2012-04-06 17:05 UTC (permalink / raw)
To: netdev; +Cc: John Keeping, linux-kernel, Mihai Maruseac
Commit f04565ddf52e4 (dev: use name hash for dev_seq_ops) introduced
code that fails to check the requested position when getting an item for
/proc/net/dev. This means that any code which seeks within this file is
likely to receive corrupted data.
A test case for this is to use the read builtin in bash:
$ while read line; do echo "$line"; done </proc/net/dev | cut -c-20
Inter-| Receive
face |bytes packe
virbr0: 20706
0
lo: 2329335 10305
eth0: 0
compared to just cat'ing the file:
$ cat /proc/net/dev | cut -c-20
Inter-| Receive
face |bytes pack
lo: 2329335 10
virbr0: 20706
sit0: 0
wlan0: 1727234745 1
eth0: 0
This patch takes the sledgehammer approach of starting again from the
beginning if asked to seek backwards.
Signed-off-by: John Keeping <john@keeping.me.uk>
---
I have made the minimal change required to fix the bug here. If desired I
can spend some more time and enhance the dev_from_new_bucket and
dev_from_same_bucket functions to support walking backwards as well as
forwards through the items in the table.
---
net/core/dev.c | 24 +++++++++++++++++++-----
1 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 6ca32f6..66b1e891 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4040,6 +4040,7 @@ static int dev_ifconf(struct net *net, char __user *arg)
struct dev_iter_state {
struct seq_net_private p;
+ loff_t expected_pos; /* current index */
unsigned int pos; /* bucket << BUCKET_SPACE + offset */
};
@@ -4096,24 +4097,37 @@ static inline struct net_device *dev_from_new_bucket(struct seq_file *seq)
void *dev_seq_start(struct seq_file *seq, loff_t *pos)
__acquires(RCU)
{
+ struct net_device *dev;
struct dev_iter_state *state = seq->private;
rcu_read_lock();
- if (!*pos)
+ if (!*pos) {
+ state->expected_pos = 0;
+ state->pos = 0;
return SEQ_START_TOKEN;
+ }
- /* check for end of the hash */
- if (state->pos == 0 && *pos > 1)
- return NULL;
+ /* If we're asked for something behind where we are, start again. */
+ if (state->expected_pos >= *pos) {
+ state->expected_pos = 0;
+ state->pos = 0;
+ }
- return dev_from_new_bucket(seq);
+ do {
+ dev = dev_from_new_bucket(seq);
+ ++state->expected_pos;
+ } while (dev && state->expected_pos < *pos);
+
+ return dev;
}
void *dev_seq_next(struct seq_file *seq, void *v, loff_t *pos)
{
struct net_device *dev;
+ struct dev_iter_state *state = seq->private;
++*pos;
+ state->expected_pos = *pos;
if (v == SEQ_START_TOKEN)
return dev_from_new_bucket(seq);
--
1.7.8.5
^ permalink raw reply related
* Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
From: Ben Hutchings @ 2012-04-06 17:06 UTC (permalink / raw)
To: Arvid Brodin; +Cc: David Miller, shemminger, netdev, balferreira, arvid.brodin
In-Reply-To: <4F7F10FC.3020308@enea.com>
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.)
>
--
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: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
From: Arvid Brodin @ 2012-04-06 17:08 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev, balferreira, arvid.brodin
In-Reply-To: <20120406.124344.564538802640968013.davem@davemloft.net>
David Miller wrote:
> From: Arvid Brodin <arvid.brodin@enea.com>
> Date: Fri, 6 Apr 2012 17:51:24 +0200
>
>> 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?
>
> It's not doing it with "char *", it's doing it with other types like
> the type of the ICMP header in this case.
>
> memcpy is expanded by the compiler internally into __builtin_memcpy()
> which if it sees the length is reasonably short will inline the
> copy. And subsequently it uses the alignment of the types involved
> to determine what kinds of loads and stores it can use in that
> inline memcpy().
>
> So the result is that just because in your case with your compiler
> it doesn't get expanded inline and fault, it doesn't mean it won't
> for someone else.
>
> You're just lucky, and you really haven't fixed the bug.
>
Ok. And thanks for the explanation. Would something like this do the
trick then?
+ /* Need to cast to (char *) below to keep gcc optimizations
+ from causing alignment faults. */
+ memcpy(&icmp_param.data.icmph, (char *) icmp_hdr(skb),
+ sizeof(icmp_param.data.icmph));
If not, any suggestions on how to tackle this?
--
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 Xdin. Read more at
www.xdin.com.
^ permalink raw reply
* Re: [PATCH] net/core: Fix seeking in /proc/net/dev
From: Mihai Maruseac @ 2012-04-06 17:14 UTC (permalink / raw)
To: John Keeping; +Cc: netdev, linux-kernel, Mihai Maruseac, Daniel Baluta
In-Reply-To: <1333731944-15808-1-git-send-email-john@keeping.me.uk>
On Fri, Apr 6, 2012 at 8:05 PM, John Keeping <john@keeping.me.uk> wrote:
> Commit f04565ddf52e4 (dev: use name hash for dev_seq_ops) introduced
> code that fails to check the requested position when getting an item for
> /proc/net/dev. This means that any code which seeks within this file is
> likely to receive corrupted data.
>
> A test case for this is to use the read builtin in bash:
>
> $ while read line; do echo "$line"; done </proc/net/dev | cut -c-20
> Inter-| Receive
> face |bytes packe
> virbr0: 20706
> 0
> lo: 2329335 10305
> eth0: 0
>
> compared to just cat'ing the file:
>
> $ cat /proc/net/dev | cut -c-20
> Inter-| Receive
> face |bytes pack
> lo: 2329335 10
> virbr0: 20706
> sit0: 0
> wlan0: 1727234745 1
> eth0: 0
>
> This patch takes the sledgehammer approach of starting again from the
> beginning if asked to seek backwards.
>
> Signed-off-by: John Keeping <john@keeping.me.uk>
>
> ---
> I have made the minimal change required to fix the bug here. If desired I
> can spend some more time and enhance the dev_from_new_bucket and
> dev_from_same_bucket functions to support walking backwards as well as
> forwards through the items in the table.
>
> ---
> net/core/dev.c | 24 +++++++++++++++++++-----
> 1 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 6ca32f6..66b1e891 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4040,6 +4040,7 @@ static int dev_ifconf(struct net *net, char __user *arg)
>
> struct dev_iter_state {
> struct seq_net_private p;
> + loff_t expected_pos; /* current index */
> unsigned int pos; /* bucket << BUCKET_SPACE + offset */
> };
>
> @@ -4096,24 +4097,37 @@ static inline struct net_device *dev_from_new_bucket(struct seq_file *seq)
> void *dev_seq_start(struct seq_file *seq, loff_t *pos)
> __acquires(RCU)
> {
> + struct net_device *dev;
> struct dev_iter_state *state = seq->private;
>
> rcu_read_lock();
> - if (!*pos)
> + if (!*pos) {
> + state->expected_pos = 0;
> + state->pos = 0;
> return SEQ_START_TOKEN;
> + }
>
> - /* check for end of the hash */
> - if (state->pos == 0 && *pos > 1)
> - return NULL;
> + /* If we're asked for something behind where we are, start again. */
> + if (state->expected_pos >= *pos) {
> + state->expected_pos = 0;
> + state->pos = 0;
> + }
>
> - return dev_from_new_bucket(seq);
> + do {
> + dev = dev_from_new_bucket(seq);
> + ++state->expected_pos;
> + } while (dev && state->expected_pos < *pos);
> +
> + return dev;
> }
>
> void *dev_seq_next(struct seq_file *seq, void *v, loff_t *pos)
> {
> struct net_device *dev;
> + struct dev_iter_state *state = seq->private;
>
> ++*pos;
> + state->expected_pos = *pos;
>
> if (v == SEQ_START_TOKEN)
> return dev_from_new_bucket(seq);
> --
> 1.7.8.5
>
Looks good to me. However, Eric just submitted a patch here with other
changes caused by a logic error in the original patch.
Now I understand why those resets to the beginning were there (though
they are very rare)
^ permalink raw reply
* Re: [PATCH net-next #2 23/39] uli526x: fix regions leak in driver probe error path.
From: Grant Grundler @ 2012-04-06 17:15 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, David Miller, Grant Grundler
In-Reply-To: <5a61e7c690fce53cd37eddc9808134bc0e6b9837.1333704409.git.romieu@fr.zoreil.com>
On Fri, Apr 6, 2012 at 3:06 AM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> Cc: Grant Grundler <grundler@parisc-linux.org>
Ack-by: Grant Grundler <grundler@parisc-linux.org>
I'm assuming uli526x_remove_one() is called after uli526x_stop()
(which quiesces the HW). That appears to be the case for tulip_core.c
as well - so this should be ok.
thanks,
grant
> ---
> drivers/net/ethernet/dec/tulip/uli526x.c | 48 ++++++++++++-----------------
> 1 files changed, 20 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/net/ethernet/dec/tulip/uli526x.c b/drivers/net/ethernet/dec/tulip/uli526x.c
> index fc4001f..c9b3396 100644
> --- a/drivers/net/ethernet/dec/tulip/uli526x.c
> +++ b/drivers/net/ethernet/dec/tulip/uli526x.c
> @@ -313,9 +313,9 @@ static int __devinit uli526x_init_one (struct pci_dev *pdev,
> goto err_out_disable;
> }
>
> - if (pci_request_regions(pdev, DRV_NAME)) {
> + err = pci_request_regions(pdev, DRV_NAME);
> + if (err < 0) {
> pr_err("Failed to request PCI regions\n");
> - err = -ENODEV;
> goto err_out_disable;
> }
>
> @@ -323,18 +323,15 @@ static int __devinit uli526x_init_one (struct pci_dev *pdev,
> db = netdev_priv(dev);
>
> /* Allocate Tx/Rx descriptor memory */
> + err = -ENOMEM;
> +
> db->desc_pool_ptr = pci_alloc_consistent(pdev, sizeof(struct tx_desc) * DESC_ALL_CNT + 0x20, &db->desc_pool_dma_ptr);
> - if(db->desc_pool_ptr == NULL)
> - {
> - err = -ENOMEM;
> - goto err_out_nomem;
> - }
> + if (!db->desc_pool_ptr)
> + goto err_out_release;
> +
> db->buf_pool_ptr = pci_alloc_consistent(pdev, TX_BUF_ALLOC * TX_DESC_CNT + 4, &db->buf_pool_dma_ptr);
> - if(db->buf_pool_ptr == NULL)
> - {
> - err = -ENOMEM;
> - goto err_out_nomem;
> - }
> + if (!db->buf_pool_ptr)
> + goto err_out_free_tx_desc;
>
> db->first_tx_desc = (struct tx_desc *) db->desc_pool_ptr;
> db->first_tx_desc_dma = db->desc_pool_dma_ptr;
> @@ -387,7 +384,7 @@ static int __devinit uli526x_init_one (struct pci_dev *pdev,
> }
> err = register_netdev (dev);
> if (err)
> - goto err_out_res;
> + goto err_out_free_tx_buf;
>
> netdev_info(dev, "ULi M%04lx at pci%s, %pM, irq %d\n",
> ent->driver_data >> 16, pci_name(pdev),
> @@ -397,16 +394,14 @@ static int __devinit uli526x_init_one (struct pci_dev *pdev,
>
> return 0;
>
> -err_out_res:
> +err_out_free_tx_buf:
> + pci_free_consistent(pdev, TX_BUF_ALLOC * TX_DESC_CNT + 4,
> + db->buf_pool_ptr, db->buf_pool_dma_ptr);
> +err_out_free_tx_desc:
> + pci_free_consistent(pdev, sizeof(struct tx_desc) * DESC_ALL_CNT + 0x20,
> + db->desc_pool_ptr, db->desc_pool_dma_ptr);
> +err_out_release:
> pci_release_regions(pdev);
> -err_out_nomem:
> - if(db->desc_pool_ptr)
> - pci_free_consistent(pdev, sizeof(struct tx_desc) * DESC_ALL_CNT + 0x20,
> - db->desc_pool_ptr, db->desc_pool_dma_ptr);
> -
> - if(db->buf_pool_ptr != NULL)
> - pci_free_consistent(pdev, TX_BUF_ALLOC * TX_DESC_CNT + 4,
> - db->buf_pool_ptr, db->buf_pool_dma_ptr);
> err_out_disable:
> pci_disable_device(pdev);
> err_out_free:
> @@ -422,19 +417,16 @@ static void __devexit uli526x_remove_one (struct pci_dev *pdev)
> struct net_device *dev = pci_get_drvdata(pdev);
> struct uli526x_board_info *db = netdev_priv(dev);
>
> - ULI526X_DBUG(0, "uli526x_remove_one()", 0);
> -
> + unregister_netdev(dev);
> pci_free_consistent(db->pdev, sizeof(struct tx_desc) *
> DESC_ALL_CNT + 0x20, db->desc_pool_ptr,
> db->desc_pool_dma_ptr);
> pci_free_consistent(db->pdev, TX_BUF_ALLOC * TX_DESC_CNT + 4,
> db->buf_pool_ptr, db->buf_pool_dma_ptr);
> - unregister_netdev(dev);
> pci_release_regions(pdev);
> - free_netdev(dev); /* free board information */
> - pci_set_drvdata(pdev, NULL);
> pci_disable_device(pdev);
> - ULI526X_DBUG(0, "uli526x_remove_one() exit", 0);
> + pci_set_drvdata(pdev, NULL);
> + free_netdev(dev);
> }
>
>
> --
> 1.7.7.6
>
^ permalink raw reply
* Re: [PATCH net-next #2 00/39] net_device.{base_addr, irq} removal update
From: Grant Grundler @ 2012-04-06 17:17 UTC (permalink / raw)
To: David Miller
Cc: romieu, netdev, gallatin, andy, chris.snook, venza, DavidLv,
ionut, jcliburn, jdmason, mason, mchan, stas.yakovlev,
steve.glendinning, thockin
In-Reply-To: <20120406.062626.578458566949440559.davem@davemloft.net>
On Fri, Apr 6, 2012 at 3:26 AM, David Miller <davem@davemloft.net> wrote:
> From: Francois Romieu <romieu@fr.zoreil.com>
> Date: Fri, 6 Apr 2012 12:06:14 +0200
>
>> If there are no further changes, I'll rebase and send a single pull request
>> for the series including Grant's Acked-by once he says it is ok.
>
> Besides the request_irq() return value test issues, this series
> seems fine to me.
Ditto. I didn't see the request_irq() issue though. :( Oh well...this
is clearly an improvement.
thanks,
grant
^ permalink raw reply
* Re: [PATCH] net/core: Fix seeking in /proc/net/dev
From: David Miller @ 2012-04-06 17:18 UTC (permalink / raw)
To: john; +Cc: netdev, linux-kernel, mihai.maruseac
In-Reply-To: <1333731944-15808-1-git-send-email-john@keeping.me.uk>
Eric Dumazet already fixed this the other day.
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2012-04-06 17:35 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix inaccuracies in network driver interface documentation, from
Ben Hutchings.
2) Fix handling of negative offsets in BPF JITs, from Jan Seiffert.
3) Compile warning, locking, and refcounting fixes in netfilter's
xt_CT, from Pablo Neira Ayuso.
4) phonet sendmsg needs to validate user length just like any
other datagram protocol, fix from Sasha Levin.
5) Ipv6 multicast code uses wrong loop index, from RongQing Li.
6) Link handling and firmware fixes in bnx2x driver from Yaniv
Rosner and Yuval Mintz.
7) mlx4 erroneously allocates 4 pages at a time, regardless of page
size, fix from Thadeu Lima de Souza Cascardo.
8) SCTP socket option wasn't extended in a backwards compatible
way, fix from Thomas Graf.
9) Add missing address change event emissions to bonding, from
Shlomo Pongratz.
10) /proc/net/dev regressed because it uses a private offset to
track where we are in the hash table, but this doesn't
track the offset pullback that the seq_file code does
resulting in some entries being missed in large dumps.
Fix from Eric Dumazet.
11) do_tcp_sendpage() unloads the send queue way too fast, because
it invokes tcp_push() when it shouldn't. Let the natural sequence
generated by the splice paths, and the assosciated MSG_MORE
settings, guide the tcp_push() calls.
Otherwise what goes out of TCP is spaghetti and doesn't batch
effectively into GSO/TSO clusters.
From Eric Dumazet.
12) Once we put a SKB into either the netlink receiver's queue
or a socket error queue, it can be consumed and freed up,
therefore we cannot touch it after queueing it like that.
Fixes from Eric Dumazet.
13) PPP has this annoying behavior in that for every transmit
call it immediately stops the TX queue, then calls down
into the next layer to transmit the PPP frame.
But if that next layer can take it immediately, it just
un-stops the TX queue right before returning from the
transmit method.
Besides being useless work, it makes several facilities
unusable, in particular things like the equalizers. Well
behaved devices should only stop the TX queue when they
really are full, and in PPP's case when it gets backlogged
to the downstream device.
David Woodhouse therefore fixed PPP to not stop the TX
queue until it's downstream can't take data any more.
14) IFF_UNICAST_FLT got accidently lost in some recent stmmac
driver changes, re-add. From Marc Kleine-Budde.
15) Fix link flaps in ixgbe, from Eric W. Multanen.
16) Descriptor writeback fixes in e1000e from Matthew Vick.
Please pull, thanks a lot!
The following changes since commit 314489bd4c7780fde6a069783d5128f6cef52919:
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2012-04-05 22:13:39 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
Artem Savkov (1):
r8169: enable napi on resume.
Ben Hutchings (6):
ethtool: Remove exception to the requirement of holding RTNL lock
doc, net: Remove obsolete reference to dev->poll
doc, net: Update documentation of synchronisation for TX multiqueue
doc, net: Update netdev operation names
doc, net: Remove instruction to set net_device::trans_start
doc, net: Update ndo_start_xmit return type and values
Bruce Allan (1):
e1000e: prevent oops when adapter is being closed and reset simultaneously
David S. Miller (2):
Merge branch 'master' of git://git.kernel.org/.../jkirsher/net
Merge branch 'master' of git://1984.lsi.us.es/net
David Woodhouse (1):
ppp: Don't stop and restart queue on every TX packet
Eric Dumazet (5):
net: fix /proc/net/dev regression
tcp: allow splice() to build full TSO packets
tcp: tcp_sendpages() should call tcp_push() once
netlink: fix races after skb queueing
net: fix a race in sock_queue_err_skb()
Fernando Luis Vazquez Cao (1):
TCP: update ip_local_port_range documentation
Jan Beulich (1):
netfilter: xt_LOG: don't use xchg() for simple assignment
Jan Engelhardt (1):
netfilter: ipset: avoid use of kernel-only types
Jan Seiffert (2):
bpf jit: Make the filter.c::__load_pointer helper non-static for the jits
bpf jit: Let the x86 jit handle negative offsets
Marc Kleine-Budde (1):
stmmac: re-add IFF_UNICAST_FLT for dwmac1000
Matthew Vick (1):
e1000e: Guarantee descriptor writeback flush success.
Multanen, Eric W (1):
ixgbe: driver fix for link flap
Pablo Neira Ayuso (4):
netfilter: xt_CT: remove a compile warning
netfilter: xt_CT: allocation has to be GFP_ATOMIC under rcu_read_lock section
netfilter: xt_CT: fix missing put timeout object in error path
netfilter: nf_conntrack: fix count leak in error path of __nf_conntrack_alloc
RongQing.Li (1):
ipv6: fix array index in ip6_mc_add_src()
Sasha Levin (1):
phonet: Check input from user before allocating
Shlomo Pongratz (2):
net/bonding: emit address change event also in bond_release
net/bonding: correctly proxy slave neigh param setup ndo function
Srinivas Kandagatla (1):
phy:icplus:fix Auto Power Saving in ip101a_config_init.
Thadeu Lima de Souza Cascardo (1):
mlx4: allocate just enough pages instead of always 4 pages
Thomas Graf (1):
sctp: Allow struct sctp_event_subscribe to grow without breaking binaries
Veaceslav Falico (1):
bonding: properly unset current_arp_slave on slave link up
Yaniv Rosner (10):
bnx2x: PFC fix
bnx2x: Fix BCM57810-KR FC
bnx2x: Fix BCM57810-KR AN speed transition
bnx2x: Fix BCM578x0-SFI pre-emphasis settings
bnx2x: Restore 1G LED on BCM57712+BCM8727 designs.
bnx2x: Fix link issue for BCM8727 boards.
bnx2x: Fix BCM84833 PHY FW version presentation
bnx2x: Clear BCM84833 LED after fan failure
bnx2x: Fix BCM57711+BCM84823 link issue
bnx2x: Clear MDC/MDIO warning message
Yuval Mintz (1):
bnx2x: correction to firmware interface
stephen hemminger (2):
sky2: copy received packets on inefficient unaligned architecture
MAINTAINERS: update for Marvell Ethernet drivers
Documentation/networking/driver.txt | 31 ++--
Documentation/networking/ip-sysctl.txt | 11 +-
Documentation/networking/netdevices.txt | 25 ++--
MAINTAINERS | 19 +--
arch/x86/net/bpf_jit.S | 122 +++++++++++----
arch/x86/net/bpf_jit_comp.c | 41 +++--
drivers/net/bonding/bond_main.c | 60 ++++++-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 1 -
.../net/ethernet/broadcom/bnx2x/bnx2x_fw_defs.h | 110 +++++++-------
drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 147 +++++++++++++----
drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h | 8 +
drivers/net/ethernet/intel/e1000e/e1000.h | 6 +
drivers/net/ethernet/intel/e1000e/netdev.c | 26 +++
drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_nl.c | 164 ++++++++++----------
drivers/net/ethernet/marvell/sky2.c | 13 ++-
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 5 +-
drivers/net/ethernet/realtek/r8169.c | 3 +
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +-
drivers/net/phy/icplus.c | 3 +-
drivers/net/ppp/ppp_generic.c | 14 +-
fs/splice.c | 5 +-
include/linux/ethtool.h | 3 +-
include/linux/netdevice.h | 2 -
include/linux/netfilter/xt_set.h | 4 +-
include/linux/socket.h | 2 +-
include/net/netfilter/xt_log.h | 2 +-
net/core/dev.c | 58 ++------
net/core/dev_addr_lists.c | 3 +-
net/core/filter.c | 9 +-
net/core/skbuff.c | 4 +-
net/ipv4/tcp.c | 2 +-
net/ipv6/mcast.c | 2 +-
net/netfilter/nf_conntrack_core.c | 1 +
net/netfilter/xt_CT.c | 28 +++-
net/netlink/af_netlink.c | 24 ++--
net/phonet/pep.c | 3 +
net/sctp/socket.c | 5 +-
net/socket.c | 6 +-
38 files changed, 602 insertions(+), 376 deletions(-)
^ permalink raw reply
* [PATCH net-next V2] tcp: Fix bug when gap in rcv sequence is filled
From: Vijay Subramanian @ 2012-04-06 17:36 UTC (permalink / raw)
To: netdev; +Cc: davem, ncardwell, ilpo.jarvinen, loke.chetan, Vijay Subramanian
As per RFC2581 and the newer RFC5681, "the receiver SHOULD send an immediate ACK
when it receives a data segment that fills in all or part of a gap in the
sequence space." When TCP receiver gets the next in-sequence packet, we move
data from ofo queue to receive queue. At this point, we should send an immediate
ack by entering quickack mode. In the current code, instead of entering
quickack mode upon requeing packets from ofo queue to receive_queue, we enter
quickack mode only when ofo queue becomes empty after requeuing. This ignores
the possibility that there may be further packets left in ofo queue. This patch
fixes this behavior and enters quickack mode whenever packets are moved from ofo
queue to receive queue.
Also, comment has been updated to reflect that RFC5681 obsoletes RFC2581.
Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
---
Changes from V1:
-- Removed bool variable to simplify code. (chetan loke <loke.chetan@gmail.com>)
net/ipv4/tcp_input.c | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index e886e2f..f4561f9 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4388,12 +4388,14 @@ static void tcp_sack_remove(struct tcp_sock *tp)
/* This one checks to see if we can put data from the
* out_of_order queue into the receive_queue.
+ * Return 1 if data is moved from ofo queue to receive_queue and 0 otherwise.
*/
-static void tcp_ofo_queue(struct sock *sk)
+static int tcp_ofo_queue(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
__u32 dsack_high = tp->rcv_nxt;
struct sk_buff *skb;
+ int requeued = 0; /*1 if an skb is requeued to receive_queue*/
while ((skb = skb_peek(&tp->out_of_order_queue)) != NULL) {
if (after(TCP_SKB_CB(skb)->seq, tp->rcv_nxt))
@@ -4418,10 +4420,12 @@ static void tcp_ofo_queue(struct sock *sk)
__skb_unlink(skb, &tp->out_of_order_queue);
__skb_queue_tail(&sk->sk_receive_queue, skb);
+ requeued = 1;
tp->rcv_nxt = TCP_SKB_CB(skb)->end_seq;
if (tcp_hdr(skb)->fin)
tcp_fin(sk);
}
+ return requeued;
}
static int tcp_prune_ofo_queue(struct sock *sk);
@@ -4636,12 +4640,11 @@ queue_and_out:
tcp_fin(sk);
if (!skb_queue_empty(&tp->out_of_order_queue)) {
- tcp_ofo_queue(sk);
- /* RFC2581. 4.2. SHOULD send immediate ACK, when
- * gap in queue is filled.
+ /* RFC5681 (which obsoletes RFC2581.) 4.2. SHOULD send
+ * immediate ACK, when gap in queue is filled.
*/
- if (skb_queue_empty(&tp->out_of_order_queue))
+ if (tcp_ofo_queue(sk))
inet_csk(sk)->icsk_ack.pingpong = 0;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] net/core: Fix seeking in /proc/net/dev
From: Eric Dumazet @ 2012-04-06 17:41 UTC (permalink / raw)
To: Mihai Maruseac
Cc: John Keeping, netdev, linux-kernel, Mihai Maruseac, Daniel Baluta
In-Reply-To: <CAOMsUMLDFpYw9REPjZd2m49xV4UKFjFobNorGmOPCFeqjV-RDg@mail.gmail.com>
On Fri, 2012-04-06 at 20:14 +0300, Mihai Maruseac wrote:
> On Fri, Apr 6, 2012 at 8:05 PM, John Keeping <john@keeping.me.uk> wrote:
> > Commit f04565ddf52e4 (dev: use name hash for dev_seq_ops) introduced
> > code that fails to check the requested position when getting an item for
> > /proc/net/dev. This means that any code which seeks within this file is
> > likely to receive corrupted data.
> >
> > A test case for this is to use the read builtin in bash:
> >
...
> Looks good to me. However, Eric just submitted a patch here with other
> changes caused by a logic error in the original patch.
Hmm, I think my patch fixed this lseek issue as well.
^ permalink raw reply
* Re: [PATCH] net/core: Fix seeking in /proc/net/dev
From: Eric Dumazet @ 2012-04-06 17:43 UTC (permalink / raw)
To: David Miller; +Cc: john, netdev, linux-kernel, mihai.maruseac
In-Reply-To: <20120406.131800.651812823796333479.davem@davemloft.net>
On Fri, 2012-04-06 at 13:18 -0400, David Miller wrote:
> Eric Dumazet already fixed this the other day.
> --
John, take a look at
http://git.kernel.org/?p=linux/kernel/git/davem/net.git;a=commit;h=2def16ae6b0c77571200f18ba4be049b03d75579
Thanks
^ permalink raw reply
* Re: [PATCH net-next V2] tcp: Fix bug when gap in rcv sequence is filled
From: chetan loke @ 2012-04-06 18:06 UTC (permalink / raw)
To: Vijay Subramanian; +Cc: netdev, davem, ncardwell, ilpo.jarvinen
In-Reply-To: <1333733810-2381-1-git-send-email-subramanian.vijay@gmail.com>
On Fri, Apr 6, 2012 at 1:36 PM, Vijay Subramanian
<subramanian.vijay@gmail.com> wrote:
> + int requeued = 0; /*1 if an skb is requeued to receive_queue*/
Vijay - minor change: missing leading/trailing space in the comment.
checkpatch.pl ?
Chetan
^ permalink raw reply
* Re: ipv6: tunnel: hang when destroying ipv6 tunnel
From: Jim Garlick @ 2012-04-06 18:09 UTC (permalink / raw)
To: Tetsuo Handa
Cc: levinsasha928@gmail.com, ericvh@gmail.com, oleg@redhat.com,
eric.dumazet@gmail.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru,
jmorris@namei.org, yoshfuji@linux-ipv6.org, kaber@trash.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
davej@redhat.com
In-Reply-To: <201204062044.EJE13062.OLMQtSVFHOFOJF@I-love.SAKURA.ne.jp>
Hi Tetsuo,
I am sorry if my patch is causing you grief!
On Fri, Apr 06, 2012 at 04:44:37AM -0700, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
> > Most suspicious change is net/9p/client.c because it is changing handling of
> > ERESTARTSYS case.
> >
> > --- linux-3.3.1/net/9p/client.c
> > +++ linux-next/net/9p/client.c
> > @@ -740,10 +740,18 @@
> > c->status = Disconnected;
> > goto reterr;
> > }
> > +again:
> > /* Wait for the response */
> > err = wait_event_interruptible(*req->wq,
> > req->status >= REQ_STATUS_RCVD);
> >
> > + if ((err == -ERESTARTSYS) && (c->status == Connected)
> > + && (type == P9_TFLUSH)) {
> > + sigpending = 1;
> > + clear_thread_flag(TIF_SIGPENDING);
> > + goto again;
> > + }
> > +
>
> I think this loop is bad with regard to response to SIGKILL.
> If wait_event_interruptible() was interrupted by SIGKILL, it will
> spin until req->status >= REQ_STATUS_RCVD becomes true.
> Rather,
>
> if ((c->status == Connected) && (type == P9_TFLUSH))
> err = wait_event_killable(*req->wq,
> req->status >= REQ_STATUS_RCVD);
> else
> err = wait_event_interruptible(*req->wq,
> req->status >= REQ_STATUS_RCVD);
>
> would be safer.
Does that work? What prevents p9_client_rpc() from recursing via
p9_client_flush() on receipt of SIGKILL?
> > error:
> > /*
> > * Fid is not valid even after a failed clunk
> > + * If interrupted, retry once then give up and
> > + * leak fid until umount.
> > */
> > - p9_fid_destroy(fid);
> > + if (err == -ERESTARTSYS) {
> > + if (retries++ == 0)
> > + goto again;
>
> I think it is possible that the process is interrupted again upon retrying.
> I suspect the handling of err == -ERESTARTSYS case when retries != 0.
> It is returning without calling p9_fid_destroy(), which will be
> unexpected behaviour for the various callers.
Yes but in the unlikely event that this happens, the effect is a small
memory leak for the duration of the mount. On the other hand if the
fid is destroyed without successfully informing the server, then
subsequent operations that involve new file references will fail
when that fid number is reused, and the mount becomes unusable.
> > + } else
> > + p9_fid_destroy(fid);
> > return err;
> > }
> > EXPORT_SYMBOL(p9_client_clunk);
Regards,
Jim
^ permalink raw reply
* Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
From: Stephen Hemminger @ 2012-04-06 18:19 UTC (permalink / raw)
To: Ben Hutchings
Cc: Arvid Brodin, David Miller, netdev, balferreira, arvid.brodin
In-Reply-To: <1333731991.3282.17.camel@deadeye>
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.
^ permalink raw reply
* Re: [PATCH] net/core: Fix seeking in /proc/net/dev
From: John Keeping @ 2012-04-06 18:19 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, linux-kernel, mihai.maruseac
In-Reply-To: <1333734192.3007.5.camel@edumazet-glaptop>
On 06.04.2012 17:43, Eric Dumazet wrote:
> On Fri, 2012-04-06 at 13:18 -0400, David Miller wrote:
>> Eric Dumazet already fixed this the other day.
>> --
>
>
> http://git.kernel.org/?p=linux/kernel/git/davem/net.git;a=commit;h=2def16ae6b0c77571200f18ba4be049b03d75579
This does indeed fix the same bug. That will teach me not to check the
appropriate maintainer's tree before sending a patch!
Sorry for the noise,
John
^ permalink raw reply
* Re: [PATCH net-next V2] tcp: Fix bug when gap in rcv sequence is filled
From: Vijay Subramanian @ 2012-04-06 18:27 UTC (permalink / raw)
To: chetan loke; +Cc: netdev, davem, ncardwell, ilpo.jarvinen
In-Reply-To: <CAAsGZS4w=2_e9O=cRK6r+gxirohhSPHpgkNpWw_ZvC-+Q-pHkA@mail.gmail.com>
>> + int requeued = 0; /*1 if an skb is requeued to receive_queue*/
>
> Vijay - minor change: missing leading/trailing space in the comment.
> checkpatch.pl ?
Thanks for the reviews Chetan. checkpatch.pl reported no errors and no
warnings however.
I will wait for additional feedback from TCP folks and send version V3
if needed.
Thanks,
Vijay
^ permalink raw reply
* Re: Expose ltr/obff interface by sysfs
From: Konrad Rzeszutek Wilk @ 2012-04-06 18:39 UTC (permalink / raw)
To: Hao, Xudong
Cc: e1000-devel@lists.sourceforge.net, linux-pci@vger.kernel.org,
Jesse Barnes, netdev@vger.kernel.org
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FD0A434@SHSMSX102.ccr.corp.intel.com>
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
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [REGRESSION][PATCH v1] bpf jit: Let the arm jit handle negative memory references
From: Jan Seiffert @ 2012-04-06 18:57 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, Eric Dumazet, David S. Miller, Mircea Gherzan,
Russell King
In-Reply-To: <4F75CA89.4010709@googlemail.com>
The arm jit has the same problem as the other two jits.
It only tests for negative absolute memory references, and if it sees
one bails out to let the interpreter handle the filter program.
But this fails if the X register contains a negative memory reference
and is used for an indirect load.
This is only caught at runtime, where the filter will always drop
the packet.
Filter which work fine with the interpreter do not work with the jit.
So this patch tries to fix it for the arm jit.
First we add the prototype of bpf_internal_load_pointer_neg_helper to
filter.h, since the arm jit has no assembler component, instead it has
to be used from C.
Then the helper functions are prepared to either handle known positive
offsets, known negative offsets, or any offset and test at runtime.
Finally the compiler is modified to emit calls to the right function,
depending if either the offset is known, or not.
This fixes the case of a negative X register and allows to lift
the restriction that bpf programs with negative offsets can't
be jited.
Signed-off-by: Jan Seiffert <kaffeemonster@googlemail.com>
---
The arm jit structure is a little bit different then the other jits, esp.
it does not use assembler load helper. So i had to put the prototype for
bpf_internal_load_pointer_neg_helper somewhere.
This is a v1 to keep the ball rolling.
Testing would also be cool, -ENOHARDWARE.
arch/arm/net/bpf_jit_32.c | 149 ++++++++++++++++++++++++++++++++-------------
include/linux/filter.h | 6 ++
net/core/filter.c | 4 +
3 files changed, 117 insertions(+), 42 deletions(-)
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index 62135849..19d60af 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -18,6 +18,7 @@
#include <linux/slab.h>
#include <asm/cacheflush.h>
#include <asm/hwcap.h>
+#include <asm/unaligned.h>
#include "bpf_jit_32.h"
@@ -71,7 +72,7 @@ struct jit_ctx {
int bpf_jit_enable __read_mostly;
-static u64 jit_get_skb_b(struct sk_buff *skb, unsigned offset)
+static u64 jit_get_skb_b_pos(struct sk_buff *skb, unsigned offset)
{
u8 ret;
int err;
@@ -81,7 +82,7 @@ static u64 jit_get_skb_b(struct sk_buff *skb, unsigned offset)
return (u64)err << 32 | ret;
}
-static u64 jit_get_skb_h(struct sk_buff *skb, unsigned offset)
+static u64 jit_get_skb_h_pos(struct sk_buff *skb, unsigned offset)
{
u16 ret;
int err;
@@ -91,7 +92,7 @@ static u64 jit_get_skb_h(struct sk_buff *skb, unsigned offset)
return (u64)err << 32 | ntohs(ret);
}
-static u64 jit_get_skb_w(struct sk_buff *skb, unsigned offset)
+static u64 jit_get_skb_w_pos(struct sk_buff *skb, unsigned offset)
{
u32 ret;
int err;
@@ -101,6 +102,60 @@ static u64 jit_get_skb_w(struct sk_buff *skb, unsigned offset)
return (u64)err << 32 | ntohl(ret);
}
+static u64 jit_get_skb_b_neg(struct sk_buff *skb, unsigned offset)
+{
+ u8 *ptr;
+
+ ptr = bpf_internal_load_pointer_neg_helper(skb, offset, 1);
+ if (!ptr)
+ return (u64)1 << 32;
+ return *ptr;
+}
+
+static u64 jit_get_skb_h_neg(struct sk_buff *skb, unsigned offset)
+{
+ u16 *ptr;
+
+ ptr = bpf_internal_load_pointer_neg_helper(skb, offset, 2);
+ if (!ptr)
+ return (u64)1 << 32;
+ return get_unaligned_be16(ptr);
+}
+
+static u64 jit_get_skb_w_neg(struct sk_buff *skb, unsigned offset)
+{
+ u32 *ptr;
+
+ ptr = bpf_internal_load_pointer_neg_helper(skb, offset, 4);
+ if (!ptr)
+ return (u64)1 << 32;
+ return get_unaligned_be32(ptr);
+}
+
+static u64 jit_get_skb_b_any(struct sk_buff *skb, unsigned offset)
+{
+ if ((int)offset >= 0)
+ return jit_get_skb_b_pos(skb, offset);
+ else
+ return jit_get_skb_b_neg(skb, offset);
+}
+
+static u64 jit_get_skb_h_any(struct sk_buff *skb, unsigned offset)
+{
+ if ((int)offset >= 0)
+ return jit_get_skb_h_pos(skb, offset);
+ else
+ return jit_get_skb_h_neg(skb, offset);
+}
+
+static u64 jit_get_skb_w_any(struct sk_buff *skb, unsigned offset)
+{
+ if ((int)offset >= 0)
+ return jit_get_skb_w_pos(skb, offset);
+ else
+ return jit_get_skb_w_neg(skb, offset);
+}
+
/*
* Wrapper that handles both OABI and EABI and assures Thumb2 interworking
* (where the assembly routines like __aeabi_uidiv could cause problems).
@@ -458,7 +513,10 @@ static inline void update_on_xread(struct jit_ctx *ctx)
static int build_body(struct jit_ctx *ctx)
{
- void *load_func[] = {jit_get_skb_b, jit_get_skb_h, jit_get_skb_w};
+ void *load_func_any[] = {jit_get_skb_b_any, jit_get_skb_h_any, jit_get_skb_w_any};
+ void *load_func_pos[] = {jit_get_skb_b_pos, jit_get_skb_h_pos, jit_get_skb_w_pos};
+ void *load_func_neg[] = {jit_get_skb_b_neg, jit_get_skb_h_neg, jit_get_skb_w_neg};
+ void **load_func;
const struct sk_filter *prog = ctx->skf;
const struct sock_filter *inst;
unsigned i, load_order, off, condt;
@@ -498,36 +556,38 @@ static int build_body(struct jit_ctx *ctx)
case BPF_S_LD_B_ABS:
load_order = 0;
load:
- /* the interpreter will deal with the negative K */
- if ((int)k < 0)
- return -ENOTSUPP;
emit_mov_i(r_off, k, ctx);
-load_common:
- ctx->seen |= SEEN_DATA | SEEN_CALL;
-
- if (load_order > 0) {
- emit(ARM_SUB_I(r_scratch, r_skb_hl,
- 1 << load_order), ctx);
- emit(ARM_CMP_R(r_scratch, r_off), ctx);
- condt = ARM_COND_HS;
- } else {
- emit(ARM_CMP_R(r_skb_hl, r_off), ctx);
- condt = ARM_COND_HI;
- }
- _emit(condt, ARM_ADD_R(r_scratch, r_off, r_skb_data),
- ctx);
-
- if (load_order == 0)
- _emit(condt, ARM_LDRB_I(r_A, r_scratch, 0),
+ /* deal with negative K */
+ if (k >= 0) {
+ load_func = load_func_pos;
+ if (load_order > 0) {
+ emit(ARM_SUB_I(r_scratch, r_skb_hl,
+ 1 << load_order), ctx);
+ emit(ARM_CMP_R(r_scratch, r_off), ctx);
+ condt = ARM_COND_HS;
+ } else {
+ emit(ARM_CMP_R(r_skb_hl, r_off), ctx);
+ condt = ARM_COND_HI;
+ }
+
+ _emit(condt, ARM_ADD_R(r_scratch, r_off, r_skb_data),
ctx);
- else if (load_order == 1)
- emit_load_be16(condt, r_A, r_scratch, ctx);
- else if (load_order == 2)
- emit_load_be32(condt, r_A, r_scratch, ctx);
- _emit(condt, ARM_B(b_imm(i + 1, ctx)), ctx);
+ if (load_order == 0)
+ _emit(condt, ARM_LDRB_I(r_A, r_scratch, 0),
+ ctx);
+ else if (load_order == 1)
+ emit_load_be16(condt, r_A, r_scratch, ctx);
+ else if (load_order == 2)
+ emit_load_be32(condt, r_A, r_scratch, ctx);
+ _emit(condt, ARM_B(b_imm(i + 1, ctx)), ctx);
+ } else {
+ load_func = load_func_neg;
+ }
+load_common:
+ ctx->seen |= SEEN_DATA | SEEN_CALL;
/* the slowpath */
emit_mov_i(ARM_R3, (u32)load_func[load_order], ctx);
emit(ARM_MOV_R(ARM_R0, r_skb), ctx);
@@ -547,7 +607,9 @@ load_common:
case BPF_S_LD_B_IND:
load_order = 0;
load_ind:
+ load_func = load_func_any;
OP_IMM3(ARM_ADD, r_off, r_X, k, ctx);
+ load_func = load_func_any;
goto load_common;
case BPF_S_LDX_IMM:
ctx->seen |= SEEN_X;
@@ -565,25 +627,28 @@ load_ind:
case BPF_S_LDX_B_MSH:
/* x = ((*(frame + k)) & 0xf) << 2; */
ctx->seen |= SEEN_X | SEEN_DATA | SEEN_CALL;
- /* the interpreter should deal with the negative K */
- if (k < 0)
- return -1;
/* offset in r1: we might have to take the slow path */
emit_mov_i(r_off, k, ctx);
- emit(ARM_CMP_R(r_skb_hl, r_off), ctx);
+ /* deal with negative K */
+ if (k >= 0) {
+ load_func = load_func_pos;
+ emit(ARM_CMP_R(r_skb_hl, r_off), ctx);
- /* load in r0: common with the slowpath */
- _emit(ARM_COND_HI, ARM_LDRB_R(ARM_R0, r_skb_data,
- ARM_R1), ctx);
- /*
- * emit_mov_i() might generate one or two instructions,
- * the same holds for emit_blx_r()
- */
- _emit(ARM_COND_HI, ARM_B(b_imm(i + 1, ctx) - 2), ctx);
+ /* load in r0: common with the slowpath */
+ _emit(ARM_COND_HI, ARM_LDRB_R(ARM_R0, r_skb_data,
+ ARM_R1), ctx);
+ /*
+ * emit_mov_i() might generate one or two instructions,
+ * the same holds for emit_blx_r()
+ */
+ _emit(ARM_COND_HI, ARM_B(b_imm(i + 1, ctx) - 2), ctx);
+ } else {
+ load_func = load_func_neg;
+ }
emit(ARM_MOV_R(ARM_R0, r_skb), ctx);
/* r_off is r1 */
- emit_mov_i(ARM_R3, (u32)jit_get_skb_b, ctx);
+ emit_mov_i(ARM_R3, (u32)load_func[0], ctx);
emit_blx_r(ARM_R3, ctx);
/* check the return value of skb_copy_bits */
emit(ARM_CMP_I(ARM_R1, 0), ctx);
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 8eeb205..78cd56d 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -161,6 +161,12 @@ extern int sk_chk_filter(struct sock_filter *filter, unsigned int flen);
extern void bpf_jit_compile(struct sk_filter *fp);
extern void bpf_jit_free(struct sk_filter *fp);
#define SK_RUN_FILTER(FILTER, SKB) (*FILTER->bpf_func)(SKB, FILTER->insns)
+/*
+ * Only Exported for the bpf jit load helper.
+ * Do not call from anywhere else!
+ */
+extern void *bpf_internal_load_pointer_neg_helper(const struct sk_buff *skb,
+ int k, unsigned int size);
#else
static inline void bpf_jit_compile(struct sk_filter *fp)
{
diff --git a/net/core/filter.c b/net/core/filter.c
index 6f755cc..9cbaecb 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -42,6 +42,10 @@
/* No hurry in this branch
*
* Exported for the bpf jit load helper.
+ *
+ * CAUTION ! :
+ * If its prototype is ever changed, check arch/{*}/net/{*}.S files,
+ * since it is called from BPF assembly code.
*/
void *bpf_internal_load_pointer_neg_helper(const struct sk_buff *skb, int k, unsigned int size)
{
^ permalink raw reply related
* Re: [PATCH v17 01/15] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs
From: Andrew Morton @ 2012-04-06 19:49 UTC (permalink / raw)
To: Will Drewry
Cc: linux-kernel, linux-security-module, linux-arch, linux-doc,
kernel-hardening, netdev, x86, arnd, davem, hpa, mingo, oleg,
peterz, rdunlap, mcgrathr, tglx, luto, eparis, serge.hallyn, djm,
scarybeasts, indan, pmoore, corbet, eric.dumazet, markus, coreyb,
keescook, jmorris, Andy Lutomirski
In-Reply-To: <1333051320-30872-2-git-send-email-wad@chromium.org>
On Thu, 29 Mar 2012 15:01:46 -0500
Will Drewry <wad@chromium.org> wrote:
> From: Andy Lutomirski <luto@amacapital.net>
>
> With this set, a lot of dangerous operations (chroot, unshare, etc)
> become a lot less dangerous because there is no possibility of
> subverting privileged binaries.
>
> This patch completely breaks apparmor. Someone who understands (and
> uses) apparmor should fix it or at least give me a hint.
So [patch 2/15] fixes all this up?
I guess we should join the two patches into one, to avoid a silly
breakage window. That means that John loses a brownie point, but we
can mention him in the changelog, include his signed-off-by:
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Several of these patches are missing your signed-off-by:. They should
all have your SOB, because you sent them.
Documentation/SubmittingPatches explains this.
I'm trying to find a way to merge all this code without reviewing it ;)
Alas, this is against my rules. Given the length of time for which
this patchset has been floating around, I'm a little surprised by the
lack of acked-by's and reviewed-by's. Have you been gathering them all
up? Are the networking guys all happy about this patchset?
^ permalink raw reply
* Re: [PATCH v17 01/15] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs
From: Andy Lutomirski @ 2012-04-06 19:55 UTC (permalink / raw)
To: Andrew Morton
Cc: Will Drewry, linux-kernel, linux-security-module, linux-arch,
linux-doc, kernel-hardening, netdev, x86, arnd, davem, hpa, mingo,
oleg, peterz, rdunlap, mcgrathr, tglx, luto, eparis, serge.hallyn,
djm, scarybeasts, indan, pmoore, corbet, eric.dumazet, markus,
coreyb, keescook, jmorris
In-Reply-To: <20120406124921.5754e941.akpm@linux-foundation.org>
On Fri, Apr 6, 2012 at 12:49 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Thu, 29 Mar 2012 15:01:46 -0500
> Will Drewry <wad@chromium.org> wrote:
>
>> From: Andy Lutomirski <luto@amacapital.net>
>>
>> With this set, a lot of dangerous operations (chroot, unshare, etc)
>> become a lot less dangerous because there is no possibility of
>> subverting privileged binaries.
>>
>> This patch completely breaks apparmor. Someone who understands (and
>> uses) apparmor should fix it or at least give me a hint.
>
> So [patch 2/15] fixes all this up?
>
> I guess we should join the two patches into one, to avoid a silly
> breakage window. That means that John loses a brownie point, but we
> can mention him in the changelog, include his signed-off-by:
Or just fix the commit message. It no longer completely breaks
AppArmor. It just causes execve to fail when PR_SET_NO_NEW_PRIVS is
set and AppArmor is in use.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" 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 v17 01/15] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs
From: Andrew Morton @ 2012-04-06 19:55 UTC (permalink / raw)
To: Will Drewry
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
linux-arch-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
kernel-hardening-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8,
netdev-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
arnd-r2nGTMty4D4, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
hpa-YMNOUZJC4hwAvxtiuMwx3w, mingo-H+wXaHxf7aLQT0dZR+AlfA,
oleg-H+wXaHxf7aLQT0dZR+AlfA, peterz-wEGCiKHe2LqWVfeAwA7xHQ,
rdunlap-/UHa2rfvQTnk1uMJSBkQmQ, mcgrathr-F7+t8E8rja9g9hUCZPvPmw,
tglx-hfZtesqFncYOwBW4kG4KsQ, luto-3s7WtUTddSA,
eparis-H+wXaHxf7aLQT0dZR+AlfA,
serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw, djm-ilwOsaqNJrtAfugRpC6u6w,
scarybeasts-Re5JQEeQqe8AvxtiuMwx3w, indan-1J6HnF7K7zE,
pmoore-H+wXaHxf7aLQT0dZR+AlfA, corbet-T1hC0tSOHrs,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
markus-F7+t8E8rja9g9hUCZPvPmw,
coreyb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
keescook-F7+t8E8rja9g9hUCZPvPmw, jmorris-gx6/JNMH7DfYtjvyW6yDsg,
Andy Lutomirski, linux-man-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1333051320-30872-2-git-send-email-wad-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
On Thu, 29 Mar 2012 15:01:46 -0500
Will Drewry <wad-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> From: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
>
> With this set, a lot of dangerous operations (chroot, unshare, etc)
> become a lot less dangerous because there is no possibility of
> subverting privileged binaries.
The changelog doesn't explain the semantics of the new syscall.
There's a comment way-down-there which I guess suffices, if you hunt
for it.
And the changelog doesn't explain why this is being added. Presumably
seccomp_filter wants/needs this feature but whowhatwherewhenwhy? Spell
it all out, please.
The new syscall mode will be documented in the prctl manpage. Please
cc linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org and work with Michael on getting this
done?
>
> ...
>
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v17 01/15] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs
From: Andrew Lutomirski @ 2012-04-06 20:01 UTC (permalink / raw)
To: Andrew Morton
Cc: Will Drewry, linux-kernel, linux-security-module, linux-arch,
linux-doc, kernel-hardening, netdev, x86, arnd, davem, hpa, mingo,
oleg, peterz, rdunlap, mcgrathr, tglx, eparis, serge.hallyn, djm,
scarybeasts, indan, pmoore, corbet, eric.dumazet, markus, coreyb,
keescook, jmorris, Andy Lutomirski, linux-man
In-Reply-To: <20120406125517.77133b4e.akpm@linux-foundation.org>
On Fri, Apr 6, 2012 at 12:55 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Thu, 29 Mar 2012 15:01:46 -0500
> Will Drewry <wad@chromium.org> wrote:
>
>> From: Andy Lutomirski <luto@amacapital.net>
>>
>> With this set, a lot of dangerous operations (chroot, unshare, etc)
>> become a lot less dangerous because there is no possibility of
>> subverting privileged binaries.
>
> The changelog doesn't explain the semantics of the new syscall.
> There's a comment way-down-there which I guess suffices, if you hunt
> for it.
>
> And the changelog doesn't explain why this is being added. Presumably
> seccomp_filter wants/needs this feature but whowhatwherewhenwhy? Spell
> it all out, please.
>
> The new syscall mode will be documented in the prctl manpage. Please
> cc linux-man@vger.kernel.org and work with Michael on getting this
> done?
This has been bugging me for awhile. Is there any interest in moving
the manpages into the kernel source tree? Then there could be a
general requirement that new APIs get documented when they're written.
(There are plenty of barely- or incompletely-documented syscalls.
futex and relatives come to mind.)
--Andy
^ permalink raw reply
* Re: [PATCH v17 07/15] asm/syscall.h: add syscall_get_arch
From: Andrew Morton @ 2012-04-06 20:05 UTC (permalink / raw)
To: Will Drewry
Cc: linux-kernel, linux-security-module, linux-arch, linux-doc,
kernel-hardening, netdev, x86, arnd, davem, hpa, mingo, oleg,
peterz, rdunlap, mcgrathr, tglx, luto, eparis, serge.hallyn, djm,
scarybeasts, indan, pmoore, corbet, eric.dumazet, markus, coreyb,
keescook, jmorris
In-Reply-To: <1333051320-30872-8-git-send-email-wad@chromium.org>
On Thu, 29 Mar 2012 15:01:52 -0500
Will Drewry <wad@chromium.org> wrote:
> Adds a stub for a function that will return the AUDIT_ARCH_*
> value appropriate to the supplied task based on the system
> call convention.
>
> For audit's use, the value can generally be hard-coded at the
> audit-site. However, for other functionality not inlined into
> syscall entry/exit, this makes that information available.
> seccomp_filter is the first planned consumer and, as such,
> the comment indicates a tie to HAVE_ARCH_SECCOMP_FILTER. That
Should be "CONFIG_HAVE_ARCH_SECCOMP_FILTER", I hope.
> is probably an unneeded detail.
>
> ...
>
> --- a/include/asm-generic/syscall.h
> +++ b/include/asm-generic/syscall.h
> @@ -142,4 +142,18 @@ void syscall_set_arguments(struct task_struct *task, struct pt_regs *regs,
> unsigned int i, unsigned int n,
> const unsigned long *args);
>
> +/**
> + * syscall_get_arch - return the AUDIT_ARCH for the current system call
> + * @task: task of interest, must be in system call entry tracing
> + * @regs: task_pt_regs() of @task
> + *
> + * Returns the AUDIT_ARCH_* based on the system call convention in use.
> + *
> + * It's only valid to call this when @task is stopped on entry to a system
> + * call, due to %TIF_SYSCALL_TRACE, %TIF_SYSCALL_AUDIT, or %TIF_SECCOMP.
> + *
> + * Note, at present this function is only required with
> + * CONFIG_HAVE_ARCH_SECCOMP_FILTER.
> + */
> +int syscall_get_arch(struct task_struct *task, struct pt_regs *regs);
> #endif /* _ASM_SYSCALL_H */
So architectures which permit CONFIG_HAVE_ARCH_SECCOMP_FILTER must
provide an implementation of this.
^ permalink raw reply
* Is this intended design, or a bug? Missing event for gateway being deleted
From: Stian Skjelstad @ 2012-04-06 20:04 UTC (permalink / raw)
To: netdev
I'm sorry if this has been discussed before, but my google searches didn't
give me any good hints so:
I'm using rtnetlink for a project and I noticed a non-consistent behavior.
When I tear down (the last) ip address, the default gateway is removed,
but it is not announced on the netlink socket. This can also be verified
using "ip monitor". This is tested with linux kernel version 3.2.6 on ARM.
# ip monitor &
# ip addr add 10.0.0.2/8 dev eth0
2: eth0 inet 10.0.0.2/8 scope global eth0
local 10.0.0.2 dev eth0 table local proto kernel scope host src 10.0.0.2
10.0.0.0/8 dev eth0 proto kernel scope link src 10.0.0.2
broadcast 10.0.0.0 dev eth0 table local proto kernel scope link src
10.0.0.2
broadcast 10.255.255.255 dev eth0 table local proto kernel scope link
src 10.0.0.2
# ip route add via 10.0.1.22
default via 10.0.1.2 dev eth0
# ip addr del 10.0.0.2/8 dev eth0
Deleted 2: eth0 inet 10.0.0.2/8 scope global eth0
Deleted 10.0.0.0/8 dev eth0 proto kernel scope link src 10.0.0.2
Deleted broadcast 10.255.255.255 dev eth0 table local proto kernel
scope link src 10.0.0.2
Deleted broadcast 10.0.0.0 dev eth0 table local proto kernel scope link
src 10.0.0.2
Deleted local 10.0.0.2 dev eth0 table local proto kernel scope host
src 10.0.0.2
(No Deleted default via line here)
Stian Skjelstad
^ 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