* 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
* [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
* 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
* 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] 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] 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
* 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
* [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
* 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
* 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
* 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] sctp: Reducing rwnd by sizeof(struct sk_buff) for each CHUNK is too aggressive
From: Vladislav Yasevich @ 2011-06-24 13:48 UTC (permalink / raw)
To: Sridhar Samudrala, linux-sctp, netdev
In-Reply-To: <20110624101535.GB9222@canuck.infradead.org>
On 06/24/2011 06:15 AM, Thomas Graf wrote:
> 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
>
Hi Thomas
I believe there was work in progress to change how window is computed. The issue with
your current patch is that it is possible to consume all of the receive buffer space while
still having an open receive window. We've seen it in real life which is why the above band-aid
was applied.
The correct patch should really something similar to TCP, where receive window is computed as
a percentage of the available receive buffer space at every adjustment. This should also take into
account SWS on the sender side.
Someone started implementing that code, but I am not sure where it currently is.
Thanks
-vlad
^ permalink raw reply
* Re: ppp_deflate + kmalloc
From: James Carlson @ 2011-06-24 14:02 UTC (permalink / raw)
To: Martin Jackson; +Cc: paulus, linux-ppp, netdev
In-Reply-To: <BANLkTi=+2dqr1LPwG8MHpcYOyzJH57iavw@mail.gmail.com>
Martin Jackson wrote:
> 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?
The code here shouldn't need contiguous pages, so vmalloc (even if
"slower") shouldn't be a problem.
But a higher-level question might be why you're bothering with RFC 1979
Deflate compression at all on this platform. I'd expect that you're
most likely going to end up talking to commercially-produced PPP servers
(possibly 3GPP or similar) at the other end, and very, very few of them
offer data compression with either RFC 1977 (BSD Compression) or RFC
1979. ("Very, very few" is probably being generous ...)
If it's always going to be negotiated away in practice, and if you're
having trouble with memory constraints, why not just ditch the baggage?
--
James Carlson 42.703N 71.076W <carlsonj@workingcode.com>
^ permalink raw reply
* Re: [PATCH 1/2] iwlwifi: use pci_dev->revision, again
From: wwguy @ 2011-06-24 14:08 UTC (permalink / raw)
To: Sergei Shtylyov
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: <4E046A9F.9020909-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
On Fri, 2011-06-24 at 03:44 -0700, Sergei Shtylyov wrote:
> 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...
>
> >
I don't believe this patch is needed since the "log" statement is move
to outside the function.
Thanks
Wey
--
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
* Re: [PATCH] MAINTAINERS: mark socketcan-core lists as subscribers-only
From: Mike Frysinger @ 2011-06-24 14:28 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Urs Thuermann, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Oliver Hartkopp,
Andrew Morton, David S. Miller
In-Reply-To: <4E044F4B.7010707-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Fri, Jun 24, 2011 at 04:48, Marc Kleine-Budde wrote:
> 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?
i have no problem with that, but i have nothing to do with the
socket-can project, so it isnt my call.
-mike
^ permalink raw reply
* Re: [uclinux-dist-devel] [PATCH 1/2] can: bfin_can: simplify xmit id1 setup
From: Mike Frysinger @ 2011-06-24 14:32 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, Urs Thuermann, David S. Miller,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
In-Reply-To: <4E046AFE.5000109-l29pVbxQd1IUtdQbppsyvg@public.gmane.org>
On Fri, Jun 24, 2011 at 06:46, Oliver Hartkopp wrote:
> In MAINTAINERS there are entries for the CAN NETWORK LAYER and for CAN
> NETWORK DRIVERS which addresses the code in drivers/net/can/...
hmm, wonder when this changed. oh well, updated local .git/mail now.
> Additionally you should address your patch to the author of the driver
> (Barry Song <21cnbao-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>).
he's already in the cc list. he's an ADI employee (like me) who
watches the Blackfin mailing lists.
-mike
^ permalink raw reply
* [PATCH 1/2] can: bfin_can: simplify xmit id1 setup
From: Mike Frysinger @ 2011-06-24 14:33 UTC (permalink / raw)
To: socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Wolfgang Grandegger,
netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller
Cc: uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
If we look closely, the 4 writes to TRANSMIT_CHL.id1 can be collapsed
down into much simpler code. So do just that.
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) {
--
1.7.5.3
^ permalink raw reply related
* [PATCH 2/2] can: bfin_can: auto-calculate accessor sizes
From: Mike Frysinger @ 2011-06-24 14:33 UTC (permalink / raw)
To: socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Wolfgang Grandegger,
netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller
Cc: uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
In-Reply-To: <1308925982-14645-1-git-send-email-vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
Since we have a struct that defines the sizes of the registers, we don't
need to explicitly use the 16bit read/write helpers. Let the code figure
out which size access to make based on the size of the C type.
There should be no functional changes here.
Signed-off-by: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
---
drivers/net/can/bfin_can.c | 118 ++++++++++++++++++++++----------------------
1 files changed, 59 insertions(+), 59 deletions(-)
diff --git a/drivers/net/can/bfin_can.c b/drivers/net/can/bfin_can.c
index dc6ef4a..a1c5abc 100644
--- a/drivers/net/can/bfin_can.c
+++ b/drivers/net/can/bfin_can.c
@@ -79,8 +79,8 @@ static int bfin_can_set_bittiming(struct net_device *dev)
if (priv->can.ctrlmode & CAN_CTRLMODE_3_SAMPLES)
timing |= SAM;
- bfin_write16(®->clock, clk);
- bfin_write16(®->timing, timing);
+ bfin_write(®->clock, clk);
+ bfin_write(®->timing, timing);
dev_info(dev->dev.parent, "setting CLOCK=0x%04x TIMING=0x%04x\n",
clk, timing);
@@ -96,16 +96,16 @@ static void bfin_can_set_reset_mode(struct net_device *dev)
int i;
/* disable interrupts */
- bfin_write16(®->mbim1, 0);
- bfin_write16(®->mbim2, 0);
- bfin_write16(®->gim, 0);
+ bfin_write(®->mbim1, 0);
+ bfin_write(®->mbim2, 0);
+ bfin_write(®->gim, 0);
/* reset can and enter configuration mode */
- bfin_write16(®->control, SRS | CCR);
+ bfin_write(®->control, SRS | CCR);
SSYNC();
- bfin_write16(®->control, CCR);
+ bfin_write(®->control, CCR);
SSYNC();
- while (!(bfin_read16(®->control) & CCA)) {
+ while (!(bfin_read(®->control) & CCA)) {
udelay(10);
if (--timeout == 0) {
dev_err(dev->dev.parent,
@@ -119,33 +119,33 @@ static void bfin_can_set_reset_mode(struct net_device *dev)
* by writing to CAN Mailbox Configuration Registers 1 and 2
* For all bits: 0 - Mailbox disabled, 1 - Mailbox enabled
*/
- bfin_write16(®->mc1, 0);
- bfin_write16(®->mc2, 0);
+ bfin_write(®->mc1, 0);
+ bfin_write(®->mc2, 0);
/* Set Mailbox Direction */
- bfin_write16(®->md1, 0xFFFF); /* mailbox 1-16 are RX */
- bfin_write16(®->md2, 0); /* mailbox 17-32 are TX */
+ bfin_write(®->md1, 0xFFFF); /* mailbox 1-16 are RX */
+ bfin_write(®->md2, 0); /* mailbox 17-32 are TX */
/* RECEIVE_STD_CHL */
for (i = 0; i < 2; i++) {
- bfin_write16(®->chl[RECEIVE_STD_CHL + i].id0, 0);
- bfin_write16(®->chl[RECEIVE_STD_CHL + i].id1, AME);
- bfin_write16(®->chl[RECEIVE_STD_CHL + i].dlc, 0);
- bfin_write16(®->msk[RECEIVE_STD_CHL + i].amh, 0x1FFF);
- bfin_write16(®->msk[RECEIVE_STD_CHL + i].aml, 0xFFFF);
+ bfin_write(®->chl[RECEIVE_STD_CHL + i].id0, 0);
+ bfin_write(®->chl[RECEIVE_STD_CHL + i].id1, AME);
+ bfin_write(®->chl[RECEIVE_STD_CHL + i].dlc, 0);
+ bfin_write(®->msk[RECEIVE_STD_CHL + i].amh, 0x1FFF);
+ bfin_write(®->msk[RECEIVE_STD_CHL + i].aml, 0xFFFF);
}
/* RECEIVE_EXT_CHL */
for (i = 0; i < 2; i++) {
- bfin_write16(®->chl[RECEIVE_EXT_CHL + i].id0, 0);
- bfin_write16(®->chl[RECEIVE_EXT_CHL + i].id1, AME | IDE);
- bfin_write16(®->chl[RECEIVE_EXT_CHL + i].dlc, 0);
- bfin_write16(®->msk[RECEIVE_EXT_CHL + i].amh, 0x1FFF);
- bfin_write16(®->msk[RECEIVE_EXT_CHL + i].aml, 0xFFFF);
+ bfin_write(®->chl[RECEIVE_EXT_CHL + i].id0, 0);
+ bfin_write(®->chl[RECEIVE_EXT_CHL + i].id1, AME | IDE);
+ bfin_write(®->chl[RECEIVE_EXT_CHL + i].dlc, 0);
+ bfin_write(®->msk[RECEIVE_EXT_CHL + i].amh, 0x1FFF);
+ bfin_write(®->msk[RECEIVE_EXT_CHL + i].aml, 0xFFFF);
}
- bfin_write16(®->mc2, BIT(TRANSMIT_CHL - 16));
- bfin_write16(®->mc1, BIT(RECEIVE_STD_CHL) + BIT(RECEIVE_EXT_CHL));
+ bfin_write(®->mc2, BIT(TRANSMIT_CHL - 16));
+ bfin_write(®->mc1, BIT(RECEIVE_STD_CHL) + BIT(RECEIVE_EXT_CHL));
SSYNC();
priv->can.state = CAN_STATE_STOPPED;
@@ -160,9 +160,9 @@ static void bfin_can_set_normal_mode(struct net_device *dev)
/*
* leave configuration mode
*/
- bfin_write16(®->control, bfin_read16(®->control) & ~CCR);
+ bfin_write(®->control, bfin_read(®->control) & ~CCR);
- while (bfin_read16(®->status) & CCA) {
+ while (bfin_read(®->status) & CCA) {
udelay(10);
if (--timeout == 0) {
dev_err(dev->dev.parent,
@@ -174,25 +174,25 @@ static void bfin_can_set_normal_mode(struct net_device *dev)
/*
* clear _All_ tx and rx interrupts
*/
- bfin_write16(®->mbtif1, 0xFFFF);
- bfin_write16(®->mbtif2, 0xFFFF);
- bfin_write16(®->mbrif1, 0xFFFF);
- bfin_write16(®->mbrif2, 0xFFFF);
+ bfin_write(®->mbtif1, 0xFFFF);
+ bfin_write(®->mbtif2, 0xFFFF);
+ bfin_write(®->mbrif1, 0xFFFF);
+ bfin_write(®->mbrif2, 0xFFFF);
/*
* clear global interrupt status register
*/
- bfin_write16(®->gis, 0x7FF); /* overwrites with '1' */
+ bfin_write(®->gis, 0x7FF); /* overwrites with '1' */
/*
* Initialize Interrupts
* - set bits in the mailbox interrupt mask register
* - global interrupt mask
*/
- bfin_write16(®->mbim1, BIT(RECEIVE_STD_CHL) + BIT(RECEIVE_EXT_CHL));
- bfin_write16(®->mbim2, BIT(TRANSMIT_CHL - 16));
+ bfin_write(®->mbim1, BIT(RECEIVE_STD_CHL) + BIT(RECEIVE_EXT_CHL));
+ bfin_write(®->mbim2, BIT(TRANSMIT_CHL - 16));
- bfin_write16(®->gim, EPIM | BOIM | RMLIM);
+ bfin_write(®->gim, EPIM | BOIM | RMLIM);
SSYNC();
}
@@ -242,28 +242,28 @@ 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);
+ bfin_write(®->chl[TRANSMIT_CHL].id0, id);
val = ((id & 0x1FFF0000) >> 16) | IDE;
} else
val = (id << 2);
if (id & CAN_RTR_FLAG)
val |= RTR;
- bfin_write16(®->chl[TRANSMIT_CHL].id1, val | AME);
+ bfin_write(®->chl[TRANSMIT_CHL].id1, val | AME);
/* fill payload */
for (i = 0; i < 8; i += 2) {
val = ((7 - i) < dlc ? (data[7 - i]) : 0) +
((6 - i) < dlc ? (data[6 - i] << 8) : 0);
- bfin_write16(®->chl[TRANSMIT_CHL].data[i], val);
+ bfin_write(®->chl[TRANSMIT_CHL].data[i], val);
}
/* fill data length code */
- bfin_write16(®->chl[TRANSMIT_CHL].dlc, dlc);
+ bfin_write(®->chl[TRANSMIT_CHL].dlc, dlc);
can_put_echo_skb(skb, dev, 0);
/* set transmit request */
- bfin_write16(®->trs2, BIT(TRANSMIT_CHL - 16));
+ bfin_write(®->trs2, BIT(TRANSMIT_CHL - 16));
return 0;
}
@@ -286,26 +286,26 @@ static void bfin_can_rx(struct net_device *dev, u16 isrc)
/* get id */
if (isrc & BIT(RECEIVE_EXT_CHL)) {
/* extended frame format (EFF) */
- cf->can_id = ((bfin_read16(®->chl[RECEIVE_EXT_CHL].id1)
+ cf->can_id = ((bfin_read(®->chl[RECEIVE_EXT_CHL].id1)
& 0x1FFF) << 16)
- + bfin_read16(®->chl[RECEIVE_EXT_CHL].id0);
+ + bfin_read(®->chl[RECEIVE_EXT_CHL].id0);
cf->can_id |= CAN_EFF_FLAG;
obj = RECEIVE_EXT_CHL;
} else {
/* standard frame format (SFF) */
- cf->can_id = (bfin_read16(®->chl[RECEIVE_STD_CHL].id1)
+ cf->can_id = (bfin_read(®->chl[RECEIVE_STD_CHL].id1)
& 0x1ffc) >> 2;
obj = RECEIVE_STD_CHL;
}
- if (bfin_read16(®->chl[obj].id1) & RTR)
+ if (bfin_read(®->chl[obj].id1) & RTR)
cf->can_id |= CAN_RTR_FLAG;
/* get data length code */
- cf->can_dlc = get_can_dlc(bfin_read16(®->chl[obj].dlc) & 0xF);
+ cf->can_dlc = get_can_dlc(bfin_read(®->chl[obj].dlc) & 0xF);
/* get payload */
for (i = 0; i < 8; i += 2) {
- val = bfin_read16(®->chl[obj].data[i]);
+ val = bfin_read(®->chl[obj].data[i]);
cf->data[7 - i] = (7 - i) < cf->can_dlc ? val : 0;
cf->data[6 - i] = (6 - i) < cf->can_dlc ? (val >> 8) : 0;
}
@@ -359,7 +359,7 @@ static int bfin_can_err(struct net_device *dev, u16 isrc, u16 status)
if (state != priv->can.state && (state == CAN_STATE_ERROR_WARNING ||
state == CAN_STATE_ERROR_PASSIVE)) {
- u16 cec = bfin_read16(®->cec);
+ u16 cec = bfin_read(®->cec);
u8 rxerr = cec;
u8 txerr = cec >> 8;
@@ -410,23 +410,23 @@ irqreturn_t bfin_can_interrupt(int irq, void *dev_id)
struct net_device_stats *stats = &dev->stats;
u16 status, isrc;
- if ((irq == priv->tx_irq) && bfin_read16(®->mbtif2)) {
+ if ((irq == priv->tx_irq) && bfin_read(®->mbtif2)) {
/* transmission complete interrupt */
- bfin_write16(®->mbtif2, 0xFFFF);
+ bfin_write(®->mbtif2, 0xFFFF);
stats->tx_packets++;
- stats->tx_bytes += bfin_read16(®->chl[TRANSMIT_CHL].dlc);
+ stats->tx_bytes += bfin_read(®->chl[TRANSMIT_CHL].dlc);
can_get_echo_skb(dev, 0);
netif_wake_queue(dev);
- } else if ((irq == priv->rx_irq) && bfin_read16(®->mbrif1)) {
+ } else if ((irq == priv->rx_irq) && bfin_read(®->mbrif1)) {
/* receive interrupt */
- isrc = bfin_read16(®->mbrif1);
- bfin_write16(®->mbrif1, 0xFFFF);
+ isrc = bfin_read(®->mbrif1);
+ bfin_write(®->mbrif1, 0xFFFF);
bfin_can_rx(dev, isrc);
- } else if ((irq == priv->err_irq) && bfin_read16(®->gis)) {
+ } else if ((irq == priv->err_irq) && bfin_read(®->gis)) {
/* error interrupt */
- isrc = bfin_read16(®->gis);
- status = bfin_read16(®->esr);
- bfin_write16(®->gis, 0x7FF);
+ isrc = bfin_read(®->gis);
+ status = bfin_read(®->esr);
+ bfin_write(®->gis, 0x7FF);
bfin_can_err(dev, isrc, status);
} else {
return IRQ_NONE;
@@ -631,9 +631,9 @@ static int bfin_can_suspend(struct platform_device *pdev, pm_message_t mesg)
if (netif_running(dev)) {
/* enter sleep mode */
- bfin_write16(®->control, bfin_read16(®->control) | SMR);
+ bfin_write(®->control, bfin_read(®->control) | SMR);
SSYNC();
- while (!(bfin_read16(®->intr) & SMACK)) {
+ while (!(bfin_read(®->intr) & SMACK)) {
udelay(10);
if (--timeout == 0) {
dev_err(dev->dev.parent,
@@ -654,7 +654,7 @@ static int bfin_can_resume(struct platform_device *pdev)
if (netif_running(dev)) {
/* leave sleep mode */
- bfin_write16(®->intr, 0);
+ bfin_write(®->intr, 0);
SSYNC();
}
--
1.7.5.3
^ permalink raw reply related
* Re: [PATCH]: Add Network Sysrq Support
From: John Haxby @ 2011-06-24 14:37 UTC (permalink / raw)
To: Florian Westphal
Cc: Prarit Bhargava, David Miller, fbl, netdev, agospoda, nhorman,
lwoodman
In-Reply-To: <20110622105434.GE16021@Chamillionaire.breakpoint.cc>
On 22/06/11 11:54, Florian Westphal wrote:
> Patrick McHardy suggested an alternative standalone method involving
> encapsulation sockets; perhaps the reasons why this path was not chosen
> have changed.
>
> I think that a standalone module (i.e. not requiring netfilter) that
> runs the sysreq handling after all netfilter hooks would be optimal,
> but I don't see a simple method to implement that.
Having just read the entire thread I have some different comments.
I think I mentioned that the standalone module didn't fly because I was
using an encapsulation socket: this preserved the ability to protect the
sysrq with iptables and also kept things nice and simple. Unfortunately
that also meant I lost IPv6 ....
One of the comments in the thread (sorry, I've lost the attribution, not
to mention the exact quote) was that you would be crazy to run this in
production. Hmmm. One of the principle use cases of this is
precisely to run the code in production: machines in production do go
AWOL for all kinds of reasons and being able to run sysrq-m, t, s and c
is particularly useful. It would be nice to be able to go up to the
machine and type on its keyboard. If only it was even on the same
continent. If only it a keyboard. Or even a PS/2 keyboard socket
(getting a USB keyboard to configure itself when the machine is wedged
is, well, unlikely).
The changes I made to the xt_SYSRQ hashing a while back to avoid things
like replay were precisely because it needs to be run in a production
environment. I've just submitted a patch that makes replay to other
machines that have the same password less likely to succeed, again, with
a view to how this thing would be used in production.
Sorry if I've repeated some things that have already been said.
jch
^ permalink raw reply
* Re: [PATCH 1/2] iwlwifi: use pci_dev->revision, again
From: Sergei Shtylyov @ 2011-06-24 14:37 UTC (permalink / raw)
To: wwguy
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: <1308924515.19001.2.camel@wwguy-ubuntu>
Hello.
wwguy 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...
> I don't believe this patch is needed since the "log" statement is move
> to outside the function.
That's what I'm talking about -- it's not needed in its current form, but I
will redo the patch to modify iwl-pci,c where iwl_pci_probe() still reads
PCI_REVISION_ID.
> Thanks
> 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
* Re: [PATCH] sctp: Reducing rwnd by sizeof(struct sk_buff) for each CHUNK is too aggressive
From: Thomas Graf @ 2011-06-24 14:42 UTC (permalink / raw)
To: Vladislav Yasevich; +Cc: Sridhar Samudrala, linux-sctp, netdev
In-Reply-To: <4E0495C3.30102@hp.com>
On Fri, Jun 24, 2011 at 09:48:51AM -0400, Vladislav Yasevich wrote:
> I believe there was work in progress to change how window is computed. The issue with
> your current patch is that it is possible to consume all of the receive buffer space while
> still having an open receive window. We've seen it in real life which is why the above band-aid
> was applied.
I don't understand this. The rwnd _announced_ is sk_rcvbuf/2 so we are
reserving half of sk_rcvbuf for structures like sk_buff. This means we
can use _all_ of rwnd for data. If the peer announces a a_rwnd of 1500
in the last SACK I expect that peer to be able to handle 1500 bytes of
data.
Regardless of that, why would we reserve a sk_buff for each chunk? We only
allocate an skb per packet which can have many chunks attached.
To me, this looks like a fix for broken sctp peers.
> The correct patch should really something similar to TCP, where receive window is computed as
> a percentage of the available receive buffer space at every adjustment. This should also take into
> account SWS on the sender side.
Can you elaborate this a little more? You want our view of the peer's receive
window to be computed as a percentage of the available receive buffer on our
side?
^ permalink raw reply
* Re: Skipping past TCP lost packet in userspace
From: Janardhan Iyengar @ 2011-06-24 14:58 UTC (permalink / raw)
To: rick.jones2; +Cc: Josh Lehan, Yuchung Cheng, netdev, Bryan Ford
In-Reply-To: <1306949723.8149.2202.camel@tardy>
[Reviving this thread... apologies for dropping it.]
Rick,
Thanks for your note. I agree that it does seem like we're simply adding to the metaphorical pile. And my first knee-jerk response would be that there's not much else one can do in the modern IPv4 Internet :-)
That said, I'd like to point out that when you say that problems at layer 4 need to be fixed, there are two kinds of changes that can be considered -- the layer 4 protocol, and the API it offers to apps. Changes to the API, which is what we're proposing, is not a modification to the transport layer protocol per se. In other words, we are changing the service that TCP offers to apps, and not the protocol.
The non-portability that you point out in the second part of your note, while a completely legitimate point, is again an API issue. While this API is non-portable because it doesn't exist in other OSes yet, that is a matter of time (hopefully), and we're hoping to start the process with Linux. And, it is easy enough for an app to fail over to using simple TCP behavior where the sockopt is not supported.
You also point out that we could perhaps fix the shortcomings of TCP by actively building and deploying alternative transports -- we've tried that and failed exactly because we've missed the point that the narrow waist of the Internet hourglass is no longer just IP, but includes TCP and UDP as well (and sometimes just TCP.) For the entire time I've been working with SCTP (since 2001), we've been working on and trying to get SCTP through middleboxes, but as it stands, we still only have pockets of success. Try using SCTP in the wild; your packets are quite likely to get black-holed within your home/ISP network. The problem with middleboxes is that the IETF missed the boat on providing standards for these devices, and there are very few (if any) points of pressure that can be applied to change these devices in the network. As a result, getting any new non-network-compatible transport deployed over the network remains untenable.
Our goal is to be able to provide new network services while remaining compatible with the network. As we see it, that is the only option that remains if we are to consider any new transport services beyond TCP's straitjacketed one. As it turns out, our work shows that we _can_ offer more services using the same TCP protocol, which is a win-win, since the new services remain network-compatible.
Note: I'm talking largely about the v4 Internet. The v6 Internet will hopefully have fewer devices that interpose on the transport layer, esp. NAPTs; however, I expect fully that firewalls and PEPs will still use transport layer information, requiring them to be able to read/understand transport header information.
- jana
On 6/1/11 1:35 PM, Rick Jones wrote:
> On Wed, 2011-06-01 at 01:10 -0700, Josh Lehan wrote:
>> On 05/31/2011 10:23 AM, Yuchung Cheng wrote:
>>> This paper may have a solution to your problem
>>> "Minion—an All-Terrain Packet Packhorse to Jump-Start Stalled Internet
>>> Transports"
>>> http://csweb1.fandm.edu/jiyengar/lair/papers/minion-pfldnet2010.pdf
>>
>> Nice, thanks for pointing me to this. I appreciate the helpful answer,
>> instead of just saying "use UDP" or "use SCTP". That's not the point.
>>
>> For better or for worse, TCP is realistically the only viable protocol
>> for streaming to the largest possible audience these days, hence my
>> question about adding this feature to the Linux TCP implementation.
>
> Isn't that treating the symptoms of problems at layers 8 and 9 (*) with
> kludges (perhaps hacks if one is feeling charitable) at the user
> interface to layer 4? Just how many more little bits can we add to the
> great pile before the aroma is overpowering? Or to abuse another
> metaphor, is there really any camel's back left here?
>
> And while Linux has had some slightly non-trivial, non-portable
> enhancements to its interface to a TCP endpoint (TCP_CORK is something
> that comes to mind) I don't think any of them have been anywhere nearly
> as large a change to a fundamental semantic of a TCP connection as what
> you propose.
>
> rick jones
>
> *
> http://www.isc.org/store/logoware-clothing/isc-9-layer-osi-model-cotton-t-shirt
>
>
--
Janardhan Iyengar
Assistant Professor, Computer Science
Franklin & Marshall College
http://www.fandm.edu/jiyengar
^ permalink raw reply
* af-packet tpacket_rcv - why is status flushed before the packet-payload ...
From: chetan loke @ 2011-06-24 15:20 UTC (permalink / raw)
To: netdev
Hi,
in tpacket_rcv() - this is the flushing sequence ...
1)
__packet_set_status(po, h.raw, status);
2)
smp_mb();
3)
#if ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE == 1
flush-the-payload
#endif
Why is it done this way?
Shouldn't we be flushing the packet_status after flushing the payload?
So 1 and 3 should be swapped, no?
Chetan Loke
^ permalink raw reply
* Re: [PATCH 1/2] iwlwifi: use pci_dev->revision, again
From: wwguy @ 2011-06-24 15:21 UTC (permalink / raw)
To: Sergei Shtylyov
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: <4E04A143.1090204-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
On Fri, 2011-06-24 at 07:37 -0700, Sergei Shtylyov wrote:
> Hello.
>
> wwguy 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...
>
> > I don't believe this patch is needed since the "log" statement is move
> > to outside the function.
>
> That's what I'm talking about -- it's not needed in its current form, but I
> will redo the patch to modify iwl-pci,c where iwl_pci_probe() still reads
> PCI_REVISION_ID.
>
ok, thanks
Wey
>
--
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
* Re: [PATCH] sctp: Reducing rwnd by sizeof(struct sk_buff) for each CHUNK is too aggressive
From: Vladislav Yasevich @ 2011-06-24 15:21 UTC (permalink / raw)
To: Sridhar Samudrala, linux-sctp, netdev
In-Reply-To: <20110624144251.GC9222@canuck.infradead.org>
On 06/24/2011 10:42 AM, Thomas Graf wrote:
> On Fri, Jun 24, 2011 at 09:48:51AM -0400, Vladislav Yasevich wrote:
>> I believe there was work in progress to change how window is computed. The issue with
>> your current patch is that it is possible to consume all of the receive buffer space while
>> still having an open receive window. We've seen it in real life which is why the above band-aid
>> was applied.
>
First, let me state that I mis-understood what the patch is attempting to do.
Looking again, I understand this a little better, but still have reservations.
> I don't understand this. The rwnd _announced_ is sk_rcvbuf/2 so we are
> reserving half of sk_rcvbuf for structures like sk_buff. This means we
> can use _all_ of rwnd for data. If the peer announces a a_rwnd of 1500
> in the last SACK I expect that peer to be able to handle 1500 bytes of
> data.
>
> Regardless of that, why would we reserve a sk_buff for each chunk? We only
> allocate an skb per packet which can have many chunks attached.
>
> To me, this looks like a fix for broken sctp peers.
Well, the rwnd announced is what the peer stated it is. All we can do is
try to estimate what it will be when this packet is received.
We, instead of trying to underestimate the window size, try to over-estimate it.
Almost every implementation has some kind of overhead and we don't know how
that overhead will impact the window. As such we try to temporarily account for this
overhead.
If we treat the window as strictly available data, then we may end up sending a lot more traffic
then the window can take thus causing us to enter 0 window probe and potential retransmission
issues that will trigger congestion control.
We'd like to avoid that so we put some overhead into our computations. It may not be ideal
since we do this on a per-chunk basis. It could probably be done on per-packet basis instead.
This way, we'll essentially over-estimate but under-subscribe our current view of the peers
window. So in one shot, we are not going to over-fill it and will get an updated view next
time the SACK arrives.
>
>> The correct patch should really something similar to TCP, where receive window is computed as
>> a percentage of the available receive buffer space at every adjustment. This should also take into
>> account SWS on the sender side.
>
> Can you elaborate this a little more? You want our view of the peer's receive
> window to be computed as a percentage of the available receive buffer on our
> side?
>
As I said, I miss-understood what you were trying to do. Sorry for going off in another direction.
Thanks
-vlad
^ 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