1. 18 Jun, 2016 1 commit
    • Linus Torvalds's avatar
      Merge tag 'pm-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 057868ea
      Linus Torvalds authored
      Pull power management fixes from Rafael Wysocki:
       "Fixes for two recent regressions that may lead to degraded performance
        (operating performance points framework, intel_pstate).
      
        Specifics:
      
         - Fix a recent regression in the intel_pstate driver that may lead to
           degraded performance on some systems due to missing turbo state
           entry in the table returned by the ACPI _PSS object (Srinivas
           Pandruvada).
      
         - Fix a recent regression in the OPP (operating performance points)
           framework that may lead to degraded performance on some systems
           where the OPP table is created too early (Viresh Kumar)"
      
      * tag 'pm-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        PM / OPP: Add 'UNKNOWN' status for shared_opp in struct opp_table
        cpufreq: intel_pstate: Adjust _PSS[0] freqeuency if needed
      057868ea
  2. 17 Jun, 2016 6 commits
  3. 16 Jun, 2016 9 commits
    • Linus Torvalds's avatar
      Merge tag 'pwm/for-4.7-rc4' of... · bb967271
      Linus Torvalds authored
      Merge tag 'pwm/for-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
      
      Pull pwm fixes from Thierry Reding:
       "These changes fix a bit of fallout from the introduction of the atomic
        API"
      
      * tag 'pwm/for-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm:
        pwm: atmel-hlcdc: Fix default PWM polarity
        pwm: sysfs: Get return value from pwm_apply_state()
        pwm: Improve args checking in pwm_apply_state()
      bb967271
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · 2668bc77
      Linus Torvalds authored
      Pull KVM fixes from Paolo Bonzini:
      
       - miscellaneous fixes for MIPS and s390
      
       - one new kvm_stat for s390
      
       - correctly disable VT-d posted interrupts with the rest of posted
         interrupts
      
       - "make randconfig" fix for x86 AMD
      
       - off-by-one in irq route check (the "good" kind that errors out a bit
         too early!)
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        kvm: vmx: check apicv is active before using VT-d posted interrupt
        kvm: Fix irq route entries exceeding KVM_MAX_IRQ_ROUTES
        kvm: svm: Do not support AVIC if not CONFIG_X86_LOCAL_APIC
        kvm: svm: Fix implicit declaration for __default_cpu_present_to_apicid()
        MIPS: KVM: Fix CACHE triggered exception emulation
        MIPS: KVM: Don't unwind PC when emulating CACHE
        MIPS: KVM: Include bit 31 in segment matches
        MIPS: KVM: Fix modular KVM under QEMU
        KVM: s390: Add stats for PEI events
        KVM: s390: ignore IBC if zero
      2668bc77
    • Linus Torvalds's avatar
      Merge tag 'nfsd-4.7-1' of git://linux-nfs.org/~bfields/linux · 41ef7218
      Linus Torvalds authored
      Pull nfsd bugfixes from Bruce Fields:
       "Oleg Drokin found and fixed races in the nfsd4 state code that go back
        to the big nfs4_lock_state removal around 3.17 (but that were also
        probably hard to reproduce before client changes in 3.20 allowed the
        client to perform parallel opens).
      
        Also fix a 4.1 backchannel crash due to rpc multipath changes in 4.6.
        Trond acked the client-side rpc fixes going through my tree"
      
      * tag 'nfsd-4.7-1' of git://linux-nfs.org/~bfields/linux:
        nfsd: Make init_open_stateid() a bit more whole
        nfsd: Extend the mutex holding region around in nfsd4_process_open2()
        nfsd: Always lock state exclusively.
        rpc: share one xps between all backchannels
        nfsd4/rpc: move backchannel create logic into rpc code
        SUNRPC: fix xprt leak on xps allocation failure
        nfsd: Fix NFSD_MDS_PR_KEY on 32-bit by adding ULL postfix
      41ef7218
    • Linus Torvalds's avatar
      Merge branch 'overlayfs-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs · 9c514bed
      Linus Torvalds authored
      Pull overlayfs fixes from Miklos Szeredi:
       "This contains two regression fixes: one for the xattr API update and
        one for using the mounter's creds in file creation in overlayfs.
      
        There's also a fix for a bug in handling hard linked AF_UNIX sockets
        that's been there from day one.  This fix is overlayfs only despite
        the fact that it touches code outside the overlay filesystem: d_real()
        is an identity function for all except overlay dentries"
      
      * 'overlayfs-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs:
        ovl: fix uid/gid when creating over whiteout
        ovl: xattr filter fix
        af_unix: fix hard linked sockets on overlay
        vfs: add d_real_inode() helper
      9c514bed
    • Dan Carpenter's avatar
      KEYS: potential uninitialized variable · 38327424
      Dan Carpenter authored
      If __key_link_begin() failed then "edit" would be uninitialized.  I've
      added a check to fix that.
      
      This allows a random user to crash the kernel, though it's quite
      difficult to achieve.  There are three ways it can be done as the user
      would have to cause an error to occur in __key_link():
      
       (1) Cause the kernel to run out of memory.  In practice, this is difficult
           to achieve without ENOMEM cropping up elsewhere and aborting the
           attempt.
      
       (2) Revoke the destination keyring between the keyring ID being looked up
           and it being tested for revocation.  In practice, this is difficult to
           time correctly because the KEYCTL_REJECT function can only be used
           from the request-key upcall process.  Further, users can only make use
           of what's in /sbin/request-key.conf, though this does including a
           rejection debugging test - which means that the destination keyring
           has to be the caller's session keyring in practice.
      
       (3) Have just enough key quota available to create a key, a new session
           keyring for the upcall and a link in the session keyring, but not then
           sufficient quota to create a link in the nominated destination keyring
           so that it fails with EDQUOT.
      
      The bug can be triggered using option (3) above using something like the
      following:
      
      	echo 80 >/proc/sys/kernel/keys/root_maxbytes
      	keyctl request2 user debug:fred negate @t
      
      The above sets the quota to something much lower (80) to make the bug
      easier to trigger, but this is dependent on the system.  Note also that
      the name of the keyring created contains a random number that may be
      between 1 and 10 characters in size, so may throw the test off by
      changing the amount of quota used.
      
      Assuming the failure occurs, something like the following will be seen:
      
      	kfree_debugcheck: out of range ptr 6b6b6b6b6b6b6b68h
      	------------[ cut here ]------------
      	kernel BUG at ../mm/slab.c:2821!
      	...
      	RIP: 0010:[<ffffffff811600f9>] kfree_debugcheck+0x20/0x25
      	RSP: 0018:ffff8804014a7de8  EFLAGS: 00010092
      	RAX: 0000000000000034 RBX: 6b6b6b6b6b6b6b68 RCX: 0000000000000000
      	RDX: 0000000000040001 RSI: 00000000000000f6 RDI: 0000000000000300
      	RBP: ffff8804014a7df0 R08: 0000000000000001 R09: 0000000000000000
      	R10: ffff8804014a7e68 R11: 0000000000000054 R12: 0000000000000202
      	R13: ffffffff81318a66 R14: 0000000000000000 R15: 0000000000000001
      	...
      	Call Trace:
      	  kfree+0xde/0x1bc
      	  assoc_array_cancel_edit+0x1f/0x36
      	  __key_link_end+0x55/0x63
      	  key_reject_and_link+0x124/0x155
      	  keyctl_reject_key+0xb6/0xe0
      	  keyctl_negate_key+0x10/0x12
      	  SyS_keyctl+0x9f/0xe7
      	  do_syscall_64+0x63/0x13a
      	  entry_SYSCALL64_slow_path+0x25/0x25
      
      Fixes: f70e2e06
      
       ('KEYS: Do preallocation for __key_link()')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      38327424
    • Daniel Thompson's avatar
      arm64: kgdb: Match pstate size with gdbserver protocol · 0d15ef67
      Daniel Thompson authored
      Current versions of gdb do not interoperate cleanly with kgdb on arm64
      systems because gdb and kgdb do not use the same register description.
      This patch modifies kgdb to work with recent releases of gdb (>= 7.8.1).
      
      Compatibility with gdb (after the patch is applied) is as follows:
      
        gdb-7.6 and earlier  Ok
        gdb-7.7 series       Works if user provides custom target description
        gdb-7.8(.0)          Works if user provides custom target description
        gdb-7.8.1 and later  Ok
      
      When commit 44679a4f ("arm64: KGDB: Add step debugging support") was
      introduced it was paired with a gdb patch that made an incompatible
      change to the gdbserver protocol. This patch was eventually merged into
      the gdb sources:
      https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=a4d9ba85ec5597a6a556afe26b712e878374b9dd
      
      The change to the protocol was mostly made to simplify big-endian support
      inside the kernel gdb stub. Unfortunately the gdb project released
      gdb-7.7.x and gdb-7.8.0 before the protocol incompatibility was identified
      and reversed:
      https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bdc144174bcb11e808b4e73089b850cf9620a7ee
      
      
      
      This leaves us in a position where kgdb still uses the no-longer-used
      protocol; gdb-7.8.1, which restored the original behaviour, was
      released on 2014-10-29.
      
      I don't believe it is possible to detect/correct the protocol
      incompatiblity which means the kernel must take a view about which
      version of the gdb remote protocol is "correct". This patch takes the
      view that the original/current version of the protocol is correct
      and that version found in gdb-7.7.x and gdb-7.8.0 is anomalous.
      Signed-off-by: default avatarDaniel Thompson <daniel.thompson@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      0d15ef67
    • Viresh Kumar's avatar
      PM / OPP: Add 'UNKNOWN' status for shared_opp in struct opp_table · 79ee2e8f
      Viresh Kumar authored
      dev_pm_opp_get_sharing_cpus() returns 0 even in the case when the OPP
      core doesn't know whether or not the table is shared. It works on the
      majority of platforms, where the OPP table is never created before
      invoking the function and then -ENODEV is returned by it.
      
      But in the case of one platform (Jetson TK1) at least, the situation
      is a bit different. The OPP table has been created (somehow) before
      dev_pm_opp_get_sharing_cpus() is called and it returns 0. Its caller
      treats that as 'the CPUs don't share OPPs' and that leads to degraded
      performance.
      
      Fix this by converting 'shared_opp' in struct opp_table to an enum
      and making dev_pm_opp_get_sharing_cpus() return -EINVAL in case when
      the value of that field is "access unknown", so that the caller can
      handle it accordingly (cpufreq-dt considers that as 'all CPUs share
      the table', for example).
      
      Fixes: 6f707daa
      
       "PM / OPP: Add dev_pm_opp_get_sharing_cpus()"
      Reported-and-tested-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      [ rjw : Subject & changelog ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      79ee2e8f
    • Yang Zhang's avatar
      kvm: vmx: check apicv is active before using VT-d posted interrupt · a0052191
      Yang Zhang authored
      VT-d posted interrupt is relying on the CPU side's posted interrupt.
      Need to check whether VCPU's APICv is active before enabing VT-d
      posted interrupt.
      
      Fixes: d62caabb
      
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarYang Zhang <yang.zhang.wz@gmail.com>
      Signed-off-by: default avatarShengge Ding <shengge.dsg@alibaba-inc.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      a0052191
    • Xiubo Li's avatar
      kvm: Fix irq route entries exceeding KVM_MAX_IRQ_ROUTES · caf1ff26
      Xiubo Li authored
      These days, we experienced one guest crash with 8 cores and 3 disks,
      with qemu error logs as bellow:
      
      qemu-system-x86_64: /build/qemu-2.0.0/kvm-all.c:984:
      kvm_irqchip_commit_routes: Assertion `ret == 0' failed.
      
      And then we found one patch(bdf026317d) in qemu tree, which said
      could fix this bug.
      
      Execute the following script will reproduce the BUG quickly:
      
      irq_affinity.sh
      ========================================================================
      
      vda_irq_num=25
      vdb_irq_num=27
      while [ 1 ]
      do
          for irq in {1,2,4,8,10,20,40,80}
              do
                  echo $irq > /proc/irq/$vda_irq_num/smp_affinity
                  echo $irq > /proc/irq/$vdb_irq_num/smp_affinity
                  dd if=/dev/vda of=/dev/zero bs=4K count=100 iflag=direct
                  dd if=/dev/vdb of=/dev/zero bs=4K count=100 iflag=direct
              done
      done
      ========================================================================
      
      The following qemu log is added in the qemu code and is displayed when
      ...
      caf1ff26
  4. 15 Jun, 2016 24 commits