Re: Re[2]: SMBFS panic: malloc: wrong bucket (was: 4.3-20010721-STABLE)
On Sat, 4 Aug 2001, Dimitry Andric wrote: Okay, this patch seems to solve the panic problem for me. On the previously crashing box, I cvsup'd today (to 4.4-PRERELEASE) and rebuilt everything, including the kernel with your patch, and the smbfs-1.4.1 port. Since then, I haven't been able to get it to crash anymore. :) (Keeping my fingers crossed.) Fine, then thats it! Many thanks to Conrad Minshall who found this bug. There is also some more fixes to merge from Darwin project. 1. When I mount_smbfs(8) a share, the mountpoint is owned by root:wheel and mode 755 by default. However, as a normal user I can _create_ files in this mountpoint, but not delete them! I would suppose that a normal user doesn't have write access with mode 755? Yes, this is a known bug and there is open PR on it. Fix is ready, and will be committed after I get access to that hard disk again. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: SMBFS panic: malloc: wrong bucket (was: 4.3-20010721-STABLE)
On Wed, 25 Jul 2001, Tim Zingelman wrote: This is a known bug, but not fixed. I worked with the maintainer, Boris Popov on it a little, but in my case it took some time between the mount and the panic, and I was not able to give him login access to the machines involved. As a result it remains unfixed. If you have a case that panics immediately and can work with him, I think he would be interested in getting this fixed. (I know I would :) Please try the attached patch. It fixes a nasty buffer overflow which may cause this panic. I'd recommend contacting the smbfs maintainer. It seems the kernel module for smbfs is now integrated into the main sources, but you still need to install a port. So I'm guessing it's now in some sort of transitional status (and thus quite unstable). Hear, hear :) All userland code for smbfs was planned to be included before 4.4 comes out. But, life is life - it has its own plans, and I hope to finish import after 4.4... -- Boris Popov http://www.butya.kz/~bp/ Index: smb.h === RCS file: /home/ncvs/src/sys/netsmb/smb.h,v retrieving revision 1.1.2.1 diff -u -r1.1.2.1 smb.h --- smb.h 2001/05/22 08:32:33 1.1.2.1 +++ smb.h 2001/08/03 13:32:25 @@ -68,7 +68,7 @@ */ #defineSMB_SIGNATURE \xFFSMB #defineSMB_SIGLEN 4 -#defineSMB_HDRMID(p) (*(u_short*)((u_char*)(p) + 30)) +#defineSMB_HDRMID(p) (letohs(*(u_short*)((u_char*)(p) + 30))) #defineSMB_HDRLEN 32 /* * bits in the smb_flags field Index: smb_crypt.c === RCS file: /home/ncvs/src/sys/netsmb/smb_crypt.c,v retrieving revision 1.1.2.1 diff -u -r1.1.2.1 smb_crypt.c --- smb_crypt.c 2001/05/22 08:32:33 1.1.2.1 +++ smb_crypt.c 2001/08/03 13:32:25 @@ -120,7 +120,7 @@ int len; len = strlen(apwd); - unipwd = malloc(len * sizeof(u_int16_t), M_SMBTEMP, M_WAITOK); + unipwd = malloc((len + 1) * sizeof(u_int16_t), M_SMBTEMP, M_WAITOK); /* * S21 = concat(MD4(U(apwd)), zeros(5)); */ Index: smb_rq.c === RCS file: /home/ncvs/src/sys/netsmb/smb_rq.c,v retrieving revision 1.1.2.1 diff -u -r1.1.2.1 smb_rq.c --- smb_rq.c2001/05/22 08:32:33 1.1.2.1 +++ smb_rq.c2001/08/03 13:32:25 @@ -238,7 +238,7 @@ bcnt = rqp-sr_rq.mb_count; if (bcnt 0x) SMBERROR(byte count too large (%d)\n, bcnt); - *rqp-sr_bcount = bcnt; + *rqp-sr_bcount = htoles(bcnt); } int
CFR: Fixes for nullfs in -stable
Hello,
I've mostly merged improvements done to nullfs in the -current to
RELENG_4 branch. Operations on mmaped files were fixed before and this
patch focused on the proper vnode locking.
Unfortunately, this code require changes in the layout of vnode
structure. It is possible to not break binary compatibility by changing
behavior of vop_sharedlock() function and using v_vnlock field as this is
done in -current. This requires changes only to nfs code by including lock
structure in the nfsnode structure (in the original code it was allocated
separately for each nfsnode). Size and layout of vnode structure left
unchanged.
I hope this will not break any 3rd party file system because all
new fs'es should use vop_std*lock() VOPs or roll their own.
Patch against recent RELENG_4 is attached. And if there is no
serious objections I'm plan to commit it on the next week.
--
Boris Popov
http://www.butya.kz/~bp/
Index: kern/vfs_default.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_default.c,v
retrieving revision 1.28.2.1
diff -u -r1.28.2.1 vfs_default.c
--- kern/vfs_default.c 2001/05/18 09:58:43 1.28.2.1
+++ kern/vfs_default.c 2001/06/06 08:53:49
@@ -360,14 +360,13 @@
* to be handled in intermediate layers.
*/
struct vnode *vp = ap-a_vp;
+ struct lock *l = (struct lock *)vp-v_data;
int vnflags, flags = ap-a_flags;
- if (vp-v_vnlock == NULL) {
- if ((flags LK_TYPE_MASK) == LK_DRAIN)
- return (0);
- MALLOC(vp-v_vnlock, struct lock *, sizeof(struct lock),
- M_VNODE, M_WAITOK);
- lockinit(vp-v_vnlock, PVFS, vnlock, 0, LK_NOPAUSE);
+ if (l == NULL) {
+ if (ap-a_flags LK_INTERLOCK)
+ simple_unlock(ap-a_vp-v_interlock);
+ return 0;
}
switch (flags LK_TYPE_MASK) {
case LK_DRAIN:
@@ -396,9 +395,9 @@
if (flags LK_INTERLOCK)
vnflags |= LK_INTERLOCK;
#ifndefDEBUG_LOCKS
- return (lockmgr(vp-v_vnlock, vnflags, vp-v_interlock, ap-a_p));
+ return (lockmgr(l, vnflags, vp-v_interlock, ap-a_p));
#else
- return (debuglockmgr(vp-v_vnlock, vnflags, vp-v_interlock, ap-a_p,
+ return (debuglockmgr(l, vnflags, vp-v_interlock, ap-a_p,
vop_sharedlock, vp-filename, vp-line));
#endif
}
@@ -435,13 +434,6 @@
struct vnode *vp = ap-a_vp;
int vnflags, flags = ap-a_flags;
- if (vp-v_vnlock == NULL) {
- if ((flags LK_TYPE_MASK) == LK_DRAIN)
- return (0);
- MALLOC(vp-v_vnlock, struct lock *, sizeof(struct lock),
- M_VNODE, M_WAITOK);
- lockinit(vp-v_vnlock, PVFS, vnlock, 0, LK_NOPAUSE);
- }
switch (flags LK_TYPE_MASK) {
case LK_DRAIN:
vnflags = LK_DRAIN;
@@ -485,13 +477,9 @@
{
struct vnode *vp = ap-a_vp;
- if (vp-v_vnlock == NULL) {
- if (ap-a_flags LK_INTERLOCK)
- simple_unlock(ap-a_vp-v_interlock);
- return (0);
- }
- return (lockmgr(vp-v_vnlock, LK_RELEASE | ap-a_flags,
- ap-a_vp-v_interlock, ap-a_p));
+ if (ap-a_flags LK_INTERLOCK)
+ simple_unlock(vp-v_interlock);
+ return (0);
}
/*
@@ -505,10 +493,11 @@
} */ *ap;
{
struct vnode *vp = ap-a_vp;
+ struct lock *l = (struct lock *)vp-v_data;
- if (vp-v_vnlock == NULL)
+ if (l == NULL)
return (0);
- return (lockstatus(vp-v_vnlock, ap-a_p));
+ return (lockstatus(l, ap-a_p));
}
int
Index: kern/vfs_subr.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v
retrieving revision 1.249.2.8
diff -u -r1.249.2.8 vfs_subr.c
--- kern/vfs_subr.c 2001/05/18 09:58:43 1.249.2.8
+++ kern/vfs_subr.c 2001/06/06 08:53:49
@@ -1707,10 +1707,7 @@
}
cache_purge(vp);
- if (vp-v_vnlock) {
- FREE(vp-v_vnlock, M_VNODE);
- vp-v_vnlock = NULL;
- }
+ vp-v_vnlock = NULL;
if (VSHOULDFREE(vp))
vfree(vp);
Index: nfs/nfs_node.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_node.c,v
retrieving revision 1.36.2.1
diff -u -r1.36.2.1 nfs_node.c
--- nfs/nfs_node.c 2001/03/21 10:50:59 1.36.2.1
+++ nfs/nfs_node.c 2001/06/06 08:53:49
@@ -175,6 +175,7 @@
bcopy((caddr_t)fhp, (caddr_t)np-n_fhp, fhsize);
np-n_fhsize = fhsize;
lockinit(np-n_rslock, PVFS | rsflags, nfrslk, 0, LK_NOPAUSE);
+ lockinit(np-n_lock, PVFS, nfsnlk, 0, LK_NOPAUSE);
*npp
Re: mount_mfs (Re: smbfs)
On Fri, 25 May 2001, Brooks Davis wrote: On Fri, May 25, 2001 at 10:04:09PM +0700, Boris Popov wrote: There is no any technical problems in doing that. But I'm unsure if this should be done (code is not very small). On other hand, people expect it in the base system... Probably we should collect more votes on this topic. I'll definatly vote for inclusion. IMO, it makes no sense to have a filesystem in the base you can't mount. If it really is so hugh that people complain, there's always the ugly NO_MOUNT_SMBFS make.conf option route. Those who really need small systems have to strip all sorts of things out already anyway, one more won't hurt. Ok, now I've received about fifty votes for inclusion of userland part in the base tree and zero objections. Import process will be done in the -current first and then MFCed to -stable. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
