On Tue, 23 Jan 2018 10:34:03 +0100
Mohammed Gamal wrote:
> Commit 0cf737808ae7 ("hv_netvsc: netvsc_teardown_gpadl() split") introduced
> a regression that caused VMs not to shutdown after netvsc_device_remove() is
> called. This is caused by GPADL teardown sequence change, and while that was
> n
On Fri, Jan 26, 2018 at 12:05:42PM +0300, Yury Norov wrote:
> On Wed, Jan 24, 2018 at 10:22:13AM +, Will Deacon wrote:
> > On Wed, Jan 24, 2018 at 12:05:16PM +0300, Yury Norov wrote:
> > > This series adds API for 128-bit memory IO access and enables it for
> > > ARM64.
> > > The original moti
On 1/26/2018 10:11 AM, David Woodhouse wrote:
I am *actively* ignoring Skylake right now. This is about per-SKL
userspace even with SMEP, because we think Intel's document lies to us.
if you think we lie to you then I think we're done with the conversation?
Please tell us then what you deploy
On Fri, 2018-01-26 at 09:59 -0800, Andi Kleen wrote:
> On Fri, Jan 26, 2018 at 09:19:09AM -0800, Linus Torvalds wrote:
> >
> > On Fri, Jan 26, 2018 at 1:11 AM, David Woodhouse wrote:
> > >
> > >
> > > Do we need to look again at the fact that we've disabled the RSB-
> > > stuffing for SMEP?
> >
I want to explain a bit what is the problem this patch solves.
Without it, I always obtain a transfer rate below 9MB/s when writing to a cifs
share using splice syscall independently of the buffer size used. However, when
reading from the cifs share, I obtain around 105 MB/s.
After applying the
On Fri, Jan 26, 2018 at 10:07 AM, Al Viro wrote:
>
> Umm... What about other architectures? Or do you want SYSCALL_DEFINE...
> to be per-arch? I wonder how much would that "go through pt_regs" hurt
> on something like sparc...
No, but I just talked to Will Deacon about register clearing on ent
On 01/26/2018 04:57 AM, Masanari Iida wrote:
> This patch fixes spelling typos found in Kconfig.
>
> Signed-off-by: Masanari Iida
Acked-by: Randy Dunlap
One comment below.
> ---
> arch/arc/Kconfig | 4 ++--
> arch/arm/mach-s3c24xx/Kconfig | 2 +-
> arch/arm/mach-s3c64xx/
On Fri, 26 Jan 2018, Victor Kamensky wrote:
> On Fri, 26 Jan 2018, Henrique de Moraes Holschuh wrote:
> > On Thu, 25 Jan 2018, Rob Landley wrote:
> > > That said, I don't think -h newcx should emit (or recognize) the
> > > "TRAILER!!!1!" entry. That's kinda silly in-band signaling for 2018:
> > >
On Fri, Jan 26, 2018 at 05:34:28PM +, Michael Kelley (EOSG) wrote:
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Thursday, January 25, 2018 2:00 AM
> > To: Michael Kelley (EOSG)
> > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
On Sun, Jan 14, 2018 at 10:32 PM, Milan Stevanovic
wrote:
> Add Linux device driver for TI single-channel CMOS
> 8/10/12-bit analog-to-digital converter with a
> high-speed serial interface.
>
> Signed-off-by: Milan Stevanovic
> + * Analog Devices AD7466/7/8 AD7476/5/7/8 (A) SPI ADC
On Fri, Jan 26, 2018 at 10:13 AM, Linus Torvalds
wrote:
> On Fri, Jan 26, 2018 at 10:07 AM, Al Viro wrote:
>>
>> Umm... What about other architectures? Or do you want SYSCALL_DEFINE...
>> to be per-arch? I wonder how much would that "go through pt_regs" hurt
>> on something like sparc...
>
> N
On 01/26/2018 07:19 PM, Andy Shevchenko wrote:
> On Sun, Jan 14, 2018 at 10:32 PM, Milan Stevanovic
> wrote:
>> Add Linux device driver for TI single-channel CMOS
>> 8/10/12-bit analog-to-digital converter with a
>> high-speed serial interface.
>>
>> Signed-off-by: Milan Stevanovic
>
On Fri, 2018-01-26 at 10:12 -0800, Arjan van de Ven wrote:
> On 1/26/2018 10:11 AM, David Woodhouse wrote:
> >
> > I am *actively* ignoring Skylake right now. This is about per-SKL
> > userspace even with SMEP, because we think Intel's document lies to us.
>
> if you think we lie to you then I th
> On Fri, 2018-01-26 at 10:12 -0800, Arjan van de Ven wrote:
> > On 1/26/2018 10:11 AM, David Woodhouse wrote:
> > >
> > > I am *actively* ignoring Skylake right now. This is about per-SKL
> > > userspace even with SMEP, because we think Intel's document lies to us.
> >
> > if you think we lie to y
On 01/25/2018 06:58 PM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20180119:
>
on x86_64:
drivers/gpu/drm/i915/intel_panel.o: In function
`intel_backlight_device_register':
intel_panel.c:(.text+0x28d4): undefined reference to `backlight_device_register'
drivers/gpu/drm/i915/intel_panel
On Fri, Jan 26, 2018 at 07:00:30AM -0800, tip-bot for David Woodhouse wrote:
> +#define X86_FEATURE_AMD_PRED_CMD (13*32+12) /* Prediction Command MSR
> (AMD) */
> +#define X86_FEATURE_AMD_SPEC_CTRL(13*32+14) /* Speculation Control MSR
> only (AMD) */
> +#define X86_FEATURE_AMD_STIBP
On Fri, Jan 26, 2018 at 8:25 PM, Lars-Peter Clausen wrote:
> On 01/26/2018 07:19 PM, Andy Shevchenko wrote:
>> On Sun, Jan 14, 2018 at 10:32 PM, Milan Stevanovic
>> wrote:
>>> Add Linux device driver for TI single-channel CMOS
>>> 8/10/12-bit analog-to-digital converter with a
>>> hig
On Fri, 2018-01-26 at 18:28 +, Van De Ven, Arjan wrote:
> > As you know well, I mean "we think Intel's document is not
> > correct".
>
> you asked before and even before you sent the email I confirmed to
> you that the document is correct
>
> I'm not sure what the point is to then question tha
> > you asked before and even before you sent the email I confirmed to
> > you that the document is correct
> >
> > I'm not sure what the point is to then question that again 15 minutes
> > later other than creating more noise.
>
> Apologies, I hadn't seen the comment on IRC.
>
> Sometimes the do
On Fri, Jan 26, 2018 at 12:47 PM, Jason A. Donenfeld wrote:
> On Fri, Jan 26, 2018 at 5:43 PM, Alan Cox wrote:
>> a) The info is already trivially accessible via /proc/cpuinfo
>
> No, /proc/cpuinfo shows if the CPU itself has these bugs, but doesn't
> show whether or not the kernel has gone to le
On Fri, 2018-01-26 at 19:41 +0100, Borislav Petkov wrote:
> +#define X86_FEATURE_AMD_IBPB (13*32+12) /* "" Indirect Branch
> Prediction Barrier MSR */
Stray quotes.
> +#define X86_FEATURE_IBRS (13*32+14) /* Indirect Branch
> Restricted Speculation */
Please don't call i
On 01/26/2018 10:38 AM, Jia-Ju Bai wrote:
After checking all possible call chains to bcma_pmu_resources_init() here,
my tool finds that this function is never called in atomic context,
namely never in an interrupt handler or holding a spinlock.
Thus mdelay can be replaced with usleep_range to avo
On Fri, Jan 26, 2018 at 06:45:18PM +, David Woodhouse wrote:
> On Fri, 2018-01-26 at 19:41 +0100, Borislav Petkov wrote:
> > +#define X86_FEATURE_AMD_IBPB (13*32+12) /* "" Indirect Branch
> > Prediction Barrier MSR */
>
> Stray quotes.
No no, those quotes are magical. :)
They don'
On Thu, Jan 25, 2018 at 01:12:14PM -0800, Andy Lutomirski wrote:
> Neil Berrington reported a double-fault on a VM with 768GB of RAM that
> uses large amounts of vmalloc space with PTI enabled.
>
> The cause is that load_new_mm_cr3() was never fixed to take the
> 5-level pgd folding code into acco
On 01/26/2018 07:25 PM, Lars-Peter Clausen wrote:
> On 01/26/2018 07:19 PM, Andy Shevchenko wrote:
>> On Sun, Jan 14, 2018 at 10:32 PM, Milan Stevanovic
>> wrote:
>>> Add Linux device driver for TI single-channel CMOS
>>> 8/10/12-bit analog-to-digital converter with a
>>> high-speed se
On Wed, Jan 24, 2018 at 7:15 PM, Ladislav Michl wrote:
> On Wed, Jan 24, 2018 at 06:21:38PM +0200, Andy Shevchenko wrote:
>> > +#define devm_ioremap_resource(dev, res) \
>> > + __devm_ioremap_resource(dev, res, false)
>> > +#define devm_ioremap_shared_resource(dev, res) \
>> > + __dev
On 01/26/2018 07:19 PM, Andy Shevchenko wrote:
> On Sun, Jan 14, 2018 at 10:32 PM, Milan Stevanovic
> wrote:
>> Add Linux device driver for TI single-channel CMOS
>> 8/10/12-bit analog-to-digital converter with a
>> high-speed serial interface.
>>
>> Signed-off-by: Milan Stevanovic
>
On Fri, Jan 26, 2018 at 10:23 AM, Andy Lutomirski wrote:
>
> The issue is that doing it this way gives us, effectively:
>
> long sys_foo(int a, int b)
> {
> body here;
> }
>
> long SyS_foo(const struct pt_regs *regs)
> {
> return sys_foo(regs->di, regs->si);
> }
>
> whereas what we want is *st
On Fri, 2018-01-26 at 18:44 +, Van De Ven, Arjan wrote:
> your question was specific to RSB not BTB. But please show the empirical
> evidence for RSB ?
We were hypothesising, which should have been clear from:
On Fri, 2018-01-26 at 09:11 +, David Woodhouse wrote:
> Likewise if the RSB on
Upstream commit 1c9de5bf4286 ("usbip: vhci-hcd: Add USB3 SuperSpeed
support")
vhci_hcd clears all the bits port_status bits instead of clearing
just the USB_PORT_STAT_POWER bit when it handles ClearPortFeature:
USB_PORT_FEAT_POWER. This causes vhci_hcd attach to fail in a bad
state, leaving device
On Thu, Jan 25, 2018 at 02:00:22PM -0800, Andy Lutomirski wrote:
> On Thu, Jan 25, 2018 at 1:49 PM, Dave Hansen wrote:
> > On 01/25/2018 01:12 PM, Andy Lutomirski wrote:
> >> Neil Berrington reported a double-fault on a VM with 768GB of RAM that
> >> uses large amounts of vmalloc space with PTI en
Upstream commit 1c9de5bf4286 ("usbip: vhci-hcd: Add USB3 SuperSpeed
support")
vhci_hcd clears all the bits port_status bits instead of clearing
just the USB_PORT_STAT_POWER bit when it handles ClearPortFeature:
USB_PORT_FEAT_POWER. This causes vhci_hcd attach to fail in a bad
state, leaving device
Keep usbip_device sockfd state in sync with tcp_socket. When tcp_socket
is reset to null, reset sockfd to -1 to keep it in sync.
Signed-off-by: Shuah Khan
Cc: sta...@vger.kernel.org
---
drivers/usb/usbip/stub_dev.c | 3 +++
drivers/usb/usbip/vhci_hcd.c | 2 ++
2 files changed, 5 insertions(+)
d
On Fri, Jan 26, 2018 at 8:22 AM, Andy Lutomirski wrote:
> On Fri, Jan 26, 2018 at 7:36 AM, Dan Rue wrote:
>>
>> We've noticed that fsgsbase_64 can fail intermittently with the
>> following error:
>>
>> [RUN] ARCH_SET_GS(0x0) and clear gs, then schedule to 0x1
>> Before s
On Fri, Jan 26, 2018 at 10:51 AM, Kirill A. Shutemov
wrote:
> On Thu, Jan 25, 2018 at 01:12:14PM -0800, Andy Lutomirski wrote:
>> Neil Berrington reported a double-fault on a VM with 768GB of RAM that
>> uses large amounts of vmalloc space with PTI enabled.
>>
>> The cause is that load_new_mm_cr3(
On Fri, Jan 26, 2018 at 10:54 AM, Linus Torvalds
wrote:
> On Fri, Jan 26, 2018 at 10:23 AM, Andy Lutomirski wrote:
>>
>> The issue is that doing it this way gives us, effectively:
>>
>> long sys_foo(int a, int b)
>> {
>> body here;
>> }
>>
>> long SyS_foo(const struct pt_regs *regs)
>> {
>> r
commit 1005bccd7a4a ("crypto: caam - enable instantiation of all RNG4 state
handles") introduces a control when incrementing ent_delay which contains
the following comment above it:
/*
* If either SH were instantiated by somebody else
* (e.g. u-boot) then it is assumed that the entropy
* parame
V2-resend:
- Patch 0005 lost in the ether - resending
V2:
- Endian detection is ok with TrustZone enabled Horia.
Endian detection logic tested with TrustZone enabled. The register that
this relies on though isn't affected by the lock-down in the first page.
Assuming set of affected registers
From: Rui Miguel Silva
Add CAAM device node to the i.MX7s device tree.
Signed-off-by: Rui Miguel Silva
Cc: "Horia Geantă"
Cc: Aymen Sghaier
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: Lukas Auer
Signed-off-by: Bryan O'Donoghue
---
arch/arm/boot/dts/imx7s.dts
From: Rui Miguel Silva
caam_remove already removes the debugfs entry, so we need to remove the one
immediately before calling caam_remove.
This fix a NULL dereference at error paths is caam_probe fail.
[bod: changed name prefix to "crypto: caam: Fix .."]
[bod: added Fixes tag]
Fixes: 67c2315de
From: Rui Miguel Silva
I.MX7x only use two clocks for the CAAM module, so make sure we do not try to
use the mem and the emi_slow clock when running in that imx7d and imx7s machine
type.
[bod: fixed minor trailing whitespace issue]
Signed-off-by: Rui Miguel Silva
Cc: "Horia Geantă"
Cc: Aymen
From: Rui Miguel Silva
Add CAAM clock so that we could use the Cryptographic Acceleration and
Assurance Module (CAAM) hardware block.
Signed-off-by: Rui Miguel Silva
Cc: "Horia Geantă"
Cc: Aymen Sghaier
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: Lukas Auer
Si
gossip_ldebug is unused.
gossip_lerr is used in two places. The messages are unique so line
numbers are unnecessary.
Also remove support for compiling gossip messages out. It wasn't
possible to enable it anyway.
Signed-off-by: Martin Brandenburg
---
fs/orangefs/orangefs-debugfs.c | 2 +-
fs
Signed-off-by: Martin Brandenburg
---
fs/orangefs/orangefs-kernel.h | 2 --
fs/orangefs/orangefs-utils.c | 38 +++---
2 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/fs/orangefs/orangefs-kernel.h b/fs/orangefs/orangefs-kernel.h
index 25bacc334d91
This formally separates userspace visible and kernel internal data
structures. The sole consumer of this would be the pvfs2-client-core,
which currently simply defines all these structures itself. Most of
these are shared with the rest of the OrangeFS userspace client and
server code.
As the use
First delete a good bit of dead code and change a few things to static.
Then move userspace visible interface to uapi.
This isn't immediately helpful without userspace consumers. This should
be helpful to your [Mike's] work with OrangeFS 3.0. We will need to
translate between OrangeFS internal
On Fri, 26 Jan 2018 18:47:28 +0100
"Jason A. Donenfeld" wrote:
> On Fri, Jan 26, 2018 at 5:43 PM, Alan Cox wrote:
> > a) The info is already trivially accessible via /proc/cpuinfo
>
> No, /proc/cpuinfo shows if the CPU itself has these bugs, but doesn't
> show whether or not the kernel has go
Signed-off-by: Martin Brandenburg
---
fs/orangefs/devorangefs-req.c | 52 +--
fs/orangefs/inode.c | 4 ++--
fs/orangefs/orangefs-kernel.h | 3 ---
3 files changed, 28 insertions(+), 31 deletions(-)
diff --git a/fs/orangefs/devorangefs-req.c b/f
Signed-off-by: Martin Brandenburg
---
fs/orangefs/orangefs-debug.h | 6
fs/orangefs/orangefs-kernel.h | 77 ---
fs/orangefs/protocol.h| 45 -
3 files changed, 128 deletions(-)
diff --git a/fs/orangefs/orangefs-debug.h
It wasn't possible to enable it, and it would've had very little effect.
Signed-off-by: Martin Brandenburg
---
fs/orangefs/orangefs-kernel.h | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/fs/orangefs/orangefs-kernel.h b/fs/orangefs/orangefs-kernel.h
index 2595453fe73
Signed-off-by: Martin Brandenburg
---
fs/orangefs/orangefs-debugfs.c | 2 +-
fs/orangefs/orangefs-debugfs.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/orangefs/orangefs-debugfs.c b/fs/orangefs/orangefs-debugfs.c
index 1c59dff530de..67d531ad5a56 100644
--- a/fs/orangef
On Fri, Jan 26, 2018 at 09:59:01AM -0800, Andi Kleen wrote:
> On Fri, Jan 26, 2018 at 09:19:09AM -0800, Linus Torvalds wrote:
> > On Fri, Jan 26, 2018 at 1:11 AM, David Woodhouse
> > wrote:
> > >
> > > Do we need to look again at the fact that we've disabled the RSB-
> > > stuffing for SMEP?
> >
The need for RSB stuffing in all the various scenarios and what the heck it
actually mitigates is freakishly complicated. I've tried to write it all down
in one place: https://goo.gl/pXbvBE
On Fri, 2018-01-26 at 14:02 -0500, Konrad Rzeszutek Wilk wrote:
>
> -ECONFUSED, see ==>
>
> Is this incorrect then?
> I see:
>
> 241 * Skylake era CPUs have a separate issue with *underflow* of the
>
> 242 * RSB, when they will predict 'ret' targets from the generic
>
On Fri, Jan 26, 2018 at 02:07:10PM -0500, Martin Brandenburg wrote:
> I have also written a "fakecore" which does about the bare minimum to
> start up and respond to mount requests. I intend to use this as a
> vehicle for experimentation with fuzzing and testing performance through
> our kernel co
Hello
The current crypto_engine support only ahash and ablkcipher request.
My first patch which try to add skcipher was Nacked, it will add too many
functions
and adding other algs(aead, asymetric_key) will make the situation worst.
This patchset remove all algs specific stuff and now only proce
The crypto engine could actually only enqueue hash and ablkcipher request.
This patch permit it to enqueue any type of crypto_async_request.
Signed-off-by: Corentin Labbe
Tested-by: Fabien Dessenne
---
crypto/crypto_engine.c | 301 ++--
include/crypt
This patch convert the driver to the new crypto engine API.
Signed-off-by: Corentin Labbe
---
drivers/crypto/virtio/virtio_crypto_algs.c | 16 ++--
drivers/crypto/virtio/virtio_crypto_common.h | 3 +--
drivers/crypto/virtio/virtio_crypto_core.c | 3 ---
3 files changed, 11 inse
This patch convert the stm32-cryp driver to the new crypto engine API.
Signed-off-by: Corentin Labbe
Tested-by: Fabien Dessenne
---
drivers/crypto/stm32/stm32-cryp.c | 29 +
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/stm32/stm32-cryp
This patch convert the driver to the new crypto engine API.
Signed-off-by: Corentin Labbe
---
drivers/crypto/omap-aes.c | 21 +++--
drivers/crypto/omap-aes.h | 3 +++
drivers/crypto/omap-des.c | 24 ++--
3 files changed, 36 insertions(+), 12 deletions(-)
dif
This patch convert the stm32-hash driver to the new crypto engine API.
Signed-off-by: Corentin Labbe
Tested-by: Fabien Dessenne
---
drivers/crypto/stm32/stm32-hash.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/stm32/stm32-hash.c
b/dr
Signed-off-by: Corentin Labbe
---
Documentation/crypto/crypto_engine.rst | 48 ++
1 file changed, 48 insertions(+)
create mode 100644 Documentation/crypto/crypto_engine.rst
diff --git a/Documentation/crypto/crypto_engine.rst
b/Documentation/crypto/crypto_engine.
Hi Al,
On Thu, Jan 25, 2018 at 7:13 PM, Al Viro wrote:
> On Thu, Jan 25, 2018 at 06:46:49PM -0800, Joel Fernandes wrote:
>> ashmem_mutex create a chain of dependencies like so:
>>
>> (1)
>> mmap syscall ->
>> mmap_sem -> (acquired)
>> ashmem_mmap
>> ashmem_mutex (try to acquire)
>> (bloc
On Fri, Jan 26, 2018 at 11:23 AM, Joel Fernandes wrote:
> Hi Al,
>
> On Thu, Jan 25, 2018 at 7:13 PM, Al Viro wrote:
>> On Thu, Jan 25, 2018 at 06:46:49PM -0800, Joel Fernandes wrote:
>>> ashmem_mutex create a chain of dependencies like so:
>>>
>>> (1)
>>> mmap syscall ->
>>> mmap_sem -> (acqu
On Fri, Jan 26, 2018 at 02:14:38PM +0900, Andi Shyti wrote:
> Hi Simon and Dmitry,
>
> On Wed, Jan 24, 2018 at 01:32:01PM -0800, Dmitry Torokhov wrote:
> > From: Simon Shields
> >
> > MMS152 has no configuration registers, but the packet format used in
> > interrupts is identical to mms114.
> >
Em Fri, 26 Jan 2018 12:17:37 -0200
Mauro Carvalho Chehab escreveu:
> Hi Alan,
>
> Em Mon, 8 Jan 2018 14:15:35 -0500 (EST)
> Alan Stern escreveu:
>
> > On Mon, 8 Jan 2018, Linus Torvalds wrote:
> >
> > > Can somebody tell which softirq it is that dvb/usb cares about?
> >
> > I don't kno
On Fri, Jan 26, 2018 at 11:23:47AM -0800, Joel Fernandes wrote:
> I was just trying to be careful with the least intrusive solution
> since I'm not the original author of the driver.
Sure, but that needs a proof that it *is* a solution...
> But one usecase for the mutex is with concurrent lseeks
On 24/01/18 19:56, Igor Stoppa wrote:
[...]
> +bool pmalloc_prealloc(struct gen_pool *pool, size_t size)
> +{
[...]
> +abort:
> + vfree(chunk);
this should be vfree_atomic()
[...]
> +void *pmalloc(struct gen_pool *pool, size_t size, gfp_t gfp)
> +{
[...]
> +free:
> + vfree(chunk);
From: Colin Ian King
Use vzalloc instead of the vmalloc, memset combo
Signed-off-by: Colin Ian King
---
fs/orangefs/devorangefs-req.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/orangefs/devorangefs-req.c b/fs/orangefs/devorangefs-req.c
index f073cd9e6687..a50fb896
On Fri, Jan 26, 2018 at 10:59 AM, Andy Lutomirski wrote:
> On Fri, Jan 26, 2018 at 8:22 AM, Andy Lutomirski wrote:
>> On Fri, Jan 26, 2018 at 7:36 AM, Dan Rue wrote:
>>>
>>> We've noticed that fsgsbase_64 can fail intermittently with the
>>> following error:
>>>
>>> [RUN] ARCH_SET_GS(0
On Tue, Dec 26, 2017 at 08:08:13AM +0100, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> On Tue, Dec 26, 2017 at 1:55 AM, Wanpeng Li wrote:
> > 2017-12-26 8:22 GMT+08:00 syzbot
> > :
> >> syzkaller has found reproducer for the following crash on
> >> 464e1d5f23cca236b930ef068c328a64cab78fb1
> >> git
Hello,
there is cdrom autoclose feature that is supposed to close the tray, wait for
the disc to become ready, and then open the device.
This used to work in ancient times. Then in old times there was a hack in
util-linux which worked around the breakage which probably resulted from
swi
On 1/25/18, 10:34 PM, "Thomas Gleixner" wrote:
On Fri, 26 Jan 2018, Wanpeng Li wrote:
> > > >Folks, can you please stop this corporate email style nonsense?
> On 1/26/18 12:55 AM, Arisetty, Chakravarthy wrote:
> >> IIRC，the race which KVM: LAPIC: Fix reentrancy issues
Hi Lothar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on shawnguo/for-next]
[also build test ERROR on next-20180126]
[cannot apply to v4.15-rc9]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
On Fri, 2018-01-26 at 17:58 +0100, Michal Suchanek wrote:
> First time I did not get any feedback for the patches.
This is likely because no-one who might inspect the code saw the
patches ... what list are they going to? I'm on the block, scsi and
ide mailing lists and I only saw a doc patch the
On Fri, Jan 26, 2018 at 05:47:46PM +0100, Borislav Petkov wrote:
> Proper ones coming soon.
Ok, here they are as a reply to this message. Lemme send them out for a
quick look, before I run them through the boxes tomorrow.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-po
Simplify it to call an asm-function instead of pasting 41 insn bytes at
every call site. Also, add alignment to the macro as suggested here:
https://support.google.com/faqs/answer/7625886
Signed-off-by: Borislav Petkov
Cc: David Woodhouse
---
arch/x86/entry/entry_32.S | 2 +-
ar
Make it all a function which does the WRMSR instead of having a hairy
inline asm.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/cpufeatures.h | 2 +-
arch/x86/include/asm/nospec-branch.h | 13 -
arch/x86/include/asm/processor.h | 4
arch/x86/kernel/cpu/bugs.c
smart1,2.h is unused since commit d436641439e0 ("cpqarray: remove it from the
kernel")
Remove it from tree.
Signed-off-by: Corentin Labbe
---
drivers/block/smart1,2.h | 278 ---
1 file changed, 278 deletions(-)
delete mode 100644 drivers/block/smart1
bsp_i2c.h is unused since commit ffe7c4f92183 ("[media] drx-j: Get rid of
drx39xyj/bsp_tuner.h")
Remove it from tree.
Signed-off-by: Corentin Labbe
---
drivers/media/dvb-frontends/drx39xyj/bsp_i2c.h | 139 -
1 file changed, 139 deletions(-)
delete mode 100644 drivers/me
On 1/26/18 1:12 PM, Corentin Labbe wrote:
> smart1,2.h is unused since commit d436641439e0 ("cpqarray: remove it from the
> kernel")
> Remove it from tree.
Indeed, thanks, applied.
--
Jens Axboe
Hi Rajendra,
On Thu, Jan 25, 2018 at 8:32 AM, Rajendra Nayak wrote:
> Add a skeletal sdm845 SoC dtsi and MTP board dts/dtsi files
>
> Signed-off-by: Rajendra Nayak
> ---
> arch/arm64/boot/dts/qcom/Makefile| 1 +
> arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 13 ++
> arch/arm64/boot/dt
Quoting Rob Landley (2018-01-25 18:40:25)
> On 01/24/2018 09:27 PM, Taras Kondratiuk wrote:
> > diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c
> > index 7a2a6d85345d..78a47a5bdcb1 100644
> > --- a/usr/gen_init_cpio.c
> > +++ b/usr/gen_init_cpio.c
> > @@ -10,6 +10,7 @@
> > #include
> > #i
Fix spelling.
Signed-off-by: Patryk Kocielnik
---
drivers/i2c/busses/i2c-sirf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-sirf.c b/drivers/i2c/busses/i2c-sirf.c
index 2fd8b6d00..605c8217f 100644
--- a/drivers/i2c/busses/i2c-sirf.c
+++ b/drivers/i2
On 01/25/2018 10:02 PM, Alexandre Courbot wrote:
> Document how the request API can be used along with the existing V4L2
> interface.
>
> +Request API
> +===
> +
> +The Request API has been designed to allow V4L2 to deal with requirements of
> +modern IPs (stateless codecs, MIPI cameras,
Hi Al,
On Fri, Jan 26, 2018 at 11:39 AM, Al Viro wrote:
[..]
>
>> But one usecase for the mutex is with concurrent lseeks, you can end
>> up with a file->f_pos that is different from the latest update to
>> asma->file->f_pos. A barrier could fix this it too though. Any
>> thoughts?
>
> lseek(2) i
On Fri, Jan 26, 2018 at 11:02:08AM -0800, Andy Lutomirski wrote:
> On Fri, Jan 26, 2018 at 10:51 AM, Kirill A. Shutemov
> wrote:
> > On Thu, Jan 25, 2018 at 01:12:14PM -0800, Andy Lutomirski wrote:
> >> Neil Berrington reported a double-fault on a VM with 768GB of RAM that
> >> uses large amounts
Hi,
I am doing development on the latest unreleased kernel on a system
running ubuntu 16.04. I can not get crash dump to be saved or use
crash on the live system. I have tried compiling crash on the system.
What is the trick to do development on the latest kernel using a
system installed with old
在 2018年1月25日星期四 CST 下午11:35:20，Maxime Ripard 写道：
> Hi,
>
> On Wed, Jan 24, 2018 at 09:10:34PM +0800, Icenowy Zheng wrote:
> > 在 2018年1月22日星期一 CST 下午8:14:35，Maxime Ripard 写道：
> >
> > > On Sat, Jan 20, 2018 at 07:17:26AM +0800, Icenowy Zheng wrote:
> > > > This is the RFC initial patchset for the "
One trivial comment:
On Thu, Jan 25, 2018 at 11:38:32PM -0800, Derek Basehore wrote:
> Some platforms power off GIC logic in suspend, so we need to
> save/restore state. The distributor and redistributor registers need
> to be handled in platform code due to access permissions on those
> registers
Next version of my patchseries for adding clockgating support for
kepler1 and 2 on nouveau. The first version of this series can be found
here:
https://patchwork.freedesktop.org/series/36504/
Some very important changes:
- Fix gf100_clkgate_init() to actually write registers! This got broken
This adds support for enabling automatic clockgating on nvidia GPUs for
Kepler1. While this is not technically a clockgating level, it does
enable clockgating using the clockgating values initially set by the
vbios (which should be safe to use).
This introduces two therm helpers for controlling ba
On Fri, Jan 26, 2018 at 1:12 AM, Benjamin Poirier wrote:
> This reverts commit 16ecba59bc333d6282ee057fb02339f77a880beb.
>
> It was reported that emulated e1000e devices in vmware esxi 6.5 Build
> 7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid receiver
> overrun interrupt bursts"
That's right, there's still more power saving to go! Starting with
kepler 2, nvidia hardware has an additional level of clockgating known
as second level clockgating. The details of this are not exact, but it
seems to work by waiting for a collection of dependent hardware blocks
to be gated before
Same as the previous patch, but for Kepler2 now
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 8 +--
drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c| 62
drivers/gpu/drm/nouveau
This enables BLCG optimization for kepler1. When using clockgating,
nvidia's firmware has a set of registers which are initially programmed
by the vbios with various engine delays and other mysterious settings
that are safe enough to bring up the GPU. However, the values used by
the vbios are more
Quoting Rob Landley (2018-01-25 18:40:54)
> On 01/24/2018 09:27 PM, Taras Kondratiuk wrote:
> > diff --git a/Documentation/early-userspace/buffer-format.txt
> > b/Documentation/early-userspace/buffer-format.txt
> > index e1fd7f9dad16..d818df4f72dc 100644
> > --- a/Documentation/early-userspace/buf
The comments doesn't match what the current code does, also have a
typo. This patch corrects them.
Signed-off-by: Haiyang Zhang
---
drivers/hv/channel_mgmt.c | 6 ++
include/linux/hyperv.h| 2 +-
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/d
On 1/26/2018 12:49 PM, Borislav Petkov wrote:
> On Fri, Jan 26, 2018 at 06:45:18PM +, David Woodhouse wrote:
>> On Fri, 2018-01-26 at 19:41 +0100, Borislav Petkov wrote:
>>> +#define X86_FEATURE_AMD_IBPB (13*32+12) /* "" Indirect Branch
>>> Prediction Barrier MSR */
>>
>> Stray quote
On Mon, Nov 06, 2017 at 12:51:57PM +0100, David Hildenbrand wrote:
> On 31.10.2017 12:34, syzbot wrote:
> > Hello,
> >
> > syzkaller hit the following crash on
> > 91dfed74eabcdae9378131546c446442c29bf769
> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> > compiler:
501 - 600 of 727 matches
Mail list logo
