Re: HEADS UP: Merge of binutils 2.17
On 2011-01-07 22:54, Ade Lovett wrote: Most likely it's low priority given all the other exp-runs that affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a bunch of other infrastructure stuff. Not to mention the impending 7- and 8- RELEASEs. I understand, and there will probably also be shortage of people with time during the holiday season. I'm fine with holding this off for as long as it takes to make it work for everybody. It would be nice to get it in well before 9.0 slowly starts going into freeze mode, though. Then of course there's the issue (which is certainly getting better) of finding a point in time along the -CURRENT path where the tree is stable (sic) enough to get through a full ports run (which is one of the bigger internal stress tests we have of the system). Yes, unfortunately there are some stability problems in vanilla -current as of late, especially with long multiprocess builds, such as universes or bulk packaging with -j nnn. Sometimes it panics. :( IMO, the best approach would be to make sure it does the right thing with 'make universe' (twice, naturally, the second time being when all traces of the previous binutils has been purged from the building system). Since the beginning of the binutils 2.17 project branch, I have built universes many times with it, and as far as I know, all problems with the base system have been solved, on all arches. Once that's done, commit (please bump __FreeBSD_version as part of this, in case ports OSVERSION hacks are eventually needed), and then give the exp-run a whirl -- with all of the above, this should be nicely after 7.4/8.2 I would rather see exp-run results before committing this. :) ___ 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: UDP checksum broken, -head and releng_8
On Fri, 7 Jan 2011, Daniel Eischen wrote:
On Fri, 7 Jan 2011, Daniel Eischen wrote:
On Fri, 7 Jan 2011, Bjoern A. Zeeb wrote:
On Fri, 7 Jan 2011, Daniel Eischen wrote:
When sending multicast packets to a socket that is _not_
bound to the multicast address, this generates bad UDP
checksums. This use to work and was broke sometime between
the middle of October and late December as far as I can
tell.
My very best guess would be: r215110
It doesn't look very harmful, but I'll try backing it out.
Backing this out seems to fix it. I'll have to test it
more after I get some sleep ;-)
I've attached what may be a proper patch. Please review.
I'd like to get this fixed in releng_8 too.
--
DEIndex: netinet/in_pcb.c
===
--- netinet/in_pcb.c(revision 216690)
+++ netinet/in_pcb.c(working copy)
@@ -874,6 +874,7 @@
}
}
if (laddr.s_addr == INADDR_ANY) {
+ error = in_pcbladdr(inp, faddr, laddr, cred);
/*
* If the destination address is multicast and an outgoing
* interface has been set as a multicast option, use the
@@ -893,16 +894,17 @@
break;
if (ia == NULL) {
IN_IFADDR_RUNLOCK();
- return (EADDRNOTAVAIL);
+ error = EADDRNOTAVAIL;
+ } else {
+ laddr = ia-ia_addr.sin_addr;
+ IN_IFADDR_RUNLOCK();
+ /* Override error from in_pcbladdr(). */
+ error = 0;
}
- laddr = ia-ia_addr.sin_addr;
- IN_IFADDR_RUNLOCK();
}
- } else {
- error = in_pcbladdr(inp, faddr, laddr, cred);
- if (error)
- return (error);
}
+ if (error)
+ return (error);
}
oinp = in_pcblookup_hash(inp-inp_pcbinfo, faddr, fport, laddr, lport,
0, NULL);
___
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: UDP checksum broken, -head and releng_8
On Sat, 8 Jan 2011, Daniel Eischen wrote:
When sending multicast packets to a socket that is _not_
bound to the multicast address, this generates bad UDP
checksums. This use to work and was broke sometime between
the middle of October and late December as far as I can
tell.
My very best guess would be: r215110
It doesn't look very harmful, but I'll try backing it out.
Backing this out seems to fix it. I'll have to test it
more after I get some sleep ;-)
I've attached what may be a proper patch. Please review.
I'd like to get this fixed in releng_8 too.
I would remove the comment from the MC good path about the in_pcbladdr()
error but just change the description at the top s,use,prefer, to be
more exact.
The other question I am not sure what shoud happen is, in the case
in_pcbladdr() returns a source address but a given one via MC option/ifp
does not find an address (in case outgoing itnerface could be different)?
That was never considered in the past.
It's probably easiest understood with the slightly modified version
of the patch.
Otherwise I think it would match both the historic behaviour again
and keep the fix for r215110 (that rev. should be mentioned in the
commit message).
So apart from the 1 line comment change (ignoring my XXX-BZ completely
for the moment and this fix) this looks good.
/bz
PS: I doubt you can make 8.2-R anymore.
Index: in_pcb.c
===
--- in_pcb.c(revision 216952)
+++ in_pcb.c(working copy)
@@ -874,9 +874,10 @@ in_pcbconnect_setup(struct inpcb *inp, struct sock
}
}
if (laddr.s_addr == INADDR_ANY) {
+ error = in_pcbladdr(inp, faddr, laddr, cred);
/*
* If the destination address is multicast and an outgoing
-* interface has been set as a multicast option, use the
+* interface has been set as a multicast option, prefer the
* address of that interface as our source address.
*/
if (IN_MULTICAST(ntohl(faddr.s_addr))
@@ -893,16 +894,23 @@ in_pcbconnect_setup(struct inpcb *inp, struct sock
break;
if (ia == NULL) {
IN_IFADDR_RUNLOCK();
- return (EADDRNOTAVAIL);
+ /*
+* XXX-BZ should we use a possible
+* source address from in_pcbladdr()
+* and only overwrite the error if
+* there was one?
+* if (error)
+*/
+ error = EADDRNOTAVAIL;
+ } else {
+ laddr = ia-ia_addr.sin_addr;
+ IN_IFADDR_RUNLOCK();
+ error = 0;
}
- laddr = ia-ia_addr.sin_addr;
- IN_IFADDR_RUNLOCK();
}
- } else {
- error = in_pcbladdr(inp, faddr, laddr, cred);
- if (error)
-return (error);
}
+ if (error)
+ return (error);
}
oinp = in_pcblookup_hash(inp-inp_pcbinfo, faddr, fport, laddr, lport,
0, NULL);
--
Bjoern A. Zeeb You have to have visions!
ks Going to jail sucks -- bz All my daemons like it!
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html
___
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: HEADS UP: Merge of binutils 2.17
On 2011-01-08 01:54, Anonymous wrote: Looks like lang/sbcl doesn't like new ld(1), here on amd64. Same error when building using devel/binutils. Can you reproduce? ... //doing warm init - compilation phase This is SBCL 1.0.43, an implementation of ANSI Common Lisp. More information about SBCL is available athttp://www.sbcl.org/. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. Bus error Yes, it gives a bus error here too, at least on amd64. I found a similar thread about such an issue with sbcl, started by you in March 2009: http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004690.html It looks like in this case, the same problem happens, it eats large amounts of memory, and then dies (this is on a box with 4G RAM and a few G of swap): PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 33512 dim 1 1110 8244M 3055M CPU11 0:54 68.99% sbcl Obviously, when it tries to actually access stuff that is above the total virtual memory of the box, it will die. In any case, the workaround in that previous thread (setting the sysctl machdep.prot_fault_translation=2) works for me, at least to let the port build to completion, and install succesfully. Now, in the previous report, it seems there was something going on with .note.ABI-tag sections, which needed a kernel fix. And since Kostik is now introducing new .note sections, for the non-executable stack feature, it may be that I just hit a window where it is not entirely complete? The last sync of binutils-2.17 with head was at r217118, just after the introduction of those .note sections, but before several related changes in the kernel and other areas. I will sync the binutils-2.17 branch again, and see if that helps the port to build without setting the workaround sysctl. ___ 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: UDP checksum broken, -head and releng_8
On Sat, 8 Jan 2011, Bjoern A. Zeeb wrote: On Sat, 8 Jan 2011, Daniel Eischen wrote: When sending multicast packets to a socket that is _not_ bound to the multicast address, this generates bad UDP checksums. This use to work and was broke sometime between the middle of October and late December as far as I can tell. My very best guess would be: r215110 It doesn't look very harmful, but I'll try backing it out. Backing this out seems to fix it. I'll have to test it more after I get some sleep ;-) I've attached what may be a proper patch. Please review. I'd like to get this fixed in releng_8 too. I would remove the comment from the MC good path about the in_pcbladdr() error but just change the description at the top s,use,prefer, to be more exact. Agreed. The other question I am not sure what shoud happen is, in the case in_pcbladdr() returns a source address but a given one via MC option/ifp does not find an address (in case outgoing itnerface could be different)? That was never considered in the past. Yes, I considered that as well. I wasn't sure about that, but the more I think about it, it might make sense to ignore any error from an invalid/nonexistent interface set as an MC option if we are able to find one via in_pcbladdr(). But we'll ignore that for now. Also, are there any restrictions with jail? If we're in a jail and can't find an address, do we really want to allow _any_ address set with an MC option? I've never used jails, but was just wondering if the application could somehow use an interface address that it wasn't allowed to use. It's probably easiest understood with the slightly modified version of the patch. Otherwise I think it would match both the historic behaviour again and keep the fix for r215110 (that rev. should be mentioned in the commit message). So apart from the 1 line comment change (ignoring my XXX-BZ completely for the moment and this fix) this looks good. Ok, I'll commit the patch, and thank you very much for helping me solve this problem :-) -- DE ___ 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: [ANNOUNCE] Playstation 3 support now in HEAD
Well done Nathan, very cool! :) any chance you could post the dmesg output to the list Sevan / Venture37 ___ 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: UDP checksum broken, -head and releng_8
On Sat, 8 Jan 2011, Daniel Eischen wrote: Also, are there any restrictions with jail? If we're in a jail and can't find an address, do we really want to allow _any_ address set with an MC option? I've never used jails, but was just wondering if the application could somehow use an interface address that it wasn't allowed to use. Yes, I think you can do that there but I'd hope the bind following would fail it. -- Bjoern A. Zeeb You have to have visions! ks Going to jail sucks -- bz All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ 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: HEADS UP: Merge of binutils 2.17
Hello Pav, Den 08/01/2011 kl. 20.34 skrev Pav Lucistnik: Package cluster is quite clever, akshully, and since this is OT here, just terse comments Sorry, replied to a bad message... redirecting to current@ 1. adding SSD disks irrelevant because of bullet 2. 2. source and destination directories on md devices already done, swap backed md devices are used 3. huge ccache cache 4. dist-cc these tend to have their own issues 5. some heuristics on which ports could be skipped because dependencies haven't changed since last run this is also already done, we call it incremental builds 6. tuning the host system for this specific task empty words I was pretty sure I couldn't improve anything with 5 minutes of thinking. I'm glad the most obvious things have already been done, and I'm sure you and others have put a lot of effort into this. My question was more what, if anything, can be done to speed up the cluster. Also, how long does it take to complete an exp-run on the cluster? Thanks, Erik
Re: HEADS UP: Merge of binutils 2.17
On Jan 8, 2011, at 3:10 PM, Erik Cederstrand wrote: Hello Pav, Den 08/01/2011 kl. 20.34 skrev Pav Lucistnik: Package cluster is quite clever, akshully, and since this is OT here, just terse comments Sorry, replied to a bad message... redirecting to current@ 1. adding SSD disks irrelevant because of bullet 2. 2. source and destination directories on md devices already done, swap backed md devices are used 3. huge ccache cache 4. dist-cc these tend to have their own issues 5. some heuristics on which ports could be skipped because dependencies haven't changed since last run this is also already done, we call it incremental builds 6. tuning the host system for this specific task empty words I was pretty sure I couldn't improve anything with 5 minutes of thinking. I'm glad the most obvious things have already been done, and I'm sure you and others have put a lot of effort into this. My question was more what, if anything, can be done to speed up the cluster. Also, how long does it take to complete an exp-run on the cluster? Erik, As I said before, the tinderbox / exp-run infrastructure needs to be made portable, the infrastructure needs to be there, and as extra credit (I've stated this in other emails in the past) parallelization in ports/pkg_install needs to be fixed as ports/packaging in FreeBSD doesn't work in an ACID[1]-like manner. I'd rather not repeat the reasons in greater detail. Please look for my replies to this thread on current@ for more details in part A, and look for my replies on ports@ for more details in part B. Thanks, -Garrett 1. http://en.wikipedia.org/wiki/ACID___ 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: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/
On Wed, Jan 05, 2011 at 10:30:43PM +0100, Ulrich Spörlein wrote: On Wed, 05.01.2011 at 20:36:53 +0100, Jilles Tjoelker wrote: On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Spörlein wrote: *But*, it should grok that for err(3) and exit(3). Now there are some possible remedies: - get IPA to work with clang, or at least file a bug - mark functions as __dead2 (please don't do that) Why not? Cause IMHO it adds clutter, is noisy and needs to be maintained manually, when we have these computer things that should deduct this by themselves. Yes, but to me it seems the only realistic option of your three. Upstream is unlikely to add IPA to the checker and other kinds of annotation are probably either similar to __dead2 with the same problems and an additional one that gcc does not check it or very specific to a particular complaint from the checker. I have done this in some cases because it leads to better code with gcc (the system version in 9-current). See SVN commit r212508 to bin/sh/parser.c. Although synexpect() and synerror() are static, adding __dead2 to both makes the executable 576 bytes smaller on i386 (these functions are called many times). Adding __dead2 to synexpect() only causes a warning noreturn function does return (it calls synerror()). Adding __dead2 to synerror() only also makes the executable smaller but not as much as adding it to both. Reordering the functions in the file does not help to make gcc see that the functions do not return. This is too bad and really makes me sad. It shouldn't be necessary to hand-hold the compilers like that. Could you try some tests with gcc 4.5 to confirm this is still required? gcc 4.5 still needs it. gcc 4.6 and clang (the compiler) do not need it. (For gcc, used ports gcc and compiled head bin/sh with some patches on stable/8. For clang, used base clang and compiled head bin/sh on head.) -- Jilles Tjoelker ___ 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: NFSv4 and pam_mount - mounting user home directories.
Hi, 1. I have a NFSv4-enabled server with /etc/exports like: V4: / -sec=sys /home/stud -sec=sys /etc/rc.conf: nfs_server_enable=YES nfsv4_server_enable=YES nfsuserd_enable=YES Is it possible to run ONLY NFSv4 server (without NFSv3 compatibility) ? You can limit the versions of NFS supported by the server via: vfs.newnfs.server_max_nfsvers vfs.newnfs.server_min_nfsvers If both of these are set to 4, only NFSv4 will be handled. (However, note that it is not possible to run the regular and experimental NFS server on the same machine concurrently, so this would mean that the box would only serve NFSv4.) 2. On a client station I installed pam_mount module in order to mount home directory from server automatically during logging in to station. I would like to mount it via NFSv4. In pam_mount.conf.xml I inserted: volume fstype=nfs server=free pgrp=stud path=/home/stud/%(USER) mountpoint=/home/stud/%(USER) / volume fstype=nfs server=free pgrp=prac path=/home/prac/%(USER) mountpoint=/home/prac/%(USER) / nfsmountmount_nfs -o nfsv4 %(SERVER):%(VOLUME) %(MNTPT)/nfsmount And it works, but: On a client station every user can be root, and I don't want even root to be able to mount user's home directories without giving a password (via mount_nfs command)- is it possible? Not that I know. If the users are root they can do a mount. It is possible to allow non-root users to do mounts, but not restrict mounting by root. Note: - root is not mapped to root on the server for your configuration so, although they can mount, they can't access the server volume beyond what nobody/world is allowed to do. The concept of mount doesn't really exist in an NFS server. The client mount_nfs simply finds a handle for the directory at the end of the mount path. The server only sees RPCs doing operations from that directory down and has no idea that the client has mounted it there. After mounting there is a strange UID and GID: ls -la total 472 drwxr-xr-x 10 32767 32767 1024 8 sty 23:00 ./ drwxr-xr-x 9 root wheel 512 1 wrz 2009 ../ -rw--- 1 32767 32767 0 12 cze 2010 .Xauthority drwxr-xr-x 3 32767 32767 512 12 cze 2010 .cache/ -rw--- 1 32767 32767 68693 8 sty 21:11 .hist -rw--- 1 32767 32767 0 11 cze 2010 .history the UID should be 700. This will be the user name mapping business. For NFSv4, both the client and the server must know the username for UID == 700 and they must be configured with the same user name space domain. (I suspect the latter is correct or root, wheel would not have worked.) For NFSv4, it is names and not numbers that go on the wire for file ownership. (Try reading man nfsv4 and man nfsuserd.) rick ___ 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
