1. 04 7月, 2012 5 次提交
  2. 03 7月, 2012 24 次提交
    • M
      dm: verity fix documentation · 18068bdd
      Milan Broz 提交于
      Veritysetup is now part of cryptsetup package.
      Remove on-disk header description (which is not parsed in kernel)
      and point users to cryptsetup where it the format is documented.
      Mention units for block size paramaters.
      Fix target line specification and dmsetup parameters.
      Signed-off-by: NMilan Broz <mbroz@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      18068bdd
    • M
      dm persistent data: fix allocation failure in space map checker init · b0239faa
      Mike Snitzer 提交于
      If CONFIG_DM_DEBUG_SPACE_MAPS is enabled and memory is fragmented and a
      sufficiently-large metadata device is used in a thin pool then the space
      map checker will fail to allocate the memory it requires.
      
      Switch from kmalloc to vmalloc to allow larger virtually contiguous
      allocations for the space map checker's internal count arrays.
      Reported-by: NVivek Goyal <vgoyal@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      b0239faa
    • M
      dm persistent data: handle space map checker creation failure · 62662303
      Mike Snitzer 提交于
      If CONFIG_DM_DEBUG_SPACE_MAPS is enabled and dm_sm_checker_create()
      fails, dm_tm_create_internal() would still return success even though it
      cleaned up all resources it was supposed to have created.  This will
      lead to a kernel crash:
      
      general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
      ...
      RIP: 0010:[<ffffffff81593659>]  [<ffffffff81593659>] dm_bufio_get_block_size+0x9/0x20
      Call Trace:
        [<ffffffff81599bae>] dm_bm_block_size+0xe/0x10
        [<ffffffff8159b8b8>] sm_ll_init+0x78/0xd0
        [<ffffffff8159c1a6>] sm_ll_new_disk+0x16/0xa0
        [<ffffffff8159c98e>] dm_sm_disk_create+0xfe/0x160
        [<ffffffff815abf6e>] dm_pool_metadata_open+0x16e/0x6a0
        [<ffffffff815aa010>] pool_ctr+0x3f0/0x900
        [<ffffffff8158d565>] dm_table_add_target+0x195/0x450
        [<ffffffff815904c4>] table_load+0xe4/0x330
        [<ffffffff815917ea>] ctl_ioctl+0x15a/0x2c0
        [<ffffffff81591963>] dm_ctl_ioctl+0x13/0x20
        [<ffffffff8116a4f8>] do_vfs_ioctl+0x98/0x560
        [<ffffffff8116aa51>] sys_ioctl+0x91/0xa0
        [<ffffffff81869f52>] system_call_fastpath+0x16/0x1b
      
      Fix the space map checker code to return an appropriate ERR_PTR and have
      dm_sm_disk_create() and dm_tm_create_internal() check for it with
      IS_ERR.
      Reported-by: NVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      62662303
    • M
      dm persistent data: fix shadow_info_leak on dm_tm_destroy · 25d7cd6f
      Mike Snitzer 提交于
      Cleanup the shadow table before destroying the transaction manager.
      
      Reference: leak was identified with kmemleak when running
      test_discard_random_sectors in the thinp-test-suite.
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      25d7cd6f
    • J
      dm thin: commit metadata before creating metadata snapshot · 0d200aef
      Joe Thornber 提交于
      Userland sometimes sees a corrupt metadata block if metadata is changing
      rapidly when a metadata snapshot is reserved for userland,  To make the
      problem go away, commit before we take the metadata snapshot (which is a
      sensible thing to do anyway).
      
      The checksums mean userland spots this corruption immediately so there's
      no risk of acting on incorrect data.  No corruption exists from the
      kernel's point of view, and thin_check passes after pool shutdown.
      
      I believe this is to do with shared blocks at the first level of the
      {device, mapping} btree.  Prior to the metadata-snap support no sharing
      at this level was possible, so this patch is only required after commit
      cc8394d8 ("dm thin: provide userspace
      access to pool metadata").
      Signed-off-by: NJoe Thornber <ejt@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      0d200aef
    • P
      security: Fix nommu build. · 75331a59
      Paul Mundt 提交于
      The security + nommu configuration presently blows up with an undefined
      reference to BDI_CAP_EXEC_MAP:
      
      security/security.c: In function 'mmap_prot':
      security/security.c:687:36: error: dereferencing pointer to incomplete type
      security/security.c:688:16: error: 'BDI_CAP_EXEC_MAP' undeclared (first use in this function)
      security/security.c:688:16: note: each undeclared identifier is reported only once for each function it appears in
      
      include backing-dev.h directly to fix it up.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      75331a59
    • D
      drm/i915: kick any firmware framebuffers before claiming the gtt · 9f846a16
      Daniel Vetter 提交于
      Especially vesafb likes to map everything as uc- (yikes), and if that
      mapping hangs around still while we try to map the gtt as wc the
      kernel will downgrade our request to uc-, resulting in abyssal
      performance.
      
      Unfortunately we can't do this as early as readon does (i.e. as the
      first thing we do when initializing the hw) because our fb/mmio space
      region moves around on a per-gen basis. So I've had to move it below
      the gtt initialization, but that seems to work, too. The important
      thing is that we do this before we set up the gtt wc mapping.
      
      Now an altogether different question is why people compile their
      kernels with vesafb enabled, but I guess making things just work isn't
      bad per se ...
      
      v2:
      - s/radeondrmfb/inteldrmfb/
      - fix up error handling
      
      v3: Kill #ifdef X86, this is Intel after all. Noticed by Ben Widawsky.
      
      v4: Jani Nikula complained about the pointless bool primary
      initialization.
      
      v5: Don't oops if we can't allocate, noticed by Chris Wilson.
      
      v6: Resolve conflicts with agp rework and fixup whitespace.
      
      This is commit e188719a in drm-next.
      
      Backport to 3.5 -fixes queue requested by Dave Airlie - due to grub
      using vesa on fedora their initrd seems to load vesafb before loading
      the real kms driver. So tons more people actually experience a
      dead-slow gpu. Hence also the Cc: stable.
      
      Cc: stable@vger.kernel.org
      Reported-and-tested-by: N"Kilarski, Bernard R" <bernard.r.kilarski@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      9f846a16
    • T
      drm: edid: Don't add inferred modes with higher resolution · 7b668ebe
      Takashi Iwai 提交于
      When a monitor EDID doesn't give the preferred bit, driver assumes
      that the mode with the higest resolution and rate is the preferred
      mode.  Meanwhile the recent changes for allowing more modes in the
      GFT/CVT ranges give actually more modes, and some modes may be over
      the native size.  Thus such a mode would be picked up as the preferred
      mode although it's no native resolution.
      
      For avoiding such a problem, this patch limits the addition of
      inferred modes by checking not to be greater than other modes.
      Also, it checks the duplicated mode entry at the same time.
      Reviewed-by: NAdam Jackson <ajax@redhat.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      7b668ebe
    • J
      drm/radeon: fix rare segfault · 1ef5325b
      Jerome Glisse 提交于
      In gem idle/busy ioctl the radeon object was derefenced after
      drm_gem_object_unreference_unlocked which in case the object
      have been destroyed lead to use of a possibly free pointer with
      possibly wrong data.
      Signed-off-by: NJerome Glisse <jglisse@redhat.com>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      1ef5325b
    • N
      md: fix up plugging (again). · b357f04a
      NeilBrown 提交于
      The value returned by "mddev_check_plug" is only valid until the
      next 'schedule' as that will unplug things.  This could happen at any
      call to mempool_alloc.
      So just calling mddev_check_plug at the start doesn't really make
      sense.
      
      So call it just before, or just after, queuing things for the thread.
      As the action that happens at unplug is to wake the thread, this makes
      lots of sense.
      If we cannot add a plug (which requires a small GFP_ATOMIC alloc) we
      wake thread immediately.
      
      RAID5 is a bit different.  Requests are queued for the thread and the
      thread is woken by release_stripe.  So we don't need to wake the
      thread on failure.
      However the thread doesn't perform certain actions when there is any
      active plug, so it is important to install a plug before waking the
      thread.  So for RAID5 we install the plug *before* queuing the request
      and waking the thread.
      
      Without this patch it is possible for raid1 or raid10 to queue a
      request without then waking the thread, resulting in the array locking
      up.
      
      Also change raid10 to only flush_pending_write when there are not
      active plugs, just like raid1.
      
      This patch is suitable for 3.0 or later.  I plan to submit it to
      -stable, but I'll like to let it spend a few weeks in mainline
      first to be sure it is completely safe.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      b357f04a
    • N
      md: support re-add of recovering devices. · f4563091
      NeilBrown 提交于
      We currently only allow a device to be re-added if it appear to be
      in-sync.  This is overly restrictive as it may be desirable to re-add
      a device that is in the middle of recovery.
      
      So remove the test for "InSync" - the test on rdev->raid_disk is
      sufficient to ensure that the re-add will succeed.
      Reported-by: NAlexander Lyakas <alex.bolshoy@gmail.com>
      Tested-by: NAlexander Lyakas <alex.bolshoy@gmail.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      f4563091
    • N
      md/raid1: fix bug in read_balance introduced by hot-replace · 32644afd
      NeilBrown 提交于
      When we added hot_replace we doubled the number of devices
      that could be in a RAID1 array.  So we doubled how far read_balance
      would search.  Unfortunately we didn't double the point at which
      it looped back to the beginning - so it effectively loops over
      all non-replacement disks twice.
      This doesn't cause bad behaviour, but it pointless and means we
      never read from replacement devices.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      32644afd
    • S
      raid5: delayed stripe fix · fab363b5
      Shaohua Li 提交于
      There isn't locking setting STRIPE_DELAYED and STRIPE_PREREAD_ACTIVE bits, but
      the two bits have relationship. A delayed stripe can be moved to hold list only
      when preread active stripe count is below IO_THRESHOLD. If a stripe has both
      the bits set, such stripe will be in delayed list and preread count not 0,
      which will make such stripe never leave delayed list.
      Signed-off-by: NShaohua Li <shli@fusionio.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      fab363b5
    • M
      md/raid456: When read error cannot be recovered, record bad block · 2e8ac303
      majianpeng 提交于
      We may not be able to fix a bad block if:
       - the array is degraded
       - the over-write fails.
      
      In these cases we currently eject the device, but we should
      record a bad block if possible.
      Signed-off-by: Nmajianpeng <majianpeng@gmail.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      2e8ac303
    • N
      md: make 'name' arg to md_register_thread non-optional. · 0232605d
      NeilBrown 提交于
      Having the 'name' arg optional and defaulting to the current
      personality name is no necessary and leads to errors, as when
      changing the level of an array we can end up using the
      name of the old level instead of the new one.
      
      So make it non-optional and always explicitly pass the name
      of the level that the array will be.
      Reported-by: Nmajianpeng <majianpeng@gmail.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      0232605d
    • N
      md/raid10: fix failure when trying to repair a read error. · 055d3747
      NeilBrown 提交于
      commit 58c54fcc
           md/raid10: handle further errors during fix_read_error better.
      
      in 3.1 added "r10_sync_page_io" which takes an IO size in sectors.
      But we were passing the IO size in bytes!!!
      This resulting in bio_add_page failing, and empty request being sent
      down, and a consequent BUG_ON in scsi_lib.
      
      [fix missing space in error message at same time]
      
      This fix is suitable for 3.1.y and later.
      
      Cc: stable@vger.kernel.org
      Reported-by: NChristian Balzer <chibi@gol.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      055d3747
    • L
      Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc · 9d4056aa
      Linus Torvalds 提交于
      Pull a couple more powerpc fixes from Benjamin Herrenschmidt:
       "Here are two more fixes that I "missed" when scrubbing patchwork last
        week which are worth still having in 3.5."
      
      * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
        powerpc/kvm: sldi should be sld
        powerpc/xmon: Use cpumask iterator to avoid warning
      9d4056aa
    • A
      security: document no_new_privs · 09b24357
      Andy Lutomirski 提交于
      Document no_new_privs.
      Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
      Acked-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      09b24357
    • N
      md/raid5: fix refcount problem when blocked_rdev is set. · 5f066c63
      NeilBrown 提交于
      commit 43220aa0
          md/raid5: fix a hang on device failure.
      
      fixed a hang, but introduced a refcounting in-balance so
      that if the presence of bad-blocks ever caused an rdev to
      be 'blocked' we would increment the refcount on the rdev and
      never decrement it.
      
      So added the needed rdev_dec_pending when md_wait_for_blocked_rdev
      is not called.
      Reported-by: Nmajianpeng <majianpeng@gmail.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      5f066c63
    • M
      md:Add blk_plug in sync_thread. · 7c2c57c9
      majianpeng 提交于
      Add blk_plug in sync_thread will increase the performance of sync.
      Because sync_thread did not blk_plug,so when raid sync, the bio merge
      not well.
      
      Testing environment:
      SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI
      Controller.
      OS:Linux xxx 3.5.0-rc2+ #340 SMP Tue Jun 12 09:00:25 CST 2012
      x86_64 x86_64 x86_64 GNU/Linux.
      RAID5: four ST31000524NS disk.
      
      Without blk_plug:recovery speed about 63M/Sec;
      Add blk_plug:recovery speed about 120M/Sec.
      
      Using blktrace:
      blktrace -d /dev/sdb -w 60  -o -|blkparse -i -
      
      without blk_plug:
      Total (8,16):
       Reads Queued:      309811,     1239MiB	 Writes Queued:           0,        0KiB
       Read Dispatches:   283583,     1189MiB	 Write Dispatches:        0,        0KiB
       Reads Requeued:         0		 Writes Requeued:         0
       Reads Completed:   273351,     1149MiB	 Writes Completed:        0,        0KiB
       Read Merges:        23533,    94132KiB	 Write Merges:            0,        0KiB
       IO unplugs:             0        	 Timer unplugs:           0
      
      add blk_plug:
      Total (8,16):
       Reads Queued:      428697,     1714MiB	 Writes Queued:           0,        0KiB
       Read Dispatches:     3954,     1714MiB	 Write Dispatches:        0,        0KiB
       Reads Requeued:         0		 Writes Requeued:         0
       Reads Completed:     3956,     1715MiB	 Writes Completed:        0,        0KiB
       Read Merges:       424743,     1698MiB	 Write Merges:            0,        0KiB
       IO unplugs:             0        	 Timer unplugs:        3384
      
      The ratio of merge will be markedly increased.
      Signed-off-by: Nmajianpeng <majianpeng@gmail.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      7c2c57c9
    • M
      md/raid5: In ops_run_io, inc nr_pending before calling md_wait_for_blocked_rdev · 1850753d
      majianpeng 提交于
      In ops_run_io(), the call to md_wait_for_blocked_rdev will decrement
      nr_pending so we lose the reference we hold on the rdev.
      So atomic_inc it first to maintain the reference.
      
      This bug was introduced by commit  73e92e51
          md/raid5.  Don't write to known bad block on doubtful devices.
      
      which appeared in 3.0, so patch is suitable for stable kernels since
      then.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: Nmajianpeng <majianpeng@gmail.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      1850753d
    • M
      md/raid5: Do not add data_offset before call to is_badblock · 6c0544e2
      majianpeng 提交于
      In chunk_aligned_read() we are adding data_offset before calling
      is_badblock.  But is_badblock also adds data_offset, so that is bad.
      
      So move the addition of data_offset to after the call to
      is_badblock.
      
      This bug was introduced by commit 31c176ec
           md/raid5: avoid reading from known bad blocks.
      which first appeared in 3.0.  So that patch is suitable for any
      -stable kernel from 3.0.y onwards.  However it will need minor
      revision for most of those (as the comment didn't appear until
      recently).
      
      Cc: stable@vger.kernel.org
      Signed-off-by: Nmajianpeng <majianpeng@gmail.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      6c0544e2
    • N
      md/raid5: prefer replacing failed devices over want-replacement devices. · 5cfb22a1
      NeilBrown 提交于
      If a RAID5 has both a failed device and a device marked as
      'WantReplacement', then we should preferentially replace the failed
      device.
      However the current code replaces whichever is found first.
      So split into 2 loops, check fail failed/missing first, and only check
      for WantReplacement if nothing is failed or missing.
      Reported-by: Nmajianpeng <majianpeng@gmail.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      5cfb22a1
    • N
      md/raid10: Don't try to recovery unmatched (and unused) chunks. · fc448a18
      NeilBrown 提交于
      If a RAID10 has an odd number of chunks - as might happen when there
      are an odd number of devices - the last chunk has no pair and so is
      not mirrored.  We don't store data there, but when recovering the last
      device in an array we retry to recover that last chunk from a
      non-existent location.  This results in an error, and the recovery
      aborts.
      
      When we get to that last chunk we should just stop - there is nothing
      more to do anyway.
      
      This bug has been present since the introduction of RAID10, so the
      patch is appropriate for any -stable kernel.
      
      Cc: stable@vger.kernel.org
      Reported-by: NChristian Balzer <chibi@gol.com>
      Tested-by: NChristian Balzer <chibi@gol.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      fc448a18
  3. 02 7月, 2012 3 次提交
    • M
      powerpc/kvm: sldi should be sld · 2f584a14
      Michael Neuling 提交于
      Since we are taking a registers, this should never have been an sldi.
      Talking to paulus offline, this is the correct fix.
      
      Was introduced by:
       commit 19ccb76a
       Author: Paul Mackerras <paulus@samba.org>
       Date:   Sat Jul 23 17:42:46 2011 +1000
      
      Talking to paulus, this shouldn't be a literal.
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      CC: <stable@kernel.org> [v3.2+]
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      2f584a14
    • A
      powerpc/xmon: Use cpumask iterator to avoid warning · bc1d7702
      Anton Blanchard 提交于
      We have a bug report where the kernel hits a warning in the cpumask
      code:
      
      WARNING: at include/linux/cpumask.h:107
      
      Which is:
              WARN_ON_ONCE(cpu >= nr_cpumask_bits);
      
      The backtrace is:
              cpu_cmd
              cmds
              xmon_core
              xmon
              die
      
      xmon is iterating through 0 to NR_CPUS. I'm not sure why we are still
      open coding this but iterating above nr_cpu_ids is definitely a bug.
      
      This patch iterates through all possible cpus, in case we issue a
      system reset and CPUs in an offline state call in.
      
      Perhaps the old code was trying to handle CPUs that were in the
      partition but were never started (eg kexec into a kernel with an
      nr_cpus= boot option). They are going to die way before we get into
      xmon since we haven't set any kernel state up for them.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      CC: <stable@kernel.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      bc1d7702
    • L
      Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm · ca24a145
      Linus Torvalds 提交于
      Pull two ARM fixes from Russell King:
       "It's been fairly quiet with the fixes.  Just two this time.  One fixes
        a long standing problem with KALLSYMS needing an additional pass, and
        the other sorts a problem with the vmalloc space interacting with
        static IO mappings."
      
      * 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
        ARM: 7438/1: fill possible PMD empty section gaps
        ARM: 7428/1: Prevent KALLSYM size mismatch on ARM.
      ca24a145
  4. 01 7月, 2012 8 次提交