5:01 a.m.
[resent from the account used to subscribe on the list]
[replacement patch below is put into audit-current.git]
On Fri, Mar 03, 2006 at 02:32:21AM -0800, akpm(a)osdl.org wrote:
The patch titled
git-audit-master build fix
has been added to the -mm tree. Its filename is
git-audit-master-build-fix.patch
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
From: Andrew Morton <akpm(a)osdl.org>
CONFIG_AUDIT=y, CONFIG_AUDITSYSCALL=n:
kernel/auditfilter.c: In function `audit_add_rule':
kernel/auditfilter.c:329: error: invalid lvalue in increment
kernel/auditfilter.c: In function `audit_del_rule':
kernel/auditfilter.c:348: error: invalid lvalue in increment
kernel/auditfilter.c:350: error: invalid lvalue in decrement
possibly-hacky-fix:
No, that defeats the purpose of that thing. It's increments and
decrements that should be conditional. Patch below should fix
that; it, or better will be folded into Jason's patch at the next
rebase.
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index aeaba84..f31e6b6 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -334,7 +334,9 @@ static inline int audit_add_rule(struct
struct list_head *list)
{
struct audit_entry *e;
+#ifdef CONFIG_AUDITSYSCALL
int dont_count = 0;
+#endif
/* Do not use the _rcu iterator here, since this is the only
* addition routine. */
@@ -344,16 +346,20 @@ static inline int audit_add_rule(struct
}
/* If either of these, don't count towards total */
+#ifdef CONFIG_AUDITSYSCALL
if (entry->rule.listnr == AUDIT_FILTER_USER ||
entry->rule.listnr == AUDIT_FILTER_TYPE)
dont_count = 1;
+#endif
if (entry->rule.flags & AUDIT_FILTER_PREPEND) {
list_add_rcu(&entry->list, list);
} else {
list_add_tail_rcu(&entry->list, list);
}
+#ifdef CONFIG_AUDITSYSCALL
if (!dont_count)
audit_n_rules++;
+#endif
return 0;
}
@@ -370,11 +376,15 @@ static inline int audit_del_rule(struct
list_for_each_entry(e, list, list) {
if (!audit_compare_rule(&entry->rule, &e->rule)) {
list_del_rcu(&e->list);
+#ifdef CONFIG_AUDITSYSCALL
if (entry->rule.listnr == AUDIT_FILTER_USER ||
entry->rule.listnr == AUDIT_FILTER_TYPE)
audit_n_rules++;
+#endif
call_rcu(&e->rcu, audit_free_rule_rcu);
+#ifdef CONFIG_AUDITSYSCALL
audit_n_rules--;
+#endif
return 0;
}
}
5:33 a.m.
On Friday 03 March 2006 06:01, Alexander Viro wrote:
[replacement patch below is put into audit-current.git]
Jason's patch, while promising, is still experimental. It has not been posted
to the linux-audit mail list for review...so I don't think it should be in
the -mm tree just yet. We need to put it into the lspp kernel first and let
people do regression tests to make sure that we have not introduced a
problem.
The flow really needs to be: lspp kernel-> -mm tree-> linus tree.
I think Amy's patches fall into this same category, meaning they need to be
run in the lspp kernel first to make sure we agree that they meet our needs
before sending on to a larger community.
The string interface patches have had enough run time in lspp kernel that they
can be moved to -mm tree. As a matter of fact, some of Dustin's work depends
on these patches and his is ready to go into -mm tree, too (including the
leak patch).
The only controversial work is the patches that touch inotify and Jason's
performance patch. I'd feel better if they get testing in lspp kernel first.
-Steve
9:25 a.m.
On Fri, Mar 03, 2006 at 06:33:42AM -0500, Steve Grubb wrote:
The flow really needs to be: lspp kernel-> -mm tree-> linus
tree.
Then please mark the patches you consider safe for inclusion. Explicitly.
I think Amy's patches fall into this same category, meaning they
need to be
run in the lspp kernel first to make sure we agree that they meet our needs
before sending on to a larger community.
The string interface patches have had enough run time in lspp kernel that they
can be moved to -mm tree. As a matter of fact, some of Dustin's work depends
on these patches and his is ready to go into -mm tree, too (including the
leak patch).
Leak patches simply got folded into the patches that introduced the leaks
in the first place. End of story. Note that moving stuff upstream is
still our job - mirrors of git trees in -mm do not get submitted upstream.
Nor could they, since they are present in -mm as single chunks, rather
than being split into changesets. So we definitely want to keep individual
changesets self-contained and mergable to mainline.
The only controversial work is the patches that touch inotify and
Jason's
performance patch. I'd feel better if they get testing in lspp kernel first.
IMO Jason's stuff is OK. inotify, OTOH, (a) conflicts with other stuff in
-mm and (b) is not ready for any testing, period. Version posted last week
would deadlock instantly and that chunk is _the_ reason for previous
inotify-affecting patch. Besides, Amy asked to move those to the end of
queue, so that she could replace them with convenience. Which is what
had been done...
I'm still not sure what to do with the string patch #2 - right now it's
in amg.b2; if Amy is OK with moving it to main branch, I'll do that and
Dustin's patches will follow immediately.
1:04 p.m.
On Fri, Mar 03, 2006 at 10:25:48AM -0500, Alexander Viro wrote:
On Fri, Mar 03, 2006 at 06:33:42AM -0500, Steve Grubb wrote:
> I think Amy's patches fall into this same category, meaning they
> need to be run in the lspp kernel first to make sure we agree that
> they meet our needs before sending on to a larger community.
>
> The string interface patches have had enough run time in lspp
> kernel that they can be moved to -mm tree. As a matter of fact,
> some of Dustin's work depends on these patches and his is ready
> to go into -mm tree, too (including the leak patch).
[..]
> The only controversial work is the patches that touch inotify
and
> Jason's performance patch. I'd feel better if they get testing in
> lspp kernel first.
IMO Jason's stuff is OK. inotify, OTOH, (a) conflicts with other
stuff in -mm and (b) is not ready for any testing, period. Version
posted last week would deadlock instantly and that chunk is _the_
reason for previous inotify-affecting patch. Besides, Amy asked to
move those to the end of queue, so that she could replace them with
convenience. Which is what had been done...
I'm still not sure what to do with the string patch #2 - right now
it's in amg.b2; if Amy is OK with moving it to main branch, I'll do
that and Dustin's patches will follow immediately.
There shouldn't be any dependencies on the string #2 patch. All of
the interface changes should be contained in the string #1 patch. If
this is not the case, point me to the specific dependency and I'll fix
it.
Separating the string #1 and string #2 patches did uncover a problem
I'd forgotten about. The string #1 patch introduces a new function as
part of the interface changes. Because it doesn't have a caller, it
generates build warnings, which akpm fixed in -mm by removing the
function.
I'm not sure removing the function is the right thing to do; it seems
we might as well remove the whole patch in that case.
Would anyone have advice on how to properly introduce new interfaces
that may not yet have callers?
Thanks,
Amy
6865
days inactive
6868
days old
linux-audit@lists.linux-audit.osci.io
3 comments
3 participants
participants (3)
-
Alexander Viro -
Amy Griffis -
Steve Grubb