Re: linux-next: manual merge of the audit tree with the powerpc tree

2022-01-12 Thread Paul Moore
On Fri, Dec 17, 2021 at 9:11 AM Christophe Leroy
 wrote:
> Le 17/12/2021 à 00:04, Paul Moore a écrit :
> > On Thu, Dec 16, 2021 at 4:08 AM Christophe Leroy
> >  wrote:
> >> Thanks Cédric, I've now been able to install debian PPC32 port of DEBIAN
> >> 11 on QEMU and run the tests.
> >>
> >> I followed instructions in file README.md provided in the test suite.
> >> I also modified tests/Makefile to force MODE := 32
> >>
> >> I've got a lot of failures, am I missing some options in the kernel or
> >> something ?
> >>
> >> Running as   userroot
> >>   with context root:::
> >>   on   system
> >
> > While SELinux is not required for audit, I don't think I've ever run
> > it on system without SELinux.  In theory the audit-testsuite shouldn't
> > rely on SELinux being present (other than the SELinux specific tests
> > of course), but I'm not confident enough to say that the test suite
> > will run without problem without SELinux.
> >
> > If it isn't too difficult, I would suggest enabling SELinux in your
> > kernel build and ensuring the necessary userspace, policy, etc. is
> > installed.  You don't need to worry about getting it all running
> > correctly; the audit-testsuite should pass with SELinux in permissive
> > mode.
> >
> > If you're still seeing all these failures after trying that let us know.
> >
>
> Still the same it seems:
>
> Running as   userroot
>  with context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
>  on   system
>
> # Test 3 got: "256" (backlog_wait_time_actual_reset/test at line 151)
> #   Expected: "0"
> #  backlog_wait_time_actual_reset/test line 151 is: ok( $result, 0 );
>   # Was an event found?

My apologies, this thread was lost in the end-of-year holidays.

At this point, and with that many failures, I think you'll need to
spend some time debugging the test failures to see what is wrong.  I
don't have a PPC32 system/VM and I don't have the time right now to
build up a PPC32 test environment.

-- 
paul moore
www.paul-moore.com


Re: linux-next: manual merge of the audit tree with the powerpc tree

2021-12-17 Thread Christophe Leroy


Le 17/12/2021 à 00:04, Paul Moore a écrit :
> On Thu, Dec 16, 2021 at 4:08 AM Christophe Leroy
>  wrote:
>> Thanks Cédric, I've now been able to install debian PPC32 port of DEBIAN
>> 11 on QEMU and run the tests.
>>
>> I followed instructions in file README.md provided in the test suite.
>> I also modified tests/Makefile to force MODE := 32
>>
>> I've got a lot of failures, am I missing some options in the kernel or
>> something ?
>>
>> Running as   userroot
>>   with context root:::
>>   on   system
> 
> While SELinux is not required for audit, I don't think I've ever run
> it on system without SELinux.  In theory the audit-testsuite shouldn't
> rely on SELinux being present (other than the SELinux specific tests
> of course), but I'm not confident enough to say that the test suite
> will run without problem without SELinux.
> 
> If it isn't too difficult, I would suggest enabling SELinux in your
> kernel build and ensuring the necessary userspace, policy, etc. is
> installed.  You don't need to worry about getting it all running
> correctly; the audit-testsuite should pass with SELinux in permissive
> mode.
> 
> If you're still seeing all these failures after trying that let us know.
> 

Still the same it seems:

Running as   userroot
 with context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
 on   system

# Test 3 got: "256" (backlog_wait_time_actual_reset/test at line 151)
#   Expected: "0"
#  backlog_wait_time_actual_reset/test line 151 is: ok( $result, 0 ); 
  # Was an event found?
