AX.25 in kernel 2.5 status?

AX.25 in kernel 2.5 status?

[M Taylor]

A while back (a few months ago) a couple of developers/hams (Ralf and others) 
mentioned that work needed to be done in the 2.5 linux kernel due to changes
(I believe relating cli()/sti() plus other things).

Has there been any progress? There appears to be some patches included
in 2.5.37 from Ralf and David Miller. Does include all the changes we 
_need_ to make? (that is for when cli()/sti() and such calls go away)

I guess I am asking what needs to be done before users can "safely" use
2.5.x kernels for amateur radio stuff.

Should the http://sourceforge.net/projects/ax25 Bug tracking, Support
Requests / Patches / Feature Requires be used for the AX.25 (et all)
kernel as well as the userland libraries, tools, and apps?

Oh, and can a non-kernel programmer help? (I'm not familiar with kernel
programming, but I can program, can I be of assistance?)

Thanks,
-ve1mct

Re: AX.25 in kernel 2.5 status?

[Ralf Baechle DO1GRB]

On Thu, Oct 10, 2002 at 03:57:03AM +0100, M Taylor wrote:

> A while back (a few months ago) a couple of developers/hams (Ralf and others) 
> mentioned that work needed to be done in the 2.5 linux kernel due to changes
> (I believe relating cli()/sti() plus other things).
> 
> Has there been any progress? There appears to be some patches included
> in 2.5.37 from Ralf and David Miller. Does include all the changes we 
> _need_ to make? (that is for when cli()/sti() and such calls go away)

Not by far.  The entire locking in the code is a mess.  It just happens
to work if you're nice to the code that is uniprocessor, no preemption
patches, avoid configuring routes etc. while the system is active etc.
Fixing all those omissions takes a while.  And cli/sti was just the peak
of the ice berg.  The SOCKCALL_WRAP wrap stuff will go away for example
and getting away without that require even more auverhaul of the locking
strategy which I'm just working on.

The result will probably be the only multithreaded AX.25, NETROM and ROSE
stacks on the planet.  An attribute of dubious value for a low bandwidth
protocols - but at least the thing will work.

> I guess I am asking what needs to be done before users can "safely" use
> 2.5.x kernels for amateur radio stuff.

2.4 needs the same stuff.  If it's working for you then just because you're
not shaking the code hard enough.

> Should the http://sourceforge.net/projects/ax25 Bug tracking, Support
> Requests / Patches / Feature Requires be used for the AX.25 (et all)
> kernel as well as the userland libraries, tools, and apps?

That project looks rather dead.

Anyway, all the userspace stuff stays usable.  I've been careful to not
change any of the kernel interfaces.

> Oh, and can a non-kernel programmer help? (I'm not familiar with kernel
> programming, but I can program, can I be of assistance?)

I don't have the bandwidth to do that but I think we need some documentation
of the AX.25 / NETROM/ ROSE network interface for programmers.  And all
the userspace stuff is still way too complex for the average "plug and play"
ham ...

  Ralf

Re: AX.25 in kernel 2.5 status?

[Steven Whitehouse]

Hi,

> 
> 
> A while back (a few months ago) a couple of developers/hams (Ralf and others) 
> mentioned that work needed to be done in the 2.5 linux kernel due to changes
> (I believe relating cli()/sti() plus other things).
> 
> Has there been any progress? There appears to be some patches included
> in 2.5.37 from Ralf and David Miller. Does include all the changes we 
> _need_ to make? (that is for when cli()/sti() and such calls go away)
>
The patch I proposed still hasn't made it into mainline yet. I had a
message from Arnaldo Carvalho de Melo recently asking about /proc
changes very much along the lines of the patch I did, so this has
brought it to mind again. I'll do my best to update, test and submit
it shortly providing there are no objections to it,

Steve.

Re: AX.25 in kernel 2.5 status?

[Ralf Baechle DO1GRB]

On Fri, Oct 11, 2002 at 10:49:25AM +0100, Steven Whitehouse wrote:

> > A while back (a few months ago) a couple of developers/hams (Ralf and others) 
> > mentioned that work needed to be done in the 2.5 linux kernel due to changes
> > (I believe relating cli()/sti() plus other things).
> > 
> > Has there been any progress? There appears to be some patches included
> > in 2.5.37 from Ralf and David Miller. Does include all the changes we 
> > _need_ to make? (that is for when cli()/sti() and such calls go away)
> >
> The patch I proposed still hasn't made it into mainline yet. I had a
> message from Arnaldo Carvalho de Melo recently asking about /proc
> changes very much along the lines of the patch I did, so this has
> brought it to mind again. I'll do my best to update, test and submit
> it shortly providing there are no objections to it,

I yesterday published my changes to redo the /proc files for AX.25,
NET/ROM and ROSE with the seq_file stuff.  As usually these changesets
are available at http://linux-ham.bkbits.net/linux-2.5.

