* Re: [PATCH] pktgen node allocation
From: Robert Olsson @ 2010-03-22 18:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Robert Olsson, David Miller, netdev, olofh
In-Reply-To: <1269243794.3029.0.camel@edumazet-laptop>
Eric Dumazet writes:
> > Result "manually" tuned.
> >
> > eth0 9617.7 M bit/s 822 k pps
> > eth1 9619.1 M bit/s 823 k pps
> > eth2 9619.1 M bit/s 823 k pps
> > eth3 9619.2 M bit/s 823 k pps
> > eth4 5995.2 M bit/s 512 k pps <- PCIe-x8
> > eth5 5995.3 M bit/s 512 k pps <- PCIe-x8
> > eth6 9619.2 M bit/s 823 k pps
> > eth7 9619.2 M bit/s 823 k pps
> > eth8 9619.1 M bit/s 823 k pps
> > eth9 9619.0 M bit/s 823 k pps
> >
> > > 90 Gbit/s
DMA potential this box is about four 10g ports.
> > Result "manually" mistuned by switching node 0 and 1.
> >
> > eth0 9613.6 M bit/s 822 k pps
> > eth1 9614.9 M bit/s 822 k pps
> > eth2 9615.0 M bit/s 822 k pps
> > eth3 9615.1 M bit/s 822 k pps
> > eth4 2918.5 M bit/s 249 k pps <- PCIe-x8
> > eth5 2918.4 M bit/s 249 k pps <- PCIe-x8
> > eth6 8597.0 M bit/s 735 k pps
> > eth7 8597.0 M bit/s 735 k pps
> > eth8 8568.3 M bit/s 733 k pps
> > eth9 8568.3 M bit/s 733 k pps
> >
> I wonder why eth0-eth3 results are unchanged after a node flip.
Yes it's strange.
With clone_skb=1 we could see differences with just one GIGE interface
using 64 byte pkts so it might be very different on 10g. We're getting
unfortunely closer to hardware...
Cheers
--ro
^ permalink raw reply
* Re: Unable to create more than 1 guest virtio-net device using vhost-net backend
From: Michael S. Tsirkin @ 2010-03-22 18:16 UTC (permalink / raw)
To: Avi Kivity; +Cc: Sridhar Samudrala, netdev, kvm@vger.kernel.org, gleb
In-Reply-To: <4BA609E5.40504@redhat.com>
On Sun, Mar 21, 2010 at 01:58:29PM +0200, Avi Kivity wrote:
> On 03/21/2010 01:34 PM, Michael S. Tsirkin wrote:
>> On Sun, Mar 21, 2010 at 12:29:31PM +0200, Avi Kivity wrote:
>>
>>> On 03/21/2010 12:15 PM, Michael S. Tsirkin wrote:
>>>
>>>>>> Nothing easy that I can see. Each device needs 2 of these. Avi, Gleb,
>>>>>> any objections to increasing the limit to say 16? That would give us
>>>>>> 5 more devices to the limit of 6 per guest.
>>>>>>
>>>>>>
>>>>>>
>>>>> Increase it to 200, then.
>>>>>
>>>>>
>>>> OK. I think we'll also need a smarter allocator
>>>> than bus->dev_count++ than we now have. Right?
>>>>
>>>>
>>> No, why?
>>>
>> We'll run into problems if devices are created/removed in random order,
>> won't we?
>>
>
> unregister_dev() takes care of it.
>
>>> Eventually we'll want faster scanning than the linear search we employ
>>> now, though.
>>>
>> Yes I suspect with 200 entries we will :). Let's just make it 16 for
>> now?
>>
>
> Let's make it 200 and fix the performance problems later. Making it 16
> is just asking for trouble.
I did this and performance with vhost seems to become much more noisy,
and drop by about 10% on average, even though in practice only
a single device is created. Still trying to figure it out ...
Any idea?
> --
> error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: Add PGM protocol support to the IP stack
From: Christoph Lameter @ 2010-03-22 18:07 UTC (permalink / raw)
To: Andi Kleen; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <877hp4i76d.fsf@basil.nowhere.org>
On Mon, 22 Mar 2010, Andi Kleen wrote:
> > What I have right now is:
> >
> > 1. Opening a socket
>
> >
> > A. Native PGM
> >
> > fd = socket(AF_INET, SOCK_RDM, IPPROTO_PGM)
>
> RDM = Reliable ? Multicast ?
RDM is Reliable Datagram Multicast I believe. I'd rather have SOCK_PGM if
I could choose.
>
> > B. PGM over UDP
> >
> > fd = socket(AF_INET, SOCK_RDM, IPPROTO_UDP)
> >
> > C. PGM over SHM (?)
> >
> > fd = socket(AF_UNIX, SOCK_RDM, 0)
>
> Not sure how that should work.
Multiple processes would communicate via shm segments. Maybe defer to the
future but its an important operation mode as the systems grow bigger and bigger.
SHM segment would have to contain some sort of ring buffer that the
receivers could tap into. But that mode has not really been thought
through.
> > 3. Sending and receiving
> >
> > Use the usual socket read and write operations and the various flavors of waiting
> > for a packet via select, poll, epoll etc.
> >
> > Packet sizes are determined by the number of packets in a single sendmsg() unless
>
> Number of bytes surely?
Sorry yes you are right.
> > overridden by the RM_SET_MESSAGE_BOUNDARY socket option.
>
> That's unusual to have such a option (except the MTU). What is it good for?
No idea why it was implemented. It can be used to use send() for portions
of a message. Triggers the send() only when all bytes have been provided.
Probably necessary if one wants to have very long (megabytes) messages.
Esoteric and likely not going to be in a first release.
> > 4. Transmitter Socket Options
> >
> >
> > A. Setting the window size / rate.
> >
> > struct pgm_send_window x;
> > x.RateKbitsPerSec = 56;
> > x.WindowSizeInMsecs = 60000;
> > x.WindowSizeinBytes = 10000000;
> >
> > setsockopt(fd, SOCK_RDM, RM_RATE_WINDOW_SIZE, &x, sizeof(x));
> >
> > Default is sending at 56Kbps with a buffer of 10 Megabytes and buffering for a minute.
>
> That's a very large buffer for a socket. It would be better to use the usual
> auto shrinking/increasing mechanisms.
Reliable multicast protocols have a defined time period / "reliabilty
buffer" so that they can resend a message that was missed for a time
period. It is customary to either specify a time period or define the size
of the "reliability buffer".
> > B. FEC mode
> >
> > struct pgm_fec_info x;
> >
> > x.FECBlocksize = 255;
> > x.FECProActivePackets = 0;
> > x.FECGroupSize = 0;
> > x.fFECOnDemandParityEnabled = 1;
> >
> > setsockopt(fd, SOCK_RDM, RM_FEC_MODE, &x, sizeof(x));
>
> Is that mode really needed?
Never used it. I'd rather skip for now. Maybe later.
>
> > /* Socket API structures (established by M$DN) */
> > struct pgm_receiver_stats {
> > u64 NumODataPacketsReceived; /* Number of ODATA (original) sequences */
>
> It's difficult to maintain 64 bit counters on 32bit hosts on all targets.
> But I guess it would be ok to only fill in 32bit in this case.
32 bit counters have the awful habit of overflowing.
^ permalink raw reply
* Re: [PATCH] net_sched: make traffic control network namespace aware
From: Patrick McHardy @ 2010-03-22 18:04 UTC (permalink / raw)
To: Tom Goff; +Cc: netdev
In-Reply-To: <4BA7AF32.8020001@trash.net>
Patrick McHardy wrote:
> Tom Goff wrote:
>> Mostly minor changes to add a net argument to various functions and
>> remove initial network namespace checks.
>>
>> Make /proc/net/psched per network namespace.
>
> Looks fine from a qdisc POV. One thing that appears to be missing
> though is teql master netdev registration in other than the initial
> namespace.
Actually we could take this opportunity and add rtnl_link support
for teql device registration. I can look into this in a couple of
days.
^ permalink raw reply
* Re: [PATCH] xfrm: cache bundle lookup results in flow cache
From: Timo Teräs @ 2010-03-22 18:03 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, David S. Miller
In-Reply-To: <20100322035201.GA14457@gondor.apana.org.au>
Herbert Xu wrote:
> On Sun, Mar 21, 2010 at 10:31:23AM +0200, Timo Teräs wrote:
>>> Ok, we can do that to skip 2. But I think 1 would be still useful.
>>> It'd probably be good to actually have flow_cache_ops pointer in
>>> each entry instead of the atomic_t pointer.
>>>
>>> The reasoning:
>>> - we can then have type-based checks that the reference count
>>> is valid (e.g. policy's refcount must not go to zero, it's bug,
>>> and we can call dst_release which warns if refcount goes to
>>> negative); imho it's hack to call atomic_dec instead of the
>>> real type's xxx_put
>>> - the flow cache needs to somehow know if the entry is stale so
>>> it'll try to refresh it atomically; e.g. if there's no
>>> check for 'stale', the lookup returns stale xfrm_dst. we'd
>>> then need new api to update the stale entry, or flush it out
>>> and repeat the lookup. the virtual get could check for it being
>>> stale (if so release the entry) and then return null for the
>>> generic code to call the resolver atomically
>>> - for paranoia we can actually check the type of the object in
>>> cache via the ops (if needed)
>
> The reason I'd prefer to keep the current scheme is to avoid
> an additional indirect function call on each packet.
>
> The way it would work is (we need flow_cache_lookup to return
> fle instead of the object):
>
> fle = flow_cache_lookup
> xdst = fle->object
> if (xdst is stale) {
> flow_cache_mark_obsolete(fle)
> fle = flow_cache_lookup
> xdst = fle->object
> if (xdst is stale)
> return error
> }
>
> Where flow_cache_mark_obsolete would set a flag in the fle that's
> checked by flow_cache_lookup. To prevent the very rare case
> where we mark an entry obsolete incorrectly, the resolver function
> should double-check that the existing entry is indeed obsolete
> before making a new one.
>
> This way we give the overhead over to the slow path where the
> bundle is stale.
Well, yes. The fast past would be slightly faster.
However, I still find the indirect call based thingy more elegant.
We would also get more common code, as flow_cache_lookup could then
figure out from the virtual call if the entry needs refreshing or
not. And doing just atomic_dec instead of the type based thingy
feels slightly kludgy. I don't think the speed difference between
direct/indirect call is that significant.
Also the fle would just need "struct flow_cache_ops *". And have
wrappers that use container_of to figure out the real address of
the cached struct. This would allow real type agnostic cache.
So we'd just need the 'ops' pointer instead of the current
object pointer and atomic_t pointer, saving in fle size.
But yes, it does impose the small speed penalty of indirect call.
I prefer the 'ops' thingy, but have no strong feelings either way.
Do you fell strongly to go with the current scheme here?
> You were saying that our bundles are going stale very frequently,
> that would sound like a bug that we should look into. The whole
> caching scheme is pointless if the bundle is going stale every
> other packet.
I mean frequently as in 'minutes' not as in 'milliseconds'. The
bundles goes stale only when the policy (mostly by user action) or
ip route (pmtu / minutes) changes. So no biggie here.
>> - could cache bundle OR policy for outgoing stuff. it's useful
>> to cache the policy in case we need to sleep, or if it's a
>> policy forbidding traffic. in those cases there's no bundle
>> to cache at all. alternatively we can make dummy bundles that
>> are marked invalid and are just used to keep a reference to
>> the policy.
>
> My instinct is to go with dummy bundles. That way given the
> direction we know exactly what object type it is. Having mixed
> object types is just too much of a pain.
Sounds good.
>> Oh, this also implies that the resolver function should be
>> changed to get the old stale object so it can re-use it to
>> get the policy object instead of searching it all over again.
>
> That should be easy to implement. Just prefill the obj argument
> to the resolver with either NULL or the stale object.
>
> For the bundle resolver, it should also remove the stale bundle
> from the policy bundle list and drop its reference.
Yup.
Cheers,
Timo
^ permalink raw reply
* Re: [PATCH] net_sched: make traffic control network namespace aware
From: Patrick McHardy @ 2010-03-22 17:56 UTC (permalink / raw)
To: Tom Goff; +Cc: netdev
In-Reply-To: <20100320014013.GC13239@boeing.com>
Tom Goff wrote:
> Mostly minor changes to add a net argument to various functions and
> remove initial network namespace checks.
>
> Make /proc/net/psched per network namespace.
Looks fine from a qdisc POV. One thing that appears to be missing
though is teql master netdev registration in other than the initial
namespace.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ipoib: remove addrlen check for mc addresses
From: Jason Gunthorpe @ 2010-03-22 17:46 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
ogerlitz-smomgflXvOZWk0Htik3J/w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, monis-smomgflXvOZWk0Htik3J/w
In-Reply-To: <20100322172613.GA2884-YzwxZg+R7et1/kRsl7OVgNvLeJWuRmrY@public.gmane.org>
On Mon, Mar 22, 2010 at 06:26:14PM +0100, Jiri Pirko wrote:
> Mon, Mar 22, 2010 at 05:59:16PM CET, jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org wrote:
> >On Mon, Mar 22, 2010 at 02:21:39PM +0100, Jiri Pirko wrote:
> >> Finally this bit can be removed. Currently, after the bonding driver is
> >> changed/fixed (32a806c194ea112cfab00f558482dd97bee5e44e net-next-2.6),
> >> that's not possible for an addr with different length than dev->addr_len
> >> to be present in list. Removing this check as in new mc_list there will be
> >> no addrlen in the record.
> >
> >Maybe just make this check a WARN_ON?
>
> As I said, addrlen will no longer be in record (because it would have no
> meaning since length ot the addr is always dev->addr_len)
Oh, I see, sounds good then
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: Add PGM protocol support to the IP stack
From: Andi Kleen @ 2010-03-22 17:43 UTC (permalink / raw)
To: Christoph Lameter; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <alpine.DEB.2.00.1003221146260.17230@router.home>
Christoph Lameter <cl@linux-foundation.org> writes:
> On Mon, 22 Mar 2010, Andi Kleen wrote:
>
>> Multicast reliable kernel protocols are somewhat new, I guess one
>> would need to make sure to come up with a clean generic interface
>> for them first.
>
> It has been around for a long time in another OS. I wonder if I should use
> the socket API realized there as a model or come up with something new
> from scratch?
If the other API doesn't have a serious flaw I guess it's better
to aim for a sub/superset at least, to make porting applications easier.
>
> What I have right now is:
>
> 1. Opening a socket
>
> A. Native PGM
>
> fd = socket(AF_INET, SOCK_RDM, IPPROTO_PGM)
RDM = Reliable ? Multicast ?
> B. PGM over UDP
>
> fd = socket(AF_INET, SOCK_RDM, IPPROTO_UDP)
>
> C. PGM over SHM (?)
>
> fd = socket(AF_UNIX, SOCK_RDM, 0)
Not sure how that should work.
> 3. Sending and receiving
>
> Use the usual socket read and write operations and the various flavors of waiting
> for a packet via select, poll, epoll etc.
>
> Packet sizes are determined by the number of packets in a single sendmsg() unless
Number of bytes surely?
> overridden by the RM_SET_MESSAGE_BOUNDARY socket option.
That's unusual to have such a option (except the MTU). What is it good for?
>
> 4. Transmitter Socket Options
>
>
> A. Setting the window size / rate.
>
> struct pgm_send_window x;
> x.RateKbitsPerSec = 56;
> x.WindowSizeInMsecs = 60000;
> x.WindowSizeinBytes = 10000000;
>
> setsockopt(fd, SOCK_RDM, RM_RATE_WINDOW_SIZE, &x, sizeof(x));
>
> Default is sending at 56Kbps with a buffer of 10 Megabytes and buffering for a minute.
That's a very large buffer for a socket. It would be better to use the usual
auto shrinking/increasing mechanisms.
> B. FEC mode
>
> struct pgm_fec_info x;
>
> x.FECBlocksize = 255;
> x.FECProActivePackets = 0;
> x.FECGroupSize = 0;
> x.fFECOnDemandParityEnabled = 1;
>
> setsockopt(fd, SOCK_RDM, RM_FEC_MODE, &x, sizeof(x));
Is that mode really needed?
> /* Socket API structures (established by M$DN) */
> struct pgm_receiver_stats {
> u64 NumODataPacketsReceived; /* Number of ODATA (original) sequences */
It's difficult to maintain 64 bit counters on 32bit hosts on all targets.
But I guess it would be ok to only fill in 32bit in this case.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [PATCH] netdev: don't always reset iflink when registering
From: Patrick McHardy @ 2010-03-22 17:42 UTC (permalink / raw)
To: Tom Goff; +Cc: netdev
In-Reply-To: <20100320013917.GB13239@boeing.com>
Tom Goff wrote:
> Bound tunnel devices set their iflink to the ifindex of the underlying
> network interface when created. It shouldn't be reset by the
> registration process.
>
Which ones exactly? Usually they do this in ->setup() or later on.
^ permalink raw reply
* forcedeth: cat /sys/class/net/eth0/carrier = Invalid argument
From: Justin P. mattock @ 2010-03-22 17:36 UTC (permalink / raw)
To: netdev; +Cc: Linux Kernel Mailing List
I've pushed my kernel from the latest HEAD to 2.6.31
and am still seeing:
cat /sys/class/net/eth0/carrier
cat: carrier: Invalid argument
with my other machine using sky2
the same results is:
cat /sys/class/net/eth0/carrier
0
is there anything on this? before I start
a bisect.(looking through bugzilla, I couldn't
see anything related).
Justin P. Mattock
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ipoib: remove addrlen check for mc addresses
From: Jiri Pirko @ 2010-03-22 17:26 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: netdev, davem, ogerlitz, linux-rdma, monis
In-Reply-To: <20100322165916.GE29129@obsidianresearch.com>
Mon, Mar 22, 2010 at 05:59:16PM CET, jgunthorpe@obsidianresearch.com wrote:
>On Mon, Mar 22, 2010 at 02:21:39PM +0100, Jiri Pirko wrote:
>> Finally this bit can be removed. Currently, after the bonding driver is
>> changed/fixed (32a806c194ea112cfab00f558482dd97bee5e44e net-next-2.6),
>> that's not possible for an addr with different length than dev->addr_len
>> to be present in list. Removing this check as in new mc_list there will be
>> no addrlen in the record.
>
>Maybe just make this check a WARN_ON?
As I said, addrlen will no longer be in record (because it would have no
meaning since length ot the addr is always dev->addr_len)
>Can userspace create a mc_list
>entry with the wrong size via netlink?
Nope - this is not possible. dev->addr_len is used.
>
>Jason
^ permalink raw reply
* Re: Gianfar: RX Recycle skb->len error
From: Anton Vorontsov @ 2010-03-22 17:24 UTC (permalink / raw)
To: David Miller; +Cc: ben, netdev, Sandeep.Kumar
In-Reply-To: <20100321.214642.67901344.davem@davemloft.net>
On Sun, Mar 21, 2010 at 09:46:42PM -0700, David Miller wrote:
[...]
> > * recycle list.
> > */
> > skb->data = skb->head + NET_SKB_PAD;
> > + skb_reset_tail_pointer(skb);
> > __skb_queue_head(&priv->rx_recycle, skb);
> > }
> > } else {
>
> This code is essentially trying to undo skb_reserve()
> but as you found it's doing so in a buggy manner.
>
> skb_reserve() adjusts both the 'data' and 'tail' pointers,
> but this attempt at a reversal is only modifying 'data'.
>
> Your fix is fine, but really any by-hand modification of
> skb->data is a bug, and we should provide an skb_unreserve()
> or similar to hide such details away, and use it here.
>
> Anton?
Yes, skb_unreserve() (or skb_reset_reserved() for naming consistency?)
would be great.
Ben, note that ucc_geth.c driver is also affected by that bug,
so I guess it needs a similar fix.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] rxrpc: Check allocation failure.
From: David Miller @ 2010-03-22 17:23 UTC (permalink / raw)
To: dhowells; +Cc: torvalds, akpm, netdev, penguin-kernel
In-Reply-To: <20100322135019.15704.20997.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Mon, 22 Mar 2010 13:50:19 +0000
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>
> alloc_skb() can return NULL.
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Signed-off-by: David Howells <dhowells@redhat.com>
Applied, thanks guys.
^ permalink raw reply
* Re: linux-next: Tree for March 22 (net-sysfs.c)
From: David Miller @ 2010-03-22 17:22 UTC (permalink / raw)
To: randy.dunlap; +Cc: sfr, linux-next, linux-kernel, netdev, therbert
In-Reply-To: <4BA78D3D.9090007@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Mon, 22 Mar 2010 08:31:09 -0700
> When CONFIG_SYSFS is not enabled:
>
> net/core/net-sysfs.c:742: error: implicit declaration of function 'rx_queue_remove_kobjects'
> net/core/net-sysfs.c:783: error: implicit declaration of function 'rx_queue_register_kobjects'
>
Tom, please fix this.
^ permalink raw reply
* Re: [Uclinux-dist-devel] [PATCH] can: bfin_can: switch to common Blackfin can header
From: David Miller @ 2010-03-22 17:17 UTC (permalink / raw)
To: vapier.adi
Cc: socketcan-core, netdev, uclinux-dist-devel, oliver.hartkopp,
urs.thuermann
In-Reply-To: <8bd0f97a1003220004q15ad498fg49914ea06c1b9a8d@mail.gmail.com>
From: Mike Frysinger <vapier.adi@gmail.com>
Date: Mon, 22 Mar 2010 03:04:48 -0400
> On Sun, Mar 21, 2010 at 23:58, David Miller wrote:
>> From: Mike Frysinger <vapier.adi@gmail.com>
>> When I say "resubmit" I've deleted your patch from my inbox
>> and marked it "changed requested" or similar in patchwork
>> so it doesn't show up in the todo list any more.
>
> i missed the relevance of your original "resubmit" because no other
> maintainer ive worked with so far has exhibited this behavior, and
> there wasnt any indication as to why a resubmission was necessary
> considering no changes were made
So when I ask you to resubmit something you just assume that
I have no reason whatsoever for doing so?
Do you still feel this way after people other than me also asked you
to do the same exact thing for me? Do you think they are making
arbitrary requests as well?
This is the fatal flaw in your logic and behavior.
^ permalink raw reply
* [iproute2] iproute2 question
From: thomas yang @ 2010-03-22 17:12 UTC (permalink / raw)
To: netdev
In-Reply-To: <f4f837ab1003221011v6657bebx3a741df5c781adf3@mail.gmail.com>
>>
>> I want to reduce the packet loss that happens while routers converge
>> after a topology change due to a failure, use precalculated backup
>> table to do rapid failure repair (repair faster than routing daemon,
>> fast reroute).
>> I do static routing on my linux routers. When some link failed,
>> I want to use backup tables to route packets. Can iproute2 do this?
>
> You could probably kludge something with multiple route tables
> and modifying a single 'ip rule'.
> Something like:
> http://www.linuxhorizon.ro/iproute2.html
>
I want to use different routing tables with different TOS (or DSCP)
e.g.
iptables -t mangle -A PREROUTING -j TOS --set-tos 0x10
...
then,
ip rule add tos 0x10 table 100
ip rule add tos 0x08 table 200
...
but there are only five TOS values 0x00,0x02,0x04,0x08,0x10. I need
more TOS values.
Does cmd 'ip rule' support DSCP ? (e.g. 'ip rule add dscp 0x11 tables 10')
^ permalink raw reply
* Re: 2.6.34-rc2: Reported regressions from 2.6.33
From: Linus Torvalds @ 2010-03-22 17:12 UTC (permalink / raw)
To: Rafael J. Wysocki, Alex Villacis Lasso
Cc: DRI, Linux SCSI List, Network Development, Linux Wireless List,
Linux Kernel Mailing List, Linux ACPI, Andrew Morton,
Kernel Testers List, Linux PM List, Maciej Rutecki
In-Reply-To: <M9dVcHY7TxH.A.2GC.ZBopLB@chimera>
On Sun, 21 Mar 2010, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15495
> Subject : Flood of SELinux denials on polkitd
> Submitter : Alex Villacis Lasso <avillaci@ceibo.fiec.espol.edu.ec>
> Date : 2010-03-09 16:47 (13 days old)
Fixed by commit 3836a03d978e68b0ae00d3589089343c998cd4ff ("anon_inodes:
mark the anon inode private"), I'm pretty sure.
Linus
^ permalink raw reply
* Re: 8021p to dscp remarking
From: Stephen Hemminger @ 2010-03-22 17:05 UTC (permalink / raw)
To: Smital Desai; +Cc: netdev
In-Reply-To: <70376CA23424B34D86F1C7DE6B997343017F72C982@VSHINMSMBX01.vshodc.lntinfotech.com>
----- "Smital Desai" <Smital.Desai@lntinfotech.com> wrote:
> Hello
>
> Is it possible to support 8021p -> Dscp remarking in kernel for the
> routers that
> are not supporting such kind of remarking mechanism at hardware level
> ?
>
> Any such support available in latest kernel ?
>
> Any help / suggestions will be appreciated .
>
> Thanks,
> Smital Desai
dsmark queue discipline with appropriate filters.
^ permalink raw reply
* Re: -next Mar 22: s390 build failure (drivers/s390/net/qeth_l3)
From: David Miller @ 2010-03-22 17:00 UTC (permalink / raw)
To: frank.blaschka; +Cc: sachinp, netdev, linux-s390
In-Reply-To: <20100322130025.GA8558@tuxmaker.boeblingen.de.ibm.com>
From: Blaschka <frank.blaschka@de.ibm.com>
Date: Mon, 22 Mar 2010 14:00:25 +0100
> [PATCH] qeth: l3 fix build error in ipv6 addr list handling
>
> From: Frank Blaschka <frank.blaschka@de.ibm.com>
>
> Adapt qeth l3 to:
> commit c2e21293c054817c42eb5fa9c613d2ad51954136
> (ipv6: convert addrconf list to hlist)
> converted lst_next member of inet6_ifaddr struct to a hlist.
>
> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
Applied, thanks for fixing this Frank.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ipoib: remove addrlen check for mc addresses
From: Jason Gunthorpe @ 2010-03-22 16:59 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
ogerlitz-smomgflXvOZWk0Htik3J/w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, monis-smomgflXvOZWk0Htik3J/w
In-Reply-To: <20100322132138.GC2780-YzwxZg+R7evMbnheQZGK0N5OCZ2W11yPFxja6HXR22MAvxtiuMwx3w@public.gmane.org>
On Mon, Mar 22, 2010 at 02:21:39PM +0100, Jiri Pirko wrote:
> Finally this bit can be removed. Currently, after the bonding driver is
> changed/fixed (32a806c194ea112cfab00f558482dd97bee5e44e net-next-2.6),
> that's not possible for an addr with different length than dev->addr_len
> to be present in list. Removing this check as in new mc_list there will be
> no addrlen in the record.
Maybe just make this check a WARN_ON? Can userspace create a mc_list
entry with the wrong size via netlink?
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: Add PGM protocol support to the IP stack
From: Christoph Lameter @ 2010-03-22 16:51 UTC (permalink / raw)
To: Andi Kleen; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <20100322163609.GZ20695@one.firstfloor.org>
On Mon, 22 Mar 2010, Andi Kleen wrote:
> Multicast reliable kernel protocols are somewhat new, I guess one
> would need to make sure to come up with a clean generic interface
> for them first.
It has been around for a long time in another OS. I wonder if I should use
the socket API realized there as a model or come up with something new
from scratch?
What I have right now is:
1. Opening a socket
A. Native PGM
fd = socket(AF_INET, SOCK_RDM, IPPROTO_PGM)
B. PGM over UDP
fd = socket(AF_INET, SOCK_RDM, IPPROTO_UDP)
C. PGM over SHM (?)
fd = socket(AF_UNIX, SOCK_RDM, 0)
2. Binding to a multicast address
A. Sender
Connect the socket to a MC address and port using connect().
Note that the port is significant since multiple streams on different
ports can be run over the same MC addr.
B. Receiver
I. Bind the socket to the MC address and port of interest.
II. Listen to the socket.
Process will wait until a PGM packet destined to the port of interest
is received.
III. Accept a connection.
Establishes a session. Data can then be received.
3. Sending and receiving
Use the usual socket read and write operations and the various flavors of waiting
for a packet via select, poll, epoll etc.
Packet sizes are determined by the number of packets in a single sendmsg() unless
overridden by the RM_SET_MESSAGE_BOUNDARY socket option.
The sender will block when the send window is full unless a non blocking write is performed.
The receiver shows the usual wait semantics. If the stream is set to unreliable then
packets may arrive in random order. If the set is set to RM_LISTEN_ONLY then packets may
just be missing.
4. Transmitter Socket Options
A. Setting the window size / rate.
struct pgm_send_window x;
x.RateKbitsPerSec = 56;
x.WindowSizeInMsecs = 60000;
x.WindowSizeinBytes = 10000000;
setsockopt(fd, SOCK_RDM, RM_RATE_WINDOW_SIZE, &x, sizeof(x));
Default is sending at 56Kbps with a buffer of 10 Megabytes and buffering for a minute.
B. FEC mode
struct pgm_fec_info x;
x.FECBlocksize = 255;
x.FECProActivePackets = 0;
x.FECGroupSize = 0;
x.fFECOnDemandParityEnabled = 1;
setsockopt(fd, SOCK_RDM, RM_FEC_MODE, &x, sizeof(x));
5. Receiver Socket Options
None?
Possible Extensions
RM_UNORDERED accept unordered packet avoiding delays when packets arrive out of sequence.
packet is still NAKed.
RM_RECEIVE_ONLY Simply ignore missed packets. Do not send any replies.
Existing socket options in the other OS (X denotes that this looks like
its screwy and should be avoided)
/* PGM socket options */
/* Transmitter */
#define RM_LATEJOIN 1 /* X Not supported on receive so why have it? */
#define RM_RATE_WINDOW_SIZE 2 /* See struct pgm_send_window */
#define RM_SEND_WINDOW_ADV_RATE 3 /* X Increase of send window in percentage of window */
#define RM_SENDER_STATISTICS 4 /* see struct pgm_sender_stats */
#define RM_SENDER_WINDOW_ADVANCE_METHOD 5 /* X seems obsolete */
#define RM_SET_MCAST_TTL 6 /* X Can be set via IP_MULTICAST_TTL */
#define RM_SET_MESSAGE_BOUNDARY 7 /* Fix the size of the messages in bytes */
#define RM_SET_SEND_IF 8 /* X use IP_MULTICAST_IF etc instead */
#define RM_USE_FEC 9
/* Receiver */
#define RM_ADD_RECEIVE_IF 100 /* X ???? IP_MULTICAST_IF instead? */
#define RM_DEL_RECEIVE_IF 101 /* X IP_MULTICAST_IF */
#define RM_HIGH_SPEED_INTRANET_OPT 102 /* X PGM should adapt automatically to high speed networks */
#define RM_RECEIVER_STATISTICS 103 /* See struct pgm_receiver_stats */
/* Socket API structures (established by M$DN) */
struct pgm_receiver_stats {
u64 NumODataPacketsReceived; /* Number of ODATA (original) sequences */
u64 NumRDataPacketsReceived; /* Number of RDATA (repair) sequences */
u64 NumDuplicateDataPackets; /* Duplicate sequences */
u64 DataBytesReceived;
u64 TotalBytesReceived;
u64 RateKBitsPerSecOverall; /* Receive rate since start of session X */
u64 RateKBitsPerSecLast; /* Receive rate for last second X*/
u64 TrailingEdgeSeqId; /* Oldest sequence in the receive window */
u64 LeadingEdgeSeqId; /* Newest sequence in the receive window */
u64 AverageSequencesInWindow; /* Average number of sequences in receive window X */
u64 MinSequencesInWindow; /* The mininum number of sequences */
u64 MaxSequencesInWindow; /* The maximum number of sequences */
u64 FirstNakSequenceNumber; /* First outstanding nack sequence number */
u64 NumPendingNaks; /* Number of sequences waiting for NCF */
u64 NumOutstandingNaks; /* Number of sequences waiting for RDATA */
u64 NumDataPacketsBuffered; /* Number of packets currently buffered */
u64 TotalSelectiveNaksSent; /* Number of NAKs sent total */
u64 TotalParityNaksSent; /* Number of parity NAKs sent */
};
struct pgm_sender_stats {
u64 DataBytesSent;
u64 TotalBytesSent;
u64 NaksReceived;
u64 NaksReceivedTooLate; /* NAKs received after receive window advanced */
u64 NumOutstandingNaks; /* Number of NAKs awaiting response */
u64 NumNaksAfterRData; /* Number of NAKs after RDATA sequences were sent which were ignored */
u64 RepairPacketsSent;
u64 BufferSpaceAvailable; /* Number of partial messages dropped */
u64 TrailingEdgeSeqId; /* Oldest sequence id in window */
u64 LeadingEdgeSeqId; /* Newest sequence id in window */
u64 RateKBitsPerSecOverall; /* Rate since start of session X */
u64 RateKBitsPerSecLast; /* Rate in last second X */
u64 TotalODataPacketsSent; /* Total data packets transmitted */
};
/* Setup of sender RateKbitsPerSec = WindowSizeBytes / WindowSizeMSecs */
struct pgm_send_window {
u64 RateKbitsPerSec; /* Allowed rate for the sender in kbits per second */
u64 WindowSizeInMSecs; /* Send window size in time */
u64 WindowSizeInBytes; /* Window size in bytes */
};
struct pgm_fec_info {
u16 FECBlockSize; /* Maximum number of packets for a group. Default and max = 255 */
u16 FECProActivePackets; /* Number of proactive packets per group. */
u8 FECGroupSize; /* Number of packets to be treated as a group. Power of two */
int fFECOnDemandParityEnabled; /* Allow sender to sent parity repair packets */
};
^ permalink raw reply
* Re: Add PGM protocol support to the IP stack
From: Andi Kleen @ 2010-03-22 16:36 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andi Kleen, David Miller, netdev, linux-kernel
In-Reply-To: <alpine.DEB.2.00.1003220916170.15360@router.home>
On Mon, Mar 22, 2010 at 09:20:42AM -0500, Christoph Lameter wrote:
> On Fri, 19 Mar 2010, Andi Kleen wrote:
>
> > Christoph Lameter <cl@linux-foundation.org> writes:
> > >
> > > I know about the openpgm implementation. Openpbm does this at the user
> > > level and requires linking to a library. It is essentially a communication
> > > protocol done in user space. It has privilege issues because it has to
> > > create PGM packets via a raw socket.
> >
> > That seems like a poor reason alone to put something into the kernel
> > Perhaps you rather need some way to have unpriviledged raw sockets?
>
> Not the only reason. There are also performance implications. NAKing and
> other control messages from user space are a pain and the available
> implementations add numerous threads just to control the timing of control
> messages and the expiration of data etc. Its difficult to listen to a PGM
> port from user space. You have to get all messages for the PGM protocol
> and then filter in each process.
Ok that sounds like a good reason to have a kernel protocol.
Thanks.
Multicast reliable kernel protocols are somewhat new, I guess one
would need to make sure to come up with a clean generic interface
for them first.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [PATCH 2/3] can: add support for Janz VMOD-ICAN3 Intelligent CAN module
From: Ira W. Snyder @ 2010-03-22 15:53 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, sameo-VuQAYsv1563Yd54FQh9/CA
In-Reply-To: <4BA47F64.8030108-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Sat, Mar 20, 2010 at 08:55:16AM +0100, Wolfgang Grandegger wrote:
> Ira W. Snyder wrote:
> > On Fri, Mar 19, 2010 at 09:13:37PM +0100, Wolfgang Grandegger wrote:
> >> Ira W. Snyder wrote:
> >>> On Fri, Mar 19, 2010 at 04:45:09PM +0100, Wolfgang Grandegger wrote:
> >>>> Ira W. Snyder wrote:
> >>>>> On Fri, Mar 19, 2010 at 10:01:14AM +0100, Wolfgang Grandegger wrote:
> >>>>>> Hi Ira,
> >>>>>>
> >>>>>> we already discussed this patch on the SocketCAN mailing list and there
> >>>>>> are just a few minor issues and the request to add support for the new
> >>>>>> "berr-reporting" option, if feasible. See:
> >>>>>>
> >>>>>> commit 52c793f24054f5dc30d228e37e0e19cc8313f086
> >>>>>> Author: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
> >>>>>> Date: Mon Feb 22 22:21:17 2010 +0000
> >>>>>>
> >>>>>> can: netlink support for bus-error reporting and counters
> >>>>>>
> >>>>>> This patch makes the bus-error reporting configurable and allows to
> >>>>>> retrieve the CAN TX and RX bus error counters via netlink interface.
> >>>>>> I have added support for the SJA1000. The TX and RX bus error counters
> >>>>>> are also copied to the data fields 6..7 of error messages when state
> >>>>>> changes are reported.
> >>>>>>
> >>>>>> Should not be a big deal.
> >>>>>>
> >>>>> I think this patch came along since my last post of the driver. I must
> >>>>> have missed it. I'll try and add support.
> >>>> No problem, it's really new. Just just need to enable BEI depending on
> >>>> CAN_CTRLMODE_BERR_REPORTING.
> >>>>
> >>> I have one final question about this.
> >>>
> >>> The documentation for the firmware isn't very specific here. I believe
> >>> that in order to get any kind of error messages, I need the bus error
> >>> feature turned on. What is the expected behavior of an SJA1000 with the
> >>> BEI (bus error interrupt) turned off? Will you still get warning
> >>> messages for ERROR_ACTIVE -> ERROR_PASSIVE state transitions?
> >> Yes. State transitions are enabled with EI and EPI.
> >>
> >
> > I cannot set the registers directly, but I think I got it right. See
> > below.
> >
> >>> I'm not sure how I would go about testing this feature, either. Ideas?
> >> Send messages without cable connected and watch the error messages with
> >> "candump any,0:0,#ffffffff". With "ip ... berr-reporting on" you should
> >> see additional bus-errors.
> >>
> >
> > Ok, I tried this. On one controller, I turned on bus-error reporting. On
> > the other, I turn off bus-error reporting. I then tried sending lots of
> > messages with the cable unplugged. Here is what happened:
> >
> > bus-error reporting on:
> > Lots of CAN_ERR_BUSERR messages are flooded in candump. There is also a
> > CAN_ERR_CRTL_TX_WARNING message, when there are too many TX errors.
>
> OK, you will now also understand why bus-error reporting is off by
> default. On low-end systems bus-error flooding may even hang the system.
>
> > bus-error reporting off:
> > There was only one message reported before the controller went into
> > ERROR-WARNING state. It was the same CAN_ERR_CRTL_TX_WARNING message as
> > above. There was no flooding of CAN_ERR_BUSERR messages.
> >
> > Does this seem right? It seems pretty good to me.
>
> Yes, I'm just missing an error-passive message. What state does "ip -d
> link show can0" report.
>
Ok, here is what I did:
$ ip link set can0 up type can bitrate 1000000
$ ip link set can1 up type can bitrate 1000000 berr-reporting on
$ ip -d -s link
5: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
link/can
can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
bitrate 1000000 sample-point 0.750
tq 125 prop-seg 2 phase-seg1 3 phase-seg2 2 sjw 1
janz-ican3: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
clock 8000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 0 0 0
RX: bytes packets errors dropped overrun mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
6: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
link/can
can <BERR-REPORTING> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
bitrate 1000000 sample-point 0.750
tq 125 prop-seg 2 phase-seg1 3 phase-seg2 2 sjw 1
janz-ican3: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
clock 8000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 0 0 0
RX: bytes packets errors dropped overrun mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
Now, in seperate windows, I ran cansequence and candump. I stopped
cansequence when it could not send any more packets (due to the cable
being unplugged).
$ cansequence -v -e -p can0
$ cansequence -v -e -p can1
$ candump any,0~0,#FFFFFFFF
can0 20000004 [8] 00 08 00 00 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000004 [8] 00 08 00 00 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
can1 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
This last message is repeated lots more times. That's the flooding we're
avoiding with berr-reporting off.
I see two types of messages here:
1) bus error (only on can1)
2) controller problems -- tx warning limit reached (both)
Am I missing some message? My error frame generation was mostly copied
from the sja1000 driver.
$ ip -d -s link
5: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
link/can
can state ERROR-WARNING (berr-counter tx 128 rx 0) restart-ms 0
bitrate 1000000 sample-point 0.750
tq 125 prop-seg 2 phase-seg1 3 phase-seg2 2 sjw 1
janz-ican3: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
clock 8000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 1 0 0
RX: bytes packets errors dropped overrun mcast
16 0 2 0 0 0
TX: bytes packets errors dropped carrier collsns
513 513 0 0 0 0
6: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
link/can
can <BERR-REPORTING> state ERROR-WARNING (berr-counter tx 128 rx 0) restart-ms 0
bitrate 1000000 sample-point 0.750
tq 125 prop-seg 2 phase-seg1 3 phase-seg2 2 sjw 1
janz-ican3: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
clock 8000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 126 0 1 0 0
RX: bytes packets errors dropped overrun mcast
1024 0 254 0 0 0
TX: bytes packets errors dropped carrier collsns
513 513 0 0 0 0
> >>> I also noticed that I can enable "self test mode" and "listen only mode"
> >>> using the same firmware command. It appears that there are netlink
> >>> messages for this as well. Should I try and support these, too? I don't
> >>> really have any use for them (yet). I assume "self test mode" is
> >>> equivalent to "loopback mode" in the netlink messages.
> >> List-only is straight forward while "self test mode" is not exactly like
> >> "loopback mode", IIRC. Feel free to send a follow-up patch when you have
> >> time for a thorough implementation and testing. It's also on my to-do
> >> list for the SJA1000.
> >>
> >
> > Ok, then I'll put this off for a while. Feel free to pester me about it
> > when there is a working implementation in the SJA1000 driver for me to
> > borrow from. :)
>
> I will let you know when I have something working.
>
Thanks,
Ira
^ permalink raw reply
* Re: [patch] stmmac: use resource_size()
From: Giuseppe CAVALLARO @ 2010-03-22 15:15 UTC (permalink / raw)
To: Dan Carpenter, netdev, Joe Perches, linux-kernel, kernel-janitors,
David S. Miller
In-Reply-To: <20100322121111.GJ21571@bicker>
Hi Dan
Thanks, the patch can also applied against the net-next driver and it's ok.
Regards,
Giuseppe
Dan Carpenter wrote:
> The size calculation is not correct. It should be end - start + 1.
> Use resource_size() to calculate it instead.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> diff --git a/drivers/net/stmmac/stmmac_main.c b/drivers/net/stmmac/stmmac_main.c
> index a673361..92bef30 100644
> --- a/drivers/net/stmmac/stmmac_main.c
> +++ b/drivers/net/stmmac/stmmac_main.c
> @@ -1685,8 +1685,7 @@ static int stmmac_dvr_probe(struct platform_device *pdev)
> }
> pr_info("done!\n");
>
> - if (!request_mem_region(res->start, (res->end - res->start),
> - pdev->name)) {
> + if (!request_mem_region(res->start, resource_size(res), pdev->name)) {
> pr_err("%s: ERROR: memory allocation failed"
> "cannot get the I/O addr 0x%x\n",
> __func__, (unsigned int)res->start);
> @@ -1694,9 +1693,9 @@ static int stmmac_dvr_probe(struct platform_device *pdev)
> goto out;
> }
>
> - addr = ioremap(res->start, (res->end - res->start));
> + addr = ioremap(res->start, resource_size(res));
> if (!addr) {
> - pr_err("%s: ERROR: memory mapping failed \n", __func__);
> + pr_err("%s: ERROR: memory mapping failed\n", __func__);
> ret = -ENOMEM;
> goto out;
> }
> @@ -1774,7 +1773,7 @@ static int stmmac_dvr_probe(struct platform_device *pdev)
> out:
> if (ret < 0) {
> platform_set_drvdata(pdev, NULL);
> - release_mem_region(res->start, (res->end - res->start));
> + release_mem_region(res->start, resource_size(res));
> if (addr != NULL)
> iounmap(addr);
> }
> @@ -1812,7 +1811,7 @@ static int stmmac_dvr_remove(struct platform_device *pdev)
>
> iounmap((void *)ndev->base_addr);
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - release_mem_region(res->start, (res->end - res->start));
> + release_mem_region(res->start, resource_size(res));
>
> free_netdev(ndev);
>
>
^ permalink raw reply
* Re: [PATCH 1/3] netlink: fix NETLINK_RECV_NO_ENOBUFS in netlink_set_err()
From: Patrick McHardy @ 2010-03-22 15:38 UTC (permalink / raw)
To: David Miller; +Cc: pablo, netdev
In-Reply-To: <20100320.143027.116368032.davem@davemloft.net>
David Miller wrote:
> From: Pablo Neira Ayuso <pablo@netfilter.org>
> Date: Fri, 19 Mar 2010 01:24:42 +0100
>
>
>> Patrick McHardy wrote:
>>
>>> Generally the logic seems inverted, you should return an error
>>> to conntrack if userspace wasn't notified of the error.
>>>
>> Indeed, thanks. Are you OK with this patch instead?
>>
>
> I went over all of this and now the patches #1 and #2 look
> correct to me, so I've applied them to net-2.6
>
> Patrick let me know if you think any follow-on tidy ups
> are still necessary and we can add them.
The patch looks fine to me as well, thanks Dave.
^ 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