Skip to content

L
linux
Switch branch/tag
  1. 14 Dec, 2015 11 commits
    • Tadeusz Struk's avatar
      crypto: qat - don't use userspace pointer · a2fda70b
      Tadeusz Struk authored 
      commit 176155da upstream.

Bugfix - don't dereference userspace pointer.
Signed-off-by: default avatarTadeusz Struk <tadeusz.struk@intel.com>
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      a2fda70b
    • Dave Hansen's avatar
      x86/fpu: Fix 32-bit signal frame handling · 12f05325
      Dave Hansen authored 
      commit ab6b5294 upstream.

(This should have gone to LKML originally. Sorry for the extra
 noise, folks on the cc.)

Background:

Signal frames on x86 have two formats:

  1. For 32-bit executables (whether on a real 32-bit kernel or
     under 32-bit emulation on a 64-bit kernel) we have a
    'fpregset_t' that includes the "FSAVE" registers.

  2. For 64-bit executables (on 64-bit kernels obviously), the
     'fpregset_t' is smaller and does not contain the "FSAVE"
     state.

When creating the signal frame, we have to be aware of whether
we are running a 32 or 64-bit executable so we create the
correct format signal frame.

Problem:

save_xstate_epilog() uses 'fx_sw_reserved_ia32' whenever it is
called for a 32-bit executable.  This is for real 32-bit and
ia32 emulation.

But, fpu__init_prepare_fx_sw_frame() only initializes
'fx_sw_reserved_ia32' when emulation is enabled, *NOT* for real
32-bit kernels.

This leads to really wierd situations where 32-bit programs
lose their extended state when returning from a signal handler.
The kernel copies the uninitialized (zero) 'fx_sw_reserved_ia32'
out to userspace in save_xstate_epilog().  But when returning
from the signal, the kernel errors out in check_for_xstate()
when it does not see FP_XSTATE_MAGIC1 present (because it was
zeroed).  This leads to the FPU/XSAVE state being initialized.

For MPX, this leads to the most permissive state and means we
silently lose bounds violations.  I think this would also mean
that we could lose *ANY* FPU/SSE/AVX state.  I'm not sure why
no one has spotted this bug.

I believe this was broken by:

	72a671ce ("x86, fpu: Unify signal handling code paths for x86 and x86_64 kernels")

way back in 2012.
Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dave@sr71.net
Cc: fenghua.yu@intel.com
Cc: yu-cheng.yu@intel.com
Link: http://lkml.kernel.org/r/20151111002354.A0799571@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
[ kamal: backport to 3.19-stable: applied to kernel/xsave.c; context ]
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      12f05325
    • Dave Hansen's avatar
      x86/mpx: Do proper get_user() when running 32-bit binaries on 64-bit kernels · abaae23a
      Dave Hansen authored 
      commit 46561c39 upstream.

When you call get_user(foo, bar), you effectively do a

	copy_from_user(&foo, bar, sizeof(*bar));

Note that the sizeof() is implicit.

When we reach out to userspace to try to zap an entire "bounds
table" we need to go read a "bounds directory entry" in order to
locate the table's address.  The size of a "directory entry"
depends on the binary being run and is always the size of a
pointer.

But, when we have a 64-bit kernel and a 32-bit application, the
directory entry is still only 32-bits long, but we fetch it with
a 64-bit pointer which makes get_user() does a 64-bit fetch.
Reading 4 extra bytes isn't harmful, unless we are at the end of
and run off the table.  It might also cause the zero page to get
faulted in unnecessarily even if you are not at the end.

Fix it up by doing a special 32-bit get_user() via a cast when
we have 32-bit userspace.
Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20151111181931.3ACF6822@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      abaae23a
    • Dave Hansen's avatar
      x86/mpx: Introduce new 'directory entry' to 'addr' helper function · 8898f1ad
      Dave Hansen authored 
      commit 54587653 upstream.

Currently, to get from a bounds directory entry to the virtual
address of a bounds table, we simply mask off a few low bits.
However, the set of bits we mask off is different for 32-bit and
64-bit binaries.

