Re: [vpp-dev] segfault due to movaps unaligned access

2018-05-04 Thread Damjan Marion 


I would suggest that instead of:

typedef struct
{
  u16 *resource_idx;
  struct rte_crypto_op **ops;
  u16 cipher_resource_idx[IPSEC_CRYPTO_N_ALG];
  u16 auth_resource_idx[IPSEC_INTEG_N_ALG];
CLIB_CACHE_LINE_ALIGN_MARK (pad);
} crypto_worker_main_t __attribute__ ((aligned (CLIB_CACHE_LINE_BYTES)));

We simply do:

typedef struct
{
CLIB_CACHE_LINE_ALIGN_MARK (cacheline0);
  u16 *resource_idx;
  struct rte_crypto_op **ops;
  u16 cipher_resource_idx[IPSEC_CRYPTO_N_ALG];
  u16 auth_resource_idx[IPSEC_INTEG_N_ALG];
} crypto_worker_main_t;

That will always automatically pad each element to the full cacheline. In 
conjunction with XXX_aligened macros it will always create data properly 
aligned.
Also, this is coding pattern we already do at many places and it helps to 
understand in GDB where the cacheline boundary is...

-- 
Damjan

> On 26 Apr 2018, at 18:08, Dave Barach <dbar...@cisco.com> wrote:
> 
> Yes, it’s arguably a compiler bug.
>
> But, it makes no sense to vec_validate_aligned(…), pool_get_aligned(…) etc. 
> objects whose size is not a multiple of the alignment request. Only the first 
> element will be aligned to the specified boundary. 
>
> __attribute__((aligned(xxx))) is not the same thing as ensuring that objects 
> are sized correctly.
>
> D.
>
> From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io 
> <mailto:vpp-dev@lists.fd.io>> On Behalf Of Radu Nicolau
> Sent: Thursday, April 26, 2018 4:54 AM
> To: Florin Coras <fcoras.li...@gmail.com <mailto:fcoras.li...@gmail.com>>
> Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] segfault due to movaps unaligned access
>
> Hi Florin,
>
> Thanks! The patch fixes the issue.
> Any idea why is it happening?
>
> Regards,
> Radu
>
>  <>From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
> [mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>] On Behalf Of Florin 
> Coras
> Sent: Tuesday, April 24, 2018 11:25 PM
> To: Nicolau, Radu <radu.nico...@intel.com <mailto:radu.nico...@intel.com>>
> Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] segfault due to movaps unaligned access
>
> Hi Radu, 
>
> Making the crypto_worker_main_t a full cache line in size (see patch [1]) 
> seems to solve the issue. Could you confirm?
>
> Florin
>
> [1] https://gerrit.fd.io/r/#/c/12086/ <https://gerrit.fd.io/r/#/c/12086/>
>
> 
> On Apr 24, 2018, at 9:23 AM, Radu Nicolau <radu.nico...@intel.com 
> <mailto:radu.nico...@intel.com>> wrote:
>
> Hello all,
>
> We’re seeing a weird issue, that is a segfault that looks to be caused by a 
> movaps instruction that is trying to access an address that is not 16 byte 
> aligned.
> The call originates from a vec_validate_init_empty_aligned that has the 
> argument aligned to 16 bytes.
> I have seen something like this in the past, we couldn’t find a root cause 
> and considered it a GCC bug (version 5 then), but now it pops up again on 
> version 7, so probably it isn’t.
> Any idea? A snapshot of the gdb screen below.
>
> gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
> https://postimg.cc/image/9jy4p38at/ <https://postimg.cc/image/9jy4p38at/>
>
> thanks and I will appreciate any help,
> Radu
>
>

Re: [vpp-dev] segfault due to movaps unaligned access

2018-05-03 Thread Marco Varlese 
On Thu, 2018-05-03 at 11:52 +, Dave Barach (dbarach) wrote:
> Dear Marco,
> 
> The condition that I'm testing for is different from the condition checked for
> by -fsanitize=alignment. 
> 
> Let's say that someone defines a packed structure which is ten bytes long.
> Clearly the compiler will not generate an aligned vector operation, nor will
> -fsanitize=alignment complain.
> 
> However, it doesn't make sense to allocate them in an aligned vector or pool -
> to a 64-byte boundary - since only the first element of the vector/pool will
> be aligned.
Thanks for taking the time to explain. Now, it makes sense to me.
> 
> The ASSERT I'm testing says that one of three things must be true: no
> alignment request, or the object size evenly divides the alignment request, or
> the alignment request evenly divides the object size.
Got you.
> 
> There are a certain number of mistakes to clean up.
> 
> HTH... Dave
Thanks,
Marco
> 
> -Original Message-
> From: Marco Varlese <mvarl...@suse.de> 
> Sent: Thursday, May 3, 2018 3:02 AM
> To: Dave Barach (dbarach) <dbar...@cisco.com>; Ray Kinsella <m...@ashroe.eu>; 
> v
> pp-...@lists.fd.io
> Subject: Re: [vpp-dev] segfault due to movaps unaligned access
> 
> Hi Dave,
> 
> On Wed, 2018-05-02 at 19:20 +, Dave Barach wrote:
> > Quick update. I added the obvious ASSERT, and immediately found a 
> > couple of non-compliant data structures. With two (trivial) fixes, vpp 
> > makes it to the debug CLI prompt. I'm going to start looking at "make 
> > test-debug", to see how many additional issues we may encounter.
> 
> Not sure if you missed my prev email but something I did in the past with this
> sort of errors was to compile the code with "-fsanitize=undefined" (or even
> simply -fsanitize=alignment).
> In that way, you don't have to place ASSERT statements yourself around
> "potential runtime error code" since the compiler will take care of
> highlighting those instances when you launch the executable.
> 
> Basically, once you compile it with that option and launch the tests you
> should be in a position to see all misalignments highlighted.
> 
> Don't know if you missed my email just wanted to follow up, maybe it might be
> quicker?
> 
> 
> Cheers,
> Marco
> > 
> > D. 
> > 
> > -Original Message-
> > From: Dave Barach (dbarach)
> > Sent: Tuesday, May 1, 2018 3:29 PM
> > To: Ray Kinsella <m...@ashroe.eu>; vpp-dev@lists.fd.io
> > Subject: RE: [vpp-dev] segfault due to movaps unaligned access
> > 
> > Hey Ray,
> > 
> > That's a good idea, and none too hard to implement. It's on my list.
> > 
> > I'm a bit afraid of what I may find when I turn it on, but anyhow...
> > 
> > Thanks... D.
> > 
> > -Original Message-
> > From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Ray 
> > Kinsella
> > Sent: Tuesday, May 1, 2018 10:58 AM
> > To: vpp-dev@lists.fd.io
> > Subject: Re: [vpp-dev] segfault due to movaps unaligned access
> > 
> > Is it worth to use an assert (or similar) to validate the assumption 
> > in the debug build at least. Well at least until the compiler bugs get's
> > sorted?
> > 
> > Ray K
> > 
> > On 26/04/2018 17:08, Dave Barach wrote:
> > > Yes, it’s arguably a compiler bug.
> > > 
> > > But, it makes no sense to vec_validate_aligned(…), 
> > > pool_get_aligned(…) etc. objects whose size is not a multiple of the
> > > alignment request.
> > > Only the first element will be aligned to the specified boundary.
> > > 
> > > __attribute__((aligned(xxx))) is not the same thing as ensuring that 
> > > objects are _sized_ correctly.
> > > 
> > > D.
> > > 
> > > *From:*vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> *On Behalf Of *Radu 
> > > Nicolau
> > > *Sent:* Thursday, April 26, 2018 4:54 AM
> > > *To:* Florin Coras <fcoras.li...@gmail.com>
> > > *Cc:* vpp-dev@lists.fd.io
> > > *Subject:* Re: [vpp-dev] segfault due to movaps unaligned access
> > > 
> > > Hi Florin,
> > > 
> > > Thanks! The patch fixes the issue.
> > > 
> > > Any idea why is it happening?
> > > 
> > > Regards,
> > > 
> > > Radu
> > > 
> > > *From:*vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
> > > [mailto:vpp-dev@lists.fd.io] *On Behalf Of *Florin Coras
> > > *Sent:* Tuesday, April 24, 2018 11:25 PM
> > > *To:* Nicolau, Radu <radu.nico

