1. 12 2月, 2007 14 次提交
  2. 14 12月, 2006 1 次提交
  3. 09 12月, 2006 1 次提交
    • A
      [PATCH] tty: switch to ktermios · 606d099c
      Alan Cox 提交于
      This is the grungy swap all the occurrences in the right places patch that
      goes with the updates.  At this point we have the same functionality as
      before (except that sgttyb() returns speeds not zero) and are ready to
      begin turning new stuff on providing nobody reports lots of bugs
      
      If you are a tty driver author converting an out of tree driver the only
      impact should be termios->ktermios name changes for the speed/property
      setting functions from your upper layers.
      
      If you are implementing your own TCGETS function before then your driver
      was broken already and its about to get a whole lot more painful for you so
      please fix it 8)
      
      Also fill in c_ispeed/ospeed on init for most devices, although the current
      code will do this for you anyway but I'd like eventually to lose that extra
      paranoia
      
      [akpm@osdl.org: bluetooth fix]
      [mp3@de.ibm.com: sclp fix]
      [mp3@de.ibm.com: warning fix for tty3270]
      [hugh@veritas.com: fix tty_ioctl powerpc build]
      [jdike@addtoit.com: uml: fix ->set_termios declaration]
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NMartin Peschke <mp3@de.ibm.com>
      Acked-by: NPeter Oberparleiter <oberpar@de.ibm.com>
      Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      606d099c
  4. 08 12月, 2006 3 次提交
  5. 03 12月, 2006 1 次提交
  6. 26 11月, 2006 1 次提交
    • P
      [PATCH] uml: make execvp safe for our usage · 5d48545e
      Paolo 'Blaisorblade' Giarrusso 提交于
      Reimplement execvp for our purposes - after we call fork() it is fundamentally
      unsafe to use the kernel allocator - current is not valid there.  So we simply
      pass to our modified execvp() a preallocated buffer.  This fixes a real bug
      and works very well in testing (I've seen indirectly warning messages from the
      forked thread - they went on the pipe connected to its stdout and where read
      as a number by UML, when calling read_output().  I verified the obtained
      number corresponded to "BUG:").
      
      The added use of __cant_sleep() is not a new bug since __cant_sleep() is
      already used in the same function - passing an atomicity parameter would be
      better but it would require huge change, stating that this function must not
      be called in atomic context and can sleep is a better idea (will make sure of
      this gradually).
      Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Acked-by: NJeff Dike <jdike@addtoit.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5d48545e
  7. 04 11月, 2006 1 次提交
    • J
      [PATCH] uml: fix I/O hang · 53b17332
      Jeff Dike 提交于
      Fix a UML hang in which everything would just stop until some I/O happened
      - a ping, someone whacking the keyboard - at which point everything would
      start up again as though nothing had happened.
      
      The cause was gcc reordering some code which absolutely needed to be
      executed in the order in the source.  When unblock_signals switches signals
      from off to on, it needs to see if any interrupts had happened in the
      critical section.  The interrupt handlers check signals_enabled - if it is
      zero, then the handler adds a bit to the "pending" bitmask and returns.
      unblock_signals checks this mask to see if any signals need to be
      delivered.
      
      The crucial part is this:
      	signals_enabled = 1;
      	save_pending = pending;
      	if(save_pending == 0)
      		return;
      	pending = 0;
      
      In order to avoid an interrupt arriving between reading pending and setting
      it to zero, in which case, the record of the interrupt would be erased,
      signals are enabled.
      
      What happened was that gcc reordered this so that 'save_pending = pending'
      came before 'signals_enabled = 1', creating a one-instruction window within
      which an interrupt could arrive, set its bit in pending, and have it be
      immediately erased.
      
      When the I/O workload is purely disk-based, the loss of a block device
      interrupt stops the entire I/O system because the next block request will
      wait for the current one to finish.  Thus the system hangs until something
      else causes some I/O to arrive, such as a network packet or console input.
      
      The fix to this particular problem is a memory barrier between enabling
      signals and reading the pending signal mask.  An xchg would also probably
      work.
      
      Looking over this code for similar problems led me to do a few more
      things:
      
      - make signals_enabled and pending volatile so that they don't get cached
        in registers
      
      - add an mb() to the return paths of block_signals and unblock_signals so
        that the modification of signals_enabled doesn't get shuffled into the
        caller in the event that these are inlined in the future.
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      53b17332
  8. 01 11月, 2006 1 次提交
  9. 25 10月, 2006 1 次提交
    • A
      [PATCH] uml: mconsole fixes · 3a51237d
      Al Viro 提交于
       * when we have stop/sysrq/go, we get pt_regs of whatever executes
         mc_work_proc().  Would be better to see what we had at the time of
         interrupt that got us stop.
      
       * stop/stop/stop.....  will give stack overflow.  Shouldn't allow stop
         from mconsole_stop().
      
       * stop/stop/go leaves us inside mconsole_stop() with
      	os_set_fd_block(req->originating_fd, 0);
      	reactivate_fd(req->originating_fd, MCONSOLE_IRQ);
         just done by nested mconsole_stop().  Ditto.
      
       * once we'd seen stop, there's a period when INTR commands are executed
         out of order (as they should; we might have the things stuck badly
         enough to never reach mconsole_stop(), but still not badly enough to
         block mconsole_interrupt(); in that situation we _want_ things like
         "cad" to be executed immediately).  Once we enter monsole_stop(), all
         INTR commands will be executed in order, mixed with PROC ones.  We'd
         better let user see that such change of behaviour has happened.
         (Suggested by lennert).
      
       * stack footprint of monsole_interrupt() is an atrocity; AFAICS we can
         safely make struct mc_request req; static in function there.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Acked-by: NJeff Dike <jdike@addtoit.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3a51237d
  10. 21 10月, 2006 1 次提交
  11. 16 10月, 2006 1 次提交
  12. 12 10月, 2006 4 次提交
  13. 09 10月, 2006 2 次提交
  14. 04 10月, 2006 2 次提交
  15. 02 10月, 2006 1 次提交
    • J
      [PATCH] const struct tty_operations · b68e31d0
      Jeff Dike 提交于
      As part of an SMP cleanliness pass over UML, I consted a bunch of
      structures in order to not have to document their locking.  One of these
      structures was a struct tty_operations.  In order to const it in UML
      without introducing compiler complaints, the declaration of
      tty_set_operations needs to be changed, and then all of its callers need to
      be fixed.
      
      This patch declares all struct tty_operations in the tree as const.  In all
      cases, they are static and used only as input to tty_set_operations.  As an
      extra check, I ran an i386 allyesconfig build which produced no extra
      warnings.
      
      53 drivers are affected.  I checked the history of a bunch of them, and in
      most cases, there have been only a handful of maintenance changes in the
      last six months.  serial_core.c was the busiest one that I looked at.
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Acked-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b68e31d0
  16. 30 9月, 2006 3 次提交
    • J
      [PATCH] uml: don't roll my own random MAC generator · fade5d54
      Jeff Dike 提交于
      Use the existing random_ether_addr() instead of cooking up my own
      version.  Pointed out by Dave Hollis and Jason Lunz.
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      fade5d54
    • J
      [PATCH] uml: mechanical tidying after random MACs change · b10aeeef
      Jeff Dike 提交于
      Mechanical, hopefully non-functional changes stemming from
      setup_etheraddr always succeeding now that it always assigns a MAC,
      either from the command line or generated randomly:
         the test of the return of setup_etheraddr is removed, and code
      dependent on it succeeding is now unconditional
         setup_etheraddr can now be made void
         struct uml_net.have_mac is now always 1, so tests of it can be
      similarly removed, and uses of it can be replaced with 1
         struct uml_net.have_mac is no longer used, so it can be removed
         struct uml_net_private.have_mac is copied from struct uml_net, so
      it is always 1
         tests of uml_net_private.have_mac can be removed
         uml_net_private.have_mac can now be removed
         the only call to dev_ip_addr was removed, so it can be deleted
      
      It also turns out that setup_etheraddr is called only once, from the same
      file, so it can be static and its declaration removed from net_kern.h.
      
      Similarly, set_ether_mac is defined and called only from one file.
      
      Finally, setup_etheraddr and set_ether_mac were moved to avoid needing forward
      declarations.
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b10aeeef
    • J
      [PATCH] uml: assign random MACs to interfaces if necessary · f3e7ed2b
      Jeff Dike 提交于
      Assign a random MAC to an ethernet interface if one was not provided on the
      command line.  This became pressing when distros started bringing interfaces
      up before assigning IPs to them.  The previous pattern of assigning an IP then
      bringing it up allowed the MAC to be generated from the first IP assigned.
      However, once the thing is up, it's probably a bad idea to change the MAC, so
      the MAC stayed initialized to fe:fd:0:0:0:0.
      
      Now, if there is no MAC from the command line, one is generated.  We use the
      microseconds from gettimeofday (20 bits), plus the low 12 bits of the pid to
      seed the random number generator.  random() is called twice, with 16 bits of
      each result used.  I didn't want to have to try to fill in 32 bits optimally
      given an arbitrary RAND_MAX, so I just assume that it is greater than 65536
      and use 16 bits of each random() return.
      
      There is also a bit of reformatting and whitespace cleanup here.
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f3e7ed2b
  17. 27 9月, 2006 2 次提交
    • J
      [PATCH] uml: thread creation tidying · 3c917350
      Jeff Dike 提交于
      fork on UML has always somewhat subtle.  The underlying cause has been the
      need to initialize a stack for the new process.  The only portable way to
      initialize a new stack is to set it as the alternate signal stack and take a
      signal.  The signal handler does whatever initialization is needed and jumps
      back to the original stack, where the fork processing is finished.  The basic
      context switching mechanism is a jmp_buf for each process.  You switch to a
      new process by longjmping to its jmp_buf.
      
      Now that UML has its own implementation of setjmp and longjmp, and I can poke
      around inside a jmp_buf without fear that libc will change the structure, a
      much simpler mechanism is possible.  The jmpbuf can simply be initialized by
      hand.
      
      This eliminates -
      	the need to set up and remove the alternate signal stack
      	sending and handling a signal
      	the signal blocking needed around the stack switching, since
      there is no stack switching
      	setting up the jmp_buf needed to jump back to the original
      stack after the new one is set up
      
      In addition, since jmp_buf is now defined by UML, and not by libc, it can be
      embedded in the thread struct.  This makes it unnecessary to have it exist on
      the stack, where it used to be.  It also simplifies interfaces, since the
      switch jmp_buf used to be a void * inside the thread struct, and functions
      which took it as an argument needed to define a jmp_buf variable and assign it
      from the void *.
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3c917350
    • J
      [PATCH] uml: mark some tt-mode code · 0915ee38
      Jeff Dike 提交于
      Mark a symbol and file as being tt-mode only.  This shrinks the binary
      slightly when tt mode support is compiled out and makes it easier to identity
      stuff when tt mode is removed.
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0915ee38