Re: Linux 2.6.36-rc7

Re: Linux 2.6.36-rc7

[Andreas Gruenbacher]

On Thursday 07 October 2010 19:49:28 Eric Paris wrote:
> The safest thing would probably be to punt the syscalls to 2.6.37.
> Which is sad since I know a number of people are already working against
> them, but maybe that proves it's the best approach?

I agree with removing the syscalls from 2.6.36 because of the following 
reasons:

 * Reviewers have complained that the feature was not ready to be merged, yet.

 * At least some of the criticism did not get addressed (neither discussed nor
   fixed).

 * Some weaknesses in the interface design were only identified and fixed late
   in the -rc phase, changing the ABI.  There may be more issues, like the
   priority discussion.  This might leave us with a broken ABI we would need
   to support forever.

   (Making fanotify fit for HSM hasn't been thought through at all AFAIK but
   fanotify has legitimate use cases apart from HSM, so I don't necessarily
   consider this a blocker.)

 * The code has shown to contain the kinds of bugs which show that it was not
   tested very well before merging.

Thanks,
Andreas

Re: Linux 2.6.36-rc7

[David Daney]

On 10/08/2010 05:06 AM, Andreas Gruenbacher wrote:
> On Thursday 07 October 2010 19:49:28 Eric Paris wrote:
>> The safest thing would probably be to punt the syscalls to 2.6.37.
>> Which is sad since I know a number of people are already working against
>> them, but maybe that proves it's the best approach?
>
> I agree with removing the syscalls from 2.6.36 because of the following
> reasons:

How would the mechanics of this be achieved?

Is it enough to just unconditionally return -ENOSYS from the sys_*() 
functions?  Or should all the patches be reverted?

David Daney

Re: Linux 2.6.36-rc7

[Andreas Gruenbacher]

On Friday 08 October 2010 18:33:55 David Daney wrote:
> On 10/08/2010 05:06 AM, Andreas Gruenbacher wrote:
> > On Thursday 07 October 2010 19:49:28 Eric Paris wrote:
> >> The safest thing would probably be to punt the syscalls to 2.6.37.
> >> Which is sad since I know a number of people are already working against
> >> them, but maybe that proves it's the best approach?
> >
> > I agree with removing the syscalls from 2.6.36 because of the following
> > reasons:
> 
> How would the mechanics of this be achieved?
> 
> Is it enough to just unconditionally return -ENOSYS from the sys_*() 
> functions?  Or should all the patches be reverted?

Whatever works I guess ... they would get reactivated pretty soon, anyway.

Andreas

Re: Linux 2.6.36-rc7

[H. Peter Anvin]

On 10/08/2010 02:50 PM, Andreas Gruenbacher wrote:
> On Friday 08 October 2010 18:33:55 David Daney wrote:
>> On 10/08/2010 05:06 AM, Andreas Gruenbacher wrote:
>>> On Thursday 07 October 2010 19:49:28 Eric Paris wrote:
>>>> The safest thing would probably be to punt the syscalls to 2.6.37.
>>>> Which is sad since I know a number of people are already working against
>>>> them, but maybe that proves it's the best approach?
>>>
>>> I agree with removing the syscalls from 2.6.36 because of the following
>>> reasons:
>>
>> How would the mechanics of this be achieved?
>>
>> Is it enough to just unconditionally return -ENOSYS from the sys_*() 
>> functions?  Or should all the patches be reverted?
> 
> Whatever works I guess ... they would get reactivated pretty soon, anyway.
> 

Returning -ENOSYS should be sufficient (that's what a non-system-call
does); it would *also* be good to block any headers from getting
exported to userspace so people don't end up with compiling against the
wrong version of the kernel headers and then wonder why their code
doesn't work in the future.

	-hpa

fanotify: disable fanotify syscalls

[Eric Paris]

This patch disables the fanotify syscalls by just not building them and
letting the cond_syscall() statements in kernel/sys_ni.c redirect them
to sys_ni_syscall().

It was pointed out by Tvrtko Ursulin that the fanotify interface did not
include an explicit prioritization between groups.  This is necessary
for fanotify to be usable for hierarchical storage management software,
as they must get first access to the file, before inotify-like notifiers
see the file.

This feature can be added in an ABI compatible way in the next release
(by using a number of bits in the flags field to carry the info) but it
was suggested by Alan that maybe we should just hold off and do it in
the next cycle, likely with an (new) explicit argument to the syscall.
I don't like this approach best as I know people are already starting to
use the current interface, but Alan is all wise and noone on list backed
me up with just using what we have.  I feel this is needlessly ripping
the rug out from under people at the last minute, but if others think it
needs to be a new argument it might be the best way forward.

Three choices:
Go with what we got (and implement the new feature next cycle).  Add a
new field right now (and implement the new feature next cycle).  Wait
till next cycle to release the ABI (and implement the new feature next
cycle).  This is number 3.

Signed-off-by: Eric Paris <eparis@redhat.com>

---

 fs/notify/Kconfig    |    2 +-
 include/linux/Kbuild |    1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/notify/Kconfig b/fs/notify/Kconfig
