18 Jul, 2014

18 commits

  • The SCSI standard defines 64-bit values for LUNs, and large arrays
    employing large or hierarchical LUN numbers become more and more
    common.

    So update the linux SCSI stack to use 64-bit LUN numbers.

    Signed-off-by: Hannes Reinecke
    Reviewed-by: Christoph Hellwig
    Reviewed-by: Ewan Milne
    Signed-off-by: Christoph Hellwig

    Hannes Reinecke
     
  • Older HBAs are only capable of supporting 16-bit LUNs,
    so we need to make sure to adjust max_lun accordingly.

    Signed-off-by: Hannes Reinecke
    Acked-by: Chad Dupuis
    Reviewed-by: Ewan Milne
    Signed-off-by: Christoph Hellwig

    Hannes Reinecke
     
  • Sequential scan for more than 256 LUNs is very fragile as
    LUNs might not be numbered sequentially after that point.

    SAM revisions later than SCSI-3 impose a structure on
    LUNs larger than 256, making LUN numbers between 256
    and 16384 illegal.
    SCSI-3, however allows for plain 64-bit numbers with
    no internal structure.

    So restrict sequential LUN scan to 256 LUNs and add a
    new blacklist flag 'BLIST_SCSI3LUN' to scan up to
    max_lun devices.

    Signed-off-by: Hannes Reinecke
    Reviewed-by: Ewan Milne
    Signed-off-by: Christoph Hellwig

    Hannes Reinecke
     
  • Obsolete; either use 'max_lun' if the host supports only a
    limited number of LUNs or BLIST_NOLUN if the target has
    problems addressing more than one LUN.

    Signed-off-by: Hannes Reinecke
    Reviewed-by: Ewan Milne
    Signed-off-by: Christoph Hellwig

    Hannes Reinecke
     
  • This addresses a problem reported by Vaughan Cao concerning
    the correctness of the O_EXCL logic in the sg driver. POSIX
    doesn't defined O_EXCL semantics on devices but "allow only
    one open file descriptor at a time per sg device" is a rough
    definition. The sg driver's semantics have been to wait
    on an open() when O_NONBLOCK is not given and there are
    O_EXCL headwinds. Nasty things can happen during that wait
    such as the device being detached (removed). So multiple
    locks are reworked in this patch making it large and hard
    to break down into digestible bits.

    This patch is against Linus's current git repository which
    doesn't include any sg patches sent in the last few weeks.
    Hence this patch touches as little as possible that it
    doesn't need to and strips out most SCSI_LOG_TIMEOUT()
    changes in v3 because Hannes said he was going to rework all
    that stuff.

    The sg3_utils package has several test programs written to
    test this patch. See examples/sg_tst_excl*.cpp .

    Not all the locks and flags in sg have been re-worked in
    this patch, notably sg_request::done . That can wait for
    a follow-up patch if this one meets with approval.

    Signed-off-by: Douglas Gilbert
    Reviewed-by: Hannes Reinecke

    Douglas Gilbert
     
  • When the SG_IO ioctl was copied into the block layer and
    later into the bsg driver, subtle differences emerged.

    One difference is the way injected commands are queued through
    the block layer (i.e. this is not SCSI device queueing nor SATA
    NCQ). Summarizing:
    - SG_IO in the block layer: blk_exec*(at_head=false)
    - sg SG_IO: at_head=true
    - bsg SG_IO: at_head=true

    Some time ago Boaz Harrosh introduced a sg v4 flag called
    BSG_FLAG_Q_AT_TAIL to override the bsg driver default.
    This patch does the equivalent for the sg driver.

    ChangeLog:
    Introduce SG_FLAG_Q_AT_TAIL flag to cause commands
    to be injected into the block layer with
    at_head=false.

    Signed-off-by: Douglas Gilbert
    Reviewed-by: Mike Christie
    Reviewed-by: Ewan D. Milne
    Signed-off-by: Christoph Hellwig

    Douglas Gilbert
     
  • - remove the 16 byte CDB (SCSI command) length limit from the sg driver
    by handling longer CDBs the same way as the bsg driver. Remove comment
    from sg.h public interface about the cmd_len field being limited to 16
    bytes.
    - remove some dead code caused by this change
    - cleanup comment block at the top of sg.h, fix urls

    Signed-off-by: Douglas Gilbert
    Reviewed-by: Mike Christie
    Reviewed-by: Hannes Reinecke
    Signed-off-by: Christoph Hellwig

    Douglas Gilbert
     
  • Until now the per-command transfer length has exclusively been gated by
    the max_sectors parameter in the scsi_host template. Given that the size
    of this parameter has been bumped to an unsigned int we have to be
    careful not to exceed the target device's capabilities.

    If the if the device specifies a Maximum Transfer Length in the Block
    Limits VPD we'll use that value. Otherwise we'll use 0xffffffff for
    devices that have use_16_for_rw set and 0xffff for the rest. We then
    combine the chosen disk limit with max_sectors in the host template. The
    smaller of the two will be used to set the max_hw_sectors queue limit.

    Signed-off-by: Martin K. Petersen
    Reviewed-by: Ewan D. Milne
    Signed-off-by: Christoph Hellwig

    Martin K. Petersen
     
  • In init_sd function, if kmem_cache_create or mempool_create_slab_pools
    calls fail, the error will not be correclty reported because
    class_register previously set the value of err to 0.

    Signed-off-by: Clément Calmels
    Reviewed-by: Ewan D. Milne
    Signed-off-by: Christoph Hellwig

    Clément Calmels
     
  • This is a fix for commit 39c60a0948cc06139e2fbfe084f83cb7e7deae3b

    "sd: fix array cache flushing bug causing performance problems"

    We must notify the block layer via q->flush_flags after a temporary change
    of the cache_type to write through. Without this, a SYNCHRONIZE CACHE
    command will still be generated. This patch factors out a helper that
    can be called from sd_revalidate_disk and cache_type_store.

    Signed-off-by: Vaughan Cao
    Reviewed-by: Christoph Hellwig
    Signed-off-by: Christoph Hellwig

    Vaughan Cao
     
  • This change enables to test read/write commands with huge transfer
    length such as 1GB. For example:

    # modprobe scsi_debug dev_size_mb=1024 clustering=1 opts=1
    # cat /sys/block/$DEV/queue/max_hw_sectors_kb > \
    /sys/block/$DEV/queue/max_sectors_kb
    # fio --name=test --rw=write --bs=1g --size=1g --filename=/dev/$DEV \
    --mem=mmaphuge --direct=1

    The data type of max_sectors in scsi_host_template has been extended
    to unsigned int by the previous change. So we can increase it from
    0xffff to 0xffffffff to allow such huge transfer length.

    Also, this increases sg_tablesize and max_segment_size, otherwise the
    maximum transfer length is limited to 64MB.
    (sg_tablesize * max_segment_size = 256 * 256KB)

    Signed-off-by: Akinobu Mita
    Reviewed-by: Christoph Hellwig
    Reviewed-by: Martin K. Petersen
    Acked by: Douglas Gilbert
    Signed-off-by: Christoph Hellwig

    Akinobu Mita
     
  • max_sectors in struct Scsi_Host specifies maximum number of sectors
    allowed in a single SCSI command. The data type of max_sectors is
    unsigned short, so the maximum transfer length per SCSI command is
    limited to less than 256MB in 4096-bytes sector size. (0xffff * 4096)

    This commit increases the SCSI mid level's limitation for max_sectors
    upto the block layer's limitation for max_hw_sectors by extending the
    data type of max_sectors in struct Scsi_Host and scsi_host_template,
    so that SCSI lower level drivers can specify more than 0xffff.

    Signed-off-by: Akinobu Mita
    Reviewed-by: Martin K. Petersen
    Signed-off-by: Christoph Hellwig

    Akinobu Mita
     
  • This change makes the scsi disk driver handle the requests whose
    transfer length is greater than 0xffff with READ_16 or WRITE_16.

    However, this is a preparation for extending the data type of
    max_sectors in struct Scsi_Host and scsi_host_template. So, it is
    impossible to happen this condition for now, because SCSI low-level
    drivers can not specify max_sectors greater than 0xffff due to the
    data type limitation.

    Signed-off-by: Akinobu Mita
    Reviewed-by: Martin K. Petersen
    Signed-off-by: Christoph Hellwig

    Akinobu Mita
     
  • This prevents integer overflow when converting the request queue's
    max_sectors from sectors to bytes. However, this is a preparation for
    extending the data type of max_sectors in struct Scsi_Host and
    scsi_host_template. So, it is impossible to happen this integer
    overflow for now, because SCSI low-level drivers can not specify
    max_sectors greater than 0xffff due to the data type limitation.

    Signed-off-by: Akinobu Mita
    Acked by: Douglas Gilbert
    Signed-off-by: Christoph Hellwig

    Akinobu Mita
     
  • scsi_put_command() is either invoked before blk_start_request() or
    after block layer processing has completed. scsi_cmnd.abort_work
    is scheduled from inside the SCSI timeout handler. The block layer
    guarantees that either the regular completion handler
    (softirq_done_fn()) or the timeout handler (rq_timed_out_fn()) is
    invoked but not both. This means that scsi_put_command() is never
    invoked while abort_work is scheduled. Hence remove the
    cancel_delayed_work() call from scsi_put_command().

    Similarly, scsi_abort_command() is only invoked from the SCSI
    timeout handler. If scsi_abort_command() is invoked for a SCSI
    command with the SCSI_EH_ABORT_SCHEDULED flag set this means that
    scmd_eh_abort_handler() has already invoked scsi_queue_insert() and
    hence that scsi_cmnd.abort_work is no longer pending. Hence also
    remove the cancel_delayed_work() call from scsi_abort_command().

    Signed-off-by: Bart Van Assche
    Reviewed-by: Hannes Reinecke
    Signed-off-by: Christoph Hellwig

    Bart Van Assche
     
  • Flush commands don't transfer data and thus need to be special cased
    in the I/O completion handler so that we can propagate errors to
    the block layer and filesystem.

    Signed-off-by: James Bottomley
    Reported-by: Steven Haber
    Tested-by: Steven Haber
    Reviewed-by: Martin K. Petersen
    Cc: stable@vger.kernel.org
    Signed-off-by: Christoph Hellwig

    James Bottomley
     
  • Pull Xen fixes from Konrad Rzeszutek Wilk:
    "Two fixes found during migration of PV guests. David would be the one
    doing this pull but he is on vacation.

    Fixes:
    - fix console deadlock when resuming PV guests
    - fix regression hit when ballooning and resuming PV guests"

    * tag 'stable/for-linus-3.16-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
    xen/balloon: set ballooned out pages as invalid in p2m
    xen/manage: fix potential deadlock when resuming the console

    Linus Torvalds
     
  • …l/git/rostedt/linux-trace

    Pull tracing fixes from Steven Rostedt:
    "A few more fixes for ftrace infrastructure.

    I was cleaning out my INBOX and found two fixes from zhangwei from a
    year ago that were lost in my mail. These fix an inconsistency
    between trace_puts() and the way trace_printk() works. The reason
    this is important to fix is because when trace_printk() doesn't have
    any arguments, it turns into a trace_puts(). Not being able to enable
    a stack trace against trace_printk() because it does not have any
    arguments is quite confusing. Also, the fix is rather trivial and low
    risk.

    While porting some changes to PowerPC I discovered that it still has
    the function graph tracer filter bug that if you also enable stack
    tracing the function graph tracer filter is ignored. I fixed that up.

    Finally, Martin Lau, fixed a bug that would cause readers of the
    ftrace ring buffer to block forever even though it was suppose to be
    NONBLOCK"

    This also includes the fix from an earlier pull request:

    "Oleg Nesterov fixed a memory leak that happens if a user creates a
    tracing instance, sets up a filter in an event, and then removes that
    instance. The filter allocates memory that is never freed when the
    instance is destroyed"

    * tag 'trace-fixes-v3.16-rc5-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
    ring-buffer: Fix polling on trace_pipe
    tracing: Add TRACE_ITER_PRINTK flag check in __trace_puts/__trace_bputs
    tracing: Fix graph tracer with stack tracer on other archs
    tracing: Add ftrace_trace_stack into __trace_puts/__trace_bputs
    tracing: instance_rmdir() leaks ftrace_event_file->filter

    Linus Torvalds
     

17 Jul, 2014

4 commits


16 Jul, 2014

4 commits

  • Pull quota fix from Jan Kara:
    "Fix locking of dquot shrinker"

    * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
    quota: missing lock in dqcache_shrink_scan()

    Linus Torvalds
     
  • Pull GPIO fix from Linus Walleij:
    "Fix up some merge confusion from the merge window"

    * tag 'gpio-v3.16-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
    gpio: mcp23s08: Eliminates redundant checking.

    Linus Torvalds
     
  • ring_buffer_poll_wait() should always put the poll_table to its wait_queue
    even there is immediate data available. Otherwise, the following epoll and
    read sequence will eventually hang forever:

    1. Put some data to make the trace_pipe ring_buffer read ready first
    2. epoll_ctl(efd, EPOLL_CTL_ADD, trace_pipe_fd, ee)
    3. epoll_wait()
    4. read(trace_pipe_fd) till EAGAIN
    5. Add some more data to the trace_pipe ring_buffer
    6. epoll_wait() -> this epoll_wait() will block forever

    ~ During the epoll_ctl(efd, EPOLL_CTL_ADD,...) call in step 2,
    ring_buffer_poll_wait() returns immediately without adding poll_table,
    which has poll_table->_qproc pointing to ep_poll_callback(), to its
    wait_queue.
    ~ During the epoll_wait() call in step 3 and step 6,
    ring_buffer_poll_wait() cannot add ep_poll_callback() to its wait_queue
    because the poll_table->_qproc is NULL and it is how epoll works.
    ~ When there is new data available in step 6, ring_buffer does not know
    it has to call ep_poll_callback() because it is not in its wait queue.
    Hence, block forever.

    Other poll implementation seems to call poll_wait() unconditionally as the very
    first thing to do. For example, tcp_poll() in tcp.c.

    Link: http://lkml.kernel.org/p/20140610060637.GA14045@devbig242.prn2.facebook.com

    Cc: stable@vger.kernel.org # 2.6.27
    Fixes: 2a2cc8f7c4d0 "ftrace: allow the event pipe to be polled"
    Reviewed-by: Chris Mason
    Signed-off-by: Martin Lau
    Signed-off-by: Steven Rostedt

    Martin Lau
     
  • Commit 1ab6c4997e04 (fs: convert fs shrinkers to new scan/count API)
    accidentally removed locking from quota shrinker. Fix it -
    dqcache_shrink_scan() should use dq_list_lock to protect the
    scan on free_dquots list.

    CC: stable@vger.kernel.org
    Fixes: 1ab6c4997e04a00c50c6d786c2f046adc0d1f5de
    Signed-off-by: Niu Yawei
    Signed-off-by: Jan Kara

    Niu Yawei
     

15 Jul, 2014

14 commits

  • The TRACE_ITER_PRINTK check in __trace_puts/__trace_bputs is missing,
    so add it, to be consistent with __trace_printk/__trace_bprintk.
    Those functions are all called by the same function: trace_printk().

    Link: http://lkml.kernel.org/p/51E7A7D6.8090900@huawei.com

    Cc: stable@vger.kernel.org # 3.11+
    Signed-off-by: zhangwei(Jovi)
    Signed-off-by: Steven Rostedt

    zhangwei(Jovi)
     
  • Pull fuse fixes from Miklos Szeredi:
    "This contains miscellaneous fixes"

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse:
    fuse: replace count*size kzalloc by kcalloc
    fuse: release temporary page if fuse_writepage_locked() failed
    fuse: restructure ->rename2()
    fuse: avoid scheduling while atomic
    fuse: handle large user and group ID
    fuse: inode: drop cast
    fuse: ignore entry-timeout on LOOKUP_REVAL
    fuse: timeout comparison fix

    Linus Torvalds
     
  • Pull networking fixes from David Miller:

    1) Bluetooth pairing fixes from Johan Hedberg.

    2) ieee80211_send_auth() doesn't allocate enough tail room for the SKB,
    from Max Stepanov.

    3) New iwlwifi chip IDs, from Oren Givon.

    4) bnx2x driver reads wrong PCI config space MSI register, from Yijing
    Wang.

    5) IPV6 MLD Query validation isn't strong enough, from Hangbin Liu.

    6) Fix double SKB free in openvswitch, from Andy Zhou.

    7) Fix sk_dst_set() being racey with UDP sockets, leading to strange
    crashes, from Eric Dumazet.

    8) Interpret the NAPI budget correctly in the new systemport driver,
    from Florian Fainelli.

    9) VLAN code frees percpu stats in the wrong place, leading to crashes
    in the get stats handler. From Eric Dumazet.

    10) TCP sockets doing a repair can crash with a divide by zero, because
    we invoke tcp_push() with an MSS value of zero. Just skip that part
    of the sendmsg paths in repair mode. From Christoph Paasch.

    11) IRQ affinity bug fixes in mlx4 driver from Amir Vadai.

    12) Don't ignore path MTU icmp messages with a zero mtu, machines out
    there still spit them out, and all of our per-protocol handlers for
    PMTU can cope with it just fine. From Edward Allcutt.

    13) Some NETDEV_CHANGE notifier invocations were not passing in the
    correct kind of cookie as the argument, from Loic Prylli.

    14) Fix crashes in long multicast/broadcast reassembly, from Jon Paul
    Maloy.

    15) ip_tunnel_lookup() doesn't interpret wildcard keys correctly, fix
    from Dmitry Popov.

    16) Fix skb->sk assigned without taking a reference to 'sk' in
    appletalk, from Andrey Utkin.

    17) Fix some info leaks in ULP event signalling to userspace in SCTP,
    from Daniel Borkmann.

    18) Fix deadlocks in HSO driver, from Olivier Sobrie.

    * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (93 commits)
    hso: fix deadlock when receiving bursts of data
    hso: remove unused workqueue
    net: ppp: don't call sk_chk_filter twice
    mlx4: mark napi id for gro_skb
    bonding: fix ad_select module param check
    net: pppoe: use correct channel MTU when using Multilink PPP
    neigh: sysctl - simplify address calculation of gc_* variables
    net: sctp: fix information leaks in ulpevent layer
    MAINTAINERS: update r8169 maintainer
    net: bcmgenet: fix RGMII_MODE_EN bit
    tipc: clear 'next'-pointer of message fragments before reassembly
    r8152: fix r8152_csum_workaround function
    be2net: set EQ DB clear-intr bit in be_open()
    GRE: enable offloads for GRE
    farsync: fix invalid memory accesses in fst_add_one() and fst_init_card()
    igb: do a reset on SR-IOV re-init if device is down
    igb: Workaround for i210 Errata 25: Slow System Clock
    usbnet: smsc95xx: add reset_resume function with reset operation
    dp83640: Always decode received status frames
    r8169: disable L23
    ...

    Linus Torvalds
     
  • Running my ftrace tests on PowerPC, it failed the test that checks
    if function_graph tracer is affected by the stack tracer. It was.
    Looking into this, I found that the update_function_graph_func()
    must be called even if the trampoline function is not changed.
    This is because archs like PowerPC do not support ftrace_ops being
    passed by assembly and instead uses a helper function (what the
    trampoline function points to). Since this function is not changed
    even when multiple ftrace_ops are added to the code, the test that
    falls out before calling update_function_graph_func() will miss that
    the update must still be done.

    Call update_function_graph_function() for all calls to
    update_ftrace_function()

    Cc: stable@vger.kernel.org # 3.3+
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)
     
  • Currently trace option stacktrace is not applicable for
    trace_printk with constant string argument, the reason is
    in __trace_puts/__trace_bputs ftrace_trace_stack is missing.

    In contrast, when using trace_printk with non constant string
    argument(will call into __trace_printk/__trace_bprintk), then
    trace option stacktrace is workable, this inconstant result
    will confuses users a lot.

    Link: http://lkml.kernel.org/p/51E7A7C9.9040401@huawei.com

    Cc: stable@vger.kernel.org # 3.10+
    Signed-off-by: zhangwei(Jovi)
    Signed-off-by: Steven Rostedt

    zhangwei(Jovi)
     
  • When the initialization of Intel HDMI controller fails due to missing
    i915 kernel symbols (e.g. HD-audio is built in while i915 is module),
    the driver discontinues the probe. However, since the probe was done
    asynchronously, the driver object still remains, thus the relevant PM
    ops are still called at suspend/resume. This results in the bad access
    to the incomplete audio card object, eventually leads to Oops or stall
    at PM.

    This patch adds the missing checks of chip->init_failed flag at each
    PM callback in order to fix the problem above.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79561
    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     
  • When the module sends bursts of data, sometimes a deadlock happens in
    the hso driver when the tty buffer doesn't get the chance to be flushed
    quickly enough.

    Remove the endless while loop in function put_rxbuf_data() which is
    called by the urb completion handler.
    If there isn't enough room in the tty buffer, discards all the data
    received in the URB.

    Cc: David Miller
    Cc: David Laight
    Cc: One Thousand Gnomes
    Cc: Dan Williams
    Cc: Jan Dumon
    Signed-off-by: Olivier Sobrie
    Acked-by: Alan Cox
    Signed-off-by: David S. Miller

    Olivier Sobrie
     
  • The workqueue "retry_unthrottle_workqueue" is not scheduled anywhere
    in the code. So, remove it.

    Signed-off-by: Olivier Sobrie
    Signed-off-by: David S. Miller

    Olivier Sobrie
     
  • Pull firewire fix from Stefan Richter:
    "The 1394 drivers cannot and are not supposed to be built on platforms
    which don't provide the DMA mapping API (regression since v3.16-rc1
    with CONFIG_COMPILE_TEST=y on some architectures)"

    * tag 'firewire-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
    firewire: IEEE 1394 (FireWire) support should depend on HAS_DMA

    Linus Torvalds
     
  • Pull another aio fix from Ben LaHaise:
    "put_reqs_available() can now be called from within irq context, which
    means that it (and its sibling function get_reqs_available()) now need
    to be irq-safe, not just preempt-safe"

    * git://git.kvack.org/~bcrl/aio-fixes:
    aio: protect reqs_available updates from changes in interrupt handlers

    Linus Torvalds
     
  • The l2tp [get|set]sockopt() code has fallen back to the UDP functions
    for socket option levels != SOL_PPPOL2TP since day one, but that has
    never actually worked, since the l2tp socket isn't an inet socket.

    As David Miller points out:

    "If we wanted this to work, it'd have to look up the tunnel and then
    use tunnel->sk, but I wonder how useful that would be"

    Since this can never have worked so nobody could possibly have depended
    on that functionality, just remove the broken code and return -EINVAL.

    Reported-by: Sasha Levin
    Acked-by: James Chapman
    Acked-by: David Miller
    Cc: Phil Turnbull
    Cc: Vegard Nossum
    Cc: Willy Tarreau
    Cc: stable@vger.kernel.org
    Signed-off-by: Linus Torvalds

    Sasha Levin
     
  • Commit 568f194e8bd16c353ad50f9ab95d98b20578a39d ("net: ppp: use
    sk_unattached_filter api") causes sk_chk_filter() to be called twice when
    setting a PPP pass or active filter. This applies to both the generic PPP
    subsystem implemented by drivers/net/ppp/ppp_generic.c and the ISDN PPP
    subsystem implemented by drivers/isdn/i4l/isdn_ppp.c. The first call is from
    within get_filter(). The second one is through the call chain

    ppp_ioctl() or isdn_ppp_ioctl()
    --> sk_unattached_filter_create()
    --> __sk_prepare_filter()
    --> sk_chk_filter()

    The first call from within get_filter() should be deleted as get_filter() is
    called just before calling sk_unattached_filter_create() later on, which
    eventually calls sk_chk_filter() anyway.

    For 3.15.x, this proposed change is a bugfix rather than a pure optimization as
    in that branch, sk_chk_filter() may replace filter codes by other codes which
    are not recognized when executing sk_chk_filter() a second time. So with
    3.15.x, if sk_chk_filter() is called twice, the second invocation may yield
    EINVAL (this depends on the filter codes found in the filter to be set, but
    because the replacement is done for frequently used codes, this is almost
    always the case). The net effect is that setting pass and/or active PPP filters
    does not work anymore, since sk_unattached_filter_create() always returns
    EINVAL due to the second call to sk_chk_filter(), regardless whether the filter
    was originally sane or not.

    Signed-off-by: Christoph Schulz
    Acked-by: Daniel Borkmann
    Signed-off-by: David S. Miller

    Christoph Schulz
     
  • Napi id was not marked for gro_skb, this will lead rx busy loop won't
    work correctly since they stack never try to call low latency receive
    method because of a zero socket napi id. Fix this by marking napi id
    for gro_skb.

    The transaction rate of 1 byte netperf tcp_rr gets about 50% increased
    (from 20531.68 to 30610.88).

    Cc: Amir Vadai
    Signed-off-by: Jason Wang
    Signed-off-by: David S. Miller

    Jason Wang
     
  • Obvious copy/paste error when I converted the ad_select to the new
    option API. "lacp_rate" there should be "ad_select" so we can get the
    proper value.

    CC: Jay Vosburgh
    CC: Veaceslav Falico
    CC: Andy Gospodarek
    CC: David S. Miller

    Fixes: 9e5f5eebe765 ("bonding: convert ad_select to use the new option
    API")
    Reported-by: Karim Scheik
    Signed-off-by: Nikolay Aleksandrov
    Signed-off-by: David S. Miller

    Nikolay Aleksandrov