lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 19 Feb 2016 15:59:59 +0300
From:	Yury Norov <ynorov@...iumnetworks.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	<linux-arm-kernel@...ts.infradead.org>, <pinskia@...il.com>,
	<Prasun.Kapoor@...iumnetworks.com>, <catalin.marinas@....com>,
	<broonie@...nel.org>, <heiko.carstens@...ibm.com>,
	<linux-kernel@...r.kernel.org>, <agraf@...e.de>,
	<Nathan_Lynch@...tor.com>, <klimov.linux@...il.com>,
	"Zhangjian (Bamvor)" <bamvor.zhangjian@...wei.com>,
	<schwab@...e.de>, <schwidefsky@...ibm.com>,
	<jan.dakinevich@...il.com>, <joseph@...esourcery.com>,
	<christoph.muellner@...obroma-systems.com>
Subject: Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64

On Fri, Feb 19, 2016 at 09:23:35AM +0100, Arnd Bergmann wrote:
> On Friday 19 February 2016 01:35:06 Yury Norov wrote:
> > 
> > Hi Bamvor, everybody,
> > 
> > I have new glibc that follows new ABI:
> > https://github.com/norov/glibc/tree/new-api
> 
> Ah, very good!
> 
> > It's very draft and dirty, but you can try it with RFC5.
> > My fail list for ltplite looks like this:
> > pipeio_4                       FAIL       11   
> > abort01                        FAIL       2    
> > clone02                        FAIL       4    
> > kill10                         FAIL       2    
> > kill11                         FAIL       2    
> > lstat01A                       FAIL       1    
> > lstat02                        FAIL       1    
> > mmap16                         FAIL       6    
> > nanosleep03                    FAIL       1    
> > nftw01                         FAIL       1    
> > nftw6401                       FAIL       1    
> > open12                         FAIL       2    
> > pathconf01                     FAIL       1    
> > pipe07                         FAIL       2    
> > profil01                       FAIL       11   
> > readdir01                      FAIL       1    
> > readlink01A                    FAIL       1    
> > rename11                       FAIL       2    
> > rmdir02                        FAIL       2    
> > sigaltstack01                  FAIL       1    
> > sigaltstack02                  FAIL       1    
> > stat03                         FAIL       1    
> > stat04                         FAIL       1    
> > stat06                         FAIL       1    
> > umount2_01                     FAIL       2    
> > umount2_02                     FAIL       2    
> > umount2_03                     FAIL       2    
> > utime06                        FAIL       2    
> > writev01                       FAIL       1    
> > mtest06                        FAIL       11   
> > rwtest01                       FAIL       2    
> > rwtest02                       FAIL       2    
> > rwtest03                       FAIL       2    
> > rwtest04                       FAIL       2    
> > rwtest05                       FAIL       2
> 
> I have no idea whether this is good news or bad news ;-)
> 
> In https://github.com/norov/glibc/commit/351b8728fdb365bd4852ac113601ddf38153fdfc
> I see that you are passing __IPC_64, I thought we had already resolved
> that in the kernel. We might need to go back to this.
> 

I'm still on 4.4 kernel. So I need it. I'll drop __IPC_64 if unneeded on
rebase. Usually I rebase on rc5 or rc6.

> In https://github.com/norov/glibc/commit/5d4290435e428267171ece871539b76e1d079d11
> you are defining a struct __kernel_stat64 in the glibc. Is this the expected
> way to do it? I would have thought you'd get the definition from the kernel
> headers.
>  
> 	Arnd
> 

Almost all ports define its own struct kernel_stat / kernel_stat64.
in "kernel_header.h" See mips, spark, alpha, i386... Some also define
function xstat_conv or similar. With all that defined, it's expected
that one of generic xstat wrappers will work properly. I tried all,
and noone got working, so I wrote this hack to make it work somehow. 


> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