index 22c629e..b388443 100644
--- a/fs/notify/Kconfig
+++ b/fs/notify/Kconfig
@@ -3,4 +3,4 @@ config FSNOTIFY
 
 source "fs/notify/dnotify/Kconfig"
 source "fs/notify/inotify/Kconfig"
-source "fs/notify/fanotify/Kconfig"
+#source "fs/notify/fanotify/Kconfig"
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index 626b629..4e8ea8c 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -118,7 +118,6 @@ header-y += eventpoll.h
 header-y += ext2_fs.h
 header-y += fadvise.h
 header-y += falloc.h
-header-y += fanotify.h
 header-y += fb.h
 header-y += fcntl.h
 header-y += fd.h

Re: Linux 2.6.36-rc7

[Eric Paris]

On Fri, 2010-10-08 at 14:06 +0200, Andreas Gruenbacher wrote:
> On Thursday 07 October 2010 19:49:28 Eric Paris wrote:
> > The safest thing would probably be to punt the syscalls to 2.6.37.
> > Which is sad since I know a number of people are already working against
> > them, but maybe that proves it's the best approach?
> 
> I agree with removing the syscalls from 2.6.36 because of the following 
> reasons:

I disagree with all of your reasons and have argued my position on this
topic repeatedly and don't see the need to refute your claims again.

However, THIS is potentially a real ABI problem and something which
deals with the interface.  Alan seemed to lean towards pulling the
syscalls.  It is relatively easily solved without changing the interface
or breaking userspace in 2.6.37.  We use some set of the flags bits as a
priority (we only use 2 of the 32 bits today so we have plenty) and
order groups with highest priority first, 0 priority last, and 2+ groups
with the same priority have unpredictable ordering.  I'd then call
priorities other than 0 a 2.6.37 feature.  If we do it in flags I think
that leaves us with say 8 bits and thus 255 priorities.  Maybe people
want more, if so, that's a interface change to add a new argument.

Now if Alan would still like me to pull, if anyone has any other 11th
hour interface problems, or if 255 priorities doesn't seem like enough
to someone I am wondering what the best way to unhook is.  Just make the
functions return -ENOSYS as the first line or actually troll through all
of the arches and explicily unhook and rehook to sys_ni_syscall?  I
started on the latter, but it seems to be a rather large patch at this
point...

-Eric

------

I said I wouldn't refute your claims but I can't help myself on one
account which I think might mislead people.

 * Some weaknesses in the interface design were only identified and fixed late
   in the -rc phase, changing the ABI.  There may be more issues, like the
   priority discussion.  This might leave us with a broken ABI we would need
   to support forever.

Between rc2 and rc3 we switched the order and size of a couple of fields
to help alignment, it did break ABI, but it wasn't an interface failing.
See: 0fb85621df4f.  It also lead to an interesting idea about a new type
for linux/types.h which both fanotify and the networking could make use
of (but isn't picked up, I'm not sure we know who is in charge of
types.h)

I concede the interface may in fact not be perfect for every user.  I
have ask for ideas and feedback on proposals for literally (not
figuratively) years.  It has gone through many iterations.  The
interface has been in Linus's kernel for some months and I know of
numerous people who are starting to code to it and haven't (until now)
found interface failings.  We can talk about how problems might be out
there but if they haven't been found after all this time I doubt just
waiting longer is going to change anything.

Re: Linux 2.6.36-rc7

[Andreas Gruenbacher]

On Friday 08 October 2010 18:38:28 Eric Paris wrote:
> However, THIS is potentially a real ABI problem and something which
> deals with the interface.  Alan seemed to lean towards pulling the
> syscalls. It is relatively easily solved without changing the interface
> or breaking userspace in 2.6.37.  We use some set of the flags bits as a
> priority (we only use 2 of the 32 bits today so we have plenty) and
> order groups with highest priority first, 0 priority last, and 2+ groups
> with the same priority have unpredictable ordering.  I'd then call
> priorities other than 0 a 2.6.37 feature.  If we do it in flags I think
> that leaves us with say 8 bits and thus 255 priorities.

That's a possibility but it seems quite messy for a brand new system call.  
I'd still pull the system call and work out the few remaining quirkses.

Thanks.

> ------
> 
> I said I wouldn't refute your claims but I can't help myself on one
> account which I think might mislead people.
> 
>  * Some weaknesses in the interface design were only identified and fixed
>    late in the -rc phase, changing the ABI.  There may be more issues, like
>    the priority discussion.  This might leave us with a broken ABI we would
>    need to support forever.
> 
> Between rc2 and rc3 we switched the order and size of a couple of fields
> to help alignment, it did break ABI, but it wasn't an interface failing.
> See: 0fb85621df4f.

See, a weakness, not a failure.  What I said.

The main issue that Andreas Schwab has pointed out (and which also lead to 
this commit) was the packing of the structs which leads to inefficient code, 
though.  This hasn't been fixed but it still can be, in a backwards compatible 
way.

Thanks,
Andreas