Re: The Trolls identity (was: Re: matthew dillon)
On Sun, 9 Feb 2003, Rahul Siddharthan wrote: (I assume I'm replying to the real PHK here) [EMAIL PROTECTED] wrote: We know that the lamer behind the Troll is Bill Huey aka billh. Is there any evidence for it? If so, you should share it and if not, you shouldn't make such accusations.
Re: matthew dillon
to quote the freebsd-current dmesg: Be nice to each other, mmmkay? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: matthew dillon
Dave Hayes wrote: Terry Lambert [EMAIL PROTECTED] writes: Do you unsubscribe from mailing lists you merely monitor for interesting content, rather than subscribing to them, when some jerk fills up your POP3 maildrop because they have an axe to grind, and, as a result, mail which you
matthew dillon
Sorry folks, I don't know, who this mathew dillon guy really is, or how important he is for the FreeBSD project, but I don't think, he should be on any of the freebsd mailing lists or any related facilities, if he just can't keep with some of the most basic rules of communication. It may be
Re: matthew dillon
, that freebsd-* is no place for private quarrels or neuroses. I think it is more than obvious that this person is NOT Matthew Dillon (if you search on last couple of weeks, you'll see that the real Dillon does not even use that e-mail address). On the other hand, I've seen someone
Re: matthew dillon
These messages aren't from the *real* Matt Dillon, they're from a stupid troll who has been impersonating various FreeBSD developers for a few months now. This particular troll uses anonymous remailers so the postmaster is helpless to block email addresses or IP ranges. So, if the message looks
Re: matthew dillon
rules of communication. [snip] Matthew Dillon [EMAIL PROTECTED] != Matthew Dillon [EMAIL PROTECTED]. I'm guessing that Matthew Dillion [EMAIL PROTECTED] is the same troll who has been (making a poor attempt at) forging email from controversial FreeBSD people for quite a long time now
RE: matthew dillon
To: [EMAIL PROTECTED] Subject: matthew dillon Sorry folks, I don't know, who this mathew dillon guy really is, or how important he is for the FreeBSD project, but I don't think, he should be on any of the freebsd mailing lists or any related facilities, if he just can't keep with some of the most
Re: Matthew Dillon
Hi Again, please take my apologizes, especially Matthew, I am rather new to FreeBSD - not in therms of using but reading the lists etc - and I just was disappointed a lot, because a had to see, that there is sadly no big difference between IRC and the freebsd mailing lists. I know, one can't do
The Trolls identity (was: Re: matthew dillon)
In message 00af01c2d04a$e948e0e0$[EMAIL PROTECTED], Matthew Emmerton w rites: These messages aren't from the *real* Matt Dillon, they're from a stupid troll who has been impersonating various FreeBSD developers for a few months now. This particular troll uses anonymous remailers so the postmaster
The Trolls identity (was: Re: matthew dillon)
(I assume I'm replying to the real PHK here) [EMAIL PROTECTED] wrote: We know that the lamer behind the Troll is Bill Huey aka billh. Is there any evidence for it? If so, you should share it and if not, you shouldn't make such accusations.
Re: The Trolls identity (was: Re: matthew dillon)
Rahul Siddharthan writes: (I assume I'm replying to the real PHK here) [EMAIL PROTECTED] wrote: We know that the lamer behind the Troll is Bill Huey aka billh. Is there any evidence for it? If so, you should share it and if not, you shouldn't make such accusations. He admitted to it. M
Re: The Trolls identity (was: Re: matthew dillon)
On Sun, Feb 09, 2003 at 04:06:52PM +0100, [EMAIL PROTECTED] wrote: We know that the lamer behind the Troll is Bill Huey aka billh. FWIW if you or someone else can establish guilt in this matter, it is actionable under 18 USC Sec. 1028[0]. If I were the real Matt Dillon I would call my local
Re: matthew dillon
Hi, Ronald G. Minnich wrote: I don't know who he is either, but much to my regret this nonsense has forced me off the list. Talk about beeing sensitive. I do not stop walking on streets despite the fact that some people get robbed there. Erich To Unsubscribe: send mail to [EMAIL
Re: matthew dillon
oceanare pte ltd wrote: Ronald G. Minnich wrote: I don't know who he is either, but much to my regret this nonsense has forced me off the list. Talk about beeing sensitive. I do not stop walking on streets despite the fact that some people get robbed there. Do you unsubscribe from
Re: matthew dillon
Terry Lambert wrote something here: ... Thanks for getting me to roll my eyes. They needed a workout after staring at code. Don To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: matthew dillon
I don't know who he is either, but much to my regret this nonsense has forced me off the list. Bye everyone, it's been a great 9 years, and it's a great OS, and you're great people! I hope this mess gets worked out someday. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with
Recent NFS commits, plus Heads up to 2.2.x users Hello everyone. There have been a number of recent NFS commits to fix bugs. Everything is hunky dory, but I do not have a 2.2.x box to test the MFC to 2.2.x so this is a head's up to 2.2.x users who are using NFS that these (relatively simple) bug fixes have been MFC'd, but not tested. It would be nice if I could get confirmation that 2.2.x hasn't blow up :-) -Matt Matthew Dillon dillon@backplane.comdillon 1999/12/11 19:19:33 PST Modified files: sys/kern vfs_subr.c vfs_syscalls.c sys/vm vm_fault.c vm_map.c vm_map.h vm_mmap.c vm_object.c vm_object.h vm_page.c vm_page.h sys/sys mman.h lib/libc/sys madvise.2 mmap.2 Log: Add MAP_NOSYNC feature to mmap(), and MADV_NOSYNC and MADV_AUTOSYNC to madvise(). This feature prevents the update daemon from gratuitously flushing dirty pages associated with a mapped file-backed region of memory. The system pager will still page the memory as necessary and the VM system will still be fully coherent with the filesystem. Modifications made by other means to the same area of memory, for example by write(), are unaffected. The feature works on a page-granularity basis. MAP_NOSYNC allows one to use mmap() to share memory between processes without incuring any significant filesystem overhead, putting it in the same performance category as SysV Shared memory and anonymous memory. Reviewed by: julian, alc, dg Revision Changes Path 1.239 +2 -2 src/sys/kern/vfs_subr.c 1.147 +3 -2 src/sys/kern/vfs_syscalls.c 1.108 +17 -3 src/sys/vm/vm_fault.c 1.184 +16 -3 src/sys/vm/vm_map.c 1.52 +3 -2 src/sys/vm/vm_map.h 1.105 +5 -4 src/sys/vm/vm_mmap.c 1.171 +32 -5 src/sys/vm/vm_object.c 1.62 +4 -3 src/sys/vm/vm_object.h 1.147 +8 -4 src/sys/vm/vm_page.c 1.74 +5 -5 src/sys/vm/vm_page.h 1.27 +4 -1 src/sys/sys/mman.h 1.16 +28 -1 src/lib/libc/sys/madvise.2 1.18 +30 -1 src/lib/libc/sys/mmap.2dillon 1999/12/11 19:28:15 PST Modified files: sys/kern vfs_syscalls.c Log: Remove accidental pollution unrelated to previous commit. The issue here is real but has not yet been discussed with Eivind. Revision Changes Path 1.148 +2 -3 src/sys/kern/vfs_syscalls.cdillon 1999/12/11 22:09:58 PST Modified files: sys/nfs nfs_bio.c nfs_subs.c nfs_vnops.c sys/sys buf.h Log: Synopsis of problem being fixed: Dan Nelson originally reported that blocks of zeros could wind up in a file written to over NFS by a client. The problem only occurs a few times per several gigabytes of data. This problem turned out to be bug #3 below. bug #1: B_CLUSTEROK must be cleared when an NFS buffer is reverted from stage 2 (ready for commit rpc) to stage 1 (ready for write). Reversions can occur when a dirty NFS buffer is redirtied with new data. Otherwise the VFS/BIO system may end up thinking that a stage 1 NFS buffer is clusterable. Stage 1 NFS buffers are not clusterable. bug #2: B_CLUSTEROK was inappropriately set for a 'short' NFS buffer (short buffers only occur near the EOF of the file). Change to only set when the buffer is a full biosize (usually 8K). This bug has no effect but should be fixed in -current anyway. It need not be backported. bug #3: B_NEEDCOMMIT was inappropriately set in nfs_flush() (which is typically only called by the update daemon). nfs_flush() does a multi-pass loop but due to the lack of vnode locking it is possible for new buffers to be added to the dirtyblkhd list while a flush operation is going on. This may result in nfs_flush() setting B_NEEDCOMMIT on a buffer which has *NOT* yet gone through its stage 1 write, causing only the commit rpc to be made and thus causing the contents of the buffer to be thrown away (never sent to the server). The patch also contains some cleanup, which only applies to the commit into -current. Reviewed by: dg, julian Originally Reported by: Dan Nelson dnelson@emsphone.com Revision Changes Path 1.81 +27 -11 src/sys/nfs/nfs_bio.c 1.86 +15 -7 src/sys/nfs/nfs_subs.c 1.148 +3 -27 src/sys/nfs/nfs_vnops.c 1.85 +8 -1 src/sys/sys/buf.hdillon 1999/12/11 22:52:35 PST Modified files: (Branch: RELENG_3) sys/nfs nfs_bio.c nfs_subs.c nfs_vnops.c Log: MFC nfs_bio.c 1.81, nfs_subs.c 1.86, nfs_vnops.c 1.148. Fixed two rare-occuring bugs in NFS. First, B_CLUSTEROK must be cleared when B_NEEDCOMMIT is cleared since uncommitted dirty buffers may not be clustered. Second, B_NEEDCOMMIT cannot be gratuitously set in nfs_flush(). Due to lack of locking a buffer may be added to the dirtyblkhd list during the flush and setting B_NEEDCOMMIT can result in the buffer's data being thrown away rather then written to the server. Reviewed by: dg Approved by: jkh Revision Changes Path 1.65.2.3 +4 -4 src/sys/nfs/nfs_bio.c 1.70.2.4 +2 -2 src/sys/nfs/nfs_subs.c 1.116.2.8 +4 -4 src/sys/nfs/nfs_vnops.cdillon 1999/12/11 23:06:40 PST Modified files: sys/nfs nfs_nqlease.c nfs_serv.c nfs_subs.c Log: Fix a number of server-side issues related to aborting badly formed NFS packets, mainly initializing structure pointers to NULL which are conditionally freed prior to return. PR: kern/15249 Submitted by: Ian Dowse iedowse@maths.tcd.ie Revision Changes Path 1.47 +4 -2 src/sys/nfs/nfs_nqlease.c 1.89 +5 -5 src/sys/nfs/nfs_serv.c 1.87 +4 -1 src/sys/nfs/nfs_subs.cdillon 1999/12/11 23:16:21 PST Modified files: (Branch: RELENG_3) sys/nfs nfs_nqlease.c nfs_serv.c nfs_subs.c Log: MFC nfs_nqlease 1.47, nfs_serv.c 1.89, nfs_subs.c 1.87. Prevent panics in server side abort code when dealing with malformed NFS packets. Approved by: jkh Revision Changes Path 1.39.2.3 +4 -2 src/sys/nfs/nfs_nqlease.c 1.72.2.6 +5 -5 src/sys/nfs/nfs_serv.c 1.70.2.5 +4 -1 src/sys/nfs/nfs_subs.cdillon 1999/12/11 23:25:12 PST Modified files: (Branch: RELENG_2_2) sys/nfs nfs_nqlease.c nfs_subs.c Log: MFC nfs_nqlease 1.47, nfs_serv.c 1.89, nfs_subs.c 1.87. Note that no changes to nfs_serv.c were required, the bugs in that routine were introduced after 2.2.x. Revision Changes Path 1.20.2.2 +4 -2 src/sys/nfs/nfs_nqlease.c 1.33.2.4 +3 -1 src/sys/nfs/nfs_subs.cdillon 1999/12/11 23:28:52 PST Modified files: (Branch: RELENG_2_2) sys/nfs nfs_bio.c nfs_subs.c nfs_vnops.c Log: MFC nfs_bio.c 1.81, nfs_subs.c 1.86, nfs_vnops.c 1.148 Revision Changes Path 1.28.2.11 +3 -3 src/sys/nfs/nfs_bio.c 1.33.2.5 +2 -2 src/sys/nfs/nfs_subs.c 1.36.2.12 +4 -4 src/sys/nfs/nfs_vnops.c
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
