Re: Patch to remove MFREE() macro entirely

[David Greenman]

>Oh what a tangled web we weave.  This should be really easy for people
>to take a quick look at to see if I made any mistakes.  I'm basically
>untangling the (small) mess that people made of the code while trying to
>use the MFREE() macro over the last N years.
>
>If nobody sees any problems it will go into -current next week some
>time and then be MFC'd to stable.

   Looks good to me. I'm definately very much in favor of killing MFREE().

-DG

David Greenman
Co-founder, The FreeBSD Project - http://www.freebsd.org
President, TeraSolutions, Inc. - http://www.terasolutions.com
President, Download Technologies, Inc. - http://www.downloadtech.com
Pave the road of life with opportunities.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: fork rate limit

[Mike Makonnen]

On Sun, 3 Feb 2002 02:35:46 +0400
Gaspar Chilingarov <[EMAIL PROTECTED]> wrote:

>   I've got such situation on our free shellbox set up in the
>   university - some newbies were kidding with old while(1) fork();
>   attack. Finnaly they got hit by memory limits set up for each
>   user, but anyway they were taking a lot of processor time. I
>   prefer to limit some uid's ability to do many forks in some
>   short period - like 'no more than 200 forks in 10 seconds' or
>   smthng like this.

Lock them out of the box for a while. If they do it again ban them
forever. The students will learn pretty quickly not to do such things.
This means less work for you, and no need to continuously maintain diffs
against the kernel sources. IMO it's a *very,very* bad thing to
introduce changes into the kernel that might introduce unintended side
effects when the problem can be solved administratively.


cheers,
mike makonnen

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Patch to remove MFREE() macro entirely

[Matthew Dillon]

Oh what a tangled web we weave.  This should be really easy for people
to take a quick look at to see if I made any mistakes.  I'm basically
untangling the (small) mess that people made of the code while trying to
use the MFREE() macro over the last N years.

If nobody sees any problems it will go into -current next week some
time and then be MFC'd to stable.

After that I'll deal with the two or three major softupdates-related
patches that need to be MFC'd and perhaps the vrele() bug, and after
I'll hopefully be able to do some work on -current.  Alfred has been
very patient I know.

It would also be nice if someone took a more detailed look at the
one 'XXX' comment I have in there for the LNC driver.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>

Index: dev/cnw/if_cnw.c
===
RCS file: /home/ncvs/src/sys/dev/cnw/if_cnw.c,v
retrieving revision 1.3
diff -u -r1.3 if_cnw.c
--- dev/cnw/if_cnw.c8 May 2001 23:57:32 -   1.3
+++ dev/cnw/if_cnw.c3 Feb 2002 03:17:59 -
@@ -869,12 +869,11 @@
  * Transmit a packet.
  */
 void
