Takashi Iwai wrote:
> Clemens Ladisch wrote:
>> Jiada Wang wrote:
>>> since commit 57e6dae1087bbaa6b33d3dd8a8e90b63888939a3 the expected
>>> packetsize is always limited to
>>> nominal + 25%. It was discovered, that some devices
>>
>> Which devices?
>>
>>> have a much higher jitter in used packets
On Thu, 2016-12-01 at 01:47 -0500, Len Brown wrote:
> Piotr,
> Thanks for sending the patch, I've made this change to my turbostat
> branch for 4.10.
>
> I did not apply your patch directly because for some reason it didn't
> appear in patchwork for linux-pm,
> only for lkml, which I do not review
Bhumika Goyal wrote:
> Declare the structure ath_bus_ops as const as it is only passed as an
> argument to the function ath9k_init_device. This argument is of type
> const struct ath_bus_ops *, so ath_bus_ops structures with this property
> can be declared as const.
> Done using Coccinelle:
> @r1
Le 01/12/2016 à 11:26, Alexandre Belloni a écrit :
> Use devm_kasprintf instead of simple kasprintf to free the allocated memory
> when needed.
>
> Suggested-by: Peter Rosin
> Signed-off-by: Alexandre Belloni
Acked-by: Nicolas Ferre
> ---
> drivers/usb/gadget/udc/atmel_usba_udc.c | 3 ++-
>
Le 01/12/2016 à 11:49, Alexandre Belloni a écrit :
> save_gs is supposed to save the channel status in order to be restored at
> resume time but it is never updated and is always 0. Anyway, the channel
> status is updated in the per channel loop later in the resume function.
>
> Signed-off-by: Ale
On Thu, 01 Dec 2016 12:16:47 +0100,
Clemens Ladisch wrote:
>
> Takashi Iwai wrote:
> > Clemens Ladisch wrote:
> >> Jiada Wang wrote:
> >>> since commit 57e6dae1087bbaa6b33d3dd8a8e90b63888939a3 the expected
> >>> packetsize is always limited to
> >>> nominal + 25%. It was discovered, that some dev
Geliang Tang wrote:
> Drop duplicate header vmalloc.h from ath5k/debug.c.
>
> Signed-off-by: Geliang Tang
Patch applied to ath-next branch of ath.git, thanks.
384abd33d5d5 ath5k: drop duplicate header vmalloc.h
--
https://patchwork.kernel.org/patch/9445537/
Documentation about submitting wi
On Mon, Nov 28, 2016 at 11:10:14AM +0800, Ming Lei wrote:
> When I run stress-ng via the following steps on one ARM64 dual
> socket system(Cavium Thunder), the kernel oops[1] can often be
> triggered after running the stress test for several hours(sometimes
> it may take longer):
>
> - git clone g
Hi Gregory, Marcin,
On Wed, 30 Nov 2016 22:42:49 +0100 Gregory CLEMENT wrote:
> From: Marcin Wojtas
>
> Prepare the mvneta driver in order to be usable on the 64 bits platform
> such as the Armada 3700.
>
> [gregory.clem...@free-electrons.com]: this patch was extract from a larger
> one to eas
On 12/01/2016 12:09 PM, Nicholas Piggin wrote:
On Thu, 1 Dec 2016 11:48:09 +0100
Stanislav Kozina wrote:
On 12/01/2016 05:13 AM, Don Zickus wrote:
...
I think GregKH pointed to one such tool, libabigail? We are working on
others too.
I should mention one of the others here:
https://gith
On 2016-11-30 23:25, Arnd Bergmann wrote:
> On Wednesday, November 30, 2016 1:48:20 PM CET Peter Rosin wrote:
>> Hi!
>>
>> changes v2 -> v3
>> - document the new compatible strings prefixed with "axentia,".
>>
>> changes v1 -> v2
>> - squash the fixup into the correct patch, sorry for the noise.
>>
-NMIs-on-one-CPU-when-unknown_nmi_panic/20161201-171219
config: i386-randconfig-x014-201648 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
On Wed, Aug 10, 2016 at 09:02:48PM +0800, fu@linaro.org wrote:
> From: Tomasz Nowicki
>
> This patch provides APEI arch-specific bits for aarch64
>
> Meanwhile,
> (1)move HEST type (ACPI_HEST_TYPE_IA32_CORRECTED_CHECK) checking to
> a generic place.
> (2)select HAVE_ACPI_APEI when EFI and AC
On Wed, Nov 30, 2016 at 10:29:00PM +0530, Nayna wrote:
>
>
> On 11/26/2016 09:17 PM, Jarkko Sakkinen wrote:
> > On Sat, Nov 26, 2016 at 07:45:39AM -0500, Nayna Jain wrote:
> > > Unlike the device driver support for TPM 1.2, the TPM 2.0 does
> > > not support the securityfs pseudo files for displa
Dear Aniroop Mathur
Got your point.
Thank you for your explanation!
Best regards
Albert (Xu) ZHANG
BST/ESA3.1
-Original Message-
From: Aniroop Mathur [mailto:a.mat...@samsung.com]
Sent: Thursday, December 01, 2016 6:34 PM
To: ZHANG Xu (BST/ESA3.1) ; Dmitry Torokhov
; linux-in...@
On Wed, 30 Nov 2016 22:42:48 +0100 Gregory CLEMENT wrote:
> Until now the virtual address of the received buffer were stored in the
> cookie field of the rx descriptor. However, this field is 32-bits only
> which prevents to use the driver on a 64-bits architecture.
>
> With this patch the virtua
On Thu, 1 Dec 2016 19:26:04 +0800
Jisheng Zhang wrote:
> Hi Gregory, Marcin,
>
> On Wed, 30 Nov 2016 22:42:49 +0100 Gregory CLEMENT wrote:
>
> > From: Marcin Wojtas
> >
> > Prepare the mvneta driver in order to be usable on the 64 bits platform
> > such as the Armada 3700.
> >
> > [gregory.c
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Nicolai Hähnle
---
kernel/locking/test-ww_mutex.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test-ww_mutex
Check that ww_mutexes can detect cyclic deadlocks (generalised ABBA
cycles) and resolve them by lock reordering.
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Nicolai Hähnle
---
kernel/locking/test-ww_mutex.c | 115 ++
v2: Add a couple more variations for degenerate ww_mutex, decrease
timeouts
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Nicolai Hähnle
---
kernel/locking/Makefile| 1 +
kernel/locking/test-ww_mutex.c | 140 +++
Hi Jisheng,
Which baseline do you use?
It took me really lot of time to catch why RX broke after rebase from
LKv4.1 to LKv4.4. Between those two, in commit:
97303480753e ("arm64: Increase the max granular size")
L1_CACHE_BYTES for all ARMv8 platforms was increased to 128B and so
did NET_SKB_PAD.
Nicolai Hähnle was looking into a deadlock within ww_mutexes (that has
been fixed by Peter's mutex rewrite) and to support his changes, I
thought it was be useful to have a small validation suite for ww_mutex.
-Chris
Although ww_mutexes degenerate into mutexes, it would be useful to
torture the deadlock handling between multiple ww_mutexes in addition to
torturing the regular mutexes.
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Nicolai Hähnle
---
kernel/lockin
>From conflicting macro parameters, passing the wrong name to
__MUTEX_INITIALIZER and a stray '\', #define __WW_MUTEX_INITIALIZER was
very unhappy.
One unnecessary change was to choose to pass &ww_class instead of
implicitly taking the address of the class within the macro.
Fixes: 1b375dc30710 ("
v2: Use both inorder and reorder locking strategies
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Nicolai Hähnle
---
kernel/locking/test-ww_mutex.c | 254 +
1 file changed, 254 insertions(+)
diff --git a/kern
Add the minimal test running (modprobe test-ww_mutex) to the kselftests
CI framework.
Signed-off-by: Chris Wilson
Cc: Shuah Khan
Cc: Peter Zijlstra
Cc: Ingo Molnar
---
tools/testing/selftests/locking/ww_mutex.sh | 10 ++
1 file changed, 10 insertions(+)
create mode 100755 tools/testi
Signed-off-by: Chris Wilson
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Nicolai Hähnle
---
kernel/locking/test-ww_mutex.c | 98 ++
1 file changed, 98 insertions(+)
diff --git a/kernel/locking/test-ww_mutex.c b/kernel/locking/test-ww_mu
Takashi Iwai wrote:
> Clemens Ladisch wrote:
>> Takashi Iwai wrote:
>>> [...]
>>> In the commit mentioned above, we changed the logic to take +25%
>>> frequency as the basis, and it my *reduce* if ep->maxpacksize is lower
>>> than that.
>>>
>>> OTOH, if ep->maxpacksize is sane, we can rely on it ra
This patch add support to return value from host_init() callback from
drivers,so that the designware library can handle or pass it to proper
place. Issue with void return type is that errors or error handling
within host_init() callback are never know to designware code, which
could go ahead and ac
On 10 August 2015 at 11:43, Jan Kara wrote:
> On Sun 09-08-15 10:49:33, Sasha Levin wrote:
>> I saw the following warning while fuzzing with trinity:
>>
>> [385644.689209] WARNING: CPU: 1 PID: 23536 at mm/truncate.c:740
>> pagecache_isize_extended+0x124/0x180()
>> [385644.691780] Modules linked i
On 12/01/2016 at 06:33 PM, Joerg Roedel wrote:
> On Thu, Dec 01, 2016 at 10:15:45AM +0800, Xunlei Pang wrote:
>> index 3965e73..624eac9 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -2024,6 +2024,25 @@ static int domain_context_mapping_one(struct
>> dmar_do
On Thu, Dec 01, 2016 at 02:27:19AM +, Gonglei (Arei) wrote:
> > On Tue, Nov 29, 2016 at 08:48:14PM +0800, Gonglei wrote:
> > > diff --git a/drivers/crypto/virtio/virtio_crypto_algs.c
> > b/drivers/crypto/virtio/virtio_crypto_algs.c
> > > new file mode 100644
> > > index 000..08b077f
> > > -
Hi Borislav,
On 1 December 2016 at 19:41, Borislav Petkov wrote:
> On Wed, Aug 10, 2016 at 09:02:48PM +0800, fu@linaro.org wrote:
>> From: Tomasz Nowicki
>>
>> This patch provides APEI arch-specific bits for aarch64
>>
>> Meanwhile,
>> (1)move HEST type (ACPI_HEST_TYPE_IA32_CORRECTED_CHECK)
On Thu, Dec 01, 2016 at 02:27:19AM +, Gonglei (Arei) wrote:
> > On Tue, Nov 29, 2016 at 08:48:14PM +0800, Gonglei wrote:
> > > +static int virtio_crypto_alg_ablkcipher_init_session(
> > > + struct virtio_crypto_ablkcipher_ctx *ctx,
> > > + uint32_t alg, const uint8_t *key,
> > >
On Thu, 1 Dec 2016, David Gibson wrote:
> On Thu, Dec 01, 2016 at 12:21:02AM +0100, Thomas Gleixner wrote:
> > On Wed, 30 Nov 2016, David Gibson wrote:
> > > On Tue, Nov 29, 2016 at 03:22:17PM +0100, Thomas Gleixner wrote:
> > > > If we have legitimate use cases with a negative delta, then this pat
This patch adds the CPU clock phandle in CPU's node
and uses operating-points-v2 to register operating points.
So it can be used by cpufreq-dt driver.
Signed-off-by: Baoyou Xie
---
arch/arm64/boot/dts/zte/zx296718.dtsi | 37 +++
1 file changed, 37 insertions(+)
Hi Laura,
On 29/11/16 18:55, Laura Abbott wrote:
> __pa_symbol is technically the marco that should be used for kernel
macro
> symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL which
> will do bounds checking. As part of this, introduce lm_alias, a
> macro which wraps the __va(__pa(..
Em Thu, 1 Dec 2016 11:48:46 +0100
Borislav Petkov escreveu:
> On Wed, Nov 30, 2016 at 08:50:13AM -0200, Mauro Carvalho Chehab wrote:
> > Fixed. If you have a stable branch, I can rebase it on the top
> > of your patches, in order to avoid the confict at linux-next.
>
> http://git.kernel.org/cgit
2016-11-30 11:10 GMT+01:00 Lars-Peter Clausen :
> On 11/29/2016 04:35 PM, Bartosz Golaszewski wrote:
>> 2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen :
>>> On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote:
>>> [...]
diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>>
Hi Marcin,
On Thu, 1 Dec 2016 12:48:39 +0100 Marcin Wojtas wrote:
> Hi Jisheng,
>
> Which baseline do you use?
>
> It took me really lot of time to catch why RX broke after rebase from
> LKv4.1 to LKv4.4. Between those two, in commit:
> 97303480753e ("arm64: Increase the max granular size")
> L
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Wednesday, November 30, 2016 7:26 PM
> To: Salil Mehta
> Cc: Zhuangyuzeng (Yisen); mehta.salil@gmail.com;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm
> Subject: Re: [PATCH V2 net-next] ne
This patch adds the CPU clock phandle in CPU's node
and uses operating-points-v2 to register operating points.
So it can be used by cpufreq-dt driver.
Signed-off-by: Baoyou Xie
---
arch/arm64/boot/dts/zte/zx296718.dtsi | 37 +++
1 file changed, 37 insertions(+)
On Thu 2016-12-01 10:07:01, Sergey Senozhatsky wrote:
> On (11/24/16 17:35), Petr Mladek wrote:
> [..]
> > > #ifdef CONFIG_PRINTK_NMI
> > > -extern void printk_nmi_init(void);
> > > -extern void printk_nmi_enter(void);
> > > -extern void printk_nmi_exit(void);
> > > -extern void printk_nmi_flush(v
Signed-off-by: Peter Rosin
---
.../bindings/sound/axentia,tse850-pcm5142.txt | 5 ++---
sound/soc/atmel/tse850-pcm5142.c | 23 +++---
2 files changed, 5 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5
The SSC is currently not usable with the ASoC simple-audio-card, as
every SSC audio user has to build a platform driver that may do as
little as calling atmel_ssc_set_audio/atmel_ssc_put_audio (which
allocates the SSC and registers a DAI with the ASoC subsystem).
So, have that happen automatically
Hi!
The Atmel SSC is currently not usable as an audio DAI unless someone
registers it with ASoC. This is currently delegated to a platform
driver for every possible audio use, and prevents the SSC from being
used as a cpu DAI with the simple-audio-card driver.
The first patch fixes this.
The sec
Jiada Wang wrote:
> On 11/30/2016 11:41 PM, Clemens Ladisch wrote:
>> Jiada Wang wrote:
>>> since commit 57e6dae1087bbaa6b33d3dd8a8e90b63888939a3 the expected
>>> packetsize is always limited to
>>> nominal + 25%. It was discovered, that some devices
>>
>> Which devices?
>
> It was a LG nexus
So
On 11/29/2016 09:17 PM, Dave Hansen wrote:
Andrew, you can drop proc-mm-export-pte-sizes-directly-in-smaps-v2.patch,
and replace it with this.
Changes from v2:
* Do not assume (wrongly) that smaps_hugetlb_range() always uses
PUDs. (Thanks for pointing this out, Vlastimil). Also handle
h
On Thu, 1 Dec 2016 20:02:05 +0800 Jisheng Zhang wrote:
> Hi Marcin,
>
> On Thu, 1 Dec 2016 12:48:39 +0100 Marcin Wojtas wrote:
>
> > Hi Jisheng,
> >
> > Which baseline do you use?
> >
> > It took me really lot of time to catch why RX broke after rebase from
> > LKv4.1 to LKv4.4. Between those
>
> Subject: Re: [PATCH v4 1/1] crypto: add virtio-crypto driver
>
> On Thu, Dec 01, 2016 at 02:27:19AM +, Gonglei (Arei) wrote:
> > > On Tue, Nov 29, 2016 at 08:48:14PM +0800, Gonglei wrote:
> > > > +static int virtio_crypto_alg_ablkcipher_init_session(
> > > > + struct virtio_c
.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=hwparam
at tag:
hwparam-20161201
David
---
David Howells (39):
Annotate module params that specify hardware parameters (eg. ioport)
Annotate hardware config module parameters in arch/x86/mm/
Annotate hardwar
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
Provided an annotation for module parameters that specify hardware
parameters (such as io ports, iomem addresses, irqs, dma channels, fixed
dma buffers and other types).
This will enable such parameters to be locked down in the core parameter
parser for secure boot support.
I've also included ann
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
On Thu, Dec 01, 2016 at 06:52:35AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 30, 2016 at 01:13:03PM -0600, Josh Poimboeuf wrote:
> > This question was probably intended for other folks, but I should point
> > out that idle tasks *do* invoke the scheduler. cpu_idle_loop() calls
> > schedule_preemp
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
>
> On Thu, Dec 01, 2016 at 02:27:19AM +, Gonglei (Arei) wrote:
> > > On Tue, Nov 29, 2016 at 08:48:14PM +0800, Gonglei wrote:
> > > > diff --git a/drivers/crypto/virtio/virtio_crypto_algs.c
> > > b/drivers/crypto/virtio/virtio_crypto_algs.c
> > > > new file mode 100644
> > > > index 000..
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
Hi Jisheng,
2016-12-01 13:16 GMT+01:00 Jisheng Zhang :
> On Thu, 1 Dec 2016 20:02:05 +0800 Jisheng Zhang wrote:
>
>> Hi Marcin,
>>
>> On Thu, 1 Dec 2016 12:48:39 +0100 Marcin Wojtas wrote:
>>
>> > Hi Jisheng,
>> >
>> > Which baseline do you use?
>> >
>> > It took me really lot of time to catch why
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
v5:
- add comments for algs_lock and table_lock. [Stefan]
- use kzfree instead of kfree for key material security. [Stefan]
- drop unnecessary spin_lock for struct virtio_crypto_ablkcipher_ctx.
- dynamically allocated memory for iv in order to avoid to do DMA from
the stack memory in __virti
On Wed, Nov 30, 2016 at 10:56:57PM -0800, Guenter Roeck wrote:
> Hi Paul,
>
> On Wed, Nov 30, 2016 at 05:19:50PM -0800, Paul E. McKenney wrote:
> [ ... ]
>
> > > > >
> > > > > BUG: sleeping function called from invalid context at
> > > > > mm/page_alloc.c:3775
> [ ... ]
> >
> > Whew! You had
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
On Thu, 1 Dec 2016 12:33:02 +0100
Stanislav Kozina wrote:
> On 12/01/2016 12:09 PM, Nicholas Piggin wrote:
> > On Thu, 1 Dec 2016 11:48:09 +0100
> > Stanislav Kozina wrote:
> >
> >> On 12/01/2016 05:13 AM, Don Zickus wrote:
> >>
> >> ...
> >>
> >>> I think GregKH pointed to one such tool, li
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
devi
On Thu, Dec 01, 2016 at 04:28:33PM +0530, Maninder Singh wrote:
> variable name can have Non NULL terminated string after cropping
> which may result strcat to fail, and cropping is not
> required if (strlen(oh->name) + 8 < MOD_CLK_MAX_NAME_LEN).
>
> Issue caught with static analysis tool:
> "Dang
On Thu, Dec 01, 2016 at 06:30:35AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 30, 2016 at 11:40:19AM -0800, Paul E. McKenney wrote:
>
> > > See commit:
> > >
> > > 4a81e8328d37 ("rcu: Reduce overhead of cond_resched() checks for RCU")
> > >
> > > Someone actually wrote down what the problem wa
On 11/30/2016 05:41 PM, Nicolas Pitre wrote:
> On Wed, 30 Nov 2016, Linus Torvalds wrote:
>
>> On Wed, Nov 30, 2016 at 10:50 AM, Prarit Bhargava wrote:
>>>
>>> It comes back. The steps to reproduce this are:
>>>
>>> 1. checkout latest linux.git
>>> 2. make -j112
>>>
>>> (IOW, it occurs 100%
On 2016/11/30 23:58, Nikita Yushchenko wrote:
>>> (1) When DSA is in use, frames processed by FEC chip contain DSA tag and
>>> thus can be larger than hardcoded limit of 1522. This issue is not
>>> FEC-specific, any driver that hardcodes maximum frame size to 1522 (many
>>> do) will have this issue
1 - 100 of 877 matches
Mail list logo
