1. 05 1月, 2012 6 次提交
  2. 04 1月, 2012 2 次提交
  3. 31 12月, 2011 9 次提交
  4. 30 12月, 2011 1 次提交
    • A
      procfs: do not confuse jiffies with cputime64_t · 34845636
      Andreas Schwab 提交于
      Commit 2a95ea6c ("procfs: do not overflow get_{idle,iowait}_time
      for nohz") did not take into account that one some architectures jiffies
      and cputime use different units.
      
      This causes get_idle_time() to return numbers in the wrong units, making
      the idle time fields in /proc/stat wrong.
      
      Instead of converting the usec value returned by
      get_cpu_{idle,iowait}_time_us to units of jiffies, use the new function
      usecs_to_cputime64 to convert it to the correct unit of cputime64_t.
      Signed-off-by: NAndreas Schwab <schwab@linux-m68k.org>
      Acked-by: NMichal Hocko <mhocko@suse.cz>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: "Artem S. Tashkinov" <t.artem@mailcity.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      34845636
  5. 29 12月, 2011 3 次提交
  6. 28 12月, 2011 2 次提交
  7. 26 12月, 2011 1 次提交
    • J
      KVM: Don't automatically expose the TSC deadline timer in cpuid · 4d25a066
      Jan Kiszka 提交于
      Unlike all of the other cpuid bits, the TSC deadline timer bit is set
      unconditionally, regardless of what userspace wants.
      
      This is broken in several ways:
       - if userspace doesn't use KVM_CREATE_IRQCHIP, and doesn't emulate the TSC
         deadline timer feature, a guest that uses the feature will break
       - live migration to older host kernels that don't support the TSC deadline
         timer will cause the feature to be pulled from under the guest's feet;
         breaking it
       - guests that are broken wrt the feature will fail.
      
      Fix by not enabling the feature automatically; instead report it to userspace.
      Because the feature depends on KVM_CREATE_IRQCHIP, which we cannot guarantee
      will be called, we expose it via a KVM_CAP_TSC_DEADLINE_TIMER and not
      KVM_GET_SUPPORTED_CPUID.
      
      Fixes the Illumos guest kernel, which uses the TSC deadline timer feature.
      
      [avi: add the KVM_CAP + documentation]
      Reported-by: NAlexey Zaytsev <alexey.zaytsev@gmail.com>
      Tested-by: NAlexey Zaytsev <alexey.zaytsev@gmail.com>
      Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: NAvi Kivity <avi@redhat.com>
      4d25a066
  8. 25 12月, 2011 3 次提交
    • P
      netfilter: xtables: add nfacct match to support extended accounting · ceb98d03
      Pablo Neira Ayuso 提交于
      This patch adds the match that allows to perform extended
      accounting. It requires the new nfnetlink_acct infrastructure.
      
       # iptables -I INPUT -p tcp --sport 80 -m nfacct --nfacct-name http-traffic
       # iptables -I OUTPUT -p tcp --dport 80 -m nfacct --nfacct-name http-traffic
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      ceb98d03
    • P
      netfilter: add extended accounting infrastructure over nfnetlink · 94139027
      Pablo Neira Ayuso 提交于
      We currently have two ways to account traffic in netfilter:
      
      - iptables chain and rule counters:
      
       # iptables -L -n -v
      Chain INPUT (policy DROP 3 packets, 867 bytes)
       pkts bytes target     prot opt in     out     source               destination
          8  1104 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
      
      - use flow-based accounting provided by ctnetlink:
      
       # conntrack -L
      tcp      6 431999 ESTABLISHED src=192.168.1.130 dst=212.106.219.168 sport=58152 dport=80 packets=47 bytes=7654 src=212.106.219.168 dst=192.168.1.130 sport=80 dport=58152 packets=49 bytes=66340 [ASSURED] mark=0 use=1
      
      While trying to display real-time accounting statistics, we require
      to pool the kernel periodically to obtain this information. This is
      OK if the number of flows is relatively low. However, in case that
      the number of flows is huge, we can spend a considerable amount of
      cycles to iterate over the list of flows that have been obtained.
      
      Moreover, if we want to obtain the sum of the flow accounting results
      that match some criteria, we have to iterate over the whole list of
      existing flows, look for matchings and update the counters.
      
      This patch adds the extended accounting infrastructure for
      nfnetlink which aims to allow displaying real-time traffic accounting
      without the need of complicated and resource-consuming implementation
      in user-space. Basically, this new infrastructure allows you to create
      accounting objects. One accounting object is composed of packet and
      byte counters.
      
      In order to manipulate create accounting objects, you require the
      new libnetfilter_acct library. It contains several examples of use:
      
      libnetfilter_acct/examples# ./nfacct-add http-traffic
      libnetfilter_acct/examples# ./nfacct-get
      http-traffic = { pkts = 000000000000,   bytes = 000000000000 };
      
      Then, you can use one of this accounting objects in several iptables
      rules using the new nfacct match (which comes in a follow-up patch):
      
       # iptables -I INPUT -p tcp --sport 80 -m nfacct --nfacct-name http-traffic
       # iptables -I OUTPUT -p tcp --dport 80 -m nfacct --nfacct-name http-traffic
      
      The idea is simple: if one packet matches the rule, the nfacct match
      updates the counters.
      
      Thanks to Patrick McHardy, Eric Dumazet, Changli Gao for reviewing and
      providing feedback for this contribution.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      94139027
    • E
      rfs: better sizing of dev_flow_table · 60b778ce
      Eric Dumazet 提交于
      Aim of this patch is to provide full range of rps_flow_cnt on 64bit arches.
      
      Theorical limit on number of flows is 2^32
      
      Fix some buggy RPS/RFS macros as well.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      CC: Tom Herbert <therbert@google.com>
      CC: Xi Wang <xi.wang@gmail.com>
      CC: Laurent Chavey <chavey@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      60b778ce
  9. 24 12月, 2011 1 次提交
  10. 23 12月, 2011 12 次提交
    • P
      netfilter: ctnetlink: remove dead NAT code · b9e61f0d
      Patrick McHardy 提交于
      The NAT range to nlattr conversation callbacks and helpers are entirely
      dead code and are also useless since there are no NAT ranges in conntrack
      context, they are only used for initially selecting a tuple. The final NAT
      information is contained in the selected tuples of the conntrack entry.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      b9e61f0d
    • P
      netfilter: nat: remove module reference counting from NAT protocols · d70308f7
      Patrick McHardy 提交于
      The only remaining user of NAT protocol module reference counting is NAT
      ctnetlink support. Since this is a fairly short sequence of code, convert
      over to use RCU and remove module reference counting.
      
      Module unregistration is already protected by RCU using synchronize_rcu(),
      so no further changes are necessary.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      d70308f7
    • P
      netfilter: nf_nat: export NAT definitions to userspace · cbc9f2f4
      Patrick McHardy 提交于
      Export the NAT definitions to userspace. So far userspace (specifically,
      iptables) has been copying the headers files from include/net. Also
      rename some structures and definitions in preparation for IPv6 NAT.
      Since these have never been officially exported, this doesn't affect
      existing userspace code.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      cbc9f2f4
    • P
      netfilter: rework user-space expectation helper support · 3d058d7b
      Pablo Neira Ayuso 提交于
      This partially reworks bc01befd
      which added userspace expectation support.
      
      This patch removes the nf_ct_userspace_expect_list since now we
      force to use the new iptables CT target feature to add the helper
      extension for conntracks that have attached expectations from
      userspace.
      
      A new version of the proof-of-concept code to implement userspace
      helpers from userspace is available at:
      
      http://people.netfilter.org/pablo/userspace-conntrack-helpers/nf-ftp-helper-POC.tar.bz2
      
      This patch also modifies the CT target to allow to set the
      conntrack's userspace helper status flags. This flag is used
      to tell the conntrack system to explicitly allocate the helper
      extension.
      
      This helper extension is useful to link the userspace expectations
      with the master conntrack that is being tracked from one userspace
      helper.
      
      This feature fixes a problem in the current approach of the
      userspace helper support. Basically, if the master conntrack that
      has got a userspace expectation vanishes, the expectations point to
      one invalid memory address. Thus, triggering an oops in the
      expectation deletion event path.
      
      I decided not to add a new revision of the CT target because
      I only needed to add a new flag for it. I'll document in this
      issue in the iptables manpage. I have also changed the return
      value from EINVAL to EOPNOTSUPP if one flag not supported is
      specified. Thus, in the future adding new features that only
      require a new flag can be added without a new revision.
      
      There is no official code using this in userspace (apart from
      the proof-of-concept) that uses this infrastructure but there
      will be some by beginning 2012.
      Reported-by: NSam Roberts <vieuxtech@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      3d058d7b
    • E
      net: relax rcvbuf limits · 0fd7bac6
      Eric Dumazet 提交于
      skb->truesize might be big even for a small packet.
      
      Its even bigger after commit 87fb4b7b (net: more accurate skb
      truesize) and big MTU.
      
      We should allow queueing at least one packet per receiver, even with a
      low RCVBUF setting.
      Reported-by: NMichal Simek <monstr@monstr.eu>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0fd7bac6
    • E
      net: introduce DST_NOPEER dst flag · e688a604
      Eric Dumazet 提交于
      Chris Boot reported crashes occurring in ipv6_select_ident().
      
      [  461.457562] RIP: 0010:[<ffffffff812dde61>]  [<ffffffff812dde61>]
      ipv6_select_ident+0x31/0xa7
      
      [  461.578229] Call Trace:
      [  461.580742] <IRQ>
      [  461.582870]  [<ffffffff812efa7f>] ? udp6_ufo_fragment+0x124/0x1a2
      [  461.589054]  [<ffffffff812dbfe0>] ? ipv6_gso_segment+0xc0/0x155
      [  461.595140]  [<ffffffff812700c6>] ? skb_gso_segment+0x208/0x28b
      [  461.601198]  [<ffffffffa03f236b>] ? ipv6_confirm+0x146/0x15e
      [nf_conntrack_ipv6]
      [  461.608786]  [<ffffffff81291c4d>] ? nf_iterate+0x41/0x77
      [  461.614227]  [<ffffffff81271d64>] ? dev_hard_start_xmit+0x357/0x543
      [  461.620659]  [<ffffffff81291cf6>] ? nf_hook_slow+0x73/0x111
      [  461.626440]  [<ffffffffa0379745>] ? br_parse_ip_options+0x19a/0x19a
      [bridge]
      [  461.633581]  [<ffffffff812722ff>] ? dev_queue_xmit+0x3af/0x459
      [  461.639577]  [<ffffffffa03747d2>] ? br_dev_queue_push_xmit+0x72/0x76
      [bridge]
      [  461.646887]  [<ffffffffa03791e3>] ? br_nf_post_routing+0x17d/0x18f
      [bridge]
      [  461.653997]  [<ffffffff81291c4d>] ? nf_iterate+0x41/0x77
      [  461.659473]  [<ffffffffa0374760>] ? br_flood+0xfa/0xfa [bridge]
      [  461.665485]  [<ffffffff81291cf6>] ? nf_hook_slow+0x73/0x111
      [  461.671234]  [<ffffffffa0374760>] ? br_flood+0xfa/0xfa [bridge]
      [  461.677299]  [<ffffffffa0379215>] ?
      nf_bridge_update_protocol+0x20/0x20 [bridge]
      [  461.684891]  [<ffffffffa03bb0e5>] ? nf_ct_zone+0xa/0x17 [nf_conntrack]
      [  461.691520]  [<ffffffffa0374760>] ? br_flood+0xfa/0xfa [bridge]
      [  461.697572]  [<ffffffffa0374812>] ? NF_HOOK.constprop.8+0x3c/0x56
      [bridge]
      [  461.704616]  [<ffffffffa0379031>] ?
      nf_bridge_push_encap_header+0x1c/0x26 [bridge]
      [  461.712329]  [<ffffffffa037929f>] ? br_nf_forward_finish+0x8a/0x95
      [bridge]
      [  461.719490]  [<ffffffffa037900a>] ?
      nf_bridge_pull_encap_header+0x1c/0x27 [bridge]
      [  461.727223]  [<ffffffffa0379974>] ? br_nf_forward_ip+0x1c0/0x1d4 [bridge]
      [  461.734292]  [<ffffffff81291c4d>] ? nf_iterate+0x41/0x77
      [  461.739758]  [<ffffffffa03748cc>] ? __br_deliver+0xa0/0xa0 [bridge]
      [  461.746203]  [<ffffffff81291cf6>] ? nf_hook_slow+0x73/0x111
      [  461.751950]  [<ffffffffa03748cc>] ? __br_deliver+0xa0/0xa0 [bridge]
      [  461.758378]  [<ffffffffa037533a>] ? NF_HOOK.constprop.4+0x56/0x56
      [bridge]
      
      This is caused by bridge netfilter special dst_entry (fake_rtable), a
      special shared entry, where attaching an inetpeer makes no sense.
      
      Problem is present since commit 87c48fa3 (ipv6: make fragment
      identifications less predictable)
      
      Introduce DST_NOPEER dst flag and make sure ipv6_select_ident() and
      __ip_select_ident() fallback to the 'no peer attached' handling.
      Reported-by: NChris Boot <bootc@bootc.net>
      Tested-by: NChris Boot <bootc@bootc.net>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e688a604
    • G
      Bluetooth: remove *_bh usage from hci_dev_list and hci_cb_list · f20d09d5
      Gustavo F. Padovan 提交于
      They don't need to disable interrupts anymore, we only run in process
      context now.
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      f20d09d5
    • G
      Bluetooth: Remove lock from inquiry_cache · 460da45d
      Gustavo F. Padovan 提交于
      It was never used, so removing it.
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      460da45d
    • B
      Bluetooth: Add MITM mechanism to LE-SMP · 2b64d153
      Brian Gix 提交于
      To achive Man-In-The-Middle (MITM) level security with Low Energy,
      we have to enable User Passkey Comparison.  This commit modifies the
      hard-coded JUST-WORKS pairing mechanism to support query via the MGMT
      interface of Passkey comparison and User Confirmation.
      Signed-off-by: NBrian Gix <bgix@codeaurora.org>
      Acked-by: Marcel Holtmann<marcel@holtmann.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      2b64d153
    • U
      Bluetooth: Fix deadlocks with sock lock and L2CAP timers locks · 371fd835
      Ulisses Furquim 提交于
      When cancelling a delayed work (timer) in L2CAP we can not sleep holding
      the sock mutex otherwise we might deadlock with an L2CAP timer handler.
      This is possible because RX/TX and L2CAP timers run in different workqueues.
      The scenario below illustrates the problem. Thus we are now avoiding to
      sleep on the timers locks.
      
       ======================================================
       [ INFO: possible circular locking dependency detected ]
       3.1.0-05270-ga978dc7-dirty #239
       -------------------------------------------------------
       kworker/1:1/873 is trying to acquire lock:
        (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+...}, at: [<ffffffffa002ceac>] l2cap_chan_timeout+0x3c/0xe0 [bluetooth]
      
       but task is already holding lock:
        ((&(&chan->chan_timer)->work)){+.+...}, at: [<ffffffff81051a86>] process_one_work+0x126/0x450
      
       which lock already depends on the new lock.
      
       the existing dependency chain (in reverse order) is:
      
       -> #1 ((&(&chan->chan_timer)->work)){+.+...}:
              [<ffffffff8106b276>] check_prevs_add+0xf6/0x170
              [<ffffffff8106b903>] validate_chain+0x613/0x790
              [<ffffffff8106dfee>] __lock_acquire+0x4be/0xac0
              [<ffffffff8106ec2d>] lock_acquire+0x8d/0xb0
              [<ffffffff81052a6f>] wait_on_work+0x4f/0x160
              [<ffffffff81052ca3>] __cancel_work_timer+0x73/0x80
              [<ffffffff81052cbd>] cancel_delayed_work_sync+0xd/0x10
              [<ffffffffa002f2ed>] l2cap_chan_connect+0x22d/0x470 [bluetooth]
              [<ffffffffa002fb51>] l2cap_sock_connect+0xb1/0x140 [bluetooth]
              [<ffffffff8130811b>] kernel_connect+0xb/0x10
              [<ffffffffa00cf98a>] rfcomm_session_create+0x12a/0x1c0 [rfcomm]
              [<ffffffffa00cfbe7>] __rfcomm_dlc_open+0x1c7/0x240 [rfcomm]
              [<ffffffffa00d07c2>] rfcomm_dlc_open+0x42/0x70 [rfcomm]
              [<ffffffffa00d3b03>] rfcomm_sock_connect+0x103/0x150 [rfcomm]
              [<ffffffff8130bd7e>] sys_connect+0xae/0xc0
              [<ffffffff813368d2>] compat_sys_socketcall+0xb2/0x220
              [<ffffffff813b2089>] sysenter_dispatch+0x7/0x30
      
       -> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+...}:
              [<ffffffff8106b16d>] check_prev_add+0x6cd/0x6e0
              [<ffffffff8106b276>] check_prevs_add+0xf6/0x170
              [<ffffffff8106b903>] validate_chain+0x613/0x790
              [<ffffffff8106dfee>] __lock_acquire+0x4be/0xac0
              [<ffffffff8106ec2d>] lock_acquire+0x8d/0xb0
              [<ffffffff8130d91a>] lock_sock_nested+0x8a/0xa0
              [<ffffffffa002ceac>] l2cap_chan_timeout+0x3c/0xe0 [bluetooth]
              [<ffffffff81051ae4>] process_one_work+0x184/0x450
              [<ffffffff8105276e>] worker_thread+0x15e/0x340
              [<ffffffff81057bb6>] kthread+0x96/0xa0
              [<ffffffff813b1ef4>] kernel_thread_helper+0x4/0x10
      
       other info that might help us debug this:
      
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock((&(&chan->chan_timer)->work));
                                      lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
                                      lock((&(&chan->chan_timer)->work));
         lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
      
        *** DEADLOCK ***
      
       2 locks held by kworker/1:1/873:
        #0:  (events){.+.+.+}, at: [<ffffffff81051a86>] process_one_work+0x126/0x450
        #1:  ((&(&chan->chan_timer)->work)){+.+...}, at: [<ffffffff81051a86>] process_one_work+0x126/0x450
      
       stack backtrace:
       Pid: 873, comm: kworker/1:1 Not tainted 3.1.0-05270-ga978dc7-dirty #239
       Call Trace:
        [<ffffffff813a0f6e>] print_circular_bug+0xd2/0xe3
        [<ffffffff8106b16d>] check_prev_add+0x6cd/0x6e0
        [<ffffffff8106b276>] check_prevs_add+0xf6/0x170
        [<ffffffff8106b903>] validate_chain+0x613/0x790
        [<ffffffff8106dfee>] __lock_acquire+0x4be/0xac0
        [<ffffffff8130d8f6>] ? lock_sock_nested+0x66/0xa0
        [<ffffffff8106ea30>] ? lock_release_nested+0x100/0x110
        [<ffffffff8130d8f6>] ? lock_sock_nested+0x66/0xa0
        [<ffffffff8106ec2d>] lock_acquire+0x8d/0xb0
        [<ffffffffa002ceac>] ? l2cap_chan_timeout+0x3c/0xe0 [bluetooth]
        [<ffffffff8130d91a>] lock_sock_nested+0x8a/0xa0
        [<ffffffffa002ceac>] ? l2cap_chan_timeout+0x3c/0xe0 [bluetooth]
        [<ffffffff81051a86>] ? process_one_work+0x126/0x450
        [<ffffffffa002ceac>] l2cap_chan_timeout+0x3c/0xe0 [bluetooth]
        [<ffffffff81051ae4>] process_one_work+0x184/0x450
        [<ffffffff81051a86>] ? process_one_work+0x126/0x450
        [<ffffffffa002ce70>] ? l2cap_security_cfm+0x4e0/0x4e0 [bluetooth]
        [<ffffffff8105276e>] worker_thread+0x15e/0x340
        [<ffffffff81052610>] ? manage_workers+0x110/0x110
        [<ffffffff81057bb6>] kthread+0x96/0xa0
        [<ffffffff813b1ef4>] kernel_thread_helper+0x4/0x10
        [<ffffffff813af69d>] ? retint_restore_args+0xe/0xe
        [<ffffffff81057b20>] ? __init_kthread_worker+0x70/0x70
        [<ffffffff813b1ef0>] ? gs_change+0xb/0xb
      Signed-off-by: NUlisses Furquim <ulisses@profusion.mobi>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      371fd835
    • U
      Bluetooth: Make HCI call directly into SCO and L2CAP event functions · 686ebf28
      Ulisses Furquim 提交于
      The struct hci_proto and all related register/unregister and dispatching
      code was removed. HCI core code now call directly the SCO and L2CAP
      event functions.
      Signed-off-by: NUlisses Furquim <ulisses@profusion.mobi>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      686ebf28
    • A
      Bluetooth: Remove magic numbers from le scan cmd · 68a8aea4
      Andrei Emeltchenko 提交于
      Make code readable by removing magic numbers.
      Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      68a8aea4