Re: [vpp-dev] segfault due to movaps unaligned access

2018-05-03 Thread Dave Barach 
Dear Marco,

The condition that I'm testing for is different from the condition checked for 
by -fsanitize=alignment. 

Let's say that someone defines a packed structure which is ten bytes long. 
Clearly the compiler will not generate an aligned vector operation, nor will 
-fsanitize=alignment complain.

However, it doesn't make sense to allocate them in an aligned vector or pool - 
to a 64-byte boundary - since only the first element of the vector/pool will be 
aligned.

The ASSERT I'm testing says that one of three things must be true: no alignment 
request, or the object size evenly divides the alignment request, or the 
alignment request evenly divides the object size.

There are a certain number of mistakes to clean up.

HTH... Dave

-Original Message-
From: Marco Varlese <mvarl...@suse.de> 
Sent: Thursday, May 3, 2018 3:02 AM
To: Dave Barach (dbarach) <dbar...@cisco.com>; Ray Kinsella <m...@ashroe.eu>; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] segfault due to movaps unaligned access

Hi Dave,

On Wed, 2018-05-02 at 19:20 +, Dave Barach wrote:
> Quick update. I added the obvious ASSERT, and immediately found a 
> couple of non-compliant data structures. With two (trivial) fixes, vpp 
> makes it to the debug CLI prompt. I'm going to start looking at "make 
> test-debug", to see how many additional issues we may encounter.
Not sure if you missed my prev email but something I did in the past with this 
sort of errors was to compile the code with "-fsanitize=undefined" (or even 
simply -fsanitize=alignment).
In that way, you don't have to place ASSERT statements yourself around 
"potential runtime error code" since the compiler will take care of 
highlighting those instances when you launch the executable.

Basically, once you compile it with that option and launch the tests you should 
be in a position to see all misalignments highlighted.

Don't know if you missed my email just wanted to follow up, maybe it might be 
quicker?


Cheers,
Marco
> 
> D. 
> 
> -Original Message-
> From: Dave Barach (dbarach)
> Sent: Tuesday, May 1, 2018 3:29 PM
> To: Ray Kinsella <m...@ashroe.eu>; vpp-dev@lists.fd.io
> Subject: RE: [vpp-dev] segfault due to movaps unaligned access
> 
> Hey Ray,
> 
> That's a good idea, and none too hard to implement. It's on my list.
> 
> I'm a bit afraid of what I may find when I turn it on, but anyhow...
> 
> Thanks... D.
> 
> -Original Message-
> From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Ray 
> Kinsella
> Sent: Tuesday, May 1, 2018 10:58 AM
> To: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] segfault due to movaps unaligned access
> 
> Is it worth to use an assert (or similar) to validate the assumption 
> in the debug build at least. Well at least until the compiler bugs get's 
> sorted?
> 
> Ray K
> 
> On 26/04/2018 17:08, Dave Barach wrote:
> > Yes, it’s arguably a compiler bug.
> > 
> > But, it makes no sense to vec_validate_aligned(…), 
> > pool_get_aligned(…) etc. objects whose size is not a multiple of the 
> > alignment request.
> > Only the first element will be aligned to the specified boundary.
> > 
> > __attribute__((aligned(xxx))) is not the same thing as ensuring that 
> > objects are _sized_ correctly.
> > 
> > D.
> > 
> > *From:*vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> *On Behalf Of *Radu 
> > Nicolau
> > *Sent:* Thursday, April 26, 2018 4:54 AM
> > *To:* Florin Coras <fcoras.li...@gmail.com>
> > *Cc:* vpp-dev@lists.fd.io
> > *Subject:* Re: [vpp-dev] segfault due to movaps unaligned access
> > 
> > Hi Florin,
> > 
> > Thanks! The patch fixes the issue.
> > 
> > Any idea why is it happening?
> > 
> > Regards,
> > 
> > Radu
> > 
> > *From:*vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
> > [mailto:vpp-dev@lists.fd.io] *On Behalf Of *Florin Coras
> > *Sent:* Tuesday, April 24, 2018 11:25 PM
> > *To:* Nicolau, Radu <radu.nico...@intel.com 
> > <mailto:radu.nico...@intel.com>>
> > *Cc:* vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> > *Subject:* Re: [vpp-dev] segfault due to movaps unaligned access
> > 
> > Hi Radu,
> > 
> > Making the crypto_worker_main_t a full cache line in size (see patch
> > [1]) seems to solve the issue. Could you confirm?
> > 
> > Florin
> > 
> > [1] https://gerrit.fd.io/r/#/c/12086/
> > 
> > On Apr 24, 2018, at 9:23 AM, Radu Nicolau <radu.nico...@intel.com
> > <mailto:radu.nico...@intel.com>> wrote:
> > 
> > Hello all,
> > 
> > We’re seeing a weird issue, t

Re: [vpp-dev] segfault due to movaps unaligned access

2018-05-03 Thread Marco Varlese 
Hi Dave,

On Wed, 2018-05-02 at 19:20 +, Dave Barach wrote:
> Quick update. I added the obvious ASSERT, and immediately found a couple of
> non-compliant data structures. With two (trivial) fixes, vpp makes it to the
> debug CLI prompt. I'm going to start looking at "make test-debug", to see how
> many additional issues we may encounter.
Not sure if you missed my prev email but something I did in the past with this
sort of errors was to compile the code with "-fsanitize=undefined" (or even
simply -fsanitize=alignment).
In that way, you don't have to place ASSERT statements yourself around
"potential runtime error code" since the compiler will take care of highlighting
those instances when you launch the executable.

Basically, once you compile it with that option and launch the tests you should
be in a position to see all misalignments highlighted.

Don't know if you missed my email just wanted to follow up, maybe it might be
quicker?


