Hi. I didn't want to leave this hanging and it stayed in my head so I
thought I'd better just finish it and test it.
I tried out this patch and it got rid of all three unaligned acces errors
I was seeing with process connectors and the patch is indeed much smaller.
I ran our container daemon
> But it's rather a lot of churn for such a thing. Did you consider simply
> using
> put_unaligned() against the specific offending field(s)?
Hi. This was not considered.
I wanted to give you some quick feedback, so I tried your suggestion in the
fork path. It seemed to fix the problem as
On Tue, 12 Dec 2006 20:31:32 -0600
Erik Jacobson <[EMAIL PROTECTED]> wrote:
> > But it's rather a lot of churn for such a thing. Did you consider simply
> > using
> > put_unaligned() against the specific offending field(s)?
>
> Hi. This was not considered.
>
> I wanted to give you some quick
On Tue, 12 Dec 2006 11:54:11 -0600
Erik Jacobson <[EMAIL PROTECTED]> wrote:
> Hi Andrew.
>
> There was some discussion on this patch but I believe we've agreed
> on the first version I sent. This was ACKed by Matt Helsley.
>
> Would you consider taking this in to -mm?
>
> I've included my
-
Original patch email:
Date: Thu, 7 Dec 2006 17:22:13 -0600
From: Erik Jacobson <[EMAIL PROTECTED]>
To: linux-kernel@vger.kernel.org
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: [PATCH] connector: Some fixes for ia64 unaligned access errors
On ia64, the various functio
2006 17:22:13 -0600
From: Erik Jacobson [EMAIL PROTECTED]
To: linux-kernel@vger.kernel.org
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: [PATCH] connector: Some fixes for ia64 unaligned access errors
On ia64, the various functions that make up cn_proc.c cause kernel
unaligned access errors
On Tue, 12 Dec 2006 11:54:11 -0600
Erik Jacobson [EMAIL PROTECTED] wrote:
Hi Andrew.
There was some discussion on this patch but I believe we've agreed
on the first version I sent. This was ACKed by Matt Helsley.
Would you consider taking this in to -mm?
I've included my original
On Tue, 12 Dec 2006 20:31:32 -0600
Erik Jacobson [EMAIL PROTECTED] wrote:
But it's rather a lot of churn for such a thing. Did you consider simply
using
put_unaligned() against the specific offending field(s)?
Hi. This was not considered.
I wanted to give you some quick feedback,
But it's rather a lot of churn for such a thing. Did you consider simply
using
put_unaligned() against the specific offending field(s)?
Hi. This was not considered.
I wanted to give you some quick feedback, so I tried your suggestion in the
fork path. It seemed to fix the problem as well.
Hi. I didn't want to leave this hanging and it stayed in my head so I
thought I'd better just finish it and test it.
I tried out this patch and it got rid of all three unaligned acces errors
I was seeing with process connectors and the patch is indeed much smaller.
I ran our container daemon
From: Matt Helsley <[EMAIL PROTECTED]>
Date: Mon, 11 Dec 2006 19:09:16 -0800
> Hmm, that GCC assumption conflicts with the prototypes of memcpy() I've
> seen.
When GCC expands __builtin_memcpy() internally it looks at the types
of the arguments, and what it knows about their guarenteed
On Mon, 2006-12-11 at 17:50 -0800, David Miller wrote:
> From: Pete Zaitcev <[EMAIL PROTECTED]>
> Date: Mon, 11 Dec 2006 17:29:07 -0800
>
> > On Mon, 11 Dec 2006 15:52:47 -0800, Matt Helsley <[EMAIL PROTECTED]> wrote:
> >
> > > I'm shocked memcpy() introduces 8-byte stores that violate
Pete Zaitcev wrote on Monday, December 11, 2006 5:29 PM
> On Mon, 11 Dec 2006 15:52:47 -0800, Matt Helsley <[EMAIL PROTECTED]> wrote:
>
> > I'm shocked memcpy() introduces 8-byte stores that violate architecture
> > alignment rules. Is there any chance this a bug in ia64's memcpy()
> >
From: Pete Zaitcev <[EMAIL PROTECTED]>
Date: Mon, 11 Dec 2006 17:29:07 -0800
> On Mon, 11 Dec 2006 15:52:47 -0800, Matt Helsley <[EMAIL PROTECTED]> wrote:
>
> > I'm shocked memcpy() introduces 8-byte stores that violate architecture
> > alignment rules. Is there any chance this a bug in
On Mon, 11 Dec 2006 15:52:47 -0800, Matt Helsley <[EMAIL PROTECTED]> wrote:
> I'm shocked memcpy() introduces 8-byte stores that violate architecture
> alignment rules. Is there any chance this a bug in ia64's memcpy()
> implementation? I've tried to read it but since I'm not familiar with
On Thu, 2006-12-07 at 17:22 -0600, Erik Jacobson wrote:
> On ia64, the various functions that make up cn_proc.c cause kernel
> unaligned access errors.
>
> If you are using these, for example, to get notification about
> all tasks forking and exiting, you get multiple unaligned access errors
>
On Sat, 2006-12-09 at 18:34 -0800, Pete Zaitcev wrote:
> On Sat, 9 Dec 2006 15:09:13 -0600, Erik Jacobson <[EMAIL PROTECTED]> wrote:
>
> > > Please try to declare u64 timestamp_ns, then copy it into the *ev
> > > instead of copying whole *ev. This ought to fix the problem if
> > > buffer[] ends
On Sat, 2006-12-09 at 18:34 -0800, Pete Zaitcev wrote:
On Sat, 9 Dec 2006 15:09:13 -0600, Erik Jacobson [EMAIL PROTECTED] wrote:
Please try to declare u64 timestamp_ns, then copy it into the *ev
instead of copying whole *ev. This ought to fix the problem if
buffer[] ends aligned to 32
On Thu, 2006-12-07 at 17:22 -0600, Erik Jacobson wrote:
On ia64, the various functions that make up cn_proc.c cause kernel
unaligned access errors.
If you are using these, for example, to get notification about
all tasks forking and exiting, you get multiple unaligned access errors
per
On Mon, 11 Dec 2006 15:52:47 -0800, Matt Helsley [EMAIL PROTECTED] wrote:
I'm shocked memcpy() introduces 8-byte stores that violate architecture
alignment rules. Is there any chance this a bug in ia64's memcpy()
implementation? I've tried to read it but since I'm not familiar with
ia64
From: Pete Zaitcev [EMAIL PROTECTED]
Date: Mon, 11 Dec 2006 17:29:07 -0800
On Mon, 11 Dec 2006 15:52:47 -0800, Matt Helsley [EMAIL PROTECTED] wrote:
I'm shocked memcpy() introduces 8-byte stores that violate architecture
alignment rules. Is there any chance this a bug in ia64's
Pete Zaitcev wrote on Monday, December 11, 2006 5:29 PM
On Mon, 11 Dec 2006 15:52:47 -0800, Matt Helsley [EMAIL PROTECTED] wrote:
I'm shocked memcpy() introduces 8-byte stores that violate architecture
alignment rules. Is there any chance this a bug in ia64's memcpy()
implementation?
On Mon, 2006-12-11 at 17:50 -0800, David Miller wrote:
From: Pete Zaitcev [EMAIL PROTECTED]
Date: Mon, 11 Dec 2006 17:29:07 -0800
On Mon, 11 Dec 2006 15:52:47 -0800, Matt Helsley [EMAIL PROTECTED] wrote:
I'm shocked memcpy() introduces 8-byte stores that violate architecture
From: Matt Helsley [EMAIL PROTECTED]
Date: Mon, 11 Dec 2006 19:09:16 -0800
Hmm, that GCC assumption conflicts with the prototypes of memcpy() I've
seen.
When GCC expands __builtin_memcpy() internally it looks at the types
of the arguments, and what it knows about their guarenteed alignment.
On Sat, 9 Dec 2006 15:09:13 -0600, Erik Jacobson <[EMAIL PROTECTED]> wrote:
> > Please try to declare u64 timestamp_ns, then copy it into the *ev
> > instead of copying whole *ev. This ought to fix the problem if
> > buffer[] ends aligned to 32 bits or better.
>
> So I took this suggestion for a
> > Here, we just adjust how the variables are declared and use memcopy to
> > avoid the error messages.
> > - ev->timestamp_ns = timespec_to_ns();
> > + ev.timestamp_ns = timespec_to_ns();
> Please try to declare u64 timestamp_ns, then copy it into the *ev
> instead of copying whole *ev. This
Here, we just adjust how the variables are declared and use memcopy to
avoid the error messages.
- ev-timestamp_ns = timespec_to_ns(ts);
+ ev.timestamp_ns = timespec_to_ns(ts);
Please try to declare u64 timestamp_ns, then copy it into the *ev
instead of copying whole *ev. This ought
On Sat, 9 Dec 2006 15:09:13 -0600, Erik Jacobson [EMAIL PROTECTED] wrote:
Please try to declare u64 timestamp_ns, then copy it into the *ev
instead of copying whole *ev. This ought to fix the problem if
buffer[] ends aligned to 32 bits or better.
So I took this suggestion for a spin and
On Fri, 2006-12-08 at 19:20 -0800, Pete Zaitcev wrote:
> On Thu, 7 Dec 2006 17:22:13 -0600, Erik Jacobson <[EMAIL PROTECTED]> wrote:
Erik,
Thanks for cc'ing me on this patch.
> > Here, we just adjust how the variables are declared and use memcopy to
> > avoid the error messages.
> > -
On Thu, 7 Dec 2006 17:22:13 -0600, Erik Jacobson <[EMAIL PROTECTED]> wrote:
> Here, we just adjust how the variables are declared and use memcopy to
> avoid the error messages.
> - ev->timestamp_ns = timespec_to_ns();
> + ev.timestamp_ns = timespec_to_ns();
Please try to declare u64
On Thu, 7 Dec 2006 17:22:13 -0600, Erik Jacobson [EMAIL PROTECTED] wrote:
Here, we just adjust how the variables are declared and use memcopy to
avoid the error messages.
- ev-timestamp_ns = timespec_to_ns(ts);
+ ev.timestamp_ns = timespec_to_ns(ts);
Please try to declare u64
On Fri, 2006-12-08 at 19:20 -0800, Pete Zaitcev wrote:
On Thu, 7 Dec 2006 17:22:13 -0600, Erik Jacobson [EMAIL PROTECTED] wrote:
Erik,
Thanks for cc'ing me on this patch.
Here, we just adjust how the variables are declared and use memcopy to
avoid the error messages.
-
On ia64, the various functions that make up cn_proc.c cause kernel
unaligned access errors.
If you are using these, for example, to get notification about
all tasks forking and exiting, you get multiple unaligned access errors
per process.
Here, we just adjust how the variables are declared and
On ia64, the various functions that make up cn_proc.c cause kernel
unaligned access errors.
If you are using these, for example, to get notification about
all tasks forking and exiting, you get multiple unaligned access errors
per process.
Here, we just adjust how the variables are declared and
34 matches
Mail list logo