This breaks the operation out in to a helper function and also
adds a temporary variable to store the result until we are
sure we are returning one.
Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Hansen <dave@sr71.net>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20150607183704.007686CE@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
[ kamal: 3.19-stable prereq for "46561c39 x86/mpx: Do proper get_user() when
  running 32-bit binaries on 64-bit kernels" ]
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      8898f1ad
    • Dave Hansen's avatar
      x86: Make is_64bit_mm() widely available · 7d757760
      Dave Hansen authored 
      commit b0e9b09b upstream.

The uprobes code has a nice helper, is_64bit_mm(), that consults
both the runtime and compile-time flags for 32-bit support.
Instead of reinventing the wheel, pull it in to an x86 header so
we can use it for MPX.

I prefer passing the 'mm' around to test_thread_flag(TIF_IA32)
because it makes it explicit where the context is coming from.
Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Hansen <dave@sr71.net>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20150607183704.F0209999@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
[ kamal: 3.19-stable prereq for "46561c39 x86/mpx: Do proper get_user() when
  running 32-bit binaries on 64-bit kernels" ]
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      7d757760
    • Dave Hansen's avatar
      x86/mpx: Add temporary variable to reduce masking · 0dffd65c
      Dave Hansen authored 
      commit a1149fc8 upstream.

When we allocate a bounds table, we call mmap(), then add a
"valid" bit to the value before storing it in to the bounds
directory.

If we fail along the way, we go and mask that valid bit
_back_ out.  That seems a little silly, and this makes it
much more clear when we have a plain address versus an
actual table _entry_.
Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Hansen <dave@sr71.net>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20150607183704.3D69D5F4@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
[ kamal: 3.19-stable prereq for "46561c39 x86/mpx: Do proper get_user() when
  running 32-bit binaries on 64-bit kernels" ]
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      0dffd65c
    • Lars-Peter Clausen's avatar
      iio:ad7793: Fix ad7785 product ID · 6ae524fc
      Lars-Peter Clausen authored 
      commit 785171fd upstream.

While the datasheet for the AD7785 lists 0xXB as the product ID the actual
product ID is 0xX3.

Fix the product ID otherwise the driver will reject the device due to non
matching IDs.

Fixes: e786cc26 ("staging:iio:ad7793: Implement stricter id checking")
Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      6ae524fc
    • Lars-Peter Clausen's avatar
      iio: ad5064: Fix ad5629/ad5669 shift · 09d58f01
      Lars-Peter Clausen authored 
      commit 5dcbe97b upstream.

The ad5629/ad5669 are the I2C variant of the ad5628/ad5668, which has a SPI
interface. They are mostly identical with the exception that the shift
factor is different. Currently the driver does not take care of this
difference which leads to incorrect DAC output values.

Fix this by introducing a custom channel spec for the ad5629/ad5669 with
the correct shift factor.

Fixes: commit 6a17a076 ("iio:dac:ad5064: Add support for the ad5629r and ad5669r")
Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      09d58f01
    • Michael Hennerich's avatar
      iio:ad5064: Make sure ad5064_i2c_write() returns 0 on success · 78c90e1d
      Michael Hennerich authored 
      commit 03fe472e upstream.

i2c_master_send() returns the number of bytes transferred on success while
the ad5064 driver expects that the write() callback returns 0 on success.
Fix that by translating any non negative return value of i2c_master_send()
to 0.

Fixes: commit 6a17a076 ("iio:dac:ad5064: Add support for the ad5629r and ad5669r")
Signed-off-by: default avatarMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      78c90e1d
    • Vladimir Zapolskiy's avatar
      iio: lpc32xx_adc: fix warnings caused by enabling unprepared clock · 99138095
      Vladimir Zapolskiy authored 
      commit 01bb70ae upstream.

If common clock framework is configured, the driver generates a warning,
which is fixed by this change:

    root@devkit3250:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 724 at drivers/clk/clk.c:727 clk_core_enable+0x2c/0xa4()
    Modules linked in: sc16is7xx snd_soc_uda1380
    CPU: 0 PID: 724 Comm: cat Not tainted 4.3.0-rc2+ #198
    Hardware name: LPC32XX SoC (Flattened Device Tree)
    Backtrace:
    [<>] (dump_backtrace) from [<>] (show_stack+0x18/0x1c)
    [<>] (show_stack) from [<>] (dump_stack+0x20/0x28)
    [<>] (dump_stack) from [<>] (warn_slowpath_common+0x90/0xb8)
    [<>] (warn_slowpath_common) from [<>] (warn_slowpath_null+0x24/0x2c)
    [<>] (warn_slowpath_null) from [<>] (clk_core_enable+0x2c/0xa4)
    [<>] (clk_core_enable) from [<>] (clk_enable+0x24/0x38)
    [<>] (clk_enable) from [<>] (lpc32xx_read_raw+0x38/0x80)
    [<>] (lpc32xx_read_raw) from [<>] (iio_read_channel_info+0x70/0x94)
    [<>] (iio_read_channel_info) from [<>] (dev_attr_show+0x28/0x4c)
    [<>] (dev_attr_show) from [<>] (sysfs_kf_seq_show+0x8c/0xf0)
    [<>] (sysfs_kf_seq_show) from [<>] (kernfs_seq_show+0x2c/0x30)
    [<>] (kernfs_seq_show) from [<>] (seq_read+0x1c8/0x440)
    [<>] (seq_read) from [<>] (kernfs_fop_read+0x38/0x170)
    [<>] (kernfs_fop_read) from [<>] (do_readv_writev+0x16c/0x238)
    [<>] (do_readv_writev) from [<>] (vfs_readv+0x50/0x58)
    [<>] (vfs_readv) from [<>] (default_file_splice_read+0x1a4/0x308)
    [<>] (default_file_splice_read) from [<>] (do_splice_to+0x78/0x84)
    [<>] (do_splice_to) from [<>] (splice_direct_to_actor+0xc8/0x1cc)
    [<>] (splice_direct_to_actor) from [<>] (do_splice_direct+0xa0/0xb8)
    [<>] (do_splice_direct) from [<>] (do_sendfile+0x1a8/0x30c)
    [<>] (do_sendfile) from [<>] (SyS_sendfile64+0x104/0x10c)
    [<>] (SyS_sendfile64) from [<>] (ret_fast_syscall+0x0/0x38)
Signed-off-by: default avatarVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      99138095
    • Bhuvanchandra DV's avatar
      vf610_adc: Fix internal temperature calculation · b2864829
      Bhuvanchandra DV authored 
      commit 6219f432 upstream.

Calculate ADCR_VTEMP25 using VTEMP25 at VREFH_ADC 3V3. Existing
calculations consider the typical values provided in datasheet.
Those typical values are valid for VREFH_ADC at 3.0V. VTEMP25
is different for different VREFH_ADC voltages. With VREFH_ADC
at 3.3V, voltage at 25°C is 0.699V. Hence update the VTEMP25
to 0.699V which gives ADCR@Temp25 as 867.

Formula for finding ADCR@Temp25:
ADCR@Temp25 = (ADCR@Vdd * V@TEMP25 * 10) / VDDconv

ADCR@Vdd for 12-Bit ADC = 4095
VDDconv = VREFH_ADC * 10

VREFH_ADC@3.3V
ADCR@Temp25 = (4095 * .699 * 10) / 33
ADCR@Temp25 ~= 867

| VREFH_ADC | V@TEMP25 | VDDconv | ADCR@Temp25 |
|   3.0V    | 0.696mV  |    30   |     950     |
|   3.3V    | 0.699mV  |    33   |     867     |
Signed-off-by: default avatarBhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Acked-by: default avatarFugang Duan <B38611@freescale.com>
Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      b2864829
  3. 07 Dec, 2015 1 commit
  5. 04 Dec, 2015 2 commits
  7. 02 Dec, 2015 1 commit
  9. 01 Dec, 2015 1 commit
  11. 30 Nov, 2015 24 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7