On Friday 22 May 2009 12:19:32 pm Rick Macklem wrote:
>
> On Fri, 22 May 2009, John Baldwin wrote:
>
> >
> > What about a malicious denial-of-service attack where a malicious client
> > initiates an endless stream of connection attempts to force a panic? I
think
> > that is where the concern li
On Fri, 22 May 2009, John Baldwin wrote:
What about a malicious denial-of-service attack where a malicious client
initiates an endless stream of connection attempts to force a panic? I think
that is where the concern lies. I'm sure a malicious client could do it
intentionally in less than 1
John Baldwin writes:
> What about a malicious denial-of-service attack where a malicious client
> initiates an endless stream of connection attempts to force a panic? I think
> that is where the concern lies. I'm sure a malicious client could do it
> intentionally in less than 136 years, perh
On Friday 22 May 2009 10:32:43 am Rick Macklem wrote:
>
> On Fri, 22 May 2009, Dag-Erling Smørgrav wrote:
>
> > Rick Macklem writes:
> >> Log:
> >> Although it should never happen, all the nfsv4 server can do
> >> when it runs out of clientids is reboot. I had replaced cpu_reboot()
> >> wi
On Fri, 22 May 2009, Dag-Erling Smørgrav wrote:
Rick Macklem writes:
Log:
Although it should never happen, all the nfsv4 server can do
when it runs out of clientids is reboot. I had replaced cpu_reboot()
with printf(), since cpu_reboot() doesn't exist for sparc64.
This change replace
Rick Macklem writes:
> Log:
> Although it should never happen, all the nfsv4 server can do
> when it runs out of clientids is reboot. I had replaced cpu_reboot()
> with printf(), since cpu_reboot() doesn't exist for sparc64.
> This change replaces the printf() with panic(), so the reboot
>
On Thu, 21 May 2009, Alexey Dokuchaev wrote:
Shouldn't the comment above be also tweaked?
./danfe
Yep, I'll do that. Thanks, rick
ps: Sorry about the multiple posts yesterday related to this. The imapd
I connect to was having "technical "difficulties" and I thought
(incorrectly) t
On Wed, May 20, 2009 at 06:58:07PM +, Rick Macklem wrote:
> Modified: head/sys/fs/nfsserver/nfs_nfsdstate.c
> ==
> --- head/sys/fs/nfsserver/nfs_nfsdstate.c Wed May 20 18:45:49 2009
> (r192462)
> +++ head/sy
On Wed, 20 May 2009, Juli Mallett wrote:
When client ids have been run out of, does that put something into a
dangerous state (insecure or crash-prone)? Isn't it better to let the
administrator make the decision of when to reboot the machine?
Don't worry, it's never going to happen. A new c
On Wed, 20 May 2009, Juli Mallett wrote:
When client ids have been run out of, does that put something into a
dangerous state (insecure or crash-prone)? Isn't it better to let the
administrator make the decision of when to reboot the machine?
Don't worry, it's never gonna happen. A new clie
On Wed, May 20, 2009 at 2:36 PM, Rick Macklem wrote:
> On Wed, 20 May 2009, Juli Mallett wrote:
>
>> When client ids have been run out of, does that put something into a
>> dangerous state (insecure or crash-prone)? Isn't it better to let the
>> administrator make the decision of when to reboot t
On Wed, 20 May 2009, Juli Mallett wrote:
When client ids have been run out of, does that put something into a
dangerous state (insecure or crash-prone)? Isn't it better to let the
administrator make the decision of when to reboot the machine?
Well, first off, this will "never" happen in pra
When client ids have been run out of, does that put something into a
dangerous state (insecure or crash-prone)? Isn't it better to let the
administrator make the decision of when to reboot the machine?
On Wed, May 20, 2009 at 11:58 AM, Rick Macklem wrote:
> Author: rmacklem
> Date: Wed May 20 18
13 matches
Mail list logo