Cheers,
Marco
> 
> D. 
> 
> -Original Message-
> From: Dave Barach (dbarach) 
> Sent: Tuesday, May 1, 2018 3:29 PM
> To: Ray Kinsella <m...@ashroe.eu>; vpp-dev@lists.fd.io
> Subject: RE: [vpp-dev] segfault due to movaps unaligned access
> 
> Hey Ray,
> 
> That's a good idea, and none too hard to implement. It's on my list.
> 
> I'm a bit afraid of what I may find when I turn it on, but anyhow...
> 
> Thanks... D.
> 
> -Original Message-
> From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Ray Kinsella
> Sent: Tuesday, May 1, 2018 10:58 AM
> To: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] segfault due to movaps unaligned access
> 
> Is it worth to use an assert (or similar) to validate the assumption in the
> debug build at least. Well at least until the compiler bugs get's sorted?
> 
> Ray K
> 
> On 26/04/2018 17:08, Dave Barach wrote:
> > Yes, it’s arguably a compiler bug.
> > 
> > But, it makes no sense to vec_validate_aligned(…), pool_get_aligned(…) 
> > etc. objects whose size is not a multiple of the alignment request.
> > Only the first element will be aligned to the specified boundary.
> > 
> > __attribute__((aligned(xxx))) is not the same thing as ensuring that 
> > objects are _sized_ correctly.
> > 
> > D.
> > 
> > *From:*vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> *On Behalf Of *Radu 
> > Nicolau
> > *Sent:* Thursday, April 26, 2018 4:54 AM
> > *To:* Florin Coras <fcoras.li...@gmail.com>
> > *Cc:* vpp-dev@lists.fd.io
> > *Subject:* Re: [vpp-dev] segfault due to movaps unaligned access
> > 
> > Hi Florin,
> > 
> > Thanks! The patch fixes the issue.
> > 
> > Any idea why is it happening?
> > 
> > Regards,
> > 
> > Radu
> > 
> > *From:*vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
> > [mailto:vpp-dev@lists.fd.io] *On Behalf Of *Florin Coras
> > *Sent:* Tuesday, April 24, 2018 11:25 PM
> > *To:* Nicolau, Radu <radu.nico...@intel.com 
> > <mailto:radu.nico...@intel.com>>
> > *Cc:* vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> > *Subject:* Re: [vpp-dev] segfault due to movaps unaligned access
> > 
> > Hi Radu,
> > 
> > Making the crypto_worker_main_t a full cache line in size (see patch
> > [1]) seems to solve the issue. Could you confirm?
> > 
> > Florin
> > 
> > [1] https://gerrit.fd.io/r/#/c/12086/
> > 
> > On Apr 24, 2018, at 9:23 AM, Radu Nicolau <radu.nico...@intel.com
> > <mailto:radu.nico...@intel.com>> wrote:
> > 
> > Hello all,
> > 
> > We’re seeing a weird issue, that is a segfault that looks to be
> > caused by a movaps instruction that is trying to access an address
> > that is not 16 byte aligned.
> > 
> > The call originates from a vec_validate_init_empty_aligned that has
> > the argument aligned to 16 bytes.
> > 
> > I have seen something like this in the past, we couldn’t find a root
> > cause and considered it a GCC bug (version 5 then), but now it pops
> > up again on version 7, so probably it isn’t.
> > 
> > Any idea? A snapshot of the gdb screen below.
> > 
> > gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
> > 
> > https://postimg.cc/image/9jy4p38at/
> > 
> > thanks and I will appreciate any help,
> > 
> > Radu
> > 
> > 
> 
> 
> 
> 
> 
> 
-- 
Marco V

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#9157): https://lists.fd.io/g/vpp-dev/message/9157
View All Messages In Topic (15): https://lists.fd.io/g/vpp-dev/topic/18058213
Mute This Topic: https://lists.fd.io/mt/18058213/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] segfault due to movaps unaligned access

2018-05-02 Thread Dave Barach 
Quick update. I added the obvious ASSERT, and immediately found a couple of 
non-compliant data structures. With two (trivial) fixes, vpp makes it to the 
debug CLI prompt. I'm going to start looking at "make test-debug", to see how 
many additional issues we may encounter.

D. 

-Original Message-
From: Dave Barach (dbarach) 
Sent: Tuesday, May 1, 2018 3:29 PM
To: Ray Kinsella <m...@ashroe.eu>; vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] segfault due to movaps unaligned access

Hey Ray,

That's a good idea, and none too hard to implement. It's on my list.

I'm a bit afraid of what I may find when I turn it on, but anyhow...

Thanks... D.

-Original Message-
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Ray Kinsella
Sent: Tuesday, May 1, 2018 10:58 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] segfault due to movaps unaligned access

Is it worth to use an assert (or similar) to validate the assumption in the 
debug build at least. Well at least until the compiler bugs get's sorted?

Ray K

On 26/04/2018 17:08, Dave Barach wrote:
> Yes, it’s arguably a compiler bug.
> 
> But, it makes no sense to vec_validate_aligned(…), pool_get_aligned(…) 
> etc. objects whose size is not a multiple of the alignment request.
> Only the first element will be aligned to the specified boundary.
> 
> __attribute__((aligned(xxx))) is not the same thing as ensuring that 
> objects are _sized_ correctly.
> 
> D.
> 
> *From:*vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> *On Behalf Of *Radu 
> Nicolau
> *Sent:* Thursday, April 26, 2018 4:54 AM
> *To:* Florin Coras <fcoras.li...@gmail.com>
> *Cc:* vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] segfault due to movaps unaligned access
> 
> Hi Florin,
> 
> Thanks! The patch fixes the issue.
> 
> Any idea why is it happening?
> 
> Regards,
> 
> Radu
> 
> *From:*vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
> [mailto:vpp-dev@lists.fd.io] *On Behalf Of *Florin Coras
> *Sent:* Tuesday, April 24, 2018 11:25 PM
> *To:* Nicolau, Radu <radu.nico...@intel.com 
> <mailto:radu.nico...@intel.com>>
> *Cc:* vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> *Subject:* Re: [vpp-dev] segfault due to movaps unaligned access
> 
> Hi Radu,
> 
> Making the crypto_worker_main_t a full cache line in size (see patch
> [1]) seems to solve the issue. Could you confirm?
> 
> Florin
> 
> [1] https://gerrit.fd.io/r/#/c/12086/
> 
> On Apr 24, 2018, at 9:23 AM, Radu Nicolau <radu.nico...@intel.com
> <mailto:radu.nico...@intel.com>> wrote:
> 
> Hello all,
> 
> We’re seeing a weird issue, that is a segfault that looks to be
> caused by a movaps instruction that is trying to access an address
> that is not 16 byte aligned.
> 
> The call originates from a vec_validate_init_empty_aligned that has
> the argument aligned to 16 bytes.
> 
> I have seen something like this in the past, we couldn’t find a root
> cause and considered it a GCC bug (version 5 then), but now it pops
> up again on version 7, so probably it isn’t.
> 
> Any idea? A snapshot of the gdb screen below.
> 
> gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
> 
> https://postimg.cc/image/9jy4p38at/
> 
> thanks and I will appreciate any help,
> 
> Radu
> 
> 




