Re: soreceive_stream: mbuf leak if called with mp0 and MSG_WAITALL
Hi,
On Tue, 06 Mar 2012 20:50:34 +0100 Andre Oppermann wrote:
AO> On 05.09.2011 21:58, Mikolaj Golub wrote:
>>
>> On Sun, 04 Sep 2011 12:30:53 +0300 Mikolaj Golub wrote:
>>
>> MG> Apparently soreceive_stream() has an issue if it is called to
>> receive data as a
>> MG> mbuf chain (by supplying an non zero mbuf **mp0) and with
>> MSG_WAITALL set.
>>
>> MG> I ran into this issue with smbfs, which uses soreceive() exactly in
>> this way
>> MG> (see netsmb/smb_trantcp.c:nbssn_recv()).
>>
>> Stressing smbfs a little I also observed the following soreceive_stream()
>> related panic:
AO> Hi Mikolaj,
AO> thank you very much for testing, reporting and fixing bugs in
soreceive_stream().
AO> I've altered your proposed patches a bit and committed them into my
workqueue
AO> with the following revisions:
AO> http://svn.freebsd.org/changeset/base/232617
AO> http://svn.freebsd.org/changeset/base/232618
AO> Would you mind testing them again before they go into HEAD?
With this patch smb mount fails with the error:
smb_iod_recvall: tran return NULL without error
AO> Index: sys/kern/uipc_socket.c
AO> ===
AO> --- sys/kern/uipc_socket.c (revision 232616)
AO> +++ sys/kern/uipc_socket.c (revision 232617)
AO> @@ -2044,7 +2044,7 @@ deliver:
AO>if (mp0 != NULL) {
AO>/* Dequeue as many mbufs as possible. */
AO>if (!(flags & MSG_PEEK) && len >= sb->sb_mb->m_len) {
AO> - for (*mp0 = m = sb->sb_mb;
AO> + for (m = sb->sb_mb;
AO> m != NULL && m->m_len <= len;
AO> m = m->m_next) {
AO>len -= m->m_len;
AO> @@ -2052,10 +2052,15 @@ deliver:
AO>sbfree(sb, m);
AO>n = m;
AO>}
AO> + n->m_next = NULL;
AO>sb->sb_mb = m;
AO> + sb->sb_lastrecord = sb->sb_mb;
AO>if (sb->sb_mb == NULL)
AO>SB_EMPTY_FIXUP(sb);
AO> - n->m_next = NULL;
AO> + if (*mp0 != NULL)
AO> + m_cat(*mp0, m);
AO> + else
AO> + *mp0 = m;
AO>}
At that moment m points to the end of the chain. Shouldn't *mp0 be set to
sb->sb_mb before the "for" loop?
AO>/* Copy the remainder. */
AO>if (len > 0) {
AO> @@ -2066,9 +2071,9 @@ deliver:
AO>if (m == NULL)
AO>len = 0;/* Don't flush data from
sockbuf. */
AO>else
AO> - uio->uio_resid -= m->m_len;
AO> + uio->uio_resid -= len;
AO>if (*mp0 != NULL)
AO> - n->m_next = m;
AO> + m_cat(*mp0, m);
AO>else
AO>*mp0 = m;
AO>if (*mp0 == NULL) {
AO>
--
Mikolaj Golub
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Multiqueue support, igb
Hello, What is the current state of support for multithreaded TCP processing in CURRENT? If a NIC supports multiple queues, will they be used automatically or net.isr.numthreads needs to be increased? I have this situation on a machine with an igb card: irq256: igb0:que 0103573 11 irq257: igb0:que 1 10094 1 irq258: igb0:que 2 18231 2 irq259: igb0:que 3 18186 2 This looks like the first queue is used ~~ 10x more often than the others. Is this a problem? signature.asc Description: OpenPGP digital signature
gsoc
hi i am teja,student.i am good in c, operating system internals and network programming. i am trying to develop a protocol by synchronizing between raw sockets and libpcap library. i have an idea of developing a transport layer protocol that could provide a secure communication between 2 systems where the data need not be encripted(avoid overhead) and with small payload.i am working on this by creating a private protocol which can only be detected by source and destination systems. can i do it as a gsoc project .i need some advice can anyone help me? thankyou ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: gsoc
On Thursday 08 March 2012 13:51:47 Teja K wrote: > hi i am teja,student.i am good in c, operating system internals and network > programming. i am trying to develop a protocol by synchronizing between raw > sockets and libpcap library. > i have an idea of developing a transport layer protocol that could provide > a secure communication between 2 systems where the data need not be > encripted(avoid overhead) and with small payload.i am working on this by > creating a private protocol which can only be detected by source and > destination systems. can i do it as a gsoc project .i need some advice can > anyone help me? thankyou Have you thrown a look at tcpcrypt.org which has roughly the same goal, and already has a working userland implementation? Maybe you could get some idea on how this could be done by dissecting and / or reusing portions of their code? Or perhaps porting tcpcrypt to fbsd kernel may be a good candidate for a gsoc project? Marko ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Multiqueue support, igb
On 03/08/12 14:47, Ivan Voras wrote: Hello, What is the current state of support for multithreaded TCP processing in CURRENT? If a NIC supports multiple queues, will they be used automatically or net.isr.numthreads needs to be increased? I have this situation on a machine with an igb card: irq256: igb0:que 0103573 11 irq257: igb0:que 1 10094 1 irq258: igb0:que 2 18231 2 irq259: igb0:que 3 18186 2 This looks like the first queue is used ~~ 10x more often than the others. Is this a problem? I believe that the card do internally some sort of ether-channel. This may explain your findings. -- Best regards, Adrian Minta ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Multiqueue support, igb
08.03.2012 19:47, Ivan Voras пишет: > Hello, > > What is the current state of support for multithreaded TCP processing in > CURRENT? If a NIC supports multiple queues, will they be used > automatically or net.isr.numthreads needs to be increased? > > I have this situation on a machine with an igb card: > > irq256: igb0:que 0103573 11 > irq257: igb0:que 1 10094 1 > irq258: igb0:que 2 18231 2 > irq259: igb0:que 3 18186 2 > > This looks like the first queue is used ~~ 10x more often than the > others. Is this a problem? It seems you have lots of non-TCP and non-UDP traffic like PPPoE or GRE. igb(4) uses Microsoft Receive Side Scaling, so it cannot compute a hash for such ethernet frames and they all go to queue zero. That is unavoidable with those cards. Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/165863: [panic] [netinet] [patch] in_lltable_prefix_free() races with lla_lookup() and arptimer()
Old Synopsis: [panic] [patch] in_lltable_prefix_free() races with lla_lookup() and arptimer() New Synopsis: [panic] [netinet] [patch] in_lltable_prefix_free() races with lla_lookup() and arptimer() Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 8 23:05:11 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=165863 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Intel 82550 Pro/100 Ethernet and Microcode
Hi, recently I installed FreeBSD 8.2 Stable on some older machines with Intel 82550 and 82550C and found that the loading of microcode with the parameter link0 in the ifconfig command did not work anymore. The reason for this is the commit r223608 for if_fxp.c with the comment: Disable microcode loading for 82550 and 82550C controllers. Loading the microcode caused SCB timeouts. I do not agree with this motivation and try to explain why. Without loading the microcode on 82550(C) there is a problem with mount_nfs -U server:/bigdisk /mnt cp /mnt/bigfile bigfile NFS with UDP works with 8 KB blocks and the cp hangs after some seconds and you see SCB messages on the console. The reason is the TCO bug of the hardware mentioned in rcvbundl.h. This old hardware bug disappears after loading the microcode. All my hardware run without problems in FreeBSD 4.11, loading of microcode is done by the function fxp_load_ucode(). Later there was trouble with the loading of microcode, see kern/103332 and kern/118909. I have posted my solution for the problem to kern/103332 but unfortunately this PR is not online anymore and so I repeat my considerations here. The difference of the function fxp_load_ucode() of FreeBSD 4.11 and later versions is that this function in 4.11 has an own private memory buffer for construction of the microcode message. In later versions fxp_load_ucode() must use a memory buffer that is shared with other parts of the driver and these other parts of the driver have problems if the shared memory buffer was used by fxp_load_ucode() before. Thats the reason for "Loading microcode caused SCB timeouts". Therefore my proposal is to revert r223608 and to clean the used shared buffer at the end of the function fxp_load_ucode(). The following patch works for me for years now: --- if_fxp.c.orig 2012-01-26 12:43:09.0 +0100 +++ if_fxp.c2012-03-08 23:41:32.0 +0100 @@ -3085,6 +3081,7 @@ sc->tunable_int_delay, uc->bundle_max_offset == 0 ? 0 : sc->tunable_bundle_max); sc->flags |= FXP_FLAG_UCODE; + bzero(cbp, (uc->length + 2) * sizeof(uint32_t)); } -- Dr. Andreas Longwitz Data Service GmbH Beethovenstr. 2A 23617 Stockelsdorf Amtsgericht Lübeck, HRB 318 BS Geschäftsführer: Wilfried Paepcke, Dr. Andreas Longwitz, Josef Flatau ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
iSCSI Target For Freebsd
Hi All, Is there are an iSCSI Software Target that you can recommend. I have tried using istgt ( on Freebsd7.2) with Windows iSCSI Software Initiator. The initiator is able to discover the target however it is unable to login to the target. The login Response shows that the = <0203> indicating that "the requested ITN does not exist at this address" Thanks David S. This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/165863: [panic] [netinet] [patch] in_lltable_prefix_free() races with lla_lookup() and arptimer()
The following reply was made to PR kern/165863; it has been noted by GNATS. From: Eric van Gyzen To: bug-follo...@freebsd.org Cc: Subject: Re: kern/165863: [panic] [netinet] [patch] in_lltable_prefix_free() races with lla_lookup() and arptimer() Date: Thu, 08 Mar 2012 20:23:14 -0600 I just realized that the first two paragraphs in the How-To-Repeat section are interchanged. I apologize for the confusion. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
