04 Oct, 2011

3 commits

  • This is a minor change.

    Up until kernel 2.6.32, getsockopt(fd, SOL_PACKET, PACKET_STATISTICS,
    ...) would return total and dropped packets since its last invocation. The
    introduction of socket queue overflow reporting [1] changed drop
    rate calculation in the normal packet socket path, but not when using a
    packet ring. As a result, the getsockopt now returns different statistics
    depending on the reception method used. With a ring, it still returns the
    count since the last call, as counts are incremented in tpacket_rcv and
    reset in getsockopt. Without a ring, it returns 0 if no drops occurred
    since the last getsockopt and the total drops over the lifespan of
    the socket otherwise. The culprit is this line in packet_rcv, executed
    on a drop:

    drop_n_acct:
    po->stats.tp_drops = atomic_inc_return(&sk->sk_drops);

    As it shows, the new drop number it taken from the socket drop counter,
    which is not reset at getsockopt. I put together a small example
    that demonstrates the issue [2]. It runs for 10 seconds and overflows
    the queue/ring on every odd second. The reported drop rates are:
    ring: 16, 0, 16, 0, 16, ...
    non-ring: 0, 15, 0, 30, 0, 46, 0, 60, 0 , 74.

    Note how the even ring counts monotonically increase. Because the
    getsockopt adds tp_drops to tp_packets, total counts are similarly
    reported cumulatively. Long story short, reinstating the original code, as
    the below patch does, fixes the issue at the cost of additional per-packet
    cycles. Another solution that does not introduce per-packet overhead
    is be to keep the current data path, record the value of sk_drops at
    getsockopt() at call N in a new field in struct packetsock and subtract
    that when reporting at call N+1. I'll be happy to code that, instead,
    it's just more messy.

    [1] http://patchwork.ozlabs.org/patch/35665/
    [2] http://kernel.googlecode.com/files/test-packetsock-getstatistics.c

    Signed-off-by: Willem de Bruijn
    Signed-off-by: David S. Miller

    Willem de Bruijn
     
  • If a VM is saved and restored (or migrated) the netback driver will no
    longer process any Tx packets from the frontend. xenvif_up() does not
    schedule the processing of any pending Tx requests from the front end
    because the carrier is off. Without this initial kick the frontend
    just adds Tx requests to the ring without raising an event (until the
    ring is full).

    This was caused by 47103041e91794acdbc6165da0ae288d844c820b (net:
    xen-netback: convert to hw_features) which reordered the calls to
    xenvif_up() and netif_carrier_on() in xenvif_connect().

    Signed-off-by: David Vrabel
    Cc: Ian Campbell
    Acked-by: Ian Campbell
    Signed-off-by: David S. Miller

    David Vrabel
     
  • During a test where a pair of bonding interfaces using ARP monitoring
    were both brought up and torn down (with an rmmod) repeatedly, a panic
    in the timer code was noticed. I tracked this down and determined that
    any of the bonding functions that ran as workqueue handlers and requeued
    more work might not properly exit when the module was removed.

    There was a flag protected by the bond lock called kill_timers that is
    set when the interface goes down or the module is removed, but many of
    the functions that monitor link status now unlock the bond lock to take
    rtnl first. There is a chance that another CPU running the rmmod could
    get the lock and set kill_timers after the first check has passed.

    This patch does not allow any function to queue work that will make
    itself run unless kill_timers is not set. I also noticed while doing
    this work that bond_resend_igmp_join_requests did not have a check for
    kill_timers, so I added the needed call there as well.

    Signed-off-by: Andy Gospodarek
    Reported-by: Liang Zheng
    Signed-off-by: David S. Miller

    Andy Gospodarek
     

30 Sep, 2011