-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#9151): https://lists.fd.io/g/vpp-dev/message/9151
View All Messages In Topic (14): https://lists.fd.io/g/vpp-dev/topic/18058213
Mute This Topic: https://lists.fd.io/mt/18058213/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] segfault due to movaps unaligned access

2018-05-01 Thread Dave Barach 
Hey Ray,

That's a good idea, and none too hard to implement. It's on my list.

I'm a bit afraid of what I may find when I turn it on, but anyhow...

Thanks... D.

-Original Message-
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Ray Kinsella
Sent: Tuesday, May 1, 2018 10:58 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] segfault due to movaps unaligned access

Is it worth to use an assert (or similar) to validate the assumption in the 
debug build at least. Well at least until the compiler bugs get's sorted?

Ray K

On 26/04/2018 17:08, Dave Barach wrote:
> Yes, it’s arguably a compiler bug.
> 
> But, it makes no sense to vec_validate_aligned(…), pool_get_aligned(…) 
> etc. objects whose size is not a multiple of the alignment request. 
> Only the first element will be aligned to the specified boundary.
> 
> __attribute__((aligned(xxx))) is not the same thing as ensuring that 
> objects are _sized_ correctly.
> 
> D.
> 
> *From:*vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> *On Behalf Of *Radu 
> Nicolau
> *Sent:* Thursday, April 26, 2018 4:54 AM
> *To:* Florin Coras <fcoras.li...@gmail.com>
> *Cc:* vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] segfault due to movaps unaligned access
> 
> Hi Florin,
> 
> Thanks! The patch fixes the issue.
> 
> Any idea why is it happening?
> 
> Regards,
> 
> Radu
> 
> *From:*vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
> [mailto:vpp-dev@lists.fd.io] *On Behalf Of *Florin Coras
> *Sent:* Tuesday, April 24, 2018 11:25 PM
> *To:* Nicolau, Radu <radu.nico...@intel.com 
> <mailto:radu.nico...@intel.com>>
> *Cc:* vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> *Subject:* Re: [vpp-dev] segfault due to movaps unaligned access
> 
> Hi Radu,
> 
> Making the crypto_worker_main_t a full cache line in size (see patch
> [1]) seems to solve the issue. Could you confirm?
> 
> Florin
> 
> [1] https://gerrit.fd.io/r/#/c/12086/
> 
> On Apr 24, 2018, at 9:23 AM, Radu Nicolau <radu.nico...@intel.com
> <mailto:radu.nico...@intel.com>> wrote:
> 
> Hello all,
> 
> We’re seeing a weird issue, that is a segfault that looks to be
> caused by a movaps instruction that is trying to access an address
> that is not 16 byte aligned.
> 
> The call originates from a vec_validate_init_empty_aligned that has
> the argument aligned to 16 bytes.
> 
> I have seen something like this in the past, we couldn’t find a root
> cause and considered it a GCC bug (version 5 then), but now it pops
> up again on version 7, so probably it isn’t.
> 
> Any idea? A snapshot of the gdb screen below.
> 
> gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
> 
> https://postimg.cc/image/9jy4p38at/
> 
> thanks and I will appreciate any help,
> 
> Radu
> 
> 




-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#9129): https://lists.fd.io/g/vpp-dev/message/9129
View All Messages In Topic (13): https://lists.fd.io/g/vpp-dev/topic/18058213
Mute This Topic: https://lists.fd.io/mt/18058213/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] segfault due to movaps unaligned access

2018-05-01 Thread Ray Kinsella 
Is it worth to use an assert (or similar) to validate the assumption in 
the debug build at least. Well at least until the compiler bugs get's 
sorted?


Ray K

On 26/04/2018 17:08, Dave Barach wrote:

Yes, it’s arguably a compiler bug.

But, it makes no sense to vec_validate_aligned(…), pool_get_aligned(…) 
etc. objects whose size is not a multiple of the alignment request. Only 
the first element will be aligned to the specified boundary.


__attribute__((aligned(xxx))) is not the same thing as ensuring that 
objects are _sized_ correctly.


D.

*From:*vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> *On Behalf Of *Radu Nicolau
*Sent:* Thursday, April 26, 2018 4:54 AM
*To:* Florin Coras <fcoras.li...@gmail.com>
*Cc:* vpp-dev@lists.fd.io
*Subject:* Re: [vpp-dev] segfault due to movaps unaligned access

Hi Florin,

Thanks! The patch fixes the issue.

Any idea why is it happening?

Regards,

Radu

*From:*vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
[mailto:vpp-dev@lists.fd.io] *On Behalf Of *Florin Coras

*Sent:* Tuesday, April 24, 2018 11:25 PM
*To:* Nicolau, Radu <radu.nico...@intel.com <mailto:radu.nico...@intel.com>>
*Cc:* vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
*Subject:* Re: [vpp-dev] segfault due to movaps unaligned access

Hi Radu,

Making the crypto_worker_main_t a full cache line in size (see patch 
[1]) seems to solve the issue. Could you confirm?


Florin

[1] https://gerrit.fd.io/r/#/c/12086/

On Apr 24, 2018, at 9:23 AM, Radu Nicolau <radu.nico...@intel.com
<mailto:radu.nico...@intel.com>> wrote:

Hello all,

We’re seeing a weird issue, that is a segfault that looks to be
caused by a movaps instruction that is trying to access an address
that is not 16 byte aligned.

The call originates from a vec_validate_init_empty_aligned that has
the argument aligned to 16 bytes.

I have seen something like this in the past, we couldn’t find a root
cause and considered it a GCC bug (version 5 then), but now it pops
up again on version 7, so probably it isn’t.

Any idea? A snapshot of the gdb screen below.

gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0

https://postimg.cc/image/9jy4p38at/

thanks and I will appreciate any help,

Radu




-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#9128): https://lists.fd.io/g/vpp-dev/message/9128
View All Messages In Topic (12): https://lists.fd.io/g/vpp-dev/topic/18058213
Mute This Topic: https://lists.fd.io/mt/18058213/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] segfault due to movaps unaligned access

2018-04-27 Thread Sergio G.M. 
 Hi,

I have to admit that the intention (when I wrote the code) of the
__attribute__ ((aligned(64))) on the typedef struct was to have elements
properly sized.

I thought to remember that I did look at this attribute behavior before but
then again my memory is not as reliable as I wish for, so nothing like some
testing to find out.

struct A {
short f[3];
} __attribute__ ((aligned (64)));

struct A a[2];

sizeof(struct A) = 64, sizeof(a) = 128 for both GCC and CLANG.
This is the sort of behavior I was expecting.

typedef struct B {
short f[3];
} b_t __attribute__ ((aligned (64)));

b_t b[2];

Interestingly enough, when defining the typedef like above, GCC fails to
compile with:
error: alignment of array elements is greater than element size
sizeof(b_t) = 6 for CLANG and what it looks wrong to me is sizeof(b) = 64.

typedef struct C {
short f[3];
} __attribute__ ((aligned (64))) c_t;

