1. 01 7月, 2012 1 次提交
  2. 26 6月, 2012 1 次提交
    • P
      bug.h: Fix up CONFIG_BUG=n implicit function declarations. · 09682c1d
      Paul Mundt 提交于
      Commit 2603efa3 ("bug.h: Fix up powerpc build regression") corrected
      the powerpc build case and extended the __ASSEMBLY__ guards, but it also
      got caught in pre-processor hell accidentally matching the else case of
      CONFIG_BUG resulting in the BUG disabled case tripping up on
      -Werror=implicit-function-declaration.
      
      It's not possible to __ASSEMBLY__ guard the entire file as architecture
      code needs to get at the BUGFLAG_WARNING definition in the GENERIC_BUG
      case, but the rest of the CONFIG_BUG=y/n case needs to be guarded.
      
      Rather than littering endless __ASSEMBLY__ checks in each of the if/else
      cases we just move the BUGFLAG definitions up under their own
      GENERIC_BUG test and then shove everything else under one big
      __ASSEMBLY__ guard.
      
      Build tested on all of x86 CONFIG_BUG=y, CONFIG_BUG=n, powerpc (due to
      it's dependence on BUGFLAG definitions in assembly code), and sh (due to
      not bringing in linux/kernel.h to satisfy the taint flag definitions used
      by the generic bug code).
      
      Hopefully that's the end of the corner cases and I can abstain from ever
      having to touch this infernal header ever again.
      Reported-by: NFengguang Wu <fengguang.wu@intel.com>
      Tested-by: NFengguang Wu <wfg@linux.intel.com>
      Acked-by: NRandy Dunlap <rdunlap@xenotime.net>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      09682c1d
  3. 23 6月, 2012 1 次提交
    • A
      SCSI & usb-storage: add try_rc_10_first flag · 6a0bdffa
      Alan Stern 提交于
      Several bug reports have been received recently for USB mass-storage
      devices that don't handle READ CAPACITY(16) commands properly.  They
      report bogus sizes, in some cases becoming unusable as a result.
      
      The bugs were triggered by commit
      09b6b51b (SCSI & usb-storage: add
      flags for VPD pages and REPORT LUNS), which caused usb-storage to stop
      overriding the SCSI level reported by devices.  By default, the sd
      driver will try READ CAPACITY(16) first for any device whose level is
      above SCSI_SPC_2.
      
      It seems likely that any device large enough to require the use of
      READ CAPACITY(16) (i.e., 2 TB or more) would be able to handle READ
      CAPACITY(10) commands properly.  Indeed, I don't know of any devices
      that don't handle READ CAPACITY(10) properly.
      
      Therefore this patch (as1559) adds a new flag telling the sd driver
      to try READ CAPACITY(10) before READ CAPACITY(16), and sets this flag
      for every USB mass-storage device.  If a device really is larger than
      2 TB, sd will fall back to READ CAPACITY(16) just as it used to.
      
      This fixes Bugzilla #43391.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NHans de Goede <hdegoede@redhat.com>
      CC: "James E.J. Bottomley" <JBottomley@parallels.com>
      CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a0bdffa
  4. 22 6月, 2012 1 次提交
  5. 21 6月, 2012 4 次提交
  6. 19 6月, 2012 2 次提交
  7. 18 6月, 2012 3 次提交
    • S
      ftrace: Make all inline tags also include notrace · 93b3cca1
      Steven Rostedt 提交于
      Commit 5963e317 ("ftrace/x86: Do not change stacks in DEBUG when
      calling lockdep") prevented lockdep calls from the int3 breakpoint handler
      from reseting the stack if a function that was called was in the process
      of being converted for tracing and had a breakpoint on it. The idea is,
      before calling the lockdep code, do a load_idt() to the special IDT that
      kept the breakpoint stack from reseting. This worked well as a quick fix
      for this kernel release, until a certain config caused a lockup in the
      function tracer start up tests.
      
      Investigating it, I found that the load_idt that was used to prevent
      the int3 from changing stacks was itself being traced!
      
      Even though the config had CONFIG_OPTIMIZE_INLINING disabled, and
      all 'inline' tags were set to always inline, there were still cases that
      it did not inline! This was caused by CONFIG_PARAVIRT_GUEST, where it
      would add a pointer to the native_load_idt() which made that function
      to be traced.
      
      Commit 45959ee7 ("ftrace: Do not function trace inlined functions")
      only touched the 'inline' tags when CONFIG_OPMITIZE_INLINING was enabled.
      PARAVIRT_GUEST shows that this was not enough and we need to also
      mark always_inline with notrace as well.
      Reported-by: NFengguang Wu <wfg@linux.intel.com>
      Tested-by: NFengguang Wu <wfg@linux.intel.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      93b3cca1
    • T
      NFSv4.1: Fix umount when filelayout DS is also the MDS · 2a4c8994
      Trond Myklebust 提交于
      Currently there is a 'chicken and egg' issue when the DS is also the mounted
      MDS. The nfs_match_client() reference from nfs4_set_ds_client bumps the
      cl_count, the nfs_client is not freed at umount, and nfs4_deviceid_purge_client
      is not called to dereference the MDS usage of a deviceid which holds a
      reference to the DS nfs_client.  The result is the umount program returns,
      but the nfs_client is not freed, and the cl_session hearbeat continues.
      
      The MDS (and all other nfs mounts) lose their last nfs_client reference in
      nfs_free_server when the last nfs_server (fsid) is umounted.
      The file layout DS lose their last nfs_client reference in destroy_ds
      when the last deviceid referencing the data server is put and destroy_ds is
      called. This is triggered by a call to nfs4_deviceid_purge_client which
      removes references to a pNFS deviceid used by an MDS mount.
      
      The fix is to track how many pnfs enabled filesystems are mounted from
      this server, and then to purge the device id cache once that count reaches
      zero.
      Reported-by: NJorge Mora <Jorge.Mora@netapp.com>
      Reported-by: NAndy Adamson <andros@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      2a4c8994
    • R
      net: remove my future former mail address · 31fdc555
      Rémi Denis-Courmont 提交于
      Signed-off-by: NRémi Denis-Courmont <remi@remlab.net>
      Cc: Sakari Ailus <sakari.ailus@nokia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      31fdc555
  8. 16 6月, 2012 6 次提交
  9. 14 6月, 2012 3 次提交
  10. 13 6月, 2012 2 次提交
    • J
      target: Add TFO->put_session() caller for HW fabric session shutdown · 4149268e
      Joern Engel 提交于
      This patch adds an optional target_core_fabric_ops->put_session() caller
      within the existing target_put_session() code path.
      
      This is required by tcm_qla2xxx code in order to invoke it's own fabric
      specific session shutdown handler using se_session->sess_kref.
      Signed-off-by: NJoern Engel <joern@logfs.org>
      Cc: Roland Dreier <roland@purestorage.com>
      Cc: Arun Easi <arun.easi@qlogic.com>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      4149268e
    • E
      bonding: Fix corrupted queue_mapping · 5ee31c68
      Eric Dumazet 提交于
      In the transmit path of the bonding driver, skb->cb is used to
      stash the skb->queue_mapping so that the bonding device can set its
      own queue mapping.  This value becomes corrupted since the skb->cb is
      also used in __dev_xmit_skb.
      
      When transmitting through bonding driver, bond_select_queue is
      called from dev_queue_xmit.  In bond_select_queue the original
      skb->queue_mapping is copied into skb->cb (via bond_queue_mapping)
      and skb->queue_mapping is overwritten with the bond driver queue.
      
      Subsequently in dev_queue_xmit, __dev_xmit_skb is called which writes
      the packet length into skb->cb, thereby overwriting the stashed
      queue mappping.  In bond_dev_queue_xmit (called from hard_start_xmit),
      the queue mapping for the skb is set to the stashed value which is now
      the skb length and hence is an invalid queue for the slave device.
      
      If we want to save skb->queue_mapping into skb->cb[], best place is to
      add a field in struct qdisc_skb_cb, to make sure it wont conflict with
      other layers (eg : Qdiscc, Infiniband...)
      
      This patchs also makes sure (struct qdisc_skb_cb)->data is aligned on 8
      bytes :
      
      netem qdisc for example assumes it can store an u64 in it, without
      misalignment penalty.
      
      Note : we only have 20 bytes left in (struct qdisc_skb_cb)->data[].
      The largest user is CHOKe and it fills it.
      
      Based on a previous patch from Tom Herbert.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NTom Herbert <therbert@google.com>
      Cc: John Fastabend <john.r.fastabend@intel.com>
      Cc: Roland Dreier <roland@kernel.org>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5ee31c68
  11. 12 6月, 2012 3 次提交
    • P
      drm: increase DRM_OBJECT_MAX_PROPERTY to 24 · fe456168
      Paulo Zanoni 提交于
      Before Kernel 3.5, no one was checking for the return value of
      drm_connector_attach_property, so we never noticed that we were unable
      to create some properties. Commit "drm: WARN() when
      drm_connector_attach_property fails" added a WARN when we fail to
      create a property, and the transition from "connector properties" to
      "object properties" changed the warning message a little bit.
      
      On i915 machines with many TV connectors we hit the maximum number of
      properties (since each TV connector uses a lot of properties), so we
      get a few backtraces in our logs. This commit increases the maximum
      number of properties to 24 hoping we'll have enough room for
      everybody.
      
      Chris suggested that we convert this code to "lists", but I believe
      this conversion can come after we make sure people's dmesgs are not
      spammed by our driver.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reported-by: NDave Jones <davej@redhat.com>
      Tested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      fe456168
    • H
      [media] snd_tea575x: Make the module using snd_tea575x the fops owner · 5daf53a6
      Hans de Goede 提交于
      Before this patch the owner field of the /dev/radio# device fops was set to
      the snd-tea575x-tuner module itself. Meaning that the module which was using
      it could be rmmod-ed while the device is open, and then BAD things happen.
      
      I know, as I found out the hard way :)
      
      Note that there is no need to also somehow increase the refcount of the
      snd-tea575x-tuner module itself, since any drivers using it will have
      symbolic references to it.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      CC: Ondrej Zary <linux@rainbow-software.org>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      5daf53a6
    • H
      [media] Fix regression in ioctl numbering · 1761a110
      Hans Verkuil 提交于
      Yuck. The VIDIOC_(TRY_)DECODER_CMD ioctls already had ioctl numbers 96 and 97,
      and after merging the timings API I forgot to continue numbering from 98. So
      now we have two ioctls with number 96 and two with 97.
      
      With the new table-driver ioctl handling in v4l2-ioctl.c it is essential that
      each ioctl has its own unique number, so let's fix this quickly for 3.5.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      1761a110
  12. 11 6月, 2012 4 次提交
  13. 10 6月, 2012 1 次提交
    • P
      net: Make linux/tcp.h C++ friendly (trivial) · 8876d6b5
      Paul Pluzhnikov 提交于
      I originally sent this patch to <trivial@kernel.org>, but Jiri Kosina did
      not feel that this is fully appropriate for the trivial tree.
      
      Using linux/tcp.h from C++ results in:
      
      cat t.cc
      #include <linux/tcp.h>
      int main() { }
      
      g++ -c t.cc
      
      In file included from t.cc:1:
      /usr/include/linux/tcp.h:72: error: '__u32 __fswab32(__u32)' cannot appear in a constant-expression
      /usr/include/linux/tcp.h:72: error: a function call cannot appear in a constant-expression
      ...
      
      Attached trivial patch fixes this problem.
      
      Tested:
      - the t.cc above compiles with g++ and
      - the following program generates the same output before/after
        the patch:
      
      #include <linux/tcp.h>
      #include <stdio.h>
      
      int main ()
      {
      #define P(a) printf("%s: %08x\n", #a, (int)a)
       P(TCP_FLAG_CWR);
       P(TCP_FLAG_ECE);
       P(TCP_FLAG_URG);
       P(TCP_FLAG_ACK);
       P(TCP_FLAG_PSH);
       P(TCP_FLAG_RST);
       P(TCP_FLAG_SYN);
       P(TCP_FLAG_FIN);
       P(TCP_RESERVED_BITS);
       P(TCP_DATA_OFFSET);
      #undef P
       return 0;
      }
      Signed-off-by: NPaul Pluzhnikov <ppluzhnikov@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8876d6b5
  14. 09 6月, 2012 2 次提交
  15. 08 6月, 2012 5 次提交
  16. 07 6月, 2012 1 次提交