# Test 4 got: "0" (backlog_wait_time_actual_reset/test at line 168)
#   Expected: "1"
#  backlog_wait_time_actual_reset/test line 168 is: ok( $found_msg, 1 ); 
# Was the message well-formed?
# Failed test 5 in backlog_wait_time_actual_reset/test at line 169
#  backlog_wait_time_actual_reset/test line 169 is: ok( $reset_rc == 
$reset_msg )
backlog_wait_time_actual_reset/test ..
Failed 3/5 subtests
sh: 1: Syntax error: Bad fd number
sh: 1: Syntax error: Bad fd number
exec_execve/test . ok
sh: 1: Syntax error: Bad fd number
sh: 1: Syntax error: Bad fd number
# Failed test 7 in exec_name/test at line 145 fail #4
#  exec_name/test line 145 is: ok( $found[$_] == $expected[$_] );
sh: 1: Syntax error: Bad fd number
# Failed test 11 in exec_name/test at line 145 fail #7
sh: 1: Syntax error: Bad fd number
# Failed test 15 in exec_name/test at line 145 fail #10
# Failed test 17 in exec_name/test at line 145 fail #12
sh: 1: Syntax error: Bad fd number
# Failed test 19 in exec_name/test at line 145 fail #13
sh: 1: Syntax error: Bad fd number
# Failed test 23 in exec_name/test at line 145 fail #16
# Failed test 24 in exec_name/test at line 145 fail #17
sh: 1: Syntax error: Bad fd number
Error sending add rule data request (Rule exists)
# Failed test 29 in exec_name/test at line 145 fail #21
sh: 1: Syntax error: Bad fd number
exec_name/test ...
Failed 8/29 subtests
sh: 1: Syntax error: Bad fd number
# Failed test 2 in file_create/test at line 121
#  file_create/test line 121 is: ok($found_syscall);
# Failed test 3 in file_create/test at line 122
#  file_create/test line 122 is: ok($found_parent);
# Failed test 4 in file_create/test at line 123
#  file_create/test line 123 is: ok($found_create);
sh: 1: Syntax error: Bad fd number
file_create/test .
Failed 3/4 subtests
sh: 1: Syntax error: Bad fd number
# Failed test 2 in file_delete/test at line 122
#  file_delete/test line 122 is: ok($found_syscall);
# Failed test 3 in file_delete/test at line 123
#  file_delete/test line 123 is: ok($found_parent);
# Failed test 4 in file_delete/test at line 124
#  file_delete/test line 124 is: ok($found_delete);
sh: 1: Syntax error: Bad fd number
file_delete/test .
Failed 3/4 subtests
sh: 1: Syntax error: Bad fd number
# Failed test 2 in file_rename/test at line 138
#  file_rename/test line 138 is: ok($found_syscall);
# Test 3 got: "0" (file_rename/test at line 139)
#   Expected: "2"
#  file_rename/test line 139 is: ok( $found_parent, 2 );
# Failed test 4 in file_rename/test at line 140
#  file_rename/test line 140 is: ok($found_create);
# Failed test 5 in file_rename/test at line 141
#  file_rename/test line 141 is: ok($found_delete);
sh: 1: Syntax error: Bad fd number
file_rename/test .
Failed 4/5 subtests
sh: 1: Syntax error: Bad fd number
# Test 20 got: "256" (filter_exclude/test at line 167)
#Expected: "0"
#  filter_exclude/test line 167 is: ok( $result, 0 );
# Test 21 got: "0" (filter_exclude/test at line 179)
#Expected: "1"
#  filter_exclude/test line 179 is: ok( $found_msg, 1 );
sh: 1: Syntax error: Bad fd number
filter_exclude/test ..
Failed 2/21 subtests
sh: 1: cannot create /dev/udp/127.0.0.1/24242: Directory nonexistent
# Test 3 got: "256" (filter_saddr_fam/test at line 88)
#   Expected: "0"
#  filter_saddr_fam/test line 88 is: ok( $result, 0 );# Was 

Re: linux-next: manual merge of the audit tree with the powerpc tree

2021-12-16 Thread Paul Moore
On Thu, Dec 16, 2021 at 4:08 AM Christophe Leroy
 wrote:
> Thanks Cédric, I've now been able to install debian PPC32 port of DEBIAN
> 11 on QEMU and run the tests.
>
> I followed instructions in file README.md provided in the test suite.
> I also modified tests/Makefile to force MODE := 32
>
> I've got a lot of failures, am I missing some options in the kernel or
> something ?
>
> Running as   userroot
>  with context root:::
>  on   system

While SELinux is not required for audit, I don't think I've ever run
it on system without SELinux.  In theory the audit-testsuite shouldn't
rely on SELinux being present (other than the SELinux specific tests
of course), but I'm not confident enough to say that the test suite
will run without problem without SELinux.