c_t c[2];

sizeof(c_t) = 64, sizeof(c) = 128 for both GCC and CLANG.

As far as allocations from the heap, __attribute__ ((aligned(xxx))) should
have the desired effect.

That being said and even though it seems to behave as I thought it should,
the error GCC throws in one of the cases makes me wonder if we should not
rely on the compiler and just add mark fields to the struct to achieve the
desired size.

Below is the link with some code to play around:
https://godbolt.org/g/7RDBQG

Regards,
Sergio


On 27 April 2018 at 10:34, Radu Nicolau <radu.nico...@intel.com> wrote:

> Thanks for looking into it!
>
>
>
> In addition, If I understand correctly, using
> __attribute__((aligned(xxx))) on structs that are only allocated from heap
> doesn’t actually do anything (but sometimes confuse gcc into generating
> misaligned accesses).
>
>
>
> *From:* Dave Barach (dbarach) [mailto:dbar...@cisco.com]
> *Sent:* Thursday, April 26, 2018 5:08 PM
> *To:* Nicolau, Radu <radu.nico...@intel.com>; Florin Coras <
> fcoras.li...@gmail.com>
> *Cc:* vpp-dev@lists.fd.io
> *Subject:* RE: [vpp-dev] segfault due to movaps unaligned access
>
>
>
> Yes, it’s arguably a compiler bug.
>
>
>
> But, it makes no sense to vec_validate_aligned(…), pool_get_aligned(…)
> etc. objects whose size is not a multiple of the alignment request. Only
> the first element will be aligned to the specified boundary.
>
>
>
> __attribute__((aligned(xxx))) is not the same thing as ensuring that
> objects are *sized* correctly.
>
>
>
> D.
>
>
>
> *From:* vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> *On Behalf Of *Radu
> Nicolau
> *Sent:* Thursday, April 26, 2018 4:54 AM
> *To:* Florin Coras <fcoras.li...@gmail.com>
> *Cc:* vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] segfault due to movaps unaligned access
>
>
>
> Hi Florin,
>
>
>
> Thanks! The patch fixes the issue.
>
> Any idea why is it happening?
>
>
>
> Regards,
>
> Radu
>
>
>
> *From:* vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io
> <vpp-dev@lists.fd.io>] *On Behalf Of *Florin Coras
> *Sent:* Tuesday, April 24, 2018 11:25 PM
> *To:* Nicolau, Radu <radu.nico...@intel.com>
> *Cc:* vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] segfault due to movaps unaligned access
>
>
>
> Hi Radu,
>
>
>
> Making the crypto_worker_main_t a full cache line in size (see patch [1])
> seems to solve the issue. Could you confirm?
>
>
>
> Florin
>
>
>
> [1] https://gerrit.fd.io/r/#/c/12086/
>
>
>
> On Apr 24, 2018, at 9:23 AM, Radu Nicolau <radu.nico...@intel.com> wrote:
>
>
>
> Hello all,
>
>
>
> We’re seeing a weird issue, that is a segfault that looks to be caused by
> a movaps instruction that is trying to access an address that is not 16
> byte aligned.
>
> The call originates from a vec_validate_init_empty_aligned that has the
> argument aligned to 16 bytes.
>
> I have seen something like this in the past, we couldn’t find a root cause
> and considered it a GCC bug (version 5 then), but now it pops up again on
> version 7, so probably it isn’t.
>
> Any idea? A snapshot of the gdb screen below.
>
>
>
> gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
>
> https://postimg.cc/image/9jy4p38at/
>
>
>
> thanks and I will appreciate any help,
>
> Radu
>
>
>
> 
>
>

Re: [vpp-dev] segfault due to movaps unaligned access

2018-04-27 Thread Marco Varlese 
Hi,
On Fri, 2018-04-27 at 10:04 +, Sergio Gonzalez Monroy wrote:
> Hi,
> 
>
> 
> I have to admit that the intention (when I wrote the code) of the
> __attribute__ ((aligned(64))) on the typedef struct was to have elements
> properly sized.
> 
>
> 
> I thought to remember that I did look at this attribute behavior before but
> then again my memory is not as reliable as I wish for, so nothing like some
> testing to find out.
> 
>
> 
> struct A {
> 
> short f[3];
> 
> } __attribute__ ((aligned (64)));
> 
>
> 
> struct A a[2];
> 
>
> 
> sizeof(struct A) = 64, sizeof(a) = 128 for both GCC and CLANG.
> 
> This is the sort of behavior I was expecting. 
> 
>
> 
> typedef struct B {
> 
> short f[3];
> 
> } b_t __attribute__ ((aligned (64)));
> 
>
> 
> b_t b[2];
> 
>
> 
> Interestingly enough, when defining the typedef like above, GCC fails to
> compile with:
> 
> error: alignment of array elements is greater than element size
> 
> sizeof(b_t) = 6 for CLANG and what it looks wrong to me is sizeof(b) = 64.
> 
>
> 
> typedef struct C {
> 
> short f[3];
> 
> } __attribute__ ((aligned (64))) c_t;
> 
>
> 
> c_t c[2];
> 
>
> 
> sizeof(c_t) = 64, sizeof(c) = 128 for both GCC and CLANG.
> 
>
> 
> As far as allocations from the heap, __attribute__ ((aligned(xxx))) should
> have the desired effect.
> 
>
> 
> That being said and even though it seems to behave as I thought it should, the
> error GCC throws in one of the cases makes me wonder if we should not rely on
> the compiler and just add mark fields to the struct to achieve the desired
> size.
According to the GCC documentation (https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/T
ype-Attributes.html): id="-x-evo-selection-start-marker">"Note that the
effectiveness of aligned attributes may be limited by inherent limitations in
your linker. On many systems, the linker is only able to arrange for variables
to be aligned up to a certain maximum alignment. (For some linkers, the maximum
supported alignment may be very very small.) If your linker is only able to
align variables up to a maximum of 8 byte alignment, then specifying aligned(16)
in an __attribute__ will still only provide you with 8 byte alignment. See your
linker documentation for further information."
Having said that, it is always possible to compile the code (temporarily) with
"-fsanitize=undefined" which would show up all the misaligned accesses which
could cause run-time errors.
>
> Below is the link with some code to play around:
> https://godbolt.org/g/7RDBQG
>
> Regards,
> Sergio
>
>
> 
> From: Radu Nicolau
> 
> Sent: Friday 27 April 2018 10:34
> 
> To: Dave Barach (dbarach); 
> Florin Coras
> 
> Cc: vpp-dev@lists.fd.io
> 
> Subject: Re: [vpp-dev] segfault due to movaps unaligned access
> 
>
> Thanks for looking into it!
>
> In addition, If I understand correctly, using __attribute__((aligned(xxx))) on
> structs that are only allocated from heap doesn’t actually do anything (but
> sometimes confuse gcc into generating misaligned
>  accesses).
>
> 
> 
> From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
> 
> 
> Sent: Thursday, April 26, 2018 5:08 PM
> 
> To: Nicolau, Radu <radu.nico...@intel.com>; Florin Coras <fcoras.lists@gmail.c
> om>
> 
> Cc: vpp-dev@lists.fd.io
> 
> Subject: RE: [vpp-dev] segfault due to movaps unaligned access
> 
> 
>
> Yes, it’s arguably a compiler bug.
>
> But, it makes no sense to vec_validate_aligned(…), pool_get_aligned(…) etc.
> objects whose size is not a multiple of the alignment request. Only the first
> element will be aligned to the
>  specified boundary. 
>
> __attribute__((aligned(xxx))) is not the same thing as ensuring that objects
> are
> sized correctly.
>
> D.
>
> 
> 
> From: 
> vpp-dev@lists.fd.io <vpp-dev@lists.fd.io>
> On Behalf Of Radu Nicolau
> 
> Sent: Thursday, April 26, 2018 4:54 AM
> 
> To: Florin Coras <fcoras.li...@gmail.com>
> 
> Cc: vpp-dev@lists.fd.io
> 
> Subject: Re: [vpp-dev] segfault due to movaps unaligned access
> 
> 
>
> Hi Florin,
>
> Thanks! The patch fixes the issue.
> 
> Any idea why is it happening?
>
> Regards,
> Radu
>
> 
> 
> From: 
> vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io]
> On Behalf Of Florin Coras
> 
> Sent: Tuesday, April 24, 2018 11:25 PM
> 
> To: Nicolau, Radu <radu.nico...@intel.com>
> 
> Cc: vpp-dev@lists.fd.io
> 
> Subject: Re: [vpp-dev] segfault due to movaps unaligned access
> 
> 
>
> Hi Radu, 
>

