Skip to content
Commits on Aug 20, 2010
  1. @gregkh

    Linux 2.6.27.52

    gregkh committed Aug 20, 2010
  2. @torvalds @gregkh

    mm: fix up some user-visible effects of the stack guard page

    commit d782437 upstream.
    
    This commit makes the stack guard page somewhat less visible to user
    space. It does this by:
    
     - not showing the guard page in /proc/<pid>/maps
    
       It looks like lvm-tools will actually read /proc/self/maps to figure
       out where all its mappings are, and effectively do a specialized
       "mlockall()" in user space.  By not showing the guard page as part of
       the mapping (by just adding PAGE_SIZE to the start for grows-up
       pages), lvm-tools ends up not being aware of it.
    
     - by also teaching the _real_ mlock() functionality not to try to lock
       the guard page.
    
       That would just expand the mapping down to create a new guard page,
       so there really is no point in trying to lock it in place.
    
    It would perhaps be nice to show the guard page specially in
    /proc/<pid>/maps (or at least mark grow-down segments some way), but
    let's not open ourselves up to more breakage by user space from programs
    that depends on the exact deails of the 'maps' file.
    
    Special thanks to Henrique de Moraes Holschuh for diving into lvm-tools
    source code to see what was going on with the whole new warning.
    
    [Note, for .27, only the /proc change is done, mlock is not modified
    here. - gregkh]
    
    Reported-and-tested-by: François Valenduc <francois.valenduc@tvcablenet.be
    Reported-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    torvalds committed with gregkh Aug 15, 2010
  3. @torvalds @gregkh

    mm: fix page table unmap for stack guard page properly

    commit 11ac552 upstream.
    
    We do in fact need to unmap the page table _before_ doing the whole
    stack guard page logic, because if it is needed (mainly 32-bit x86 with
    PAE and CONFIG_HIGHPTE, but other architectures may use it too) then it
    will do a kmap_atomic/kunmap_atomic.
    
    And those kmaps will create an atomic region that we cannot do
    allocations in.  However, the whole stack expand code will need to do
    anon_vma_prepare() and vma_lock_anon_vma() and they cannot do that in an
    atomic region.
    
    Now, a better model might actually be to do the anon_vma_prepare() when
    _creating_ a VM_GROWSDOWN segment, and not have to worry about any of
    this at page fault time.  But in the meantime, this is the
    straightforward fix for the issue.
    
    See https://bugzilla.kernel.org/show_bug.cgi?id=16588 for details.
    
    Reported-by: Wylda <wylda@volny.cz>
    Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
    Reported-by: Mike Pagano <mpagano@gentoo.org>
    Reported-by: François Valenduc <francois.valenduc@tvcablenet.be>
    Tested-by: Ed Tomlinson <edt@aei.ca>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: Greg KH <gregkh@suse.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    torvalds committed with gregkh Aug 14, 2010
  4. @gregkh

    mm: pass correct mm when growing stack

    commit 05fa199 upstream.
    
    Tetsuo Handa reports seeing the WARN_ON(current->mm == NULL) in
    security_vm_enough_memory(), when do_execve() is touching the
    target mm's stack, to set up its args and environment.
    
    Yes, a UMH_NO_WAIT or UMH_WAIT_PROC call_usermodehelper() spawns
    an mm-less kernel thread to do the exec.  And in any case, that
    vm_enough_memory check when growing stack ought to be done on the
    target mm, not on the execer's mm (though apart from the warning,
    it only makes a slight tweak to OVERCOMMIT_NEVER behaviour).
    
    Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
    Signed-off-by: Hugh Dickins <hugh@veritas.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Hugh Dickins committed with gregkh Apr 16, 2009
  5. @gregkh

    x86: don't send SIGBUS for kernel page faults

    Based on commit 9605456 upstream,
    authored by Linus Torvalds.
    
    This is my backport to the .27 kernel tree, hopefully preserving
    the same functionality.
    
    Original commit message:
    	It's wrong for several reasons, but the most direct one is that the
    	fault may be for the stack accesses to set up a previous SIGBUS.  When
    	we have a kernel exception, the kernel exception handler does all the
    	fixups, not some user-level signal handler.
    
    	Even apart from the nested SIGBUS issue, it's also wrong to give out
    	kernel fault addresses in the signal handler info block, or to send a
    	SIGBUS when a system call already returns EFAULT.
    
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    gregkh committed Aug 13, 2010
  6. @torvalds @gregkh

    mm: fix missing page table unmap for stack guard page failure case

    commit 5528f91 upstream.
    
    .. which didn't show up in my tests because it's a no-op on x86-64 and
    most other architectures.  But we enter the function with the last-level
    page table mapped, and should unmap it at exit.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    torvalds committed with gregkh Aug 13, 2010
  7. @torvalds @gregkh

    mm: keep a guard page below a grow-down stack segment

    commit 320b2b8 upstream.
    
    This is a rather minimally invasive patch to solve the problem of the
    user stack growing into a memory mapped area below it.  Whenever we fill
    the first page of the stack segment, expand the segment down by one
    page.
    
    Now, admittedly some odd application might _want_ the stack to grow down
    into the preceding memory mapping, and so we may at some point need to
    make this a process tunable (some people might also want to have more
    than a single page of guarding), but let's try the minimal approach
    first.
    
    Tested with trivial application that maps a single page just below the
    stack, and then starts recursing.  Without this, we will get a SIGSEGV
    _after_ the stack has smashed the mapping.  With this patch, we'll get a
    nice SIGBUS just as the stack touches the page just above the mapping.
    
    Requested-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    torvalds committed with gregkh Aug 12, 2010
