| Mariusz Kozlowski | [PATCH] remove unbalanced opening brace from drivers/atm ...
It's under #ifdef 0 but I think it's worth fixing anyway.
Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
---
drivers/atm/iphase.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/atm/iphase.c b/drivers/atm/iphase.c
index 78c9736..dd8c3ec 100644
--- a/drivers/atm/iphase.c
+++ b/drivers/atm/iphase.c
@@ -795,7 +795,7 @@ static void ia_hw_type(IADEV *iadev) {
iadev->rx_buf_sz, iadev->rx_pkt_ram);)
#if 0
- if ((memType & FE_MASK) == ...
| Apr 12, 12:49 pm 2009 |
| Denys Fedoryschenko | tun device, unregister_netdevice: waiting for tunx0 to b ...
Kernel 2.6.29
I have program, that creates tunnel interfaces over /dev/net/tun tunx0, tunx1,
tunx2
After some event i killed program over SIGKILL, and tunnels remain alive, and
program become unkillable.
dmesg flooded slowly by:
[598567.076211] unregister_netdevice: waiting for tunx0 to become free. Usage
count = 30
[598577.118112] unregister_netdevice: waiting for tunx0 to become free. Usage
count = 30
[598587.384016] unregister_netdevice: waiting for tunx0 to become free. Usage ...
| Apr 12, 9:58 am 2009 |
| Ed Tomlinson | 2.6.30-rc1 A few issues and a stall
Hi,
I got tired of building out of tree DRM drivers so decided to try 2.6.30-rc1. For simple tasks
it works fine, for slightly more complex ones it is not quite as good...
Here is an example. I normally start a kvm session with the commands below:
ed@grover ~/vm $ sudo modprobe tun
ed@grover ~/vm $ sudo brctl addbr br0
ed@grover ~/vm $ sudo ifconfig br0 192.168.100.254 netmask 255.255.255.0 up
ed@grover ~/vm $ sudo tunctl -b -u ed -t qtap0
qtap0
ed@grover ~/vm $ sudo brctl addif br0 ...
| Apr 12, 8:24 am 2009 |
| Fondation De France | Grant Donation
Congratulation for your $1,350,000.00 as grant from the
Fondation De France. You are to send us the following
details so that we can proceed to process your grant. Name:
Address: Occupation: Sex: Tel.
And send to Mr Patrice Williams ( fdf022@yahoo.com.hk)
Sincerely,
Mrs. Claudia Lauren Announcer.
www.fdf.org
--
| Apr 11, 5:19 pm 2009 |
| Alexander Beregalov | [PATCH] drivers/net: replace BUG() with BUG_ON() if possible
Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
---
drivers/net/atl1e/atl1e_main.c | 3 +--
drivers/net/atlx/atl1.c | 7 +++----
drivers/net/chelsio/sge.c | 4 ++--
drivers/net/fs_enet/mii-fec.c | 6 ++----
drivers/net/ixgb/ixgb_osdep.h | 2 +-
drivers/net/pppol2tp.c | 3 +--
drivers/net/tulip/winbond-840.c | 3 +--
drivers/net/virtio_net.c | ...
| Apr 11, 5:50 pm 2009 |
| david |
| Apr 11, 5:54 pm 2009 |
| Paul Mackerras |
| Apr 12, 4:34 am 2009 |
| Evgeniy Polyakov | Re: iptables very slow after commit 784544739a25c3063739 ...
Hi.
If we add or change the rule we can not know if iptables' return to
userspace does mean that rule started to act. There may be other queues
already filled with the packets which could match the new rule (like
receiving socket buffer). So effectively we want it to take effect very
soon. What if there will be a timer which will synchronize RCU-added states,
so if we update single rule - it will take effect in a second, and if we
update bunch of them - during the delay second we pretty much ...
| Apr 12, 12:23 am 2009 |
| Paul E. McKenney |
| Apr 12, 10:31 am 2009 |
| Kyle Moffett | Re: iptables very slow after commit 784544739a25c3063739 ...
Not true... The iptables-restore format is pretty well documented and
not far off the standard command-line argument format. For instance
the "shorewall" tool does a sort of "compile" of its high-level
firewall language into an input file for the "iptables-restore"
command.
The basic format to atomically load a table is:
-A SOMECHAIN --rule-arguments-here
-A customchain --rule-arguments-here
COMMIT
At the end of this email you can find some sample data cut-n-pasted
from the ...
| Apr 11, 10:05 pm 2009 |
| Jan Engelhardt |
| Apr 12, 9:38 am 2009 |
| Ingo Molnar | Re: iptables very slow after commit 784544739a25c3063739 ...
ia64 would naturally support the CMPXCHG8B instructions.
Not sure about powerpc32. Having a lock for the library
implementation is not _that_ much of a problem. We obviously dont
want the design of Linux to be dictated by the weakest link of all
platforms, right?
Ingo
--
| Apr 12, 3:54 am 2009 |
| Paul E. McKenney | Re: iptables very slow after commit 784544739a25c3063739 ...
This one makes a lot of sense to me. The overhead of an uncontended
lock is pretty small on most systems. This would also mean that you
If you really do need to swap the counters themselves, you -might- also
need call_rcu() to dispose of them. But it should possible to do that
You could certainly use something like smp_call_function() to collect
the other CPUs' counter values -- just disable interrupts across the
increments for architectures that cannot atomically increment a ...
| Apr 12, 10:30 am 2009 |
| Stephen Hemminger | Re: iptables very slow after commit 784544739a25c3063739 ...
On Sat, 11 Apr 2009 17:34:45 -0700
We could also try:
* per-cpu spinlock on counters (instead of synchronize_net).
When doing update, just acquire
lock on that cpu and futz with counters then. Overhead should
still be less than 2.6.29 and earlier global rwlock
* synchonize_rcu/synchronize_net is more guarantee than needed?
* use on_each_cpu() somehow to do grace periood?
* Add a cond_resched() into net_rx_action which might cause rx processing
to get out of rcu ...
| Apr 12, 9:06 am 2009 |
| Harald Welte | Re: iptables very slow after commit 784544739a25c3063739 ...
Hi all,
That's what I implemented as "iptables-restore --noflush" a number of years
ago. It doesn't flush the current uleset and swaps in a new one, but=20
reads the current rules from kernel, applies any number of changes and swaps
the new ruleset in.
The syntax of iptables-restore is almost identical to iptables commands, you
just specify the table in a different way. So you would just create your
desired changes in that format, and echo that into iptables-restore. If it=
's
an entire ...
| Apr 12, 5:30 am 2009 |
| Paul E. McKenney | Re: iptables very slow after commit 784544739a25c3063739 ...
The issue at this point seems to be the need to get accurate snapshots
of various counters -- there are a number of Linux networking users who
need to account for every byte flowing through their systems. However,
it is also necessary to update these counters very efficiently, given
that they are updated on a per-packet basis. The current approach is
as follows:
1. Install a new set of counters.
2. Wait for a grace period to elapse.
3. At this point, we know that all subsequent ...
| Apr 11, 5:34 pm 2009 |
| Evgeniy Polyakov | Re: [PATCH] TX_RING and packet mmap
pull_pages:
eat = delta;
k = 0;
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
if (skb_shinfo(skb)->frags[i].size <= eat) {
put_page(skb_shinfo(skb)->frags[i].page);
eat -= skb_shinfo(skb)->frags[i].size;
} else {
skb_shinfo(skb)->frags[k] = skb_shinfo(skb)->frags[i];
--
Evgeniy Polyakov
--
| Apr 12, 1:53 pm 2009 |
| Evgeniy Polyakov |
| Apr 12, 7:24 am 2009 |
| Johann Baudy | Re: [PATCH] TX_RING and packet mmap
Ok, so if my understanding is correct, fragment data is copied, frags
info (page, offset, size ...) of skb_shinfo(skb) remain available and
skb->data_len is equal to 0 (to tag it as linear).
Then I can use address of skb_shinfo(n)->frags[0].page to derive my
header whatever sending path.
Is it correct?
Best regards,
Johann
--
Johann Baudy
johaahn@gmail.com
--
| Apr 12, 4:23 am 2009 |
| Johann Baudy |
| Apr 12, 1:30 pm 2009 |
| Evgeniy Polyakov |
| Apr 12, 12:52 pm 2009 |
| Johann Baudy | Re: [PATCH] TX_RING and packet mmap
Do you mean that skb_shinfo(skb)->frags[i].page will be valid until
destructor? even if linearized, cloned ....?
Thanks in advance for your help,
Johann
--
| Apr 12, 3:27 am 2009 |
| Johann Baudy | Re: [PATCH] TX_RING and packet mmap
Thanks Evgeniy,
So if my understanding is correct, there is no way to get original
fragment address in destructor using skb fragment page/data.
Then,
I can't use fragments due to skb_linearize
I can't hide pointer into skb data due to skb_copy.
I can't rely on other fields of skb.
IMHO, using skb pointer requires too much cpu resources (parsing
headers to identify the right buffer...)
So what can I do except using a new field?
What do you think about adding a new field that is always ...
| Apr 12, 4:31 pm 2009 |
| Evgeniy Polyakov | Re: [PATCH] TX_RING and packet mmap
Hi Johann.
Sorry for long reply.
Page itself will live until destruction time, when skb is linearized
page is freed, so your own destructor will find that given page is no
longer used, and appropriate memory area can be overwritten.
When skb is cloned, page is untouched, only shared info reference
counter is increased.
--
Evgeniy Polyakov
--
| Apr 12, 3:32 am 2009 |
| Johann Baudy | Re: [PATCH] TX_RING and packet mmap
I've seen that during skb_linearize(), skb_shinfo(skb)->frags[i].page
is not lost even if pages has been put. So I can get back original
frag address from this info in skb destructor. Can I rely on
skb_shinfo(skb)->frags[i].page on more complicated sending paths ... ?
Thanks in advance,
Johann
--
Johann Baudy
johaahn@gmail.com
--
| Apr 12, 12:27 pm 2009 |
