1. 06 2月, 2013 15 次提交
  2. 05 2月, 2013 17 次提交
  3. 04 2月, 2013 8 次提交
    • M
      zram: give up lazy initialization of zram metadata · 3de738cd
      Minchan Kim 提交于
      1) User of zram normally do mkfs.xxx or mkswap before using
         the zram block device(ex, normally, do it at booting time)
         It ends up allocating such metadata of zram before real usage so
         benefit of lazy initialzation would be mitigated.
      
      2) Some user want to use zram when memory pressure is high.(ie, load zram
         dynamically, NOT booting time). It does make sense because people don't
         want to waste memory until memory pressure is high(ie, where zram is really
         helpful time). In this case, lazy initialzation could be failed easily
         because we will use GFP_NOIO instead of GFP_KERNEL for avoiding deadlock.
         So the benefit of lazy initialzation would be mitigated, too.
      
      3) Metadata overhead is not critical and Nitin has a plan to diet it.
         4K : 12 byte(64bit machine) -> 64G : 192M so 0.3% isn't big overhead
         If insane user use such big zram device up to 20, it could consume 6% of ram
         but efficieny of zram will cover the waste.
      
      So this patch gives up lazy initialization and instead we initialize metadata
      at disksize setting time.
      Acked-by: NJerome Marchand <jmarchand@redhat.com>
      Acked-by: NNitin Gupta <ngupta@vflare.org>
      Signed-off-by: NMinchan Kim <minchan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3de738cd
    • M
      zram: force disksize setting before using zram · 0231c403
      Minchan Kim 提交于
      Now zram document syas "set disksize is optional"
      but partly it's wrong. When you try to use zram firstly after
      booting, you must set disksize, otherwise zram can't work because
      zram gendisk's size is 0. But once you do it, you can use zram freely
      after reset because reset doesn't reset to zero paradoxically.
      So in this time, disksize setting is optional.:(
      It's inconsitent for user behavior and not straightforward.
      
      This patch forces always setting disksize firstly before using zram.
      Yes. It changes current behavior so someone could complain when
      he upgrades zram. Apparently it could be a problem if zram is mainline
      but it still lives in staging so behavior could be changed for right
      way to go. Let them excuse.
      Acked-by: NJerome Marchand <jmarchand@redhat.com>
      Acked-by: NNitin Gupta <ngupta@vflare.org>
      Acked-by: NDan Magenheimer <dan.magenheimer@oracle.com>
      Signed-off-by: NMinchan Kim <minchan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0231c403
    • M
      zram: Fix deadlock bug in partial read/write · 7e5a5104
      Minchan Kim 提交于
      Now zram allocates new page with GFP_KERNEL in zram I/O path
      if IO is partial. Unfortunately, It may cause deadlock with
      reclaim path like below.
      
      write_page from fs
      fs_lock
      allocation(GFP_KERNEL)
      reclaim
      pageout
      				write_page from fs
      				fs_lock <-- deadlock
      
      This patch fixes it by using GFP_NOIO.  In read path, we
      reorganize code flow so that kmap_atomic is called after the
      GFP_NOIO allocation.
      
      Cc: stable@vger.kernel.org
      Acked-by: NJerome Marchand <jmarchand@redhat.com>
      Acked-by: NNitin Gupta <ngupta@vflare.org>
      [ penberg@kernel.org: don't use GFP_ATOMIC ]
      Signed-off-by: NPekka Enberg <penberg@kernel.org>
      Signed-off-by: NMinchan Kim <minchan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7e5a5104
    • H
      pci_ids.h: add common pci vendor ids from comedi subsystem · 7f70410f
      H Hartley Sweeten 提交于
      There are a number of pci vendor ids that are used in multiple
      drivers in the comedi subsystem. Move these ids to pci_ids.h.
      
      This also fixes some build warnings reported by the kbuild test
      robot about PCI_VENDOR_ID_AMPLICON being undeclared.
      Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7f70410f
    • I
      staging: comedi: ni_labpc: correct differential channel sequence for AI commands · 4c4bc25d
      Ian Abbott 提交于
      Tuomas <tvainikk _at_ gmail _dot_ com> reported problems getting
      meaningful output from a Lab-PC+ in differential mode for AI cmds, but
      AI insn reads gave correct readings.  He tracked it down to two
      problems, one of which is addressed by this patch.
      
      It seems the setting of the channel bits for particular scanning modes
      was incorrect for differential mode.  (Only half the number of channels
      are available in differential mode; comedi refers to them as channels 0,
      1, 2 and 3, but the hardware documentation refers to them as channels 0,
      2, 4 and 6.)  In differential mode, the setting of the channel enable
      bits in the command1 register should depend on whether the scan enable
      bit is set.  Effectively, we need to double the comedi channel number
      when the scan enable bit is not set in differential mode.  The scan
      enable bit gets set when the AI scan mode is `MODE_MULT_CHAN_UP` or
      `MODE_MULT_CHAN_DOWN`, and gets cleared when the AI scan mode is
      `MODE_SINGLE_CHAN` or `MODE_SINGLE_CHAN_INTERVAL`.  The existing test
      for whether the comedi channel number needs to be doubled in
      differential mode is incorrect in `labpc_ai_cmd()`.  This patch corrects
      the test.
      
      Thanks to Tuomas for suggesting the fix.
      Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
      Cc: <stable@vger.kernel.org> # 3.7.x, 3.8.x
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4c4bc25d
    • I
      staging: comedi: ni_labpc: set up command4 register *after* command3 · 22056e2b
      Ian Abbott 提交于
      Tuomas <tvainikk _at_ gmail _dot_ com> reported problems getting
      meaningful output from a Lab-PC+ in differential mode for AI cmds, but
      AI insn reads gave correct readings.  He tracked it down to two
      problems, one of which is addressed by this patch.
      
      It seems that writing to the command3 register after writing to the
      command4 register in `labpc_ai_cmd()` messes up the differential
      reference bit setting in the command4 register.  Set up the command4
      register after the command3 register (as in `labpc_ai_rinsn()`) to avoid
      the problem.
      
      Thanks to Tuomas for suggesting the fix.
      Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
      Cc: <stable@vger.kernel.org> # 3.7.x, 3.8.x
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22056e2b
    • I
      staging: comedi: restrict comedi_set_hw_dev() usage · de06d7c6
      Ian Abbott 提交于
      Don't allow comedi drivers to change `dev->hw_dev` using
      `comedi_set_hw_dev()` if it's already been set.  Return `-EEXIST` in
      that case.
      
      `dev->hw_dev` needs to be set to NULL by the core during clean-up of the
      comedi device, so add a local function `comedi_clear_hw_dev()` to do
      that.
      Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de06d7c6
    • I
      staging: comedi: export comedi_set_hw_dev() · da717511
      Ian Abbott 提交于
      Chnage the inline `comedi_set_hw_dev()` to an exported function and
      change it's return type from `void` to `int` so we can impose some
      restrictions (in a later patch) and return an error if necessary.
      
      Only a few comedi drivers call this, although they don't need to if the
      hardware device has been attached automatically via
      `comedi_auto_config()` and the comedi driver's `auto_attach()` method.
      Signed-off-by: NIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      da717511