Re: smp_rendezvous_action: Are atomics correctly used ?
Le vendredi 10 mars 2017, 16:46:26 Konstantin Belousov a écrit : > On Fri, Mar 10, 2017 at 03:30:21PM +0100, Alexandre Martins wrote: > > Le vendredi 10 mars 2017, 15:57:16 Konstantin Belousov a ?crit : > > > On Fri, Mar 10, 2017 at 02:24:52PM +0100, Alexandre Martins wrote: > > > > Le jeudi 9 mars 2017, 16:25:17 Konstantin Belousov a ?crit : > > > > > On Thu, Mar 09, 2017 at 02:52:09PM +0100, Alexandre Martins wrote: > > > > > > Le jeudi 9 mars 2017, 15:07:54 Konstantin Belousov a ?crit : > > > > > > > On Thu, Mar 09, 2017 at 10:59:27AM +0100, Alexandre Martins wrote: > > > > > > > > I have the save question for the cpu_ipi_pending here: > > > > > > > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/x86/x86/mp_x86.c?view > > > > > > > > =ann > > > > > > > > otat > > > > > > > > e#l1 > > > > > > > > 080> > > > > > > > > > > > > > > > > Le jeudi 9 mars 2017, 10:43:14 Alexandre Martins a ?crit : > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > I'm curently reading the code of the function > > > > > > > > > smp_rendezvous_action, > > > > > > > > > in > > > > > > > > > kern/subr_smp.c file. In that function, i see that the > > > > > > > > > variable > > > > > > > > > smp_rv_waiters is read in some while() loop in a non-atomic > > > > > > > > > way. > > > > > > > > > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?vie > > > > > > > > > w=an > > > > > > > > > nota > > > > > > > > > te#l > > > > > > > > > 412 > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?vie > > > > > > > > > w=an > > > > > > > > > nota > > > > > > > > > te#l > > > > > > > > > 458 > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?vie > > > > > > > > > w=an > > > > > > > > > nota > > > > > > > > > te#l > > > > > > > > > 472 > > > > > > > > > > > > > > > > > > I suspect one of my freeze to be due by that. > > > > > > > > > > > > > > You should provide either evidence or, at least, some reasoning > > > > > > > supporting > > > > > > > your claims. > > > > > > > > > > > > I curently have a software watchdog that triger and does a > > > > > > coredump. > > > > > > In > > > > > > the > > > > > > coredumps, I always see a CPU trying to write-lock a "rm lock". > > > > > > Every > > > > > > time, > > > > > > that CPU is spinning into the smp_rendezvous_action, in the first > > > > > > while > > > > > > loop) while the others are into the idle threads. > > > > > > > > > > > > The fact is that freeze is not clear and I start to search > > > > > > "exotic" > > > > > > causes > > > > > > to explain it. > > > > > > > > > > This sounds as the 'usual' deadlock, where some other thread owns > > > > > rmlock > > > > > in > > > > > read mode. I recommend you to follow the > > > > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handboo > > > > > k/ke > > > > > rnel debug-deadlocks.html > > > > > > > > Just a last question, for my personnal knowledge. > > > > > > > > In ARM >= 6, for atomic acces, the code should (?) use LDREX and STREX > > > > for, I quote : "Use LDREX and STREX to implement interprocess > > > > communication in multiple-processor and shared-memory systems." (see > > > > here > > > > > > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489e/C > >
Re: smp_rendezvous_action: Are atomics correctly used ?
Le vendredi 10 mars 2017, 15:57:16 Konstantin Belousov a écrit : > On Fri, Mar 10, 2017 at 02:24:52PM +0100, Alexandre Martins wrote: > > Le jeudi 9 mars 2017, 16:25:17 Konstantin Belousov a ?crit : > > > On Thu, Mar 09, 2017 at 02:52:09PM +0100, Alexandre Martins wrote: > > > > Le jeudi 9 mars 2017, 15:07:54 Konstantin Belousov a ?crit : > > > > > On Thu, Mar 09, 2017 at 10:59:27AM +0100, Alexandre Martins wrote: > > > > > > I have the save question for the cpu_ipi_pending here: > > > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/x86/x86/mp_x86.c?view=ann > > > > > > otat > > > > > > e#l1 > > > > > > 080> > > > > > > > > > > > > Le jeudi 9 mars 2017, 10:43:14 Alexandre Martins a ?crit : > > > > > > > Hello, > > > > > > > > > > > > > > I'm curently reading the code of the function > > > > > > > smp_rendezvous_action, > > > > > > > in > > > > > > > kern/subr_smp.c file. In that function, i see that the variable > > > > > > > smp_rv_waiters is read in some while() loop in a non-atomic way. > > > > > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=an > > > > > > > nota > > > > > > > te#l > > > > > > > 412 > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=an > > > > > > > nota > > > > > > > te#l > > > > > > > 458 > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=an > > > > > > > nota > > > > > > > te#l > > > > > > > 472 > > > > > > > > > > > > > > I suspect one of my freeze to be due by that. > > > > > > > > > > You should provide either evidence or, at least, some reasoning > > > > > supporting > > > > > your claims. > > > > > > > > I curently have a software watchdog that triger and does a coredump. > > > > In > > > > the > > > > coredumps, I always see a CPU trying to write-lock a "rm lock". Every > > > > time, > > > > that CPU is spinning into the smp_rendezvous_action, in the first > > > > while > > > > loop) while the others are into the idle threads. > > > > > > > > The fact is that freeze is not clear and I start to search "exotic" > > > > causes > > > > to explain it. > > > > > > This sounds as the 'usual' deadlock, where some other thread owns rmlock > > > in > > > read mode. I recommend you to follow the > > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ke > > > rnel debug-deadlocks.html > > > > Just a last question, for my personnal knowledge. > > > > In ARM >= 6, for atomic acces, the code should (?) use LDREX and STREX > > for, I quote : "Use LDREX and STREX to implement interprocess > > communication in multiple-processor and shared-memory systems." (see here > > : > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489e/Cihbg > > hef.html > In my previous response to you, I explicitely defined what 'atomic' > means when adjected to the term 'load'. The *EX instructions are used on > ll/sc architectures to implement read/modify/write atomic operations, > which are different from load (read) operations. Ok ! Because we just want to read the value, there is no need to use the *EX version. *EX is intended to be use when a modification will be done thereafter. > > > But, in that while loop, it's a standard "LDR" that is used. Is it correct > > too, and why ? > > Which 'that while loop' ? > while (atomic_load_acq_int(&smp_rv_waiters[3]) < ncpus) > cpu_spinwait(); > This one ? No, I point the one at line 412, 458 and 472: 412: while (smp_rv_waiters[0] < smp_rv_ncpus) cpu_spinwait(); 458: while (smp_rv_waiters[1] < smp_rv_ncpus) cpu_spinwait(); 472: while (smp_rv_waiters[2] < smp_rv_ncpus) cpu_spinwait(); > > Because the semantic of the normal load + DMB barrier provides the expected > semantic of atomic_load_acq(), as explained in atomic(9) and utilized by > the author of the code. So, the writer must use LDREX/STREX to modify the value and use dmb to make visible to other CPU the write. The readers can read simply the value without the barrier because cache coherancy protcol will update the value automaticaly. I think I finally got it ! Thank you so much ! Best regards, -- Alexandre Martins STORMSHIELD smime.p7s Description: S/MIME cryptographic signature
Re: smp_rendezvous_action: Are atomics correctly used ?
Le jeudi 9 mars 2017, 16:25:17 Konstantin Belousov a écrit : > On Thu, Mar 09, 2017 at 02:52:09PM +0100, Alexandre Martins wrote: > > Le jeudi 9 mars 2017, 15:07:54 Konstantin Belousov a ?crit : > > > On Thu, Mar 09, 2017 at 10:59:27AM +0100, Alexandre Martins wrote: > > > > I have the save question for the cpu_ipi_pending here: > > > > > > > > https://svnweb.freebsd.org/base/head/sys/x86/x86/mp_x86.c?view=annotat > > > > e#l1 > > > > 080> > > > > > > > > Le jeudi 9 mars 2017, 10:43:14 Alexandre Martins a ?crit : > > > > > Hello, > > > > > > > > > > I'm curently reading the code of the function smp_rendezvous_action, > > > > > in > > > > > kern/subr_smp.c file. In that function, i see that the variable > > > > > smp_rv_waiters is read in some while() loop in a non-atomic way. > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annota > > > > > te#l > > > > > 412 > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annota > > > > > te#l > > > > > 458 > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annota > > > > > te#l > > > > > 472 > > > > > > > > > > I suspect one of my freeze to be due by that. > > > > > > You should provide either evidence or, at least, some reasoning > > > supporting > > > your claims. > > > > I curently have a software watchdog that triger and does a coredump. In > > the > > coredumps, I always see a CPU trying to write-lock a "rm lock". Every > > time, > > that CPU is spinning into the smp_rendezvous_action, in the first while > > loop) while the others are into the idle threads. > > > > The fact is that freeze is not clear and I start to search "exotic" causes > > to explain it. > > This sounds as the 'usual' deadlock, where some other thread owns rmlock in > read mode. I recommend you to follow the > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kernel > debug-deadlocks.html Just a last question, for my personnal knowledge. In ARM >= 6, for atomic acces, the code should (?) use LDREX and STREX for, I quote : "Use LDREX and STREX to implement interprocess communication in multiple-processor and shared-memory systems." (see here : http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489e/Cihbghef.html But, in that while loop, it's a standard "LDR" that is used. Is it correct too, and why ? -- Alexandre Martins STORMSHIELD smime.p7s Description: S/MIME cryptographic signature
Re: smp_rendezvous_action: Are atomics correctly used ?
Le jeudi 9 mars 2017, 16:25:17 Konstantin Belousov a écrit : > On Thu, Mar 09, 2017 at 02:52:09PM +0100, Alexandre Martins wrote: > > Le jeudi 9 mars 2017, 15:07:54 Konstantin Belousov a ?crit : > > > On Thu, Mar 09, 2017 at 10:59:27AM +0100, Alexandre Martins wrote: > > > > I have the save question for the cpu_ipi_pending here: > > > > > > > > https://svnweb.freebsd.org/base/head/sys/x86/x86/mp_x86.c?view=annotat > > > > e#l1 > > > > 080> > > > > > > > > Le jeudi 9 mars 2017, 10:43:14 Alexandre Martins a ?crit : > > > > > Hello, > > > > > > > > > > I'm curently reading the code of the function smp_rendezvous_action, > > > > > in > > > > > kern/subr_smp.c file. In that function, i see that the variable > > > > > smp_rv_waiters is read in some while() loop in a non-atomic way. > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annota > > > > > te#l > > > > > 412 > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annota > > > > > te#l > > > > > 458 > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annota > > > > > te#l > > > > > 472 > > > > > > > > > > I suspect one of my freeze to be due by that. > > > > > > You should provide either evidence or, at least, some reasoning > > > supporting > > > your claims. > > > > I curently have a software watchdog that triger and does a coredump. In > > the > > coredumps, I always see a CPU trying to write-lock a "rm lock". Every > > time, > > that CPU is spinning into the smp_rendezvous_action, in the first while > > loop) while the others are into the idle threads. > > > > The fact is that freeze is not clear and I start to search "exotic" causes > > to explain it. > > This sounds as the 'usual' deadlock, where some other thread owns rmlock in > read mode. I recommend you to follow the > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kernel > debug-deadlocks.html As habit, with theses options, in our test environment, it never happen. But at customers, in production, ... :-D The only thing I have it's the coredump. In it, the rm_lock seems free of readers/writers. There is nothing in the pcpu->pc_rm_queue (of all CPU) and nothing in the rm->rm_activeReaders. Thank you. It' s realy nice to try to help me ! -- Alexandre Martins STORMSHIELD smime.p7s Description: S/MIME cryptographic signature
Re: smp_rendezvous_action: Are atomics correctly used ?
Le jeudi 9 mars 2017, 15:07:54 Konstantin Belousov a écrit : > On Thu, Mar 09, 2017 at 10:59:27AM +0100, Alexandre Martins wrote: > > I have the save question for the cpu_ipi_pending here: > > > > https://svnweb.freebsd.org/base/head/sys/x86/x86/mp_x86.c?view=annotate#l1 > > 080> > > Le jeudi 9 mars 2017, 10:43:14 Alexandre Martins a ?crit : > > > Hello, > > > > > > I'm curently reading the code of the function smp_rendezvous_action, in > > > kern/subr_smp.c file. In that function, i see that the variable > > > smp_rv_waiters is read in some while() loop in a non-atomic way. > > > > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annotate#l > > > 412 > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annotate#l > > > 458 > > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annotate#l > > > 472 > > > > > > I suspect one of my freeze to be due by that. > > You should provide either evidence or, at least, some reasoning supporting > your claims. I curently have a software watchdog that triger and does a coredump. In the coredumps, I always see a CPU trying to write-lock a "rm lock". Every time, that CPU is spinning into the smp_rendezvous_action, in the first while loop) while the others are into the idle threads. The fact is that freeze is not clear and I start to search "exotic" causes to explain it. > > > > Should this function be patched to use > > > "atomic_load_acq_int(&smp_rv_waiters[])" ? > > There too. > > As a side note, any read or write of the naturally aligned integer > types with size less or equal than the machine word, on all supported > architectures, are atomic. The meaning of the word atomic there is > that when reading, you always get a complete value that was written by > a writer into this location, not some out of thin air value. Similarly, > when writing, you are guaranteed that any observer of the write will see > the value you have wrote. > > The guarantees above hold both for C-level code and for the assembler > accesses. > > atomic_load_acq() provides additional guarantees which do not affect the > value read from the variable itself, but establish the ordering on the > visibility of the related operations. OK, I got it. Thank you ! -- Alexandre Martins STORMSHIELD smime.p7s Description: S/MIME cryptographic signature
Re: smp_rendezvous_action: Are atomics correctly used ?
I have the save question for the cpu_ipi_pending here: https://svnweb.freebsd.org/base/head/sys/x86/x86/mp_x86.c?view=annotate#l1080 Le jeudi 9 mars 2017, 10:43:14 Alexandre Martins a écrit : > Hello, > > I'm curently reading the code of the function smp_rendezvous_action, in > kern/subr_smp.c file. In that function, i see that the variable > smp_rv_waiters is read in some while() loop in a non-atomic way. > > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annotate#l412 > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annotate#l458 > https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annotate#l472 > > I suspect one of my freeze to be due by that. > > Should this function be patched to use > "atomic_load_acq_int(&smp_rv_waiters[])" ? > > Best regards -- Alexandre Martins STORMSHIELD smime.p7s Description: S/MIME cryptographic signature
smp_rendezvous_action: Are atomics correctly used ?
Hello, I'm curently reading the code of the function smp_rendezvous_action, in kern/subr_smp.c file. In that function, i see that the variable smp_rv_waiters is read in some while() loop in a non-atomic way. https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annotate#l412 https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annotate#l458 https://svnweb.freebsd.org/base/head/sys/kern/subr_smp.c?view=annotate#l472 I suspect one of my freeze to be due by that. Should this function be patched to use "atomic_load_acq_int(&smp_rv_waiters[])" ? Best regards -- Alexandre Martins STORMSHIELD smime.p7s Description: S/MIME cryptographic signature
Re: Mbuf leak in if_lagg.c
Le jeudi 26 mars 2015, 23:10:49 Andrey V. Elsukov a écrit : > On 26.03.2015 22:42, Andrey V. Elsukov wrote: > >> If lp_detaching is non 0, the mbuf pointer is set to NULL without m_freem > >> it. > >> > >> Can you look at this ? > > > > Hi, > > > > what you thing about this patch? > > lp_detaching can be non zero in case of parent interface departure. > > So I don't see the reason to call ETHER_BPF_MTAP() in this case. > > Now I see the reason - to capture all received packets before interface > departure. New is attached. Sounds good for me :) -- Alexandre Martins STORMSHIELD smime.p7s Description: S/MIME cryptographic signature
Mbuf leak in if_lagg.c
Hi ! I found a leak of mbuf in the lagg driver : https://svnweb.freebsd.org/base/head/sys/net/if_lagg.c?view=annotate#l1672 -=-=-=-=-=-=-=-=-=-=- m = (lp->lp_detaching == 0) ? lagg_proto_input(sc, lp, m) : NULL; -=-=-=-=-=-=-=-=-=-=- If lp_detaching is non 0, the mbuf pointer is set to NULL without m_freem it. Can you look at this ? Regards -- Alexandre Martins STORMSHIELD smime.p7s Description: S/MIME cryptographic signature
Possible race in IPv6
Dear,
I'm facing some crash around manipulations of IPv6 address.
I already found that the commit 275593 will fix my issue.
However, after some code review, i see a possible race in the function
nd6_na_input:
https://svnweb.freebsd.org/base/head/sys/netinet6/nd6_nbr.c?annotate=279676#l750
=-=-=-=-=-=-=-=-=-=
if (ifa
&& (((struct in6_ifaddr *)ifa)->ia6_flags & IN6_IFF_TENTATIVE)) {
ifa_free(ifa);
nd6_dad_na_input(ifa);
goto freeit;
}
=-=-=-=-=-=-=-=-=-=
As you can see, the function drop its reference on the address and pass it to
nd6_dad_na_input.
It should be better to release the reference after the call.
What about you?
Regards
--
Alexandre Martins
STORMSHIELD
smime.p7s
Description: S/MIME cryptographic signature
Re: Status on igb crash
Hi Eric, Thank you for the reply. Regards, -- Alexandre Martins NETASQ -- We secure IT Le mercredi 26 février 2014 10:50:48 Eric Joyner a écrit : > Hi Alexandre, > > We didn't put the fix into the repository because we think it would have > had a significant impact on throughput. It fixed a crash, but that gotcha > could potentially annoy everyone else using the driver who wasn't > experiencing the same type of crash. That said, I'm going to look into that > performance impact, and will try to submit a patch later without one. > > --- > - Eric Joyner > > > On Wed, Feb 26, 2014 at 3:06 AM, Alexandre Martins < > > alexandre.mart...@netasq.com> wrote: > > Hi Eric, > > > > In January, I have report a bug into igb driver : > > > > http://lists.freebsd.org/pipermail/freebsd-current/2014-January/047827.htm > > l > > > > You send me a patch, but nothing was done into kernel sources. > > > > Will it be planed to put a fix into the repository ? > > > > Kind regards > > > > -- > > Alexandre Martins > > NETASQ -- We secure IT smime.p7s Description: S/MIME cryptographic signature
Status on igb crash
Hi Eric, In January, I have report a bug into igb driver : http://lists.freebsd.org/pipermail/freebsd-current/2014-January/047827.html You send me a patch, but nothing was done into kernel sources. Will it be planed to put a fix into the repository ? Kind regards -- Alexandre Martins NETASQ -- We secure IT smime.p7s Description: S/MIME cryptographic signature
Re: FreeBSD 10-RC4: Got crash in igb driver
I have some compillation issues : ../../../dev/e1000/if_igb.c: In function 'igb_mq_start_locked': ../../../dev/e1000/if_igb.c:3936: warning: 'poff' may be used uninitialized in this function ../../../dev/e1000/if_igb.c:3936: note: 'poff' was declared here ../../../dev/e1000/if_igb.c:3936: warning: 'ip_hlen' may be used uninitialized in this function ../../../dev/e1000/if_igb.c:3936: note: 'ip_hlen' was declared here But this fix the crash. However, I have now a copy made of all ipv6 forwarded packet in igb_pullup_headers. It will be nice to m_free the copy of the packet made in ip6_forward before calling nd6_output function. It will put back the packet writable and avoid (in most cases) the copy. I have no time this week to check performance of this new driver version. I'll try to make that Monday. Thank you for this fix Le mardi 14 janvier 2014 14:22:43 Eric Joyner a écrit : > All, > > I work with Jack on FreeBSD network drivers, and we have a patch that we > think might fix this problem. It re-implements the header pull-up code that > was in the driver pre-2.4.0, but with IPv6 support. Alexandre, could you > apply this patch to the igb version in HEAD and try it out on your network? > We can't replicate your setup here. > > If it solves your problem, then the next step would be to port the patch to > the ixgbe driver since, as Yonghyeon noted, it looks like that driver will > encounter the same problem. We could then modify em to add IPv6 offload > support as well. > > Thanks, > > --- > - Eric Joyner > > On Fri, Jan 10, 2014 at 02:35:29PM +0400, Gleb Smirnoff wrote: > > Yonghyeon, > > > > On Fri, Jan 10, 2014 at 10:21:14AM +0900, Yonghyeon PYUN wrote: > > Y> > I experience some troubles with the igb device driver on FreeBSD > > 10-RC4. > > > Y> > > > Y> > The kernel make a pagefault in the igb_tx_ctx_setup function when > > accessing to > > > Y> > a IPv6 header. > > Y> > > > Y> > The network configuration is the following: > > Y> > - box acting as an IPv6 router > > Y> > - one interface with an IPv6 (igb0) > > Y> > - another interface with a vlan, and IPv6 on it (vlan0 on igb1) > > Y> > > > Y> > Vlan Hardware tagging is set on both interfaces. > > Y> > > > Y> > The packet that cause the crash come from igb0 and go to vlan0. > > Y> > > > Y> > After investigation, i see that the mbuf is split in two. The first > > one carry > > > Y> > the ethernet header, the second, the IPv6 header and data payload. > > Y> > > > Y> > The split is due to the "m_copy" done in ip6_forward, that make the > > mbuf not > > > Y> > writable and the "M_PREPEND" in ether_output that insert the new > > mbuf before > > > Y> > the original one. > > Y> > > > Y> > The kernel crashes only if the newly allocated mbuf is at the end of > > a memory > > > Y> > page, and no page is available after this one. So, it's extremly > > rare. > > > Y> > > > Y> > I inserted a "KASSERT" into the function (see attached patch) to > > check this > > > Y> > behavior, and it raises on every IPv6 forwarded packet to the vlan. > > The > > > Y> > problem disapear if i remove hardware tagging. > > Y> > > > Y> > In the commit 256200, i see that pullups has been removed. May it be > > related ? > > > Y> > > Y> I think I introduced the header parsing code to meet controller > > Y> requirement in em(4) and Jack borrowed that code in the past but it > > Y> seems it was removed in r256200. It seems igb_tx_ctx_setup() > > Y> assumes it can access ethernet/IP/TCP/UDP headers in the first mbuf > > Y> of the chain. > > Y> This looks wrong to me. > > > > Can you please restore the important code in head ASAP? Although crashes > > happen > > > only when the mbuf is last in a page and page isn't mapped, we read > > thrash from > > > next allocation on almost every packet. > > It seems other Intel ethernet drivers except em(4) have similar > issues. I didn't check recent Intel controllers/drivers for long > time so I don't know details on hardware requirements of > offloading. > Since Jack is very responsive and has hardwares to verify, he would > be more appropriate person to handle these issues. > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- Alexandre Martins NETASQ -- We secure IT smime.p7s Description: S/MIME cryptographic signature
FreeBSD 10-RC4: Got crash in igb driver
Dear,
I experience some troubles with the igb device driver on FreeBSD 10-RC4.
The kernel make a pagefault in the igb_tx_ctx_setup function when accessing to
a IPv6 header.
The network configuration is the following:
- box acting as an IPv6 router
- one interface with an IPv6 (igb0)
- another interface with a vlan, and IPv6 on it (vlan0 on igb1)
Vlan Hardware tagging is set on both interfaces.
The packet that cause the crash come from igb0 and go to vlan0.
After investigation, i see that the mbuf is split in two. The first one carry
the ethernet header, the second, the IPv6 header and data payload.
The split is due to the "m_copy" done in ip6_forward, that make the mbuf not
writable and the "M_PREPEND" in ether_output that insert the new mbuf before
the original one.
The kernel crashes only if the newly allocated mbuf is at the end of a memory
page, and no page is available after this one. So, it's extremly rare.
I inserted a "KASSERT" into the function (see attached patch) to check this
behavior, and it raises on every IPv6 forwarded packet to the vlan. The
problem disapear if i remove hardware tagging.
In the commit 256200, i see that pullups has been removed. May it be related ?
Can you confirm the problem ?
Best regards
--
Alexandre Martins
NETASQ -- We secure IT
--- sys/dev/e1000/if_igb.c.orig 2014-01-09 16:33:39.0 +0100
+++ sys/dev/e1000/if_igb.c 2014-01-09 16:36:31.0 +0100
@@ -3883,6 +3883,7 @@
type_tucmd_mlhl |= E1000_ADVTXD_TUCMD_IPV4;
break;
case ETHERTYPE_IPV6:
+ KASSERT(ehdrlen + sizeof(struct ip6_hdr) <= mp->m_len, ("Ethernet and IPv6 header not contiguous"));
ip6 = (struct ip6_hdr *)(mp->m_data + ehdrlen);
ip_hlen = sizeof(struct ip6_hdr);
/* XXX-BZ this will go badly in case of ext hdrs. */
smime.p7s
Description: S/MIME cryptographic signature
Re: Troubles with VIA VX900 chipset
I forget to attach patches
Le jeudi 24 octobre 2013 15:56:15 Alexandre Martins a écrit :
> Dear,
>
> We have seen some issues with the VIA VX900 chipset. The main trouble is
> that some SATA hard drive are not seen by the kernel (BIOS and boot-loader
> are OK).
>
> After investigations, it seems that during the initialisation of the
> controler, some reset commands are send via "ata_via_sata_reset" fonction.
> Into the chipset documentation, there is a warning about successive reset
> commands, and software must waiting the "BUSY" flag is clear, before send
> another reset. I have added a "DELAY(1)" between the second call of
> "ata_sata_phy_reset" and the call of "ata_generic_reset" and the problem
> disapear.
>
> I also made a more complex fix which check the "BUSY" flag.
>
> Which fix of delai checking is the better one ?
>
> Best Regards
--
Alexandre Martins
NETASQ -- We secure IT
--- dev/ata/chipsets/ata-via.c.orig 2013-10-24 09:32:45.0 +
+++ dev/ata/chipsets/ata-via.c 2013-10-24 09:39:51.0 +
@@ -459,6 +459,7 @@
devs = ata_sata_phy_reset(dev, 0, 0);
DELAY(1);
devs += ata_sata_phy_reset(dev, 1, 0);
+ DELAY(1);
} else
devs = 1;
if (devs)
--- dev/ata/chipsets/ata-via.c.orig 2013-10-24 13:39:17.0 +
+++ dev/ata/chipsets/ata-via.c 2013-10-24 09:24:04.0 +
@@ -456,11 +456,29 @@
{
struct ata_channel *ch = device_get_softc(dev);
int devs;
+ u_int8_t status;
+ int count;
if (ch->unit == 0) {
devs = ata_sata_phy_reset(dev, 0, 0);
- DELAY(1);
+ count = 0;
+ do
+ {
+ ATA_IDX_OUTB(ch, ATA_DRIVE, ATA_D_IBM | ATA_D_LBA | ATA_DEV(ATA_MASTER));
+ DELAY(1000);
+ status = ATA_IDX_INB(ch, ATA_STATUS);
+ count++;
+ } while (status & ATA_S_BUSY && count < 100);
+
devs += ata_sata_phy_reset(dev, 1, 0);
+ count = 0;
+ do
+ {
+ ATA_IDX_OUTB(ch, ATA_DRIVE, ATA_D_IBM | ATA_D_LBA | ATA_DEV(ATA_SLAVE));
+ DELAY(1000);
+ status = ATA_IDX_INB(ch, ATA_STATUS);
+ count++;
+ } while (status & ATA_S_BUSY && count < 100);
} else
devs = 1;
if (devs)
smime.p7s
Description: S/MIME cryptographic signature
Troubles with VIA VX900 chipset
Dear, We have seen some issues with the VIA VX900 chipset. The main trouble is that some SATA hard drive are not seen by the kernel (BIOS and boot-loader are OK). After investigations, it seems that during the initialisation of the controler, some reset commands are send via "ata_via_sata_reset" fonction. Into the chipset documentation, there is a warning about successive reset commands, and software must waiting the "BUSY" flag is clear, before send another reset. I have added a "DELAY(1)" between the second call of "ata_sata_phy_reset" and the call of "ata_generic_reset" and the problem disapear. I also made a more complex fix which check the "BUSY" flag. Which fix of delai checking is the better one ? Best Regards -- Alexandre Martins NETASQ -- We secure IT smime.p7s Description: S/MIME cryptographic signature
Some question about IPv4 routes
Dears, Since FreeBSD 8.0, there is some changes about routing table, in particular the IPv4 'link-local' route. In my case, i have this config: em0 192.168.0.1 / 24 In FreeBSD < 8, if I run 'route get 192.168.0.0', it tell me : =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- route to: 192.168.0.0 destination: 192.168.0.0 mask: 255.255.255.0 interface: em0 flags: recvpipe sendpipe ssthresh rtt,msecrttvar hopcount mtu expire 0 0 0 0 0 0 1500 -537398 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- And in FreeBSD >= 8 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- route: writing to routing socket: No such process =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- In addition, if I run a ping on network and broadcast address (ping 192.168.0.0; ping 192.168.0.255) In Freebsd < 8, a new route was created and i can see it in 'netstat -rn -af inet' =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Internet: DestinationGatewayFlagsRefs Use Netif Expire 192.168.0.0 ff:ff:ff:ff:ff:ff UHLWb 11 em0 => 192.168.0.255 ff:ff:ff:ff:ff:ff UHLWb 11 em0 => =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- But not in FreeBSD >= 8 So, why is the broadcast route not created in FreeBSD >= 8 ? And why is the command 'route get 192.168.0.0' fail in FreeBSD >= 8 ? Regards -- Alexandre Martins NETASQ -- We secure IT
Re: Potential deadlock on mbuf
On Tue, 3 Apr 2012, Andre Oppermann wrote: >> On 02.04.2012 18:21, Alexandre Martins wrote: >>> Dear, >>> >>> I have currently having troubles with a basic socket stress. >>> >>> The socket are setup to use non-blocking I/O. >>> >>> During this stress-test, the kernel is running mbuf exhaustion, the goal is >>> to >>> see system limits. >>> >>> If the program make a write on a socket during this mbuf exhaustion, it >>> become >>> blocked in "write" system call. The status of the process is "zonelimit" >>> and >>> whole network I/O fall in timeout. >>> >>> I have found the root cause of the block : >>> http://svnweb.freebsd.org/base/head/sys/kern/uipc_socket.c?view=markup#l1279 >>> >>> So, the question is : Why m_uiotombuf is called with a blocking parameter >>> (M_WAITOK) even if is for a non-blocking socket ? >>> >>> Then, if M_NOWAIT is used, maybe it will be usefull to have an 'ENOMEM' >>> error. > > I'm surprised you can even see blocking of malloc(... M_WAITOK). > O_NONBLOCK is mostly for operations that might block for a long time, > but malloc() is not expected to block for long. Regular files are > always so non-blocking that most file systems have no references to > O_NONBLOCK (or FNONBLOCK), but file systems often execute memory > allocation code that can easily block for as long as malloc() does. > When malloc() starts blocking for a long time, lots of things will > fail. The fact is that all mbuf are used by connected sockets, waiting for program reading. But the program try to make a write for data transfert. So, the mbuf allocation block in waiting of available mbuf, but the only proccess wich can "free" mbuf is blocked. The mbuff allocation is deadlocked and host become unreachable. >> This is a bit of an catch-22 we have here. Trouble is that when >> we return with EAGAIN the next select/poll cycle will tell you >> that this and possibly other sockets are writeable again, when in >> fact they are not due to kernel memory shortage. Then the application >> will tightly loop around the "writeable" non-writeable sockets. >> It's about the interaction of write with O_NONBLOCK and select/poll >> on the socket. > > This would be difficult to handle better. I play with the flag. I switched it to M_NOWAIT en return a EAGAIN error if allocation failed. The program fail some write, but try again later and the host continue to be reachable. I agree that solution is not correct. >> Do you have any references how other OSes behave, in particular >> Linux? >> >> I've added bde@ as our resident standards compliance expert. >> Hopefully he can give us some more insight on this issue. > > Standards won't say what happens at this level of detail. > > Blocking for network i/o is still completely broken at levels below > sockets AFAIK. I (and ttcp) mainly wanted it to work for send() of > udp. I saw no problems at the socket level, but driver queues just > filled up and send() returned ENOBUFS. I wanted either the opposite > of O_NONBLOCK (block until !ENOBUFS), or at least for select() to work > for waiting until !ENOBUFS. But select() doesn't work at all for this. > It seemed to work better in Linux. > > Bruce Alexandre Martins ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Potential deadlock on mbuf
Dear, I have currently having troubles with a basic socket stress. The socket are setup to use non-blocking I/O. During this stress-test, the kernel is running mbuf exhaustion, the goal is to see system limits. If the program make a write on a socket during this mbuf exhaustion, it become blocked in "write" system call. The status of the process is "zonelimit" and whole network I/O fall in timeout. I have found the root cause of the block : http://svnweb.freebsd.org/base/head/sys/kern/uipc_socket.c?view=markup#l1279 So, the question is : Why m_uiotombuf is called with a blocking parameter (M_WAITOK) even if is for a non-blocking socket ? Then, if M_NOWAIT is used, maybe it will be usefull to have an 'ENOMEM' error. Regards -- Alexandre Martins ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Double free() in libc or gdb ?
On Tuesday 13 March 2012 20:44:43 you wrote: > On 2012-03-13 11:08, Alexandre Martins wrote: > > On Monday 12 March 2012 18:55:55 Konstantin Belousov wrote: > >> On Mon, Mar 12, 2012 at 05:50:33PM +0100, Alexandre Martins wrote: > ... > > >>> I have the libc compilled with "MALLOC_DEBUG" flag to detect double > >>> free. When i run this piece of code (attached file) thought GDB, i > >>> have this assertion : > >>> > >>> Assertion failed: ((run->regs_mask[elm] & (1U << bit)) == 0), function > >>> arena_run_reg_dalloc, file /usr/src/lib/libc/stdlib/malloc.c, line > >>> 2543. > > I have committed a fix for this assertion (actually a double free) in > r232934. Can you please update to that revision, rebuild your gdb, and > try again? Dear, The problem have disapear with an update to gdb 7.3. Thank you for your help ! Regards -- Alexandre Martins NETASQ -- We secure IT
Re: Double free() in libc or gdb ?
Dear, On Tuesday 13 March 2012 15:18:31 jb wrote: > Alexandre Martins netasq.com> writes: > > ... > > first.c: > > ... > > second.c > > ... > > main.c > > ... > > > > while(42) > > How do you exit that loop ? It's just a sample. There is no exit here, you have to kill the process. > > > ... > > Compilation and execution : > > > > gcc -shared -O0 -g second.c -o second.so > > gcc -shared -O0 -g first.c -o libfirst.so > > gcc -O0 -g toto.c -lfirst -L. -o test > > export LD_LIBRARY_PATH=$PWD > > gdb ./test > > ... > > What is your toto.c (source code) ? > What about your main.c in compilation ? Yes, you're right. "toto.c" is the "main.c" file. > > jb > > > > > > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" To Konstantin Belousov : The GDB v7.3 solved the assert. but is still memleak. Regards -- Alexandre Martins NETASQ -- We secure IT
Re: Double free() in libc or gdb ?
On Tuesday 13 March 2012 13:17:52 Konstantin Belousov wrote:
> On Tue, Mar 13, 2012 at 11:08:40AM +0100, Alexandre Martins wrote:
> > On Monday 12 March 2012 18:55:55 Konstantin Belousov wrote:
> > > On Mon, Mar 12, 2012 at 05:50:33PM +0100, Alexandre Martins wrote:
> > > > Dear all,
> > > >
> > > > I'm currently having some trouble with the dynamic loader.
> > > >
> > > > I have the libc compilled with "MALLOC_DEBUG" flag to detect double
> > > > free. When i run this piece of code (attached file) thought GDB, i
> > > > have this assertion :
> > > >
> > > > Assertion failed: ((run->regs_mask[elm] & (1U << bit)) == 0),
> > > > function arena_run_reg_dalloc, file
> > > > /usr/src/lib/libc/stdlib/malloc.c, line 2543.
> > > >
> > > > But when i run the same binary without GDB, no assert.
> > > >
> > > > I'm very confused. Can you help me to debug that ?
> > >
> > > There is no attachment. Put the source somewhere on web.
> >
> > Sorry, I'll past code here :
> >
> > first.c:
> >
> > #include
> >
> > void print_name(void)
> > {
> >
> > printf("I'm " __FILE__ " at line %d\n", __LINE__);
> >
> > }
> >
> >
> > second.c
> >
> > #include
> >
> > void second_name(void)
> > {
> >
> > printf("I'm " __FILE__ " at line %d\n", __LINE__);
> >
> > }
> >
> > void print_name(void)
> > {
> >
> > printf("I'm " __FILE__ " at line %d\n", __LINE__);
> >
> > }
> >
> >
> > main.c
> >
> > #include
> > #include
> >
> > extern void print_name(void);
> >
> > int main(int argc, char *argv[])
> > {
> >
> > void (*second_name)(void);
> > void *handle;
> > int count = 0;
> >
> > while(42)
> > {
> >
> > print_name();
> > handle = dlopen("second.so", RTLD_NOW);
> > print_name();
> > if (handle != NULL)
> > {
> >
> > second_name = dlsym(handle, "second_name");
> > if (second_name != NULL)
> > {
> >
> > printf("second : ");
> > second_name();
> >
> > }
> > dlclose(handle);
> >
> > }
> > else
> >
> > fprintf(stderr, "Error : %s\n", dlerror());
> >
> > }
> >
> > }
> >
> >
> > Compilation and execution :
> >
> > gcc -shared -O0 -g second.c -o second.so
> > gcc -shared -O0 -g first.c -o libfirst.so
> > gcc -O0 -g toto.c -lfirst -L. -o test
> > export LD_LIBRARY_PATH=$PWD
> > gdb ./test
>
> First, the libc malloc is not used inside rtld, so assertion which you
> see points to somebody else. This somebody could be the stdio in your
> example, or it could be gdb.
>
> On the HEAD r232862, I indeed get the assertion, that obviously comes
> from gdb. So this is a bug in gdb. Probably, try devel/gdb from ports,
> I hardly can help you with gdb bug.
Dear,
Thank for your response.
Two other thing
- The process consume memory, but there is no allocation in my code. Maybe a
leak in the libc ?
- My kernel have crashed after some minute of leak (i have removed printf for
better perf on the loop). Maybe unrelated, but ...
Regards,
--
Alexandre Martins
NETASQ -- We secure IT
Re: Double free() in libc or gdb ?
On Monday 12 March 2012 18:55:55 Konstantin Belousov wrote:
> On Mon, Mar 12, 2012 at 05:50:33PM +0100, Alexandre Martins wrote:
> > Dear all,
> >
> > I'm currently having some trouble with the dynamic loader.
> >
> > I have the libc compilled with "MALLOC_DEBUG" flag to detect double free.
> > When i run this piece of code (attached file) thought GDB, i have this
> > assertion :
> >
> > Assertion failed: ((run->regs_mask[elm] & (1U << bit)) == 0), function
> > arena_run_reg_dalloc, file /usr/src/lib/libc/stdlib/malloc.c, line 2543.
> >
> > But when i run the same binary without GDB, no assert.
> >
> > I'm very confused. Can you help me to debug that ?
>
> There is no attachment. Put the source somewhere on web.
Sorry, I'll past code here :
first.c:
#include
void print_name(void)
{
printf("I'm " __FILE__ " at line %d\n", __LINE__);
}
second.c
#include
void second_name(void)
{
printf("I'm " __FILE__ " at line %d\n", __LINE__);
}
void print_name(void)
{
printf("I'm " __FILE__ " at line %d\n", __LINE__);
}
main.c
#include
#include
extern void print_name(void);
int main(int argc, char *argv[])
{
void (*second_name)(void);
void *handle;
int count = 0;
while(42)
{
print_name();
handle = dlopen("second.so", RTLD_NOW);
print_name();
if (handle != NULL)
{
second_name = dlsym(handle, "second_name");
if (second_name != NULL)
{
printf("second : ");
second_name();
}
dlclose(handle);
}
else
fprintf(stderr, "Error : %s\n", dlerror());
}
}
____
Compilation and execution :
gcc -shared -O0 -g second.c -o second.so
gcc -shared -O0 -g first.c -o libfirst.so
gcc -O0 -g toto.c -lfirst -L. -o test
export LD_LIBRARY_PATH=$PWD
gdb ./test
Thank you for your help
--
Alexandre Martins
NETASQ -- We secure IT
Double free() in libc or gdb ?
Dear all, I'm currently having some trouble with the dynamic loader. I have the libc compilled with "MALLOC_DEBUG" flag to detect double free. When i run this piece of code (attached file) thought GDB, i have this assertion : Assertion failed: ((run->regs_mask[elm] & (1U << bit)) == 0), function arena_run_reg_dalloc, file /usr/src/lib/libc/stdlib/malloc.c, line 2543. But when i run the same binary without GDB, no assert. I'm very confused. Can you help me to debug that ? Best regards -- Alexandre Martins NETASQ -- We secure IT
Re: Fwd: OpenSSL 1.0.0d for Freebsd HEAD
Hello, This sound great :) SIGILL is raised when the program try to execute an assembly code that the CPU cannot execute. It mean that the library or the binary is miscompiled. Regards, On Tuesday 01 March 2011 20:20:58 Marius Strobl wrote: > On Tue, Mar 01, 2011 at 10:31:16AM +0100, Alexandre Martins wrote: > > Dear, > > > > Have you extracted the tarball fo openssl source (1.0.0d) in > > crypto/openssl ? > > Ah, I missed that, the last couple of mails in this thread were only > talking about the patch :) > With the tarball untared it actually builds and works on sparc64 as > far as ssh(d) and HTTPS via fetch are concerned. The problem reports > (programs getting killed with SIGILL probably due to an infinite > recursion or some such) were about apache and unbound using an > OpenSSL 1.0.0 port. I'm not sure whether their use of OpenSSL would > make a difference or the port is broken. > > Marius -- Alexandre Martins NETASQ signature.asc Description: This is a digitally signed message part.
Re: OpenSSL 1.0.0d for Freebsd HEAD
To make it simple, you will find the "howto" for applying this patch: 1) move to freebsd HEAD directory cd 2) download patch and openssl: fetch http://www.openssl.org/source/openssl-1.0.0d.tar.gz fetch http://people.freebsd.org/~fabient/patch-head20110222-openssl1.0.0d 3) erase current sources of openssl rm -rf crypto/openssl 4) extract the sources of openssl into crypto/openssl tar -C crypto -xf openssl-1.0.0d.tar.gz mv crypto/openssl-1.0.0d crypto/openssl 5) apply the patch to migrate the build patch -p0 < patch-head20110222-openssl1.0.0d 6) compile the world make buildworld 7) and install it make installworld 8) welcome to openssl 1.0.0d openssl version I have build successfully FreeBSD for all platfom (make universe) I also checked it on i386 and amd64 platform and no problems was found. Regards, On Tuesday 01 March 2011 10:31:16 Alexandre Martins wrote: > Dear, > > Have you extracted the tarball fo openssl source (1.0.0d) in crypto/openssl > ? > > Regards, > > > From: Marius Strobl > > Date: February 28, 2011 9:23:07 PM GMT+01:00 > > To: Fabien Thomas > > Cc: freebsd-current@freebsd.org > > Subject: Re: OpenSSL 1.0.0d for Freebsd HEAD > > > > On Mon, Feb 28, 2011 at 12:00:19PM +0100, Fabien Thomas wrote: > >>> Dears, > >>> > >>> After several research, i have removed the problematic part. > >>> > >>> You can find the new version here: > >>> > >>> http://people.freebsd.org/~fabient/patch-head20110222-openssl1.0.0d > >> > >> It will be great to have it in 9.0. > >> > >> To do that how is it possible rebuild the port for all platform with > >> openssl 1.0.0d in base? Is there some people against that inclusion? > > > > Given that some users report ports linked against the port version > > of OpenSSL 1.0.0 (c I think) to not work on sparc64 I wanted to > > give your patch a try, but unfortuntately it doesn't even build: > > ===> secure/lib/libcrypto (buildincludes) > > cp > > /usr/home/marius/co/head3/src/secure/lib/libcrypto/opensslconf-sparc64.h > > opensslconf.h ( echo "#ifndef MK1MF_BUILD"; echo " /* auto-generated > > by crypto/Makefile.ssl for crypto/cversion.c */"; echo " #define > > CFLAGS \"cc\""; echo " #define PLATFORM \"FreeBSD-sparc64\""; echo " > > #define DATE \"`LC_ALL=C date`\""; echo "#endif" ) > buildinf.h make: > > don't know how to make asn1_locl.h. Stop > > *** Error code 2 > > > > Marius -- Alexandre Martins NETASQ signature.asc Description: This is a digitally signed message part.
Re: Fwd: OpenSSL 1.0.0d for Freebsd HEAD
Dear, Have you extracted the tarball fo openssl source (1.0.0d) in crypto/openssl ? Regards, > From: Marius Strobl > Date: February 28, 2011 9:23:07 PM GMT+01:00 > To: Fabien Thomas > Cc: freebsd-current@freebsd.org > Subject: Re: OpenSSL 1.0.0d for Freebsd HEAD > > On Mon, Feb 28, 2011 at 12:00:19PM +0100, Fabien Thomas wrote: >>> Dears, >>> >>> After several research, i have removed the problematic part. >>> >>> You can find the new version here: >>> >>> http://people.freebsd.org/~fabient/patch-head20110222-openssl1.0.0d >> >> It will be great to have it in 9.0. >> >> To do that how is it possible rebuild the port for all platform with >> openssl 1.0.0d in base? Is there some people against that inclusion? > > Given that some users report ports linked against the port version > of OpenSSL 1.0.0 (c I think) to not work on sparc64 I wanted to > give your patch a try, but unfortuntately it doesn't even build: > ===> secure/lib/libcrypto (buildincludes) > cp > /usr/home/marius/co/head3/src/secure/lib/libcrypto/opensslconf-sparc64.h > opensslconf.h ( echo "#ifndef MK1MF_BUILD"; echo " /* auto-generated > by crypto/Makefile.ssl for crypto/cversion.c */"; echo " #define > CFLAGS \"cc\""; echo " #define PLATFORM \"FreeBSD-sparc64\""; echo " > #define DATE \"`LC_ALL=C date`\""; echo "#endif" ) > buildinf.h make: > don't know how to make asn1_locl.h. Stop > *** Error code 2 > > Marius -- Alexandre Martins Research engineer NETASQ signature.asc Description: This is a digitally signed message part.
Re: OpenSSL 1.0.0d for Freebsd HEAD
Dears, After several research, i have removed the problematic part. You can find the new version here: http://people.freebsd.org/~fabient/patch-head20110222-openssl1.0.0d Regards, -- Alexandre Martins Research engineer NETASQ On Monday 14 February 2011 17:18:24 Alexandre Martins wrote: > Dear, > > Thank you for your feed-back. > > I'll look for this issu, and i hope deliver a better patch quickly. > > Regards, > > > Alexandre Martins writes: > > > For those interested in testing, you can find a patch that add OpenSSL > > > 1.0d to head. > > > > [...] > > > > Hmm, doesn't build with ld(1) from /projects/binutils-2.17. > > > > $ make -dl all > > as -o rc4-amd64.o /usr/src/secure/lib/libcrypto/amd64/rc4-amd64.s > > [ -z "ctfconvert" -o -n "1" ] || (echo ctfconvert -L VERSION > > rc4-amd64.o > > > > && ctfconvert -L VERSION rc4-amd64.o) echo building static crypto > > library > > > > building static crypto library > > rm -f libcrypto.a > > ar cq libcrypto.a `lorder ...` > > ranlib libcrypto.a > > as -o rc4-amd64.po /usr/src/secure/lib/libcrypto/amd64/rc4-amd64.s > > [ -z "ctfconvert" -o -n "1" ] || (echo ctfconvert -L VERSION > > > > rc4-amd64.po && ctfconvert -L VERSION rc4-amd64.po) echo building > > profiled crypto library > > > > building profiled crypto library > > rm -f libcrypto_p.a > > ar cq libcrypto_p.a `lorder ...` > > ranlib libcrypto_p.a > > as -o rc4-amd64.So /usr/src/secure/lib/libcrypto/amd64/rc4-amd64.s > > [ -z "ctfconvert" -o -n "1" ] || (echo ctfconvert -L VERSION > > > > rc4-amd64.So && ctfconvert -L VERSION rc4-amd64.So) echo building shared > > library libcrypto.so.7 > > > > building shared library libcrypto.so.7 > > rm -f libcrypto.so.7 libcrypto.so > > ln -fs libcrypto.so.7 libcrypto.so > > cc -fstack-protector -shared -Wl,-x -o libcrypto.so.7 > > > > -Wl,-soname,libcrypto.so.7 `lorder ...` /usr/bin/ld: rc4-amd64.So: > > relocation R_X86_64_PC32 against `OPENSSL_ia32cap_P' can not be used when > > making a shared object; recompile with -fPIC /usr/bin/ld: final link > > failed: Bad value > > > > *** Error code 1 > > > > Reverting back to binutils-2.15 makes build fail with another error. > > libcrypto builds fine but linking against it always fails > > > > $ cc foo.c -lcrypto > > /usr/lib/libcrypto.so: undefined reference to > > `_x86_64_Camellia_decrypt' /usr/lib/libcrypto.so: undefined reference > > to `.Ldloop' > > > > Indeed, some parts are missing > > > > %% diff against output from cmll-x86_64.pl > > --- secure/lib/libcrypto/amd64/cmll_amd64.s > > +++ crypto/openssl/crypto/camellia/asm/cmll-x86_64.pl.out > > > > @@ -312,6 +312,170 @@ Camellia_DecryptBlock_Rounds: > > call_x86_64_Camellia_decrypt > > signature.asc Description: This is a digitally signed message part.
Re: OpenSSL 1.0.0d for Freebsd HEAD
Dear, Thank you for your feed-back. I'll look for this issu, and i hope deliver a better patch quickly. Regards, -- Alexandre Martins Research engineer NETASQ On Monday 14 February 2011 16:50:26 Anonymous wrote: > Alexandre Martins writes: > > For those interested in testing, you can find a patch that add OpenSSL > > 1.0d to head. > > [...] > > Hmm, doesn't build with ld(1) from /projects/binutils-2.17. > > $ make -dl all > as -o rc4-amd64.o /usr/src/secure/lib/libcrypto/amd64/rc4-amd64.s > [ -z "ctfconvert" -o -n "1" ] || (echo ctfconvert -L VERSION rc4-amd64.o > && ctfconvert -L VERSION rc4-amd64.o) echo building static crypto library > building static crypto library > rm -f libcrypto.a > ar cq libcrypto.a `lorder ...` > ranlib libcrypto.a > as -o rc4-amd64.po /usr/src/secure/lib/libcrypto/amd64/rc4-amd64.s > [ -z "ctfconvert" -o -n "1" ] || (echo ctfconvert -L VERSION > rc4-amd64.po && ctfconvert -L VERSION rc4-amd64.po) echo building > profiled crypto library > building profiled crypto library > rm -f libcrypto_p.a > ar cq libcrypto_p.a `lorder ...` > ranlib libcrypto_p.a > as -o rc4-amd64.So /usr/src/secure/lib/libcrypto/amd64/rc4-amd64.s > [ -z "ctfconvert" -o -n "1" ] || (echo ctfconvert -L VERSION > rc4-amd64.So && ctfconvert -L VERSION rc4-amd64.So) echo building shared > library libcrypto.so.7 > building shared library libcrypto.so.7 > rm -f libcrypto.so.7 libcrypto.so > ln -fs libcrypto.so.7 libcrypto.so > cc -fstack-protector -shared -Wl,-x -o libcrypto.so.7 > -Wl,-soname,libcrypto.so.7 `lorder ...` /usr/bin/ld: rc4-amd64.So: > relocation R_X86_64_PC32 against `OPENSSL_ia32cap_P' can not be used when > making a shared object; recompile with -fPIC /usr/bin/ld: final link > failed: Bad value > *** Error code 1 > > Reverting back to binutils-2.15 makes build fail with another error. > libcrypto builds fine but linking against it always fails > > $ cc foo.c -lcrypto > /usr/lib/libcrypto.so: undefined reference to `_x86_64_Camellia_decrypt' > /usr/lib/libcrypto.so: undefined reference to `.Ldloop' > > Indeed, some parts are missing > > %% diff against output from cmll-x86_64.pl > --- secure/lib/libcrypto/amd64/cmll_amd64.s > +++ crypto/openssl/crypto/camellia/asm/cmll-x86_64.pl.out > @@ -312,6 +312,170 @@ Camellia_DecryptBlock_Rounds: > > call_x86_64_Camellia_decrypt > > + bswapl %r8d > + bswapl %r9d > + bswapl %r10d > + movl%r8d,0(%r13) > + bswapl %r11d > + movl%r9d,4(%r13) > + movl%r10d,8(%r13) > + movl%r11d,12(%r13) > + > + movq0(%rsp),%r15 > + movq8(%rsp),%r14 > + movq16(%rsp),%r13 > + movq24(%rsp),%rbp > + movq32(%rsp),%rbx > + leaq40(%rsp),%rsp > +.Ldec_epilogue: > + .byte 0xf3,0xc3 > +.sizeCamellia_DecryptBlock_Rounds,.-Camellia_DecryptBlock_Rounds > + > +.type_x86_64_Camellia_decrypt,@function > +.align 16 > +_x86_64_Camellia_decrypt: > + xorl0(%r14),%r9d > + xorl4(%r14),%r8d > + xorl8(%r14),%r11d > + xorl12(%r14),%r10d > +.align 16 > +.Ldloop: > + movl-8(%r14),%ebx > + movl-4(%r14),%eax > + > + xorl%r8d,%eax > + xorl%r9d,%ebx > + movzbl %ah,%esi > + movzbl %bl,%edi > + movl2052(%rbp,%rsi,8),%edx > + movl0(%rbp,%rdi,8),%ecx > + movzbl %al,%esi > + shrl$16,%eax > + movzbl %bh,%edi > + xorl4(%rbp,%rsi,8),%edx > + shrl$16,%ebx > + xorl4(%rbp,%rdi,8),%ecx > + movzbl %ah,%esi > + movzbl %bl,%edi > + xorl0(%rbp,%rsi,8),%edx > + xorl2052(%rbp,%rdi,8),%ecx > + movzbl %al,%esi > + movzbl %bh,%edi > + xorl2048(%rbp,%rsi,8),%edx > + xorl2048(%rbp,%rdi,8),%ecx > + movl-16(%r14),%ebx > + movl-12(%r14),%eax > + xorl%edx,%ecx > + rorl$8,%edx > + xorl%ecx,%r10d > + xorl%ecx,%r11d > + xorl%edx,%r11d > + xorl%r10d,%eax > + xorl%r11d,%ebx > + movzbl %ah,%esi > + movzbl %bl,%edi > + movl2052(%rbp,%rsi,8),%edx > + movl0(%rbp,%rdi,8),%ecx > + movzbl %al,%esi > + shrl$16,%eax > + movzbl %bh,%edi > + xorl4(%rbp,%rsi,8),%edx > + shrl$16,%ebx > + xorl4(%rbp,%rdi,8),%ecx > + movzbl %ah,%esi > + movzbl %bl,%edi > + xorl0(%rbp,%rsi,8),%edx > + xorl2052(%rbp,%rdi,8),
