Re: pf nat fails on msk0 from packets deriving from a jail interface
On 08/09/12 20:00, YongHyeon PYUN wrote: On Wed, Aug 08, 2012 at 02:33:25PM +0300, George Mamalakis wrote: Hi all, Suddenly I am facing a problem on a new PC, using a configuration that I have been using on more than 10 servers for the last few years. The only thing that I find that differs from my other configuratinos is the NIC of the PC. If not, I must be missing something very trivial. I have built a jail on this PC, following the handbook's guidelines (section: application of jails). The PC has one NIC, msk0, where I run pf on (built on my kernel; I have already tried using the module). My pf.conf is as simple as possible: # cat /etc/pf.conf nat on msk0 from any to any - 10.0.3.6 pass quick all when I jexec inside the jail, and pf is running, I am unable to reach any machine except my jail (not even the host). If pf is off, the network works just fine (of course my router knows where to find my jail's subnet). What is strange is that if I tcpdump on msk0, then after a few seconds that I request something from within the jail, I see the packets going and coming on msk0 using the correct IP (the NAT IP), but it seems that the machine fails to route them back inside the jail. I guess this is the same issue reported in kern/170081. Some msk(4) controllers lack full hardware checksum offloading capability such that pseudo checksum should be computed by upper layer. It seems pf(4) NAT was broken for controllers that lack pseudo checksumming. This indicates the following ethernet controller do not work with pf(4) NAT. sk(4), msk(4), fxp(4), hme(4) and gem(4) Try disabling RX checksum offloading as a work-around. #ifconfig msk0 -rxcsum You were absolutely right! Once I disabled RX checksum offloading -as you suggested- everything started working just fine. Since this issue has been reported already, I will not send a bug report. Thanx again! -- George Mamalakis IT and Security Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: lock violation in unionfs (9.0-STABLE r230270)
On 8/8/12, Harald Schmalzbauer h.schmalzba...@omnilan.de wrote:
schrieb Pavel Polyakov am 06.03.2012 11:20 (localtime):
mount -t unionfs -o noatime /usr /mnt
insmntque: mp-safe fs and non-locked vp: 0xfe01d96704f0 is not
exclusive locked but should be
KDB: enter: lock violation
Pavel,
can you give a spin to this patch?:
http://www.freebsd.org/~attilio/unionfs_missing_insmntque_lock.patch
I think that the unlocking is due at that point as the vnode lock can
be switch later on.
Let me know what you think about it and what the test does.
Thanks!
This patch fixes the problem with lock violation. Sorry I've tested it so
late.
Hello,
this patch still applies cleanly to RELENG_9_1. Was there another fix
for the issue or has it just not been PR-sent and thus forgotten?
Can you and Pavel try the attached patch? Unfortunately I had no time
to test it, I just made in 5 free mins from a non-FreeBSD workstation,
then you should be able to tell me if it works or not, even compiling
it on a RELENG_9_1.
Please try with INVARIANTS option on.
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
Index: sys/fs/unionfs/union_subr.c
===
--- sys/fs/unionfs/union_subr.c (revision 239152)
+++ sys/fs/unionfs/union_subr.c (working copy)
@@ -237,7 +237,8 @@ unionfs_nodeget(struct mount *mp, struct vnode *up
if (vp != NULLVP) {
vref(vp);
*vpp = vp;
- goto unionfs_nodeget_out;
+ lockmgr(vp-v_vnlock, LK_EXCLUSIVE, NULL);
+ return (0);
}
}
@@ -255,17 +256,19 @@ unionfs_nodeget(struct mount *mp, struct vnode *up
*/
unp = malloc(sizeof(struct unionfs_node),
M_UNIONFSNODE, M_WAITOK | M_ZERO);
+ if (path != NULL) {
+ unp-un_path = (char *)
+ malloc(cnp-cn_namelen +1, M_UNIONFSPATH, M_WAITOK|M_ZERO);
+ bcopy(cnp-cn_nameptr, unp-un_path, cnp-cn_namelen);
+ unp-un_path[cnp-cn_namelen] = '\0';
+ }
error = getnewvnode(unionfs, mp, unionfs_vnodeops, vp);
if (error != 0) {
+ free(unp-un_path, M_UNIONFSNODE);
free(unp, M_UNIONFSNODE);
return (error);
}
- error = insmntque(vp, mp); /* XXX: Too early for mpsafe fs */
- if (error != 0) {
- free(unp, M_UNIONFSNODE);
- return (error);
- }
if (dvp != NULLVP)
vref(dvp);
if (uppervp != NULLVP)
@@ -286,15 +289,22 @@ unionfs_nodeget(struct mount *mp, struct vnode *up
else
vp-v_vnlock = lowervp-v_vnlock;
- if (path != NULL) {
- unp-un_path = (char *)
- malloc(cnp-cn_namelen +1, M_UNIONFSPATH, M_WAITOK|M_ZERO);
- bcopy(cnp-cn_nameptr, unp-un_path, cnp-cn_namelen);
- unp-un_path[cnp-cn_namelen] = '\0';
- }
vp-v_type = vt;
vp-v_data = unp;
+ lockmgr(vp-v_vnlock, LK_EXCLUSIVE, NULL);
+ error = insmntque(vp, mp);
+ if (error != 0) {
+ if (dvp != NULLVP)
+ vrele(dvp);
+ if (uppervp != NULLVP)
+ vrele(uppervp);
+ if (lowervp != NULLVP)
+ vrele(lowervp);
+ free(unp-un_path, M_UNIONFSNODE);
+ free(unp, M_UNIONFSNODE);
+ return (error);
+ }
if ((uppervp != NULLVP ump-um_uppervp == uppervp)
(lowervp != NULLVP ump-um_lowervp == lowervp))
vp-v_vflag |= VV_ROOT;
@@ -317,11 +327,6 @@ unionfs_nodeget(struct mount *mp, struct vnode *up
vref(vp);
} else
*vpp = vp;
-
-unionfs_nodeget_out:
- if (lkflags LK_TYPE_MASK)
- vn_lock(vp, lkflags | LK_RETRY);
-
return (0);
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: lock violation in unionfs (9.0-STABLE r230270)
schrieb Attilio Rao am 09.08.2012 20:26 (localtime): On 8/8/12, Harald Schmalzbauer h.schmalzba...@omnilan.de wrote: schrieb Pavel Polyakov am 06.03.2012 11:20 (localtime): mount -t unionfs -o noatime /usr /mnt insmntque: mp-safe fs and non-locked vp: 0xfe01d96704f0 is not exclusive locked but should be KDB: enter: lock violation Pavel, can you give a spin to this patch?: http://www.freebsd.org/~attilio/unionfs_missing_insmntque_lock.patch I think that the unlocking is due at that point as the vnode lock can be switch later on. Let me know what you think about it and what the test does. Thanks! This patch fixes the problem with lock violation. Sorry I've tested it so late. Hello, this patch still applies cleanly to RELENG_9_1. Was there another fix for the issue or has it just not been PR-sent and thus forgotten? Can you and Pavel try the attached patch? Unfortunately I had no time to test it, I just made in 5 free mins from a non-FreeBSD workstation, then you should be able to tell me if it works or not, even compiling it on a RELENG_9_1. Please try with INVARIANTS option on Unfortunately I don't have a spare machine handy, but I ran a kernel compile job in our lab and at least I can confirm that it applies + compiles fine (i386 target on amd64, RELENG_9_1, options UNIONFS static included on a heavy-nodevice-over-GENERIC kernel). Thanks, -Harry P.S.: I'll have a nice testing machine vacant soon, so if no one else has time to test, I can come back in about 2 weeks with results. But that's far too late for 9.1-RELEASE I guess. signature.asc Description: OpenPGP digital signature
