Re: is it possible to have a NULL procp for an NFS request?
Matthew Jacob [EMAIL PROTECTED] writes:
I had a panic just now:
db t
tprintf() at tprintf+0x7c
nfs_msg() at nfs_msg+0x28
nfs_timer() at nfs_timer+0x1fc
softclock() at softclock+0x4f4
sithd_loop() at sithd_loop+0x18c
exception_return() at exception_return
Yes, this is possible, (at least) when following symbolic links. This
was discussed here on -current some time ago and I proposed the
appended simple patch, but I didn't get any feedback on it.
/assar
Index: nfs_socket.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_socket.c,v
retrieving revision 1.62
diff -u -w -u -w -r1.62 nfs_socket.c
--- nfs_socket.c2000/11/26 20:35:21 1.62
+++ nfs_socket.c2000/12/23 05:59:51
@@ -1969,6 +1969,7 @@
char *server, *msg;
{
+ if (p != NULL)
tprintf(p, LOG_INFO, "nfs server %s: %s\n", server, msg);
return (0);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: is it possible to have a NULL procp for an NFS request?
Hmm. The client wasn't following symlinks. The patch seems
simple enough, but it probably shouldn't just swallow the
error.
It looks like the last phk simplification lost some of the
functionality of the previous code- that I can fix.
On 23 Dec 2000, Assar Westerlund wrote:
Matthew Jacob [EMAIL PROTECTED] writes:
I had a panic just now:
db t
tprintf() at tprintf+0x7c
nfs_msg() at nfs_msg+0x28
nfs_timer() at nfs_timer+0x1fc
softclock() at softclock+0x4f4
sithd_loop() at sithd_loop+0x18c
exception_return() at exception_return
Yes, this is possible, (at least) when following symbolic links. This
was discussed here on -current some time ago and I proposed the
appended simple patch, but I didn't get any feedback on it.
/assar
Index: nfs_socket.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_socket.c,v
retrieving revision 1.62
diff -u -w -u -w -r1.62 nfs_socket.c
--- nfs_socket.c 2000/11/26 20:35:21 1.62
+++ nfs_socket.c 2000/12/23 05:59:51
@@ -1969,6 +1969,7 @@
char *server, *msg;
{
+ if (p != NULL)
tprintf(p, LOG_INFO, "nfs server %s: %s\n", server, msg);
return (0);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: is it possible to have a NULL procp for an NFS request?
Matthew Jacob [EMAIL PROTECTED] writes: Hmm. The client wasn't following symlinks. You sure? What happens is when you queue up an nfs operation provoked by following a symlink. I couldn't figure any other way of making that happen. The patch seems simple enough, but it probably shouldn't just swallow the error. Yeah, your patch to subr_prf.c is better. /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is it possible to have a NULL procp for an NFS request?
I'm pretty sure that the server had no symlinks in that filesystem. On 23 Dec 2000, Assar Westerlund wrote: Matthew Jacob [EMAIL PROTECTED] writes: Hmm. The client wasn't following symlinks. You sure? What happens is when you queue up an nfs operation provoked by following a symlink. I couldn't figure any other way of making that happen. The patch seems simple enough, but it probably shouldn't just swallow the error. Yeah, your patch to subr_prf.c is better. Well, it covers more. Sigh. Just pluggin' holes To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is it possible to have a NULL procp for an NFS request?
:Matthew Jacob [EMAIL PROTECTED] writes: : Hmm. The client wasn't following symlinks. : :You sure? What happens is when you queue up an nfs operation provoked :by following a symlink. I couldn't figure any other way of making :that happen. : : The patch seems simple enough, but it probably shouldn't just : swallow the error. : :Yeah, your patch to subr_prf.c is better. : :/assar Looking at the cvs logs it looks like Poul forgot to check for p == NULL in his new simplified tprintf() API. The 'sess' based tprintf did check for NULL. The proc based tprintf does not. So fixing it in tprintf() itself, in subr_prf.c, is the right move. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
