On Tue, Jul 2, 2013 at 9:39 AM, Yann Droneaud wrote:
> static long sw_sync_ioctl_create_fence(struct sw_sync_timeline *obj,
>unsigned long arg)
> {
> - int fd = get_unused_fd();
> + int fd = get_unused_fd_flags(0);
I think we should use O_CLOE
On Tue, Jul 2, 2013 at 9:39 AM, Yann Droneaud wrote:
> static long sync_fence_ioctl_merge(struct sync_fence *fence, unsigned long
> arg)
> {
> - int fd = get_unused_fd();
> + int fd = get_unused_fd_flags(0);
I think we should use O_CLOEXEC here. Colin and I can't think of any
case
On Fri, Mar 1, 2013 at 12:21 AM, Erik Gilling wrote:
> On Thu, Feb 28, 2013 at 7:59 PM, John Stultz wrote:
>> Given its the sync driver, its most obvious choice, but I agree its likely
>> to collide with filesystem related or other sync_ named functions that don't
>&g
On Fri, Mar 1, 2013 at 5:55 AM, Greg KH wrote:
> On Fri, Mar 01, 2013 at 12:21:24AM -0800, Erik Gilling wrote:
>> As John pointed out, the exynos and msm display and code uses them. I
>> know nvidia is working on adding suport to their tegra tree. My knee
>> jerk reaction
On Thu, Feb 28, 2013 at 5:59 PM, Greg KH wrote:
> On Thu, Feb 28, 2013 at 04:42:56PM -0800, John Stultz wrote:
>> Erik also provided a nice background on the patch set in his
>> reply yesterday, which I'll quote here:
>
> Mind if I put that in the 1/30 changelog body for future people to see?
Ple
On Thu, Feb 28, 2013 at 7:59 PM, John Stultz wrote:
>>> +EXPORT_SYMBOL(sync_timeline_create);
>>
>> As these are now global, should they be a bit more "specific"? "sync_"
>> seems pretty broad.
>
>
> Given its the sync driver, its most obvious choice, but I agree its likely
> to collide with file
On Wed, Feb 27, 2013 at 6:14 PM, John Stultz wrote:
> Also note: I've done this so far without any feedback from the Android devs
> (despite my reaching out to Erik a few times recently), so if they object to
> pushing it to staging, in deference to it being their code I'll back off,
> even though
7 matches
Mail list logo
