09 Dec, 2006

1 commit

  • 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: Alan Cox
    Signed-off-by: Martin Peschke
    Acked-by: Peter Oberparleiter
    Cc: Cornelia Huck
    Signed-off-by: Hugh Dickins
    Signed-off-by: Jeff Dike
    Cc: Paolo 'Blaisorblade' Giarrusso
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alan Cox
     

08 Dec, 2006

3 commits


03 Dec, 2006

1 commit


26 Nov, 2006

1 commit

  • 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: Paolo 'Blaisorblade' Giarrusso
    Acked-by: Jeff Dike
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paolo 'Blaisorblade' Giarrusso
     

04 Nov, 2006

1 commit

  • 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: Jeff Dike
    Cc: Paolo 'Blaisorblade' Giarrusso
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Dike
     

01 Nov, 2006

1 commit

  • Fix a small memory leak in ubd_config, and clearify the confusion which lead
    to it.

    Then, some little changes not affecting operations -
    * move init functions together,
    * add a comment about a potential problem in case of some evolution in the block layer,
    * mark all initcalls as static __init functions
    * mark an used once little function as inline
    * document that mconsole methods are all called in process context (was
    triggered when checking ubd mconsole methods).

    Signed-off-by: Paolo 'Blaisorblade' Giarrusso
    Cc: Jeff Dike
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paolo 'Blaisorblade' Giarrusso
     

25 Oct, 2006

1 commit

  • * 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: Al Viro
    Acked-by: Jeff Dike
    Signed-off-by: Linus Torvalds

    Al Viro
     

21 Oct, 2006

1 commit


16 Oct, 2006

1 commit

  • I need this patch to get a UML kernel to compile. This is with the
    kernel headers in FC6 which are automatically generated from the kernel
    tree. Some headers are missing but those files don't need them. At
    least it appears so since the resuling kernel works fine.

    Tested on x86-64.

    Signed-off-by: Ulrich Drepper
    Signed-off-by: Linus Torvalds

    Ulrich Drepper
     

12 Oct, 2006

4 commits


09 Oct, 2006

2 commits

  • Use the new typedef for interrupt handler function pointers rather than
    actually spelling out the full thing each time. This was scripted with the
    following small shell script:

    #!/bin/sh
    egrep -nHrl -e 'irqreturn_t[ ]*[(][*]' $* |
    while read i
    do
    echo $i
    perl -pi -e 's/irqreturn_t\s*[(]\s*[*]\s*([_a-zA-Z0-9]*)\s*[)]\s*[(]\s*int\s*,\s*void\s*[*]\s*[)]/irq_handler_t \1/g' $i || exit $?
    done

    Signed-Off-By: David Howells

    David Howells
     
  • Real fix for UML pt_regs stuff. Note set_irq_regs() logics in there...

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     

04 Oct, 2006

2 commits


02 Oct, 2006

1 commit

  • 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: Jeff Dike
    Acked-by: Alan Cox
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Dike
     

30 Sep, 2006

3 commits

  • Use the existing random_ether_addr() instead of cooking up my own
    version. Pointed out by Dave Hollis and Jason Lunz.

    Signed-off-by: Jeff Dike
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    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: Jeff Dike
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    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: Jeff Dike
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Dike
     

27 Sep, 2006

4 commits

  • 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: Jeff Dike
    Cc: Paolo 'Blaisorblade' Giarrusso
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    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: Jeff Dike
    Cc: Paolo 'Blaisorblade' Giarrusso
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Dike
     
  • The UML/x86_64 headers were missing ptrace support for some segment registers.
    The underlying problem was that the x86_64 kernel uses user_regs_struct
    rather than the ptrace register definitions in ptrace. This patch switches
    UML/x86_64 to using user_regs_struct for its definitions of the host's
    registers.

    Signed-off-by: Jeff Dike
    Cc: Paolo 'Blaisorblade' Giarrusso
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Dike
     
  • Make lots of structures const in order to make it obvious that they need no
    locking.

    Signed-off-by: Jeff Dike
    Cc: Paolo 'Blaisorblade' Giarrusso
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Dike
     

