In addition to Fabio's comment. I believe whole original code is just
nonsense. I've merged these two mappings into one and it looks like
functionality is kept (patch Remove unnecessary mmap in cpg).
Roy,
do you think you can try that patch and tell me, if it solves also
problem you are hitting? (it should)
Regards,
Honza
Fabio M. Di Nitto napsal(a):
> On 5/19/2013 3:00 AM, rongqing.li@xxxxxxxxxxxxx wrote:
>> From: "Roy.Li" <rongqing.li@xxxxxxxxxxxxx>
>>
>> On a number of arches, any fixed and shared mmap() mapping address must be
>> aligned to 16k, or MIPS cpu askes that the address must be aligned to not
>> violate cache aliasing constraints.
>>
>> If we create a shared memory like below:
>>
>> addr_orig = mmap (NULL, bytes, PROT_NONE,
>> MAP_ANONYMOUS| MAP_PRIVATE, -1, 0);
>>
>> addr = mmap (addr_orig, bytes, PROT_READ | PROT_WRITE,
>> MAP_FIXED | MAP_SHARED, fd, 0);
>>
>> If the first mmap() upper is not shared then the first mmap() will succeed
>> because these restrictions do not apply to private mappings. The second
>> mmap() wants a shared memory mapping but the address returned by the first
>> one is only page-aligned and not aligned to 16k, or violate cache aliasing
>> constraints on MIPS cpu, will lead to second mmap failure.
>>
>> Signed-off-by: Roy.Li <rongqing.li@xxxxxxxxxxxxx>
>> ---
>> configure.ac | 25 +++++++++++++++++++++++++
>> exec/cpg.c | 13 +++++++++----
>> lib/cpg.c | 10 ++++++++--
>> 3 files changed, 42 insertions(+), 6 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 523d2cf..d3a9c25 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -647,6 +647,31 @@ else
>> AC_SUBST(VERSCRIPT_LDFLAGS, [""])
>> fi
>>
>> +arch_force_shmlba=no
>> +AC_MSG_CHECKING([for architecture in ${host_cpu}])
>> +case $host_cpu in
>> + sparc*)
>> + AC_MSG_RESULT([${host_cpu}])
>> + arch_force_shmlba=yes
>> + ;;
>> + arm*)
>> + AC_MSG_RESULT([${host_cpu}])
>> + arch_force_shmlba=yes
>> + ;;
>> + mips*)
>> + AC_MSG_RESULT([${host_cpu}])
>> + arch_force_shmlba=yes
>> + ;;
>> + *)
>> + AC_MSG_RESULT([${host_cpu}])
>> + ;;
>> +esac
>
> Hi,
>
> this part of the patch is not ok. We spent a decent amount of time
> dropping all hard coded architecture bits from configure.ac because they
> are not portable.
>
> You will need to find a more generic test to verify if shmlba is
> necessary on a certain architecture/OS. Remember that we do support more
> than just Linux for upstream.
>
> Cheers
> Fabio
>
> _______________________________________________
> discuss mailing list
> discuss@xxxxxxxxxxxx
> http://lists.corosync.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