-cnw_transmit(sc, m0)
+cnw_transmit(sc, m)
struct cnw_softc *sc;
-   struct mbuf *m0;
+   struct mbuf *m;
 {
int buffer, bufsize, bufoffset, bufptr, bufspace, len, mbytes, n;
-   struct mbuf *m;
u_int8_t *mptr;
 
/* Get buffer info from card */
@@ -891,7 +890,7 @@
bufptr = sc->sc_memoff + buffer + bufoffset;
bufspace = bufsize;
len = 0;
-   for (m = m0; m; ) {
+   while (m) {
mptr = mtod(m, u_int8_t *);
mbytes = m->m_len;
len += mbytes;
@@ -914,8 +913,7 @@
mptr += n;
mbytes -= n;
}
-   MFREE(m, m0);
-   m = m0;
+   m = m_free(m);
}
 
/* Issue transmit command */
Index: dev/lnc/if_lnc.c
===
RCS file: /home/ncvs/src/sys/dev/lnc/if_lnc.c,v
retrieving revision 1.89
diff -u -r1.89 if_lnc.c
--- dev/lnc/if_lnc.c4 Jul 2001 13:00:19 -   1.89
+++ dev/lnc/if_lnc.c3 Feb 2002 03:20:18 -
@@ -833,9 +833,11 @@
sc->mbuf_count++;
start->buff.mbuf = 0;
} else {
-   struct mbuf *junk;
-   MFREE(start->buff.mbuf, junk);
-   start->buff.mbuf = 0;
+   /*
+* XXX should this be m_freem()?
+*/
+   m_free(start->buff.mbuf);
+   start->buff.mbuf = NULL;
}
}
sc->pending_transmits--;
@@ -1308,8 +1310,8 @@
m->m_len -= chunk;
m->m_data += chunk;
if (m->m_len <= 0) {
-   MFREE(m, head->m_next);
-   m = head->m_next;
+   m = m_free(m);
+   head->m_next = m;
}
}
}
Index: dev/vx/if_vx.c
===
RCS file: /home/ncvs/src/sys/dev/vx/if_vx.c,v
retrieving revision 1.34
diff -u -r1.34 if_vx.c
--- dev/vx/if_vx.c  19 Jul 2001 02:16:01 -  1.34
+++ dev/vx/if_vx.c  3 Feb 2002 03:22:42 -
@@ -390,7 +390,7 @@
 struct ifnet *ifp;
 {
 register struct vx_softc *sc = ifp->if_softc;
-register struct mbuf *m, *m0;
+register struct mbuf *m;
 int sh, len, pad;
 
 /* Don't transmit if interface is busy or not running */
@@ -399,14 +399,14 @@
 
 startagain:
 /* Sneak a peek at the next packet */
-m0 = ifp->if_snd.ifq_head;
-if (m0 == 0) {
+m = ifp->if_snd.ifq_head;
+if (m == NULL) {
return;
 }
 /* We need to use m->m_pkthdr.len, so require the header */
- if ((m0->m_flags & M_PKTHDR) == 0)
+ if ((m->m_flags & M_PKTHDR) == 0)
panic("vxstart: no header mbuf");
- len = m0->m_pkthdr.len;
+ len = m->m_pkthdr.len;
 
  pad = (4 - len) & 3;
 
@@ -418,8 +418,8 @@
 if (len + pad > ETHER_MAX_LEN) {
/* packet is obviously too large: toss it */
++ifp->if_oerrors;
-   IF_DEQUEUE

Re: problem w/ dlopen(); bug or feature?

[Terry Lambert]

Bjoern Fischer wrote:
> > Yes, it's possible to find out which shared object the dlopen call
> > was made from.  There's already a function obj_from_addr() in rtld.c
> > which does that.  But as far as I know, it is not standard behavior to
> > search the RPATH of the object which issued the dlopen call.
> 
> I only have seen an early draft of the current ELF spec, but I think
> the search strategy is simply unspecified in this point. Even so, the ELF
> spec probably would have specified to use the RPATH of the 'parent'
> object, because the ELF spec targets self containedness for all shared
> objects.
> 
> A shared object should be self contained. This is not possible for
> dlopen()ed objects with the current search strategy of the FreeBSD rtld.

It would be useful to be able to dlopen a shared object
that was linked against a Linux shared library, from inside
a FreeBSD binary that opens the shared object.

I think that FreeBSD still does not handle the ld and the
rtld code correctly, right now.

There was an issue that Archie Cobbs ran into with Kaffe;
it was not obvious to start with, but it boiled down to
a shared object needing symbols from another shared object,
and the dlopen not bringing in the second shared object
when the first was brought in (the Kaffe issue is that it
was in the context of a JNI).  The ugly workaround was to
link the Kaffe against the library that the shared object
needed to be linked against, so the symbols would be found.

There are also some issues with rtld of "RTLD_NOW" vs.
"RTLD_LAZY", when linking against shared libraries.  In
particular, the FreeBSD linker doesn't treat all symbols
as "RTLD_NOW" for liraries that reference libraries.

Specifically, if I have program A linked against library B
(shared), which needs library C (shared) for some of the
symbols it imports, the link will succeed anyway, and the
program will fail at runtime, if library C is not specified,
and there will not be an "unresolved symbols" error, as you
would expect (want) in the case that the library C is used
*only* by library B, and not by program A.

In other words, links are treated as "RTLD_LAZY" at link
time.

I went and tried to fix this in ld, at one time, but there
is a lot of sweater on the other end of that thread, if you
pull it, and I stopped when it became obvious that fixing
it for real would require some fundamental linker changes
for symbol reference counting (I had it fixed, but it was
over 300 lines of changes, and the resulting code was very
ugly).


Personally, I like the idea that linking a shared object
against a shared object should work to drag in the second,
when a main program links against the first.  The ELF spec
*dies* specify that that should work.

I like the "by extension" argument that would let me use
different versions of the same library in the same program,
based on an intermediate library being linked against a
different version than the main program (we're talking only
major version numbers here -- for minors, the one the main
program is linked against should override).  I don't know
how you would deal with data space, in that case, though.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: fork rate limit

[Gaspar Chilingarov]

-> Date: Sat, 2 Feb 2002 12:52:24 -0800 (PST)
-> From: Matthew Dillon <[EMAIL PROTECTED]>
-> To: Gaspar Chilingarov <[EMAIL PROTECTED]>
-> Cc: [EMAIL PROTECTED]
-> Subject: Re: fork rate limit
-> 
-> :Hi!
-> :
-> :Is it reasonable to administratively limit users' ability to call fork
-> :too other ? Users can take away too much CPU time even if you have
^^^ sorry, often, it's my typo :)
-> :limited them by login.conf 'cputime' limit - just forking lightweight
-> :processes too often.
-> :
-> :If it seems good thing to do, i'll try to code it and submit patches for
-> :-current. 
-> :
-> :I think this limit must go to struct uidinfo, am i right ? 
-> :Also i need to store per-user counters somewhere, can i place it there?
-> :
-> :-- 
-> :Gaspar Chilingarov
-> 
-> Well, we did make fork inherit the parent process's current
-> priority, so if a parent process forks() a lot it and its
-> children should get less cpu.  Beyond that the system can't really
-> tell whether the cpu use is something the sysad wants (i.e. sa
-> y it's a web server) or something the sysad doesn't want (an 
-> abusive user).
-> 
->  -Matt

i think SA can easily tell tehe system by assigning 
different uids assigned to them :)

I've got such situation on our free shellbox set up in the
university - some newbies were kidding with old while(1) fork();
attack. Finnaly they got hit by memory limits set up for each
user, but anyway they were taking a lot of processor time. I
prefer to limit some uid's ability to do many forks in some
short period - like 'no more than 200 forks in 10 seconds' or
smthng like this.

-- 
Gaspar 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: fork rate limit

[Matthew Dillon]

:Hi!
:
:Is it reasonable to administratively limit users' ability to call fork
:too other ? Users can take away too much CPU time even if you have
:limited them by login.conf 'cputime' limit - just forking lightweight
:processes too often.
:
:If it seems good thing to do, i'll try to code it and submit patches for
:-current. 
:
:I think this limit must go to struct uidinfo, am i right ? 
:Also i need to store per-user counters somewhere, can i place it there?
:
:-- 
:Gaspar Chilingarov

Well, we did make fork inherit the parent process's current
priority, so if a parent process forks() a lot it and its
children should get less cpu.  Beyond that the system can't really
tell whether the cpu use is something the sysad wants (i.e. sa
y it's a web server) or something the sysad doesn't want (an 
abusive user).

-Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

fork rate limit

[Gaspar Chilingarov]

Hi!

Is it reasonable to administratively limit users' ability to call fork
too other ? Users can take away too much CPU time even if you have
limited them by login.conf 'cputime' limit - just forking lightweight
processes too often.

If it seems good thing to do, i'll try to code it and submit patches for
-current. 

I think this limit must go to struct uidinfo, am i right ? 
Also i need to store per-user counters somewhere, can i place it there?

-- 
Gaspar Chilingarov

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

USB CDRW

[Matthew]

Is FreeBSD support CD-rewriting for an external USB CDRW?
--
WWW.XGFORCE.COM - 
The Next Generation System Clustering
and Enterprise Firewall/VPN Solutions.
--


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: buildworld via ro mounted /usr/src

[Simon 'corecode' Schubert]

On Fri, 1 Feb 2002 15:03:32 -0800 "Crist J. Clark"
<[EMAIL PROTECTED]> wrote:

> > The build procedure should be done as usual --
> > # make (env variables if not given in /etc/make.conf) -j4 buildworld
> > # make KERNCONF=FreeBEER KERNCONFDIR=/usr/local/etc/conf -j4
> > buildkernel# make KERNCONF=FreeBEER KERNCONFDIR=/usr/local/etc/conf
> > installkernel and so on...
> 
> No, I was confused. I thought we were discussing how to do an "old
> fashioned" kernel build in a read-only /usr/src/sys.

thanks for your replies ;]
actually the main problem was make needing MAKEOBJDIRPREFIX set as env var. perhaps 
there is a way to specify something like WRKDIRPREFIX (ports') for bsd.obj.mk.
after setting MAKEOBJDIRPREFIX to the right path and really cleaning /usr/src i was 
able to build world + kernel on a readonly /usr/src. though i needed to do
env MAKEOBJDIRPREFIX=/usr/obj/i386/k7 make buildworld -j4
 builds bootstrap tools, somewhere bails out on a rm i think.
env MAKEOBJDIRPREFIX=/usr/obj/i386/k7 make buildworld -j4 -DNOCLEAN
 then works as desired.
env MAKEOBJDIRPREFIX=/usr/obj/i386/k7 make buildkernel -j4
 works right out-of-the-box.

cheerz
  corecode

-- 
/"\   http://corecode.ath.cx/
\ /
 \ ASCII Ribbon Campaign
/ \  Against HTML Mail and News



msg31353/pgp0.pgp
Description: PGP signature

natd UDP errors with PPP demand dial

[Marko]

Hello,

My  question  is  concerning  the  popular  "netd[pid] failed to write
packet back [Permission denied]" message.

The  machine  is  FreeBSD 4.3R.  It connects to the Internet through a
PPP  demand dial link.  Natd is in dynamic mode.  The rules seem to be
ok, and packet filtering is working great.

The natd errors always log right at the end of the PPP link setup, and
intermittently  thereafter.  On  link  setup,  their  cause  from  the
security log is this:


Jan 25 19:37:45 PROTODOG /kernel: ipfw: 65000 Deny UDP 207.69.102.30:53 
207.69.99.196:1909 out via tun0
Jan 25 19:37:45 PROTODOG /kernel: ipfw: 65000 Deny UDP 207.69.102.30:41755 
207.69.99.196:1909 out via tun0
Jan 25 19:37:45 PROTODOG /kernel: ipfw: 65000 Deny UDP 207.69.102.30:53 
207.69.99.196:1909 out via tun0
Jan 25 19:37:45 PROTODOG /kernel: ipfw: 65000 Deny UDP 207.69.102.30:41755 
207.69.99.196:1909 out via tun0
Jan 25 19:37:45 PROTODOG /kernel: ipfw: 65000 Deny UDP 207.69.102.30:53 
207.69.99.196:1909 out via tun0

Jan 25 21:11:45 PROTODOG /kernel: ipfw: 65000 Deny UDP 207.69.101.242:53 
207.69.102.30:2138 out via tun0
Jan 25 21:11:45 PROTODOG /kernel: ipfw: 65000 Deny UDP 207.69.101.242:53 
207.69.102.30:2144 out via tun0
Jan 25 21:11:45 PROTODOG /kernel: ipfw: 65000 Deny UDP 207.69.101.242:53 
207.69.102.30:2144 out via tun0

There  are 2 PPP sessions depicted.  During the first, the machine had
the  207.69.102.30 IP, during the second - 207.69.101.242.  As you can
see,   it   tries  to  send  something via UDP to an IP it held during
the  previous  ppp  session.   Of  course, those attempts run into the
ipfw rules causing the natd error, and get rejected as they should be.

Some packets originate from very high ports, but there are always some
from port 53 on my machine.  Named is not running on it.

Tcpdump  doesn't  show  much  useful  stuff.  I think it's because the
packets never make it to the interface.

The  packets  don't come from my private network either because I have
the  internal interface shut off to most UDP traffic.  DNS queries are
directed  at  particular  servers  and work fine.  The problem packets
originate on the firewall machine.

My questions are: How do I find out what the machine is trying to send
in those rejected UDP packets?

Does this seem to be a bug, or do I have something configured wrong?(I
have  ruled  out opening UDP outbound rules and bombarding machines on
my previous IP's with nonsense.)

Thank you for any input YOU might have.

Marko


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: problem w/ dlopen(); bug or feature?

[Bjoern Fischer]

Hello John,

> Yes, it's possible to find out which shared object the dlopen call
> was made from.  There's already a function obj_from_addr() in rtld.c
> which does that.  But as far as I know, it is not standard behavior to
> search the RPATH of the object which issued the dlopen call.

I only have seen an early draft of the current ELF spec, but I think
the search strategy is simply unspecified in this point. Even so, the ELF
spec probably would have specified to use the RPATH of the 'parent'
object, because the ELF spec targets self containedness for all shared
objects.

A shared object should be self contained. This is not possible for
dlopen()ed objects with the current search strategy of the FreeBSD rtld.

> I try
> to follow the ELF specification and/or the behavior of Sun's dynamic
> linker, and I don't think either one specifies this sort of dynamic
> scoping.

I've not looked into the source code of Sun's dynamic linker (yet), but 
I have developed a lot on that platform and I am sure that the linker
uses the RPATH of the 'parent' object. You can prove it yourself by
running the small dlopen-test code I sent to hackers@ in the first mail
of this thread. I tried it on Sparc-Solaris 2.5.1 and x86-Solaris 8.

So I would by happy if you adapt the behavior of Sun's dynamic linker
for FreeBSD's rtld in this case.

> It's risky to get too creative in this area.  Usually doing
> so breaks several random ports.

It is not bad to be conservative, I agree. But isn't it that, what's
-CURRENT is for?

Ports can be fixed.

[tree structure]
> If you're talking about functionality, the linked list isn't the
> only data structure.  Each shared object is also inserted into a
> doubly-linked tree structure (actually a DAG) which represents the
> hierarchical relationships between the shared objects.  That's done
> using the "dldags" and "dlmembers" members of the Obj_Entry structure.

Exactly. That's what I was looking for. Thanks.

-Björn


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message