Commits on Aug 13, 2010
  1. @gregkh

    Linux 2.6.27.51

    gregkh committed Aug 13, 2010
  2. @gregkh

    mm/backing-dev.c: remove recently-added WARN_ON()

    commit 69fc208 upstream.
    
    On second thoughts, this is just going to disturb people while telling us
    things which we already knew.
    
    Cc: Peter Korsgaard <jacmet@sunsite.dk>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Kay Sievers <kay.sievers@vrfy.org>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Ben Hutchings <bhutchings@solarflare.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Andrew Morton committed with gregkh Dec 9, 2008
  3. @kaysievers @gregkh

    bdi: register sysfs bdi device only once per queue

    commit f1d0b06 upstream.
    
    Devices which share the same queue, like floppies and mtd devices, get
    registered multiple times in the bdi interface, but bdi accounts only the
    last registered device of the devices sharing one queue.
    
    On remove, all earlier registered devices leak, stay around in sysfs, and
    cause "duplicate filename" errors if the devices are re-created.
    
    This prevents the creation of multiple bdi interfaces per queue, and the
    bdi device will carry the dev_t name of the block device which is the
    first one registered, of the pool of devices using the same queue.
    
    [akpm@linux-foundation.org: add a WARN_ON so we know which drivers are misbehaving]
    Tested-by: Peter Korsgaard <jacmet@sunsite.dk>
    Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Ben Hutchings <bhutchings@solarflare.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    kaysievers committed with gregkh Dec 2, 2008
  4. @gregkh

    xen: drop xen_sched_clock in favour of using plain wallclock time

    commit 8a22b99 upstream.
    
    xen_sched_clock only counts unstolen time.  In principle this should
    be useful to the Linux scheduler so that it knows how much time a process
    actually consumed.  But in practice this doesn't work very well as the
    scheduler expects the sched_clock time to be synchronized between
    cpus.  It also uses sched_clock to measure the time a task spends
    sleeping, in which case "unstolen time" isn't meaningful.
    
    So just use plain xen_clocksource_read to return wallclock nanoseconds
    for sched_clock.
    
    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Jeremy Fitzhardinge committed with gregkh Jul 12, 2010
  5. @gregkh

    jfs: don't allow os2 xattr namespace overlap with others

    commit aca0fa3 upstream.
    
    It's currently possible to bypass xattr namespace access rules by
    prefixing valid xattr names with "os2.", since the os2 namespace stores
    extended attributes in a legacy format with no prefix.
    
    This patch adds checking to deny access to any valid namespace prefix
    following "os2.".
    
    Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
    Reported-by: Sergey Vlasov <vsu@altlinux.ru>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Dave Kleikamp committed with gregkh Aug 9, 2010
  6. @nathanlynch @gregkh

    signalfd: fill in ssi_int for posix timers and message queues

    commit a2a20c4 upstream.
    
    If signalfd is used to consume a signal generated by a POSIX interval
    timer or POSIX message queue, the ssi_int field does not reflect the data
    (sigevent->sigev_value) supplied to timer_create(2) or mq_notify(3).  (The
    ssi_ptr field, however, is filled in.)
    
    This behavior differs from signalfd's treatment of sigqueue-generated
    signals -- see the default case in signalfd_copyinfo.  It also gives
    results that differ from the case when a signal is handled conventionally
    via a sigaction-registered handler.
    
    So, set signalfd_siginfo->ssi_int in the remaining cases (__SI_TIMER,
    __SI_MESGQ) where ssi_ptr is set.
    
    akpm: a non-back-compatible change.  Merge into -stable to minimise the
    number of kernels which are in the field and which miss this feature.
    
    Signed-off-by: Nathan Lynch <ntl@pobox.com>
    Acked-by: Davide Libenzi <davidel@xmailserver.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    nathanlynch committed with gregkh Aug 10, 2010
  7. @JuliaLawall @gregkh

    fs/ecryptfs/file.c: introduce missing free

    commit ceeab92 upstream.
    
    The comments in the code indicate that file_info should be released if the
    function fails.  This releasing is done at the label out_free, not out.
    
    The semantic match that finds this problem is as follows:
    (http://www.emn.fr/x-info/coccinelle/)
    
    // <smpl>
    @r exists@
    local idexpression x;
    statement S;
    expression E;
    identifier f,f1,l;
    position p1,p2;
    expression *ptr != NULL;
    @@
    
    x@p1 = kmem_cache_zalloc(...);
    ...
    if (x == NULL) S
    <... when != x
         when != if (...) { <+...x...+> }
    (
    x->f1 = E
    |
     (x->f1 == NULL || ...)
    |
     f(...,x->f1,...)
    )
    ...>
    (
     return <+...x...+>;
    |
     return@p2 ...;
    )
    
    @script:python@
    p1 << r.p1;
    p2 << r.p2;
    @@
    
    print "* file: %s kmem_cache_zalloc %s" % (p1[0].file,p1[0].line)
    // </smpl>
    
    Signed-off-by: Julia Lawall <julia@diku.dk>
    Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    JuliaLawall committed with gregkh Aug 6, 2010
  8. @gregkh

    eCryptfs: Handle ioctl calls with unlocked and compat functions

    commit c43f7b8 upstream.
    
    Lower filesystems that only implemented unlocked_ioctl weren't being
    passed ioctl calls because eCryptfs only checked for
    lower_file->f_op->ioctl and returned -ENOTTY if it was NULL.
    
    eCryptfs shouldn't implement ioctl(), since it doesn't require the BKL.
    This patch introduces ecryptfs_unlocked_ioctl() and
    ecryptfs_compat_ioctl(), which passes the calls on to the lower file
    system.
    
    https://bugs.launchpad.net/ecryptfs/+bug/469664
    
    Reported-by: James Dupin <james.dupin@gmail.com>
    Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Tyler Hicks committed with gregkh Nov 3, 2009
  9. @neilbrown @gregkh

    md/raid10: fix deadlock with unaligned read during resync

    commit 51e9ac7 upstream.
    
    If the 'bio_split' path in raid10-read is used while
    resync/recovery is happening it is possible to deadlock.
    Fix this be elevating ->nr_waiting for the duration of both
    parts of the split request.
    
    This fixes a bug that has been present since 2.6.22
    but has only started manifesting recently for unknown reasons.
    It is suitable for and -stable since then.
    
    Reported-by:  Justin Bronder <jsbronder@gentoo.org>
    Tested-by:  Justin Bronder <jsbronder@gentoo.org>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    neilbrown committed with gregkh Aug 7, 2010
  10. @htejun @gregkh

    PCI: disable MSI on VIA K8M800

    commit 549e156 upstream.
    
    MSI delivery from on-board ahci controller doesn't work on K8M800.  At
    this point, it's unclear whether the culprit is with the ahci
    controller or the host bridge.  Given the track record and considering
    the rather minimal impact of MSI, disabling it seems reasonable.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Rainer Hurtado Navarro <publio.escipion.el.africano@gmail.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    htejun committed with gregkh May 23, 2010
  11. @szmi @gregkh

    splice: fix misuse of SPLICE_F_NONBLOCK

    commit 6965031 upstream.
    
    SPLICE_F_NONBLOCK is clearly documented to only affect blocking on the
    pipe.  In __generic_file_splice_read(), however, it causes an EAGAIN
    if the page is currently being read.
    
    This makes it impossible to write an application that only wants
    failure if the pipe is full.  For example if the same process is
    handling both ends of a pipe and isn't otherwise able to determine
    whether a splice to the pipe will fill it or not.
    
    We could make the read non-blocking on O_NONBLOCK or some other splice
    flag, but for now this is the simplest fix.
    
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    szmi committed with gregkh Aug 3, 2010
  12. @gregkh

    nvram: Fix write beyond end condition; prove to gcc copy is safe

    commit a01c780 upstream.
    
    In nvram_write, first of all, correctly handle the case where the file
    pointer is already beyond the end; we should return EOF in that case.
    
    Second, make the logic a bit more explicit so that gcc can statically
    prove that the copy_from_user() is safe.  Once the condition of the
    beyond-end filepointer is eliminated, the copy is safe but gcc can't
    prove it, causing build failures for i386 allyesconfig.
    
    Third, eliminate the entirely superfluous variable "len", and just use
    the passed-in variable "count" instead.
    
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Cc: Arjan van de Ven <arjan@infradead.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Wim Van Sebroeck <wim@iguana.be>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    LKML-Reference: <tip-*@git.kernel.org>
    Cc: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    H. Peter Anvin committed with gregkh Dec 11, 2009
Commits on Aug 10, 2010
  1. @gregkh

    Linux 2.6.27.50

    gregkh committed Aug 10, 2010
  2. @gregkh

    GFS2: rename causes kernel Oops

    commit 728a756 upstream.
    
    This patch fixes a kernel Oops in the GFS2 rename code.
    
    The problem was in the way the gfs2 directory code was trying
    to re-use sentinel directory entries.
    
    In the failing case, gfs2's rename function was renaming a
    file to another name that had the same non-trivial length.
    The file being renamed happened to be the first directory
    entry on the leaf block.
    
    First, the rename code (gfs2_rename in ops_inode.c) found the
    original directory entry and decided it could do its job by
    simply replacing the directory entry with another.  Therefore
    it determined correctly that no block allocations were needed.
    
    Next, the rename code deleted the old directory entry prior to
    replacing it with the new name.  Therefore, the soon-to-be
    replaced directory entry was temporarily made into a directory
    entry "sentinel" or a place holder at the start of a leaf block.
    
    Lastly, it went to re-add the replacement directory entry in
    that leaf block.  However, when gfs2_dirent_find_space was
    looking for space in the leaf block, it used the wrong value
    for the sentinel.  That threw off its calculations so later
    it decides it can't really re-use the sentinel and therefore
    must allocate a new leaf block.  But because it previously decided
    to re-use the directory entry, it didn't waste the time to
    grab a new block allocation for the inode.  Therefore, the
    inode's i_alloc pointer was still NULL and it crashes trying to
    reference it.
    
    In the case of sentinel directory entries, the entire dirent is
    reused, not just the "free space" portion of it, and therefore
    the function gfs2_dirent_find_space should use the value 0
    rather than GFS2_DIRENT_SIZE(0) for the actual dirent size.
    
    Fixing this calculation enables the reproducer programs to work
    properly.
    
    Signed-off-by: Bob Peterson <rpeterso@redhat.com>
    Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Bob Peterson committed with gregkh Jul 14, 2010
  3. @gregkh

    SCSI: enclosure: fix error path - actually return ERR_PTR() on error

    commit a91c1be upstream.
    
    we also need to clean up and free the cdev.
    
    Reported-by: Jani Nikula <ext-jani.1.nikula@nokia.com>
    Signed-off-by: James Bottomley <James.Bottomley@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    James Bottomley committed with gregkh Mar 12, 2010
  4. @djrbliss @gregkh

    xfs: prevent swapext from operating on write-only files

    commit 1817176 upstream.
    
    This patch prevents user "foo" from using the SWAPEXT ioctl to swap
    a write-only file owned by user "bar" into a file owned by "foo" and
    subsequently reading it.  It does so by checking that the file
    descriptors passed to the ioctl are also opened for reading.
    
    Signed-off-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    djrbliss committed with gregkh Jun 24, 2010
  5. @gregkh

    PARISC: led.c - fix potential stack overflow in led_proc_write()

    commit 4b4fd27 upstream.
    
    avoid potential stack overflow by correctly checking count parameter
    
    Reported-by: Ilja <ilja@netric.org>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Acked-by: Kyle McMartin <kyle@mcmartin.ca>
    Cc: James E.J. Bottomley <jejb@parisc-linux.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Helge Deller committed with gregkh Aug 2, 2010
Commits on Aug 6, 2010
  1. @gregkh

    .gitignore updates

    commit c17dad6 upstream.
    
    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Alexey Dobriyan committed with gregkh Oct 29, 2008
Commits on Aug 2, 2010
  1. @gregkh

    Linux 2.6.27.49

    gregkh committed Aug 2, 2010
  2. @gregkh

    ecryptfs: Bugfix for error related to ecryptfs_hash_buckets

    commit a6f80fb upstream.
    
    The function ecryptfs_uid_hash wrongly assumes that the
    second parameter to hash_long() is the number of hash
    buckets instead of the number of hash bits.
    This patch fixes that and renames the variable
    ecryptfs_hash_buckets to ecryptfs_hash_bits to make it
    clearer.
    
    Fixes: CVE-2010-2492
    
    Signed-off-by: Andre Osterhues <aosterhues@escrypt.com>
    Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Andre Osterhues committed with gregkh Jul 13, 2010
  3. @gregkh

    kbuild: Fix modpost segfault

    commit 1c93866 upstream.
    
    Alan <alan@clueserver.org> writes:
    
    > program: /home/alan/GitTrees/linux-2.6-mid-ref/scripts/mod/modpost -o
    > Module.symvers -S vmlinux.o
    >
    > Program received signal SIGSEGV, Segmentation fault.
    
    It just hit me.
    It's the offset calculation in reloc_location() which overflows:
            return (void *)elf->hdr + sechdrs[section].sh_offset +
                   (r->r_offset - sechdrs[section].sh_addr);
    
    E.g. for the first rodata r entry:
    r->r_offset < sechdrs[section].sh_addr
    and the expression in the parenthesis produces 0xFFFFFFE0 or something
    equally wise.
    
    Reported-by: Alan <alan@clueserver.org>
    Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
    Tested-by: Alan <alan@clueserver.org>
    Signed-off-by: Michal Marek <mmarek@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Krzysztof Halasa committed with gregkh Jun 11, 2010
  4. @gregkh

    bonding: select current active slave when enslaving device for mode t…

    …lb and alb
    
    commit 5a29f78 upstream.
    
    I've hit an issue on my system when I've been using RealTek RTL8139D cards in
    bonding interface in mode balancing-alb. When I enslave a card, the current
    active slave (bond->curr_active_slave) is not set and the link is therefore
    not functional.
    
    ----
    # cat /proc/net/bonding/bond0
    Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
    
    Bonding Mode: adaptive load balancing
    Primary Slave: None
    Currently Active Slave: None
    MII Status: up
    MII Polling Interval (ms): 100
    Up Delay (ms): 0
    Down Delay (ms): 0
    
    Slave Interface: eth1
    MII Status: up
    Link Failure Count: 0
    Permanent HW addr: 00:1f:1f:01:2f:22
    ----
    
    The thing that gets it right is when I unplug the cable and then I put it back
    into the NIC. Then the current active slave is set to eth1 and link is working
    just fine. Here is dmesg log with bonding DEBUG messages turned on:
    ----
    ADDRCONF(NETDEV_UP): bond0: link is not ready
    event_dev: bond0, event: 1
    IFF_MASTER
    event_dev: bond0, event: 8
    IFF_MASTER
    bond_ioctl: master=bond0, cmd=35216
    slave_dev=cac5d800:
    slave_dev->name=eth1:
    eth1: ! NETIF_F_VLAN_CHALLENGED
    event_dev: eth1, event: 8
    eth1: link up, 100Mbps, full-duplex, lpa 0xC5E1
    event_dev: eth1, event: 1
    event_dev: eth1, event: 8
    IFF_SLAVE
    Initial state of slave_dev is BOND_LINK_UP
    bonding: bond0: enslaving eth1 as an active interface with an up link.
    ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
    event_dev: bond0, event: 4
    IFF_MASTER
    bond0: no IPv6 routers present
    
    <<<<cable unplug>>>>
    
    eth1: link down
    event_dev: eth1, event: 4
    IFF_SLAVE
    bonding: bond0: link status definitely down for interface eth1, disabling it
    event_dev: bond0, event: 4
    IFF_MASTER
    
    <<<<cable plug>>>>
    
    eth1: link up, 100Mbps, full-duplex, lpa 0xC5E1
    event_dev: eth1, event: 4
    IFF_SLAVE
    bonding: bond0: link status definitely up for interface eth1.
    bonding: bond0: making interface eth1 the new active one.
    event_dev: eth1, event: 8
    IFF_SLAVE
    event_dev: eth1, event: 8
    IFF_SLAVE
    bonding: bond0: first active interface up!
    event_dev: bond0, event: 4
    IFF_MASTER
    ----
    
    The current active slave is set by calling bond_select_active_slave() function
    from bond_miimon_commit() function when the slave (eth1) link goes to state up.
    
    I also tested this on other machine with Broadcom NetXtreme II BCM5708
    1000Base-T NIC and there all works fine. The thing is that this adapter is down
    and goes up after few seconds after it is enslaved.
    
    This patch calls bond_select_active_slave() in bond_enslave() function for modes
    alb and tlb and makes sure that the current active slave is set up properly even
    when the slave state is already up. Tested on both systems, works fine.
    
    Notice: The same problem can maybe also occrur in mode 8023AD but I'm unable to
    test that.
    
    Signed-off-by: Jiri Pirko <jpirko@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Jean Delvare <jdelvare@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Jiri Pirko committed with gregkh Mar 25, 2009
  5. @gregkh

    IPoIB: Fix world-writable child interface control sysfs attributes

    commit 7a52b34 upstream.
    
    Sumeet Lahorani <sumeet.lahorani@oracle.com> reported that the IPoIB
    child entries are world-writable; however we don't want ordinary users
    to be able to create and destroy child interfaces, so fix them to be
    writable only by root.
    
    Signed-off-by: Or Gerlitz <ogerlitz@voltaire.com>
    Signed-off-by: Roland Dreier <rolandd@cisco.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Or Gerlitz committed with gregkh Jun 6, 2010
  6. @gregkh

    x86, Calgary: Limit the max PHB number to 256

    commit d596043 upstream.
    
    The x3950 family can have as many as 256 PCI buses in a single system, so
    change the limits to the maximum.  Since there can only be 256 PCI buses in one
    domain, we no longer need the BUG_ON check.
    
    Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
    LKML-Reference: <20100701004519.GQ15515@tux1.beaverton.ibm.com>
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Darrick J. Wong committed with gregkh Jun 30, 2010
  7. @gregkh

    x86, Calgary: Increase max PHB number

    commit 499a00e upstream.
    
    Newer systems (x3950M2) can have 48 PHBs per chassis and 8
    chassis, so bump the limits up and provide an explanation
    of the requirements for each class.
    
    Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
    Acked-by: Muli Ben-Yehuda <muli@il.ibm.com>
    Cc: Corinna Schultz <cschultz@linux.vnet.ibm.com>
    LKML-Reference: <20100624212647.GI15515@tux1.beaverton.ibm.com>
    [ v2: Fixed build bug, added back PHBS_PER_CALGARY == 4 ]
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Darrick J. Wong committed with gregkh Jun 24, 2010
  8. @bwhacks @gregkh

    amd64-agp: Probe unknown AGP devices the right way

    commit 6fd0248 upstream.
    
    The current initialisation code probes 'unsupported' AGP devices
    simply by calling its own probe function.  It does not lock these
    devices or even check whether another driver is already bound to
    them.
    
    We must use the device core to manage this.  So if the specific
    device id table didn't match anything and agp_try_unsupported=1,
    switch the device id table and call driver_attach() again.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    bwhacks committed with gregkh Mar 24, 2010
  9. @JuliaLawall @gregkh

    SCSI: aacraid: Eliminate use after free

    commit 8a52da6 upstream.
    
    The debugging code using the freed structure is moved before the kfree.
    
    A simplified version of the semantic match that finds this problem is as
    follows: (http://coccinelle.lip6.fr/)
    
    // <smpl>
    @free@
    expression E;
    position p;
    @@
    kfree@p(E)
    
    @@
    expression free.E, subE<=free.E, E1;
    position free.p;
    @@
    
      kfree@p(E)
      ...
    (
      subE = E1
    |
    * E
    )
    // </smpl>
    
    Signed-off-by: Julia Lawall <julia@diku.dk>
    Signed-off-by: James Bottomley <James.Bottomley@suse.de>
    JuliaLawall committed with gregkh May 15, 2010
  10. @gregkh

    netfilter: ip6t_REJECT: fix a dst leak in ipv6 REJECT

    commit 499031a upstream.
    
    We should release dst if dst->error is set.
    
    Bug introduced in 2.6.14 by commit e104411
    ([XFRM]: Always release dst_entry on error in xfrm_lookup)
    
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Eric Dumazet committed with gregkh Jul 2, 2010
Something went wrong with that request. Please try again.