Re: Why can't I flush /dev/ram0?
On Mon, 18 Jun 2001, Kelledin Tane wrote: > At this point, I'm trying to get an initrd working properly. So far, it > works, the system boots, etc. etc., but whenever I try to do a "blockdev > --flushbufs /dev/ram0", I get "device or resource busy" > > When I mount the filesystem to check it out, nothing appears to have > anything open on the filesystem. So why am I not able to flush it > clean? Because of a bug present in Linus tree. Try this patch: --- linux.orig/drivers/block/rd.c Mon Nov 20 02:07:47 2000 +++ linux/drivers/block/rd.cMon Nov 20 04:03:42 2000 @@ -690,6 +690,7 @@ done: if (infile.f_op->release) infile.f_op->release(inode, &infile); + blkdev_put(out_inode->i_bdev, BDEV_FILE); set_fs(fs); return; free_inodes: /* free inodes on error */ BTW, it's fixed in -ac patches. Jan -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] zerocopy BETA 3
On Sun, 25 Feb 2001, Chris Wedgwood wrote:
> On Fri, Feb 23, 2001 at 11:42:49AM +0100, Jan Rekorajski wrote:
>
> Could you please make a patch with this fix only? Or is it
> available somewhere?
>
[cut incomplete patch ;)]
There are more changes, I hacked'em out of vger CVS:
diff -urN linux/include/net/ip.h linux.fixed/include/net/ip.h
--- linux/include/net/ip.h Thu Feb 22 01:10:38 2001
+++ linux.fixed/include/net/ip.hFri Feb 23 14:40:40 2001
@@ -188,11 +188,16 @@
extern void __ip_select_ident(struct iphdr *iph, struct dst_entry *dst);
-static inline void ip_select_ident(struct iphdr *iph, struct dst_entry *dst)
+static inline void ip_select_ident(struct iphdr *iph, struct dst_entry *dst, struct
+sock *sk)
{
- if (iph->frag_off&__constant_htons(IP_DF))
- iph->id = 0;
- else
+ if (iph->frag_off&__constant_htons(IP_DF)) {
+ /* This is only to work around buggy Windows95/2000
+* VJ compression implementations. If the ID field
+* does not change, they drop every other packet in
+* a TCP stream using header compression.
+*/
+ iph->id = (sk ? sk->protinfo.af_inet.id++ : 0);
+ } else
__ip_select_ident(iph, dst);
}
diff -urN linux/include/net/ipip.h linux.fixed/include/net/ipip.h
--- linux/include/net/ipip.hSat Aug 5 03:18:49 2000
+++ linux.fixed/include/net/ipip.h Fri Feb 23 14:40:43 2001
@@ -30,7 +30,7 @@
int pkt_len = skb->len; \
\
iph->tot_len = htons(skb->len); \
- ip_select_ident(iph, &rt->u.dst); \
+ ip_select_ident(iph, &rt->u.dst, NULL); \
ip_send_check(iph); \
\
err = NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL, rt->u.dst.dev, do_ip_send);
\
diff -urN linux/include/net/sock.h linux.fixed/include/net/sock.h
--- linux/include/net/sock.hThu Feb 22 01:10:24 2001
+++ linux.fixed/include/net/sock.h Fri Feb 23 14:40:49 2001
@@ -204,6 +204,7 @@
__u8mc_loop;/* Loopback */
unsignedrecverr : 1,
freebind : 1;
+ __u16 id; /* ID counter for DF pkts */
__u8pmtudisc;
int mc_index; /* Multicast device index */
__u32 mc_addr;
diff -urN linux/net/ipv4/af_inet.c linux.fixed/net/ipv4/af_inet.c
--- linux/net/ipv4/af_inet.cFri Dec 29 23:07:24 2000
+++ linux.fixed/net/ipv4/af_inet.c Fri Feb 23 14:40:34 2001
@@ -355,6 +355,8 @@
else
sk->protinfo.af_inet.pmtudisc = IP_PMTUDISC_WANT;
+ sk->protinfo.af_inet.id = 0;
+
sock_init_data(sock,sk);
sk->destruct = inet_sock_destruct;
diff -urN linux/net/ipv4/igmp.c linux.fixed/net/ipv4/igmp.c
--- linux/net/ipv4/igmp.c Tue Jan 9 19:54:57 2001
+++ linux.fixed/net/ipv4/igmp.c Fri Feb 23 14:40:38 2001
@@ -235,7 +235,7 @@
iph->saddr= rt->rt_src;
iph->protocol = IPPROTO_IGMP;
iph->tot_len = htons(IGMP_SIZE);
- ip_select_ident(iph, &rt->u.dst);
+ ip_select_ident(iph, &rt->u.dst, NULL);
((u8*)&iph[1])[0] = IPOPT_RA;
((u8*)&iph[1])[1] = 4;
((u8*)&iph[1])[2] = 0;
diff -urN linux/net/ipv4/ip_output.c linux.fixed/net/ipv4/ip_output.c
--- linux/net/ipv4/ip_output.c Fri Oct 27 20:03:14 2000
+++ linux.fixed/net/ipv4/ip_output.cFri Feb 23 14:54:17 2001
@@ -141,7 +141,7 @@
iph->saddr= rt->rt_src;
iph->protocol = sk->protocol;
iph->tot_len = htons(skb->len);
- ip_select_ident(iph, &rt->u.dst);
+ ip_select_ident(iph, &rt->u.dst, sk);
skb->nh.iph = iph;
if (opt && opt->optlen) {
@@ -307,7 +307,7 @@
if (ip_dont_fragment(sk, &rt->u.dst))
iph->frag_off |= __constant_htons(IP_DF);
- ip_select_ident(iph, &rt->u.dst);
+ ip_select_ident(iph, &rt->u.dst, sk);
/* Add an IP checksum. */
ip_send_check(iph);
@@ -328,7 +328,7 @@
kfree_skb(skb);
return -EMSGSIZE;
}
- ip_select_ident(iph, &rt->u.dst);
+ ip_select_ident(iph, &rt->u.dst, sk);
return ip_fragment(skb, skb->dst->output);
}
@@ -425,7 +425,7 @@
int err;
int offset, mf;
int mtu;
- u16 id = 0;
+ u16 id;
int hh_len =
Re: [UPDATE] zerocopy BETA 3
On Thu, 22 Feb 2001, David S. Miller wrote: > > Usual spot: > > ftp://ftp.kernel.org/pub/linux/kernel/people/davem/zerocopy-2.4.2-2.diff.gz > > Changes since last installment: > > 3) Workaround for win2000/95 VJ header compression bugs is >implemented. Could you please make a patch with this fix only? Or is it available somewhere? Jan -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ATM breakage introduced in 2.4.0
Hi,
2.4.0 introduced serious breakage to LANE. It's impossible to do
ifdown lec? ; ifup lec? because memory allocated by lec? is freed but
unregister_netdev() is not called, so SIOCGIFFLAGS tells me ok, but
SIOCSIFFLAGS tells me -ENODEV. No, rmmod lec ; insmod lec does not help.
Patch follows
--- linux/net/atm/lec.c.origThu Jan 11 19:40:50 2001
+++ linux/net/atm/lec.c Thu Jan 11 19:42:20 2001
@@ -858,8 +858,11 @@
if (dev_lec[i] != NULL) {
priv = (struct lec_priv *)dev_lec[i]->priv;
#if defined(CONFIG_TR)
-unregister_trdev(dev_lec[i]);
+ if (priv->is_trdev)
+ unregister_trdev(dev_lec[i]);
+ else
#endif
+unregister_netdev(dev_lec[i]);
kfree(dev_lec[i]);
dev_lec[i] = NULL;
}
And it would be nice if I was able to build Fore 200e driver in 2.4.1 ;)
--- linux/drivers/atm/Makefile.orig Tue Jan 2 10:18:25 2001
+++ linux/drivers/atm/Makefile Tue Jan 2 12:00:05 2001
@@ -46,7 +46,7 @@
endif
endif
-obj-$(CONFIG_ATM_FORE200E) += fore200e.o $(FORE200E_FW_OBJS)
+obj-$(CONFIG_ATM_FORE200E) += fore_200e.o
include $(TOPDIR)/Rules.make
Jan
--
Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD!
bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, MANIAC | -- TROOPS by Kevin Rubio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.0 drivers/atm/Makefile...
...is still broken. It does not build Fore 200e driver. Jan --- linux/drivers/atm/Makefile.orig Tue Jan 2 10:18:25 2001 +++ linux/drivers/atm/Makefile Tue Jan 2 12:00:05 2001 @@ -46,7 +46,7 @@ endif endif -obj-$(CONFIG_ATM_FORE200E) += fore200e.o $(FORE200E_FW_OBJS) +obj-$(CONFIG_ATM_FORE200E) += fore_200e.o include $(TOPDIR)/Rules.make -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Makefile fix for FORE 200e and a typo in lec.c
Hi,
The Fore dirver in 2.4.0-prerelease just does not build
with the current makefile. This patch fixes it (works for me):
--- linux/drivers/atm/Makefile.orig Tue Jan 2 10:18:25 2001
+++ linux/drivers/atm/Makefile Tue Jan 2 12:00:05 2001
@@ -46,7 +46,7 @@
endif
endif
-obj-$(CONFIG_ATM_FORE200E) += fore200e.o $(FORE200E_FW_OBJS)
+obj-$(CONFIG_ATM_FORE200E) += fore_200e.o
include $(TOPDIR)/Rules.make
Second thing, there is a typo in net/atm/lec.c:
--- linux/net/atm/lec.c.origSat Dec 30 20:19:13 2000
+++ linux/net/atm/lec.c Tue Jan 2 12:06:34 2001
@@ -857,7 +857,7 @@
for (i = 0; i < MAX_LEC_ITF; i++) {
if (dev_lec[i] != NULL) {
priv = (struct lec_priv *)dev_lec[i]->priv;
-unregister_trdev(dev_lec[i]);
+unregister_netdev(dev_lec[i]);
kfree(dev_lec[i]);
dev_lec[i] = NULL;
}
And, just in case you missed it, modular LEC fix:
--- linux/net/atm/Makefile.orig Sun Dec 31 17:57:15 2000
+++ linux/net/atm/Makefile Sun Dec 31 19:04:49 2000
@@ -33,7 +33,13 @@
obj-y += proc.o
endif
-obj-$(CONFIG_ATM_LANE) += lec.o lane_mpoa_init.o
+ifneq ($(CONFIG_ATM_LANE),n)
+ifneq ($(CONFIG_ATM_LANE),)
+obj-y += lane_mpoa_init.o
+endif
+endif
+
+obj-$(CONFIG_ATM_LANE) += lec.o
obj-$(CONFIG_ATM_MPOA) += mpoa.o
include $(TOPDIR)/Rules.make
Jan
--
Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD!
bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, MANIAC | -- TROOPS by Kevin Rubio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ATM LANE modular build
Hi, Due to latest Makefile changes ATM LANE won't build as module. The following patch fixes it. --- linux/net/atm/Makefile.orig Sun Dec 31 17:57:15 2000 +++ linux/net/atm/Makefile Sun Dec 31 19:04:49 2000 @@ -33,7 +33,13 @@ obj-y += proc.o endif -obj-$(CONFIG_ATM_LANE) += lec.o lane_mpoa_init.o +ifneq ($(CONFIG_ATM_LANE),n) +ifneq ($(CONFIG_ATM_LANE),) +obj-y += lane_mpoa_init.o +endif +endif + +obj-$(CONFIG_ATM_LANE) += lec.o obj-$(CONFIG_ATM_MPOA) += mpoa.o include $(TOPDIR)/Rules.make Jan -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 problem
On Sun, 10 Dec 2000, Maciej Bogucki wrote: > HI! > I have 2.4.0-test9 and 2.2.16 kernel compiled on my computer .I have > httpd server on this computer . With 2.2.16 apache work good ( via DSL > and modem ), but with 2.4 ( the same computer ) , when I wont to connect > to my page via modem first few kilobytes are downloaded "fast" and then > connection slow down and transfer rate is 1byte per second . When I > download this page from linux ( via modem ) everything is ok ! I have > this problem , when I want to see this this page from MS Windows > computers only via ppp connection . I have tested it on two different > computer and result is the same . > > I have seek this proble on mailing lists , but I haven't found . Have > anybody had the same problem like me ? Same here, tested on 2.4.0-test6 up to test11 :( Jan -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] no RLIMIT_NPROC for root, please
On Thu, 30 Nov 2000, Pavel Machek wrote: > Hi! > > > > On Tue, 28 Nov 2000, Jan Rekorajski wrote: > > > > --- linux/kernel/fork.c~Tue Sep 5 23:48:59 2000 > > > > +++ linux/kernel/fork.c Sun Nov 26 20:22:20 2000 > > > > @@ -560,7 +560,8 @@ > > > > *p = *current; > > > > > > > > retval = -EAGAIN; > > > > - if (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur) > > > > + if (p->user->uid && > > > > + (atomic_read(&p->user->processes) >= >p->rlim[RLIMIT_NPROC].rlim_cur)) > > > > > > Jan, > > > > > > Hardcoding things signifying special treatment of uid=0 is almost always a > > > bad idea. If you _really_ think that superuser (whatever entity that might > > > be) should be exempt from RLIMIT_NPROC and can prove that (SuSv2 seems to > > > be silent so you may be right), then you should use capable() to do proper > > > capability test and not that horrible explicit uid test as in your patch > > > above. > > > > Ok, how about setting limits on login? When this looks like: > > > > --- uid = 0 here > > setrlimit(RLIMIT_NPROC, n) > > fork() <- this will fail if root has >n processes > > setuid(user) > > > > and it is hard to change this sequence, all PAM enabled apps depend > > on it :( > > So PAM dictates kernel changes? Fix pam, do not break kernel. Fixed :) Jan -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, type MANIAC | -- TROOPS by Kevin Rubio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] no RLIMIT_NPROC for root, please
On Tue, 28 Nov 2000, Alan Cox wrote: > > Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel j= > > ob to > > prevent admin from shooting him/her self in the foot. > > > > root should be able to do fork() regardless of any limits, > > and IMHO the following patch is the right thing. > > This patch is bogus. root can always raise their limit. But having root > tasks by default not take out the box is good OK, I just fix applications that assume root = no limits ;) Jan -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, type MANIAC | -- TROOPS by Kevin Rubio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] no RLIMIT_NPROC for root, please
On Tue, 28 Nov 2000, Andreas Schwab wrote: > Jan Rekorajski <[EMAIL PROTECTED]> writes: > > |> Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel job to > |> prevent admin from shooting him/her self in the foot. > |> > |> root should be able to do fork() regardless of any limits, > |> and IMHO the following patch is the right thing. > > AFAICS, _all_ resource limits are equally applied to root processes. Why > should NPROC be different? Because you want to be able to `kill `? And if you are over-limits you can't? Jan -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, type MANIAC | -- TROOPS by Kevin Rubio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] no RLIMIT_NPROC for root, please
On Tue, 28 Nov 2000, Tigran Aivazian wrote: > On Tue, 28 Nov 2000, Jan Rekorajski wrote: > > --- linux/kernel/fork.c~Tue Sep 5 23:48:59 2000 > > +++ linux/kernel/fork.c Sun Nov 26 20:22:20 2000 > > @@ -560,7 +560,8 @@ > > *p = *current; > > > > retval = -EAGAIN; > > - if (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur) > > + if (p->user->uid && > > + (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur)) > > Jan, > > Hardcoding things signifying special treatment of uid=0 is almost always a > bad idea. If you _really_ think that superuser (whatever entity that might > be) should be exempt from RLIMIT_NPROC and can prove that (SuSv2 seems to > be silent so you may be right), then you should use capable() to do proper > capability test and not that horrible explicit uid test as in your patch > above. Ok, how about setting limits on login? When this looks like: --- uid = 0 here setrlimit(RLIMIT_NPROC, n) fork() <- this will fail if root has >n processes setuid(user) and it is hard to change this sequence, all PAM enabled apps depend on it :( The other scenario may be when root has already n processes, call them system stuff, and cannot login or even kill anything because of limits. Is this patch better? I put CAP_SYS_RESOURCE, but maybe it should be CAP_SYS_ADMIN. --- linux/kernel/fork.c~Fri Nov 17 15:09:26 2000 +++ linux/kernel/fork.c Tue Nov 28 22:02:17 2000 @@ -562,7 +562,8 @@ *p = *current; retval = -EAGAIN; - if (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur) + if ((atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur) && + !capable(CAP_SYS_RESOURCE)) goto bad_fork_free; atomic_inc(&p->user->__count); atomic_inc(&p->user->processes); Jan -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, type MANIAC | -- TROOPS by Kevin Rubio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] no RLIMIT_NPROC for root, please
Why is RLIMIT_NPROC apllied to root(uid 0) processes? It's not kernel job to prevent admin from shooting him/her self in the foot. root should be able to do fork() regardless of any limits, and IMHO the following patch is the right thing. --- linux/kernel/fork.c~Tue Sep 5 23:48:59 2000 +++ linux/kernel/fork.c Sun Nov 26 20:22:20 2000 @@ -560,7 +560,8 @@ *p = *current; retval = -EAGAIN; - if (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur) + if (p->user->uid && + (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur)) goto bad_fork_free; atomic_inc(&p->user->__count); atomic_inc(&p->user->processes); Jan -- Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, type MANIAC | -- TROOPS by Kevin Rubio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: setrlimit() and 2.4.0-test11
On Wed, 22 Nov 2000, Arkadiusz Miskiewicz wrote:
>
> Is probably broken (I didnt't saw any disscusion about this here,
> I missed it?).
>
> when I try to start first user process I get:
> 4366 fork()= -1 EAGAIN (Resource temporarily
>unavailable)
> but strace show proper value passed to setrlimit() -- 40 max number of processes:
> 4366 setrlimit(0x6 /* RLIMIT_??? */, {rlim_cur=40, rlim_max=40}) = 0
>
> On test10 everything is ok.
No, you are just lucky.
The problem is that root (uid=0) is not a special case anymore, and you can't
do something like this:
setrlimit(NPROC)
fork()
setuid(user)
setrlimit() and fork() are executed in root context, so sterlimit
apllies to root, not the user you're setuid to :(
Why is this so? root should be able to do fork() regardless of any limits,
and IMHO the following patch is the right thing.
--- linux/kernel/fork.c~Tue Sep 5 23:48:59 2000
+++ linux/kernel/fork.c Sun Nov 26 20:22:20 2000
@@ -560,7 +560,8 @@
*p = *current;
retval = -EAGAIN;
- if (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur)
+ if (p->user->uid &&
+ (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur))
goto bad_fork_free;
atomic_inc(&p->user->__count);
atomic_inc(&p->user->processes);
Jan
--
Jan Rękorajski| ALL SUSPECTS ARE GUILTY. PERIOD!
bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, type MANIAC | -- TROOPS by Kevin Rubio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