3 commits

  • The commit aabdcb0b553b9c9547b1a506b34d55a764745870 ("can bcm: fix tx_setup
    off-by-one errors") fixed only a part of the original problem reported by
    Andre Naujoks. It turned out that the original code needed to be re-ordered
    to reduce complexity and to finally fix the reported frame counting issues.

    Signed-off-by: Oliver Hartkopp
    Signed-off-by: David S. Miller

    Oliver Hartkopp
     
  • In the rds_iw_mr_pool struct the free_pinned field keeps track of
    memory pinned by free MRs. While this field is incremented properly
    upon allocation, it is never decremented upon unmapping. This would
    cause the rds_rdma module to crash the kernel upon unloading, by
    triggering the BUG_ON in the rds_iw_destroy_mr_pool function.

    This change keeps track of the MRs that become unpinned, so that
    free_pinned can be decremented appropriately.

    Signed-off-by: Jonathan Lallinger
    Signed-off-by: Steve Wise
    Signed-off-by: David S. Miller

    Jonathan Lallinger
     
  • Signed-off-by: Roy.Li
    Signed-off-by: David S. Miller

    Roy.Li
     

29 Sep, 2011

8 commits

  • If request_irq fails, the ibmveth driver will overwrite
    the rc and end up returning a successful rc on its open
    function, resulting in an oops later when a packet gets
    sent and buffers are not allocated due to the failed open.

    Signed-off-by: Brian King
    Signed-off-by: David S. Miller

    Brian King
     
  • ipv6_ac_list and ipv6_fl_list from listening socket are inadvertently
    shared with new socket created for connection.

    Signed-off-by: Zheng Yan
    Signed-off-by: David S. Miller

    Yan, Zheng
     
  • Fix EEH recovery on new P Series platform by
    requesting fundamental reset.

    Signed-off-by: Divy Le Ray
    Signed-off-by: David S. Miller

    Divy Le Ray
     
  • This patch fixes two off-by-one errors that canceled each other out.
    Checking for the same condition two times in bcm_tx_timeout_tsklet() reduced
    the count of frames to be sent by one. This did not show up the first time
    tx_setup is invoked as an additional frame is sent due to TX_ANNONCE.
    Invoking a second tx_setup on the same item led to a reduced (by 1) number of
    sent frames.

    Reported-by: Andre Naujoks
    Signed-off-by: Oliver Hartkopp
    Signed-off-by: David S. Miller

    Oliver Hartkopp
     
  • I got:
    Generating server: Tehuti.onmicrosoft.com

    baum@tehutinetworks.net
    #< #5.1.1 smtp;550 5.1.1 RESOLVER.ADR.RecipNotFound; not found> #SMTP#

    Signed-off-by: Ian Campbell
    Cc: Alexander Indenbaum
    Cc: Andy Gospodarek
    Cc: Andrew Morton
    Cc: netdev@vger.kernel.org
    Signed-off-by: David S. Miller

    Ian Campbell
     
  • The driver has two warning messages that might be triggered
    by normal use cases. When they appear, the messages give the
    impression of a never ending series of errors.

    This commit changes them to debug messages instead.

    Signed-off-by: Richard Cochran
    Signed-off-by: David S. Miller

    Richard Cochran
     
  • The IEEE 1588 standard defines two kinds of messages, event and general
    messages. Event messages require time stamping, and general do not. When
    using UDP transport, two separate ports are used for the two message
    types.

    The BPF designed to recognize event messages incorrectly classifies L2
    general messages as event messages. This commit fixes the issue by
    extending the filter to check the message type field for L2 PTP packets.
    Event messages are be distinguished from general messages by testing
    the "general" bit.

    Signed-off-by: Richard Cochran
    Cc:
    Signed-off-by: David S. Miller

    Richard Cochran
     
  • Doing it just before starting to call into cpu_idle() made a sick kind
    of sense only because the original bug we fixed (see commit
    288d5abec831: "Boot up with usermodehelper disabled") was about problems
    with some scheduler data structures not being initialized, and they had
    better be initialized at that point.

    But it really didn't make any other conceptual sense, and doing it after
    the initial "schedule()" call for the idle thread actually opened up a
    race: what if the main initialization thread did everything without
    needing to sleep, and got all the way into user land too? Without
    actually having scheduled back to the idle thread?

    Now, in normal circumstances that doesn't ever happen, but it looks like
    Richard Cochran triggered exactly that on his ARM IXP4xx machines:

    "I have some ARM IXP4xx based machines that use the two on chip MAC
    ports (aka NPEs). The NPE needs a firmware in order to function.
    Ever since the following commit [that 288d5abec831 one], it is no
    longer possible to bring up the interfaces during the init scripts."

    with a call trace showing an ioctl coming from user space. Richard says:

    "The init is busybox, and the startup script does mount, syslogd, and
    then ifup, so that all can go by quickly."

    The fix is to move the usermodehelper_enable() into the main 'init'
    thread, and just put it after we've done all our initcalls. By then,
    everything really should be up, but we've obviously not actually started
    the user-mode portion of init yet.

    Reported-and-tested-by: Richard Cochran
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

28 Sep, 2011

20 commits


27 Sep, 2011

6 commits

  • That flag no longer makes sense, since we don't look up automount points
    as eagerly any more. Additionally, it turns out that the NO_AUTOMOUNT
    handling was buggy to begin with: it would avoid automounting even for
    cases where we really *needed* to do the automount handling, and could
    return ENOENT for autofs entries that hadn't been instantiated yet.

    With our new non-eager automount semantics, one discussion has been
    about adding a AT_AUTOMOUNT flag to vfs_fstatat (and thus the
    newfstatat() and fstatat64() system calls), but it's probably not worth
    it: you can always force at least directory automounting by simply
    adding the final '/' to the filename, which works for *all* of the stat
    family system calls, old and new.

    So AT_NO_AUTOMOUNT (and thus LOOKUP_NO_AUTOMOUNT) really were just a
    result of our bad default behavior.

    Acked-by: Ian Kent
    Acked-by: Trond Myklebust
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • Currently the the internal oscillator is powered down when entering BIAS_OFF
    state, but not re-enabled when going back to BIAS_STANDBY. As a result the
    CODEC will stop working after suspend if the internal oscillator is used to
    generate the sysclock signal. This patch fixes it by clearing the appropriate
    bit in the power down register when the CODEC is re-enabled.

    Signed-off-by: Lars-Peter Clausen
    Signed-off-by: Mark Brown
    Cc: stable@kernel.org

    Lars-Peter Clausen
     
  • The concensus seems to be that system calls such as stat() etc should
    not trigger an automount. Neither should the l* versions.

    This patch therefore adds a LOOKUP_AUTOMOUNT flag to tag those lookups
    that _should_ trigger an automount on the last path element.

    Signed-off-by: Trond Myklebust
    [ Edited to leave out the cases that are already covered by LOOKUP_OPEN,
    LOOKUP_DIRECTORY and LOOKUP_CREATE - all of which also fundamentally
    force automounting for their own reasons - Linus ]
    Signed-off-by: Linus Torvalds

    Trond Myklebust
     
  • Since we've now turned around and made LOOKUP_FOLLOW *not* force an
    automount, we want to add the ability to force an automount event on
    lookup even if we don't happen to have one of the other flags that force
    it implicitly (LOOKUP_OPEN, LOOKUP_DIRECTORY, LOOKUP_PARENT..)

    Most cases will never want to use this, since you'd normally want to
    delay automounting as long as possible, which usually implies
    LOOKUP_OPEN (when we open a file or directory, we really cannot avoid
    the automount any more).

    But Trond argued sufficiently forcefully that at a minimum bind mounting
    a file and quotactl will want to force the automount lookup. Some other
    cases (like nfs_follow_remote_path()) could use it too, although
    LOOKUP_DIRECTORY would work there as well.

    This commit just adds the flag and logic, no users yet, though. It also
    doesn't actually touch the LOOKUP_NO_AUTOMOUNT flag that is related, and
    was made irrelevant by the same change that made us not follow on
    LOOKUP_FOLLOW.

    Cc: Trond Myklebust
    Cc: Ian Kent
    Cc: Jeff Layton
    Cc: Miklos Szeredi
    Cc: David Howells
    Cc: Al Viro
    Cc: Greg KH
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • * 'samsung-fixes-3' of git://github.com/kgene/linux-samsung:
    ARM: EXYNOS4: Rename sclk_cam clocks for FIMC driver
    ARM: S5PV210: Rename sclk_cam clocks for FIMC media driver
    ARM: S5P: fix incorrect loop iterator usage on gpio-interrupt
    ARM: S3C2443: Fix bit-reset in setrate of clk_armdiv

    Linus Torvalds
     
  • The sclk_cam clocks are now controlled by the top level FIMC media
    device driver bound to "s5p-fimc-md" platform device.
    Rename sclk_cam clocks so they accessible by the corresponding
    driver.

    Signed-off-by: Sylwester Nawrocki
    Signed-off-by: Kyungmin Park
    Signed-off-by: Kukjin Kim

    Sylwester Nawrocki