netdev - Re: [PATCH 2/6] move _body_io_syscall to the generic syscall.h

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 05 Jan 2018 17:49:59 -0500
From:   Jeff Moyer <jmoyer@...hat.com>
To:     Benjamin LaHaise <ben@...munityfibre.ca>
Cc:     Christoph Hellwig <hch@....de>, linux-aio@...ck.org,
        Avi Kivity <avi@...lladb.com>, linux-fsdevel@...r.kernel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/6] move _body_io_syscall to the generic syscall.h

Hi, Ben,

Thanks for the quick reply.

Benjamin LaHaise <ben@...munityfibre.ca> writes:

> On Fri, Jan 05, 2018 at 11:25:17AM -0500, Jeff Moyer wrote:
>> Christoph Hellwig <hch@....de> writes:
>> 
>> > This way it can be used for the fallback 6-argument version on
>> > all architectures.
>> >
>> > Signed-off-by: Christoph Hellwig <hch@....de>
>> 
>> This is a strange way to do things.  However, I was never really sold on
>> libaio having to implement its own system call wrappers.  That decision
>> definitely resulted in some maintenance overhead.
>> 
>> Ben, what was your reasoning for not just using syscall?
>
> The main issue was that glibc's pthreads implementation really sucked back
> during initial development and there was a use-case for having the io_XXX
> functions usable directly from clone()ed threads that didn't have all the
> glibc pthread state setup for per-cpu areas to handle per-thread errno.
> That made sense back then, but is rather silly today.

Thanks for the background info.

> Technically, I'm not sure the generic syscall wrapper is safe to use.  The
> io_XXX arch wrappers don't modify errno, while it appears the generic one
> does.  That said, nobody has ever noticed...

Good point.  Common architectures don't use the generic syscall wrapper,
so I'm not sure we can conclude that it won't break anything.  At the
same time, I'm not sure I want to write and test the io_syscall6
assembly for all of the supported arches.  I could save and restore
errno.  That sounds ugly, but less painful than the other options.

Does anyone have any strong preferences?

-Jeff