linux-kernel - Aw: Re: [PATCH 1/1] staging : android : sync : get_unused

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]

Message-ID: <trinity-ff6d6a3f-e1a7-4d9b-a199-3fd66138f758-1412025565926@3capp-gmx-bs36>
Date:	Mon, 29 Sep 2014 23:19:26 +0200
From:	"Heinrich Schuchardt" <xypron.glpk@....de>
To:	"Yann Droneaud" <ydroneaud@...eya.com>
Cc:	"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
	"Colin Cross" <ccross@...roid.com>,
	"John Stultz" <john.stultz@...aro.org>,
	"Daniel Vetter" <daniel@...ll.ch>,
	"Sumit Semwal" <sumit.semwal@...aro.org>,
	"Masanari Iida" <standby24x7@...il.com>,
	"Daeseok Youn" <daeseok.youn@...il.com>,
	"Maarten Lankhorst" <maarten.lankhorst@...onical.com>,
	devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
	"Yann Droneaud" <ydroneaud@...eya.com>
Subject: Aw: Re: [PATCH 1/1] staging : android : sync : get_unused_fd


> Gesendet: Montag, 29. September 2014 um 20:03 Uhr
> Von: "Yann Droneaud" <ydroneaud@...eya.com>
> An: "Heinrich Schuchardt" <xypron.glpk@....de>
> Cc: "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>, "Colin Cross" <ccross@...roid.com>, "John Stultz" <john.stultz@...aro.org>, "Daniel Vetter" <daniel@...ll.ch>, "Sumit Semwal" <sumit.semwal@...aro.org>, "Masanari Iida" <standby24x7@...il.com>, "Daeseok Youn" <daeseok.youn@...il.com>, "Maarten Lankhorst" <maarten.lankhorst@...onical.com>, devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org, "Yann Droneaud" <ydroneaud@...eya.com>
> Betreff: Re: [PATCH 1/1] staging : android : sync : get_unused_fd
>
> Hi,
> 
> Le samedi 27 septembre 2014 à 10:52 +0200, Heinrich Schuchardt a écrit :
> > sync.h recommends to use get_unused_fd which does not set
> > O_CLOEXEC while the rest of the android tree uses
> > get_unused_fd_flags and sets O_CLOEXEC.
> > 
> > The patch adjust the comment.
> > 
> 
> I'd like to add this patch to my patchset which try to remove
> get_unused_fd() in favor of get_unused_fd_flags():
> 
> http://lkml.kernel.org/r/cover.1411562410.git.ydroneaud@opteya.com
> 
> But having O_CLOEXEC is welcome but not strictly needed,
> so I think the patch should be reworked to not require O_CLOEXEC.

All calls to get_unused_fd_flags() in directory drivers/staging/android
use O_CLOEXEC. That is why I guess it is correct to put it into the
sync.h comment too.

Your patch set inspired me to look for further usages of get_unused_fd().
But I think the patch below is valid even if get_unused_fd() should not
be removed from the kernel.

Best regards

Heinrich 

> 
> > Signed-off-by: Heinrich Schuchardt <xypron.glpk@....de>
> > ---
> >  drivers/staging/android/sync.h | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
> > index 66b0f43..a21b79f 100644
> > --- a/drivers/staging/android/sync.h
> > +++ b/drivers/staging/android/sync.h
> > @@ -293,7 +293,8 @@ void sync_fence_put(struct sync_fence *fence);
> >   * @fence:	fence to install
> >   * @fd:		file descriptor in which to install the fence
> >   *
> > - * Installs @fence into @fd.  @fd's should be acquired through get_unused_fd().
> > + * Installs @fence into @fd.  @fd's should be acquired through
> > + * get_unused_fd_flags(O_CLOEXEC).
> 
> I think it will be better to have something like:
> 
>     get_unused_fd_flags(flags), with flags either provided by userspace
>     or set to O_CLOEXEC.
> 
> 
> >   */
> >  void sync_fence_install(struct sync_fence *fence, int fd);
> >  
> 
> Regards.
> 
> -- 
> Yann Droneaud
> OPTEYA
> 
> 
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/