On Sunday, March 30, 2014 07:07:54 PM Eric Paris wrote:
It its possible to configure your PAM stack to refuse login if
audit messages (about the login) were unable to be sent. This is common
in many distros and thus normal configuration of many containers. The
PAM modules determine if audit
Hello Mimi,
On Wednesday, April 02, 2014 01:39:47 PM Mimi Zohar wrote:
> This change is already being upstreamed as commit 73a6b44 "Integrity:
> Pass commname via get_task_comm()".
While I was looking at Richard's patch, I noticed a few places where cause and
op are logged and the string isn't
Hello Mimi,
On Wednesday, April 02, 2014 01:39:47 PM Mimi Zohar wrote:
This change is already being upstreamed as commit 73a6b44 Integrity:
Pass commname via get_task_comm().
While I was looking at Richard's patch, I noticed a few places where cause and
op are logged and the string isn't tied
On Saturday, March 15, 2014 07:28:46 PM Richard Guy Briggs wrote:
> I'm inclined to go get_task_comm() in all 5 locations, but if we care
> more about locking overhead, I'll switch to memcpy().
>
> Steve, do we care about the integrity of the comm field?
In the case of interpreters, its about
On Saturday, March 15, 2014 07:28:46 PM Richard Guy Briggs wrote:
I'm inclined to go get_task_comm() in all 5 locations, but if we care
more about locking overhead, I'll switch to memcpy().
Steve, do we care about the integrity of the comm field?
In the case of interpreters, its about the
On Friday, March 07, 2014 07:48:01 PM David Miller wrote:
> From: Eric Paris
> Date: Fri, 07 Mar 2014 17:52:02 -0500
>
> > Audit is non-tolerant to failure and loss.
>
> Netlink is not a loss-less transport.
Perhaps. But in all our testing over the years its been very good.
-Steve
--
To
On Friday, March 07, 2014 07:48:01 PM David Miller wrote:
From: Eric Paris epa...@redhat.com
Date: Fri, 07 Mar 2014 17:52:02 -0500
Audit is non-tolerant to failure and loss.
Netlink is not a loss-less transport.
Perhaps. But in all our testing over the years its been very good.
-Steve
On Tuesday, March 04, 2014 07:21:52 PM David Miller wrote:
> From: ebied...@xmission.com (Eric W. Biederman)
> Date: Tue, 04 Mar 2014 14:41:16 -0800
>
> > If we really want the ability to always appened to the queue of skb's
> > is to just have a version of netlink_send_skb that ignores the
On Tuesday, March 04, 2014 07:21:52 PM David Miller wrote:
From: ebied...@xmission.com (Eric W. Biederman)
Date: Tue, 04 Mar 2014 14:41:16 -0800
If we really want the ability to always appened to the queue of skb's
is to just have a version of netlink_send_skb that ignores the queued
On Tuesday, February 18, 2014 03:50:44 PM Richard Guy Briggs wrote:
> > missing '=' but this isn't what audit_get_context() does... it's
> > crappy naming...I'd think a combo of audit_dummy_context() and
> > current->audit_context would be most appropriate.
>
> Ok. I think I finally
On Tuesday, February 18, 2014 03:50:44 PM Richard Guy Briggs wrote:
missing '=' but this isn't what audit_get_context() does... it's
crappy naming...I'd think a combo of audit_dummy_context() and
current-audit_context would be most appropriate.
Ok. I think I finally understand
On Monday, February 10, 2014 11:01:36 AM Andy Lutomirski wrote:
> >> And I still think this needs more changes. Once again, I do not think
> >> that, say, __audit_log_bprm_fcaps() should populate context->aux if
> >> !TIF_SYSCALL_AUDIT, this list can grow indefinitely. Or
> >>
On Monday, February 10, 2014 09:29:19 AM Andy Lutomirski wrote:
> Grr. Why is all this crap tied up with syscall auditing anyway? ISTM
> it would have been a lot nicer if audit calls just immediately emitted
> audit records, completely independently of the syscall machinery.
Because the
On Monday, February 10, 2014 09:29:19 AM Andy Lutomirski wrote:
Grr. Why is all this crap tied up with syscall auditing anyway? ISTM
it would have been a lot nicer if audit calls just immediately emitted
audit records, completely independently of the syscall machinery.
Because the majority
On Monday, February 10, 2014 11:01:36 AM Andy Lutomirski wrote:
And I still think this needs more changes. Once again, I do not think
that, say, __audit_log_bprm_fcaps() should populate context-aux if
!TIF_SYSCALL_AUDIT, this list can grow indefinitely. Or
__audit_signal_info()...
On Thursday, February 06, 2014 10:15:28 AM William Roberts wrote:
> During an audit event, cache and print the value of the process's
> proctitle value (proc//cmdline). This is useful in situations
> where processes are started via fork'd virtual machines where the
> comm field is incorrect. Often
On Thursday, February 06, 2014 10:15:28 AM William Roberts wrote:
During an audit event, cache and print the value of the process's
proctitle value (proc/pid/cmdline). This is useful in situations
where processes are started via fork'd virtual machines where the
comm field is incorrect. Often
On Monday, February 03, 2014 09:53:23 AM Andy Lutomirski wrote:
> This toggles TIF_SYSCALL_AUDIT as needed when rules change instead of
> leaving it set whenever rules might be set in the future. This reduces
> syscall latency from >60ns to closer to 40ns on my laptop.
Does this mean that we
On Saturday, February 01, 2014 06:51:56 PM Andy Lutomirski wrote:
> On Sat, Feb 1, 2014 at 6:32 PM, Andy Lutomirski wrote:
> > On a stock Fedora installation:
> >
> > $ sudo auditctl -l
> > No rules
What rules would you want? The audit package ships with several which affects
performance to
On Saturday, February 01, 2014 06:51:56 PM Andy Lutomirski wrote:
On Sat, Feb 1, 2014 at 6:32 PM, Andy Lutomirski l...@amacapital.net wrote:
On a stock Fedora installation:
$ sudo auditctl -l
No rules
What rules would you want? The audit package ships with several which affects
On Monday, February 03, 2014 09:53:23 AM Andy Lutomirski wrote:
This toggles TIF_SYSCALL_AUDIT as needed when rules change instead of
leaving it set whenever rules might be set in the future. This reduces
syscall latency from 60ns to closer to 40ns on my laptop.
Does this mean that we have
On Thursday, January 16, 2014 07:03:34 AM William Roberts wrote:
> On Thu, Jan 16, 2014 at 6:02 AM, Steve Grubb wrote:
> > On Wednesday, January 15, 2014 09:08:39 PM William Roberts wrote:
> >> >> > Try this,
> >> >> >
> >> >> > cp
On Wednesday, January 15, 2014 09:08:39 PM William Roberts wrote:
> >> > Try this,
> >> >
> >> > cp /bin/ls 'test test test'
> >> > auditctll -a always,exit -F arch=b64 -S stat -k test
> >> > ./test\ test\ test './test\ test\ test'
> >> > auditctl -D
> >> > ausearch --start recent --key test
> >>
On Wednesday, January 15, 2014 09:08:39 PM William Roberts wrote:
Try this,
cp /bin/ls 'test test test'
auditctll -a always,exit -F arch=b64 -S stat -k test
./test\ test\ test './test\ test\ test'
auditctl -D
ausearch --start recent --key test
On the event of weird
On Thursday, January 16, 2014 07:03:34 AM William Roberts wrote:
On Thu, Jan 16, 2014 at 6:02 AM, Steve Grubb sgr...@redhat.com wrote:
On Wednesday, January 15, 2014 09:08:39 PM William Roberts wrote:
Try this,
cp /bin/ls 'test test test'
auditctll -a always,exit -F arch=b64 -S
On Wednesday, January 15, 2014 05:44:29 PM William Roberts wrote:
> On Wed, Jan 15, 2014 at 5:33 PM, Steve Grubb wrote:
> > On Wednesday, January 15, 2014 05:08:13 PM William Roberts wrote:
> >> On Wed, Jan 15, 2014 at 4:54 PM, Steve Grubb wrote:
> >> > On Wednesday
On Wednesday, January 15, 2014 05:08:13 PM William Roberts wrote:
> On Wed, Jan 15, 2014 at 4:54 PM, Steve Grubb wrote:
> > On Wednesday, January 15, 2014 01:02:14 PM William Roberts wrote:
> >> During an audit event, cache and print the value of the process's
> >> c
On Wednesday, January 15, 2014 01:02:14 PM William Roberts wrote:
> During an audit event, cache and print the value of the process's
> cmdline value (proc//cmdline). This is useful in situations
> where processes are started via fork'd virtual machines where the
> comm field is incorrect. Often
On Wednesday, January 15, 2014 01:02:14 PM William Roberts wrote:
During an audit event, cache and print the value of the process's
cmdline value (proc/pid/cmdline). This is useful in situations
where processes are started via fork'd virtual machines where the
comm field is incorrect. Often
On Wednesday, January 15, 2014 05:08:13 PM William Roberts wrote:
On Wed, Jan 15, 2014 at 4:54 PM, Steve Grubb sgr...@redhat.com wrote:
On Wednesday, January 15, 2014 01:02:14 PM William Roberts wrote:
During an audit event, cache and print the value of the process's
cmdline value (proc/pid
On Wednesday, January 15, 2014 05:44:29 PM William Roberts wrote:
On Wed, Jan 15, 2014 at 5:33 PM, Steve Grubb sgr...@redhat.com wrote:
On Wednesday, January 15, 2014 05:08:13 PM William Roberts wrote:
On Wed, Jan 15, 2014 at 4:54 PM, Steve Grubb sgr...@redhat.com wrote:
On Wednesday
On Wednesday, September 18, 2013 03:06:52 PM Richard Guy Briggs wrote:
> Re-named confusing local variable names (status_set and status_get didn't
> agree with their command type name) and reduced their scope.
>
> Future-proof API changes by not depending on the exact size of the
> audit_status
On Wednesday, September 18, 2013 03:06:52 PM Richard Guy Briggs wrote:
Re-named confusing local variable names (status_set and status_get didn't
agree with their command type name) and reduced their scope.
Future-proof API changes by not depending on the exact size of the
audit_status
On Sunday, September 08, 2013 05:54:35 PM Oleg Nesterov wrote:
> Sorry for delay, vacation.
>
> First of all, I do not pretend I understand this code. This was mostly
> the question, and in fact I mostly asked about audit_bprm() in 0/1.
>
> However,
>
> On
On Tuesday, September 10, 2013 07:20:33 PM Oleg Nesterov wrote:
> On 09/08, Oleg Nesterov wrote:
> > First of all, I do not pretend I understand this code. This was mostly
> > the question, and in fact I mostly asked about audit_bprm() in 0/1.
> >
> > However,
> >
On Tuesday, September 10, 2013 07:20:33 PM Oleg Nesterov wrote:
On 09/08, Oleg Nesterov wrote:
First of all, I do not pretend I understand this code. This was mostly
the question, and in fact I mostly asked about audit_bprm() in 0/1.
However,
On 08/30, Steve Grubb wrote
On Sunday, September 08, 2013 05:54:35 PM Oleg Nesterov wrote:
Sorry for delay, vacation.
First of all, I do not pretend I understand this code. This was mostly
the question, and in fact I mostly asked about audit_bprm() in 0/1.
However,
On 08/30, Steve Grubb wrote:
On Friday, August
On Friday, August 30, 2013 03:06:46 PM Richard Guy Briggs wrote:
> On Tue, Aug 27, 2013 at 07:11:34PM +0200, Oleg Nesterov wrote:
> > Btw. audit looks unmaintained... if you are going to take care of
> > this code, perhaps you can look at
> >
> >
On Friday, August 30, 2013 03:06:46 PM Richard Guy Briggs wrote:
On Tue, Aug 27, 2013 at 07:11:34PM +0200, Oleg Nesterov wrote:
Btw. audit looks unmaintained... if you are going to take care of
this code, perhaps you can look at
http://marc.info/?l=linux-kernelm=137589907108485
ed-off-by: is appropriate
> for me in this case, but I'll throw in a:
>
> Tested-by: Richard Guy Briggs
>
> and recommend a:
>
> Reported-By: Steve Grubb
If this is the approved patch, can it be put in stable? The audit system
hasn't worked as intended since January.
Thank
and recommend a:
Reported-By: Steve Grubb sbr...@redhat.com
If this is the approved patch, can it be put in stable? The audit system
hasn't worked as intended since January.
Thanks,
-Steve
From: Eric W. Biederman ebied...@xmission.com
Date: Tue, 9 Apr 2013 02:22:10 -0700
Subject: [PATCH
On Tuesday, April 09, 2013 02:39:32 AM Eric W. Biederman wrote:
> Andrew Morton writes:
> > On Wed, 20 Mar 2013 15:18:17 -0400 Richard Guy Briggs
wrote:
> >> audit rule additions containing "-F auid!=4294967295" were failing with
> >> EINVAL.
> >>
> >> UID_INVALID (and GID_INVALID) is actually
On Tuesday, April 09, 2013 02:39:32 AM Eric W. Biederman wrote:
Andrew Morton a...@linux-foundation.org writes:
On Wed, 20 Mar 2013 15:18:17 -0400 Richard Guy Briggs r...@redhat.com
wrote:
audit rule additions containing -F auid!=4294967295 were failing with
EINVAL.
UID_INVALID (and
On Monday, November 26, 2012 09:45:56 AM Kees Cook wrote:
> On Mon, Nov 26, 2012 at 6:14 AM, Steve Grubb wrote:
> > On Monday, November 19, 2012 01:56:53 PM Kees Cook wrote:
> >> The seccomp path was using AUDIT_ANOM_ABEND from when seccomp mode 1
> >> could only kil
On Monday, November 26, 2012 09:45:56 AM Kees Cook wrote:
On Mon, Nov 26, 2012 at 6:14 AM, Steve Grubb sgr...@redhat.com wrote:
On Monday, November 19, 2012 01:56:53 PM Kees Cook wrote:
The seccomp path was using AUDIT_ANOM_ABEND from when seccomp mode 1
could only kill a process. While we
On Monday, November 19, 2012 01:56:53 PM Kees Cook wrote:
> The seccomp path was using AUDIT_ANOM_ABEND from when seccomp mode 1
> could only kill a process. While we still want to make sure an audit
> record is forced on a kill, this should use a separate record type since
> seccomp mode 2
On Monday, November 19, 2012 01:56:53 PM Kees Cook wrote:
The seccomp path was using AUDIT_ANOM_ABEND from when seccomp mode 1
could only kill a process. While we still want to make sure an audit
record is forced on a kill, this should use a separate record type since
seccomp mode 2 introduces
On Wednesday 07 November 2007 12:04:46 am Yuichi Nakamura wrote:
> I found syscall audit does not work on SH(SuperH).
> I made patch to support syscall audit for SH.
I think this is close, but it looks like you missed the syscall classification
piece. You can find an example here:
On Wednesday 07 November 2007 12:04:46 am Yuichi Nakamura wrote:
I found syscall audit does not work on SH(SuperH).
I made patch to support syscall audit for SH.
I think this is close, but it looks like you missed the syscall classification
piece. You can find an example here:
On Thursday 01 November 2007 01:23:24 pm Tony Jones wrote:
> > We are looking into this - at one time it did. Someone should follow up
> > with a path correcting this soon. But I doubt the audit system will work
> > correctly if the flag gets removed as there is no good way to add it
> > again
On Monday 29 October 2007 07:15:30 pm Tony Jones wrote:
> On Mon, Oct 29, 2007 at 06:04:31PM -0400, Steve Grubb wrote:
> > So when audit is re-enabled, how do you make that task auditable?
>
> No idea. How do you do it currently? HINT: current->audit_context == NULL
On Monday 29 October 2007 07:15:30 pm Tony Jones wrote:
On Mon, Oct 29, 2007 at 06:04:31PM -0400, Steve Grubb wrote:
So when audit is re-enabled, how do you make that task auditable?
No idea. How do you do it currently? HINT: current-audit_context == NULL
for these tasks. If !audit_enabled
On Thursday 01 November 2007 01:23:24 pm Tony Jones wrote:
We are looking into this - at one time it did. Someone should follow up
with a path correcting this soon. But I doubt the audit system will work
correctly if the flag gets removed as there is no good way to add it
again later.
So
On Monday 29 October 2007 01:20:58 pm Tony Jones wrote:
> > The problem is that removing that flag makes the children unauditable in
> > the future. The only place that flag gets set is during fork.
>
> I don't see this.
If the child does not have the TIF_SYSCALL_AUDIT flag, it never goes into
On Monday 29 October 2007 01:20:58 pm Tony Jones wrote:
The problem is that removing that flag makes the children unauditable in
the future. The only place that flag gets set is during fork.
I don't see this.
If the child does not have the TIF_SYSCALL_AUDIT flag, it never goes into
On Friday 26 October 2007 04:42:28 pm Tony Jones wrote:
> Thread flag TIF_SYSCALL_AUDIT is not cleared for new children when audit
> context creation has been disabled (auditctl -e0). This can cause new
> children forked from a parent created when audit was enabled to not take
> the fastest
On Friday 26 October 2007 04:42:28 pm Tony Jones wrote:
Thread flag TIF_SYSCALL_AUDIT is not cleared for new children when audit
context creation has been disabled (auditctl -e0). This can cause new
children forked from a parent created when audit was enabled to not take
the fastest syscall
On Sunday 29 July 2007 11:02:33 Adrian Bunk wrote:
> They are still completely unused, but hopefully some of the theoretical
> code that might use it will appear in the kernel in the near future...
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> Acked-by: Steve Grubb <
On Sunday 29 July 2007 11:02:33 Adrian Bunk wrote:
They are still completely unused, but hopefully some of the theoretical
code that might use it will appear in the kernel in the near future...
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Steve Grubb [EMAIL PROTECTED]
I am
On Thursday 07 June 2007 11:42, Casey Schaufler wrote:
> > tools like rootsh, but that is too easy to detect and defeat. And then it
> > does not put its data into the audit system where its correlated with
> > other system events.
>
> The evaluation teams that I have worked with (OrangeBook and
On Thursday 07 June 2007 04:13:42 Jan Engelhardt wrote:
> >Add TTY input auditing, used to audit system administrator's actions.
>
> _What_ exactly does it audit?
In theory, it should audit the actions performed by the sysadmin. This patch
doesn't cover actions done via X windows interface.
>
On Thursday 07 June 2007 04:13:42 Jan Engelhardt wrote:
Add TTY input auditing, used to audit system administrator's actions.
_What_ exactly does it audit?
In theory, it should audit the actions performed by the sysadmin. This patch
doesn't cover actions done via X windows interface.
And
On Thursday 07 June 2007 11:42, Casey Schaufler wrote:
tools like rootsh, but that is too easy to detect and defeat. And then it
does not put its data into the audit system where its correlated with
other system events.
The evaluation teams that I have worked with (OrangeBook and CC)
as
On Thursday 07 July 2005 15:04, Greg KH wrote:
> You are adding auditfs, a new userspace access, right?
Not sure what you mean. This is using the same netlink interface that all the
rest of the audit system is using for command and control. Nothing has
changed here. What is different is the
On Thursday 07 July 2005 14:15, Greg KH wrote:
> I fail to see any refactoring here, why not make your patch rely on
> theirs?
At the time this code was developed, inotify was not in the kernel. We would
be patching against another patch that's not in the kernel.
> > The whole rest of it is
On Thursday 07 July 2005 14:15, Greg KH wrote:
I fail to see any refactoring here, why not make your patch rely on
theirs?
At the time this code was developed, inotify was not in the kernel. We would
be patching against another patch that's not in the kernel.
The whole rest of it is
On Thursday 07 July 2005 15:04, Greg KH wrote:
You are adding auditfs, a new userspace access, right?
Not sure what you mean. This is using the same netlink interface that all the
rest of the audit system is using for command and control. Nothing has
changed here. What is different is the
ath from the perspective of the app
generating the events, but since we added the /var/chroot key, we can see
that it really came from the chroot dir.
Hope this helps...
-Steve Grubb
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EM
of the app
generating the events, but since we added the /var/chroot key, we can see
that it really came from the chroot dir.
Hope this helps...
-Steve Grubb
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
dit daemon can switch to
another format (binary data ?) which might be more efficient. I haven't spent
anytime looking at what makes sense for a binary format, nor do we have time
for that right now. But I'd like to look at that in the future.
-Steve Grubb
-
To unsubscribe from this list: s
daemon can switch to
another format (binary data ?) which might be more efficient. I haven't spent
anytime looking at what makes sense for a binary format, nor do we have time
for that right now. But I'd like to look at that in the future.
-Steve Grubb
-
To unsubscribe from this list: send the line
or two for everyone to look over.
-Steve Grubb
-
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/
for everyone to look over.
-Steve Grubb
-
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/
.html#SEC92
Or perhaps type checking macro arguments would be another fertile area for
the Stanford Checker...
Cheers,
Steve Grubb
-
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.
.html#SEC92
Or perhaps type checking macro arguments would be another fertile area for
the Stanford Checker...
Cheers,
Steve Grubb
-
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.
ts 2 lines later.
Cheers,
Steve Grubb
--
--- lib/vsprintf.orig Fri Dec 1 08:58:02 2000
+++ lib/vsprintf.c Wed Dec 20 13:14:13 2000
@@ -14,10 +14,13 @@
#include
#include
+/*
+* This function converts base 8, 10, or 16 only - Steve Grubb
+*/
unsigned
ay the word & I'll gen up another patch...but it will be
more bytes.
Cheers,
Steve Grubb
-
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/
value with this define to 8, 10, or 16 to
see the speed change for each numeric representation:
#define BASE 10
Have fun,
Steve Grubb
--strtoul_test.c--
#include
#include
#include
#include
#include
#include
struct timeval last_stopwatch_time;
void stopwatch()
{
struct
application that demonstrates the performance gain. This patch was
generated against 2.2.16, but should apply to 2.2.19 cleanly. In
2.4.0-test9, simple_strtoul starts on line 19 rather than 17, hopefully
that's not a problem.
Cheers,
Steve Grubb
-
--- lib/vsprintf.orig Fri
application that demonstrates the performance gain. This patch was
generated against 2.2.16, but should apply to 2.2.19 cleanly. In
2.4.0-test9, simple_strtoul starts on line 19 rather than 17, hopefully
that's not a problem.
Cheers,
Steve Grubb
-
--- lib/vsprintf.orig Fri
value with this define to 8, 10, or 16 to
see the speed change for each numeric representation:
#define BASE 10
Have fun,
Steve Grubb
--strtoul_test.c--
#include unistd.h
#include stdlib.h
#include stdio.h
#include string.h
#include sys/resource.h
#include linux/ctype.h
struct
'll gen up another patch...but it will be
more bytes.
Cheers,
Steve Grubb
-
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/
lines later.
Cheers,
Steve Grubb
--
--- lib/vsprintf.orig Fri Dec 1 08:58:02 2000
+++ lib/vsprintf.c Wed Dec 20 13:14:13 2000
@@ -14,10 +14,13 @@
#include linux/string.h
#include linux/ctype.h
+/*
+* This function converts base 8, 10, or 16 only - Steve Grubb
Hello,
This patch removes extra setting of the error value in the do_syslog
function. The patch is against 2.2.16, but printk.c seems to have changed
little so it probably applies against other kernels.
See Ya,
Steve Grubb
--- printk.orig Thu Nov 30 07:58:58 2000
Hello,
This patch removes extra setting of the error value in the do_syslog
function. The patch is against 2.2.16, but printk.c seems to have changed
little so it probably applies against other kernels.
See Ya,
Steve Grubb
--- printk.orig Thu Nov 30 07:58:58 2000
201 - 285 of 285 matches
Mail list logo
