1. 06 3月, 2012 1 次提交
  2. 05 3月, 2012 4 次提交
  3. 04 3月, 2012 2 次提交
  4. 02 3月, 2012 2 次提交
  5. 29 2月, 2012 1 次提交
  6. 27 2月, 2012 5 次提交
  7. 25 2月, 2012 1 次提交
    • O
      epoll: introduce POLLFREE to flush ->signalfd_wqh before kfree() · d80e731e
      Oleg Nesterov 提交于
      This patch is intentionally incomplete to simplify the review.
      It ignores ep_unregister_pollwait() which plays with the same wqh.
      See the next change.
      
      epoll assumes that the EPOLL_CTL_ADD'ed file controls everything
      f_op->poll() needs. In particular it assumes that the wait queue
      can't go away until eventpoll_release(). This is not true in case
      of signalfd, the task which does EPOLL_CTL_ADD uses its ->sighand
      which is not connected to the file.
      
      This patch adds the special event, POLLFREE, currently only for
      epoll. It expects that init_poll_funcptr()'ed hook should do the
      necessary cleanup. Perhaps it should be defined as EPOLLFREE in
      eventpoll.
      
      __cleanup_sighand() is changed to do wake_up_poll(POLLFREE) if
      ->signalfd_wqh is not empty, we add the new signalfd_cleanup()
      helper.
      
      ep_poll_callback(POLLFREE) simply does list_del_init(task_list).
      This make this poll entry inconsistent, but we don't care. If you
      share epoll fd which contains our sigfd with another process you
      should blame yourself. signalfd is "really special". I simply do
      not know how we can define the "right" semantics if it used with
      epoll.
      
      The main problem is, epoll calls signalfd_poll() once to establish
      the connection with the wait queue, after that signalfd_poll(NULL)
      returns the different/inconsistent results depending on who does
      EPOLL_CTL_MOD/signalfd_read/etc. IOW: apart from sigmask, signalfd
      has nothing to do with the file, it works with the current thread.
      
      In short: this patch is the hack which tries to fix the symptoms.
      It also assumes that nobody can take tasklist_lock under epoll
      locks, this seems to be true.
      
      Note:
      
      	- we do not have wake_up_all_poll() but wake_up_poll()
      	  is fine, poll/epoll doesn't use WQ_FLAG_EXCLUSIVE.
      
      	- signalfd_cleanup() uses POLLHUP along with POLLFREE,
      	  we need a couple of simple changes in eventpoll.c to
      	  make sure it can't be "lost".
      Reported-by: NMaxime Bizon <mbizon@freebox.fr>
      Cc: <stable@kernel.org>
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d80e731e
  8. 24 2月, 2012 4 次提交
  9. 22 2月, 2012 5 次提交
    • L
      sys_poll: fix incorrect type for 'timeout' parameter · faf30900
      Linus Torvalds 提交于
      The 'poll()' system call timeout parameter is supposed to be 'int', not
      'long'.
      
      Now, the reason this matters is that right now 32-bit compat mode is
      broken on at least x86-64, because the 32-bit code just calls
      'sys_poll()' directly on x86-64, and the 32-bit argument will have been
      zero-extended, turning a signed 'int' into a large unsigned 'long'
      value.
      
      We could just introduce a 'compat_sys_poll()' function for this, and
      that may eventually be what we have to do, but since the actual standard
      poll() semantics is *supposed* to be 'int', and since at least on x86-64
      glibc sign-extends the argument before invocing the system call (so
      nobody can actually use a 64-bit timeout value in user space _anyway_,
      even in 64-bit binaries), the simpler solution would seem to be to just
      fix the definition of the system call to match what it should have been
      from the very start.
      
      If it turns out that somebody somehow circumvents the user-level libc
      64-bit sign extension and actually uses a large unsigned 64-bit timeout
      despite that not being how poll() is supposed to work, we will need to
      do the compat_sys_poll() approach.
      Reported-by: NThomas Meyer <thomas@m3y3r.de>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      faf30900
    • G
      rtnetlink: Fix problem with buffer allocation · 115c9b81
      Greg Rose 提交于
      Implement a new netlink attribute type IFLA_EXT_MASK.  The mask
      is a 32 bit value that can be used to indicate to the kernel that
      certain extended ifinfo values are requested by the user application.
      At this time the only mask value defined is RTEXT_FILTER_VF to
      indicate that the user wants the ifinfo dump to send information
      about the VFs belonging to the interface.
      
      This patch fixes a bug in which certain applications do not have
      large enough buffers to accommodate the extra information returned
      by the kernel with large numbers of SR-IOV virtual functions.
      Those applications will not send the new netlink attribute with
      the interface info dump request netlink messages so they will
      not get unexpectedly large request buffers returned by the kernel.
      
      Modifies the rtnl_calcit function to traverse the list of net
      devices and compute the minimum buffer size that can hold the
      info dumps of all matching devices based upon the filter passed
      in via the new netlink attribute filter mask.  If no filter
      mask is sent then the buffer allocation defaults to NLMSG_GOODSIZE.
      
      With this change it is possible to add yet to be defined netlink
      attributes to the dump request which should make it fairly extensible
      in the future.
      Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      115c9b81
    • P
      sock: Introduce the SO_PEEK_OFF sock option · ef64a54f
      Pavel Emelyanov 提交于
      This one specifies where to start MSG_PEEK-ing queue data from. When
      set to negative value means that MSG_PEEK works as ususally -- peeks
      from the head of the queue always.
      
      When some bytes are peeked from queue and the peeking offset is non
      negative it is moved forward so that the next peek will return next
      portion of data.
      
      When non-peeking recvmsg occurs and the peeking offset is non negative
      is is moved backward so that the next peek will still peek the proper
      data (i.e. the one that would have been picked if there were no non
      peeking recv in between).
      
      The offset is set using per-proto opteration to let the protocol handle
      the locking issues and to check whether the peeking offset feature is
      supported by the protocol the socket belongs to.
      Signed-off-by: NPavel Emelyanov <xemul@parallels.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ef64a54f
    • P
      da5ef6e5
    • P
      datagram: Add offset argument to __skb_recv_datagram · 3f518bf7
      Pavel Emelyanov 提交于
      This one is only considered for MSG_PEEK flag and the value pointed by
      it specifies where to start peeking bytes from. If the offset happens to
      point into the middle of the returned skb, the offset within this skb is
      put back to this very argument.
      Signed-off-by: NPavel Emelyanov <xemul@parallels.com>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3f518bf7
  10. 21 2月, 2012 1 次提交
    • J
      netfilter: ebtables: fix alignment problem in ppc · 88ba136d
      Joerg Willmann 提交于
      ebt_among extension of ebtables uses __alignof__(_xt_align) while the
      corresponding kernel module uses __alignof__(ebt_replace) to determine
      the alignment in EBT_ALIGN().
      
      These are the results of these values on different platforms:
      
      x86 x86_64 ppc
      __alignof__(_xt_align) 4 8 8
      __alignof__(ebt_replace) 4 8 4
      
      ebtables fails to add rules which use the among extension.
      
      I'm using kernel 2.6.33 and ebtables 2.0.10-4
      
      According to Bart De Schuymer, userspace alignment was changed to
      _xt_align to fix an alignment issue on a userspace32-kernel64 system
      (he thinks it was for an ARM device). So userspace must be right.
      The kernel alignment macro needs to change so it also uses _xt_align
      instead of ebt_replace. The userspace changes date back from
      June 29, 2009.
      Signed-off-by: NJoerg Willmann <joe@clnt.de>
      Signed-off by: Bart De Schuymer <bdschuym@pandora.be>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      88ba136d
  11. 20 2月, 2012 1 次提交
  12. 17 2月, 2012 1 次提交
  13. 16 2月, 2012 1 次提交
  14. 14 2月, 2012 5 次提交
    • J
      vfs: Provide function to get superblock and wait for it to thaw · 6b6dc836
      Jan Kara 提交于
      In quota code we need to find a superblock corresponding to a device and wait
      for superblock to be unfrozen. However this waiting has to happen without
      s_umount semaphore because that is required for superblock to thaw. So provide
      a function in VFS for this to keep dances with s_umount where they belong.
      
      [AV: implementation switched to saner variant]
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      6b6dc836
    • S
      mmc: dw_mmc: Fix PIO mode with support of highmem · f9c2a0dc
      Seungwon Jeon 提交于
      Current PIO mode makes a kernel crash with CONFIG_HIGHMEM.
      Highmem pages have a NULL from sg_virt(sg).
      This patch fixes the following problem.
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: Oops: 817 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 0    Not tainted  (3.0.15-01423-gdbf465f #589)
      PC is at dw_mci_pull_data32+0x4c/0x9c
      LR is at dw_mci_read_data_pio+0x54/0x1f0
      pc : [<c0358824>]    lr : [<c035988c>]    psr: 20000193
      sp : c0619d48  ip : c0619d70  fp : c0619d6c
      r10: 00000000  r9 : 00000002  r8 : 00001000
      r7 : 00000200  r6 : 00000000  r5 : e1dd3100  r4 : 00000000
      r3 : 65622023  r2 : 0000007f  r1 : eeb96000  r0 : e1dd3100
      Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment
      xkernel
      Control: 10c5387d  Table: 61e2004a  DAC: 00000015
      Process swapper (pid: 0, stack limit = 0xc06182f0)
      Stack: (0xc0619d48 to 0xc061a000)
      9d40:                   e1dd3100 e1a4f000 00000000 e1dd3100 e1a4f000 00000200
      9d60: c0619da4 c0619d70 c035988c c03587e4 c0619d9c e18158f4 e1dd3100 e1dd3100
      9d80: 00000020 00000000 00000000 00000020 c06e8a84 00000000 c0619e04 c0619da8
      9da0: c0359b24 c0359844 e18158f4 e1dd3164 e1dd3168 e1dd3150 3d02fc79 e1dd3154
      9dc0: e1dd3178 00000000 00000020 00000000 e1dd3150 00000000 c10dd7e8 e1a84900
      9de0: c061e7cc 00000000 00000000 0000008d c06e8a84 c061e780 c0619e4c c0619e08
      9e00: c00c4738 c0359a34 3d02fc79 00000000 c0619e4c c05a1698 c05a1670 c05a165c
      9e20: c04de8b0 c061e780 c061e7cc e1a84900 ffffed68 0000008d c0618000 00000000
      9e40: c0619e6c c0619e50 c00c48b4 c00c46c8 c061e780 c00423ac c061e7cc ffffed68
      9e60: c0619e8c c0619e70 c00c7358 c00c487c 0000008d ffffee38 c0618000 ffffed68
      9e80: c0619ea4 c0619e90 c00c4258 c00c72b0 c00423ac ffffee38 c0619ecc c0619ea8
      9ea0: c004241c c00c4234 ffffffff f8810000 0000006d 00000002 00000001 7fffffff
      9ec0: c0619f44 c0619ed0 c0048bc0 c00423c4 220ae7a9 00000000 386f0d30 0005d3a4
      9ee0: c00423ac c10dd0b8 c06f2cd8 c0618000 c0594778 c003a674 7fffffff c0619f44
      9f00: 386f0d30 c0619f18 c00a6f94 c005be3c 80000013 ffffffff 386f0d30 0005d3a4
      9f20: 386f0d30 0005d2d1 c10dd0a8 c10dd0b8 c06f2cd8 c0618000 c0619f74 c0619f48
      9f40: c0345858 c005be00 c00a2440 c0618000 c0618000 c00410d8 c06c1944 c00410fc
      9f60: c0594778 c003a674 c0619f9c c0619f78 c004a7e8 c03457b4 c0618000 c06c18f8
      9f80: 00000000 c0039c70 c06c18d4 c003a674 c0619fb4 c0619fa0 c04ceafc c004a714
      9fa0: c06287b4 c06c18f8 c0619ff4 c0619fb8 c0008b68 c04cea68 c0008578 00000000
      9fc0: 00000000 c003a674 00000000 10c5387d c0628658 c003aa78 c062f1c4 4000406a
      9fe0: 413fc090 00000000 00000000 c0619ff8 40008044 c0008858 00000000 00000000
      Backtrace:
      [<c03587d8>] (dw_mci_pull_data32+0x0/0x9c) from [<c035988c>] (dw_mci_read_data_pio+0x54/0x1f0)
       r6:00000200 r5:e1a4f000 r4:e1dd3100
       [<c0359838>] (dw_mci_read_data_pio+0x0/0x1f0) from [<c0359b24>] (dw_mci_interrupt+0xfc/0x4a4)
      [<c0359a28>] (dw_mci_interrupt+0x0/0x4a4) from [<c00c4738>] (handle_irq_event_percpu+0x7c/0x1b4)
      [<c00c46bc>] (handle_irq_event_percpu+0x0/0x1b4) from [<c00c48b4>] (handle_irq_event+0x44/0x64)
      [<c00c4870>] (handle_irq_event+0x0/0x64) from [<c00c7358>] (handle_fasteoi_irq+0xb4/0x124)
       r7:ffffed68 r6:c061e7cc r5:c00423ac r4:c061e780
       [<c00c72a4>] (handle_fasteoi_irq+0x0/0x124) from [<c00c4258>] (generic_handle_irq+0x30/0x38)
       r7:ffffed68 r6:c0618000 r5:ffffee38 r4:0000008d
       [<c00c4228>] (generic_handle_irq+0x0/0x38) from [<c004241c>] (asm_do_IRQ+0x64/0xe0)
       r5:ffffee38 r4:c00423ac
       [<c00423b8>] (asm_do_IRQ+0x0/0xe0) from [<c0048bc0>] (__irq_svc+0x80/0x14c)
      Exception stack(0xc0619ed0 to 0xc0619f18)
      Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
      Acked-by: NWill Newton <will.newton@imgtec.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      f9c2a0dc
    • G
      mmc: core: Fix PowerOff Notify suspend/resume · 3e73c36b
      Girish K S 提交于
      Modified the mmc_poweroff to resume before sending the poweroff
      notification command. In sleep mode only AWAKE and RESET commands are
      allowed, so before sending the poweroff notification command resume from
      sleep mode and then send the notification command.
      
      PowerOff Notify is tested on a Synopsis Designware Host Controller
      (eMMC 4.5). The suspend to RAM and resume works fine.
      Signed-off-by: NGirish K S <girish.shivananjappa@linaro.org>
      Tested-by: NGirish K S <girish.shivananjappa@linaro.org>
      Reviewed-by: NSaugata Das <saugata.das@linaro.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      3e73c36b
    • J
      mmc: core: add the capability for broken voltage · 6e8201f5
      Jaehoon Chung 提交于
      There is an understood mismatch between the voltage the host controller is
      set to and the voltage supplied to the card by a fixed voltage regulator.
      Teaching the driver to accept the mismatch is overly complicated.  Instead
      just accept the regulator's voltage.
      
      This patch adds MMC_CAP2_BROKEN_VOLTAGE.
      
      If the voltage didn't satisfy between min_uV and max_uV, try to change
      the voltage in core.c.  When changing the voltage, maybe use
      regulator_set_voltage().
      
      In regulator_set_voltage(), check the below condition.
      
      	/* sanity check */
      	if (!rdev->desc->ops->set_voltage &&
      	    !rdev->desc->ops->set_voltage_sel) {
      		ret = -EINVAL;
      		goto out;
      	}
      
      If some board should use the fixed-regulator, always return -EINVAL.
      Then, eMMC didn't initialize always.
      
      So if use a fixed-regulator, we need to add the MMC_CAP2_BROKEN_VOLTAGE.
      Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      6e8201f5
    • S
      mmc: core: Ensure clocks are always enabled before host interaction · 2c4967f7
      Sujit Reddy Thumma 提交于
      Ensure clocks are always enabled before any interaction with the
      host controller driver. This makes sure that there is no race
      between host execution and the core layer turning off clocks
      in different context with clock gating framework.
      Signed-off-by: NSujit Reddy Thumma <sthumma@codeaurora.org>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Acked-by: NPer Forlin <per.forlin@stericsson.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      2c4967f7
  15. 13 2月, 2012 3 次提交
  16. 11 2月, 2012 2 次提交
    • A
      skbuff: Move rxhash and vlan_tci to consolidate holes in sk_buff · 4031ae6e
      Alexander Duyck 提交于
      This change helps to reduce the overall size of the sk_buff by moving
      rxhash and vlan_tci so that the u16 values and u8 bitfields can be better
      combined to create only one hole instead of multiple.
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
      Tested-by: NStephen Ko <stephen.s.ko@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4031ae6e
    • S
      USB: Remove duplicate USB 3.0 hub feature #defines. · d9f5343e
      Sarah Sharp 提交于
      Somehow we ended up with duplicate hub feature #defines in ch11.h.
      Tatyana Brokhman first created the USB 3.0 hub feature macros in 2.6.38
      with commit 0eadcc09 "usb: USB3.0 ch11
      definitions".  In 2.6.39, I modified a patch from John Youn that added
      similar macros in a different place in the same file, and committed
      dbe79bbe "USB 3.0 Hub Changes".
      
      Some of the #defines used different names for the same values.  Others
      used exactly the same names with the same values, like these gems:
      
       #define USB_PORT_FEAT_BH_PORT_RESET     28
      ...
       #define USB_PORT_FEAT_BH_PORT_RESET            28
      
      According to my very geeky husband (who looked it up in the C99 spec),
      it is allowed to have object-like macros with duplicate names as long as
      the replacement list is exactly the same.  However, he recalled that
      some compilers will give warnings when they find duplicate macros.  It's
      probably best to remove the duplicates in the stable tree, so that the
      code compiles for everyone.
      
      The macros are now fixed to move the feature requests that are specific
      to USB 3.0 hubs into a new section (out of the USB 2.0 hub feature
      section), and use the most common macro name.
      
      This patch should be backported to 2.6.39.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Tatyana Brokhman <tlinder@codeaurora.org>
      Cc: John Youn <johnyoun@synopsys.com>
      Cc: Jamey Sharp <jamey@minilop.net>
      Cc: stable@vger.kernel.org
      d9f5343e
  17. 09 2月, 2012 1 次提交