1. 07 Jul, 2015 14 commits
  2. 06 Jul, 2015 1 commit
  3. 30 Jun, 2015 6 commits
  4. 22 Jun, 2015 1 commit
  5. 18 Jun, 2015 1 commit
  6. 17 Jun, 2015 17 commits
    • Shawn Bohrer's avatar
      ipv4/udp: Verify multicast group is ours in upd_v4_early_demux() · 7af6649d
      Shawn Bohrer authored
      [ Upstream commit 6e540309 ]
      
      421b3885 "udp: ipv4: Add udp early
      demux" introduced a regression that allowed sockets bound to INADDR_ANY
      to receive packets from multicast groups that the socket had not joined.
      For example a socket that had joined 224.168.2.9 could also receive
      packets from 225.168.2.9 despite not having joined that group if
      ip_early_demux is enabled.
      
      Fix this by calling ip_check_mc_rcu() in udp_v4_early_demux() to verify
      that the multicast packet is indeed ours.
      Signed-off-by: default avatarShawn Bohrer <sbohrer@rgmadvisors.com>
      Reported-by: default avatarYurij M. Plotnikov <Yurij.Plotnikov@oktetlabs.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7af6649d
    • Ian Campbell's avatar
      xen: netback: read hotplug script once at start of day. · 3540c634
      Ian Campbell authored
      [ Upstream commit 31a41898 ]
      
      When we come to tear things down in netback_remove() and generate the
      uevent it is possible that the xenstore directory has already been
      removed (details below).
      
      In such cases netback_uevent() won't be able to read the hotplug
      script and will write a xenstore error node.
      
      A recent change to the hypervisor exposed this race such that we now
      sometimes lose it (where apparently we didn't ever before).
      
      Instead read the hotplug script configuration during setup and use it
      for the lifetime of the backend device.
      
      The apparently more obvious fix of moving the transition to
      state=Closed in netback_remove() to after the uevent does not work
      because it is possible that we are already in state=Closed (in
      reaction to the guest having disconnected as it shutdown). Being
      already in Closed means the toolstack is at liberty to start tearing
      down the xenstore directories. In principal it might be possible to
      arrange to unregister the device sooner (e.g on transition to Closing)
      such that xenstore would still be there but this state machine is
      fragile and prone to anger...
      
      A modern Xen system only relies on the hotplug uevent for driver
      domains, when the backend is in the same domain as the toolstack it
      will run the necessary setup/teardown directly in the correct sequence
      wrt xenstore changes.
      Signed-off-by: default avatarIan Campbell <ian.campbell@citrix.com>
      Acked-by: default avatarWei Liu <wei.liu2@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      3540c634
    • Eric Dumazet's avatar
      udp: fix behavior of wrong checksums · fcff4119
      Eric Dumazet authored
      [ Upstream commit beb39db5 ]
      
      We have two problems in UDP stack related to bogus checksums :
      
      1) We return -EAGAIN to application even if receive queue is not empty.
         This breaks applications using edge trigger epoll()
      
      2) Under UDP flood, we can loop forever without yielding to other
         processes, potentially hanging the host, especially on non SMP.
      
      This patch is an attempt to make things better.
      
      We might in the future add extra support for rt applications
      wanting to better control time spent doing a recv() in a hostile
      environment. For example we could validate checksums before queuing
      packets in socket receive queue.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      fcff4119
    • WANG Cong's avatar
      net_sched: invoke ->attach() after setting dev->qdisc · 543cfe7a
      WANG Cong authored
      [ Upstream commit 86e363dc ]
      
      For mq qdisc, we add per tx queue qdisc to root qdisc
      for display purpose, however, that happens too early,
      before the new dev->qdisc is finally set, this causes
      q->list points to an old root qdisc which is going to be
      freed right before assigning with a new one.
      
      Fix this by moving ->attach() after setting dev->qdisc.
      
      For the record, this fixes the following crash:
      
       ------------[ cut here ]------------
       WARNING: CPU: 1 PID: 975 at lib/list_debug.c:59 __list_del_entry+0x5a/0x98()
       list_del corruption. prev->next should be ffff8800d1998ae8, but was 6b6b6b6b6b6b6b6b
       CPU: 1 PID: 975 Comm: tc Not tainted 4.1.0-rc4+ #1019
       Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
        0000000000000009 ffff8800d73fb928 ffffffff81a44e7f 0000000047574756
        ffff8800d73fb978 ffff8800d73fb968 ffffffff810790da ffff8800cfc4cd20
        ffffffff814e725b ffff8800d1998ae8 ffffffff82381250 0000000000000000
       Call Trace:
        [<ffffffff81a44e7f>] dump_stack+0x4c/0x65
        [<ffffffff810790da>] warn_slowpath_common+0x9c/0xb6
        [<ffffffff814e725b>] ? __list_del_entry+0x5a/0x98
        [<ffffffff81079162>] warn_slowpath_fmt+0x46/0x48
        [<ffffffff81820eb0>] ? dev_graft_qdisc+0x5e/0x6a
        [<ffffffff814e725b>] __list_del_entry+0x5a/0x98
        [<ffffffff814e72a7>] list_del+0xe/0x2d
        [<ffffffff81822f05>] qdisc_list_del+0x1e/0x20
        [<ffffffff81820cd1>] qdisc_destroy+0x30/0xd6
        [<ffffffff81822676>] qdisc_graft+0x11d/0x243
        [<ffffffff818233c1>] tc_get_qdisc+0x1a6/0x1d4
        [<ffffffff810b5eaf>] ? mark_lock+0x2e/0x226
        [<ffffffff817ff8f5>] rtnetlink_rcv_msg+0x181/0x194
        [<ffffffff817ff72e>] ? rtnl_lock+0x17/0x19
        [<ffffffff817ff72e>] ? rtnl_lock+0x17/0x19
        [<ffffffff817ff774>] ? __rtnl_unlock+0x17/0x17
        [<ffffffff81855dc6>] netlink_rcv_skb+0x4d/0x93
        [<ffffffff817ff756>] rtnetlink_rcv+0x26/0x2d
        [<ffffffff818544b2>] netlink_unicast+0xcb/0x150
        [<ffffffff81161db9>] ? might_fault+0x59/0xa9
        [<ffffffff81854f78>] netlink_sendmsg+0x4fa/0x51c
        [<ffffffff817d6e09>] sock_sendmsg_nosec+0x12/0x1d
        [<ffffffff817d8967>] sock_sendmsg+0x29/0x2e
        [<ffffffff817d8cf3>] ___sys_sendmsg+0x1b4/0x23a
        [<ffffffff8100a1b8>] ? native_sched_clock+0x35/0x37
        [<ffffffff810a1d83>] ? sched_clock_local+0x12/0x72
        [<ffffffff810a1fd4>] ? sched_clock_cpu+0x9e/0xb7
        [<ffffffff810def2a>] ? current_kernel_time+0xe/0x32
        [<ffffffff810b4bc5>] ? lock_release_holdtime.part.29+0x71/0x7f
        [<ffffffff810ddebf>] ? read_seqcount_begin.constprop.27+0x5f/0x76
        [<ffffffff810b6292>] ? trace_hardirqs_on_caller+0x17d/0x199
        [<ffffffff811b14d5>] ? __fget_light+0x50/0x78
        [<ffffffff817d9808>] __sys_sendmsg+0x42/0x60
        [<ffffffff817d9838>] SyS_sendmsg+0x12/0x1c
        [<ffffffff81a50e97>] system_call_fastpath+0x12/0x6f
       ---[ end trace ef29d3fb28e97ae7 ]---
      
      For long term, we probably need to clean up the qdisc_graft() code
      in case it hides other bugs like this.
      
      Fixes: 95dc1929 ("pkt_sched: give visibility to mq slave qdiscs")
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      543cfe7a
    • Mark Salyzyn's avatar
      unix/caif: sk_socket can disappear when state is unlocked · 29d01d68
      Mark Salyzyn authored
      [ Upstream commit b48732e4 ]
      
      got a rare NULL pointer dereference in clear_bit
      Signed-off-by: default avatarMark Salyzyn <salyzyn@android.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      ----
      v2: switch to sock_flag(sk, SOCK_DEAD) and added net/caif/caif_socket.c
      v3: return -ECONNRESET in upstream caller of wait function for SOCK_DEAD
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      29d01d68
    • Richard Cochran's avatar
      net: dp83640: fix broken calibration routine. · 970233ca
      Richard Cochran authored
      [ Upstream commit 397a253a ]
      
      Currently, the calibration function that corrects the initial offsets
      among multiple devices only works the first time.  If the function is
      called more than once, the calibration fails and bogus offsets will be
      programmed into the devices.
      
      In a well hidden spot, the device documentation tells that trigger indexes
      0 and 1 are special in allowing the TRIG_IF_LATE flag to actually work.
      
      This patch fixes the issue by using one of the special triggers during the
      recalibration method.
      Signed-off-by: default avatarRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      970233ca
    • Alexei Starovoitov's avatar
      x86: bpf_jit: fix compilation of large bpf programs · 64a3d0b7
      Alexei Starovoitov authored
      [ Upstream commit 3f7352bf ]
      
      x86 has variable length encoding. x86 JIT compiler is trying
      to pick the shortest encoding for given bpf instruction.
      While doing so the jump targets are changing, so JIT is doing
      multiple passes over the program. Typical program needs 3 passes.
      Some very short programs converge with 2 passes. Large programs
      may need 4 or 5. But specially crafted bpf programs may hit the
      pass limit and if the program converges on the last iteration
      the JIT compiler will be producing an image full of 'int 3' insns.
      Fix this corner case by doing final iteration over bpf program.
      
      Fixes: 0a14842f ("net: filter: Just In Time compiler for x86-64")
      Reported-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@plumgrid.com>
      Tested-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      64a3d0b7
    • Vlad Yasevich's avatar
      net: core: Correct an over-stringent device loop detection. · 6f760598
      Vlad Yasevich authored
      [ Upstream commit d66bf7dd ]
      
      The code in __netdev_upper_dev_link() has an over-stringent
      loop detection logic that actually prevents valid configurations
      from working correctly.
      
      In particular, the logic returns an error if an upper device
      is already in the list of all upper devices for a given dev.
      This particular check seems to be a overzealous as it disallows
      perfectly valid configurations.  For example:
        # ip l a link eth0 name eth0.10 type vlan id 10
        # ip l a dev br0 typ bridge
        # ip l s eth0.10 master br0
        # ip l s eth0 master br0  <--- Will fail
      
      If you switch the last two commands (add eth0 first), then both
      will succeed.  If after that, you remove eth0 and try to re-add
      it, it will fail!
      
      It appears to be enough to simply check adj_list to keeps things
      safe.
      
      I've tried stacking multiple devices multiple times in all different
      combinations, and either rx_handler registration prevented the stacking
      of the device linking cought the error.
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Acked-by: default avatarJiri Pirko <jiri@resnulli.us>
      Acked-by: default avatarVeaceslav Falico <vfalico@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      6f760598
    • Michal Kubeček's avatar
      ipv6: fix ECMP route replacement · 20fa896e
      Michal Kubeček authored
      commit 27596472 upstream.
      
      When replacing an IPv6 multipath route with "ip route replace", i.e.
      NLM_F_CREATE | NLM_F_REPLACE, fib6_add_rt2node() replaces only first
      matching route without fixing its siblings, resulting in corrupted
      siblings linked list; removing one of the siblings can then end in an
      infinite loop.
      
      IPv6 ECMP implementation is a bit different from IPv4 so that route
      replacement cannot work in exactly the same way. This should be a
      reasonable approximation:
      
      1. If the new route is ECMP-able and there is a matching ECMP-able one
      already, replace it and all its siblings (if any).
      
      2. If the new route is ECMP-able and no matching ECMP-able route exists,
      replace first matching non-ECMP-able (if any) or just add the new one.
      
      3. If the new route is not ECMP-able, replace first matching
      non-ECMP-able route (if any) or add the new route.
      
      We also need to remove the NLM_F_REPLACE flag after replacing old
      route(s) by first nexthop of an ECMP route so that each subsequent
      nexthop does not replace previous one.
      
      Fixes: 51ebd318 ("ipv6: add support of equal cost multipath (ECMP)")
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Acked-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      20fa896e
    • Michal Kubeček's avatar
      ipv6: do not delete previously existing ECMP routes if add fails · 222a415b
      Michal Kubeček authored
      commit 35f1b4e9 upstream.
      
      If adding a nexthop of an IPv6 multipath route fails, comment in
      ip6_route_multipath() says we are going to delete all nexthops already
      added. However, current implementation deletes even the routes it
      hasn't even tried to add yet. For example, running
      
        ip route add 1234:5678::/64 \
            nexthop via fe80::aa dev dummy1 \
            nexthop via fe80::bb dev dummy1 \
            nexthop via fe80::cc dev dummy1
      
      twice results in removing all routes first command added.
      
      Limit the second (delete) run to nexthops that succeeded in the first
      (add) run.
      
      Fixes: 51ebd318 ("ipv6: add support of equal cost multipath (ECMP)")
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Acked-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      222a415b
    • Eric W. Biederman's avatar
      ipv4: Avoid crashing in ip_error · 5fb1c73e
      Eric W. Biederman authored
      commit 381c759d upstream.
      
      ip_error does not check if in_dev is NULL before dereferencing it.
      
      IThe following sequence of calls is possible:
      CPU A                          CPU B
      ip_rcv_finish
          ip_route_input_noref()
              ip_route_input_slow()
                                     inetdev_destroy()
          dst_input()
      
      With the result that a network device can be destroyed while processing
      an input packet.
      
      A crash was triggered with only unicast packets in flight, and
      forwarding enabled on the only network device.   The error condition
      was created by the removal of the network device.
      
      As such it is likely the that error code was -EHOSTUNREACH, and the
      action taken by ip_error (if in_dev had been accessible) would have
      been to not increment any counters and to have tried and likely failed
      to send an icmp error as the network device is going away.
      
      Therefore handle this weird case by just dropping the packet if
      !in_dev.  It will result in dropping the packet sooner, and will not
      result in an actual change of behavior.
      
      Fixes: 251da413 ("ipv4: Cache ip_error() routes even when not forwarding.")
      Reported-by: default avatarVittorio Gambaletta <linuxbugs@vittgam.net>
      Tested-by: default avatarVittorio Gambaletta <linuxbugs@vittgam.net>
      Signed-off-by: default avatarVittorio Gambaletta <linuxbugs@vittgam.net>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      5fb1c73e
    • Thadeu Lima de Souza Cascardo's avatar
      bridge: fix parsing of MLDv2 reports · e988a5e0
      Thadeu Lima de Souza Cascardo authored
      commit 47cc84ce upstream.
      
      When more than a multicast address is present in a MLDv2 report, all but
      the first address is ignored, because the code breaks out of the loop if
      there has not been an error adding that address.
      
      This has caused failures when two guests connected through the bridge
      tried to communicate using IPv6. Neighbor discoveries would not be
      transmitted to the other guest when both used a link-local address and a
      static address.
      
      This only happens when there is a MLDv2 querier in the network.
      
      The fix will only break out of the loop when there is a failure adding a
      multicast address.
      
      The mdb before the patch:
      
      dev ovirtmgmt port vnet0 grp ff02::1:ff7d:6603 temp
      dev ovirtmgmt port vnet1 grp ff02::1:ff7d:6604 temp
      dev ovirtmgmt port bond0.86 grp ff02::2 temp
      
      After the patch:
      
      dev ovirtmgmt port vnet0 grp ff02::1:ff7d:6603 temp
      dev ovirtmgmt port vnet1 grp ff02::1:ff7d:6604 temp
      dev ovirtmgmt port bond0.86 grp ff02::fb temp
      dev ovirtmgmt port bond0.86 grp ff02::2 temp
      dev ovirtmgmt port bond0.86 grp ff02::d temp
      dev ovirtmgmt port vnet0 grp ff02::1:ff00:76 temp
      dev ovirtmgmt port bond0.86 grp ff02::16 temp
      dev ovirtmgmt port vnet1 grp ff02::1:ff00:77 temp
      dev ovirtmgmt port bond0.86 grp ff02::1:ff00:def temp
      dev ovirtmgmt port bond0.86 grp ff02::1:ffa1:40bf temp
      
      Fixes: 08b202b6 ("bridge br_multicast: IPv6 MLD support.")
      Reported-by: default avatarRik Theys <Rik.Theys@esat.kuleuven.be>
      Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@redhat.com>
      Tested-by: default avatarRik Theys <Rik.Theys@esat.kuleuven.be>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      e988a5e0
    • Florian Fainelli's avatar
      net: phy: Allow EEE for all RGMII variants · 1a0558a0
      Florian Fainelli authored
      commit 7e140696 upstream.
      
      RGMII interfaces come in multiple flavors: RGMII with transmit or
      receive internal delay, no delays at all, or delays in both direction.
      
      This change extends the initial check for PHY_INTERFACE_MODE_RGMII to
      cover all of these variants since EEE should be allowed for any of these
      modes, since it is a property of the RGMII, hence Gigabit PHY capability
      more than the RGMII electrical interface and its delays.
      
      Fixes: a59a4d19 ("phy: add the EEE support and the way to access to the MMD registers")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      1a0558a0
    • Tommi Rantala's avatar
      ipvs: fix memory leak in ip_vs_ctl.c · f5599722
      Tommi Rantala authored
      commit f30bf2a5 upstream.
      
      Fix memory leak introduced in commit a0840e2e ("IPVS: netns,
      ip_vs_ctl local vars moved to ipvs struct."):
      
      unreferenced object 0xffff88005785b800 (size 2048):
        comm "(-localed)", pid 1434, jiffies 4294755650 (age 1421.089s)
        hex dump (first 32 bytes):
          bb 89 0b 83 ff ff ff ff b0 78 f0 4e 00 88 ff ff  .........x.N....
          04 00 00 00 a4 01 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffff8262ea8e>] kmemleak_alloc+0x4e/0xb0
          [<ffffffff811fba74>] __kmalloc_track_caller+0x244/0x430
          [<ffffffff811b88a0>] kmemdup+0x20/0x50
          [<ffffffff823276b7>] ip_vs_control_net_init+0x1f7/0x510
          [<ffffffff8231d630>] __ip_vs_init+0x100/0x250
          [<ffffffff822363a1>] ops_init+0x41/0x190
          [<ffffffff82236583>] setup_net+0x93/0x150
          [<ffffffff82236cc2>] copy_net_ns+0x82/0x140
          [<ffffffff810ab13d>] create_new_namespaces+0xfd/0x190
          [<ffffffff810ab49a>] unshare_nsproxy_namespaces+0x5a/0xc0
          [<ffffffff810833e3>] SyS_unshare+0x173/0x310
          [<ffffffff8265cbd7>] system_call_fastpath+0x12/0x6f
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      Fixes: a0840e2e ("IPVS: netns, ip_vs_ctl local vars moved to ipvs struct.")
      Signed-off-by: default avatarTommi Rantala <tt.rantala@gmail.com>
      Acked-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      f5599722
    • Harald Freudenberger's avatar
      crypto: s390/ghash - Fix incorrect ghash icv buffer handling. · 66201a68
      Harald Freudenberger authored
      commit a1cae34e upstream.
      
      Multitheaded tests showed that the icv buffer in the current ghash
      implementation is not handled correctly. A move of this working ghash
      buffer value to the descriptor context fixed this. Code is tested and
      verified with an multithreaded application via af_alg interface.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.vnet.ibm.com>
      Signed-off-by: default avatarGerald Schaefer <geraldsc@linux.vnet.ibm.com>
      Reported-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      66201a68
    • Ilya Dryomov's avatar
      libceph: request a new osdmap if lingering request maps to no osd · cd181cb3
      Ilya Dryomov authored
      commit b0494532 upstream.
      
      This commit does two things.  First, if there are any homeless
      lingering requests, we now request a new osdmap even if the osdmap that
      is being processed brought no changes, i.e. if a given lingering
      request turned homeless in one of the previous epochs and remained
      homeless in the current epoch.  Not doing so leaves us with a stale
      osdmap and as a result we may miss our window for reestablishing the
      watch and lose notifies.
      
      MON=1 OSD=1:
      
          # cat linger-needmap.sh
          #!/bin/bash
          rbd create --size 1 test
          DEV=$(rbd map test)
          ceph osd out 0
          rbd map dne/dne # obtain a new osdmap as a side effect (!)
          sleep 1
          ceph osd in 0
          rbd resize --size 2 test
          # rbd info test | grep size -> 2M
          # blockdev --getsize $DEV -> 1M
      
      N.B.: Not obtaining a new osdmap in between "osd out" and "osd in"
      above is enough to make it miss that resize notify, but that is a
      bug^Wlimitation of ceph watch/notify v1.
      
      Second, homeless lingering requests are now kicked just like those
      lingering requests whose mapping has changed.  This is mainly to
      recognize that a homeless lingering request makes no sense and to
      preserve the invariant that a registered lingering request is not
      sitting on any of r_req_lru_item lists.  This spares us a WARN_ON,
      which commit ba9d114e ("libceph: clear r_req_lru_item in
      __unregister_linger_request()") tried to fix the _wrong_ way.
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      cd181cb3
    • Mark Hounschell's avatar
      sd: Disable support for 256 byte/sector disks · b1fc2b0f
      Mark Hounschell authored
      commit 74856fbf upstream.
      
      256 bytes per sector support has been broken since 2.6.X,
      and no-one stepped up to fix this.
      So disable support for it.
      Signed-off-by: default avatarMark Hounschell <dmarkh@cfl.rr.com>
      Signed-off-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      b1fc2b0f