Date: Sun, 13 Jan 2002 09:35:11 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Alfred Perlstein <bright@mu.org> Cc: tanimura@freebsd.org, dillon@freebsd.org, smp@freebsd.org Subject: Re: fd locking. Message-ID: <XFMail.020113093511.jhb@FreeBSD.org> In-Reply-To: <20020112191645.J7984@elvis.mu.org>
index | next in thread | previous in thread | raw e-mail
On 13-Jan-02 Alfred Perlstein wrote:
>> In svr4_stream.c, do_putmsg and do_getmsg should be taking a thread not a
>> proc
>> as their first argument and callers should be fixed as well.
>
> Can this be delayed?
They are system calls, so they are really getting a thread not a proc (well,
the functions that call them are syscalls). These are KSE conflicts. If
you've fixed them already that is good, but if not it's pretty quick to do. :)
>> You might consider a file_init() and file_destroy() function or macro like
>> so:
>>
>> void
>> file_init(struct file *fp)
>> {
>>
>> mtx_init(&fp->f_mtx, "struct file", MTX_DEF);
>> fp->f_count = 1;
>> }
>>
>> void
>> file_destroy(struct file *fp)
>> {
>>
>> mtx_destroy(&fp->f_mtx);
>> }
>>
>> I would just make file_destroy a macro for now. Having file_init a function
>> would save a little space since the "struct file" string wouldn't be
>> duplicated, but you can always change it later. You could add more stuff if
>> needed as well. :)
>
> Can this be delayed?
It's not required, it's just cleaner, esp. if we switch to a new slab allocator
since these functions will almost fit in perfectly to such a beast.
>> hmm, for this code:
>>
>> + mtx_init(&fp->f_mtx, "file structure", MTX_DEF);
>> + fp->f_gcflag = 0;
>> fp->f_count = 1;
>> fp->f_cred = crhold(p->p_ucred);
>> fp->f_ops = &badfileops;
>> fp->f_seqcount = 1;
>> + FILEDESC_UNLOCK(p->p_fd);
>> + sx_xlock(&filelist_lock);
>> + FILEDESC_LOCK(p->p_fd);
>> if ((fq = p->p_fd->fd_ofiles[0])) {
>> LIST_INSERT_AFTER(fq, fp, f_list);
>> } else {
>> LIST_INSERT_HEAD(&filehead, fp, f_list);
>> }
>> p->p_fd->fd_ofiles[i] = fp;
>> + FILEDESC_UNLOCK(p->p_fd);
>> + sx_xunlock(&filelist_lock);
>> if (resultfp)
>> *resultfp = fp;
>> if (resultfd)
>>
>> You could xlock filelist_lock earlier before the first FILEDESC_LOCK with
>> associated changes to avoid as many locking operations. You wouldn't keep
>> the
>> xlock held for much longer and it would probably be quicker in the long run.
>
> Yes, but those codes call malloc with M_WAITOK, if someone was to close
> a filedescriptor i may get deadlock because they block on the filehead
> sx lock while i'm blocked in malloc and i already have the filedesc lock.
No, not that early, you get the FILEDESC_LOCK a few lines earlier, and you
could lock the xlock right before that, but after the malloc.
>> Bruce is going to not like you for adding nested includes of sys/lock.h and
>> sys/mutex.h. Instead, add nested includes of sys/_lock.h and sys/_mutex.h,
>> and
>> then add sys/lock.h and sys/mutex.h to the files that need them.
>
> Can this be delayed?
Well, now you won't know what headers to remove unless you start going around
with phk's script. Much easier to get this right the first time.
>> Other then that it looks great. Can you clean these bits up and post a new
>> patch for folks to test. Aside form svr4, the current patch should be good
>> for
>> testing as well. Esp. need people with SMP machines to test this stuff.
>
> New patch up:
>
> http://people.freebsd.org/~alfred/fd.diff
I see you've committed it already, so I'll just test the code in the tree now.
You really need to get it tested by SMP prior to commit since a UP box just
isn't going to see the same races, and now if you have a bug that hoses
current, we all get to live with it until it's fixed. :-P
> I still need to fix Matt's fd holding stuff, but I'm anxious to get this
> in before I loose it all to some massive structure renaming or whitespace
> run like I have before. :)
Start using p4 since it handles this for you better. It's not hard or
anything. :-P
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.020113093511.jhb>