* Re: linux-next: build failure after merge of the final tree (net tree related)
From: John W. Linville @ 2010-09-27 18:44 UTC (permalink / raw)
To: Ohad Ben-Cohen; +Cc: David Miller, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <AANLkTi=YHhRWFix1QDuEnRW7r_UaNtp6KSL9uLdUzdqM@mail.gmail.com>
On Mon, Sep 27, 2010 at 08:38:50PM +0200, Ohad Ben-Cohen wrote:
> On Mon, Sep 27, 2010 at 8:25 PM, John W. Linville
> <linville@tuxdriver.com> wrote:
> >> BTW, if this fuglet going to work if the driver is built modular?
> >>
> >> The idea of this things seems to be to allow arch platform code to call
> >> into it to set things. Such calls from arch platform code are going
> >> to be "obj-y"
> >>
> >> So if this is built into the modular driver, I can't see how it
> >> can work.
> >
> > Dave is right -- these Kconfig dependencies (or lack thereof) seem
> > to be wrong.
>
> This is why I had to put it in drivers/net/wireless/Makefile (in both
> the original patch and in the fix I sent earlier) and not in
> drivers/net/wireless/wl12xx/Makefile (as it was in the fix that Dave
> was referring to).
>
> This way it works with a modular driver.
That doesn't seem very helpful if someone selects
CONFIG_MACH_OMAP_ZOOM2=y
CONFIG_WL12XX_PLATFORM_DATA=n
or am I missing something?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] mm: do not print backtraces on GFP_ATOMIC failures
From: Andrew Morton @ 2010-09-27 18:49 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Eric Dumazet, Rik van Riel, linux-mm, linux-kernel, netdev
In-Reply-To: <20100927110723.6B37.A69D9226@jp.fujitsu.com>
On Mon, 27 Sep 2010 11:17:19 +0900 (JST)
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> > > > @@ -72,7 +72,7 @@ struct vm_area_struct;
> > > > /* This equals 0, but use constants in case they ever change */
> > > > #define GFP_NOWAIT (GFP_ATOMIC & ~__GFP_HIGH)
> > > > /* GFP_ATOMIC means both !wait (__GFP_WAIT not set) and use emergency pool */
> > > > -#define GFP_ATOMIC (__GFP_HIGH)
> > > > +#define GFP_ATOMIC (__GFP_HIGH | __GFP_NOWARN)
> > > > #define GFP_NOIO (__GFP_WAIT)
> > > > #define GFP_NOFS (__GFP_WAIT | __GFP_IO)
> > > > #define GFP_KERNEL (__GFP_WAIT | __GFP_IO | __GFP_FS)
> > >
> > > A much finer-tuned implementation would be to add __GFP_NOWARN just to
> > > the networking call sites. I asked about this in June and it got
> > > nixed:
> > >
> > > http://www.spinics.net/lists/netdev/msg131965.html
> > > --
> >
> > Yes, I remember this particular report was useful to find and correct a
> > bug.
> >
> > I dont know what to say.
> >
> > Being silent or verbose, it really depends on the context ?
>
> At least, MM developers don't want to track network allocation failure
> issue. We don't have enough knowledge in this area. To be honest, We
> are unhappy current bad S/N bug report rate ;)
>
> Traditionally, We hoped this warnings help to debug VM issue.
Well, no, not really. I thought that the main reason for having that
warning was to debug _callers_ of the memory allocator.
Firstly it tells us when callsites are being too optimistic: asking for
large amounts of contiguous pages, sometimes from atomic context.
Quite a number of such callsites have been fixed as a result.
Secondly, memory allocation failures are a rare event, so the calling
code's error paths are not well tested. This warning turns the bug
report "hey, my computer locked up" into the much better "hey, I got
this error message and then my computer locked up". This allows us to
go and look at the offending code and see if it is handling ENOMEM
correctly. However I don't recall this scenario ever having actually
happened.
> but
> It haven't happen. We haven't detect VM issue from this allocation
> failure report. Instead, We've received a lot of network allocation
> failure report.
>
> Recently, The S/N ratio became more bad. If the network device enable
> jumbo frame feature, order-2 GFP_ATOMIC allocation is called frequently.
> Anybody don't have to assume order-2 allocation can success anytime.
>
> I'm not against accurate warning at all. but I cant tolerate this
> semi-random warning steal our time. If anyone will not make accurate
> warning, I hope to remove this one completely instead.
We can disable the warning for only net drivers quite easily. I don't
have any strong opinions, really - yes, we get quite a few such bug
reports but most of them end up in my lap anyway and it can't be more
than one per week, shrug.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net tree related)
From: Ohad Ben-Cohen @ 2010-09-27 19:01 UTC (permalink / raw)
To: John W. Linville; +Cc: David Miller, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <20100927184445.GF11086@tuxdriver.com>
On Mon, Sep 27, 2010 at 8:44 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Mon, Sep 27, 2010 at 08:38:50PM +0200, Ohad Ben-Cohen wrote:
>> On Mon, Sep 27, 2010 at 8:25 PM, John W. Linville
>> <linville@tuxdriver.com> wrote:
>> >> BTW, if this fuglet going to work if the driver is built modular?
>> >>
>> >> The idea of this things seems to be to allow arch platform code to call
>> >> into it to set things. Such calls from arch platform code are going
>> >> to be "obj-y"
>> >>
>> >> So if this is built into the modular driver, I can't see how it
>> >> can work.
>> >
>> > Dave is right -- these Kconfig dependencies (or lack thereof) seem
>> > to be wrong.
>>
>> This is why I had to put it in drivers/net/wireless/Makefile (in both
>> the original patch and in the fix I sent earlier) and not in
>> drivers/net/wireless/wl12xx/Makefile (as it was in the fix that Dave
>> was referring to).
>>
>> This way it works with a modular driver.
>
> That doesn't seem very helpful if someone selects
>
> CONFIG_MACH_OMAP_ZOOM2=y
> CONFIG_WL12XX_PLATFORM_DATA=n
>
CONFIG_WL12XX_PLATFORM_DATA is selected automatically if the relevant
driver is selected (this is independent of the underlying arch/board):
config WL12XX_PLATFORM_DATA
bool
depends on WL1271_SDIO != n
default y
All we have to make sure is that it will be compiled built-in. If we
use drivers/net/wireless/wl12xx/Makefile, and we build a modular
wl1271_sdio, it won't (despite it being selected as y).
That's why I put it in drivers/net/wireless/Makefile.
In the original patch I put the code itself in
drivers/net/wireless/wl12xx to make it look nicer, but as Stephen
reported that seem to break building with a separate object folder...
So the fix I sent just moves that builtin code to
drivers/net/wireless. This maintains the builtin property even if the
driver is modular, and fixes the issue reported by Stephen.
Please tell me if you have any thoughts/suggestions.
Thanks,
Ohad.
> or am I missing something?
>
> John
> --
> John W. Linville Someday the world will need a hero, and you
> linville@tuxdriver.com might be all we have. Be ready.
>
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net tree related)
From: Ohad Ben-Cohen @ 2010-09-27 19:06 UTC (permalink / raw)
To: John W. Linville; +Cc: David Miller, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <AANLkTi=2KqQb+gvuigxb+-tSzawx7=q3HtnkkE6t_4XF@mail.gmail.com>
On Mon, Sep 27, 2010 at 9:01 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> On Mon, Sep 27, 2010 at 8:44 PM, John W. Linville
> <linville@tuxdriver.com> wrote:
>> On Mon, Sep 27, 2010 at 08:38:50PM +0200, Ohad Ben-Cohen wrote:
>>> On Mon, Sep 27, 2010 at 8:25 PM, John W. Linville
>>> <linville@tuxdriver.com> wrote:
>>> >> BTW, if this fuglet going to work if the driver is built modular?
>>> >>
>>> >> The idea of this things seems to be to allow arch platform code to call
>>> >> into it to set things. Such calls from arch platform code are going
>>> >> to be "obj-y"
>>> >>
>>> >> So if this is built into the modular driver, I can't see how it
>>> >> can work.
>>> >
>>> > Dave is right -- these Kconfig dependencies (or lack thereof) seem
>>> > to be wrong.
>>>
>>> This is why I had to put it in drivers/net/wireless/Makefile (in both
>>> the original patch and in the fix I sent earlier) and not in
>>> drivers/net/wireless/wl12xx/Makefile (as it was in the fix that Dave
>>> was referring to).
>>>
>>> This way it works with a modular driver.
>>
>> That doesn't seem very helpful if someone selects
>>
>> CONFIG_MACH_OMAP_ZOOM2=y
>> CONFIG_WL12XX_PLATFORM_DATA=n
That's a good point (it's a separate issue); we need to have a select there.
I'll send a patch.
>>
>
> CONFIG_WL12XX_PLATFORM_DATA is selected automatically if the relevant
> driver is selected (this is independent of the underlying arch/board):
>
> config WL12XX_PLATFORM_DATA
> bool
> depends on WL1271_SDIO != n
> default y
>
> All we have to make sure is that it will be compiled built-in. If we
> use drivers/net/wireless/wl12xx/Makefile, and we build a modular
> wl1271_sdio, it won't (despite it being selected as y).
>
> That's why I put it in drivers/net/wireless/Makefile.
>
> In the original patch I put the code itself in
> drivers/net/wireless/wl12xx to make it look nicer, but as Stephen
> reported that seem to break building with a separate object folder...
>
> So the fix I sent just moves that builtin code to
> drivers/net/wireless. This maintains the builtin property even if the
> driver is modular, and fixes the issue reported by Stephen.
>
> Please tell me if you have any thoughts/suggestions.
>
> Thanks,
> Ohad.
>
>> or am I missing something?
>>
>> John
>> --
>> John W. Linville Someday the world will need a hero, and you
>> linville@tuxdriver.com might be all we have. Be ready.
>>
>
^ permalink raw reply
* Re: [PATCH v3] xmit_compl_seq: information to reclaim vmsplice buffers
From: Eric Dumazet @ 2010-09-27 19:12 UTC (permalink / raw)
To: Tom Herbert; +Cc: Michael S. Tsirkin, netdev, davem, sridharr
In-Reply-To: <AANLkTimdrFuYONq6FvBW41AnhpA6Q+acSUmy4CiJatYL@mail.gmail.com>
Le lundi 27 septembre 2010 à 11:38 -0700, Tom Herbert a écrit :
> >
> > Can not packets referencing this memory
> > still be outstanding at the NIC device, if retransmit happens
> > before the ack but after the packet was passed to a device?
> >
> > It's true that the reftransmit will likely get discarded
> > by the remote end, but this might be a security issue
> > if an application puts sensitive data in the buffer
> > and that gets inadvertently sent on the wire, can it not?
> >
> Yes, this hole probably does exist. I don't know how to fix it other
> than more API that specifically reports when all references to a
> buffer are released. In the case of TCP that probably means we'd need
> a destructor.
Hmm, thats a serious problem IMHO. This would need destructor on data,
not on skb (see previous discussion about early skb_orphan and
af_packet)
Then, it needs to handle an ordered list of packets in flight, to be
able to return the sequence of the first packet.
Alternative would be to copy data on retransmits, for tcp sockets using
SOCK_XMIT_COMPL_SEQ. (ie not using skb_clone but skb_copy())
^ permalink raw reply
* Re: [PATCH] fix TSO FACK loss marking in tcp_mark_head_lost
From: Ilpo Järvinen @ 2010-09-27 19:20 UTC (permalink / raw)
To: David Miller; +Cc: ycheng, Netdev
In-Reply-To: <20100927.111114.124003889.davem@davemloft.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4893 bytes --]
On Mon, 27 Sep 2010, David Miller wrote:
> From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
> Date: Mon, 27 Sep 2010 15:22:09 +0300 (EEST)
>
> > On Fri, 24 Sep 2010, Yuchung Cheng wrote:
> >
> >> When TCP uses FACK algorithm to mark lost packets in
> >> tcp_mark_head_lost(), if the number of packets in the (TSO) skb is
> >> greater than the number of packets that should be marked lost, TCP
> >> incorrectly exits the loop and marks no packets lost in the skb. This
> >> underestimates tp->lost_out and affects the recovery/retransmission.
> >> This patch fargments the skb and marks the correct amount of packets
> >> lost.
> >>
> >> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> >> ---
> >> net/ipv4/tcp_input.c | 3 ++-
> >> 1 files changed, 2 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> >> index 1bc87a0..e4f472e 100644
> >> --- a/net/ipv4/tcp_input.c
> >> +++ b/net/ipv4/tcp_input.c
> >> @@ -2532,7 +2532,8 @@ static void tcp_mark_head_lost(struct sock *sk, int packets)
> >> cnt += tcp_skb_pcount(skb);
> >>
> >> if (cnt > packets) {
> >> - if (tcp_is_sack(tp) || (oldcnt >= packets))
> >> + if ((tcp_is_sack(tp) && !tcp_is_fack(tp)) ||
> >> + (oldcnt >= packets))
> >> break;
> >>
> >> mss = skb_shinfo(skb)->gso_size;
> >>
> >
> > Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
>
> BTW, the history is that this code was added to fix a bug because
> we didn't handle GSO packets at all at one point.
>
> But, conservatively, we didn't do splits here for SACK, and it was
> stated in the commit that we would look into it "at some point in the
> future" :-)
>
> --------------------
> commit c137f3dda04b0aee1bc6889cdc69185f53df8a82
> Author: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
> Date: Mon Apr 7 22:32:38 2008 -0700
>
> [TCP]: Fix NewReno's fast rexmit/recovery problems with GSOed skb
>
> Fixes a long-standing bug which makes NewReno recovery crippled.
> With GSO the whole head skb was marked as LOST which is in
> violation of NewReno procedure that only wants to mark one packet
> and ended up breaking our TCP code by causing counter overflow
> because our code was built on top of assumption about valid
> NewReno procedure. This manifested as triggering a WARN_ON for
> the overflow in a number of places.
>
> It seems relatively safe alternative to just do nothing if
> tcp_fragment fails due to oom because another duplicate ACK is
> likely to be received soon and the fragmentation will be retried.
>
> Special thanks goes to Soeren Sonnenburg <kernel@nn7.de> who was
> lucky enough to be able to reproduce this so that the warning
> for the overflow was hit. It's not as easy task as it seems even
> if this bug happens quite often because the amount of outstanding
> data is pretty significant for the mismarkings to lead to an
> overflow.
>
> Because it's very late in 2.6.25-rc cycle (if this even makes in
> time), I didn't want to touch anything with SACK enabled here.
> Fragmenting might be useful for it as well but it's more or less
> a policy decision rather than mandatory fix. Thus there's no need
> to rush and we can postpone considering tcp_fragment with SACK
> for 2.6.26.
>
> In 2.6.24 and earlier, this very same bug existed but the effect
> is slightly different because of a small changes in the if
> conditions that fit to the patch's context. With them nothing
> got lost marker and thus no retransmissions happened.
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> --------------------
>
> To be honest, we should probably just remove the whole tcp_is_sack()
> test, rather than special case FACK.
>
> The cost isn't what it was when this code was added. Back then we
> didn't have Ilpo's restransmit queue coalescing code, so it would make
> retransmit queue packet freeing more expensive. But since the
> coalescing code is there now, splitting all the time to record
> accurate loss information should be fine.
>
> Ilpo what do you say?
Removing it would add a bug for non-FACK SACK as lost_cnt_hint is
calculated a bit differently with it (only SACKed skbs count so
lost_cnt_hint is not changing over the whole skb with pcount > 1 while
it does change per each seg for FACK, basically non-FACK is all or
nothing as only passing by an already SACKed segment increases
lost_cnt_hint). ...I also fell to this trap once while reviewing this
change and wondered in my mind why not to d it for all variants :-). So
Yuchung's patch is fine as is afaict.
I disagree now with myself btw, it's not just "a policy decision" as we
do not retransmit some segments at all before RTO in some scenarios.
--
i.
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Willy Tarreau @ 2010-09-27 19:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100927.004239.58422076.davem@davemloft.net>
On Mon, Sep 27, 2010 at 12:42:39AM -0700, David Miller wrote:
> I still think it's completely broken that you want to close a
> connection for which data is still going to arrive.
>
> And I really can't think of why this can't be solved at the
> application level.
>
> Either there is an application level ACK that you have to wait for
> anyways, or there isn't and you receive the entire request packet
> before you start sending the data.
>
> If there is some kind of unpredictable "dribbling" after the request
> arrives, you really have to fix that.
>
> I honestly have no sympathy for an application level protocol that
> works this way, and I don't think the kernel is the place where this
> should be handled.
>
> Please don't exhaust me any further on this issue, thank you.
David,
I don't want to exhaust you on the issue and I really understand that
you quickly read my explanations and don't get the issues.
Two quick facts :
- HTTP allows the client to send whatever it wants whenever it wants
and allows the server to close after whatever response it wants.
Thus the server cannot predict that the client will talk.
- orphans don't work anymore, period. Why not remove that whole code
if you pretend it must not be used ? You still did not reply to this
point, and I'm sure you will still not respond to this, probably
because you've realized that there is indeed a bug which is probably
not easy to solve, given the limited use it has.
Please, wait for a moment when you have a bit more spare time and check
what the orphans may be used for with this issue => nothing. That's why
I'm trying to discuss a possible fix.
Thanks,
Willy
^ permalink raw reply
* Re: igmp: Staggered igmp report intervals for unsolicited igmp reports
From: David Stevens @ 2010-09-27 19:24 UTC (permalink / raw)
To: Christoph Lameter
Cc: David S. Miller,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Bob Arendt
In-Reply-To: <alpine.DEB.2.00.1009231021080.32567-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org> wrote on 09/23/2010 08:37:48 AM:
>
> On Wed, 22 Sep 2010, David Stevens wrote:
>
> > >
> > > Also increment the frequency so that we get a 10 reports send over a
> > > few seconds.
> >
> > Except you want to conform and not conform at the same time.
:-)
> > IGMPv2 should be: default count 2, interval 10secs
> > IGMPv3 should be: default count 2, interval 1sec
>
> This is during the period of unsolicited igmp reports. We do not know if
> this group is managed using V3 or V2 since no igmp query/report has been
> received yet.
The default is IGMPv3 unless a v2 querier is present. You can
force
it to be IGMPv2 with by having an IGMPv2 querier on the network or by
using
the force_igmp_version tunable.
> > ...and no way is it a good idea to send 10 unsolicited reports on an
> > Ethernet.
>
> Why would that be an issue?
Because the traffic for all joins is multiplied by >3. If you're
joining 1 group, maybe that wouldn't be an issue, but what if I join
100, and what if hundreds of other hosts on that network do too? And
applications that dynamically join and leave groups may do this
"normally."
Even 3 reports on switched networks with low loss is really unnecessary
overkill; 10 is just wasted bandwidth.
> The IGMPv2 RFC has no strict limit and RFC3376
> mentions that the retransmission occurs "Robustness Variable" times
> minus one. Choosing 10 for the "Robustness Variable" is certainly ok.
Both of them specify the default value and say a querier is the
mechanism for changing that. If you want to follow the RFC, the default
is "2", not "10." While it'd be reasonable for a sysadmin to tune this
per-interface without a querier, it's not reasonable to make all linux
systems on all networks more than triple the number of reports they send
from the RFC-specified default. Right?!? :-)
> If we do not increase the number of reports but just limit the interval
> then the chance of outages of a second or so during mc group creation
> causing routers missing igmp reports is significantly increased.
If you can't send on a group for 1 second, all of the initial
IGMPv3 reports will be lost about half of the time if we make that
conformant (it looks like it now uses the 10sec v2 time instead of the
1 sec v3 time it should). That's a problem IB needs to solve. Ideally,
you wouldn't want to return from the hardware join until you can actually
send the reports, but I expect there are locks held and that can't be 1
second
of spinning on a processor. So, I think you really should put a queue in
IB for that hardware multicast address and send those packets when/if you
get positive acknowledgement (much as done for ARP completion, but maybe
queue more than 1) from the fabric that you can use it. If you don't get
any sort of ACK for that, then you can instrument a delay for it, but
any fixed number you use may be either too big or too small for a
particular fabric.
+-DLS
--
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: TCP: orphans broken by RFC 2525 #2.17
From: Willy Tarreau @ 2010-09-27 19:24 UTC (permalink / raw)
To: Julian Anastasov; +Cc: netdev
In-Reply-To: <alpine.LFD.2.00.1009271159070.2191@u.domain.uli>
Hi Julian
[removed Davem from the CC upon his request, not to pollute him]
On Mon, Sep 27, 2010 at 12:12:24PM +0300, Julian Anastasov wrote:
> If it is not already mentioned, the application can
> know if sent data is acked. I think, ioctl SIOCOUTQ is for
> this purpose. May be the application that wants to send
> reliably HTTP error response before closing should do something
> like:
>
> - add this FD in some list for monitoring instead of keeping
> large connection state
> - use shutdown SHUT_WR to add FIN after response
> - use setsockopt SO_RCVBUF with some low value to close the
> RX window, we do not want the body
> - wait for POLLHUP (FIN), not for POLLIN because we want to
> ignore data, not to read it. Still, data can be read and
> dropped if needed to release the socket memory
> - use timer to limit the time we wait our data to be acked
> - use SIOCOUTQ to know if everything is received in peer and
> then close the fd
Thanks very much for this suggestion. I was looking for something
like this and even looked at the tcp_info struct, but it did not
look very easy to use.
Still, I think that polling on POLLIN and checking with SIOCOUTQ
on every read to see if the out queue is now empty would do the
trick, without forcing to read huge amounts of unnecessary data.
I'll simply enclose that inside a #ifdef LINUX and that should be
OK. It kinda sucks to be able to workaround low level issues at the
application level but at least this workaround is acceptable.
Regards,
Willy
^ permalink raw reply
* Re: igmp: Staggered igmp report intervals for unsolicited igmp reports
From: David Stevens @ 2010-09-27 19:32 UTC (permalink / raw)
To: Christoph Lameter
Cc: Jason Gunthorpe, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Bob Arendt
In-Reply-To: <alpine.DEB.2.00.1009231230100.2962-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org> wrote on 09/23/2010 10:37:28 AM:
>
> If all unsolicited igmp reports are lost then the router will
> only start forwarding the mc group after the reporting intervals
> (which could be in the range of minutes) when it triggers igmp reports
> through a general igmp query. Until that time the MC group looks dead.
And
> people and software may conclude that the **** network is broken.
You can, of course, add a querier (or configure it, assuming
an attached switch supports it) and set the query interval and robustness
count as appropriate for that network.
> This is a general issue for any network where configurations for MC
> forwarding is needed and where initial igmp reports may get lost.
Meaning "IB-only", right? :-) Maybe other NBMA networks too, but
certainly not a typical problem for typical networks (i.e., Ethernet).
> A staggering of time intervals would be a general solution to that
issue.
As would be having those networks queue packets for hardware addresses
they
know require a delay before a transmit can complete. But that approach
can't
adversely affect already-working solutions for typical networks, or
depart unnecessarily from established standard protocols.
+-DLS
--
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: linux-next: build failure after merge of the final tree (net tree related)
From: John W. Linville @ 2010-09-27 19:44 UTC (permalink / raw)
To: Ohad Ben-Cohen; +Cc: David Miller, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <AANLkTim9nHmhNLmECnYk-OHYmyk96tz65kd=ybz24M3Y@mail.gmail.com>
On Mon, Sep 27, 2010 at 09:06:09PM +0200, Ohad Ben-Cohen wrote:
> On Mon, Sep 27, 2010 at 9:01 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> > On Mon, Sep 27, 2010 at 8:44 PM, John W. Linville
> > <linville@tuxdriver.com> wrote:
> >> On Mon, Sep 27, 2010 at 08:38:50PM +0200, Ohad Ben-Cohen wrote:
> >>> On Mon, Sep 27, 2010 at 8:25 PM, John W. Linville
> >>> <linville@tuxdriver.com> wrote:
> >>> >> BTW, if this fuglet going to work if the driver is built modular?
> >>> >>
> >>> >> The idea of this things seems to be to allow arch platform code to call
> >>> >> into it to set things. Such calls from arch platform code are going
> >>> >> to be "obj-y"
> >>> >>
> >>> >> So if this is built into the modular driver, I can't see how it
> >>> >> can work.
> >>> >
> >>> > Dave is right -- these Kconfig dependencies (or lack thereof) seem
> >>> > to be wrong.
> >>>
> >>> This is why I had to put it in drivers/net/wireless/Makefile (in both
> >>> the original patch and in the fix I sent earlier) and not in
> >>> drivers/net/wireless/wl12xx/Makefile (as it was in the fix that Dave
> >>> was referring to).
> >>>
> >>> This way it works with a modular driver.
> >>
> >> That doesn't seem very helpful if someone selects
> >>
> >> CONFIG_MACH_OMAP_ZOOM2=y
> >> CONFIG_WL12XX_PLATFORM_DATA=n
>
>
> That's a good point (it's a separate issue); we need to have a select there.
>
> I'll send a patch.
No, maybe you don't need it -- the bool line by itself means there
is no menu item. So the default y does the job of selecting it all
the time (which kinda sucks for non-OMAP)...
> >>
> >
> > CONFIG_WL12XX_PLATFORM_DATA is selected automatically if the relevant
> > driver is selected (this is independent of the underlying arch/board):
> >
> > config WL12XX_PLATFORM_DATA
> > bool
> > depends on WL1271_SDIO != n
> > default y
> >
> > All we have to make sure is that it will be compiled built-in. If we
> > use drivers/net/wireless/wl12xx/Makefile, and we build a modular
> > wl1271_sdio, it won't (despite it being selected as y).
I don't understand this part. FWIW, Kconfig is not a strength for me.
But...
> > That's why I put it in drivers/net/wireless/Makefile.
Can't we do this? It seems to work (i.e. the symbols from
wl12xx_platform_data.o end-up in built-in.o).
From d8ddd0ebe8ae3791ba9c76a506bfcdd60be40f5b Mon Sep 17 00:00:00 2001
From: John W. Linville <linville@tuxdriver.com>
Date: Mon, 27 Sep 2010 14:00:51 -0400
Subject: [PATCH] wl12xx: fix separate-object-folder builds
Make this go away (happens when building with a separate object
directory):
Assembler messages:
Fatal error: can't create drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.o: No such file or directory
drivers/net/wireless/wl12xx/wl12xx_platform_data.c: In function 'wl12xx_get_platform_data':
drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: error: cannot open drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.gcno
drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: confused by earlier errors, bailing out
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
---
drivers/net/wireless/Makefile | 3 +--
drivers/net/wireless/wl12xx/Makefile | 3 +++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
index 85af697..a13a602 100644
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -50,7 +50,6 @@ obj-$(CONFIG_ATH_COMMON) += ath/
obj-$(CONFIG_MAC80211_HWSIM) += mac80211_hwsim.o
obj-$(CONFIG_WL12XX) += wl12xx/
-# small builtin driver bit
-obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx/wl12xx_platform_data.o
+obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx/
obj-$(CONFIG_IWM) += iwmc3200wifi/
diff --git a/drivers/net/wireless/wl12xx/Makefile b/drivers/net/wireless/wl12xx/Makefile
index 078b439..0d334d6 100644
--- a/drivers/net/wireless/wl12xx/Makefile
+++ b/drivers/net/wireless/wl12xx/Makefile
@@ -16,3 +16,6 @@ wl1271-$(CONFIG_NL80211_TESTMODE) += wl1271_testmode.o
obj-$(CONFIG_WL1271) += wl1271.o
obj-$(CONFIG_WL1271_SPI) += wl1271_spi.o
obj-$(CONFIG_WL1271_SDIO) += wl1271_sdio.o
+
+# small builtin driver bit
+obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx_platform_data.o
--
1.7.2.3
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: igmp: Allow mininum interval specification for igmp timers.
From: David Stevens @ 2010-09-27 19:55 UTC (permalink / raw)
To: David Miller
Cc: cl-vYTEC60ixJUAvxtiuMwx3w, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
netdev-owner-u79uwXL29TY76Z2rM5mHXA, rda-x0S3BwdUo6DQT0dZR+AlfA
In-Reply-To: <20100927.105444.214208865.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote on 09/27/2010 10:54:44 AM:
> This patch on the other hand is attacking a different problem,
> namely avoiding the worst cases caused by the randomization we
> do for the timer.
>
> With bad luck this thing times out way too fast because the total of
> all of the randomized intervals can end up being very small, and I
> think we should fix that independently of the other issues hit by the
> IB folks.
I think I'm caught up on the discussion now. For IGMPv3, we
would send all the reports always in < 2 secs, and the average would
be < 1 sec, so I'm not sure any sort of tweaks we do to enforce a
minimum randomized interval are compatible with IGMPv3 and still
solve IB's problem.
As I said before, I think per protocol, back-to-back is both
allowed and not a problem, even if both subsequent randomized reports
come out to 0 time. But if we wanted to enforce a minimum interval
of, say, X, then I think the better way to do that is to set the
timer to X + rand(Interval-X) and not a table of fixed intervals
as in the original patch. For v2, X=1 or 2 sec and Interval=10
might work well, but for v3, the entire interval is 1 sec and I
think I saw that the set-up time for the fabric may be on the
order of 1 sec.
I also don't think that we want those kinds of delays on
Ethernet. A program may join and send lots of traffic in 1 sec,
and if the immediate join is lost, one of the quickly-following
<1 sec duplicate reports will make it recover and work. Delaying
the minimum would guarantee it wouldn't work until that minimum
and drop all that traffic if the immediate report is lost, then.
Really, of course, I think the solution belongs in IB, but
if we did anything in IGMP, I'd prefer it were a per-interface
tunable that defaults as in the RFC. Since you can change the
interval and # of reports through a querier now, exporting the
default values of (10,2) for v2 and (1,2) for v3 to instead be
per-interface tunables and then bumped as needed for IB would
allow tweaking without running a querier. But a querier that's
using default values would also override that and cause the
problem all over again. Queuing in the driver until the MAC
address is usable solves it generally.
Also, MLD and IPv6 will have all these same issues, and
working multicasting is even more important there.
+-DLS
--
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: [PATCH] iwl3945: queue the right work if the scan needs to be aborted
From: Guy, Wey-Yi W @ 2010-09-27 19:59 UTC (permalink / raw)
To: Florian Mickler
Cc: linux-wireless@vger.kernel.org, Chatre, Reinette,
Intel Linux Wireless, John W. Linville, Berg, Johannes, Zhu Yi,
Cahill, Ben M, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20100927081358.07b30327@schatten.dmk.lab>
Hi Florian,
Agree the patch is needed for .35 and .36.
Thanks
Wey
-----Original Message-----
From: Florian Mickler [mailto:florian@mickler.org]
Sent: Sunday, September 26, 2010 11:14 PM
To: Guy, Wey-Yi W
Cc: linux-wireless@vger.kernel.org; Chatre, Reinette; Intel Linux Wireless; John W. Linville; Berg, Johannes; Zhu Yi; Cahill, Ben M; netdev@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iwl3945: queue the right work if the scan needs to be aborted
On Fri, 24 Sep 2010 12:51:08 -0700
"Guy, Wey-Yi" <wey-yi.w.guy@intel.com> wrote:
> Hi Florian,
>
> Thanks for sending the patch, the scan operation in iwlwifi just being
> modified and the changes you have no longer apply.please check the
> latest kernel.
>
> Thanks
> Wey
>
Ok, I checked out
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6.git
and it definitely looks better in there. This patch shouldn't be
necessary for that.
Do you plan on submitting this for 2.6.36 or .37?
I think my patch should fix the instance reported in the bug in a less
invasive manner.
Only remaining question is why it did only show up now. But that's
probably due to the workqueue changes.
Regards,
Flo
^ permalink raw reply
* Re: [Bugme-new] [Bug 18952] New: The mount of SYN retries is not equal to /proc/sys/net/ipv4/tcp_syn_retries
From: Damian Lukowski @ 2010-09-27 20:00 UTC (permalink / raw)
To: David Miller; +Cc: yuri, akpm, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <20100927.011046.45906887.davem@davemloft.net>
Ok, I see.
When I read your mail this morning, I was afraid, that this is another
bug in the calculation routine. However, the routine seems ok to me.
The problem is the high discrepancy between the RTO_MIN-based
calculation and TCP_TIMEOUT_INIT-based actual backoff in the SYN-case.
Yuris example did not reveal a conceptually new bug, as the same
behaviour can be observed on pre 2.6.32 kernels at higher values.
I tested wget on a 2.6.26 kernel with timeout values of 300 and above.
All runs did time out after 189 seconds, with the sysctl-value as their
hard limit.
My suggestion for solving this issue:
Introducing a third boolean parameter for retransmits_timed_out()
indicating whether the socket is in SYN state or not. In the SYN case,
TCP_TIMEOUT_INIT will be used for the calculation instead of
TCP_RTO_MIN.
Is that ok?
Regards
Damian
Am Montag, den 27.09.2010, 01:10 -0700 schrieb David Miller:
> From: Yuri Chislov <yuri@itinteg.net>
> Date: Mon, 27 Sep 2010 10:07:06 +0200
>
> > It looks like the behavior changed in 2.6.32. 2.6.32 and up, uses some
> > calculation instead of a direct definition of the retries number, that makes it
> > harder to achieve the necessary system behavior.
> >
> > The default behavior of the system changed completely
> > (the old default connect timeout was ~ 180 seconds, while the new one is ~21
> > sec).
> >
> > The new behavior invalidates the kernel documentation and tcp man page.
> >
> > It's not possible to set a connect timeout > 25 sec in the applications while
> > using the default values in /proc.
> >
> > From my view point is regression.
>
> Agreed, Damian you have to fix this.
>
> Otherwise I'm reverting all of your Revert Backoff commits.
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Willy Tarreau @ 2010-09-27 20:00 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20100927080222.GA31309@gondor.apana.org.au>
Hi Herbert,
On Mon, Sep 27, 2010 at 04:02:22PM +0800, Herbert Xu wrote:
> Willy Tarreau <w@1wt.eu> wrote:
> >
> > Looking more closely, I noticed that in traces showing the issue,
> > the client was sending an additional CRLF after the data in a
> > separate packet (permitted eventhough not recommended).
>
> Where is this permitted? RFC2616 says:
>
> Certain buggy HTTP/1.0 client implementations generate
> extra CRLF's after a POST request. To restate what is
> explicitly forbidden by the BNF, an HTTP/1.1 client MUST
> NOT preface or follow a request with an extra CRLF.
And the paragraph just before says :
In the interest of robustness, servers SHOULD ignore any empty
line(s) received where a Request-Line is expected. In other words, if
the server is reading the protocol stream at the beginning of a
message and receives a CRLF first, it should ignore the CRLF.
That's the usual principle : be strict with what you send and be liberal
with what you accept. Also, clients are encouraged to pipeline requests
over a connection and may very legally send a new request before the
current response is completely received.
> This workaround for broken HTTP clients definitely does not belong
> in the TCP stack.
I'm not trying to workaround broken HTTP clients using the TCP stack,
that's contrary to my principles. I want to ensure that the orphans code
that should legitimately be used can be used. And if orphans work again
as advertised, then the HTTP issue that revealed the issue automatically
gets fixed.
Regards,
Willy
^ permalink raw reply
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Eric Dumazet @ 2010-09-27 20:00 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Julian Anastasov, netdev
In-Reply-To: <20100927192450.GU12373@1wt.eu>
Le lundi 27 septembre 2010 à 21:24 +0200, Willy Tarreau a écrit :
> Hi Julian
>
> [removed Davem from the CC upon his request, not to pollute him]
>
> On Mon, Sep 27, 2010 at 12:12:24PM +0300, Julian Anastasov wrote:
> > If it is not already mentioned, the application can
> > know if sent data is acked. I think, ioctl SIOCOUTQ is for
> > this purpose. May be the application that wants to send
> > reliably HTTP error response before closing should do something
> > like:
> >
> > - add this FD in some list for monitoring instead of keeping
> > large connection state
> > - use shutdown SHUT_WR to add FIN after response
> > - use setsockopt SO_RCVBUF with some low value to close the
> > RX window, we do not want the body
> > - wait for POLLHUP (FIN), not for POLLIN because we want to
> > ignore data, not to read it. Still, data can be read and
> > dropped if needed to release the socket memory
> > - use timer to limit the time we wait our data to be acked
> > - use SIOCOUTQ to know if everything is received in peer and
> > then close the fd
>
> Thanks very much for this suggestion. I was looking for something
> like this and even looked at the tcp_info struct, but it did not
> look very easy to use.
>
> Still, I think that polling on POLLIN and checking with SIOCOUTQ
> on every read to see if the out queue is now empty would do the
> trick, without forcing to read huge amounts of unnecessary data.
>
> I'll simply enclose that inside a #ifdef LINUX and that should be
> OK. It kinda sucks to be able to workaround low level issues at the
> application level but at least this workaround is acceptable.
Just a point :
RFC1122 :
A host MAY implement a "half-duplex" TCP close sequence, so
that an application that has called CLOSE cannot continue to
read data from the connection. If such a host issues a
CLOSE call while received data is still pending in TCP, or
if new data is received after CLOSE is called, its TCP
SHOULD send a RST to show that data was lost.
Maybe only linux respects the RFC ? ;)
^ permalink raw reply
* (unknown)
From: Jason Gunthorpe @ 2010-09-27 20:05 UTC (permalink / raw)
To: David Stevens
Cc: Christoph Lameter, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Bob Arendt
Bcc:
Subject: Re: igmp: Staggered igmp report intervals for unsolicited igmp
reports
Reply-To:
In-Reply-To: <OF871D4733.876C9DA0-ON882577AB.006AB200-882577AB.006B6101-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
On Mon, Sep 27, 2010 at 12:32:45PM -0700, David Stevens wrote:
> You can, of course, add a querier (or configure it, assuming an
> attached switch supports it) and set the query interval and
> robustness count as appropriate for that network.
Presumably the IPoIB multicast router should already be the querier..
How does this help handling joins to new groups?
> As would be having those networks queue packets for hardware
> addresses they know require a delay before a transmit can
> complete. But that approach can't adversely affect already-working
> solutions for typical networks, or depart unnecessarily from
> established standard protocols.
There is no way to know when a hardware address is 'ready' in a IGMPv2
sense.. The problem with IGMPv2 and any network that doesn't flood
multicast to all nodes is that there is no way to know when all IGMPv2
listeners are listening on the group you just created.
For IGMPv2 there is a special hack in the IPoIB routers that cause
them to automatically join the IP multicast groups as they are created
so they can get the per-group IGMP messages, and this process takes
time and is completely opaque to the end nodes.
IB could emulate something like ethernet flooding by sending packets
to the permanent 'broadcast' (all-IP-endpoints) multicast group - but
it has no way to know when that is necessary and when it is not.
Sending IGMPv2 packets to the group address that is being managed
(rather than an IGMP specific group like in v3) is a design choice
that probably only works well on ethernet :(
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: TCP: orphans broken by RFC 2525 #2.17
From: Rick Jones @ 2010-09-27 20:08 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Herbert Xu, netdev
In-Reply-To: <20100927200018.GY12373@1wt.eu>
Willy Tarreau wrote:
> Hi Herbert,
>
> On Mon, Sep 27, 2010 at 04:02:22PM +0800, Herbert Xu wrote:
>
>>Willy Tarreau <w@1wt.eu> wrote:
>>
>>>Looking more closely, I noticed that in traces showing the issue,
>>>the client was sending an additional CRLF after the data in a
>>>separate packet (permitted eventhough not recommended).
>>
>>Where is this permitted? RFC2616 says:
>>
>> Certain buggy HTTP/1.0 client implementations generate
>> extra CRLF's after a POST request. To restate what is
>> explicitly forbidden by the BNF, an HTTP/1.1 client MUST
>> NOT preface or follow a request with an extra CRLF.
>
>
> And the paragraph just before says :
>
> In the interest of robustness, servers SHOULD ignore any empty
> line(s) received where a Request-Line is expected. In other words, if
> the server is reading the protocol stream at the beginning of a
> message and receives a CRLF first, it should ignore the CRLF.
It is the HTTP server code being addressed there, not the underlying TCP stack
is it not?
rick jones
^ permalink raw reply
* Re: [PATCH] iwl3945: queue the right work if the scan needs to be aborted
From: Guy, Wey-Yi @ 2010-09-27 20:11 UTC (permalink / raw)
To: Florian Mickler
Cc: linux-wireless@vger.kernel.org, Chatre, Reinette,
Intel Linux Wireless, John W. Linville, Berg, Johannes, Zhu Yi,
Cahill, Ben M, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1285345323-4250-1-git-send-email-florian@mickler.org>
On Fri, 2010-09-24 at 09:22 -0700, Florian Mickler wrote:
> iwl3945's scan_completed calls into the mac80211 stack which triggers a
> warn on if there is no scan outstanding.
>
> This can be avoided by not calling scan_completed but abort_scan in
> iwl3945_request_scan in the done: branch of the function which is used
> as an error out.
>
> The done: branch seems to be an error-out branch, as, for example, if
> iwl_is_ready(priv) returns false the done: branch is executed.
>
> NOTE:
> I'm not familiar with the driver at all.
> I just quickly scanned as a reaction to
>
> https://bugzilla.kernel.org/show_bug.cgi?id=17722
>
> the users of scan_completed in the iwl3945 driver and noted the odd
> discrepancy between the comment above this instance and the comment in
> mac80211 scan_completed function.
> Signed-off-by: Florian Mickler <florian@mickler.org>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> ---
go into wireless-2.6 and stable only, scan fix already in
wireless-next-2.6
Thanks
Wey
> drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 2 +-
> drivers/net/wireless/iwlwifi/iwl3945-base.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> index 9dd9e64..8fd00a6 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> @@ -1411,7 +1411,7 @@ void iwlagn_request_scan(struct iwl_priv *priv, struct ieee80211_vif *vif)
> clear_bit(STATUS_SCAN_HW, &priv->status);
> clear_bit(STATUS_SCANNING, &priv->status);
> /* inform mac80211 scan aborted */
> - queue_work(priv->workqueue, &priv->scan_completed);
> + queue_work(priv->workqueue, &priv->abort_scan);
> }
>
> int iwlagn_manage_ibss_station(struct iwl_priv *priv,
> diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> index 59a308b..d31661c 100644
> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> @@ -3018,7 +3018,7 @@ void iwl3945_request_scan(struct iwl_priv *priv, struct ieee80211_vif *vif)
> clear_bit(STATUS_SCANNING, &priv->status);
>
> /* inform mac80211 scan aborted */
> - queue_work(priv->workqueue, &priv->scan_completed);
> + queue_work(priv->workqueue, &priv->abort_scan);
> }
>
> static void iwl3945_bg_restart(struct work_struct *data)
^ permalink raw reply
* Re:
From: David Stevens @ 2010-09-27 20:14 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Christoph Lameter, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
netdev-owner-u79uwXL29TY76Z2rM5mHXA, Bob Arendt
In-Reply-To: <20100927200500.GB25879-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote on 09/27/2010
01:05:00 PM:
> On Mon, Sep 27, 2010 at 12:32:45PM -0700, David Stevens wrote:
>
> > You can, of course, add a querier (or configure it, assuming an
> > attached switch supports it) and set the query interval and
> > robustness count as appropriate for that network.
>
> Presumably the IPoIB multicast router should already be the querier..
> How does this help handling joins to new groups?
Because a querier can set the robustness value and
query interval to anything you want. In the original report,
he's not running a querier. The fact that it's a new group
doesn't matter -- these are per-interface.
+-DLS
--
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: linux-next: build failure after merge of the final tree (net tree related)
From: Ohad Ben-Cohen @ 2010-09-27 20:18 UTC (permalink / raw)
To: John W. Linville; +Cc: David Miller, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <20100927194408.GG11086@tuxdriver.com>
On Mon, Sep 27, 2010 at 9:44 PM, John W. Linville
<linville@tuxdriver.com> wrote:
>> On Mon, Sep 27, 2010 at 9:01 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
>> >> CONFIG_MACH_OMAP_ZOOM2=y
>> >> CONFIG_WL12XX_PLATFORM_DATA=n
>>
>> That's a good point (it's a separate issue); we need to have a select there.
>>
>> I'll send a patch.
>
> No, maybe you don't need it -- the bool line by itself means there
> is no menu item. So the default y does the job of selecting it all
> the time (which kinda sucks for non-OMAP)...
The default y will kick in only if WL1271_SDIO is selected:
>> > config WL12XX_PLATFORM_DATA
>> > bool
>> > depends on WL1271_SDIO != n
>> > default y
But if we don't select this driver at all, we better have something like:
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index 95deae3..51e4ba9 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -32,7 +32,20 @@ struct wl12xx_platform_data {
int board_ref_clock;
};
+#ifdef CONFIG_WL12XX_PLATFORM_DATA
+
int wl12xx_set_platform_data(const struct wl12xx_platform_data *data);
+
+#else
+
+static inline int wl12xx_set_platform_data(const struct
+ wl12xx_platform_data *data)
+{
+ return -ENOSYS;
+}
+
+#endif
+
const struct wl12xx_platform_data *wl12xx_get_platform_data(void);
#endif
It's better than forcing a select - if we don't need the driver, we
don't need this piece of code too.
I'll give this a spin tomorrow and send it over nicely.
> Can't we do this? It seems to work (i.e. the symbols from
> wl12xx_platform_data.o end-up in built-in.o).
Yes, this one looks good !
Thanks a lot, John.
>
> From d8ddd0ebe8ae3791ba9c76a506bfcdd60be40f5b Mon Sep 17 00:00:00 2001
> From: John W. Linville <linville@tuxdriver.com>
> Date: Mon, 27 Sep 2010 14:00:51 -0400
> Subject: [PATCH] wl12xx: fix separate-object-folder builds
>
> Make this go away (happens when building with a separate object
> directory):
>
> Assembler messages:
> Fatal error: can't create drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.o: No such file or directory
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c: In function 'wl12xx_get_platform_data':
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: error: cannot open drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.gcno
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: confused by earlier errors, bailing out
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> ---
> drivers/net/wireless/Makefile | 3 +--
> drivers/net/wireless/wl12xx/Makefile | 3 +++
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
> index 85af697..a13a602 100644
> --- a/drivers/net/wireless/Makefile
> +++ b/drivers/net/wireless/Makefile
> @@ -50,7 +50,6 @@ obj-$(CONFIG_ATH_COMMON) += ath/
> obj-$(CONFIG_MAC80211_HWSIM) += mac80211_hwsim.o
>
> obj-$(CONFIG_WL12XX) += wl12xx/
> -# small builtin driver bit
> -obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx/wl12xx_platform_data.o
> +obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx/
>
> obj-$(CONFIG_IWM) += iwmc3200wifi/
> diff --git a/drivers/net/wireless/wl12xx/Makefile b/drivers/net/wireless/wl12xx/Makefile
> index 078b439..0d334d6 100644
> --- a/drivers/net/wireless/wl12xx/Makefile
> +++ b/drivers/net/wireless/wl12xx/Makefile
> @@ -16,3 +16,6 @@ wl1271-$(CONFIG_NL80211_TESTMODE) += wl1271_testmode.o
> obj-$(CONFIG_WL1271) += wl1271.o
> obj-$(CONFIG_WL1271_SPI) += wl1271_spi.o
> obj-$(CONFIG_WL1271_SDIO) += wl1271_sdio.o
> +
> +# small builtin driver bit
> +obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx_platform_data.o
> --
> 1.7.2.3
>
>
> --
> John W. Linville Someday the world will need a hero, and you
> linville@tuxdriver.com might be all we have. Be ready.
>
^ permalink raw reply related
* Re: TCP: orphans broken by RFC 2525 #2.17
From: Willy Tarreau @ 2010-09-27 20:20 UTC (permalink / raw)
To: Rick Jones; +Cc: Herbert Xu, netdev
In-Reply-To: <4CA0F9AD.5050302@hp.com>
On Mon, Sep 27, 2010 at 01:08:13PM -0700, Rick Jones wrote:
> Willy Tarreau wrote:
> >Hi Herbert,
> >
> >On Mon, Sep 27, 2010 at 04:02:22PM +0800, Herbert Xu wrote:
> >
> >>Willy Tarreau <w@1wt.eu> wrote:
> >>
> >>>Looking more closely, I noticed that in traces showing the issue,
> >>>the client was sending an additional CRLF after the data in a
> >>>separate packet (permitted eventhough not recommended).
> >>
> >>Where is this permitted? RFC2616 says:
> >>
> >> Certain buggy HTTP/1.0 client implementations generate
> >> extra CRLF's after a POST request. To restate what is
> >> explicitly forbidden by the BNF, an HTTP/1.1 client MUST
> >> NOT preface or follow a request with an extra CRLF.
> >
> >
> >And the paragraph just before says :
> >
> > In the interest of robustness, servers SHOULD ignore any empty
> > line(s) received where a Request-Line is expected. In other words, if
> > the server is reading the protocol stream at the beginning of a
> > message and receives a CRLF first, it should ignore the CRLF.
>
> It is the HTTP server code being addressed there, not the underlying TCP
> stack is it not?
yes, precisely.
regards,
Willy
^ permalink raw reply
* Re: igmp: Allow mininum interval specification for igmp timers.
From: Christoph Lameter @ 2010-09-27 20:20 UTC (permalink / raw)
To: David Stevens; +Cc: David Miller, linux-rdma, netdev, netdev-owner, rda
In-Reply-To: <OFC4EC0538.26831D99-ON882577AB.006B8055-882577AB.006D75FF@us.ibm.com>
On Mon, 27 Sep 2010, David Stevens wrote:
> > With bad luck this thing times out way too fast because the total of
> > all of the randomized intervals can end up being very small, and I
> > think we should fix that independently of the other issues hit by the
> > IB folks.
>
> I think I'm caught up on the discussion now. For IGMPv3, we
> would send all the reports always in < 2 secs, and the average would
> be < 1 sec, so I'm not sure any sort of tweaks we do to enforce a
> minimum randomized interval are compatible with IGMPv3 and still
> solve IB's problem.
Ok thanks for the effort but so far I do not see you having caught up. I'd
rather avoid responding to the misleading statements you made in other
replies and just respond to where you missed the boat here.
> As I said before, I think per protocol, back-to-back is both
> allowed and not a problem, even if both subsequent randomized reports
> come out to 0 time. But if we wanted to enforce a minimum interval
> of, say, X, then I think the better way to do that is to set the
> timer to X + rand(Interval-X) and not a table of fixed intervals
The second patch sets the intervals to X .. X + Rand (interval) and not to
a table of fixed intervals as you state here. I have pointed this out
before.
> as in the original patch. For v2, X=1 or 2 sec and Interval=10
> might work well, but for v3, the entire interval is 1 sec and I
> think I saw that the set-up time for the fabric may be on the
> order of 1 sec.
Again there is no knowledge about V2 or V3 without a query and this is
during the period when no querier is known yet. You stated elsewhere that
I can assume V3 by default? So 1 sec?
> I also don't think that we want those kinds of delays on
> Ethernet. A program may join and send lots of traffic in 1 sec,
> and if the immediate join is lost, one of the quickly-following
> <1 sec duplicate reports will make it recover and work. Delaying
> the minimum would guarantee it wouldn't work until that minimum
> and drop all that traffic if the immediate report is lost, then.
There can be any number of reasons that a short outage could prevent the
packets from going through. A buffer overrun (that you mentioned
elsewhere) usually causes lots of packets to be lost. Buffer overrun
scenarios usually mean that all igmp queries are lost.
> Really, of course, I think the solution belongs in IB, but
> if we did anything in IGMP, I'd prefer it were a per-interface
> tunable that defaults as in the RFC. Since you can change the
> interval and # of reports through a querier now, exporting the
> default values of (10,2) for v2 and (1,2) for v3 to instead be
> per-interface tunables and then bumped as needed for IB would
> allow tweaking without running a querier. But a querier that's
> using default values would also override that and cause the
> problem all over again. Queuing in the driver until the MAC
> address is usable solves it generally.
There is no solution on the IB layer since there is no notification when
the fabric reconfiguration necessary for an multicast group is complete.
The querier is of not use since (for the gazillionth of times) this is an
unsolicited IGMP report. If there is a querier then the unsolicited igmp
reports would not be used but the timeout indicated by the querier would
be used.
^ permalink raw reply
* Re:
From: Christoph Lameter @ 2010-09-27 20:23 UTC (permalink / raw)
To: David Stevens
Cc: Jason Gunthorpe, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
netdev-owner-u79uwXL29TY76Z2rM5mHXA, Bob Arendt
In-Reply-To: <OF056C7E7C.A9A5EFC7-ON882577AB.006E6B89-882577AB.006F2C1E-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
On Mon, 27 Sep 2010, David Stevens wrote:
> Because a querier can set the robustness value and
> query interval to anything you want. In the original report,
> he's not running a querier. The fact that it's a new group
> doesn't matter -- these are per-interface.
The per interface settings are used to force an IGMP version overriding
any information by the queriers. You would not want to enable that because
it disables support for other IGMP versions. Without the override
different version of IGMP can be handled per MC group.
--
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:
From: Bob Arendt @ 2010-09-27 20:54 UTC (permalink / raw)
To: Christoph Lameter
Cc: David Stevens, Jason Gunthorpe,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <alpine.DEB.2.00.1009271521510.14117-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
On 09/27/10 13:23, Christoph Lameter wrote:
> On Mon, 27 Sep 2010, David Stevens wrote:
>
>> Because a querier can set the robustness value and
>> query interval to anything you want. In the original report,
>> he's not running a querier. The fact that it's a new group
>> doesn't matter -- these are per-interface.
>
> The per interface settings are used to force an IGMP version overriding
> any information by the queriers. You would not want to enable that because
> it disables support for other IGMP versions. Without the override
> different version of IGMP can be handled per MC group.
>
If a network vlan has IGMPv3 capability, then it should be able
to support both v2 and v3 Joins (clients). But if the vlan is
IGMPv2 only, then an initial Join from a Linux client might go out
as v3 (if it hasn't seen a query yet) and be ignored. I believe
this is the case that force_igmp_version really addresses.
And it turns out that force_igmp_version=2 doesn't fully work.
If the host sees a IGMPv3 query, it still responds with a v3 Join
despite the flag. Bug report and candidate patch here:
https://bugzilla.kernel.org/show_bug.cgi?id=18212
--
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
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