Re: [vpp-dev] segfault due to movaps unaligned access

2018-04-27 Thread Sergio Gonzalez Monroy 
Hi,

I have to admit that the intention (when I wrote the code) of the __attribute__ 
((aligned(64))) on the typedef struct was to have elements properly sized.

I thought to remember that I did look at this attribute behavior before but 
then again my memory is not as reliable as I wish for, so nothing like some 
testing to find out.

struct A {
short f[3];
} __attribute__ ((aligned (64)));

struct A a[2];

sizeof(struct A) = 64, sizeof(a) = 128 for both GCC and CLANG.
This is the sort of behavior I was expecting.

typedef struct B {
short f[3];
} b_t __attribute__ ((aligned (64)));

b_t b[2];

Interestingly enough, when defining the typedef like above, GCC fails to 
compile with:
error: alignment of array elements is greater than element size
sizeof(b_t) = 6 for CLANG and what it looks wrong to me is sizeof(b) = 64.

typedef struct C {
short f[3];
} __attribute__ ((aligned (64))) c_t;

c_t c[2];

sizeof(c_t) = 64, sizeof(c) = 128 for both GCC and CLANG.

As far as allocations from the heap, __attribute__ ((aligned(xxx))) should have 
the desired effect.

That being said and even though it seems to behave as I thought it should, the 
error GCC throws in one of the cases makes me wonder if we should not rely on 
the compiler and just add mark fields to the struct to achieve the desired size.

Below is the link with some code to play around:
https://godbolt.org/g/7RDBQG

Regards,
Sergio


From: Radu Nicolau<mailto:radu.nico...@intel.com>
Sent: Friday 27 April 2018 10:34
To: Dave Barach (dbarach)<mailto:dbar...@cisco.com>; Florin 
Coras<mailto:fcoras.li...@gmail.com>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] segfault due to movaps unaligned access

Thanks for looking into it!

In addition, If I understand correctly, using __attribute__((aligned(xxx))) on 
structs that are only allocated from heap doesn’t actually do anything (but 
sometimes confuse gcc into generating misaligned accesses).

From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
Sent: Thursday, April 26, 2018 5:08 PM
To: Nicolau, Radu <radu.nico...@intel.com>; Florin Coras 
<fcoras.li...@gmail.com>
Cc: vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] segfault due to movaps unaligned access

Yes, it’s arguably a compiler bug.

But, it makes no sense to vec_validate_aligned(…), pool_get_aligned(…) etc. 
objects whose size is not a multiple of the alignment request. Only the first 
element will be aligned to the specified boundary.

__attribute__((aligned(xxx))) is not the same thing as ensuring that objects 
are sized correctly.

D.

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> On Behalf Of Radu Nicolau
Sent: Thursday, April 26, 2018 4:54 AM
To: Florin Coras <fcoras.li...@gmail.com<mailto:fcoras.li...@gmail.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] segfault due to movaps unaligned access

Hi Florin,

Thanks! The patch fixes the issue.
Any idea why is it happening?

Regards,
Radu

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
[mailto:vpp-dev@lists.fd.io] On Behalf Of Florin Coras
Sent: Tuesday, April 24, 2018 11:25 PM
To: Nicolau, Radu <radu.nico...@intel.com<mailto:radu.nico...@intel.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] segfault due to movaps unaligned access

Hi Radu,

Making the crypto_worker_main_t a full cache line in size (see patch [1]) seems 
to solve the issue. Could you confirm?

Florin

[1] https://gerrit.fd.io/r/#/c/12086/

On Apr 24, 2018, at 9:23 AM, Radu Nicolau 
<radu.nico...@intel.com<mailto:radu.nico...@intel.com>> wrote:

Hello all,

We’re seeing a weird issue, that is a segfault that looks to be caused by a 
movaps instruction that is trying to access an address that is not 16 byte 
aligned.
The call originates from a vec_validate_init_empty_aligned that has the 
argument aligned to 16 bytes.
I have seen something like this in the past, we couldn’t find a root cause and 
considered it a GCC bug (version 5 then), but now it pops up again on version 
7, so probably it isn’t.
Any idea? A snapshot of the gdb screen below.

gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
https://postimg.cc/image/9jy4p38at/

thanks and I will appreciate any help,
Radu

Re: [vpp-dev] segfault due to movaps unaligned access

2018-04-27 Thread Radu Nicolau 
Thanks for looking into it!

In addition, If I understand correctly, using __attribute__((aligned(xxx))) on 
structs that are only allocated from heap doesn’t actually do anything (but 
sometimes confuse gcc into generating misaligned accesses).

From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
Sent: Thursday, April 26, 2018 5:08 PM
To: Nicolau, Radu <radu.nico...@intel.com>; Florin Coras 
<fcoras.li...@gmail.com>
Cc: vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] segfault due to movaps unaligned access

Yes, it’s arguably a compiler bug.

But, it makes no sense to vec_validate_aligned(…), pool_get_aligned(…) etc. 
objects whose size is not a multiple of the alignment request. Only the first 
element will be aligned to the specified boundary.

__attribute__((aligned(xxx))) is not the same thing as ensuring that objects 
are sized correctly.

D.

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> On Behalf Of Radu Nicolau
Sent: Thursday, April 26, 2018 4:54 AM
To: Florin Coras <fcoras.li...@gmail.com<mailto:fcoras.li...@gmail.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] segfault due to movaps unaligned access

Hi Florin,

Thanks! The patch fixes the issue.
Any idea why is it happening?

