1. 12 1月, 2013 2 次提交
    • R
      module: put modules in list much earlier. · 1fb9341a
      Rusty Russell 提交于
      Prarit's excellent bug report:
      > In recent Fedora releases (F17 & F18) some users have reported seeing
      > messages similar to
      >
      > [   15.478160] kvm: Could not allocate 304 bytes percpu data
      > [   15.478174] PERCPU: allocation failed, size=304 align=32, alloc from
      > reserved chunk failed
      >
      > during system boot.  In some cases, users have also reported seeing this
      > message along with a failed load of other modules.
      >
      > What is happening is systemd is loading an instance of the kvm module for
      > each cpu found (see commit e9bda3b3).  When the module load occurs the kernel
      > currently allocates the modules percpu data area prior to checking to see
      > if the module is already loaded or is in the process of being loaded.  If
      > the module is already loaded, or finishes load, the module loading code
      > releases the current instance's module's percpu data.
      
      Now we have a new state MODULE_STATE_UNFORMED, we can insert the
      module into the list (and thus guarantee its uniqueness) before we
      allocate the per-cpu region.
      Reported-by: NPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Tested-by: NPrarit Bhargava <prarit@redhat.com>
      1fb9341a
    • R
      module: add new state MODULE_STATE_UNFORMED. · 0d21b0e3
      Rusty Russell 提交于
      You should never look at such a module, so it's excised from all paths
      which traverse the modules list.
      
      We add the state at the end, to avoid gratuitous ABI break (ksplice).
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      0d21b0e3
  2. 03 1月, 2013 1 次提交
  3. 02 1月, 2013 1 次提交
    • A
      virtio-blk: Don't free ida when disk is in use · f4953fe6
      Alexander Graf 提交于
      When a file system is mounted on a virtio-blk disk, we then remove it
      and then reattach it, the reattached disk gets the same disk name and
      ids as the hot removed one.
      
      This leads to very nasty effects - mostly rendering the newly attached
      device completely unusable.
      
      Trying what happens when I do the same thing with a USB device, I saw
      that the sd node simply doesn't get free'd when a device gets forcefully
      removed.
      
      Imitate the same behavior for vd devices. This way broken vd devices
      simply are never free'd and newly attached ones keep working just fine.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: stable@kernel.org
      f4953fe6
  4. 24 12月, 2012 1 次提交
  5. 22 12月, 2012 35 次提交