If it isn't too difficult, I would suggest enabling SELinux in your
kernel build and ensuring the necessary userspace, policy, etc. is
installed.  You don't need to worry about getting it all running
correctly; the audit-testsuite should pass with SELinux in permissive
mode.

If you're still seeing all these failures after trying that let us know.

> # Test 3 got: "256" (backlog_wait_time_actual_reset/test at line 151)
> #   Expected: "0"
> #  backlog_wait_time_actual_reset/test line 151 is: ok( $result, 0 );
>   # Was an event found?

...

-- 
paul moore
www.paul-moore.com


Re: linux-next: manual merge of the audit tree with the powerpc tree

2021-12-16 Thread Christophe Leroy


Le 14/12/2021 à 21:30, Cédric Le Goater a écrit :
> On 12/14/21 20:32, Christophe Leroy wrote:
>>
>>
>> Le 14/12/2021 à 19:23, Paul Moore a écrit :
>>> On Tue, Dec 14, 2021 at 12:59 PM Christophe Leroy
>>>  wrote:
 Hello Paul,

 I've been trying to setup your test suite on my powerpc board but it's
 based on Perl and on a lot of optional Perl packages. I was able to add
 them one by one until some of them require some .so libraries
 (Pathtools-Cwd), and it seems nothing is made to allow cross building
 those libraries.

 Do you have another test suite based on C and not perl ?

 If not, what can I do, do you know how I can cross compile those Perl
 packages for PPC32 ?
>>>
>>> Is there no Linux distribution that supports PPC32?  I would think
>>> that would be the easiest path forward, but you're the PPC32 expert -
>>> not me - so I'll assume you already tried that or it didn't work for
>>> other reasons.
>>
>> There hasn't been Linux distribution supporting PPC32 for a few years
>> now. And regardless, the boards I'm running Linux on are home made
>> embedded boards, with limited amount of memory and flashdisk space and
>> no video chip, so they are hardly supported by any distributions, even
>> older ones.
> 
> We still have debian. you will find images under :
> 
>    https://cdimage.debian.org/cdimage/ports/snapshots/2021-04-17/
> 
> and from there, you can update to unstable, which runs fine under
> a mac99 QEMU machine.
> 

Thanks Cédric, I've now been able to install debian PPC32 port of DEBIAN 
11 on QEMU and run the tests.

I followed instructions in file README.md provided in the test suite.
I also modified tests/Makefile to force MODE := 32

I've got a lot of failures, am I missing some options in the kernel or 
something ?

Running as   userroot
 with context root:::
 on   system

# Test 3 got: "256" (backlog_wait_time_actual_reset/test at line 151)
#   Expected: "0"
#  backlog_wait_time_actual_reset/test line 151 is: ok( $result, 0 ); 
  # Was an event found?