Regards,
Radu

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
[mailto:vpp-dev@lists.fd.io] On Behalf Of Florin Coras
Sent: Tuesday, April 24, 2018 11:25 PM
To: Nicolau, Radu <radu.nico...@intel.com<mailto:radu.nico...@intel.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] segfault due to movaps unaligned access

Hi Radu,

Making the crypto_worker_main_t a full cache line in size (see patch [1]) seems 
to solve the issue. Could you confirm?

Florin

[1] https://gerrit.fd.io/r/#/c/12086/

On Apr 24, 2018, at 9:23 AM, Radu Nicolau 
<radu.nico...@intel.com<mailto:radu.nico...@intel.com>> wrote:

Hello all,

We’re seeing a weird issue, that is a segfault that looks to be caused by a 
movaps instruction that is trying to access an address that is not 16 byte 
aligned.
The call originates from a vec_validate_init_empty_aligned that has the 
argument aligned to 16 bytes.
I have seen something like this in the past, we couldn’t find a root cause and 
considered it a GCC bug (version 5 then), but now it pops up again on version 
7, so probably it isn’t.
Any idea? A snapshot of the gdb screen below.

gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
https://postimg.cc/image/9jy4p38at/

thanks and I will appreciate any help,
Radu

Re: [vpp-dev] segfault due to movaps unaligned access

2018-04-26 Thread Dave Barach 
Yes, it’s arguably a compiler bug.

But, it makes no sense to vec_validate_aligned(…), pool_get_aligned(…) etc. 
objects whose size is not a multiple of the alignment request. Only the first 
element will be aligned to the specified boundary.

__attribute__((aligned(xxx))) is not the same thing as ensuring that objects 
are sized correctly.

D.

From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Radu Nicolau
Sent: Thursday, April 26, 2018 4:54 AM
To: Florin Coras <fcoras.li...@gmail.com>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] segfault due to movaps unaligned access

Hi Florin,

Thanks! The patch fixes the issue.
Any idea why is it happening?

Regards,
Radu

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
[mailto:vpp-dev@lists.fd.io] On Behalf Of Florin Coras
Sent: Tuesday, April 24, 2018 11:25 PM
To: Nicolau, Radu <radu.nico...@intel.com<mailto:radu.nico...@intel.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] segfault due to movaps unaligned access

Hi Radu,

Making the crypto_worker_main_t a full cache line in size (see patch [1]) seems 
to solve the issue. Could you confirm?

Florin

[1] https://gerrit.fd.io/r/#/c/12086/

On Apr 24, 2018, at 9:23 AM, Radu Nicolau 
<radu.nico...@intel.com<mailto:radu.nico...@intel.com>> wrote:

Hello all,

We’re seeing a weird issue, that is a segfault that looks to be caused by a 
movaps instruction that is trying to access an address that is not 16 byte 
aligned.
The call originates from a vec_validate_init_empty_aligned that has the 
argument aligned to 16 bytes.
I have seen something like this in the past, we couldn’t find a root cause and 
considered it a GCC bug (version 5 then), but now it pops up again on version 
7, so probably it isn’t.
Any idea? A snapshot of the gdb screen below.

gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
https://postimg.cc/image/9jy4p38at/

thanks and I will appreciate any help,
Radu

Re: [vpp-dev] segfault due to movaps unaligned access

2018-04-26 Thread Florin Coras 
Yup, it surely seems so. 

Florin

> On Apr 26, 2018, at 8:40 AM, Nicolau, Radu <radu.nico...@intel.com> wrote:
> 
> Hi,
>
> If elements of the vector are 54 bytes and first is aligned, accessing the 
> second one should not generate instructions that assume it is aligned as 
> well. So based on that and your description, this is a gcc bug, right? The 
> issue does not occur on gcc 6.3, 6.4 but occurs on 7.2.0 and 7.3.1 (and I’ve 
> seen it a while ago on 5.x).
>   <>
> Regards,
> Radu
>  <>From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
> [mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>] On Behalf Of Florin 
> Coras
> Sent: Thursday, April 26, 2018 4:13 PM
> To: Nicolau, Radu <radu.nico...@intel.com <mailto:radu.nico...@intel.com>>
> Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] segfault due to movaps unaligned access
>
> Hi Radu, 
>
> The problem was that the vector was expected to have cacheline size aligned 
> data, but the elements in the vector were not a multiple of a cache line 
> (size was 54). As a result, the first element was aligned and the rest were 
> not. The vector infra just allocates an aligned chunk of memory, it does not 
> guarantee anything with respect to individual element placement.
>
> Hope it helps!
>
> Cheers,
> Florin
> 
> 
> On Apr 26, 2018, at 1:53 AM, Nicolau, Radu <radu.nico...@intel.com 
> <mailto:radu.nico...@intel.com>> wrote:
>
> Hi Florin,
>
> Thanks! The patch fixes the issue.
> Any idea why is it happening?
>
> Regards,
> Radu
>
> From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
> [mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>] On Behalf Of Florin 
> Coras
> Sent: Tuesday, April 24, 2018 11:25 PM
> To: Nicolau, Radu <radu.nico...@intel.com <mailto:radu.nico...@intel.com>>
> Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] segfault due to movaps unaligned access
>
> Hi Radu, 
>
> Making the crypto_worker_main_t a full cache line in size (see patch [1]) 
> seems to solve the issue. Could you confirm?
>
> Florin
>
> [1] https://gerrit.fd.io/r/#/c/12086/ <https://gerrit.fd.io/r/#/c/12086/>
> 
> 
> 
> On Apr 24, 2018, at 9:23 AM, Radu Nicolau <radu.nico...@intel.com 
> <mailto:radu.nico...@intel.com>> wrote:
>
> Hello all,
>
> We’re seeing a weird issue, that is a segfault that looks to be caused by a 
> movaps instruction that is trying to access an address that is not 16 byte 
> aligned.
> The call originates from a vec_validate_init_empty_aligned that has the 
> argument aligned to 16 bytes.
> I have seen something like this in the past, we couldn’t find a root cause 
> and considered it a GCC bug (version 5 then), but now it pops up again on 
> version 7, so probably it isn’t.
> Any idea? A snapshot of the gdb screen below.
>
> gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
> https://postimg.cc/image/9jy4p38at/ <https://postimg.cc/image/9jy4p38at/>
>
> thanks and I will appreciate any help,
> Radu
>
>
>

Re: [vpp-dev] segfault due to movaps unaligned access

2018-04-26 Thread Radu Nicolau 
Hi,

If elements of the vector are 54 bytes and first is aligned, accessing the 
second one should not generate instructions that assume it is aligned as well. 
So based on that and your description, this is a gcc bug, right? The issue does 
not occur on gcc 6.3, 6.4 but occurs on 7.2.0 and 7.3.1 (and I’ve seen it a 
while ago on 5.x).

Regards,
Radu
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Florin Coras
Sent: Thursday, April 26, 2018 4:13 PM
To: Nicolau, Radu <radu.nico...@intel.com>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] segfault due to movaps unaligned access

Hi Radu,

