1. 10 Jun, 2015 7 commits
    • Viresh Kumar's avatar
      cpufreq: Remove cpufreq_update_policy() · 37829029
      Viresh Kumar authored
      cpufreq_update_policy() was kept as a separate routine earlier as it was
      handling migration of sysfs directories, which isn't the case anymore.
      It is only updating policy->cpu now and is called by a single caller.
      
      The WARN_ON() isn't really required anymore, as we are just updating the
      cpu now, not moving the sysfs directories.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      37829029
    • Viresh Kumar's avatar
      cpufreq: Restart governor as soon as possible · 9591becb
      Viresh Kumar authored
      __cpufreq_remove_dev_finish() is doing two things today:
      - Restarts the governor if some CPUs from concerned policy are still
        online.
      - Frees the policy if all CPUs are offline.
      
      The first task of restarting the governor can be moved to
      __cpufreq_remove_dev_prepare() to restart the governor early. There is
      no race between _prepare() and _finish() as they would be handling
      completely different cases. _finish() will only be required if we are
      going to free the policy and that has nothing to do with restarting the
      governor.
      Original-by: default avatarSaravana Kannan <skannan@codeaurora.org>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9591becb
    • Viresh Kumar's avatar
      cpufreq: Call cpufreq_policy_put_kobj() from cpufreq_policy_free() · 3654c5cc
      Viresh Kumar authored
      cpufreq_policy_put_kobj() is actually part of freeing the policy and can
      be called from cpufreq_policy_free() directly instead of a separate
      call.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3654c5cc
    • Viresh Kumar's avatar
      cpufreq: Initialize policy->kobj while allocating policy · 2fc3384d
      Viresh Kumar authored
      policy->kobj is required to be initialized once in the lifetime of a
      policy.  Currently we are initializing it from __cpufreq_add_dev() and
      that doesn't look to be the best place for doing so as we have to do
      this on special cases (like: !recover_policy).
      
      We can initialize it from a more obvious place cpufreq_policy_alloc()
      and that will make code look cleaner, specially the error handling part.
      
      The error handling part of __cpufreq_add_dev() was doing almost the same
      thing while recover_policy is true or false. Fix that as well by always
      calling cpufreq_policy_put_kobj() with an additional parameter to skip
      notification part of it.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2fc3384d
    • Viresh Kumar's avatar
      cpufreq: Stop migrating sysfs files on hotplug · 87549141
      Viresh Kumar authored
      When we hot-unplug a cpu, we remove its sysfs cpufreq directory and if
      the outgoing cpu was the owner of policy->kobj earlier then we migrate
      the sysfs directory to under another online cpu.
      
      There are few disadvantages this brings:
      - Code Complexity
      - Slower hotplug/suspend/resume
      - sysfs file permissions are reset after all policy->cpus are offlined
      - CPUFreq stats history lost after all policy->cpus are offlined
      - Special management of sysfs stuff during suspend/resume
      
      To overcome these, this patch modifies the way sysfs directories are
      managed:
      - Select sysfs kobjects owner while initializing policy and don't change
        it during hotplugs. Track it with kobj_cpu created earlier.
      
      - Create symlinks for all related CPUs (can be offline) instead of
        affected CPUs on policy initialization and remove them only when the
        policy is freed.
      
      - Free policy structure only on the removal of cpufreq-driver and not
        during hotplug/suspend/resume, detected by checking 'struct
        subsys_interface *' (Valid only when called from
        subsys_interface_unregister() while unregistering driver).
      
      Apart from this, special care is taken to handle physical hoplug of CPUs
      as we wouldn't remove sysfs links or remove policies on logical
      hotplugs. Physical hotplug happens in the following sequence.
      
      Hot removal:
      - CPU is offlined first, ~ 'echo 0 >
        /sys/devices/system/cpu/cpuX/online'
      - Then its device is removed along with all sysfs files, cpufreq core
        notified with cpufreq_remove_dev() callback from subsys-interface..
      
      Hot addition:
      - First the device along with its sysfs files is added, cpufreq core
        notified with cpufreq_add_dev() callback from subsys-interface..
      - CPU is onlined, ~ 'echo 1 > /sys/devices/system/cpu/cpuX/online'
      
      We call the same routines with both hotplug and subsys callbacks, and we
      sense physical hotplug with cpu_offline() check in subsys callback. We
      can handle most of the stuff with regular hotplug callback paths and
      add/remove cpufreq sysfs links or free policy from subsys callbacks.
      Original-by: default avatarSaravana Kannan <skannan@codeaurora.org>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      87549141
    • Viresh Kumar's avatar
      cpufreq: Don't allow updating inactive policies from sysfs · 11e584cf
      Viresh Kumar authored
      Later commits would change the way policies are managed today. Policies
      wouldn't be freed on cpu hotplug (currently they aren't freed only for
      suspend), and while the CPU is offline, the sysfs cpufreq files would
      still be present.
      
      User may accidentally try to update the sysfs files in following
      directory: '/sys/devices/system/cpu/cpuX/cpufreq/'. And that would
      result in undefined behavior as policy wouldn't be active then.
      
      Apart from updating the store() routine, we also update __cpufreq_get()
      which can call cpufreq_out_of_sync(). The later routine tries to update
      policy->cur and starts notifying kernel about it.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: default avatarSaravana Kannan <skannan@codeaurora.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      11e584cf
    • Doug Smythies's avatar
      intel_pstate: Force setting target pstate when required · 6c1e4591
      Doug Smythies authored
      During initialization and exit it is possible that the target pstate
      might not actually be set. Furthermore, the result can be that the
      driver and the processor are out of synch and, under some conditions,
      the driver might never send the processor the proper target pstate.
      
      This patch adds a bypass or do_checks flag to the call to
      intel_pstate_set_pstate. If bypass, then specifically bypass clamp
      checks and the do not send if it is the same as last time check. If
      do_checks, then, and as before, do the current policy clamp checks,
      and do not do actual send if the new target is the same as the old.
      Signed-off-by: default avatarDoug Smythies <dsmythies@telus.net>
      Reported-by: default avatarMarien Zwart <marien.zwart@gmail.com>
      Reported-by: default avatarAlex Lochmann <alexander.lochmann@tu-dortmund.de>
      Reported-by: default avatarPiotr Ko?aczkowski <pkolaczk@gmail.com>
      Reported-by: default avatarClemens Eisserer <linuxhippy@gmail.com>
      Tested-by: default avatarMarien Zwart <marien.zwart@gmail.com>
      Tested-by: default avatarDoug Smythies <dsmythies@telus.net>
      [ rjw: Dropped pointless symbol definitions, rebased ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6c1e4591
  2. 09 Jun, 2015 1 commit
  3. 22 May, 2015 2 commits
  4. 15 May, 2015 6 commits
  5. 14 May, 2015 1 commit
  6. 12 May, 2015 1 commit
  7. 07 May, 2015 5 commits
  8. 05 May, 2015 1 commit
  9. 04 May, 2015 8 commits
  10. 03 May, 2015 8 commits
    • Dave Airlie's avatar
      Merge tag 'drm-intel-fixes-2015-04-30' of git://anongit.freedesktop.org/drm-intel into drm-fixes · 71aee819
      Dave Airlie authored
      Just a single intel fix
      * tag 'drm-intel-fixes-2015-04-30' of git://anongit.freedesktop.org/drm-intel:
        drm/i915/chv: Implement WaDisableShadowRegForCpd
      71aee819
    • Dave Airlie's avatar
      Merge branch 'drm-next0420' of https://github.com/markyzq/kernel-drm-rockchip into drm-fixes · df9ebeb2
      Dave Airlie authored
      one fix and maintainers update
      * 'drm-next0420' of https://github.com/markyzq/kernel-drm-rockchip:
        drm/rockchip: fix error check when getting irq
        MAINTAINERS: add entry for Rockchip drm drivers
      df9ebeb2
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 61f06db0
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "This is three logical fixes (as 5 patches).
      
        The 3ware class of drivers were causing an oops with multiqueue by
        tearing down the command mappings after completing the command (where
        the variables in the command used to tear down the mapping were
        no-longer valid).  There's also a fix for the qnap iscsi target which
        was choking on us sending it commands that were too long and a fix for
        the reworked aha1542 allocating GFP_KERNEL under a lock"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        3w-9xxx: fix command completion race
        3w-xxxx: fix command completion race
        3w-sas: fix command completion race
        aha1542: Allocate memory before taking a lock
        SCSI: add 1024 max sectors black list flag
      61f06db0
    • Linus Torvalds's avatar
      Merge branch 'next' of git://git.infradead.org/users/vkoul/slave-dma · 33332224
      Linus Torvalds authored
      Pull slave dmaengine fixes from Vinod Koul:
       "Here are the fixes in dmaengine subsystem for rc2:
      
         - privatecnt fix for slave dma request API by Christopher
      
         - warn fix for PM ifdef in usb-dmac by Geert
      
         - fix hardware dependency for xgene by Jean"
      
      * 'next' of git://git.infradead.org/users/vkoul/slave-dma:
        dmaengine: increment privatecnt when using dma_get_any_slave_channel
        dmaengine: xgene: Set hardware dependency
        dmaengine: usb-dmac: Protect PM-only functions to kill warning
      33332224
    • Linus Torvalds's avatar
      Merge tag 'powerpc-4.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux · 180d89f6
      Linus Torvalds authored
      Pull powerpc fixes from Michael Ellerman:
       - build fix for SMP=n in book3s_xics.c
       - fix for Daniel's pci_controller_ops on powernv.
       - revert the TM syscall abort patch for now.
       - CPU affinity fix from Nathan.
       - two EEH fixes from Gavin.
       - fix for CR corruption from Sam.
       - selftest build fix.
      
      * tag 'powerpc-4.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux:
        powerpc/powernv: Restore non-volatile CRs after nap
        powerpc/eeh: Delay probing EEH device during hotplug
        powerpc/eeh: Fix race condition in pcibios_set_pcie_reset_state()
        powerpc/pseries: Correct cpu affinity for dlpar added cpus
        selftests/powerpc: Fix the pmu install rule
        Revert "powerpc/tm: Abort syscalls in active transactions"
        powerpc/powernv: Fix early pci_controller_ops loading.
        powerpc/kvm: Fix SMP=n build error in book3s_xics.c
      180d89f6
    • Jan Kara's avatar
      ext4: fix growing of tiny filesystems · 2c869b26
      Jan Kara authored
      The estimate of necessary transaction credits in ext4_flex_group_add()
      is too pessimistic. It reserves credit for sb, resize inode, and resize
      inode dindirect block for each group added in a flex group although they
      are always the same block and thus it is enough to account them only
      once. Also the number of modified GDT block is overestimated since we
      fit EXT4_DESC_PER_BLOCK(sb) descriptors in one block.
      
      Make the estimation more precise. That reduces number of requested
      credits enough that we can grow 20 MB filesystem (which has 1 MB
      journal, 79 reserved GDT blocks, and flex group size 16 by default).
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarEric Sandeen <sandeen@redhat.com>
      2c869b26
    • Davide Italiano's avatar
      ext4: move check under lock scope to close a race. · 280227a7
      Davide Italiano authored
      fallocate() checks that the file is extent-based and returns
      EOPNOTSUPP in case is not. Other tasks can convert from and to
      indirect and extent so it's safe to check only after grabbing
      the inode mutex.
      Signed-off-by: default avatarDavide Italiano <dccitaliano@gmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      280227a7
    • Lukas Czerner's avatar
      ext4: fix data corruption caused by unwritten and delayed extents · d2dc317d
      Lukas Czerner authored
      Currently it is possible to lose whole file system block worth of data
      when we hit the specific interaction with unwritten and delayed extents
      in status extent tree.
      
      The problem is that when we insert delayed extent into extent status
      tree the only way to get rid of it is when we write out delayed buffer.
      However there is a limitation in the extent status tree implementation
      so that when inserting unwritten extent should there be even a single
      delayed block the whole unwritten extent would be marked as delayed.
      
      At this point, there is no way to get rid of the delayed extents,
      because there are no delayed buffers to write out. So when a we write
      into said unwritten extent we will convert it to written, but it still
      remains delayed.
      
      When we try to write into that block later ext4_da_map_blocks() will set
      the buffer new and delayed and map it to invalid block which causes
      the rest of the block to be zeroed loosing already written data.
      
      For now we can fix this by simply not allowing to set delayed status on
      written extent in the extent status tree. Also add WARN_ON() to make
      sure that we notice if this happens in the future.
      
      This problem can be easily reproduced by running the following xfs_io.
      
      xfs_io -f -c "pwrite -S 0xaa 4096 2048" \
                -c "falloc 0 131072" \
                -c "pwrite -S 0xbb 65536 2048" \
                -c "fsync" /mnt/test/fff
      
      echo 3 > /proc/sys/vm/drop_caches
      xfs_io -c "pwrite -S 0xdd 67584 2048" /mnt/test/fff
      
      This can be theoretically also reproduced by at random by running fsx,
      but it's not very reliable, though on machines with bigger page size
      (like ppc) this can be seen more often (especially xfstest generic/127)
      Signed-off-by: default avatarLukas Czerner <lczerner@redhat.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      d2dc317d