> On Sep 17, 2019, at 9:08 PM, Takashi YAMAMOTO wrote:
>
> but it would be a super expensive operation for the majority of filesystems,
> right?
But it will most likely be extremely rare, so *shrug*?
-- thorpej
2019年9月16日(月) 3:43 Jason Thorpe :
>
>
> > On Sep 15, 2019, at 11:03 AM, Christos Zoulas
> wrote:
> >
> > I think it is quite reliable because all the file descriptors would be
> recently
> > opened and therefore be in the cache. One would need to DoS the cache
> > cause eviction. If that turns
2019年9月15日(日) 9:06 Christos Zoulas :
> In article <2f29ca9a-0ae1-48d3-b3f4-1556912d4...@me.com>,
> Jason Thorpe wrote:
> >
> >
> >> On Sep 14, 2019, at 2:52 PM, Kamil Rytarowski wrote:
> >>
> >> On 14.09.2019 23:34, Christos Zoulas wrote:
> >>> Comments?
> >>>
> >>
> >> Question. How does it
In article ,
Jason Thorpe wrote:
>
>
>> On Sep 17, 2019, at 1:39 PM, Christos Zoulas wrote:
>>
>> I am not sure though if we should change the current behavior just to make
>> F_GETPATH better? Opinions?
>
>It seems completely logical that we SHOULD fix this.
I concur. Specially because some
> On Sep 17, 2019, at 1:39 PM, Christos Zoulas wrote:
>
> I am not sure though if we should change the current behavior just to make
> F_GETPATH better? Opinions?
It seems completely logical that we SHOULD fix this.
-- thorpej
In article <4e7e49e0-9c71-1f21-22fc-8ed54590a...@gmx.com>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 15.09.2019 20:03, Christos Zoulas wrote:
>> I think it is quite reliable because all the file descriptors would be
>recently
>> opened and therefore be in the cache. One would need
On 9/15/19, Jason Thorpe wrote:
>
>
>> On Sep 15, 2019, at 11:03 AM, Christos Zoulas
>> wrote:
>>
>> I think it is quite reliable because all the file descriptors would be
>> recently
>> opened and therefore be in the cache. One would need to DoS the cache
>> cause eviction. If that turns out
On 15.09.2019 20:03, Christos Zoulas wrote:
> I think it is quite reliable because all the file descriptors would be
> recently
> opened and therefore be in the cache. One would need to DoS the cache
> cause eviction. If that turns out to be false, we can make the namecache
> reliable, or
> On Sep 15, 2019, at 1:17 PM, Mouse wrote:
>
> [top-posting damage repaired manually]
>>> If you can get a file desriptor to a symlink, it will work; I don't
>>> think that we have a way to do this now.
>> FYI - XNU has O_SYMLINK for this.
>
> What operations does it support on fds open
>>> If you can get a file desriptor to a symlink, [...]
> There should be no way to get a fd for a symlink; if you can,
> something bad has happened.
At present, perhaps.
> Because of the way short symlinks are handled in ffs, I wouldn't be
> surprised if managing to get one let you corrupt the
[top-posting damage repaired manually]
>> If you can get a file desriptor to a symlink, it will work; I don't
>> think that we have a way to do this now.
> FYI - XNU has O_SYMLINK for this.
What operations does it support on fds open onto symlinks?
/~\ The ASCII Mouse
On Sun, Sep 15, 2019 at 09:53:41AM -0700, Jason Thorpe wrote:
> FYI - XNU has O_SYMLINK for this. Not saying we should necessarily add it
> to NetBSD, just noting the precedent.
>
> -- thorpej
> Sent from my iPhone.
>
> > On Sep 14, 2019, at 5:06 PM, Christos Zoulas wrote:
> >
> >
> On Sep 15, 2019, at 11:03 AM, Christos Zoulas wrote:
>
> I think it is quite reliable because all the file descriptors would be
> recently
> opened and therefore be in the cache. One would need to DoS the cache
> cause eviction. If that turns out to be false, we can make the namecache
>
On 9/15/19, Mateusz Guzik wrote:
> On 9/14/19, Christos Zoulas wrote:
>>
>> Comments?
>>
>> +error = vnode_to_path(kpath, MAXPATHLEN, fp->f_vnode, l, l->l_proc);
>
> What motivates this change?
>
> I think it is a little problematic in that namecache resolution is not
> guaranteed to work.
On 9/14/19, Christos Zoulas wrote:
>
> Comments?
>
> + error = vnode_to_path(kpath, MAXPATHLEN, fp->f_vnode, l, l->l_proc);
What motivates this change?
I think it is a little problematic in that namecache resolution is not
guaranteed to work. If the consumer does not check for failure or
> On Sep 15, 2019, at 12:43 PM, Mateusz Guzik wrote:
>
> On 9/14/19, Christos Zoulas wrote:
>>
>> Comments?
>>
>> +error = vnode_to_path(kpath, MAXPATHLEN, fp->f_vnode, l, l->l_proc);
>
> What motivates this change?
>
> I think it is a little problematic in that namecache resolution
FYI - XNU has O_SYMLINK for this. Not saying we should necessarily add it to
NetBSD, just noting the precedent.
-- thorpej
Sent from my iPhone.
> On Sep 14, 2019, at 5:06 PM, Christos Zoulas wrote:
>
> If you can get a file desriptor to a symlink, it will work; I don't think
> that we have a
In article <2f29ca9a-0ae1-48d3-b3f4-1556912d4...@me.com>,
Jason Thorpe wrote:
>
>
>> On Sep 14, 2019, at 2:52 PM, Kamil Rytarowski wrote:
>>
>> On 14.09.2019 23:34, Christos Zoulas wrote:
>>> Comments?
>>>
>>
>> Question. How does it handle symbolic/hardlinks?
>
>Symbolic links, of course,
> On Sep 14, 2019, at 2:52 PM, Kamil Rytarowski wrote:
>
> On 14.09.2019 23:34, Christos Zoulas wrote:
>> Comments?
>>
>
> Question. How does it handle symbolic/hardlinks?
Symbolic links, of course, are simply continuations of the lookup, so there's
"nothing to see here" with a symbolic
On 14.09.2019 23:34, Christos Zoulas wrote:
> Comments?
>
Question. How does it handle symbolic/hardlinks?
> christos
>
>
> Index: kern/sys_descrip.c
> ===
> RCS file: /cvsroot/src/sys/kern/sys_descrip.c,v
> retrieving revision
Comments?
christos
Index: kern/sys_descrip.c
===
RCS file: /cvsroot/src/sys/kern/sys_descrip.c,v
retrieving revision 1.34
diff -u -p -u -r1.34 sys_descrip.c
--- kern/sys_descrip.c 26 Aug 2019 10:19:08 - 1.34
+++
21 matches
Mail list logo
