Not a lot of people are familiar with fd passing so I'll give
a short description:
By using AF_UNIX sockets between processes, a process can use
sendmsg() to send a filedescriptor through the socket where the
other process will do a recvmsg() to pickup the descriptor.
The "problem" is that
< said:
> Gee, this looks suspiciously like jhb's refcount patch:
...Except that I made provision for architectures which have LL/SC
rather than CAS, which saves a few instructions.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the me
Mark Wright wrote:
>
> I'm trying to get frame relay working with a lmc1200 card, and I'm getting
> the following error:
>
> sj# ngctl mkpeer lmc0: frame_relay rawdata downstream
> sj# ngctl mkpeer lmc0:rawdata lmi dlci0 auto0
> sj# ngctl mkpeer lmc0:rawdata rfc1490 dlci15 downstream
> ngctl: se
Hi,
A while ago (it's been at least two weeks now), Mike Silbersack
requested a review for:
http://www.silby.com/patches/ratelimit-enhancement-2.patch
To quote the description on his web page, this diff will:
* ICMP ECHO and TSTAMP replies are now rate-limited.
* RSTs gene
On Wed, 13 Dec 2000, Bosko Milekic wrote:
>Suppressing udp flood/scan: 212/200 pps
>Suppressing outgoing RST due to port scan: 202/200 pps
>Suppressing outgoing RST due to ACK flood: 19725/200 pps
>Suppressing ping flood: 230/200 pps
>Suppressing icmp tstam
* Richard A. Steenbergen <[EMAIL PROTECTED]> [001213 11:17] wrote:
> On Wed, 13 Dec 2000, Bosko Milekic wrote:
>
> >Suppressing udp flood/scan: 212/200 pps
> >Suppressing outgoing RST due to port scan: 202/200 pps
> >Suppressing outgoing RST due to ACK flood: 19725/200 pps
On Wed, 13 Dec 2000, Richard A. Steenbergen wrote:
> I would be extremely careful with those descriptions... When you tell
> people directly that something is an attack, even if its not, there are
> enough who will jump to immediate conclusions and begin making false
> accusations. While it may
On Wed, 13 Dec 2000, Alfred Perlstein wrote:
> I think the word "possible" should be prepended to all of these messages.
>
> Now I have a weird question, I've seen the ICMP responce limit when
> getting pegged by a couple hundred hits per second on a port that isn't
> open by legimitimate connec
On Wed, 13 Dec 2000, Mike Silbersack wrote:
> > I also see no compelling reason to put ICMP Timestamp
> > in a seperate queue, but what I would recommend is seperate queues for
> > ICMP messages which would be defined as "query/response" and those which
> > would be called "error" messages. If so
On Wed, 13 Dec 2000, Richard A. Steenbergen wrote:
> Is there some specific reason you need timestamp seperate? If you're
> really up for that, why not just limit each ICMP type seperately?
There's no real need for it to be separate, it just feels cleaner. I
prefer seeing the two cases have se
On Wed, 13 Dec 2000, Mike Silbersack wrote:
> On Wed, 13 Dec 2000, Richard A. Steenbergen wrote:
>
> > Is there some specific reason you need timestamp seperate? If you're
> > really up for that, why not just limit each ICMP type seperately?
>
> There's no real need for it to be separate, it ju
On Wed, 13 Dec 2000, Richard A. Steenbergen wrote:
> > Hm, true. I was thinking of limiting the outgoing side, which would mean
> > ipfw comes later in the string, but I suppose that if you limit on the
> > incoming ipfw's sooner.
>
> Historically bandlim has been the process of stopping the
On Wed, 13 Dec 2000, Mike Silbersack wrote:
> On Wed, 13 Dec 2000, Richard A. Steenbergen wrote:
>
> > > Hm, true. I was thinking of limiting the outgoing side, which would mean
> > > ipfw comes later in the string, but I suppose that if you limit on the
> > > incoming ipfw's sooner.
> >
> > H
I believe that your changes have been sorely needed for many
years. While I would like to see regular mbufs given a callback
mechanism, your present approach of using an mbuf cluster
solves 90% of the problem.
Kirk McKusick
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscri
:I believe that your changes have been sorely needed for many
:years. While I would like to see regular mbufs given a callback
:mechanism, your present approach of using an mbuf cluster
:solves 90% of the problem.
:
: Kirk McKusick
... Aflred, be careful that you don't break things we
> Not a lot of people are familiar with fd passing so I'll give
> a short description:
>
> By using AF_UNIX sockets between processes, a process can use
> sendmsg() to send a filedescriptor through the socket where the
> other process will do a recvmsg() to pickup the descriptor.
>
> The "
* Matt Dillon <[EMAIL PROTECTED]> [001213 13:07] wrote:
> :I believe that your changes have been sorely needed for many
> :years. While I would like to see regular mbufs given a callback
> :mechanism, your present approach of using an mbuf cluster
> :solves 90% of the problem.
> :
> : Kirk Mc
* Alfred Perlstein <[EMAIL PROTECTED]> [001213 14:20] wrote:
> * Matt Dillon <[EMAIL PROTECTED]> [001213 13:07] wrote:
> > :I believe that your changes have been sorely needed for many
> > :years. While I would like to see regular mbufs given a callback
> > :mechanism, your present approach of usi
On Wed, Dec 13, 2000 at 02:42:53PM -0500, Richard A. Steenbergen wrote:
> It could just as easily be a SYN flood against a single port... or a large
> number of clients trying to connected to your crashed web server... :P Or
> it could just as easily be an ack flood against a port without a liste
Brian Somers <[EMAIL PROTECTED]> wrote:
>
>Hmm, the last time i looked at this, I believe the whole thing was
>dealt with by not increasing the file descriptor reference count
>when it was put in the message header. If process A closed the
>descriptor before process B actually recvmsg()d it, i
> This causes a leak, I think the trick is to just always call sorflush()
> when the pcb is free'd.
Even this doesn't work.
>
> Looking at linux they still are using gc. I'll give this a lot
> more thought before resubmitting this idea.
Ok, the problem is you have 3 af_unix pairs all open bet
On Wed, 13 Dec 2000, Bill Fumerola wrote:
> On Wed, Dec 13, 2000 at 02:42:53PM -0500, Richard A. Steenbergen wrote:
>
> > It could just as easily be a SYN flood against a single port... or a large
> > number of clients trying to connected to your crashed web server... :P Or
> > it could just as
Alfred Perlstein <[EMAIL PROTECTED]> wrote:
>
>I guess the gc has to stay.
>
>dammit. :)
>
>My apologies for wasting everyone's time here.
``One day a student came to Moon and said: "I understand how to make a
better garbage collector. We must keep a reference count of the
pointers to each cons."
> Brian Somers <[EMAIL PROTECTED]> wrote:
> >
> >Hmm, the last time i looked at this, I believe the whole thing was
> >dealt with by not increasing the file descriptor reference count
> >when it was put in the message header. If process A closed the
> >descriptor before process B actually recv
:I guess the gc has to stay.
:
:dammit. :)
:
:My apologies for wasting everyone's time here.
:
:--
:-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
No waste at all, Alfred, the file descriptor passing code had been
broken for over 10 years precisely because of its complexity.
* Matt Dillon <[EMAIL PROTECTED]> [001213 17:25] wrote:
>
> :I guess the gc has to stay.
> :
> :dammit. :)
> :
> :My apologies for wasting everyone's time here.
> :
> :--
> :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
>
> No waste at all, Alfred, the file descriptor passing co
:> No waste at all, Alfred, the file descriptor passing code had been
:
:Are you saying the code in place is broken? If so I'll spend some
:time looking at it and the Linux implementation to figure if at
:least one of us gets it right and try to find some sort of solution.
No, *had*, no
:Hmm, the last time i looked at this, I believe the whole thing was
:dealt with by not increasing the file descriptor reference count
:when it was put in the message header. If process A closed the
:descriptor before process B actually recvmsg()d it, it would be
:EBADF. The recvmsg() actual
Matt Dillon <[EMAIL PROTECTED]> wrote:
>
>No waste at all, Alfred, the file descriptor passing code had been
>broken for over 10 years precisely because of its complexity. Rewriting
>the GC to be more efficient essentially requires using deep graph theory
>to locate isolated loops
On Wed, Dec 13, 2000 at 09:35:40PM -0500, Bosko Milekic wrote:
> > Bosko, please change the descriptions to something very generic before
> > committing them ("ratelimiting TCP RST packets: x/y pps" or something)
>
> Mike said he would do it and re-post the diff.
Excellent.
--
Bill Fume
30 matches
Mail list logo