# Test 4 got: "0" (backlog_wait_time_actual_reset/test at line 168)
#   Expected: "1"
#  backlog_wait_time_actual_reset/test line 168 is: ok( $found_msg, 1 ); 
# Was the message well-formed?
# Failed test 5 in backlog_wait_time_actual_reset/test at line 169
#  backlog_wait_time_actual_reset/test line 169 is: ok( $reset_rc == 
$reset_msg )
backlog_wait_time_actual_reset/test ..
Failed 3/5 subtests
sh: 1: Syntax error: Bad fd number
sh: 1: Syntax error: Bad fd number
exec_execve/test . ok
sh: 1: Syntax error: Bad fd number
sh: 1: Syntax error: Bad fd number
# Failed test 7 in exec_name/test at line 145 fail #4
#  exec_name/test line 145 is: ok( $found[$_] == $expected[$_] );
sh: 1: Syntax error: Bad fd number
# Failed test 11 in exec_name/test at line 145 fail #7
sh: 1: Syntax error: Bad fd number
# Failed test 15 in exec_name/test at line 145 fail #10
# Failed test 17 in exec_name/test at line 145 fail #12
sh: 1: Syntax error: Bad fd number
# Failed test 19 in exec_name/test at line 145 fail #13
sh: 1: Syntax error: Bad fd number
# Failed test 23 in exec_name/test at line 145 fail #16
# Failed test 24 in exec_name/test at line 145 fail #17
sh: 1: Syntax error: Bad fd number
Error sending add rule data request (Rule exists)
# Failed test 29 in exec_name/test at line 145 fail #21
sh: 1: Syntax error: Bad fd number
exec_name/test ...
Failed 8/29 subtests
sh: 1: Syntax error: Bad fd number
# Failed test 2 in file_create/test at line 121
#  file_create/test line 121 is: ok($found_syscall);
# Failed test 3 in file_create/test at line 122
#  file_create/test line 122 is: ok($found_parent);
# Failed test 4 in file_create/test at line 123
#  file_create/test line 123 is: ok($found_create);
sh: 1: Syntax error: Bad fd number
file_create/test .
Failed 3/4 subtests
sh: 1: Syntax error: Bad fd number
# Failed test 2 in file_delete/test at line 122
#  file_delete/test line 122 is: ok($found_syscall);
# Failed test 3 in file_delete/test at line 123
#  file_delete/test line 123 is: ok($found_parent);
# Failed test 4 in file_delete/test at line 124
#  file_delete/test line 124 is: ok($found_delete);
sh: 1: Syntax error: Bad fd number
file_delete/test .
Failed 3/4 subtests
sh: 1: Syntax error: Bad fd number
# Failed test 2 in file_rename/test at line 138
#  file_rename/test line 138 is: ok($found_syscall);
# Test 3 got: "0" (file_rename/test at line 139)
#   Expected: "2"
#  file_rename/test line 139 is: ok( $found_parent, 2 );
# Failed test 4 in file_rename/test at line 140
#  file_rename/test line 140 is: ok($found_create);
# Failed test 5 in file_rename/test at line 141
#  file_rename/test line 141 is: ok($found_delete);
sh: 1: Syntax error: Bad fd number
file_rename/test .
Failed 4/5 subtests
sh: 1: Syntax error: Bad fd number
# Test 1 got: "256" (filter_exclude/test at 

Re: linux-next: manual merge of the audit tree with the powerpc tree

2021-12-14 Thread Cédric Le Goater

On 12/14/21 20:32, Christophe Leroy wrote:



Le 14/12/2021 à 19:23, Paul Moore a écrit :

On Tue, Dec 14, 2021 at 12:59 PM Christophe Leroy
 wrote:

Hello Paul,

I've been trying to setup your test suite on my powerpc board but it's
based on Perl and on a lot of optional Perl packages. I was able to add
them one by one until some of them require some .so libraries
(Pathtools-Cwd), and it seems nothing is made to allow cross building
those libraries.

Do you have another test suite based on C and not perl ?

If not, what can I do, do you know how I can cross compile those Perl
packages for PPC32 ?


Is there no Linux distribution that supports PPC32?  I would think
that would be the easiest path forward, but you're the PPC32 expert -
not me - so I'll assume you already tried that or it didn't work for
other reasons.


There hasn't been Linux distribution supporting PPC32 for a few years
now. And regardless, the boards I'm running Linux on are home made
embedded boards, with limited amount of memory and flashdisk space and
no video chip, so they are hardly supported by any distributions, even
older ones.


We still have debian. you will find images under :

  https://cdimage.debian.org/cdimage/ports/snapshots/2021-04-17/

and from there, you can update to unstable, which runs fine under
a mac99 QEMU machine.

Cheers,

C.


Re: linux-next: manual merge of the audit tree with the powerpc tree

2021-12-14 Thread Christophe Leroy


Le 14/12/2021 à 19:23, Paul Moore a écrit :
> On Tue, Dec 14, 2021 at 12:59 PM Christophe Leroy
>  wrote:
>> Hello Paul,
>>
>> I've been trying to setup your test suite on my powerpc board but it's
>> based on Perl and on a lot of optional Perl packages. I was able to add
>> them one by one until some of them require some .so libraries
>> (Pathtools-Cwd), and it seems nothing is made to allow cross building
>> those libraries.
>>
>> Do you have another test suite based on C and not perl ?
>>
>> If not, what can I do, do you know how I can cross compile those Perl
>> packages for PPC32 ?
> 
> Is there no Linux distribution that supports PPC32?  I would think
> that would be the easiest path forward, but you're the PPC32 expert -
> not me - so I'll assume you already tried that or it didn't work for
> other reasons.

There hasn't been Linux distribution supporting PPC32 for a few years 
now. And regardless, the boards I'm running Linux on are home made 
embedded boards, with limited amount of memory and flashdisk space and 
no video chip, so they are hardly supported by any distributions, even 
older ones.

