{"ref":"refs/heads/master","push_id":55193624,"commits":[{"sha":"e30e2fdfe56288576ee9e04dbb06b4bd5f282203","author":{"email":"5b23f8226e886b22344fc642373ea657dd596b63@linux.vnet.ibm.com","name":"Srivatsa S. Bhat"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/e30e2fdfe56288576ee9e04dbb06b4bd5f282203","message":"VFS: Fix race between CPU hotplug and lglocks\n\nCurrently, the *_global_[un]lock_online() routines are not at all synchronized\nwith CPU hotplug. Soft-lockups detected as a consequence of this race was\nreported earlier at https://lkml.org/lkml/2011/8/24/185. (Thanks to Cong Meng\nfor finding out that the root-cause of this issue is the race condition\nbetween br_write_[un]lock() and CPU hotplug, which results in the lock states\ngetting messed up).\n\nFixing this race by just adding {get,put}_online_cpus() at appropriate places\nin *_global_[un]lock_online() is not a good option, because, then suddenly\nbr_write_[un]lock() would become blocking, whereas they have been kept as\nnon-blocking all this time, and we would want to keep them that way.\n\nSo, overall, we want to ensure 3 things:\n1. br_write_lock() and br_write_unlock() must remain as non-blocking.\n2. The corresponding lock and unlock of the per-cpu spinlocks must not happen\n   for different sets of CPUs.\n3. Either prevent any new CPU online operation in between this lock-unlock, or\n   ensure that the newly onlined CPU does not proceed with its corresponding\n   per-cpu spinlock unlocked.\n\nTo achieve all this:\n(a) We introduce a new spinlock that is taken by the *_global_lock_online()\n    routine and released by the *_global_unlock_online() routine.\n(b) We register a callback for CPU hotplug notifications, and this callback\n    takes the same spinlock as above.\n(c) We maintain a bitmap which is close to the cpu_online_mask, and once it is\n    initialized in the lock_init() code, all future updates to it are done in\n    the callback, under the above spinlock.\n(d) The above bitmap is used (instead of cpu_online_mask) while locking and\n    unlocking the per-cpu locks.\n\nThe callback takes the spinlock upon the CPU_UP_PREPARE event. So, if the\nbr_write_lock-unlock sequence is in progress, the callback keeps spinning,\nthus preventing the CPU online operation till the lock-unlock sequence is\ncomplete. This takes care of requirement (3).\n\nThe bitmap that we maintain remains unmodified throughout the lock-unlock\nsequence, since all updates to it are managed by the callback, which takes\nthe same spinlock as the one taken by the lock code and released only by the\nunlock routine. Combining this with (d) above, satisfies requirement (2).\n\nOverall, since we use a spinlock (mentioned in (a)) to prevent CPU hotplug\noperations from racing with br_write_lock-unlock, requirement (1) is also\ntaken care of.\n\nBy the way, it is to be noted that a CPU offline operation can actually run\nin parallel with our lock-unlock sequence, because our callback doesn't react\nto notifications earlier than CPU_DEAD (in order to maintain our bitmap\nproperly). And this means, since we use our own bitmap (which is stale, on\npurpose) during the lock-unlock sequence, we could end up unlocking the\nper-cpu lock of an offline CPU (because we had locked it earlier, when the\nCPU was online), in order to satisfy requirement (2). But this is harmless,\nthough it looks a bit awkward.\n\nDebugged-by: Cong Meng <mc@linux.vnet.ibm.com>\nSigned-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>\nCc: stable@vger.kernel.org"},{"sha":"b9eda06f80b0db61a73bd87c6b0eb67d8aca55ad","author":{"email":"4bf0fb350827ce8d86875e76c923a478597c3cef@canb.auug.org.au","name":"Stephen Rothwell"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/b9eda06f80b0db61a73bd87c6b0eb67d8aca55ad","message":"ipv4: using prefetch requires including prefetch.h\n\nSigned-off-by: Stephen Rothwell <sfr@canb.auug.org.au>\nAcked-by: Eric Dumazet <eric.dumazet@gmail.com>\nAcked-by: David Miller <davem@davemloft.net>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>"},{"sha":"19d40dcabf1cdf84e1a76c147b7177b5a6c21943","author":{"email":"fe08d3c717adf2ae63592e4c9aec6e3e404d8e3e@davemloft.net","name":"David Miller"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/19d40dcabf1cdf84e1a76c147b7177b5a6c21943","message":"pata_of_platform: Add missing CONFIG_OF_IRQ dependency.\n\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Jeff Garzik <jgarzik@redhat.com>"},{"sha":"abe8809c14f05430f9f8cb13bd70b2ec3195e84b","author":{"email":"69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org","name":"Linus Torvalds"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/abe8809c14f05430f9f8cb13bd70b2ec3195e84b","message":"Merge branch 'upstream-linus' of git://github.com/jgarzik/libata-dev\n\n* 'upstream-linus' of git://github.com/jgarzik/libata-dev:\n  pata_of_platform: Add missing CONFIG_OF_IRQ dependency."},{"sha":"b3b1b70e62a603f473619dbebc3b3d23f535e6f8","author":{"email":"69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org","name":"Linus Torvalds"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/b3b1b70e62a603f473619dbebc3b3d23f535e6f8","message":"Merge branch 'usb-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb\n\n* 'usb-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:\n  USB: Fix usb/isp1760 build on sparc\n  usb: gadget: epautoconf: do not change number of streams\n  usb: dwc3: core: fix cached revision on our structure\n  usb: musb: fix reset issue with full speed device"},{"sha":"7cc8583372a21d98a23b703ad96cab03180b5030","author":{"email":"fe08d3c717adf2ae63592e4c9aec6e3e404d8e3e@davemloft.net","name":"David S. Miller"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/7cc8583372a21d98a23b703ad96cab03180b5030","message":"sparc64: Fix MSIQ HV call ordering in pci_sun4v_msiq_build_irq().\n\nThis silently was working for many years and stopped working on\nNiagara-T3 machines.\n\nWe need to set the MSIQ to VALID before we can set it's state to IDLE.\n\nOn Niagara-T3, setting the state to IDLE first was causing HV_EINVAL\nerrors.  The hypervisor documentation says, rather ambiguously, that\nthe MSIQ must be \"initialized\" before one can set the state.\n\nI previously understood this to mean merely that a successful setconf()\noperation has been performed on the MSIQ, which we have done at this\npoint.  But it seems to also mean that it has been set VALID too.\n\nSigned-off-by: David S. Miller <davem@davemloft.net>"},{"sha":"09cd9270ea52e0f9851528e8ed028073f96b3c34","author":{"email":"1c00aa603bb92d594c03cff60ecf8e63b2a5bcb1@suse.de","name":"NeilBrown"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/09cd9270ea52e0f9851528e8ed028073f96b3c34","message":"md/linear: fix hot-add of devices to linear arrays.\n\ncommit d70ed2e4fafdbef0800e73942482bb075c21578b\nbroke hot-add to a linear array.\nAfter that commit, metadata if not written to devices until they\nhave been fully integrated into the array as determined by\nsaved_raid_disk.  That patch arranged to clear that field after\na recovery completed.\n\nHowever for linear arrays, there is no recovery - the integration is\ninstantaneous.  So we need to explicitly clear the saved_raid_disk\nfield.\n\nSigned-off-by: NeilBrown <neilb@suse.de>"},{"sha":"30d7a4836847bdb10b32c78a4879d4aebe0f193b","author":{"email":"1c00aa603bb92d594c03cff60ecf8e63b2a5bcb1@suse.de","name":"NeilBrown"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/30d7a4836847bdb10b32c78a4879d4aebe0f193b","message":"md/raid5: ensure correct assessment of drives during degraded reshape.\n\nWhile reshaping a degraded array (as when reshaping a RAID0 by first\nconverting it to a degraded RAID4) we currently get confused about\nwhich devices are in_sync.  In most cases we get it right, but in the\nregion that is being reshaped we need to treat non-failed devices as\nin-sync when we have the data but haven't actually written it out yet.\n\nReported-by: Adam Kwolek <adam.kwolek@intel.com>\nSigned-off-by: NeilBrown <neilb@suse.de>"},{"sha":"60fc13702a1b35118c1548e9c257fa038cecb658","author":{"email":"1c00aa603bb92d594c03cff60ecf8e63b2a5bcb1@suse.de","name":"NeilBrown"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/60fc13702a1b35118c1548e9c257fa038cecb658","message":"md: don't give up looking for spares on first failure-to-add\n\nBefore performing a recovery we try to remove any spares that\nmight not be working, then add any that might have become relevant.\n\nCurrently we abort on the first spare that cannot be added.\nThis is a false optimisation.\nIt is conceivable that - depending on rules in the personality - a\nsubsequent spare might be accepted.\nAlso the loop does other things like count the available spares and\nreset the 'recovery_offset' value.\n\nIf we abort early these might not happen properly.\n\nSo remove the early abort.\n\nIn particular if you have an array what is undergoing recovery and\nwhich has extra spares, then the recovery may not restart after as\nreboot as the could of 'spares' might end up as zero.\n\nReported-by: Anssi Hannula <anssi.hannula@iki.fi>\nSigned-off-by: NeilBrown <neilb@suse.de>"},{"sha":"961902c0f8240175729274cd14198872f42072b7","author":{"email":"1c00aa603bb92d594c03cff60ecf8e63b2a5bcb1@suse.de","name":"NeilBrown"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/961902c0f8240175729274cd14198872f42072b7","message":"md/bitmap: It is OK to clear bits during recovery.\n\ncommit d0a4bb492772ce5c4bdfba3744a99ed6f6fb238f introduced a\nregression which is annoying but fairly harmless.\n\nWhen writing to an array that is undergoing recovery (a spare\nin being integrated into the array), writing to the array will\nset bits in the bitmap, but they will not be cleared when the\nwrite completes.\n\nFor bits covering areas that have not been recovered yet this is not a\nproblem as the recovery will clear the bits.  However bits set in\nalready-recovered region will stay set and never be cleared.\nThis doesn't risk data integrity.  The only negatives are:\n - next time there is a crash, more resyncing than necessary will\n   be done.\n - the bitmap doesn't look clean, which is confusing.\n\nWhile an array is recovering we don't want to update the\n'events_cleared' setting in the bitmap but we do still want to clear\nbits that have very recently been set - providing they were written to\nthe recovering device.\n\nSo split those two needs - which previously both depended on 'success'\nand always clear the bit of the write went to all devices.\n\nSigned-off-by: NeilBrown <neilb@suse.de>"},{"sha":"ad1fca2003822ff2f24c88ad68a29970c5e0d0a7","author":{"email":"69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org","name":"Linus Torvalds"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/ad1fca2003822ff2f24c88ad68a29970c5e0d0a7","message":"Merge branch 'for-linus' of git://neil.brown.name/md\n\n* 'for-linus' of git://neil.brown.name/md:\n  md/bitmap: It is OK to clear bits during recovery.\n  md: don't give up looking for spares on first failure-to-add\n  md/raid5: ensure correct assessment of drives during degraded reshape.\n  md/linear: fix hot-add of devices to linear arrays."},{"sha":"a13861a28b90541aa207532d237e7a940f1b1c7b","author":{"email":"a0baddf32b28d2f9429941ed4af2fe636e210591@gmail.com","name":"Eric Dumazet"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/a13861a28b90541aa207532d237e7a940f1b1c7b","message":"bridge: provide a mtu() method for fake_dst_ops\n\nCommit 618f9bc74a039da76 (net: Move mtu handling down to the protocol\ndepended handlers) forgot the bridge netfilter case, adding a NULL\ndereference in ip_fragment().\n\nReported-by: Chris Boot <bootc@bootc.net>\nCC: Steffen Klassert <steffen.klassert@secunet.com>\nSigned-off-by: Eric Dumazet <eric.dumazet@gmail.com>\nAcked-by: Steffen Klassert <steffen.klassert@secunet.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>"},{"sha":"7838f2ce36b6ab5c13ef20b1857e3bbd567f1759","author":{"email":"17c2d8920621522552b392f72d8fdb4d1e866b44@redhat.com","name":"Thomas Graf"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/7838f2ce36b6ab5c13ef20b1857e3bbd567f1759","message":"mqprio: Avoid panic if no options are provided\n\nUserspace may not provide TCA_OPTIONS, in fact tc currently does\nso not do so if no arguments are specified on the command line.\nReturn EINVAL instead of panicing.\n\nSigned-off-by: Thomas Graf <tgraf@redhat.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>"},{"sha":"e688a604807647c9450f9c12a7cb6d027150a895","author":{"email":"a0baddf32b28d2f9429941ed4af2fe636e210591@gmail.com","name":"Eric Dumazet"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/e688a604807647c9450f9c12a7cb6d027150a895","message":"net: introduce DST_NOPEER dst flag\n\nChris Boot reported crashes occurring in ipv6_select_ident().\n\n[  461.457562] RIP: 0010:[<ffffffff812dde61>]  [<ffffffff812dde61>]\nipv6_select_ident+0x31/0xa7\n\n[  461.578229] Call Trace:\n[  461.580742] <IRQ>\n[  461.582870]  [<ffffffff812efa7f>] ? udp6_ufo_fragment+0x124/0x1a2\n[  461.589054]  [<ffffffff812dbfe0>] ? ipv6_gso_segment+0xc0/0x155\n[  461.595140]  [<ffffffff812700c6>] ? skb_gso_segment+0x208/0x28b\n[  461.601198]  [<ffffffffa03f236b>] ? ipv6_confirm+0x146/0x15e\n[nf_conntrack_ipv6]\n[  461.608786]  [<ffffffff81291c4d>] ? nf_iterate+0x41/0x77\n[  461.614227]  [<ffffffff81271d64>] ? dev_hard_start_xmit+0x357/0x543\n[  461.620659]  [<ffffffff81291cf6>] ? nf_hook_slow+0x73/0x111\n[  461.626440]  [<ffffffffa0379745>] ? br_parse_ip_options+0x19a/0x19a\n[bridge]\n[  461.633581]  [<ffffffff812722ff>] ? dev_queue_xmit+0x3af/0x459\n[  461.639577]  [<ffffffffa03747d2>] ? br_dev_queue_push_xmit+0x72/0x76\n[bridge]\n[  461.646887]  [<ffffffffa03791e3>] ? br_nf_post_routing+0x17d/0x18f\n[bridge]\n[  461.653997]  [<ffffffff81291c4d>] ? nf_iterate+0x41/0x77\n[  461.659473]  [<ffffffffa0374760>] ? br_flood+0xfa/0xfa [bridge]\n[  461.665485]  [<ffffffff81291cf6>] ? nf_hook_slow+0x73/0x111\n[  461.671234]  [<ffffffffa0374760>] ? br_flood+0xfa/0xfa [bridge]\n[  461.677299]  [<ffffffffa0379215>] ?\nnf_bridge_update_protocol+0x20/0x20 [bridge]\n[  461.684891]  [<ffffffffa03bb0e5>] ? nf_ct_zone+0xa/0x17 [nf_conntrack]\n[  461.691520]  [<ffffffffa0374760>] ? br_flood+0xfa/0xfa [bridge]\n[  461.697572]  [<ffffffffa0374812>] ? NF_HOOK.constprop.8+0x3c/0x56\n[bridge]\n[  461.704616]  [<ffffffffa0379031>] ?\nnf_bridge_push_encap_header+0x1c/0x26 [bridge]\n[  461.712329]  [<ffffffffa037929f>] ? br_nf_forward_finish+0x8a/0x95\n[bridge]\n[  461.719490]  [<ffffffffa037900a>] ?\nnf_bridge_pull_encap_header+0x1c/0x27 [bridge]\n[  461.727223]  [<ffffffffa0379974>] ? br_nf_forward_ip+0x1c0/0x1d4 [bridge]\n[  461.734292]  [<ffffffff81291c4d>] ? nf_iterate+0x41/0x77\n[  461.739758]  [<ffffffffa03748cc>] ? __br_deliver+0xa0/0xa0 [bridge]\n[  461.746203]  [<ffffffff81291cf6>] ? nf_hook_slow+0x73/0x111\n[  461.751950]  [<ffffffffa03748cc>] ? __br_deliver+0xa0/0xa0 [bridge]\n[  461.758378]  [<ffffffffa037533a>] ? NF_HOOK.constprop.4+0x56/0x56\n[bridge]\n\nThis is caused by bridge netfilter special dst_entry (fake_rtable), a\nspecial shared entry, where attaching an inetpeer makes no sense.\n\nProblem is present since commit 87c48fa3b46 (ipv6: make fragment\nidentifications less predictable)\n\nIntroduce DST_NOPEER dst flag and make sure ipv6_select_ident() and\n__ip_select_ident() fallback to the 'no peer attached' handling.\n\nReported-by: Chris Boot <bootc@bootc.net>\nTested-by: Chris Boot <bootc@bootc.net>\nSigned-off-by: Eric Dumazet <eric.dumazet@gmail.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>"},{"sha":"a0a129f8b6cff54ab479324a54aefdab5db4f240","author":{"email":"91e0ff19c25a4c90f9bdc24b1ac8e48e9177c077@gmail.com","name":"Xi Wang"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/a0a129f8b6cff54ab479324a54aefdab5db4f240","message":"rps: fix insufficient bounds checking in store_rps_dev_flow_table_cnt()\n\nSetting a large rps_flow_cnt like (1 << 30) on 32-bit platform will\ncause a kernel oops due to insufficient bounds checking.\n\n\tif (count > 1<<30) {\n\t\t/* Enforce a limit to prevent overflow */\n\t\treturn -EINVAL;\n\t}\n\tcount = roundup_pow_of_two(count);\n\ttable = vmalloc(RPS_DEV_FLOW_TABLE_SIZE(count));\n\nNote that the macro RPS_DEV_FLOW_TABLE_SIZE(count) is defined as:\n\n\t... + (count * sizeof(struct rps_dev_flow))\n\nwhere sizeof(struct rps_dev_flow) is 8.  (1 << 30) * 8 will overflow\n32 bits.\n\nThis patch replaces the magic number (1 << 30) with a symbolic bound.\n\nSuggested-by: Eric Dumazet <eric.dumazet@gmail.com>\nSigned-off-by: Xi Wang <xi.wang@gmail.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>"},{"sha":"0fd7bac6b6157eed6cf0cb86a1e88ba29e57c033","author":{"email":"a0baddf32b28d2f9429941ed4af2fe636e210591@gmail.com","name":"Eric Dumazet"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/0fd7bac6b6157eed6cf0cb86a1e88ba29e57c033","message":"net: relax rcvbuf limits\n\nskb->truesize might be big even for a small packet.\n\nIts even bigger after commit 87fb4b7b533 (net: more accurate skb\ntruesize) and big MTU.\n\nWe should allow queueing at least one packet per receiver, even with a\nlow RCVBUF setting.\n\nReported-by: Michal Simek <monstr@monstr.eu>\nSigned-off-by: Eric Dumazet <eric.dumazet@gmail.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>"},{"sha":"8d532b2afb2eacc84588db709ec280a3d1219be3","author":{"email":"a169954b4cb1a46cee25f659d3bddfebe02b5fba@oracle.com","name":"Chris Mason"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/8d532b2afb2eacc84588db709ec280a3d1219be3","message":"Btrfs: fix worker lock misuse in find_worker\n\nDan Carpenter noticed that we were doing a double unlock on the worker\nlock, and sometimes picking a worker thread without the lock held.\n\nThis fixes both errors.\n\nSigned-off-by: Chris Mason <chris.mason@oracle.com>\nReported-by: Dan Carpenter <dan.carpenter@oracle.com>"},{"sha":"08c422c27f855d27b0b3d9fa30ebd938d4ae6f1f","author":{"email":"de609eb4d5d70b1d38ec6642adbfc33a2781f63c@ZenIV.linux.org.uk","name":"Al Viro"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/08c422c27f855d27b0b3d9fa30ebd938d4ae6f1f","message":"Btrfs: call d_instantiate after all ops are setup\n\nThis closes races where btrfs is calling d_instantiate too soon during\ninode creation.  All of the callers of btrfs_add_nondir are updated to\ninstantiate after the inode is fully setup in memory.\n\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>\nSigned-off-by: Chris Mason <chris.mason@oracle.com>"},{"sha":"0354b48f633ae435acbc01b470a1ce8cfeff3e9f","author":{"email":"cef439e78636cdab99cd2923826c5065a0743e5b@strlen.de","name":"Florian Westphal"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/0354b48f633ae435acbc01b470a1ce8cfeff3e9f","message":"netfilter: xt_connbytes: handle negation correctly\n\n\"! --connbytes 23:42\" should match if the packet/byte count is not in range.\n\nAs there is no explict \"invert match\" toggle in the match structure,\nuserspace swaps the from and to arguments\n(i.e., as if \"--connbytes 42:23\" were given).\n\nHowever, \"what <= 23 && what >= 42\" will always be false.\n\nChange things so we use \"||\" in case \"from\" is larger than \"to\".\n\nThis change may look like it breaks backwards compatibility when \"to\" is 0.\nHowever, older iptables binaries will refuse \"connbytes 42:0\",\nand current releases treat it to mean \"! --connbytes 0:42\",\nso we should be fine.\n\nSigned-off-by: Florian Westphal <fw@strlen.de>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>"},{"sha":"6350323ad8def2ac00d77cdee3b79c9b9fba75c4","author":{"email":"fe08d3c717adf2ae63592e4c9aec6e3e404d8e3e@davemloft.net","name":"David S. Miller"},"url":"https://api.github.com/repos/giuseppecalderaro/linux/commits/6350323ad8def2ac00d77cdee3b79c9b9fba75c4","message":"Merge branch 'nf' of git://1984.lsi.us.es/net"}],"head":"5f0a6e2d503896062f641639dacfe5055c2f593b","size":28}