On Wednesday, July 01, 2015 02:07:49 PM Andrew Jones wrote:
On Tue, Jun 30, 2015 at 01:18:49PM -0400, Paul Moore wrote:
On Tuesday, June 30, 2015 06:07:40 PM Peter Maydell wrote:
On 30 June 2015 at 18:01, Paul Moore pmo...@redhat.com wrote:
I'm starting to wonder if the 32-bit ARM build
On Tue, Jun 30, 2015 at 01:18:49PM -0400, Paul Moore wrote:
On Tuesday, June 30, 2015 06:07:40 PM Peter Maydell wrote:
On 30 June 2015 at 18:01, Paul Moore pmo...@redhat.com wrote:
I'm starting to wonder if the 32-bit ARM build system didn't have
__NR_cacheflush defined in the system
On Mon, Jun 29, 2015 at 04:24:55PM -0400, Paul Moore wrote:
On Monday, June 29, 2015 07:47:29 PM Andrew Jones wrote:
On Mon, Jun 29, 2015 at 10:53:14AM -0400, Paul Moore wrote:
On Monday, June 29, 2015 09:50:17 AM Andrew Jones wrote:
On Fri, Jun 26, 2015 at 04:26:22PM -0400, Paul Moore
On 30 June 2015 at 18:01, Paul Moore pmo...@redhat.com wrote:
I'm starting to wonder if the 32-bit ARM build system didn't have
__NR_cacheflush defined in the system headers; that might explain some of the
behavior. Could you check your system to see if it has __NR_cacheflush
defined (try
On Tuesday, June 30, 2015 10:39:34 AM Andrew Jones wrote:
On Mon, Jun 29, 2015 at 04:24:55PM -0400, Paul Moore wrote:
Hmm, so either the kernel is screwing up with the seccomp filter for this
particular syscall (unlikely) or libseccomp is screwing up the filter
creation (more likely). I
On Tuesday, June 30, 2015 06:07:40 PM Peter Maydell wrote:
On 30 June 2015 at 18:01, Paul Moore pmo...@redhat.com wrote:
I'm starting to wonder if the 32-bit ARM build system didn't have
__NR_cacheflush defined in the system headers; that might explain some of
the behavior. Could you check
On Monday, June 29, 2015 09:50:17 AM Andrew Jones wrote:
On Fri, Jun 26, 2015 at 04:26:22PM -0400, Paul Moore wrote:
Perhaps a stupid question, but you did verify that it is cacheflush that
is causing the problem? The seccomp filter code will emit a message to
syslog or the audit log,
On Mon, Jun 29, 2015 at 10:53:14AM -0400, Paul Moore wrote:
On Monday, June 29, 2015 09:50:17 AM Andrew Jones wrote:
On Fri, Jun 26, 2015 at 04:26:22PM -0400, Paul Moore wrote:
Perhaps a stupid question, but you did verify that it is cacheflush that
is causing the problem? The seccomp
On Monday, June 29, 2015 07:47:29 PM Andrew Jones wrote:
On Mon, Jun 29, 2015 at 10:53:14AM -0400, Paul Moore wrote:
On Monday, June 29, 2015 09:50:17 AM Andrew Jones wrote:
On Fri, Jun 26, 2015 at 04:26:22PM -0400, Paul Moore wrote:
Perhaps a stupid question, but you did verify that it
On Fri, Jun 26, 2015 at 04:26:22PM -0400, Paul Moore wrote:
On Friday, June 26, 2015 06:03:18 PM Andrew Jones wrote:
On Tue, Jun 16, 2015 at 02:16:03PM +0100, Peter Maydell wrote:
On 16 June 2015 at 14:12, Andrew Jones drjo...@redhat.com wrote:
Can we now revert this revert, along with
On Tue, Jun 16, 2015 at 02:16:03PM +0100, Peter Maydell wrote:
On 16 June 2015 at 14:12, Andrew Jones drjo...@redhat.com wrote:
Can we now revert this revert, along with bumping the non-x86 arch
atleast-version to v2.2.1
Probably. I suggest you submit a patch and test it on the
relevant
On Friday, June 26, 2015 06:03:18 PM Andrew Jones wrote:
On Tue, Jun 16, 2015 at 02:16:03PM +0100, Peter Maydell wrote:
On 16 June 2015 at 14:12, Andrew Jones drjo...@redhat.com wrote:
Can we now revert this revert, along with bumping the non-x86 arch
atleast-version to v2.2.1
On 16 June 2015 at 14:12, Andrew Jones drjo...@redhat.com wrote:
Can we now revert this revert, along with bumping the non-x86 arch
atleast-version to v2.2.1
Probably. I suggest you submit a patch and test it on the
relevant architectures and seccomp versions.
thanks
-- PMM
On Fri, Apr 10, 2015 at 01:58:01PM +0100, Peter Maydell wrote:
Unfortunately it turns out that libseccomp 2.2 still does not work
correctly on non-x86 architectures; return to the previous configure
setup of insisting on libseccomp 2.1 or better and i386/x86_64 and
disabling seccomp support in
14 matches
Mail list logo
