* ppp_deflate + kmalloc
From: Martin Jackson @ 2011-06-24 13:41 UTC (permalink / raw)
To: paulus; +Cc: linux-ppp, netdev
Hi,
In our android froyo-based system (omap3 hardware), we are getting the
following problem where the ppp driver cannot kmalloc enough memory
for the decomp buffer in the ppp driver.
Trying to make a 4th-order kmalloc (I think that amounts to 64kB)
seems ambitious. I do not understand why vmalloc is not being used
here, like it is for the compression buffer. Is using vmalloc here an
acceptable solution?
pppd: page allocation failure. order:4, mode:0x44d0
[<c016bc10>] (unwind_backtrace+0x0/0xdc) from [<c01fea80>]
(__alloc_pages_nodemask+0x4c4/0x5a4)
[<c01fea80>] (__alloc_pages_nodemask+0x4c4/0x5a4) from [<c01feb70>]
(__get_free_pages+0x10/0x3c)
[<c01feb70>] (__get_free_pages+0x10/0x3c) from [<c021cc24>]
(__kmalloc+0x3c/0x220)
[<c021cc24>] (__kmalloc+0x3c/0x220) from [<c03519d8>]
(z_decomp_alloc+0x120/0x164)
[<c03519d8>] (z_decomp_alloc+0x120/0x164) from [<c034de14>]
(ppp_ioctl+0xae4/0xf18)
[<c034de14>] (ppp_ioctl+0xae4/0xf18) from [<c022cd3c>] (vfs_ioctl+0x2c/0x8c)
[<c022cd3c>] (vfs_ioctl+0x2c/0x8c) from [<c022d3e8>] (do_vfs_ioctl+0x55c/0x5a0)
[<c022d3e8>] (do_vfs_ioctl+0x55c/0x5a0) from [<c022d478>] (sys_ioctl+0x4c/0x6c)
[<c022d478>] (sys_ioctl+0x4c/0x6c) from [<c0166f80>] (ret_fast_syscall+0x0/0x38)
Mem-info:
Normal per-cpu:
CPU 0: hi: 90, btch: 15 usd: 0
active_anon:6829 inactive_anon:6914 isolated_anon:0
active_file:14397 inactive_file:14438 isolated_file:0
unevictable:0 dirty:12 writeback:0 unstable:0
free:901 slab_reclaimable:1040 slab_unreclaimable:1117
mapped:12160 shmem:64 pagetables:1576 bounce:0
Normal free:3604kB min:2036kB low:2544kB high:3052kB
active_anon:27316kB inactive_anon:27656kB active_file:57588kB
inactive_file:57752kB unevictable:0kB isolated(anon):0kB
isolated(file):0kB present:260096kB mlocked:0kB dirty:48kB
writeback:0kB mapped:48640kB shmem:256kB slab_reclaimable:4160kB
slab_unreclaimable:4468kB kernel_stack:2128kB pagetables:6304kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 359*4kB 183*8kB 42*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 3604kB
28899 total pagecache pages
65536 pages of RAM
1299 free pages
13785 reserved pages
1482 slab pages
89904 pages shared
0 pages swap cached
This is how I worked around it.
--- a/drivers/net/ppp_deflate.c
+++ b/drivers/net/ppp_deflate.c
@@ -305,7 +305,7 @@ static void z_decomp_free(void *arg)
if (state) {
zlib_inflateEnd(&state->strm);
- kfree(state->strm.workspace);
+ vfree(state->strm.workspace);
kfree(state);
}
}
@@ -345,8 +345,7 @@ static void *z_decomp_alloc(unsigned char
*options, int opt_len)
state->w_size = w_size;
state->strm.next_out = NULL;
- state->strm.workspace = kmalloc(zlib_inflate_workspacesize(),
- GFP_KERNEL|__GFP_REPEAT);
+ state->strm.workspace = vmalloc(zlib_inflate_workspacesize());
if (state->strm.workspace == NULL)
goto out_free;
Best regards,
Martin Jackson
^ permalink raw reply
* Re: [PATCH 00/35]: System Firmware and SMBIOS Support
From: Arnd Bergmann @ 2011-06-24 13:40 UTC (permalink / raw)
To: Prarit Bhargava
Cc: linux-kernel, linux-ia64, x86, linux-acpi, linux-ide,
openipmi-developer, platform-driver-x86, linux-crypto, dri-devel,
lm-sensors, linux-i2c, linux-input, linux-media, linux-mmc,
netdev, linux-pci, rtc-linux, evel, linux-usb,
device-drivers-devel, linux-watchdog, grant.likely, dz, rpurdie,
eric.piel, abelay, johnpol
In-Reply-To: <20110623172206.27602.34306.sendpatchset@prarit.bos.redhat.com>
On Thursday 23 June 2011 19:22:06 Prarit Bhargava wrote:
> This new patchset reworks the existing DMI code into two separate layers. It is
> based off of the feedback I received previously when discussing the SMBIOS
> version patch on LKML.
Hi Prarit,
No objections to the patches, but when you send out a series as long as
this one, please ensure that all patches are sent as replies to the
introductory mail. Also, do not repeat the one-line patch summary in the
body of the email.
When using "git send-email --thread --no-chain-reply", this works
automatically. It will also let you put the Cc list into the
patch description and work out where to send each patch.
Arnd
^ permalink raw reply
* Re: RFT: virtio_net: limit xmit polling
From: Roopa Prabhu @ 2011-06-24 12:50 UTC (permalink / raw)
To: Tom Lendacky, Michael S. Tsirkin
Cc: Krishna Kumar2, habanero, lguest, Shirley Ma, kvm, Carsten Otte,
linux-s390, Heiko Carstens, linux-kernel, virtualization, steved,
Christian Borntraeger, netdev, Martin Schwidefsky, linux390
In-Reply-To: <201106211023.24643.tahm@linux.vnet.ibm.com>
[-- Attachment #1.1: Type: text/plain, Size: 1934 bytes --]
Michael,
I am testing this too.
I have finished one round of testing. But am running it again just to
confirm.
This time I will see if I can collect some exit stats too. Will post results
sometime this weekend.
I am just doing TCP_STREAM and TCP_MAERTS from guest to remote host.
Thanks,
Roopa
On 6/21/11 8:23 AM, "Tom Lendacky" <tahm@linux.vnet.ibm.com> wrote:
> On Sunday, June 19, 2011 05:27:00 AM Michael S. Tsirkin wrote:
>> > OK, different people seem to test different trees. In the hope to get
>> > everyone on the same page, I created several variants of this patch so
>> > they can be compared. Whoever's interested, please check out the
>> > following, and tell me how these compare:
>
> I'm in the process of testing these patches. Base and v0 are complete
> and v1 is near complete with v2 to follow. I'm testing with a variety
> of TCP_RR and TCP_STREAM/TCP_MAERTS tests involving local guest-to-guest
> tests and remote host-to-guest tests. I'll post the results in the next
> day or two when the tests finish.
>
> Thanks,
> Tom
>
>> >
>> > kernel:
>> >
>> > git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
>> >
>> > virtio-net-limit-xmit-polling/base - this is net-next baseline to test
>> > against virtio-net-limit-xmit-polling/v0 - fixes checks on out of capacity
>> > virtio-net-limit-xmit-polling/v1 - previous revision of the patch
>> > this does xmit,free,xmit,2*free,free
>> > virtio-net-limit-xmit-polling/v2 - new revision of the patch
>> > this does free,xmit,2*free,free
>> >
>> > There's also this on top:
>> > virtio-net-limit-xmit-polling/v3 -> don't delay avail index update
>> > I don't think it's important to test this one, yet
>> >
>> > Userspace to use: event index work is not yet merged upstream
>> > so the revision to use is still this:
>> > git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu-kvm.git
>> > virtio-net-event-idx-v3
>
[-- Attachment #1.2: Type: text/html, Size: 2700 bytes --]
[-- Attachment #2: Type: text/plain, Size: 184 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH] Bluetooth: Prevent buffer overflow in l2cap config request
From: Dan Rosenberg @ 2011-06-24 12:38 UTC (permalink / raw)
To: marcel, padovan, davem; +Cc: linux-bluetooth, netdev, linux-kernel, security
A remote user can provide a small value for the command size field in
the command header of an l2cap configuration request, resulting in an
integer underflow when subtracting the size of the configuration request
header. This results in copying a very large amount of data via
memcpy() and destroying the kernel heap. Check for underflow.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: stable <stable@kernel.org>
---
net/bluetooth/l2cap_core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index e64a1c2..06ea272 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -2334,7 +2334,7 @@ static inline int l2cap_config_req(struct l2cap_conn *conn, struct l2cap_cmd_hdr
/* Reject if config buffer is too small. */
len = cmd_len - sizeof(*req);
- if (chan->conf_len + len > sizeof(chan->conf_req)) {
+ if (len < 0 || chan->conf_len + len > sizeof(chan->conf_req)) {
l2cap_send_cmd(conn, cmd->ident, L2CAP_CONF_RSP,
l2cap_build_conf_rsp(chan, rsp,
L2CAP_CONF_REJECT, flags), rsp);
^ permalink raw reply related
* IEEE 802.1ag / 802.1x / Y1731
From: Satendra... @ 2011-06-24 12:06 UTC (permalink / raw)
To: netdev
Hi,
Could someone please tell me which version of linux has got support
for below (all three) protocols:
- IEEE 802.1ag
- 802.1x
- Y1731
Thanks,
Satendra
^ permalink raw reply
* Re: [PATCH] net/usb: kalmia: Various fixes for better support of non-x86 architectures.
From: Sergei Shtylyov @ 2011-06-24 11:55 UTC (permalink / raw)
To: Oliver Neukum
Cc: Sergei Shtylyov, Alan Stern, Marius B. Kotsbak,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Marius B. Kotsbak
In-Reply-To: <201106240742.38806.oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
Hello.
On 24-06-2011 9:42, Oliver Neukum wrote:
>>>> Actually 'const' alone should've been enough for the variable to be placed
>>>> in the data section ISO stack.
>>> I don't understand what "ISO stack" means here.
>> ISO == instead of.
> That doesn't matter. If you are sufficiently unlucky it will land on
> a page boundary. You must not do DMA on the data section either.
Who said it was going to do DMA on the data section? The arrays got copied
to heap-allocated buffer before DMA. But allocating those arrays on stack was
not optimal anyway.
> Regards
> Oliver
>
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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] ssb: use pci_dev->revision
From: Sergei Shtylyov @ 2011-06-24 11:20 UTC (permalink / raw)
To: Michael Büsch; +Cc: Sergei Shtylyov, netdev
In-Reply-To: <20110623173204.00fbaed6@maggie>
Hello.
On 23-06-2011 19:32, Michael Büsch wrote:
>>>> The bus scan code reads PCI revision ID from the PCI configuration register
>>>> while it's already stored by PCI subsystem in the 'revision' field of 'struct
>>>> pci_dev'...
>>>> Signed-off-by: Sergei Shtylyov<sshtylyov@ru.mvista.com>
>>>> ---
>>>> The patch is against the recent Linus' tree.
>>>> There's another place where the revision ID register is read but as 16-bit
>>>> entity (probably by mistake though), so I didn't convert it...
>>> Where is that?
>> drivers/ssb/pci.c, line 741.
> Yes that probably is by mistake. Can you convert it as well, please?
Tnen that whole function needs to be converted, as it reads subsystrem ID
from the PCI config. space, while it's aready stored by PCI core. That is a
matter of yet another patch.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/2] can: bfin_can: simplify xmit id1 setup
From: Oliver Hartkopp @ 2011-06-24 10:46 UTC (permalink / raw)
To: Mike Frysinger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b,
David S. Miller, Urs Thuermann
In-Reply-To: <1308861380-27485-1-git-send-email-vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
Am 23.06.2011 22:36, schrieb Mike Frysinger:
> If we look closely, the 4 writes to TRANSMIT_CHL.id1 can be collapsed
> down into much simpler code. So do just that.
Hello Mike,
unfortunately you addressed the wrong people to ack your patch.
In MAINTAINERS there are entries for the CAN NETWORK LAYER and for CAN
NETWORK DRIVERS which addresses the code in drivers/net/can/...
Additionally you should address your patch to the author of the driver
(Barry Song <21cnbao-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>).
Tnx & best regards,
Oliver
>
> This also fixes a build failure due to the I/O macros no longer
> getting pulled in. Their minor (and accidental) usage here gets
> dropped as part of the unification.
>
> Signed-off-by: Mike Frysinger<vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
> ---
> drivers/net/can/bfin_can.c | 21 ++++++---------------
> 1 files changed, 6 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/can/bfin_can.c b/drivers/net/can/bfin_can.c
> index b6e890d..dc6ef4a 100644
> --- a/drivers/net/can/bfin_can.c
> +++ b/drivers/net/can/bfin_can.c
> @@ -243,21 +243,12 @@ static int bfin_can_start_xmit(struct sk_buff *skb, struct net_device *dev)
> /* fill id */
> if (id& CAN_EFF_FLAG) {
> bfin_write16(®->chl[TRANSMIT_CHL].id0, id);
> - if (id& CAN_RTR_FLAG)
> - writew(((id& 0x1FFF0000)>> 16) | IDE | AME | RTR,
> - ®->chl[TRANSMIT_CHL].id1);
> - else
> - writew(((id& 0x1FFF0000)>> 16) | IDE | AME,
> - ®->chl[TRANSMIT_CHL].id1);
> -
> - } else {
> - if (id& CAN_RTR_FLAG)
> - writew((id<< 2) | AME | RTR,
> - ®->chl[TRANSMIT_CHL].id1);
> - else
> - bfin_write16(®->chl[TRANSMIT_CHL].id1,
> - (id<< 2) | AME);
> - }
> + val = ((id& 0x1FFF0000)>> 16) | IDE;
> + } else
> + val = (id<< 2);
> + if (id& CAN_RTR_FLAG)
> + val |= RTR;
> + bfin_write16(®->chl[TRANSMIT_CHL].id1, val | AME);
>
> /* fill payload */
> for (i = 0; i< 8; i += 2) {
^ permalink raw reply
* Re: [PATCH 1/2] iwlwifi: use pci_dev->revision, again
From: Sergei Shtylyov @ 2011-06-24 10:44 UTC (permalink / raw)
To: Guy, Wey-Yi
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ilw-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
In-Reply-To: <1308841365.13397.274.camel@wwguy-huron>
Hello.
On 23-06-2011 19:02, Guy, Wey-Yi wrote:
>> Commit ff938e43d39e926de74b32a3656c190f979ab642 (net: use pci_dev->revision,
>> again) already converted this driver to using the 'revision' field of 'struct
>> pci_dev' but commit c2974a1d18832a9fffb2eb389c3878f5c4ed92f1 (iwlagn: remove
>> rev_id) later reverted that change for no reason. Now restore the change...
>> Signed-off-by: Sergei Shtylyov<sshtylyov-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
>> ---
>> The patch is against the recent Linus' tree.
>> drivers/net/wireless/iwlwifi/iwl-agn.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>> Index: linux-2.6/drivers/net/wireless/iwlwifi/iwl-agn.c
>> ===================================================================
>> --- linux-2.6.orig/drivers/net/wireless/iwlwifi/iwl-agn.c
>> +++ linux-2.6/drivers/net/wireless/iwlwifi/iwl-agn.c
>> @@ -3275,10 +3275,9 @@ struct ieee80211_ops iwlagn_hw_ops = {
>>
>> static u32 iwl_hw_detect(struct iwl_priv *priv)
>> {
>> - u8 rev_id;
>> + IWL_DEBUG_INFO(priv, "HW Revision ID = 0x%X\n",
>> + priv->pci_dev->revision);
>>
>> - pci_read_config_byte(priv->pci_dev, PCI_REVISION_ID,&rev_id);
>> - IWL_DEBUG_INFO(priv, "HW Revision ID = 0x%X\n", rev_id);
>> return iwl_read32(priv, CSR_HW_REV);
>> }
> hmm, I believe it is merge sequence issue, the IWL_DEBUG_INFO line has
> benn remove all together in later patch. the information is being log in
> the calling function, no need to log in "iwl_hw_detect"
Hm, you probably mean this patch in the iwlwifi-2.6.git (of which I wasn't
aware):
author Emmanuel Grumbach <emmanuel.grumbach-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Tue, 31 May 2011 06:58:18 +0000 (09:58 +0300)
committer Wey-Yi Guy <wey-yi.w.guy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Sat, 18 Jun 2011 15:18:01 +0000 (08:18 -0700)
commit 85aed7c48113dfcdc913008481c46346af0db69e
tree 75831a2ec540039470c295a81c2059a24a4531f5
parent 19707bac16129ccebc398dbff9d2b44b17b24fea
iwlagn: don't read the PCI_REVISION_ID from iwl-agn.c
The PCI_REVISION_ID is read and printed in iwl_pci_probe anyway using pr_info
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Since iwl_pci_probe() still reads the PCI config. register, my patch
should be recast to modify iwl-pci.c instead...
> Wey
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* [PATCH] sctp: Reducing rwnd by sizeof(struct sk_buff) for each CHUNK is too aggressive
From: Thomas Graf @ 2011-06-24 10:15 UTC (permalink / raw)
To: Vlad Yasevich, Sridhar Samudrala; +Cc: linux-sctp, netdev
Currently we subtract sizeof(struct sk_buff) of our view of the
receiver's rwnd for each DATA chunk appended to a sctp packet.
Reducing the rwnd by >200 bytes for each DATA chunk quickly
consumes the available window and prevents max MTU sized packets
(for large MTU values) from being generated in combination with
small DATA chunks. The sender has to wait for the next SACK to
be processed for the rwnd to be corrected.
Accounting for data structures required for rx is the responsibility
of the stack which is why we announce a rwnd of sk_rcvbuf/2.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
diff --git a/net/sctp/output.c b/net/sctp/output.c
index b4f3cf0..ceb55b2 100644
--- a/net/sctp/output.c
+++ b/net/sctp/output.c
@@ -700,13 +700,7 @@ static void sctp_packet_append_data(struct sctp_packet *packet,
/* Keep track of how many bytes are in flight to the receiver. */
asoc->outqueue.outstanding_bytes += datasize;
- /* Update our view of the receiver's rwnd. Include sk_buff overhead
- * while updating peer.rwnd so that it reduces the chances of a
- * receiver running out of receive buffer space even when receive
- * window is still open. This can happen when a sender is sending
- * sending small messages.
- */
- datasize += sizeof(struct sk_buff);
+ /* Update our view of the receiver's rwnd. */
if (datasize < rwnd)
rwnd -= datasize;
else
^ permalink raw reply related
* winner
From: Microsoft @ 2011-06-23 18:56 UTC (permalink / raw)
You have won 500.000 GBP
send your phone number
and address
^ permalink raw reply
* Re: [PATCH 13/37] Remove unneeded version.h includes from drivers/net/
From: David Miller @ 2011-06-24 9:40 UTC (permalink / raw)
To: jj-IYz4IdjRLj0sV2N9l4h3zg
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
rmody-43mecJUBy8ZBDgjK7y7TUQ, oliver-Q6YOFhsQ4GZ7tPAFqOLdPg,
sathya.perla-laKkSmNT4hbQT0dZR+AlfA, xeb-JGs/UdohzUI,
wg-5Yr1BZd7O62+XT7JhA+gdA, leedom-ut6Up61K2wZBDgjK7y7TUQ,
ddutt-43mecJUBy8ZBDgjK7y7TUQ, shodgson-s/n/eUQHGBpZroRs9YW3xA,
ajit.khaparde-laKkSmNT4hbQT0dZR+AlfA,
bhutchings-s/n/eUQHGBpZroRs9YW3xA,
subbu.seetharaman-laKkSmNT4hbQT0dZR+AlfA,
linux-net-drivers-s/n/eUQHGBpZroRs9YW3xA,
trivial-DgEjT+Ai2ygdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
gregkh-l3A5Bk7waGM, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
chaoming_li-kXabqFNEczNtrwSWzY7KCg,
sjur.brandeland-0IS4wlFg1OjSUeElwK9/Pw,
Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ
In-Reply-To: <alpine.LNX.2.00.1106240017510.17688-h2p7t3/P30RzeRGmFJ5qR7ZzlVVXadcDXqFh9Ls21Oc@public.gmane.org>
From: Jesper Juhl <jj-IYz4IdjRLj0sV2N9l4h3zg@public.gmane.org>
Date: Fri, 24 Jun 2011 00:21:10 +0200 (CEST)
> It was pointed out by 'make versioncheck' that some includes of
> linux/version.h are not needed in drivers/net/.
> This patch removes them.
>
> Signed-off-by: Jesper Juhl <jj-IYz4IdjRLj0sV2N9l4h3zg@public.gmane.org>
Applied, thanks.
^ permalink raw reply
* Re: [RFC PATCH 0/1] BPF JIT for PPC64
From: Kumar Gala @ 2011-06-24 9:16 UTC (permalink / raw)
To: Matt Evans; +Cc: netdev, linuxppc-dev
In-Reply-To: <4E042867.5020902@ozlabs.org>
On Jun 24, 2011, at 1:02 AM, Matt Evans wrote:
> Hi,
>
>
> Inspired by Eric Dumazet's x86-64 compiler for Berkeley Packet Filter programs,
> I've written a BPF compiler for 64-bit PowerPC. Although it hasn't finished its
> strenuous testing regime, I'll have intermittent net access for a couple of
> weeks so thought I'd post it for feedback now and submit a 'proper' version when
> I'm back.
>
> It's a fairly simple code generator, following a similar structure to the x86
> version. The filter programs are an array of opcode/constant/branch destination
> structs, and can perform arithmetic/logical/comparison operations on two virtual
> registers A and X, loads from packet headers/data and accesses to local
> variables, M[]. Branching is also supported, but only forwards and only within
> the extent of the program.
>
> I would probably describe this as more of a "static template binary translator"
> than a "JIT" but have kept naming consistent :)
>
>
> Features include:
>
> - Filter code is generated as an ABI-compliant function, stackframe &
> prologue/epilogue if necessary.
>
> - Simple filters (e.g. RET nn) need no stackframe or save/restore code so
> generate into only an li/blr.
>
> - Local variables, M[], live in registers
>
> - I believe this supports all BPF opcodes, although "complicated" loads from
> negative packet offsets (e.g. SKF_LL_OFF) are not yet supported.
>
> Caveats include: :)
>
> - Packet data loads call out to simple helper functions (bpf_jit.S) which
> themselves may fall back to a trampoline to skb_copy_bits. I haven't decided
> whether (as per comments there) it would be better to generate the simple
> loads inline and only call out in the slow case.
>
> - Branches currently generate to "bcc 1f; b <far dest>; 1:" or
> "bcc <near dest> ; nop" so either case is the same size. Multiple passes of
> assembly are used (the first gets an idea of how big everything is and what
> features are required), the next generates everything at accurate size, the
> third generates everything with accurate branch destination addresses); I
> intend not to nop-pad the short branch case but changing code size may
> result in more passes and a 'settling-down period'. Kept simple for now.
>
> - Anyone running PPC64 little-endian is doing something both interesting and
> unsupported for this work :-) (There are some trivial endian assumptions.)
>
> Tested in-situ (tcpdump with varying complexity filters) and with a random BPF
> generator; I haven't verified loads from the fall back skb_copy_bits path. Bug
> reports/testing would be very welcome.
Would be nice to get PPC32 support as well.
- k
^ permalink raw reply
* RE: [PATCH net-next-2.6 1/3] be2net: fix netdev_stats_update
From: Sathya.Perla @ 2011-06-24 8:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1308911520.2228.1.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
>-----Original Message-----
>From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
>Sent: Friday, June 24, 2011 4:02 PM
>To: Perla, Sathya
>Cc: netdev@vger.kernel.org
>Subject: Re: [PATCH net-next-2.6 1/3] be2net: fix netdev_stats_update
>
>Le vendredi 24 juin 2011 à 13:43 +0530, Sathya Perla a écrit :
>> netdev_stats_update() resets netdev->stats and then accumulates stats from
>> various rings. This is wrong as stats readers can sometimes catch zero
>values.
>> Use temporary variables instead for accumulating per-ring values.
>>
>> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
>> ---
>
>
>Hmm, isnt it a patch I provided 10 days ago ?
>
>I find very strange so few people are able to properly attribute work
>today...
>
Yes, this patch is indeed based on your suggested-fix patch last week.
Sorry, are you referring to the fact that I missed a "Signed-off-by-Eric"?
If so, my bad, I'll resend this patch with that line...
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: mark socketcan-core lists as subscribers-only
From: Marc Kleine-Budde @ 2011-06-24 8:48 UTC (permalink / raw)
To: Mike Frysinger
Cc: Urs Thuermann, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Oliver Hartkopp,
Andrew Morton, David S. Miller
In-Reply-To: <1308875142-10429-1-git-send-email-vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 449 bytes --]
On 06/24/2011 02:25 AM, Mike Frysinger wrote:
> The socketcan-core lists require subscription, so mark them as such.
what about making this list open instead?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/3] be2net: fix netdev_stats_update
From: Eric Dumazet @ 2011-06-24 10:32 UTC (permalink / raw)
To: Sathya Perla; +Cc: netdev
In-Reply-To: <913f4373-e01f-4aa9-b8c7-d041d70f0945@exht1.ad.emulex.com>
Le vendredi 24 juin 2011 à 13:43 +0530, Sathya Perla a écrit :
> netdev_stats_update() resets netdev->stats and then accumulates stats from
> various rings. This is wrong as stats readers can sometimes catch zero values.
> Use temporary variables instead for accumulating per-ring values.
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
> ---
> drivers/net/benet/be_main.c | 29 +++++++++++++++++------------
> 1 files changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
> index c4f564c..5ca06b0 100644
> --- a/drivers/net/benet/be_main.c
> +++ b/drivers/net/benet/be_main.c
> @@ -428,33 +428,38 @@ void netdev_stats_update(struct be_adapter *adapter)
> struct net_device_stats *dev_stats = &adapter->netdev->stats;
> struct be_rx_obj *rxo;
> struct be_tx_obj *txo;
> + unsigned long pkts = 0, bytes = 0, mcast = 0, drops = 0;
> int i;
>
> - memset(dev_stats, 0, sizeof(*dev_stats));
> for_all_rx_queues(adapter, rxo, i) {
> - dev_stats->rx_packets += rx_stats(rxo)->rx_pkts;
> - dev_stats->rx_bytes += rx_stats(rxo)->rx_bytes;
> - dev_stats->multicast += rx_stats(rxo)->rx_mcast_pkts;
> + pkts += rx_stats(rxo)->rx_pkts;
> + bytes += rx_stats(rxo)->rx_bytes;
> + mcast += rx_stats(rxo)->rx_mcast_pkts;
> /* no space in linux buffers: best possible approximation */
> if (adapter->generation == BE_GEN3) {
> if (!(lancer_chip(adapter))) {
> - struct be_erx_stats_v1 *erx_stats =
> + struct be_erx_stats_v1 *erx =
> be_erx_stats_from_cmd(adapter);
> - dev_stats->rx_dropped +=
> - erx_stats->rx_drops_no_fragments[rxo->q.id];
> + drops += erx->rx_drops_no_fragments[rxo->q.id];
> }
> } else {
> - struct be_erx_stats_v0 *erx_stats =
> + struct be_erx_stats_v0 *erx =
> be_erx_stats_from_cmd(adapter);
> - dev_stats->rx_dropped +=
> - erx_stats->rx_drops_no_fragments[rxo->q.id];
> + drops += erx->rx_drops_no_fragments[rxo->q.id];
> }
> }
> + dev_stats->rx_packets = pkts;
> + dev_stats->rx_bytes = bytes;
> + dev_stats->multicast = mcast;
> + dev_stats->rx_dropped = drops;
>
> + pkts = bytes = 0;
> for_all_tx_queues(adapter, txo, i) {
> - dev_stats->tx_packets += tx_stats(txo)->be_tx_pkts;
> - dev_stats->tx_bytes += tx_stats(txo)->be_tx_bytes;
> + pkts += tx_stats(txo)->be_tx_pkts;
> + bytes += tx_stats(txo)->be_tx_bytes;
> }
> + dev_stats->tx_packets = pkts;
> + dev_stats->tx_bytes = bytes;
>
> /* bad pkts received */
> dev_stats->rx_errors = drvs->rx_crc_errors +
Hmm, isnt it a patch I provided 10 days ago ?
I find very strange so few people are able to properly attribute work
today...
^ permalink raw reply
* Re: [PATCH net-next 0/7] qlcnic: Misc. fixes and loopback support
From: David Miller @ 2011-06-24 8:18 UTC (permalink / raw)
To: anirban.chakraborty; +Cc: netdev
In-Reply-To: <1308747144-23785-8-git-send-email-anirban.chakraborty@qlogic.com>
From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Date: Wed, 22 Jun 2011 05:52:24 -0700
> Please apply the series to net-next. Thanks.
All applied, thanks.
^ permalink raw reply
* [PATCH net-next-2.6 3/3] be2net: fix initialization of vlan_prio_bmap
From: Sathya Perla @ 2011-06-24 8:14 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla
Initialization of this field to "all priorities" must be done before MCC queue
creation. As soon as the MCC queue is created, an event modifying this value
may be received.
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/benet/be_main.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 2373d39..ae281de 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -2554,6 +2554,9 @@ static int be_setup(struct be_adapter *adapter)
if (status != 0)
goto tx_qs_destroy;
+ /* Allow all priorities by default. A GRP5 evt may modify this */
+ adapter->vlan_prio_bmap = 0xff;
+
status = be_mcc_queues_create(adapter);
if (status != 0)
goto rx_qs_destroy;
@@ -3419,10 +3422,6 @@ static int __devinit be_probe(struct pci_dev *pdev,
}
dev_info(&pdev->dev, "%s port %d\n", nic_name(pdev), adapter->port_num);
- /* By default all priorities are enabled.
- * Needed in case of no GRP5 evt support
- */
- adapter->vlan_prio_bmap = 0xff;
schedule_delayed_work(&adapter->work, msecs_to_jiffies(100));
return 0;
--
1.7.4
^ permalink raw reply related
* [PATCH net-next-2.6 2/3] be2net: get rid of multi_rxq module param
From: Sathya Perla @ 2011-06-24 8:13 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/benet/be_main.c | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 5ca06b0..2373d39 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -33,10 +33,6 @@ module_param(num_vfs, uint, S_IRUGO);
MODULE_PARM_DESC(rx_frag_size, "Size of a fragment that holds rcvd data.");
MODULE_PARM_DESC(num_vfs, "Number of PCI VFs to initialize");
-static bool multi_rxq = true;
-module_param(multi_rxq, bool, S_IRUGO | S_IWUSR);
-MODULE_PARM_DESC(multi_rxq, "Multi Rx Queue support. Enabled by default");
-
static DEFINE_PCI_DEVICE_TABLE(be_dev_ids) = {
{ PCI_DEVICE(BE_VENDOR_ID, BE_DEVICE_ID1) },
{ PCI_DEVICE(BE_VENDOR_ID, BE_DEVICE_ID2) },
@@ -1785,7 +1781,7 @@ static void be_rx_queues_destroy(struct be_adapter *adapter)
static u32 be_num_rxqs_want(struct be_adapter *adapter)
{
- if (multi_rxq && (adapter->function_caps & BE_FUNCTION_CAPS_RSS) &&
+ if ((adapter->function_caps & BE_FUNCTION_CAPS_RSS) &&
!adapter->sriov_enabled && !(adapter->function_mode & 0x400)) {
return 1 + MAX_RSS_QS; /* one default non-RSS queue */
} else {
--
1.7.4
^ permalink raw reply related
* [PATCH net-next-2.6 1/3] be2net: fix netdev_stats_update
From: Sathya Perla @ 2011-06-24 8:13 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla
netdev_stats_update() resets netdev->stats and then accumulates stats from
various rings. This is wrong as stats readers can sometimes catch zero values.
Use temporary variables instead for accumulating per-ring values.
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/benet/be_main.c | 29 +++++++++++++++++------------
1 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index c4f564c..5ca06b0 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -428,33 +428,38 @@ void netdev_stats_update(struct be_adapter *adapter)
struct net_device_stats *dev_stats = &adapter->netdev->stats;
struct be_rx_obj *rxo;
struct be_tx_obj *txo;
+ unsigned long pkts = 0, bytes = 0, mcast = 0, drops = 0;
int i;
- memset(dev_stats, 0, sizeof(*dev_stats));
for_all_rx_queues(adapter, rxo, i) {
- dev_stats->rx_packets += rx_stats(rxo)->rx_pkts;
- dev_stats->rx_bytes += rx_stats(rxo)->rx_bytes;
- dev_stats->multicast += rx_stats(rxo)->rx_mcast_pkts;
+ pkts += rx_stats(rxo)->rx_pkts;
+ bytes += rx_stats(rxo)->rx_bytes;
+ mcast += rx_stats(rxo)->rx_mcast_pkts;
/* no space in linux buffers: best possible approximation */
if (adapter->generation == BE_GEN3) {
if (!(lancer_chip(adapter))) {
- struct be_erx_stats_v1 *erx_stats =
+ struct be_erx_stats_v1 *erx =
be_erx_stats_from_cmd(adapter);
- dev_stats->rx_dropped +=
- erx_stats->rx_drops_no_fragments[rxo->q.id];
+ drops += erx->rx_drops_no_fragments[rxo->q.id];
}
} else {
- struct be_erx_stats_v0 *erx_stats =
+ struct be_erx_stats_v0 *erx =
be_erx_stats_from_cmd(adapter);
- dev_stats->rx_dropped +=
- erx_stats->rx_drops_no_fragments[rxo->q.id];
+ drops += erx->rx_drops_no_fragments[rxo->q.id];
}
}
+ dev_stats->rx_packets = pkts;
+ dev_stats->rx_bytes = bytes;
+ dev_stats->multicast = mcast;
+ dev_stats->rx_dropped = drops;
+ pkts = bytes = 0;
for_all_tx_queues(adapter, txo, i) {
- dev_stats->tx_packets += tx_stats(txo)->be_tx_pkts;
- dev_stats->tx_bytes += tx_stats(txo)->be_tx_bytes;
+ pkts += tx_stats(txo)->be_tx_pkts;
+ bytes += tx_stats(txo)->be_tx_bytes;
}
+ dev_stats->tx_packets = pkts;
+ dev_stats->tx_bytes = bytes;
/* bad pkts received */
dev_stats->rx_errors = drvs->rx_crc_errors +
--
1.7.4
^ permalink raw reply related
* [PATCH NET-NEXT] net: Kill unuseful net/TUNABLE doc in kernel source
From: Shan Wei @ 2011-06-24 7:53 UTC (permalink / raw)
To: David Miller, netdev
File net/TUNABLE has never be updated since git age.
For some tunable parameters which user can control with proc file-system,
They are all in ip-sysctl.txt doc.
For tunable parameters that only at compile time, no meaning to note them.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
---
net/TUNABLE | 50 --------------------------------------------------
1 files changed, 0 insertions(+), 50 deletions(-)
delete mode 100644 net/TUNABLE
diff --git a/net/TUNABLE b/net/TUNABLE
deleted file mode 100644
index 9913211..0000000
--- a/net/TUNABLE
+++ /dev/null
@@ -1,50 +0,0 @@
-The following parameters should be tunable at compile time. Some of them
-exist as sysctls too.
-
-This is far from complete
-
-Item Description
-----------------------------------------------------------------------------
-MAX_LINKS Maximum number of netlink minor devices. (1-32)
-RIF_TABLE_SIZE Token ring RIF cache size (tunable)
-AARP_HASH_SIZE Size of Appletalk hash table (tunable)
-AX25_DEF_T1 AX.25 parameters. These are all tunable via
-AX25_DEF_T2 SIOCAX25SETPARMS
-AX25_DEF_T3 T1-T3,N2 have the meanings in the specification
-AX25_DEF_N2
-AX25_DEF_AXDEFMODE 8 = normal 128 is PE1CHL extended
-AX25_DEF_IPDEFMODE 'D' - datagram 'V' - virtual connection
-AX25_DEF_BACKOFF 'E'xponential 'L'inear
-AX25_DEF_NETROM Allow netrom 1=Y
-AX25_DF_TEXT Allow PID=Text 1=Y
-AX25_DEF_WINDOW Window for normal mode
-AX25_DEF_EWINDOW Window for PE1CHL mode
-AX25_DEF_DIGI 1 for inband 2 for cross band 3 for both
-AX25_DEF_CONMODE Allow connected modes 1=Yes
-AX25_ROUTE_MAX AX.25 route cache size - no currently tunable
-Unnamed (16) Number of protocol hash slots (tunable)
-DEV_NUMBUFFS Number of priority levels (not easily tunable)
-Unnamed (300) Maximum packet backlog queue (tunable)
-MAX_IOVEC Maximum number of iovecs in a message (tunable)
-MIN_WINDOW Offered minimum window (tunable)
-MAX_WINDOW Offered maximum window (tunable)
-MAX_HEADER Largest physical header (tunable)
-MAX_ADDR_LEN Largest physical address (tunable)
-SOCK_ARRAY_SIZE IP socket array hash size (tunable)
-IP_MAX_MEMBERSHIPS Largest number of groups per socket (BSD style) (tunable)
-16 Hard coded constant for amount of room allowed for
- cache align and faster forwarding (tunable)
-IP_FRAG_TIME Time we hold a fragment for. (tunable)
-PORT_MASQ_BEGIN First port reserved for masquerade (tunable)
-PORT_MASQ_END Last port used for masquerade (tunable)
-MASQUERADE_EXPIRE_TCP_FIN Time we keep a masquerade for after a FIN
-MASQUERADE_EXPIRE_UDP Time we keep a UDP masquerade for (tunable)
-MAXVIFS Maximum mrouted vifs (1-32)
-MFC_LINES Lines in the multicast router cache (tunable)
-
-NetROM parameters are tunable via an ioctl passing a struct
-
-4000 Size a Unix domain socket malloc falls back to
- (tunable) should be 8K - a bit for 8K machines like
- the ALPHA
-
--
1.7.4.1
^ permalink raw reply related
* Re: Is File net/TUNABLE in kernel source still useful?
From: David Miller @ 2011-06-24 7:39 UTC (permalink / raw)
To: shanwei; +Cc: netdev
In-Reply-To: <4E04376F.1040607@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
Date: Fri, 24 Jun 2011 15:06:23 +0800
> So many ones and seems no meaning.
> Directly send a patch to kill it, OK?
Sure.
^ permalink raw reply
* Re: [PATCH 1/2] rt2x00: Fix unspeficied typo
From: Ivo Van Doorn @ 2011-06-24 7:34 UTC (permalink / raw)
To: Joe Perches
Cc: Gertjan van Wingerde, Helmut Schaa, John W. Linville,
linux-wireless, users, netdev, linux-kernel
In-Reply-To: <6002eb70809bb1c87c84f32ab4a4f034d2d1ffb5.1308868289.git.joe@perches.com>
On Fri, Jun 24, 2011 at 12:35 AM, Joe Perches <joe@perches.com> wrote:
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2x00queue.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.h b/drivers/net/wireless/rt2x00/rt2x00queue.h
> index 167d458..5900474 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00queue.h
> +++ b/drivers/net/wireless/rt2x00/rt2x00queue.h
> @@ -54,7 +54,7 @@
> * @QID_RX: RX queue
> * @QID_OTHER: None of the above (don't use, only present for completeness)
> * @QID_BEACON: Beacon queue (value unspecified, don't send it to device)
> - * @QID_ATIM: Atim queue (value unspeficied, don't send it to device)
> + * @QID_ATIM: Atim queue (value unspecified, don't send it to device)
> */
> enum data_queue_qid {
> QID_AC_VO = 0,
> --
> 1.7.6.rc1
>
>
^ permalink raw reply
* Is File net/TUNABLE in kernel source still useful?
From: Shan Wei @ 2011-06-24 7:06 UTC (permalink / raw)
To: David Miller, netdev, 单卫
Hi David，
File net/TUNABLE has never be updated since git age.
For some tunable parameters which user can control with proc file-system,
They are all in ip-sysctl.txt doc.
But for tunable parameters that only at compile time,
Do we really need this document to maintain them?
So many ones and seems no meaning.
Directly send a patch to kill it, OK?
--
Best Regards
-----
Shan Wei
^ permalink raw reply
* Re: [net-next 00/11][pull request] Intel Wired LAN Driver Update
From: David Miller @ 2011-06-24 6:52 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo
In-Reply-To: <1308895397-23133-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 23 Jun 2011 23:03:06 -0700
> The following series contains updates to ixgbe. There are 2 fixes, along
> with several cleanups from Alex and Emil. In addition, nfc support was added
> as well as bumping the driver version.
>
> Dropped patch 7 (ixgbe: add support for modifying UDP RSS flow hash options)
> from the previous submission based on comments from Ben H.
>
> The following are changes since commit 4d054f2f1445aceedab3f9642692d55d2caa7ec6:
> dcb: use nlmsg_free() instead of kfree()
> and are available in the git repository at:
> master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6 master
Pulled, thanks Jeff.
^ 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