26 Sep, 2006

7 commits

  • The KSTK_* macros used an inordinate amount of stack. In order to overcome
    an impedance mismatch between their interface, which just returns a single
    register value, and the interface of get_thread_regs, which took a full
    pt_regs, the implementation created an on-stack pt_regs, filled it in, and
    returned one field. do_task_stat calls KSTK_* twice, resulting in two
    local pt_regs, blowing out the stack.

    This patch changes the interface (and name) of get_thread_regs to just
    return a single register from a jmp_buf.

    The include of archsetjmp.h" in registers.h to get the definition of
    jmp_buf exposed a bogus include of in start_up.c.
    shouldn't be used anywhere any more since UML uses the klibc
    setjmp/longjmp.

    Signed-off-by: Jeff Dike
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Dike
     
  • Clean set_ether_mac usage. Maybe could also be removed, but surely it can't
    be a global function taking a void* argument.

    Signed-off-by: Paolo 'Blaisorblade' Giarrusso
    Acked-by: Jeff Dike
    Cc: Jeff Garzik
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paolo 'Blaisorblade' Giarrusso
     
  • timer_irq_inited was useless, so it is removed.

    Signed-off-by: Jeff Dike
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Dike
     
  • set_interval returns an error instead of panicing if setitimer fails. Some of
    its callers now check the return.

    enable_timer is largely tt-mode-specific, so it is marked as such, and the
    only skas-mode caller is made to call set-interval instead.

    user_time_init was a no-value-added wrapper around set_interval, so it is
    gone.

    Since set_interval is now called from kernel code, callers no longer pass
    ITIMER_* to it. Instead, they pass a flag which is converted into ITIMER_REAL
    or ITIMER_VIRTUAL.

    Signed-off-by: Jeff Dike
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Dike
     
  • Have most signals go through an arch-provided handler which recovers the
    sigcontext and then calls a generic handler. This replaces the
    ARCH_GET_SIGCONTEXT macro, which was somewhat fragile. On x86_64, recovering
    %rdx (which holds the sigcontext pointer) must be the first thing that
    happens. sig_handler duly invokes that first, but there is no guarantee that
    I can see that instructions won't be reordered such that %rdx is used before
    that. Having the arch provide the handler seems much more robust.

    Some signals in some parts of UML require their own handlers - these places
    don't call set_handler any more. They call sigaction or signal themselves.

    Signed-off-by: Jeff Dike
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Dike
     
  • - Various cleanups in the sigio code.

    - Removed explicit zero-initializations of a few structures.

    - Improved some error messages.

    - An API change - there was an asymmetry between reactivate_fd calling
    maybe_sigio_broken, which goes through all the machinery of figuring out if
    a file descriptor supports SIGIO and applying the workaround to it if not,
    and deactivate_fd, which just turns off the descriptor.

    This is changed so that only activate_fd calls maybe_sigio_broken, when
    the descriptor is first seen. reactivate_fd now calls add_sigio_fd, which
    is symmetric with ignore_sigio_fd.

    This removes a recursion which makes a critical section look more critical
    than it really was, obsoleting a big comment to that effect. This requires
    keeping track of all descriptors which are getting the SIGIO treatment, not
    just the ones being polled at any given moment, so that reactivate_fd,
    through add_sigio_fd, doesn't try to tell the SIGIO thread about descriptors
    it doesn't care about.

    Signed-off-by: Jeff Dike
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Dike
     
  • This patch adds an implementation of setjmp and longjmp to UML, allowing
    access to the inside of a jmpbuf without needing the access macros formerly
    provided by libc.

    The implementation is stolen from klibc. I copy the relevant files into
    arch/um. I have another patch which avoids the copying, but requires klibc be
    in the tree.

    setjmp and longjmp users required some tweaking. Includes of were
    removed and includes of the UML longjmp.h were added where necessary. There
    are also replacements of siglongjmp with UML_LONGJMP which I somehow missed
    earlier.

    Signed-off-by: Jeff Dike
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Dike
     

15 Jul, 2006

2 commits


11 Jul, 2006

4 commits