LWN.net Logo

Not logged in

Log in now

Create an account

Subscribe to LWN

Recent Features

LWN.net Weekly Edition for June 20, 2013

Pencil, Pencil, and Pencil

Dividing the Linux desktop

LWN.net Weekly Edition for June 13, 2013

A report from pgCon 2013

Printable page
Weekly edition Kernel Security Distributions Contact Us Search
Archives Calendar Subscribe Write for LWN LWN.net FAQ Sponsors

Exercises for the interested reader

Exercises for the interested reader

Posted Nov 25, 2010 16:07 UTC (Thu) by lacos (subscriber, #70616)
Parent article: Ghosts of Unix past, part 4: High-maintenance designs

1. Identify a design element in the IP protocol suite which could be described as "high maintenance" or as having "unintended consequences".

Source routing and TCP urgent data come to my mind.

3. Research and enumerate uses of "hard links" which are not adequately served by using symbolic links instead. Suggest technologies that might effectively replace these other uses.

Some programs do this:

  1. Create a file.
  2. Work with the file.
  3. If the work completes, close the file, leave the reference (the name) in the fs.
  4. If the work is interrupted or fails, close the file and remove the reference (in some order).
It is sometimes useful to add an independent hard link to the file during step 2, so it can be salvaged when the program removes it in step 4. Example: downloading a big file with your browser, then continuing it with wget.

The non-plus-ultra of hard-linking is flink(). Among other things, it should allow for a very useful operation: make a file reappear instantenously in the filesystem. Consider the practice of some utilities:

  1. Create a temporary file.
  2. Remove its name immediately, but keep it open by file descriptor, file description, and inode.
  3. If the work completes, close the file. With the last reference going away, the space occupied by the file is released.
  4. If the program crashes, or eg. a SIGKILL is delivered to it, the previous step happens automatically. Nothing left around to clean up later.
flink() extends this workflow for files that you want to keep in the end! Just replace the third step in the previous list: if the work completes, flink() the file back into the filesystem, then close it. It's like a lightweight "commit transaction" statement, with automatic rollback on failure.

(Log in to post comments)

flink syscall

Posted Nov 26, 2010 23:44 UTC (Fri) by speedster1 (subscriber, #8143) [Link]

It sounded very promising, but unfortunately nobody was able to come up with an implementation avoiding security holes. Linus put it this way, later in the same thread:

"As others have pointed out, there is no way in HELL we can do this
securely without major other incursions.

In particular, both flink() and funlink() require that you do all the
same permission checks that a real link() or unlink() would do. And as
some of them are done on the _source_ of the file, that implies that
they have to be done at open() time."

http://lkml.indiana.edu/hypermail/linux/kernel/0304.0/160...

Exercises for the interested reader

Posted Dec 4, 2010 1:20 UTC (Sat) by mxkb (guest, #71646) [Link]

Thinking outside of IP, IPv6's design is of high maintenance. The design was based on 1990's technology and is much worse than IPv4. There's no Identification field, which makes it very hard to debug. It uses this linked TLV headers instead of stating the total length in the beginning, and that makes the implementation very hard.

Ipv6's design is just so bad, and I don't understand why people won't start to work on the replacement.

Exercises for the interested reader

Posted Dec 4, 2010 1:34 UTC (Sat) by foom (subscriber, #14868) [Link]

Probably because those two things you said cannot possibly rise to the level of "needs a brand new incompatible-with-everything replacement"...

Also: the identification field is used for something other than fragment reassembly? huh..

Exercises for the interested reader

Posted Dec 7, 2010 0:55 UTC (Tue) by mxkb (guest, #71646) [Link]

Yes, protocol wise, the identification field is used only for fragmentation. But in debugging, you can use it for correlating packets seen at two different places. Just think about it, in a datagram paradigm, isn't it useful if I can tell a retransmitted packet from the original packet?

Exercises for the interested reader

Posted Dec 4, 2010 7:22 UTC (Sat) by paulj (subscriber, #341) [Link]

I've heard people with experience of building hardware-forward routers complain about the same thing - that the IPv6 "Next-Header" daisy chain is a pain to implement (in hardware specifically, was their complaint). I don't understand yet why though - IPv4 options *also* use a TLV format, and the v6 payload length includes the options just as v4's length does. What am I missing?

Exercises for the interested reader

Posted Dec 7, 2010 0:50 UTC (Tue) by mxkb (guest, #71646) [Link]

Extension headers are considered part of the payload. So even from ipv6 header, you can get payload length, you still have to parse every extension header to find the TCP/UDP header. The difference is in IPV4, you can find the L4 header directly.

Exercises for the interested reader

Posted Dec 7, 2010 10:41 UTC (Tue) by paulj (subscriber, #341) [Link]

Yes, I can see how some might dislike that, but it only applies to end-hosts. So doesn't affect routers, unless I'm missing something? (Indeed, making it more expensive for middle-boxes to unpack and get at the ULPs might even be a good thing in some respects).

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds