1. 12 Mar, 2015 17 commits
  2. 11 Mar, 2015 1 commit
  3. 04 Mar, 2015 3 commits
  4. 03 Mar, 2015 17 commits
  5. 02 Mar, 2015 2 commits
    • Hans de Goede's avatar
      ideapad-laptop: Change Lenovo Yoga 2 series rfkill handling · f58ad536
      Hans de Goede authored
      commit ce363c2b upstream.
      
      It seems that the same problems which lead to adding an rfkill blacklist and
      putting the Lenovo Yoga 2 11 on it are also present on the Lenovo Yoga 2 13
      and Lenovo Yoga 2 Pro too:
      https://bugzilla.redhat.com/show_bug.cgi?id=1021036
      https://forums.lenovo.com/t5/Linux-Discussion/Yoga-2-13-not-Pro-Linux-Warning/m-p/1517612
      
      Testing has shown that the firmware rfkill settings are persistent over
      reboots. So blacklisting the driver is not good enough, if the wifi is blocked
      at the firmware level the wifi needs to be explictly unblocked through the
      ideapad-laptop interface.
      
      And at least on the Lenovo Yoga 2 13 the VPCCMD_RF register which on devices
      with hardware kill switch reports the hardware switch state, needs to be
      explictly set to 1 (radio enabled / not blocked).
      
      So this patch does 3 things to get proper rfkill handling on these models:
      
      1) Instead of blacklisting the rfkill functionality, which means that people
      with a firmware blocked wifi get stuck in that situation, ignore the value
      reported by the not present hardware rfkill switch, as this is what is causing
      ideapad-laptop to wrongly report all radios as hardware blocks. But do register
      the rfkill interfaces so that the user can soft [un]block them.
      
      2) On models without a hardware rfkill switch, explictly set VPCCMD_RF to 1
      
      3) Drop the " 11" postfix from the dmi match string, as the entire Yoga 2
      series is affected.
      
      Yoga 2 11:
      Reported-and-tested-by: default avatarVincent Gerris <vgerris@gmail.com>
      
      Yoga 2 13:
      Tested-by: madls05 <http://ubuntuforums.org/showthread.php?t=2215044>
      
      Yoga 2 Pro:
      Reported-and-tested-by: default avatarPeter F. Patel-Schneider <pfpschneider@gmail.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarMatthew Garrett <matthew.garrett@nebula.com>
      Cc: Gaudenz Steinlin <gaudenz@debian.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f58ad536
    • Daniel Borkmann's avatar
      ipv6: mld: fix add_grhead skb_over_panic for devs with large MTUs · c562e7c8
      Daniel Borkmann authored
      commit 4c672e4b upstream.
      
      It has been reported that generating an MLD listener report on
      devices with large MTUs (e.g. 9000) and a high number of IPv6
      addresses can trigger a skb_over_panic():
      
      skbuff: skb_over_panic: text:ffffffff80612a5d len:3776 put:20
      head:ffff88046d751000 data:ffff88046d751010 tail:0xed0 end:0xec0
      dev:port1
       ------------[ cut here ]------------
      kernel BUG at net/core/skbuff.c:100!
      invalid opcode: 0000 [#1] SMP
      Modules linked in: ixgbe(O)
      CPU: 3 PID: 0 Comm: swapper/3 Tainted: G O 3.14.23+ #4
      [...]
      Call Trace:
       <IRQ>
       [<ffffffff80578226>] ? skb_put+0x3a/0x3b
       [<ffffffff80612a5d>] ? add_grhead+0x45/0x8e
       [<ffffffff80612e3a>] ? add_grec+0x394/0x3d4
       [<ffffffff80613222>] ? mld_ifc_timer_expire+0x195/0x20d
       [<ffffffff8061308d>] ? mld_dad_timer_expire+0x45/0x45
       [<ffffffff80255b5d>] ? call_timer_fn.isra.29+0x12/0x68
       [<ffffffff80255d16>] ? run_timer_softirq+0x163/0x182
       [<ffffffff80250e6f>] ? __do_softirq+0xe0/0x21d
       [<ffffffff8025112b>] ? irq_exit+0x4e/0xd3
       [<ffffffff802214bb>] ? smp_apic_timer_interrupt+0x3b/0x46
       [<ffffffff8063f10a>] ? apic_timer_interrupt+0x6a/0x70
      
      mld_newpack() skb allocations are usually requested with dev->mtu
      in size, since commit 72e09ad1 ("ipv6: avoid high order allocations")
      we have changed the limit in order to be less likely to fail.
      
      However, in MLD/IGMP code, we have some rather ugly AVAILABLE(skb)
      macros, which determine if we may end up doing an skb_put() for
      adding another record. To avoid possible fragmentation, we check
      the skb's tailroom as skb->dev->mtu - skb->len, which is a wrong
      assumption as the actual max allocation size can be much smaller.
      
      The IGMP case doesn't have this issue as commit 57e1ab6e
      ("igmp: refine skb allocations") stores the allocation size in
      the cb[].
      
      Set a reserved_tailroom to make it fit into the MTU and use
      skb_availroom() helper instead. This also allows to get rid of
      igmp_skb_size().
      Reported-by: default avatarWei Liu <lw1a2.jing@gmail.com>
      Fixes: 72e09ad1 ("ipv6: avoid high order allocations")
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Cc: David L Stevens <david.stevens@oracle.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c562e7c8