73 de DO1GRB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

Re: AX.25 in kernel 2.5 status?

[Steven Whitehouse]

Hi,

[snip]
> 
> I yesterday published my changes to redo the /proc files for AX.25,
> NET/ROM and ROSE with the seq_file stuff.  As usually these changesets
> are available at http://linux-ham.bkbits.net/linux-2.5.
> 
> 73 de DO1GRB op Ralf

It seems you beat me to it :-) though there is one extra thing that still needs
to be fixed in the uid code from my patch where ax25_findbyuid() returns
a pointer to a structure which might disappear at any time. Its only use
is to check permissions at bind time, so I just moved the check under
the lock,

Steve.

Re: AX.25 in kernel 2.5 status?

[Ralf Baechle DO1GRB]

On Fri, Oct 11, 2002 at 02:47:36PM +0100, Steven Whitehouse wrote:

> > I yesterday published my changes to redo the /proc files for AX.25,
> > NET/ROM and ROSE with the seq_file stuff.  As usually these changesets
> > are available at http://linux-ham.bkbits.net/linux-2.5.
> > 
> > 73 de DO1GRB op Ralf
> 
> It seems you beat me to it :-) though there is one extra thing that still needs
> to be fixed in the uid code from my patch where ax25_findbyuid() returns
> a pointer to a structure which might disappear at any time. Its only use
> is to check permissions at bind time, so I just moved the check under
> the lock,

Unfortunately the code is full of such funnies.  Remember as the code is
in 2.5 there are no more locks outside protecting us from our own thread
safety - or rather the lack thereof.  In particular the socket locking
is rather hard to get right.

Another problem we still have - and we're sharing it with other protocols
such ipv4 - is that our proc code is holding a lock for the time the
/proc file is open.  That's not a significant time but it may delay
access, so I've made most of those loads rw locks.  Worst case a buggy
or malicious piece of software might even hold a proc file open for a long
time thereby stalling the functioning of the stack partially or fully.

If you could update your fix I certainly would accept it :)

73 de DO1GRB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

Re: AX.25 in kernel 2.5 status?

[Steven Whitehouse]

Hi,

> 
> On Fri, Oct 11, 2002 at 02:47:36PM +0100, Steven Whitehouse wrote:
> 
> > > I yesterday published my changes to redo the /proc files for AX.25,
> > > NET/ROM and ROSE with the seq_file stuff.  As usually these changesets
> > > are available at http://linux-ham.bkbits.net/linux-2.5.
> > > 
> > > 73 de DO1GRB op Ralf
> > 
> > It seems you beat me to it :-) though there is one extra thing that still needs
> > to be fixed in the uid code from my patch where ax25_findbyuid() returns
> > a pointer to a structure which might disappear at any time. Its only use
> > is to check permissions at bind time, so I just moved the check under
> > the lock,
> 
> Unfortunately the code is full of such funnies.  Remember as the code is
> in 2.5 there are no more locks outside protecting us from our own thread
> safety - or rather the lack thereof.  In particular the socket locking
> is rather hard to get right.
>
Yes I know, I worked on this for DECnet a while back :-) My plan since I am
rather constrained by time was to start at the lower levels of this
and do one small easily testable feature as I get time to work on it
and very slowly work towards the higher layers.
 
> Another problem we still have - and we're sharing it with other protocols
> such ipv4 - is that our proc code is holding a lock for the time the
> /proc file is open.  That's not a significant time but it may delay
> access, so I've made most of those loads rw locks.  Worst case a buggy
> or malicious piece of software might even hold a proc file open for a long
> time thereby stalling the functioning of the stack partially or fully.
> 
Its only during read operations, not the open that the lock is held I
think, but I agree that an rw lock is the best solution here.

> If you could update your fix I certainly would accept it :)
> 
> 73 de DO1GRB op Ralf
>
Ok. I'll do that,

Steve.

Re: AX.25 in kernel 2.5 status?

[Ralf Baechle DO1GRB]

On Fri, Oct 11, 2002 at 03:56:23PM +0100, Steven Whitehouse wrote:

> > Another problem we still have - and we're sharing it with other protocols
> > such ipv4 - is that our proc code is holding a lock for the time the
> > /proc file is open.  That's not a significant time but it may delay
> > access, so I've made most of those loads rw locks.  Worst case a buggy
> > or malicious piece of software might even hold a proc file open for a long
> > time thereby stalling the functioning of the stack partially or fully.
> > 
> Its only during read operations, not the open that the lock is held I
> think, but I agree that an rw lock is the best solution here.

The only solution I see would be redoing the data structures or as
implemented in a few other places in the kernel accepting O(n) behaviour
for the seq_operations.next method - which would make reading the
performance for reading the proc file O(n^2).  But that's a minor
problem at the moment.

73 de DO1GRB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21