Re: svn commit: r232271 - head/sys/kern
On Wed, 29 Feb 2012, Dimitry Andric wrote: On 2012-02-28 23:11, Giovanni Trematerra wrote: On Tue, Feb 28, 2012 at 10:45 PM, Dimitry Andric wrote: ... It introduces a style(9) violation, though. I think it should be in this way pipe_chmod(struct file *fp, mode_t mode, struct ucred *active_cred, struct thread *td) Indeed. Is there any interest in changing the other K&R definitions in this file to C99? Or does that cause too much churn? I tried to make this change as minimal as possible to make it compile. It is just churn for me. Btw, style(9) doesn't say anything about a maximum line width, maybe that should be added explicitly...:) Everything in style(9) is supposed to be implicit if not stated explicitly, but the examples of the line length limit have been especially broken by changing it into man page. Manpage formatting adds a 5-space left margin which starts by breaking all the literal examples of indentation by tabs -- e.g., leading tabs become a leading tab followed by 5 spaces, or 13 spaces if you filter the man page through col -bx. Any examples of the limit of 79 columns look like they are broken since they became non-examples with 84 columns *the maximum length is actually 5+77, not counting bad examples due to expansion of verbose VCS ids). I recently noticed another class of breakage: there were many examples of vertical whitespace, with none between statements except always 1 blank line before most block comments in groups of statements. Changing to a man page destroyed _all_ examples of this by turning all the block comments before statements into meta-comments in man page text instead of in C comments, and by adding more meta-comments in man page text; then to make things look right, there must be blank lines separating the man page text from the C code, and you can't tell if these blank lines are part of the literal examples of C code or just mdoc formatting. 4 explicit rules about blank lines remain, and none of these is in C function. 1 explicit rule about an empty line remains, but it is about the empty line after null declarations at the beginning of a function. It goes without saying that there is a blank line after non-null declarations at the beginning of a function, but most examples of this are now indistinguishable from man page paragraph breaks and the others are hard to see. Bruce ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r232261 - in head/sys: amd64/include i386/include pc98/include x86/include
on 28/02/2012 20:15 Tijl Coosemans said the following: > Author: tijl > Date: Tue Feb 28 18:15:28 2012 > New Revision: 232261 > URL: http://svn.freebsd.org/changeset/base/232261 > > Log: > Copy amd64 _types.h to x86 and merge with i386 _types.h. Replace existing > amd64/i386/pc98 _types.h with stubs. These header changes seem to be quite significant with potentially long-term consequences. If they have been thoroughly reviewed and discussed then it makes sense to not withhold at least "Reviewed by" line. -- Andriy Gapon ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r232238 - in head: share/man/man4 sys/dev/e1000 sys/dev/ixgbe sys/dev/netmap sys/dev/re sys/net tools/tools/netmap
On Tue, Feb 28, 2012 at 10:58:56PM +0100, Luigi Rizzo wrote: > On Wed, Feb 29, 2012 at 12:35:23AM +0400, Slawa Olhovchenkov wrote: > ... > > > > > ?3. The two changes above unfortunately require an API change, so > > > > > while > > > > > ? ? at it add a version field and some spares to the ioctl() argument > > > > > ? ? to help detect mismatches. > > > > > > > > Is it worth bumping __FreeBSD_version? > > > > > > I don't think it is necessary. > > > There is basically no code that uses the netmap API except for > > > the examples in tools/tools/netmap, and i now have a NETMAP_API macro > > > > no code in *FreeBSD base system*, yes? > > because I am write tools uses the netmap API now. > > i am glad to hear that, and the NETMAP_API will serve you well > because you can use the same also on the Linux version of netmap Can you explain some detail about netmap? 1. What is order of send packets from different rings? 2. What is time packets sent? I am need sustain desired value of transfer rate. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r232238 - in head: share/man/man4 sys/dev/e1000 sys/dev/ixgbe sys/dev/netmap sys/dev/re sys/net tools/tools/netmap
On Wed, Feb 29, 2012 at 01:14:33PM +0400, Slawa Olhovchenkov wrote: > On Tue, Feb 28, 2012 at 10:58:56PM +0100, Luigi Rizzo wrote: > > > On Wed, Feb 29, 2012 at 12:35:23AM +0400, Slawa Olhovchenkov wrote: > > ... > > > > > > ?3. The two changes above unfortunately require an API change, so > > > > > > while > > > > > > ? ? at it add a version field and some spares to the ioctl() > > > > > > argument > > > > > > ? ? to help detect mismatches. > > > > > > > > > > Is it worth bumping __FreeBSD_version? > > > > > > > > I don't think it is necessary. > > > > There is basically no code that uses the netmap API except for > > > > the examples in tools/tools/netmap, and i now have a NETMAP_API macro > > > > > > no code in *FreeBSD base system*, yes? > > > because I am write tools uses the netmap API now. > > > > i am glad to hear that, and the NETMAP_API will serve you well > > because you can use the same also on the Linux version of netmap > > Can you explain some detail about netmap? > > 1. What is order of send packets from different rings? > 2. What is time packets sent? I am need sustain desired value of > transfer rate. Same as with the standard API: 1. it is the hardware that decides that. You can make no assumptions. 2. once again, once you have issued the system call, it is the hardware that decides when it will send packets out. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r232238 - in head: share/man/man4 sys/dev/e1000 sys/dev/ixgbe sys/dev/netmap sys/dev/re sys/net tools/tools/netmap
On Wed, Feb 29, 2012 at 10:51:26AM +0100, Luigi Rizzo wrote: > On Wed, Feb 29, 2012 at 01:14:33PM +0400, Slawa Olhovchenkov wrote: > > On Tue, Feb 28, 2012 at 10:58:56PM +0100, Luigi Rizzo wrote: > > > > > On Wed, Feb 29, 2012 at 12:35:23AM +0400, Slawa Olhovchenkov wrote: > > > ... > > > > > > > ?3. The two changes above unfortunately require an API change, so > > > > > > > while > > > > > > > ? ? at it add a version field and some spares to the ioctl() > > > > > > > argument > > > > > > > ? ? to help detect mismatches. > > > > > > > > > > > > Is it worth bumping __FreeBSD_version? > > > > > > > > > > I don't think it is necessary. > > > > > There is basically no code that uses the netmap API except for > > > > > the examples in tools/tools/netmap, and i now have a NETMAP_API macro > > > > > > > > no code in *FreeBSD base system*, yes? > > > > because I am write tools uses the netmap API now. > > > > > > i am glad to hear that, and the NETMAP_API will serve you well > > > because you can use the same also on the Linux version of netmap > > > > Can you explain some detail about netmap? > > > > 1. What is order of send packets from different rings? > > 2. What is time packets sent? I am need sustain desired value of > > transfer rate. > > Same as with the standard API: > > 1. it is the hardware that decides that. You can make no assumptions. > 2. once again, once you have issued the system call, >it is the hardware that decides when it will send packets out. Realy? I don't do any system call now and see transmited packets (in dev.ix.0.mac_stats.tx_frames_XXX stats). 3. Jumbo frames support only throw tunable hw.netmap.buf_size? ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r232238 - in head: share/man/man4 sys/dev/e1000 sys/dev/ixgbe sys/dev/netmap sys/dev/re sys/net tools/tools/netmap
On Wed, Feb 29, 2012 at 01:46:03PM +0400, Slawa Olhovchenkov wrote: > On Wed, Feb 29, 2012 at 10:51:26AM +0100, Luigi Rizzo wrote: > > > On Wed, Feb 29, 2012 at 01:14:33PM +0400, Slawa Olhovchenkov wrote: > > > On Tue, Feb 28, 2012 at 10:58:56PM +0100, Luigi Rizzo wrote: > > > > > > > On Wed, Feb 29, 2012 at 12:35:23AM +0400, Slawa Olhovchenkov wrote: > > > > ... > > > > > > > > ?3. The two changes above unfortunately require an API change, > > > > > > > > so while > > > > > > > > ? ? at it add a version field and some spares to the ioctl() > > > > > > > > argument > > > > > > > > ? ? to help detect mismatches. > > > > > > > > > > > > > > Is it worth bumping __FreeBSD_version? > > > > > > > > > > > > I don't think it is necessary. > > > > > > There is basically no code that uses the netmap API except for > > > > > > the examples in tools/tools/netmap, and i now have a NETMAP_API > > > > > > macro > > > > > > > > > > no code in *FreeBSD base system*, yes? > > > > > because I am write tools uses the netmap API now. > > > > > > > > i am glad to hear that, and the NETMAP_API will serve you well > > > > because you can use the same also on the Linux version of netmap > > > > > > Can you explain some detail about netmap? > > > > > > 1. What is order of send packets from different rings? > > > 2. What is time packets sent? I am need sustain desired value of > > > transfer rate. > > > > Same as with the standard API: > > > > 1. it is the hardware that decides that. You can make no assumptions. > > 2. once again, once you have issued the system call, > >it is the hardware that decides when it will send packets out. > > Realy? I don't do any system call now and see transmited packets > (in dev.ix.0.mac_stats.tx_frames_XXX stats). you MUST issue system calls (ioctl() or poll()) ) to have packets sent out. Please re-read the manpage. > 3. Jumbo frames support only throw tunable hw.netmap.buf_size? yes but in practice forget jumbo frames. There is no guarantees that the code works for buf_size > 4096 . Unless you want to use them to support NFS and 8K filesystem blocks (in which case there is a point - you have no fragmentation), jumbo frames are only useful with low-performance drivers. With netmap you have no such an issue. cheers luigi ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r232238 - in head: share/man/man4 sys/dev/e1000 sys/dev/ixgbe sys/dev/netmap sys/dev/re sys/net tools/tools/netmap
On Wed, Feb 29, 2012 at 11:08:25AM +0100, Luigi Rizzo wrote: > On Wed, Feb 29, 2012 at 01:46:03PM +0400, Slawa Olhovchenkov wrote: > > On Wed, Feb 29, 2012 at 10:51:26AM +0100, Luigi Rizzo wrote: > > > > > On Wed, Feb 29, 2012 at 01:14:33PM +0400, Slawa Olhovchenkov wrote: > > > > On Tue, Feb 28, 2012 at 10:58:56PM +0100, Luigi Rizzo wrote: > > > > > > > > > On Wed, Feb 29, 2012 at 12:35:23AM +0400, Slawa Olhovchenkov wrote: > > > > > ... > > > > > > > > > ?3. The two changes above unfortunately require an API > > > > > > > > > change, so while > > > > > > > > > ? ? at it add a version field and some spares to the ioctl() > > > > > > > > > argument > > > > > > > > > ? ? to help detect mismatches. > > > > > > > > > > > > > > > > Is it worth bumping __FreeBSD_version? > > > > > > > > > > > > > > I don't think it is necessary. > > > > > > > There is basically no code that uses the netmap API except for > > > > > > > the examples in tools/tools/netmap, and i now have a NETMAP_API > > > > > > > macro > > > > > > > > > > > > no code in *FreeBSD base system*, yes? > > > > > > because I am write tools uses the netmap API now. > > > > > > > > > > i am glad to hear that, and the NETMAP_API will serve you well > > > > > because you can use the same also on the Linux version of netmap > > > > > > > > Can you explain some detail about netmap? > > > > > > > > 1. What is order of send packets from different rings? > > > > 2. What is time packets sent? I am need sustain desired value of > > > > transfer rate. > > > > > > Same as with the standard API: > > > > > > 1. it is the hardware that decides that. You can make no assumptions. > > > 2. once again, once you have issued the system call, > > >it is the hardware that decides when it will send packets out. > > > > Realy? I don't do any system call now and see transmited packets > > (in dev.ix.0.mac_stats.tx_frames_XXX stats). > > you MUST issue system calls (ioctl() or poll()) ) to have packets > sent out. Please re-read the manpage. Ah, pool(). I am don't clean understand this, please write some more in manpage. > > 3. Jumbo frames support only throw tunable hw.netmap.buf_size? > > yes but in practice forget jumbo frames. There is no guarantees > that the code works for buf_size > 4096 . > > Unless you want to use them to support NFS and 8K filesystem blocks > (in which case there is a point - you have no fragmentation), > jumbo frames are only useful with low-performance drivers. > With netmap you have no such an issue. This is (suuport jumbo frames) not for performance, but for compatibility and simplify application: one way for generation/capturing small and jumbo packets. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r232181 - in head/sys: kern sys
On 29 Feb 2012, at 07:50, Mikolaj Golub wrote: > JE> well that's exactly what I AM questioning.. how often will this be used? > JE> one person using this once in all of history isn't a real requirement > JE> for inclusion. > > This information may be very useful when troubleshooting unexpected behavior > of the application. > > Dmitry Banschikov, who was asking for this functionality and eventually > provided the patch, said that it needed this investigating an issue with an > application which created files with unexpected permissions. It turned out the > issue was with wrong usage of su(1), which may interpret '-c' option as a > login class or as a command to run, so the umask specified in the login class > was not applied. Then it wrote an utility to read a process umask via kvm to > troubleshoot this. > > I don't think this situation is in the class "one person using this once in > all of history". > > In my practice I have not face a situation when I need to know umask of > another process and it will be good if I never need this. But if I need it > eventually I would like to have a quick and easy way to do this. > > Also for me after applying the patch 'procstat -sa' output on my hosts was > rather educational. > > JE> It seems to me that someone is more likely to figure out a sneaky way > JE> to use this in a bad way than to want to use it in the way you expect. > > Being this someone I would use much easier sneaky ways to make a mess for > processes running with my uid. I think the monitoring aspect of the patch is fine. The bit I was worried about was external umask changes. This can cause race conditions for applications that manage their umask -- for example, bsdtar, if I recall correctly. It's one thing to use a debugger to force an application to change its umask -- the developer needs to know they are changing application behaviour. But exposing a feature that can lead to correct applications but incorrect results is a risky thing to do, hence my objection. I think given the other objections, it would be wise to remove write access to process umasks, but retain read access for procstat (which is quite useful, I agree). Robert___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r232181 - in head/sys: kern sys
On Wed, 29 Feb 2012 12:03:00 + Robert N. M. Watson wrote: RNMW> I think the monitoring aspect of the patch is fine. RNMW> The bit I was worried about was external umask changes. This can cause RNMW> race conditions for applications that manage their umask -- for RNMW> example, bsdtar, if I recall correctly. It's one thing to use a RNMW> debugger to force an application to change its umask -- the developer RNMW> needs to know they are changing application behaviour. But exposing a RNMW> feature that can lead to correct applications but incorrect results is RNMW> a risky thing to do, hence my objection. RNMW> I think given the other objections, it would be wise to remove write RNMW> access to process umasks, but retain read access for procstat (which is RNMW> quite useful, I agree). I still don't see why having a sysctl RW is worse than asking users to run something like in the attach when they need to change umask for another process, but ok, if people don't like RW I will remove it. -- Mikolaj Golub ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r232295 - in head/sys/arm: mv xscale/i8134x
Author: cognet
Date: Wed Feb 29 12:44:34 2012
New Revision: 232295
URL: http://svn.freebsd.org/changeset/base/232295
Log:
Make sure we do not provide the page 0 to the VM. It can't handle it properly,
because pmap_extract() returns 0 when there's no mapping.
PR: arm/154227
MFC after:1 week
Modified:
head/sys/arm/mv/mv_machdep.c
head/sys/arm/xscale/i8134x/crb_machdep.c
Modified: head/sys/arm/mv/mv_machdep.c
==
--- head/sys/arm/mv/mv_machdep.cWed Feb 29 12:13:05 2012
(r232294)
+++ head/sys/arm/mv/mv_machdep.cWed Feb 29 12:44:34 2012
(r232295)
@@ -287,9 +287,19 @@ physmap_init(void)
availmem_regions[i].mr_start + availmem_regions[i].mr_size,
availmem_regions[i].mr_size);
- phys_avail[j] = availmem_regions[i].mr_start;
- phys_avail[j + 1] = availmem_regions[i].mr_start +
- availmem_regions[i].mr_size;
+ /*
+* We should not map the page at PA 0x000, the VM can't
+* handle it, as pmap_extract() == 0 means failure.
+*/
+ if (availmem_regions[i].mr_start > 0 ||
+ availmem_regions[i].mr_size > PAGE_SIZE) {
+ phys_avail[j] = availmem_regions[i].mr_start;
+ if (phys_avail[j] == 0)
+ phys_avail[j] += PAGE_SIZE;
+ phys_avail[j + 1] = availmem_regions[i].mr_start +
+ availmem_regions[i].mr_size;
+ } else
+ j -= 2;
}
phys_avail[j] = 0;
phys_avail[j + 1] = 0;
Modified: head/sys/arm/xscale/i8134x/crb_machdep.c
==
--- head/sys/arm/xscale/i8134x/crb_machdep.cWed Feb 29 12:13:05 2012
(r232294)
+++ head/sys/arm/xscale/i8134x/crb_machdep.cWed Feb 29 12:44:34 2012
(r232295)
@@ -381,8 +381,8 @@ initarm(void *arg, void *arg2)
i = 0;
#ifdef ARM_USE_SMALL_ALLOC
- phys_avail[i++] = 0x;
- phys_avail[i++] = 0x1000; /*
+ phys_avail[i++] = 0x1000;
+ phys_avail[i++] = 0x2000; /*
*XXX: Gross hack to get our
* pages in the vm_page_array
. */
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r232181 - in head/sys: kern sys
On Wed, Feb 29, 2012 at 02:37:25PM +0200, Mikolaj Golub wrote: > > On Wed, 29 Feb 2012 12:03:00 + Robert N. M. Watson wrote: > > RNMW> I think the monitoring aspect of the patch is fine. > > RNMW> The bit I was worried about was external umask changes. This can cause > RNMW> race conditions for applications that manage their umask -- for > RNMW> example, bsdtar, if I recall correctly. It's one thing to use a > RNMW> debugger to force an application to change its umask -- the developer > RNMW> needs to know they are changing application behaviour. But exposing a > RNMW> feature that can lead to correct applications but incorrect results is > RNMW> a risky thing to do, hence my objection. > > RNMW> I think given the other objections, it would be wise to remove write > RNMW> access to process umasks, but retain read access for procstat (which is > RNMW> quite useful, I agree). > > I still don't see why having a sysctl RW is worse than asking users to run > something like in the attach when they need to change umask for another > process, but ok, if people don't like RW I will remove it. > What is done is attach is much worse then the sysctl, just because debugger attach often causes spurious EINTR, indeed seriously disrupting applications, as opposed to some uncertain damage that could be done in theory. *shrug* pgpIp9YrWG0Dc.pgp Description: PGP signature
svn commit: r232296 - head/sys/fs/nullfs
Author: kib Date: Wed Feb 29 14:43:27 2012 New Revision: 232296 URL: http://svn.freebsd.org/changeset/base/232296 Log: Merge a split multi-line comment. MFC after:1 week Modified: head/sys/fs/nullfs/null_subr.c Modified: head/sys/fs/nullfs/null_subr.c == --- head/sys/fs/nullfs/null_subr.c Wed Feb 29 12:44:34 2012 (r232295) +++ head/sys/fs/nullfs/null_subr.c Wed Feb 29 14:43:27 2012 (r232296) @@ -213,12 +213,9 @@ null_nodeget(mp, lowervp, vpp) /* * We do not serialize vnode creation, instead we will check for * duplicates later, when adding new vnode to hash. -* * Note that duplicate can only appear in hash if the lowervp is * locked LK_SHARED. -*/ - - /* +* * Do the MALLOC before the getnewvnode since doing so afterward * might cause a bogus v_data pointer to get dereferenced * elsewhere if MALLOC should block. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r232297 - head/usr.sbin/tzsetup
Author: emaste Date: Wed Feb 29 14:44:42 2012 New Revision: 232297 URL: http://svn.freebsd.org/changeset/base/232297 Log: Grammar: tzsetup now has more than one option. Modified: head/usr.sbin/tzsetup/tzsetup.8 Modified: head/usr.sbin/tzsetup/tzsetup.8 == --- head/usr.sbin/tzsetup/tzsetup.8 Wed Feb 29 14:43:27 2012 (r232296) +++ head/usr.sbin/tzsetup/tzsetup.8 Wed Feb 29 14:44:42 2012 (r232297) @@ -49,7 +49,7 @@ utility also determines whether any adju the hardware clock does not keep .Tn UTC . .Pp -The following option is available: +The following options are available: .Bl -tag -offset indent -width Fl .It Fl C Ar chroot_directory Open all files and directories relative to ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r232299 - head/sys/fs/nullfs
Author: kib
Date: Wed Feb 29 15:06:00 2012
New Revision: 232299
URL: http://svn.freebsd.org/changeset/base/232299
Log:
Move the code to destroy half-contructed nullfs vnode into helper
function null_destroy_proto() from null_insmntque_dtr(). Also
apply null_destroy_proto() in null_nodeget() when we raced and a vnode
is found in the hash, so the currently allocated protonode shall be
destroyed.
Lock the vnode interlock around reassigning the v_vnlock.
In fact, this path will not be exercised after several later commits,
since null_nodeget() cannot take shared-locked lowervp at all due to
insmntque() requirements.
Reported by: rea
Tested by:pho
MFC after:1 week
Modified:
head/sys/fs/nullfs/null_subr.c
Modified: head/sys/fs/nullfs/null_subr.c
==
--- head/sys/fs/nullfs/null_subr.c Wed Feb 29 14:50:17 2012
(r232298)
+++ head/sys/fs/nullfs/null_subr.c Wed Feb 29 15:06:00 2012
(r232299)
@@ -169,17 +169,26 @@ null_hashins(mp, xp)
}
static void
-null_insmntque_dtr(struct vnode *vp, void *xp)
+null_destroy_proto(struct vnode *vp, void *xp)
{
- vput(((struct null_node *)xp)->null_lowervp);
+ VI_LOCK(vp);
vp->v_data = NULL;
vp->v_vnlock = &vp->v_lock;
- free(xp, M_NULLFSNODE);
vp->v_op = &dead_vnodeops;
+ VI_UNLOCK(vp);
(void) vn_lock(vp, LK_EXCLUSIVE | LK_RETRY);
vgone(vp);
vput(vp);
+ free(xp, M_NULLFSNODE);
+}
+
+static void
+null_insmntque_dtr(struct vnode *vp, void *xp)
+{
+
+ vput(((struct null_node *)xp)->null_lowervp);
+ null_destroy_proto(vp, xp);
}
/*
@@ -247,9 +256,7 @@ null_nodeget(mp, lowervp, vpp)
*vpp = null_hashins(mp, xp);
if (*vpp != NULL) {
vrele(lowervp);
- vp->v_vnlock = &vp->v_lock;
- xp->null_lowervp = NULL;
- vrele(vp);
+ null_destroy_proto(vp, xp);
return (0);
}
*vpp = vp;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r232300 - head/usr.bin/procstat
Author: pluknet Date: Wed Feb 29 15:06:40 2012 New Revision: 232300 URL: http://svn.freebsd.org/changeset/base/232300 Log: Update the description for -s flag after r232182. When displaying security credential information show also process umask. X-MFC-with: r232182 Modified: head/usr.bin/procstat/procstat.1 Modified: head/usr.bin/procstat/procstat.1 == --- head/usr.bin/procstat/procstat.1Wed Feb 29 15:06:00 2012 (r232299) +++ head/usr.bin/procstat/procstat.1Wed Feb 29 15:06:40 2012 (r232300) @@ -25,7 +25,7 @@ .\" .\" $FreeBSD$ .\" -.Dd November 28, 2011 +.Dd February 29, 2012 .Dt PROCSTAT 1 .Os .Sh NAME @@ -329,6 +329,8 @@ effective group ID real group ID .It SVGID saved group ID +.It UMASK +file creation mode mask .It FLAGS credential flags .It GROUPS ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r232301 - head/sys/fs/nullfs
Author: kib
Date: Wed Feb 29 15:09:20 2012
New Revision: 232301
URL: http://svn.freebsd.org/changeset/base/232301
Log:
Always request exclusive lock for the lower vnode in nullfs_vget().
The null_nodeget() requires exclusive lock on lowervp to be able to
insmntque() new vnode.
Reported by: rea
Tested by:pho
MFC after:1 week
Modified:
head/sys/fs/nullfs/null_vfsops.c
Modified: head/sys/fs/nullfs/null_vfsops.c
==
--- head/sys/fs/nullfs/null_vfsops.cWed Feb 29 15:06:40 2012
(r232300)
+++ head/sys/fs/nullfs/null_vfsops.cWed Feb 29 15:09:20 2012
(r232301)
@@ -312,6 +312,12 @@ nullfs_vget(mp, ino, flags, vpp)
struct vnode **vpp;
{
int error;
+
+ KASSERT((flags & LK_TYPE_MASK) != 0,
+ ("nullfs_vget: no lock requested"));
+ flags &= ~LK_TYPE_MASK;
+ flags |= LK_EXCLUSIVE;
+
error = VFS_VGET(MOUNTTONULLMOUNT(mp)->nullm_vfs, ino, flags, vpp);
if (error)
return (error);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r232303 - head/sys/fs/nullfs
Author: kib
Date: Wed Feb 29 15:15:36 2012
New Revision: 232303
URL: http://svn.freebsd.org/changeset/base/232303
Log:
In null_reclaim(), assert that reclaimed vnode is fully constructed,
instead of accepting half-constructed vnode. Previous code cannot decide
what to do with such vnode anyway, and although processing it for hash
removal, paniced later when getting rid of nullfs reference on lowervp.
While there, remove initializations from the declaration block.
Tested by:pho
MFC after:1 week
Modified:
head/sys/fs/nullfs/null_vnops.c
Modified: head/sys/fs/nullfs/null_vnops.c
==
--- head/sys/fs/nullfs/null_vnops.c Wed Feb 29 15:10:34 2012
(r232302)
+++ head/sys/fs/nullfs/null_vnops.c Wed Feb 29 15:15:36 2012
(r232303)
@@ -697,12 +697,18 @@ null_inactive(struct vop_inactive_args *
static int
null_reclaim(struct vop_reclaim_args *ap)
{
- struct vnode *vp = ap->a_vp;
- struct null_node *xp = VTONULL(vp);
- struct vnode *lowervp = xp->null_lowervp;
+ struct vnode *vp;
+ struct null_node *xp;
+ struct vnode *lowervp;
+
+ vp = ap->a_vp;
+ xp = VTONULL(vp);
+ lowervp = xp->null_lowervp;
+
+ KASSERT(lowervp != NULL && vp->v_vnlock != &vp->v_lock,
+ ("Reclaiming inclomplete null vnode %p", vp));
- if (lowervp)
- null_hashrem(xp);
+ null_hashrem(xp);
/*
* Use the interlock to protect the clearing of v_data to
* prevent faults in null_lock().
@@ -713,10 +719,7 @@ null_reclaim(struct vop_reclaim_args *ap
vp->v_object = NULL;
vp->v_vnlock = &vp->v_lock;
VI_UNLOCK(vp);
- if (lowervp)
- vput(lowervp);
- else
- panic("null_reclaim: reclaiming a node with no lowervp");
+ vput(lowervp);
free(xp, M_NULLFSNODE);
return (0);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r232304 - head/sys/fs/nullfs
Author: kib
Date: Wed Feb 29 15:18:04 2012
New Revision: 232304
URL: http://svn.freebsd.org/changeset/base/232304
Log:
Document that null_nodeget() cannot take shared-locked lowervp due to
insmntque() requirements.
Tested by:pho
MFC after:1 week
Modified:
head/sys/fs/nullfs/null_subr.c
Modified: head/sys/fs/nullfs/null_subr.c
==
--- head/sys/fs/nullfs/null_subr.c Wed Feb 29 15:15:36 2012
(r232303)
+++ head/sys/fs/nullfs/null_subr.c Wed Feb 29 15:18:04 2012
(r232304)
@@ -209,7 +209,11 @@ null_nodeget(mp, lowervp, vpp)
struct vnode *vp;
int error;
- ASSERT_VOP_LOCKED(lowervp, "lowervp");
+ /*
+* The insmntque1() call below requires the exclusive lock on
+* the nullfs vnode.
+*/
+ ASSERT_VOP_ELOCKED(lowervp, "lowervp");
KASSERT(lowervp->v_usecount >= 1, ("Unreferenced vnode %p\n", lowervp));
/* Lookup the hash firstly */
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r232305 - head/sys/fs/nullfs
Author: kib Date: Wed Feb 29 15:18:53 2012 New Revision: 232305 URL: http://svn.freebsd.org/changeset/base/232305 Log: Allow shared locks for reads when lower filesystem accept shared locking. Tested by:pho MFC after:1 week Modified: head/sys/fs/nullfs/null_vfsops.c Modified: head/sys/fs/nullfs/null_vfsops.c == --- head/sys/fs/nullfs/null_vfsops.cWed Feb 29 15:18:04 2012 (r232304) +++ head/sys/fs/nullfs/null_vfsops.cWed Feb 29 15:18:53 2012 (r232305) @@ -185,7 +185,8 @@ nullfs_mount(struct mount *mp) MNT_IUNLOCK(mp); } MNT_ILOCK(mp); - mp->mnt_kern_flag |= lowerrootvp->v_mount->mnt_kern_flag & MNTK_MPSAFE; + mp->mnt_kern_flag |= lowerrootvp->v_mount->mnt_kern_flag & + (MNTK_MPSAFE | MNTK_SHARED_WRITES); MNT_IUNLOCK(mp); mp->mnt_data = xmp; vfs_getnewfsid(mp); ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r232181 - in head/sys: kern sys
On Wednesday, February 29, 2012 8:25:07 am Konstantin Belousov wrote: > On Wed, Feb 29, 2012 at 02:37:25PM +0200, Mikolaj Golub wrote: > > > > On Wed, 29 Feb 2012 12:03:00 + Robert N. M. Watson wrote: > > > > RNMW> I think the monitoring aspect of the patch is fine. > > > > RNMW> The bit I was worried about was external umask changes. This can > > cause > > RNMW> race conditions for applications that manage their umask -- for > > RNMW> example, bsdtar, if I recall correctly. It's one thing to use a > > RNMW> debugger to force an application to change its umask -- the developer > > RNMW> needs to know they are changing application behaviour. But exposing a > > RNMW> feature that can lead to correct applications but incorrect results > > is > > RNMW> a risky thing to do, hence my objection. > > > > RNMW> I think given the other objections, it would be wise to remove write > > RNMW> access to process umasks, but retain read access for procstat (which > > is > > RNMW> quite useful, I agree). > > > > I still don't see why having a sysctl RW is worse than asking users to run > > something like in the attach when they need to change umask for another > > process, but ok, if people don't like RW I will remove it. > > > What is done is attach is much worse then the sysctl, just because > debugger attach often causes spurious EINTR, indeed seriously disrupting > applications, as opposed to some uncertain damage that could be done in > theory. kgdb doesn't though, and presumably for umask you would change it via kgdb, so from the running process' perspective it would look the same as changing it via sysctl. -- John Baldwin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r232181 - in head/sys: kern sys
On Wed, Feb 29, 2012 at 09:36:02AM -0500, John Baldwin wrote: > On Wednesday, February 29, 2012 8:25:07 am Konstantin Belousov wrote: > > On Wed, Feb 29, 2012 at 02:37:25PM +0200, Mikolaj Golub wrote: > > > > > > On Wed, 29 Feb 2012 12:03:00 + Robert N. M. Watson wrote: > > > > > > RNMW> I think the monitoring aspect of the patch is fine. > > > > > > RNMW> The bit I was worried about was external umask changes. This can > > > cause > > > RNMW> race conditions for applications that manage their umask -- for > > > RNMW> example, bsdtar, if I recall correctly. It's one thing to use a > > > RNMW> debugger to force an application to change its umask -- the > > > developer > > > RNMW> needs to know they are changing application behaviour. But > > > exposing a > > > RNMW> feature that can lead to correct applications but incorrect > > > results is > > > RNMW> a risky thing to do, hence my objection. > > > > > > RNMW> I think given the other objections, it would be wise to remove > > > write > > > RNMW> access to process umasks, but retain read access for procstat > > > (which is > > > RNMW> quite useful, I agree). > > > > > > I still don't see why having a sysctl RW is worse than asking users to run > > > something like in the attach when they need to change umask for another > > > process, but ok, if people don't like RW I will remove it. > > > > > What is done is attach is much worse then the sysctl, just because > > debugger attach often causes spurious EINTR, indeed seriously disrupting > > applications, as opposed to some uncertain damage that could be done in > > theory. > > kgdb doesn't though, and presumably for umask you would change it via kgdb, so > from the running process' perspective it would look the same as changing it > via > sysctl. Right, but an idea of the change was to allow to do this for somebody who does not know how to perform it in kgdb. Not to mention that kgdb -w is risky, e.g. because filedesc might have changed under kgdb, so you would write over freed memory. pgp23htm50KdX.pgp Description: PGP signature
svn commit: r232307 - head/sys/fs/devfs
Author: mm
Date: Wed Feb 29 16:16:36 2012
New Revision: 232307
URL: http://svn.freebsd.org/changeset/base/232307
Log:
Add "export" to devfs_opts[] and return EOPNOTSUPP if called with it.
Fixes mountd warnings.
Reported by: kib
MFC after:1 week
Modified:
head/sys/fs/devfs/devfs_vfsops.c
Modified: head/sys/fs/devfs/devfs_vfsops.c
==
--- head/sys/fs/devfs/devfs_vfsops.cWed Feb 29 16:16:00 2012
(r232306)
+++ head/sys/fs/devfs/devfs_vfsops.cWed Feb 29 16:16:36 2012
(r232307)
@@ -58,7 +58,7 @@ static vfs_root_t devfs_root;
static vfs_statfs_tdevfs_statfs;
static const char *devfs_opts[] = {
- "from", "ruleset", NULL
+ "from", "export", "ruleset", NULL
};
/*
@@ -91,6 +91,9 @@ devfs_mount(struct mount *mp)
if (vfs_filteropt(mp->mnt_optnew, devfs_opts))
return (EINVAL);
+ if (vfs_flagopt(mp->mnt_optnew, "export", NULL, 0))
+ return (EOPNOTSUPP);
+
if (vfs_getopt(mp->mnt_optnew, "ruleset", NULL, NULL) == 0 &&
(vfs_scanopt(mp->mnt_optnew, "ruleset", "%d",
&rsnum) != 1 || rsnum < 0 || rsnum > 65535)) {
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r232308 - head/sys/xen/interface/io
Author: gibbs Date: Wed Feb 29 17:47:01 2012 New Revision: 232308 URL: http://svn.freebsd.org/changeset/base/232308 Log: blkif interface comment cleanups. No functional changes sys/xen/interface/io/blkif.h: o Insert space in "Red Hat". o Fix typo "discard-aligment" -> "discard-alignment" o Fix typo "unamp" -> "unmap" o Fix typo "formated" -> "formatted" o Clarify the text for "params". o Clarify the text for "sector-size". o Clarify the text for "max-requests" in the backend section. Modified: head/sys/xen/interface/io/blkif.h Modified: head/sys/xen/interface/io/blkif.h == --- head/sys/xen/interface/io/blkif.h Wed Feb 29 16:16:36 2012 (r232307) +++ head/sys/xen/interface/io/blkif.h Wed Feb 29 17:47:01 2012 (r232308) @@ -59,7 +59,7 @@ * All data in the XenStore is stored as strings. Nodes specifying numeric * values are encoded in decimal. Integer value ranges listed below are * expressed as fixed sized integer types capable of storing the conversion - * of a properly formated node string, without loss of information. + * of a properly formatted node string, without loss of information. * * Any specified default value is in effect if the corresponding XenBus node * is not present in the XenStore. @@ -67,6 +67,9 @@ * XenStore nodes in sections marked "PRIVATE" are solely for use by the * driver side whose XenBus tree contains them. * + * XenStore nodes marked "DEPRECATED" in their notes section should only be + * used to provide interoperability with legacy implementations. + * * See the XenBus state transition diagram below for details on when XenBus * nodes must be published and when they can be queried. * @@ -85,9 +88,9 @@ * params * Values: string * - * A free formatted string providing sufficient information for the - * backend driver to open the backing device. (e.g. the path to the - * file or block device representing the backing store.) + * Data used by the backend driver to locate and configure the backing + * device. The format and semantics of this data vary according to the + * backing device in use and are outside the scope of this specification. * * type * Values: "file", "phy", "tap" @@ -137,7 +140,7 @@ * max-ring-pages * Values: * Default Value: 1 - * Notes: 2, 3 + * Notes: DEPRECATED, 2, 3 * * The maximum supported size of the request ring buffer in units of * machine pages. The value must be a power of 2. @@ -146,8 +149,8 @@ * Default Value: BLKIF_MAX_RING_REQUESTS(PAGE_SIZE) * Maximum Value: BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages) * - * The maximum number of concurrent, logical requests that will be - * issued by the backend. + * The maximum number of concurrent, logical requests supported by + * the backend. * * Note: A logical request may span multiple ring entries. * @@ -170,7 +173,7 @@ * *- Backend Device Properties - * - * discard-aligment + * discard-alignment * Values: * Default Value: 0 * Notes: 4, 5 @@ -203,7 +206,8 @@ * sector-size * Values: * - * The native sector size, in bytes, of the backend device. + * The size, in bytes, of the individually addressible data blocks + * on the backend device. * * sectors * Values: @@ -234,8 +238,8 @@ * Values: * Notes: 6 * - * For a frontend providing a multi-page ring, a "num-ring-pages" sized - * list of nodes, each containing a Xen grant reference granting + * For a frontend providing a multi-page ring, a "number of ring pages" + * sized list of nodes, each containing a Xen grant reference granting * permission for the backend to map the page of the ring located * at page index "%u". Page indexes are zero based. * @@ -260,7 +264,7 @@ * Values: * Default Value: 1 * Maximum Value: MAX(max-ring-pages,(0x1 << max-ring-page-order)) - * Notes: 2, 3 + * Notes: DEPRECATED, 2, 3 * * The size of the frontend allocated request ring buffer in units of * machine pages. The value must be a power of 2. @@ -311,11 +315,11 @@ * - * (1) Multi-page ring buffer scheme first developed in the Citrix XenServer * PV drivers. - * (2) Multi-page ring buffer scheme first used in some RedHat distributions + * (2) Multi-page ring buffer scheme first used in some Red Hat distributions * including a distribution deployed on certain nodes of the Amazon * EC2 cluster. * (3) Support for multi-page ring buffers was implemented independently, - * in slightly different forms, by both Citrix and RedHat
svn commit: r232309 - head/sys/boot/i386/libi386
Author: jkim
Date: Wed Feb 29 18:11:33 2012
New Revision: 232309
URL: http://svn.freebsd.org/changeset/base/232309
Log:
Fix a long standing bug. The caller expects a non-zero value for success.
Luckily keyboard probing was turned off by default from the first revision.
Submitted by: Alexander Sack (asack at niksun dot com)
MFC after:3 days
Modified:
head/sys/boot/i386/libi386/vidconsole.c
Modified: head/sys/boot/i386/libi386/vidconsole.c
==
--- head/sys/boot/i386/libi386/vidconsole.c Wed Feb 29 17:47:01 2012
(r232308)
+++ head/sys/boot/i386/libi386/vidconsole.c Wed Feb 29 18:11:33 2012
(r232309)
@@ -623,10 +623,10 @@ probe_keyboard(void)
#endif
if (i == KBD_ECHO) {
/* got the right answer */
- return (0);
+ return (1);
}
}
-return (1);
+return (0);
}
#endif /* KEYBOARD_PROBE */
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r232309 - head/sys/boot/i386/libi386
On Wed, Feb 29, 2012 at 06:11:34PM +, Jung-uk Kim wrote: > Author: jkim > Date: Wed Feb 29 18:11:33 2012 > New Revision: 232309 > URL: http://svn.freebsd.org/changeset/base/232309 > > Log: > Fix a long standing bug. The caller expects a non-zero value for success. > Luckily keyboard probing was turned off by default from the first revision. Could it be related to the resume brokenesss I've reported earlier on -stable@, or this code path does not touch it? ./danfe ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r232309 - head/sys/boot/i386/libi386
On Wednesday 29 February 2012 01:23 pm, Alexey Dokuchaev wrote: > On Wed, Feb 29, 2012 at 06:11:34PM +, Jung-uk Kim wrote: > > Author: jkim > > Date: Wed Feb 29 18:11:33 2012 > > New Revision: 232309 > > URL: http://svn.freebsd.org/changeset/base/232309 > > > > Log: > > Fix a long standing bug. The caller expects a non-zero value > > for success. Luckily keyboard probing was turned off by default > > from the first revision. > > Could it be related to the resume brokenesss I've reported earlier > on -stable@, or this code path does not touch it? No. This is a loader fix and it is turned off by default as I noted. Jung-uk Kim ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r232311 - head/share/man/man5
Author: dim Date: Wed Feb 29 19:18:32 2012 New Revision: 232311 URL: http://svn.freebsd.org/changeset/base/232311 Log: Regenerate src.conf(5) after r231530 (and to correct a little screwup with the WITH_CLANG_EXTRAS fragment I added). Modified: head/share/man/man5/src.conf.5 Modified: head/share/man/man5/src.conf.5 == --- head/share/man/man5/src.conf.5 Wed Feb 29 18:41:59 2012 (r232310) +++ head/share/man/man5/src.conf.5 Wed Feb 29 19:18:32 2012 (r232311) @@ -1,7 +1,7 @@ .\" DO NOT EDIT-- this file is automatically generated. .\" from FreeBSD: head/tools/build/options/makeman 221733 2011-05-10 13:01:11Z ru .\" $FreeBSD$ -.Dd February 6, 2012 +.Dd February 29, 2012 .Dt SRC.CONF 5 .Os .Sh NAME @@ -284,7 +284,7 @@ Set to build the Clang C/C++ compiler. It is a default setting on amd64/amd64, i386/i386, pc98/i386, powerpc/powerpc and powerpc/powerpc64. .It Va WITH_CLANG_EXTRAS -.\" $FreeBSD$ +.\" from FreeBSD: head/tools/build/options/WITH_CLANG_EXTRAS 231057 2012-02-05 23:56:22Z dim Set to build additional clang and llvm tools, such as bugpoint. .It Va WITHOUT_CPP .\" from FreeBSD: head/tools/build/options/WITHOUT_CPP 156932 2006-03-21 07:50:50Z ru @@ -956,7 +956,7 @@ When set, it also enforces the following .\" from FreeBSD: head/tools/build/options/WITHOUT_USB 156932 2006-03-21 07:50:50Z ru Set to not build USB-related programs and libraries. .It Va WITHOUT_UTMPX -.\" from FreeBSD: head/tools/build/options/WITHOUT_UTMPX 230060 2012-01-13 15:40:49Z ed +.\" from FreeBSD: head/tools/build/options/WITHOUT_UTMPX 231530 2012-02-11 20:28:42Z ed Set to not build user accounting tools such as .Xr last 1 , .Xr users 1 , @@ -964,7 +964,7 @@ Set to not build user accounting tools s .Xr ac 8 , .Xr lastlogin 8 and -.Xr utxrm 8 . +.Xr utx 8 . .It Va WITHOUT_WIRELESS .\" from FreeBSD: head/tools/build/options/WITHOUT_WIRELESS 183242 2008-09-21 22:02:26Z sam Set to not build programs used for 802.11 wireless networks; especially ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r232312 - head/tools/regression/security/cap_test
Author: brueffer Date: Wed Feb 29 19:50:49 2012 New Revision: 232312 URL: http://svn.freebsd.org/changeset/base/232312 Log: Fix order of arguments to lseek(). PR: 160867 Submitted by: Henning Petersen MFC after:1 week Modified: head/tools/regression/security/cap_test/cap_test_capmode.c Modified: head/tools/regression/security/cap_test/cap_test_capmode.c == --- head/tools/regression/security/cap_test/cap_test_capmode.c Wed Feb 29 19:18:32 2012(r232311) +++ head/tools/regression/security/cap_test/cap_test_capmode.c Wed Feb 29 19:50:49 2012(r232312) @@ -117,7 +117,7 @@ test_capmode(void) CHECK_SYSCALL_SUCCEEDS(close, fd_close); CHECK_SYSCALL_SUCCEEDS(dup, fd_file); CHECK_SYSCALL_SUCCEEDS(fstat, fd_file, &sb); - CHECK_SYSCALL_SUCCEEDS(lseek, fd_file, SEEK_SET, 0); + CHECK_SYSCALL_SUCCEEDS(lseek, fd_file, 0, SEEK_SET); CHECK_SYSCALL_SUCCEEDS(msync, &fd_file, 8192, MS_ASYNC); CHECK_SYSCALL_SUCCEEDS(profil, NULL, 0, 0, 0); CHECK_SYSCALL_SUCCEEDS(read, fd_file, &ch, sizeof(ch)); ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r232313 - head/share/misc
Author: pluknet Date: Wed Feb 29 20:13:53 2012 New Revision: 232313 URL: http://svn.freebsd.org/changeset/base/232313 Log: Add myself, and show marck@ as my mentor. Approved by: marck (mentor) Modified: head/share/misc/committers-doc.dot Modified: head/share/misc/committers-doc.dot == --- head/share/misc/committers-doc.dot Wed Feb 29 19:50:49 2012 (r232312) +++ head/share/misc/committers-doc.dot Wed Feb 29 20:13:53 2012 (r232313) @@ -72,6 +72,7 @@ maxim [label="Maxim Konovalov\nmaxim@Fre miwi [label="Martin Wilke\nm...@freebsd.org\n2007/10/26"] murray [label="Murray Stokely\nmur...@freebsd.org\n2000/04/05"] pav [label="Pav Lucistnik\n...@freebsd.org\n2005/08/12"] +pluknet [label="Sergey Kandaurov\npluk...@freebsd.org\n2012/02/14"] remko [label="Remko Lodder\nre...@freebsd.org\n2004/10/16"] rene [label="Rene Ladan\nr...@freebsd.org\n2008/11/03"] roam [label="Peter Pentchev\nr...@freebsd.org\n2003/02/14"] @@ -129,6 +130,7 @@ keramida -> gjb keramida -> pav marck -> bvs +marck -> pluknet marck -> taras maxim -> taras ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r232315 - head/sys/net
Author: thompsa
Date: Wed Feb 29 20:58:21 2012
New Revision: 232315
URL: http://svn.freebsd.org/changeset/base/232315
Log:
Use a more appropriate default for the maximum number of addresses in the
bridge forwarding table.
PR: docs/164564
Discussed with: brueffer
Modified:
head/sys/net/if_bridge.c
Modified: head/sys/net/if_bridge.c
==
--- head/sys/net/if_bridge.cWed Feb 29 20:22:45 2012(r232314)
+++ head/sys/net/if_bridge.cWed Feb 29 20:58:21 2012(r232315)
@@ -144,10 +144,10 @@ __FBSDID("$FreeBSD$");
#defineBRIDGE_RTHASH_MASK (BRIDGE_RTHASH_SIZE - 1)
/*
- * Maximum number of addresses to cache.
+ * Default maximum number of addresses to cache.
*/
#ifndef BRIDGE_RTABLE_MAX
-#defineBRIDGE_RTABLE_MAX 100
+#defineBRIDGE_RTABLE_MAX 2000
#endif
/*
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r232316 - head/sbin/ifconfig
Author: brueffer Date: Wed Feb 29 21:11:02 2012 New Revision: 232316 URL: http://svn.freebsd.org/changeset/base/232316 Log: Update bridge(4) default values. PR: 164564 Submitted by: "Rudy (bulk)" MFC after:2 weeks Modified: head/sbin/ifconfig/ifconfig.8 Modified: head/sbin/ifconfig/ifconfig.8 == --- head/sbin/ifconfig/ifconfig.8 Wed Feb 29 20:58:21 2012 (r232315) +++ head/sbin/ifconfig/ifconfig.8 Wed Feb 29 21:11:02 2012 (r232316) @@ -28,7 +28,7 @@ .\" From: @(#)ifconfig.8 8.3 (Berkeley) 1/5/94 .\" $FreeBSD$ .\" -.Dd January 4, 2012 +.Dd February 29, 2012 .Dt IFCONFIG 8 .Os .Sh NAME @@ -2106,7 +2106,7 @@ it is removed from the bridge. .It Cm maxaddr Ar size Set the size of the bridge address cache to .Ar size . -The default is 100 entries. +The default is 2000 entries. .It Cm timeout Ar seconds Set the timeout of address cache entries to .Ar seconds @@ -2114,7 +2114,7 @@ seconds. If .Ar seconds is zero, then address cache entries will not be expired. -The default is 240 seconds. +The default is 1200 seconds. .It Cm addr Display the addresses that have been learned by the bridge. .It Cm static Ar interface-name Ar address ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r232317 - in head: . sys/kern sys/sys
Author: trociny
Date: Wed Feb 29 21:38:31 2012
New Revision: 232317
URL: http://svn.freebsd.org/changeset/base/232317
Log:
Introduce VOP_UNP_BIND(), VOP_UNP_CONNECT(), and VOP_UNP_DETACH()
operations for setting and accessing vnode's v_socket field.
The operations are necessary to implement proper unix socket handling
on layered file systems like nullfs(5).
This change fixes the long standing issue with nullfs(5) being in that
unix sockets did not work between lower and upper layers: if we bound
to a socket on the lower layer we could connect only to the lower
path; if we bound to the upper layer we could connect only to the
upper path. The new behavior is one can connect to both the lower and
the upper paths regardless what layer path one binds to.
PR: kern/51583, kern/159663
Suggested by: kib
Reviewed by: arch
MFC after:2 weeks
Modified:
head/UPDATING
head/sys/kern/uipc_usrreq.c
head/sys/kern/vfs_default.c
head/sys/kern/vnode_if.src
head/sys/sys/vnode.h
Modified: head/UPDATING
==
--- head/UPDATING Wed Feb 29 21:11:02 2012(r232316)
+++ head/UPDATING Wed Feb 29 21:38:31 2012(r232317)
@@ -22,6 +22,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 10
machines to maximize performance. (To disable malloc debugging, run
ln -s aj /etc/malloc.conf.)
+20120229:
+ Now unix domain sockets behave "as expected" on nullfs(5). Previously
+ nullfs(5) did not pass through all behaviours to the underlying layer,
+ as a result if we bound to a socket on the lower layer we could connect
+ only to the lower path; if we bound to the upper layer we could connect
+ only to the upper path. The new behavior is one can connect to both the
+ lower and the upper paths regardless what layer path one binds to.
+
20120211:
The getifaddrs upgrade path broken with 20111215 has been restored.
If you have upgraded in between 20111215 and 20120209 you need to
Modified: head/sys/kern/uipc_usrreq.c
==
--- head/sys/kern/uipc_usrreq.c Wed Feb 29 21:11:02 2012(r232316)
+++ head/sys/kern/uipc_usrreq.c Wed Feb 29 21:38:31 2012(r232317)
@@ -542,7 +542,7 @@ restart:
UNP_LINK_WLOCK();
UNP_PCB_LOCK(unp);
- vp->v_socket = unp->unp_socket;
+ VOP_UNP_BIND(vp, unp->unp_socket);
unp->unp_vnode = vp;
unp->unp_addr = soun;
unp->unp_flags &= ~UNP_BINDING;
@@ -638,7 +638,7 @@ uipc_detach(struct socket *so)
* XXXRW: Should assert vp->v_socket == so.
*/
if ((vp = unp->unp_vnode) != NULL) {
- unp->unp_vnode->v_socket = NULL;
+ VOP_UNP_DETACH(vp);
unp->unp_vnode = NULL;
}
unp2 = unp->unp_conn;
@@ -1308,7 +1308,7 @@ unp_connect(struct socket *so, struct so
* and to protect simultaneous locking of multiple pcbs.
*/
UNP_LINK_WLOCK();
- so2 = vp->v_socket;
+ VOP_UNP_CONNECT(vp, &so2);
if (so2 == NULL) {
error = ECONNREFUSED;
goto bad2;
@@ -2318,17 +2318,15 @@ vfs_unp_reclaim(struct vnode *vp)
active = 0;
UNP_LINK_WLOCK();
- so = vp->v_socket;
+ VOP_UNP_CONNECT(vp, &so);
if (so == NULL)
goto done;
unp = sotounpcb(so);
if (unp == NULL)
goto done;
UNP_PCB_LOCK(unp);
- if (unp->unp_vnode != NULL) {
- KASSERT(unp->unp_vnode == vp,
- ("vfs_unp_reclaim: vp != unp->unp_vnode"));
- vp->v_socket = NULL;
+ if (unp->unp_vnode == vp) {
+ VOP_UNP_DETACH(vp);
unp->unp_vnode = NULL;
active = 1;
}
Modified: head/sys/kern/vfs_default.c
==
--- head/sys/kern/vfs_default.c Wed Feb 29 21:11:02 2012(r232316)
+++ head/sys/kern/vfs_default.c Wed Feb 29 21:38:31 2012(r232317)
@@ -123,6 +123,9 @@ struct vop_vector default_vnodeops = {
.vop_unlock = vop_stdunlock,
.vop_vptocnp = vop_stdvptocnp,
.vop_vptofh = vop_stdvptofh,
+ .vop_unp_bind = vop_stdunp_bind,
+ .vop_unp_connect = vop_stdunp_connect,
+ .vop_unp_detach = vop_stdunp_detach,
};
/*
@@ -1037,6 +1040,30 @@ vop_stdadvise(struct vop_advise_args *ap
return (error);
}
+int
+vop_stdunp_bind(struct vop_unp_bind_args *ap)
+{
+
+ ap->a_vp->v_socket = ap->a_socket;
+ return (0);
+}
+
+int
+vop_stdunp_connect(struct vop_unp_connect_args *ap)
+{
+
+ *ap->a_socket = ap->a_vp->v_socke
svn commit: r232318 - head/sys/dev/pci
Author: jhb
Date: Wed Feb 29 22:06:44 2012
New Revision: 232318
URL: http://svn.freebsd.org/changeset/base/232318
Log:
Use pci_printf() instead of a home-rolled version in the VPD parsing code.
Modified:
head/sys/dev/pci/pci.c
Modified: head/sys/dev/pci/pci.c
==
--- head/sys/dev/pci/pci.c Wed Feb 29 21:38:31 2012(r232317)
+++ head/sys/dev/pci/pci.c Wed Feb 29 22:06:44 2012(r232318)
@@ -878,10 +878,9 @@ pci_read_vpd(device_t pcib, pcicfgregs *
remain |= byte2 << 8;
if (remain > (0x7f*4 - vrs.off)) {
state = -1;
- printf(
- "pci%d:%d:%d:%d: invalid VPD data, remain %#x\n",
- cfg->domain, cfg->bus, cfg->slot,
- cfg->func, remain);
+ pci_printf(cfg,
+ "invalid VPD data, remain %#x\n",
+ remain);
}
name = byte & 0x7f;
} else {
@@ -953,10 +952,8 @@ pci_read_vpd(device_t pcib, pcicfgregs *
* if this happens, we can't trust the rest
* of the VPD.
*/
- printf(
- "pci%d:%d:%d:%d: bad keyword length: %d\n",
- cfg->domain, cfg->bus, cfg->slot,
- cfg->func, dflen);
+ pci_printf(cfg, "bad keyword length: %d\n",
+ dflen);
cksumvalid = 0;
state = -1;
break;
@@ -989,10 +986,8 @@ pci_read_vpd(device_t pcib, pcicfgregs *
cksumvalid = 1;
else {
if (bootverbose)
- printf(
- "pci%d:%d:%d:%d: bad VPD cksum, remain %hhu\n",
- cfg->domain, cfg->bus,
- cfg->slot, cfg->func,
+ pci_printf(cfg,
+ "bad VPD cksum, remain %hhu\n",
vrs.cksum);
cksumvalid = 0;
state = -1;
@@ -1070,9 +1065,7 @@ pci_read_vpd(device_t pcib, pcicfgregs *
break;
default:
- printf("pci%d:%d:%d:%d: invalid state: %d\n",
- cfg->domain, cfg->bus, cfg->slot, cfg->func,
- state);
+ pci_printf(cfg, "invalid state: %d\n", state);
state = -1;
break;
}
@@ -1089,8 +1082,7 @@ pci_read_vpd(device_t pcib, pcicfgregs *
}
if (state < -1) {
/* I/O error, clean up */
- printf("pci%d:%d:%d:%d: failed to read VPD data.\n",
- cfg->domain, cfg->bus, cfg->slot, cfg->func);
+ pci_printf(cfg, "failed to read VPD data.\n");
if (cfg->vpd.vpd_ident != NULL) {
free(cfg->vpd.vpd_ident, M_DEVBUF);
cfg->vpd.vpd_ident = NULL;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r232320 - head/usr.bin/csup
Author: cognet
Date: Wed Feb 29 22:35:09 2012
New Revision: 232320
URL: http://svn.freebsd.org/changeset/base/232320
Log:
Use srandom() to init the PRNG, not srand(), since we use random().
This is harmless because srandom() is called somewhere else, with time(NULL)
as a seed, but this is more correct.
Obtained from:https://bitbucket.org/mux/csup
Pointyhat to: not mux, somebody else
MFC after:1 week
Modified:
head/usr.bin/csup/auth.c
Modified: head/usr.bin/csup/auth.c
==
--- head/usr.bin/csup/auth.cWed Feb 29 22:21:58 2012(r232319)
+++ head/usr.bin/csup/auth.cWed Feb 29 22:35:09 2012(r232320)
@@ -293,7 +293,7 @@ auth_makechallenge(struct config *config
gettimeofday(&tv, NULL);
pid = getpid();
ppid = getppid();
- srand(tv.tv_usec ^ tv.tv_sec ^ pid);
+ srandom(tv.tv_usec ^ tv.tv_sec ^ pid);
addrlen = sizeof(laddr);
error = getsockname(config->socket, (struct sockaddr *)&laddr,
&addrlen);
if (error < 0) {
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r232321 - head/share/man/man9
Author: thompsa Date: Wed Feb 29 22:41:40 2012 New Revision: 232321 URL: http://svn.freebsd.org/changeset/base/232321 Log: Correct the description for CTLFLAG_TUN and CTLFLAG_RDTUN, the declaring of a system tunable has never been implemented. This flag is only used by sysctl(8) to provide a helpful error message. Discussed with: dwhite, kan Modified: head/share/man/man9/sysctl.9 Modified: head/share/man/man9/sysctl.9 == --- head/share/man/man9/sysctl.9Wed Feb 29 22:35:09 2012 (r232320) +++ head/share/man/man9/sysctl.9Wed Feb 29 22:41:40 2012 (r232321) @@ -138,9 +138,9 @@ This sysctl can be written to by process .It Dv CTLFLAG_SKIP When iterating the sysctl name space, do not list this sysctl. .It Dv CTLFLAG_TUN -Also declare a system tunable with the same name to initialize this variable. +Advisory flag that a system tunable also exists for this variable. .It Dv CTLFLAG_RDTUN -Also declare a system tunable with the same name to initialize this variable; +Advisory flag that a system tunable also exists for this variable; however, the run-time variable is read-only. .El .Pp ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r232322 - in head: . gnu/usr.bin/cc/c++ gnu/usr.bin/cc/cc gnu/usr.bin/cc/cpp share/mk sys/conf tools/build/options usr.bin/clang/clang
Author: dim
Date: Wed Feb 29 22:58:51 2012
New Revision: 232322
URL: http://svn.freebsd.org/changeset/base/232322
Log:
Add a WITH_CLANG_IS_CC option for src.conf(5), disabled by default, that
installs clang as /usr/bin/cc, /usr/bin/c++ and /usr/bin/cpp.
Note this does *not* disable building and installing gcc, which will
still be available as /usr/bin/gcc, /usr/bin/g++ and /usr/bin/gcpp. If
you want to disable gcc completely, you must use WITHOUT_GCC.
MFC after:2 weeks
Added:
head/gnu/usr.bin/cc/cpp/gcpp.1
- copied unchanged from r232312, head/contrib/gcc/doc/cpp.1
head/tools/build/options/WITH_CLANG_IS_CC (contents, props changed)
Modified:
head/Makefile.inc1
head/gnu/usr.bin/cc/c++/Makefile
head/gnu/usr.bin/cc/cc/Makefile
head/gnu/usr.bin/cc/cpp/Makefile
head/share/mk/bsd.own.mk
head/share/mk/bsd.sys.mk
head/sys/conf/kern.mk
head/sys/conf/kern.pre.mk
head/sys/conf/kmod.mk
head/usr.bin/clang/clang/Makefile
Modified: head/Makefile.inc1
==
--- head/Makefile.inc1 Wed Feb 29 22:41:40 2012(r232321)
+++ head/Makefile.inc1 Wed Feb 29 22:58:51 2012(r232322)
@@ -1108,6 +1108,10 @@ _aicasm= sys/modules/aic7xxx/aicasm
_share=share/syscons/scrnmaps
.endif
+.if ${MK_GCC} != "no" && (${MK_CLANG_IS_CC} == "no" && ${CC:T:Mclang} !=
"clang")
+_gcc_tools= gnu/usr.bin/cc/cc_tools
+.endif
+
.if ${MK_KERBEROS} != "no"
_kerberos5_tools= kerberos5/tools
.endif
@@ -1136,7 +1140,7 @@ build-tools:
${MAKE} DIRPRFX=${_tool}/ build-tools
.endfor
.for _tool in \
-gnu/usr.bin/cc/cc_tools \
+${_gcc_tools} \
${_kerberos5_tools}
${_+_}@${ECHODIR} "===> ${_tool} (obj,depend,all)"; \
cd ${.CURDIR}/${_tool}; \
@@ -1166,14 +1170,12 @@ _kgzip= usr.sbin/kgzip
_binutils= gnu/usr.bin/binutils
.endif
-.if ${MK_CLANG} != "no"
-.if ${CC:T:Mclang} == "clang"
+.if ${MK_CLANG} != "no" && (${MK_CLANG_IS_CC} != "no" || ${CC:T:Mclang} ==
"clang")
_clang=usr.bin/clang
_clang_libs= lib/clang
.endif
-.endif
-.if ${MK_GCC} != "no"
+.if ${MK_GCC} != "no" && (${MK_CLANG_IS_CC} == "no" && ${CC:T:Mclang} !=
"clang")
_cc= gnu/usr.bin/cc
.endif
Modified: head/gnu/usr.bin/cc/c++/Makefile
==
--- head/gnu/usr.bin/cc/c++/MakefileWed Feb 29 22:41:40 2012
(r232321)
+++ head/gnu/usr.bin/cc/c++/MakefileWed Feb 29 22:58:51 2012
(r232322)
@@ -1,14 +1,18 @@
# $FreeBSD$
+.include
+
.include "../Makefile.inc"
.include "../Makefile.fe"
.PATH: ${GCCDIR}/cp
-PROG= c++
+PROG= g++
SRCS+= g++spec.c
-LINKS= ${BINDIR}/c++ ${BINDIR}/g++
-LINKS+=${BINDIR}/c++ ${BINDIR}/CC
+.if ${MK_CLANG_IS_CC} == "no"
+LINKS= ${BINDIR}/g++ ${BINDIR}/c++
+LINKS+=${BINDIR}/g++ ${BINDIR}/CC
+.endif
NO_MAN=
DPADD= ${LIBCPP} ${LIBIBERTY}
Modified: head/gnu/usr.bin/cc/cc/Makefile
==
--- head/gnu/usr.bin/cc/cc/Makefile Wed Feb 29 22:41:40 2012
(r232321)
+++ head/gnu/usr.bin/cc/cc/Makefile Wed Feb 29 22:58:51 2012
(r232322)
@@ -1,15 +1,20 @@
# $FreeBSD$
+.include
+
.include "../Makefile.inc"
.include "../Makefile.fe"
-PROG= cc
+PROG= gcc
MAN= gcc.1
SRCS+= gccspec.c
NO_SHARED?=yes
-LINKS= ${BINDIR}/cc ${BINDIR}/gcc
-MLINKS=gcc.1 cc.1 gcc.1 c++.1 gcc.1 g++.1 gcc.1 CC.1
+MLINKS=gcc.1 g++.1
+.if ${MK_CLANG_IS_CC} == "no"
+LINKS= ${BINDIR}/gcc ${BINDIR}/cc
+MLINKS+= gcc.1 cc.1 gcc.1 c++.1 gcc.1 CC.1
+.endif
.include
Modified: head/gnu/usr.bin/cc/cpp/Makefile
==
--- head/gnu/usr.bin/cc/cpp/MakefileWed Feb 29 22:41:40 2012
(r232321)
+++ head/gnu/usr.bin/cc/cpp/MakefileWed Feb 29 22:58:51 2012
(r232322)
@@ -1,10 +1,16 @@
# $FreeBSD$
+.include
.include "../Makefile.inc"
.include "../Makefile.fe"
-PROG= cpp
+PROG= gcpp
SRCS+= cppspec.c
+.if ${MK_CLANG_IS_CC} == "no"
+LINKS= ${BINDIR}/gcpp ${BINDIR}/cpp
+MLINKS=gcpp.1 cpp.1
+.endif
+
.include
Copied: head/gnu/usr.bin/cc/cpp/gcpp.1 (from r232312,
head/contrib/gcc/doc/cpp.1)
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/gnu/usr.bin/cc/cpp/gcpp.1 Wed Feb 29 22:58:51 2012
(r232322, copy of r232312, head/contrib/gcc/doc/cpp.1)
@@ -0,0 +1,929 @@
+.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14
+.\"
+.\" Standard preamble:
+.\"
+.de Sh \" Subsection heading
+.br
+.if t .Sp
+.ne 5
+.PP
+\fB\\$1\fR
+.PP
+..
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin
svn commit: r232323 - head/share/man/man5
Author: dim Date: Wed Feb 29 23:06:48 2012 New Revision: 232323 URL: http://svn.freebsd.org/changeset/base/232323 Log: Regenerate src.conf(5) after r232322. MFC after:2 weeks Modified: head/share/man/man5/src.conf.5 Modified: head/share/man/man5/src.conf.5 == --- head/share/man/man5/src.conf.5 Wed Feb 29 22:58:51 2012 (r232322) +++ head/share/man/man5/src.conf.5 Wed Feb 29 23:06:48 2012 (r232323) @@ -276,6 +276,8 @@ When set, it also enforces the following .Bl -item -compact .It .Va WITHOUT_CLANG_EXTRAS +.It +.Va WITHOUT_CLANG_IS_CC .El .It Va WITH_CLANG .\" from FreeBSD: head/tools/build/options/WITH_CLANG 221730 2011-05-10 11:14:40Z ru @@ -286,6 +288,15 @@ amd64/amd64, i386/i386, pc98/i386, power .It Va WITH_CLANG_EXTRAS .\" from FreeBSD: head/tools/build/options/WITH_CLANG_EXTRAS 231057 2012-02-05 23:56:22Z dim Set to build additional clang and llvm tools, such as bugpoint. +.It Va WITH_CLANG_IS_CC +.\" from FreeBSD: head/tools/build/options/WITH_CLANG_IS_CC 232322 2012-02-29 22:58:51Z dim +Set to install the Clang C/C++ compiler as +.Pa /usr/bin/cc +, +.Pa /usr/bin/c++ +and +.Pa /usr/bin/cpp +. .It Va WITHOUT_CPP .\" from FreeBSD: head/tools/build/options/WITHOUT_CPP 156932 2006-03-21 07:50:50Z ru Set to not build @@ -342,6 +353,8 @@ When set, it also enforces the following .It .Va WITHOUT_CLANG .It +.Va WITHOUT_CLANG_IS_CC +.It .Va WITHOUT_GROFF .El .It Va WITHOUT_DICT @@ -948,6 +961,8 @@ When set, it also enforces the following .It .Va WITHOUT_CLANG .It +.Va WITHOUT_CLANG_IS_CC +.It .Va WITHOUT_GCC .It .Va WITHOUT_GDB ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r232317 - in head: . sys/kern sys/sys
On 29. Feb 2012, at 21:38 , Mikolaj Golub wrote: > Author: trociny > Date: Wed Feb 29 21:38:31 2012 > New Revision: 232317 > URL: http://svn.freebsd.org/changeset/base/232317 > > Log: > Introduce VOP_UNP_BIND(), VOP_UNP_CONNECT(), and VOP_UNP_DETACH() > operations for setting and accessing vnode's v_socket field. > > The operations are necessary to implement proper unix socket handling > on layered file systems like nullfs(5). > > This change fixes the long standing issue with nullfs(5) being in that > unix sockets did not work between lower and upper layers: if we bound > to a socket on the lower layer we could connect only to the lower > path; if we bound to the upper layer we could connect only to the > upper path. The new behavior is one can connect to both the lower and > the upper paths regardless what layer path one binds to. At this point I wonder if jhb has added (enough) spares with an earlier MFC of another change or whether we'll break thing again? > > PR: kern/51583, kern/159663 > Suggested by:kib > Reviewed by: arch > MFC after: 2 weeks -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r232327 - in head/sys: fs/nfsclient nfsclient
Author: rmacklem
Date: Thu Mar 1 03:53:07 2012
New Revision: 232327
URL: http://svn.freebsd.org/changeset/base/232327
Log:
Fix the NFS clients so that they use copyin() instead of bcopy(),
when doing direct I/O. This direct I/O code is not enabled by default.
Submitted by: kib (earlier version)
Reviewed by: kib
MFC after:1 week
Modified:
head/sys/fs/nfsclient/nfs_clbio.c
head/sys/nfsclient/nfs_bio.c
Modified: head/sys/fs/nfsclient/nfs_clbio.c
==
--- head/sys/fs/nfsclient/nfs_clbio.c Thu Mar 1 00:54:08 2012
(r232326)
+++ head/sys/fs/nfsclient/nfs_clbio.c Thu Mar 1 03:53:07 2012
(r232327)
@@ -820,7 +820,21 @@ do_sync:
t_uio->uio_segflg = UIO_SYSSPACE;
t_uio->uio_rw = UIO_WRITE;
t_uio->uio_td = td;
- bcopy(uiop->uio_iov->iov_base, t_iov->iov_base, size);
+ KASSERT(uiop->uio_segflg == UIO_USERSPACE ||
+ uiop->uio_segflg == UIO_SYSSPACE,
+ ("nfs_directio_write: Bad uio_segflg"));
+ if (uiop->uio_segflg == UIO_USERSPACE) {
+ error = copyin(uiop->uio_iov->iov_base,
+ t_iov->iov_base, size);
+ if (error != 0)
+ goto err_free;
+ } else
+ /*
+* UIO_SYSSPACE may never happen, but handle
+* it just in case it does.
+*/
+ bcopy(uiop->uio_iov->iov_base, t_iov->iov_base,
+ size);
bp->b_flags |= B_DIRECT;
bp->b_iocmd = BIO_WRITE;
if (cred != NOCRED) {
@@ -831,6 +845,7 @@ do_sync:
bp->b_caller1 = (void *)t_uio;
bp->b_vp = vp;
error = ncl_asyncio(nmp, bp, NOCRED, td);
+err_free:
if (error) {
free(t_iov->iov_base, M_NFSDIRECTIO);
free(t_iov, M_NFSDIRECTIO);
Modified: head/sys/nfsclient/nfs_bio.c
==
--- head/sys/nfsclient/nfs_bio.cThu Mar 1 00:54:08 2012
(r232326)
+++ head/sys/nfsclient/nfs_bio.cThu Mar 1 03:53:07 2012
(r232327)
@@ -814,7 +814,21 @@ do_sync:
t_uio->uio_segflg = UIO_SYSSPACE;
t_uio->uio_rw = UIO_WRITE;
t_uio->uio_td = td;
- bcopy(uiop->uio_iov->iov_base, t_iov->iov_base, size);
+ KASSERT(uiop->uio_segflg == UIO_USERSPACE ||
+ uiop->uio_segflg == UIO_SYSSPACE,
+ ("nfs_directio_write: Bad uio_segflg"));
+ if (uiop->uio_segflg == UIO_USERSPACE) {
+ error = copyin(uiop->uio_iov->iov_base,
+ t_iov->iov_base, size);
+ if (error != 0)
+ goto err_free;
+ } else
+ /*
+* UIO_SYSSPACE may never happen, but handle
+* it just in case it does.
+*/
+ bcopy(uiop->uio_iov->iov_base, t_iov->iov_base,
+ size);
bp->b_flags |= B_DIRECT;
bp->b_iocmd = BIO_WRITE;
if (cred != NOCRED) {
@@ -825,6 +839,7 @@ do_sync:
bp->b_caller1 = (void *)t_uio;
bp->b_vp = vp;
error = nfs_asyncio(nmp, bp, NOCRED, td);
+err_free:
if (error) {
free(t_iov->iov_base, M_NFSDIRECTIO);
free(t_iov, M_NFSDIRECTIO);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r232317 - in head: . sys/kern sys/sys
On Wed, 29 Feb 2012 23:44:47 + Bjoern A. Zeeb wrote: BAZ> On 29. Feb 2012, at 21:38 , Mikolaj Golub wrote: >> Author: trociny >> Date: Wed Feb 29 21:38:31 2012 >> New Revision: 232317 >> URL: http://svn.freebsd.org/changeset/base/232317 >> >> Log: >> Introduce VOP_UNP_BIND(), VOP_UNP_CONNECT(), and VOP_UNP_DETACH() >> operations for setting and accessing vnode's v_socket field. >> >> The operations are necessary to implement proper unix socket handling >> on layered file systems like nullfs(5). >> >> This change fixes the long standing issue with nullfs(5) being in that >> unix sockets did not work between lower and upper layers: if we bound >> to a socket on the lower layer we could connect only to the lower >> path; if we bound to the upper layer we could connect only to the >> upper path. The new behavior is one can connect to both the lower and >> the upper paths regardless what layer path one binds to. BAZ> At this point I wonder if jhb has added (enough) spares with an earlier MFC of another change or whether we'll break thing again? That is why I asked about this on arch@ and was waiting several days for people opinion :-). The response I had was: do MFC if jhb does not have any plans for the vop spares (and he does not). I can change "MFC after" to 2 months or undef, and I will be fine with any other solution proposed. >> >> PR:kern/51583, kern/159663 >> Suggested by:kib >> Reviewed by:arch >> MFC after:2 weeks BAZ> -- BAZ> Bjoern A. Zeeb You have to have visions! BAZ>It does not matter how good you are. It matters what good you do! -- Mikolaj Golub ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r232321 - head/share/man/man9
On 01.03.2012 2:41, Andrew Thompson wrote: Author: thompsa Date: Wed Feb 29 22:41:40 2012 New Revision: 232321 URL: http://svn.freebsd.org/changeset/base/232321 Log: Correct the description for CTLFLAG_TUN and CTLFLAG_RDTUN, the declaring of a system tunable has never been implemented. This flag is only used by sysctl(8) to provide a helpful error message. Thanks! I also think we should remove all CTLFLAG_TUN flags which are combination with CTLFLAG_RW. -- Andrey Zonov ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