The problem was that the vector was expected to have cacheline size aligned 
data, but the elements in the vector were not a multiple of a cache line (size 
was 54). As a result, the first element was aligned and the rest were not. The 
vector infra just allocates an aligned chunk of memory, it does not guarantee 
anything with respect to individual element placement.

Hope it helps!

Cheers,
Florin


On Apr 26, 2018, at 1:53 AM, Nicolau, Radu 
<radu.nico...@intel.com<mailto:radu.nico...@intel.com>> wrote:

Hi Florin,

Thanks! The patch fixes the issue.
Any idea why is it happening?

Regards,
Radu

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
[mailto:vpp-dev@lists.fd.io] On Behalf Of Florin Coras
Sent: Tuesday, April 24, 2018 11:25 PM
To: Nicolau, Radu <radu.nico...@intel.com<mailto:radu.nico...@intel.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] segfault due to movaps unaligned access

Hi Radu,

Making the crypto_worker_main_t a full cache line in size (see patch [1]) seems 
to solve the issue. Could you confirm?

Florin

[1] https://gerrit.fd.io/r/#/c/12086/



On Apr 24, 2018, at 9:23 AM, Radu Nicolau 
<radu.nico...@intel.com<mailto:radu.nico...@intel.com>> wrote:

Hello all,

We’re seeing a weird issue, that is a segfault that looks to be caused by a 
movaps instruction that is trying to access an address that is not 16 byte 
aligned.
The call originates from a vec_validate_init_empty_aligned that has the 
argument aligned to 16 bytes.
I have seen something like this in the past, we couldn’t find a root cause and 
considered it a GCC bug (version 5 then), but now it pops up again on version 
7, so probably it isn’t.
Any idea? A snapshot of the gdb screen below.

gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
https://postimg.cc/image/9jy4p38at/

thanks and I will appreciate any help,
Radu

Re: [vpp-dev] segfault due to movaps unaligned access

2018-04-26 Thread Florin Coras 
Hi Radu, 

The problem was that the vector was expected to have cacheline size aligned 
data, but the elements in the vector were not a multiple of a cache line (size 
was 54). As a result, the first element was aligned and the rest were not. The 
vector infra just allocates an aligned chunk of memory, it does not guarantee 
anything with respect to individual element placement.

Hope it helps!

Cheers,
Florin

> On Apr 26, 2018, at 1:53 AM, Nicolau, Radu <radu.nico...@intel.com> wrote:
> 
> Hi Florin,
>
> Thanks! The patch fixes the issue.
> Any idea why is it happening?
>
> Regards,
> Radu
>   <>
>  <>From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
> [mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>] On Behalf Of Florin 
> Coras
> Sent: Tuesday, April 24, 2018 11:25 PM
> To: Nicolau, Radu <radu.nico...@intel.com <mailto:radu.nico...@intel.com>>
> Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] segfault due to movaps unaligned access
>
> Hi Radu, 
>
> Making the crypto_worker_main_t a full cache line in size (see patch [1]) 
> seems to solve the issue. Could you confirm?
>
> Florin
>
> [1] https://gerrit.fd.io/r/#/c/12086/ <https://gerrit.fd.io/r/#/c/12086/>
> 
> 
> On Apr 24, 2018, at 9:23 AM, Radu Nicolau <radu.nico...@intel.com 
> <mailto:radu.nico...@intel.com>> wrote:
>
> Hello all,
>
> We’re seeing a weird issue, that is a segfault that looks to be caused by a 
> movaps instruction that is trying to access an address that is not 16 byte 
> aligned.
> The call originates from a vec_validate_init_empty_aligned that has the 
> argument aligned to 16 bytes.
> I have seen something like this in the past, we couldn’t find a root cause 
> and considered it a GCC bug (version 5 then), but now it pops up again on 
> version 7, so probably it isn’t.
> Any idea? A snapshot of the gdb screen below.
>
> gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
> https://postimg.cc/image/9jy4p38at/ <https://postimg.cc/image/9jy4p38at/>
>
> thanks and I will appreciate any help,
> Radu
>
>

Re: [vpp-dev] segfault due to movaps unaligned access

2018-04-26 Thread Radu Nicolau 
Hi Florin,

Thanks! The patch fixes the issue.
Any idea why is it happening?

Regards,
Radu

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Florin Coras
Sent: Tuesday, April 24, 2018 11:25 PM
To: Nicolau, Radu <radu.nico...@intel.com>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] segfault due to movaps unaligned access

Hi Radu,

Making the crypto_worker_main_t a full cache line in size (see patch [1]) seems 
to solve the issue. Could you confirm?

Florin

[1] https://gerrit.fd.io/r/#/c/12086/


On Apr 24, 2018, at 9:23 AM, Radu Nicolau 
<radu.nico...@intel.com<mailto:radu.nico...@intel.com>> wrote:

Hello all,

We’re seeing a weird issue, that is a segfault that looks to be caused by a 
movaps instruction that is trying to access an address that is not 16 byte 
aligned.
The call originates from a vec_validate_init_empty_aligned that has the 
argument aligned to 16 bytes.
I have seen something like this in the past, we couldn’t find a root cause and 
considered it a GCC bug (version 5 then), but now it pops up again on version 
7, so probably it isn’t.
Any idea? A snapshot of the gdb screen below.

gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
https://postimg.cc/image/9jy4p38at/

thanks and I will appreciate any help,
Radu

Re: [vpp-dev] segfault due to movaps unaligned access

2018-04-24 Thread Florin Coras 
Hi Radu, 

Making the crypto_worker_main_t a full cache line in size (see patch [1]) seems 
to solve the issue. Could you confirm?

Florin

[1] https://gerrit.fd.io/r/#/c/12086/ 

> On Apr 24, 2018, at 9:23 AM, Radu Nicolau  wrote:
> 
> Hello all,
>
> We’re seeing a weird issue, that is a segfault that looks to be caused by a 
> movaps instruction that is trying to access an address that is not 16 byte 
> aligned.
> The call originates from a vec_validate_init_empty_aligned that has the 
> argument aligned to 16 bytes.
> I have seen something like this in the past, we couldn’t find a root cause 
> and considered it a GCC bug (version 5 then), but now it pops up again on 
> version 7, so probably it isn’t.
> Any idea? A snapshot of the gdb screen below.
>
> gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
> https://postimg.cc/image/9jy4p38at/ 
>
> thanks and I will appreciate any help,
> Radu
>

[vpp-dev] segfault due to movaps unaligned access

2018-04-24 Thread Radu Nicolau 
Hello all,

We're seeing a weird issue, that is a segfault that looks to be caused by a 
movaps instruction that is trying to access an address that is not 16 byte 
aligned.
The call originates from a vec_validate_init_empty_aligned that has the 
argument aligned to 16 bytes.
I have seen something like this in the past, we couldn't find a root cause and 
considered it a GCC bug (version 5 then), but now it pops up again on version 
7, so probably it isn't.
Any idea? A snapshot of the gdb screen below.

gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
https://postimg.cc/image/9jy4p38at/

thanks and I will appreciate any help,
Radu