> 
> I'm also not a Perl expert, but it looks like PathTools is part of the
> core Perl5 release, have you tried that?
> 
> https://github.com/Perl/perl5/tree/blead/dist/PathTools

I got it from https://metacpan.org/pod/Cwd
I guess it is the same ?

> 
> Finally, no, our only really maintained test suite is the Perl based
> one; there have been other efforts over the years but they were never
> properly supported and fell out of use (and applicability).  At some
> point you/someone was able to run the test suite, why isn't that
> working now?  Or was it a different powerpc ABI?
> 

Yes, Michael did on some PPC64 server, for this kind of HW there are 
distribution and they are able to run native compilers on it as well, so 
that's another story.

Christophe

Re: linux-next: manual merge of the audit tree with the powerpc tree

2021-12-14 Thread Paul Moore
On Tue, Dec 14, 2021 at 12:59 PM Christophe Leroy
 wrote:
> Hello Paul,
>
> I've been trying to setup your test suite on my powerpc board but it's
> based on Perl and on a lot of optional Perl packages. I was able to add
> them one by one until some of them require some .so libraries
> (Pathtools-Cwd), and it seems nothing is made to allow cross building
> those libraries.
>
> Do you have another test suite based on C and not perl ?
>
> If not, what can I do, do you know how I can cross compile those Perl
> packages for PPC32 ?

Is there no Linux distribution that supports PPC32?  I would think
that would be the easiest path forward, but you're the PPC32 expert -
not me - so I'll assume you already tried that or it didn't work for
other reasons.

I'm also not a Perl expert, but it looks like PathTools is part of the
core Perl5 release, have you tried that?

https://github.com/Perl/perl5/tree/blead/dist/PathTools

Finally, no, our only really maintained test suite is the Perl based
one; there have been other efforts over the years but they were never
properly supported and fell out of use (and applicability).  At some
point you/someone was able to run the test suite, why isn't that
working now?  Or was it a different powerpc ABI?

-- 
paul moore
www.paul-moore.com


Re: linux-next: manual merge of the audit tree with the powerpc tree

2021-12-14 Thread Christophe Leroy


Le 27/10/2021 à 16:18, Paul Moore a écrit :
> On Wed, Oct 27, 2021 at 7:41 AM Christophe Leroy
>  wrote:
>> Le 27/10/2021 à 13:29, Michael Ellerman a écrit :
>>> Paul Moore  writes:
 On Tue, Oct 26, 2021 at 6:55 AM Michael Ellerman  
 wrote:
> Stephen Rothwell  writes:
>> Hi all,
>>
>> Today's linux-next merge of the audit tree got conflicts in:
>>
>> arch/powerpc/kernel/audit.c
>> arch/powerpc/kernel/compat_audit.c
>>
>> between commit:
>>
>> 566af8cda399 ("powerpc/audit: Convert powerpc to 
>> AUDIT_ARCH_COMPAT_GENERIC")
>>
>> from the powerpc tree and commits:
>>
>> 42f355ef59a2 ("audit: replace magic audit syscall class numbers with 
>> macros")
>> 1c30e3af8a79 ("audit: add support for the openat2 syscall")
>>
>> from the audit tree.
>
> Thanks.
>
> I guess this is OK, unless the audit folks disagree. I could revert the
> powerpc commit and try it again later.
>
> If I don't hear anything I'll leave it as-is.

 Hi Michael,

 Last I recall from the powerpc/audit thread there were still some
 issues with audit working properly in your testing, has that been
 resolved?
>>>
>>> No.
>>>
>>> There's one test failure both before and after the conversion to use the
>>> generic code.
>>>
 If nothing else, -rc7 seems a bit late for this to hit -next for me to
 feel comfortable about this.
>>>
>>> OK. I'll revert the patch in my tree.
>>
>> But it's been in the pipe since end of August and no one reported any
>> issue other issue than the pre-existing one, so what's the new issue
>> that prevents us to merge it two monthes later, and how do we walk
>> forward then ?
> 
> We work to resolve the test failure, it's that simple.  I haven't seen
> the failure so I haven't been much help to do any sort of root cause
> digging on the problem, it would be helpful if those who are seeing
> the problem could dig into the failure and report back on what they
> find.  That is what has been missing and why I never ACK'd or merged
> the powerpc audit code.
> 

Hello Paul,

I've been trying to setup your test suite on my powerpc board but it's 
based on Perl and on a lot of optional Perl packages. I was able to add 
them one by one until some of them require some .so libraries 
(Pathtools-Cwd), and it seems nothing is made to allow cross building 
those libraries.

Do you have another test suite based on C and not perl ?

If not, what can I do, do you know how I can cross compile those Perl 
packages for PPC32 ?

Thanks
Christophe

Re: linux-next: manual merge of the audit tree with the powerpc tree

2021-10-27 Thread Paul Moore
On Wed, Oct 27, 2021 at 7:41 AM Christophe Leroy
 wrote:
> Le 27/10/2021 à 13:29, Michael Ellerman a écrit :
> > Paul Moore  writes:
> >> On Tue, Oct 26, 2021 at 6:55 AM Michael Ellerman  
> >> wrote:
> >>> Stephen Rothwell  writes:
>  Hi all,
> 
>  Today's linux-next merge of the audit tree got conflicts in:
> 
> arch/powerpc/kernel/audit.c
> arch/powerpc/kernel/compat_audit.c
> 
>  between commit:
> 
> 566af8cda399 ("powerpc/audit: Convert powerpc to 
>  AUDIT_ARCH_COMPAT_GENERIC")
> 
>  from the powerpc tree and commits:
> 
> 42f355ef59a2 ("audit: replace magic audit syscall class numbers with 
>  macros")
> 1c30e3af8a79 ("audit: add support for the openat2 syscall")
> 
>  from the audit tree.
> >>>
> >>> Thanks.
> >>>
> >>> I guess this is OK, unless the audit folks disagree. I could revert the
> >>> powerpc commit and try it again later.
> >>>
> >>> If I don't hear anything I'll leave it as-is.
> >>
> >> Hi Michael,
> >>
> >> Last I recall from the powerpc/audit thread there were still some
> >> issues with audit working properly in your testing, has that been
> >> resolved?
> >
> > No.
> >
> > There's one test failure both before and after the conversion to use the
> > generic code.
> >
> >> If nothing else, -rc7 seems a bit late for this to hit -next for me to
> >> feel comfortable about this.
> >
> > OK. I'll revert the patch in my tree.
>
> But it's been in the pipe since end of August and no one reported any
> issue other issue than the pre-existing one, so what's the new issue
> that prevents us to merge it two monthes later, and how do we walk
> forward then ?

We work to resolve the test failure, it's that simple.  I haven't seen
the failure so I haven't been much help to do any sort of root cause
digging on the problem, it would be helpful if those who are seeing
the problem could dig into the failure and report back on what they
find.  That is what has been missing and why I never ACK'd or merged
the powerpc audit code.

-- 
paul moore
www.paul-moore.com


Re: linux-next: manual merge of the audit tree with the powerpc tree

2021-10-27 Thread Christophe Leroy




Le 27/10/2021 à 13:29, Michael Ellerman a écrit :

Paul Moore  writes:

On Tue, Oct 26, 2021 at 6:55 AM Michael Ellerman  wrote:

Stephen Rothwell  writes:

Hi all,

Today's linux-next merge of the audit tree got conflicts in:

   arch/powerpc/kernel/audit.c
   arch/powerpc/kernel/compat_audit.c

between commit:

   566af8cda399 ("powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC")

from the powerpc tree and commits:

   42f355ef59a2 ("audit: replace magic audit syscall class numbers with macros")
   1c30e3af8a79 ("audit: add support for the openat2 syscall")

from the audit tree.


Thanks.

I guess this is OK, unless the audit folks disagree. I could revert the
powerpc commit and try it again later.

If I don't hear anything I'll leave it as-is.


Hi Michael,

Last I recall from the powerpc/audit thread there were still some
issues with audit working properly in your testing, has that been
resolved?


No.

There's one test failure both before and after the conversion to use the
generic code.


If nothing else, -rc7 seems a bit late for this to hit -next for me to
feel comfortable about this.


OK. I'll revert the patch in my tree.



But it's been in the pipe since end of August and no one reported any 
issue other issue than the pre-existing one, so what's the new issue 
that prevents us to merge it two monthes later, and how do we walk 
forward then ?


Thanks
Christophe


Re: linux-next: manual merge of the audit tree with the powerpc tree

2021-10-27 Thread Michael Ellerman
Paul Moore  writes:
> On Tue, Oct 26, 2021 at 6:55 AM Michael Ellerman  wrote:
>> Stephen Rothwell  writes:
>> > Hi all,
>> >
>> > Today's linux-next merge of the audit tree got conflicts in:
>> >
>> >   arch/powerpc/kernel/audit.c
>> >   arch/powerpc/kernel/compat_audit.c
>> >
>> > between commit:
>> >
>> >   566af8cda399 ("powerpc/audit: Convert powerpc to 
>> > AUDIT_ARCH_COMPAT_GENERIC")
>> >
>> > from the powerpc tree and commits:
>> >
>> >   42f355ef59a2 ("audit: replace magic audit syscall class numbers with 
>> > macros")
>> >   1c30e3af8a79 ("audit: add support for the openat2 syscall")
>> >
>> > from the audit tree.
>>
>> Thanks.
>>
>> I guess this is OK, unless the audit folks disagree. I could revert the
>> powerpc commit and try it again later.
>>
>> If I don't hear anything I'll leave it as-is.
>
> Hi Michael,
>
> Last I recall from the powerpc/audit thread there were still some
> issues with audit working properly in your testing, has that been
> resolved?

No.

There's one test failure both before and after the conversion to use the
generic code.

> If nothing else, -rc7 seems a bit late for this to hit -next for me to
> feel comfortable about this.

OK. I'll revert the patch in my tree.

cheers


Re: linux-next: manual merge of the audit tree with the powerpc tree

2021-10-26 Thread Paul Moore
On Tue, Oct 26, 2021 at 6:55 AM Michael Ellerman  wrote:
>
> Stephen Rothwell  writes:
> > Hi all,
> >
> > Today's linux-next merge of the audit tree got conflicts in:
> >
> >   arch/powerpc/kernel/audit.c
> >   arch/powerpc/kernel/compat_audit.c
> >
> > between commit:
> >
> >   566af8cda399 ("powerpc/audit: Convert powerpc to 
> > AUDIT_ARCH_COMPAT_GENERIC")
> >
> > from the powerpc tree and commits:
> >
> >   42f355ef59a2 ("audit: replace magic audit syscall class numbers with 
> > macros")
> >   1c30e3af8a79 ("audit: add support for the openat2 syscall")
> >
> > from the audit tree.
>
> Thanks.
>
> I guess this is OK, unless the audit folks disagree. I could revert the
> powerpc commit and try it again later.
>
> If I don't hear anything I'll leave it as-is.

Hi Michael,

Last I recall from the powerpc/audit thread there were still some
issues with audit working properly in your testing, has that been
resolved?  If nothing else, -rc7 seems a bit late for this to hit
-next for me to feel comfortable about this.

-- 
paul moore
www.paul-moore.com


Re: linux-next: manual merge of the audit tree with the powerpc tree

2021-10-26 Thread Michael Ellerman
Stephen Rothwell  writes:
> Hi all,
>
> Today's linux-next merge of the audit tree got conflicts in:
>
>   arch/powerpc/kernel/audit.c
>   arch/powerpc/kernel/compat_audit.c
>
> between commit:
>
>   566af8cda399 ("powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC")
>
> from the powerpc tree and commits:
>
>   42f355ef59a2 ("audit: replace magic audit syscall class numbers with 
> macros")
>   1c30e3af8a79 ("audit: add support for the openat2 syscall")
>
> from the audit tree.

Thanks.

I guess this is OK, unless the audit folks disagree. I could revert the
powerpc commit and try it again later.

If I don't hear anything I'll leave it as-is.

cheers


linux-next: manual merge of the audit tree with the powerpc tree

2021-10-25 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the audit tree got conflicts in:

  arch/powerpc/kernel/audit.c
  arch/powerpc/kernel/compat_audit.c

between commit:

  566af8cda399 ("powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC")

from the powerpc tree and commits:

  42f355ef59a2 ("audit: replace magic audit syscall class numbers with macros")
  1c30e3af8a79 ("audit: add support for the openat2 syscall")

from the audit tree.

I fixed it up (I just removed the files like the former commit) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.



-- 
Cheers,
Stephen Rothwell


pgpA2Gjdtyh3F.pgp
Description: OpenPGP digital signature