Consolidated all the "manual" TPM startup code to a single function
in order to make code flows a bit cleaner and migrate to tpm_buf.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-interface.c | 67 +---
drivers/char/tpm/tpm.h | 6 +---
dri
On Tue, Jun 20, 2017 at 10:50 AM, Sandy Harris wrote:
> On Tue, Jun 20, 2017 at 5:49 AM, Jeffrey Walton wrote:
>> On Tue, Jun 20, 2017 at 5:36 AM, Theodore Ts'o wrote:
>>> On Tue, Jun 20, 2017 at 10:53:35AM +0200, Jason A. Donenfeld wrote:
>
> Suppressing all messages for all configurations
On Tue, Jun 20, 2017 at 06:49:33PM +0200, David Hildenbrand wrote:
> On 20.06.2017 18:44, Rik van Riel wrote:
> > On Mon, 2017-06-12 at 07:10 -0700, Dave Hansen wrote:
> >
> >> The hypervisor is going to throw away the contents of these pages,
> >> right? As soon as the spinlock is released, some
Yu-cheng,
Am 20.06.2017 um 20:04 schrieb Yu-cheng Yu:
>>> So to summarize:
>>>
>>> - PTRACE_GETREGSET with NT_X86_XSTATE gets 832 and return 832, with no
>>> error.
>>>
>>> - PTRACE_SETREGSET get 832 (sizeof struct _xstate) but wants at least
>>> 1088, otherwise it will fail with -EFAULT (why not
On Tue, 2017-06-20 at 12:13 -0600, Baicar, Tyler wrote:
> On 6/20/2017 2:47 AM, Andy Shevchenko wrote:
> > On Tue, 2017-06-20 at 10:43 +0200, Christoph Hellwig wrote:
> > >
> Andy,
>
> The patch that was causing compilation failures on your branch was:
>
> 22e31da efi: Switch to use new generic
On Tue, Jun 20, 2017 at 12:13:13PM -0600, Baicar, Tyler wrote:
> I have sent you the rebased patches. I took Christoph's uuid-types tree and
> added this patch onto it:
>
> 7bf130e4a065 ("ACPI/APEI: Handle GSIV and GPIO notification types")
>
> And then added my patches onto that. This will hopef
On Tue, Jun 20, 2017 at 01:29:00PM -0400, Rik van Riel wrote:
> On Tue, 2017-06-20 at 18:49 +0200, David Hildenbrand wrote:
> > On 20.06.2017 18:44, Rik van Riel wrote:
>
> > > Nitesh Lal (on the CC list) is working on a way
> > > to efficiently batch recently freed pages for
> > > free page hinti
On 6/20/2017 12:20 PM, Will Deacon wrote:
On Tue, Jun 20, 2017 at 12:13:13PM -0600, Baicar, Tyler wrote:
I have sent you the rebased patches. I took Christoph's uuid-types tree and
added this patch onto it:
7bf130e4a065 ("ACPI/APEI: Handle GSIV and GPIO notification types")
And then added my p
Hi Jon,
>
> >> >> The current SPCR code does not check the access width of the mmio,
> >> >> and
> >> >> uses a default of 8bit register accesses. This prevents devices
> >> >> that
> >> >> only do 16 or 32bit register accesses from working. By simply
> >> >> checking
Hi Mark and All,
Do you have any comments on this patch set?
Thank you!
Hoan
On Tue, Jun 6, 2017 at 11:02 AM, Hoan Tran wrote:
> This patch set adds support for SoC-wide (AKA uncore) Performance Monitoring
> Unit version 3.
>
> It can support up to
> - 2 IOB PMU instances
> - 8 L3C PMU instan
On 20.06.2017 20:17, Michael S. Tsirkin wrote:
> On Tue, Jun 20, 2017 at 06:49:33PM +0200, David Hildenbrand wrote:
>> On 20.06.2017 18:44, Rik van Riel wrote:
>>> On Mon, 2017-06-12 at 07:10 -0700, Dave Hansen wrote:
>>>
The hypervisor is going to throw away the contents of these pages,
On Tue, Jun 20, 2017 at 08:54:29PM +0200, David Hildenbrand wrote:
> On 20.06.2017 20:17, Michael S. Tsirkin wrote:
> > On Tue, Jun 20, 2017 at 06:49:33PM +0200, David Hildenbrand wrote:
> >> On 20.06.2017 18:44, Rik van Riel wrote:
> >>> On Mon, 2017-06-12 at 07:10 -0700, Dave Hansen wrote:
> >>>
Yu-cheng,
Am 20.06.2017 um 20:17 schrieb Richard Weinberger:
> Yu-cheng,
>
> Am 20.06.2017 um 20:04 schrieb Yu-cheng Yu:
So to summarize:
- PTRACE_GETREGSET with NT_X86_XSTATE gets 832 and return 832, with no
error.
- PTRACE_SETREGSET get 832 (sizeof struct _xstate)
John reported that an Intel QuickAssist crypto accelerator didn't work in a
Dell PowerEdge R730. The problem seems to be that we enabled ECRC when the
device doesn't support it:
85:00.0 Co-processor [0b40]: Intel Corporation DH895XCC Series QAT [8086:0435]
Capabilities: [100 v1] Advanced Er
>> IMHO even simply writing all-zeros to all free pages before starting
>> migration (or even when freeing a page) would be a cleaner interface
>> than this (because it atomically works with the entity the host cares
>> about for migration). But yes, performance is horrible that's why I am
>> not
Hi,
On 06/20/2017 09:42 AM, Russell King - ARM Linux wrote:
> On Fri, May 19, 2017 at 12:57:08PM -0500, Dave Gerlach wrote:
>> +.arm
>> +.align 3
>> +
>> +ENTRY(ti_emif_sram)
>
> Will you ever want to have any of this code as Thumb?
I cannot see any requirement for that. I will say it is
On Tue, 2017-06-20 at 13:42 -0400, Rik van Riel wrote:
> On Mon, 2017-06-19 at 04:12 +0200, Frederic Weisbecker wrote:
> > Although idle load balancing obviously only concern idle CPUs, it can
> > be a disturbance on a busy nohz_full CPU. Indeed a CPU can only get
> > rid
> > of an idle load balanc
On 6/20/17, 1:45 PM, "Tejun Heo" wrote:
> Applied to percpu/for-4.13. I had to update 0002 because of the
> recent __ro_after_init changes. Can you please see whether I made any
> mistakes while updating it?
There is a tagging mismatch in 0002. Can you please change or remove the
__read_mostly
From: Krzysztof Kozlowski
Date: Mon, 19 Jun 2017 18:05:41 +0200
> The lan911x family of devices require supplying from 3.3 V power
> supplies (connected to VDD_IO, VDD_A and VREG_3.3 pins). The existing
> driver however obtains only VDD_IO and VDD_A regulators in an optional
> way so document th
On 20 Jun 2017, at 13:06, Jeff Layton wrote:
>
> Now that I think about it a bit more, I don't think we really need a
> flag here.
>
> Just have the ->lock operation set the fl_pid to a negative value. That
> will never be a valid pid anyway. Then flock_translate_pid could just
> return any negativ
From: Niklas Cassel
Date: Mon, 19 Jun 2017 18:36:44 +0200
> There is nothing in the IP that prevents us from enabling TSO for IPv6.
>
> Before patch:
> ftp fe80::2aa:bbff:fecc:1336%eth0
> ftp> get /dev/zero
> 882512708 bytes received in 00:14 (56.11 MiB/s)
>
> After patch:
> ftp fe80::2aa:bbff:
On Mon, 19 Jun 2017, Vitaly Kuznetsov wrote:
> +#define HV_X64_ACCESS_FREQUENCY_MSRS (1 << 11)
>
> /*
> * Basic SynIC MSRs (HV_X64_MSR_SCONTROL through HV_X64_MSR_EOM
> @@ -73,6 +67,9 @@
>*/
> #define HV_X64_MSR_STAT_PAGES_AVAILABLE (1 << 8)
>
> +/* Frequency MSRs a
From: Denys Vlasenko
Date: Mon, 19 Jun 2017 21:50:52 +0200
> Only compile-tested - I don't have the hardware.
>
> From code inspection, octeon_pci_write_core_mem() appears to be safe wrt
> unaligned source. In any case, u8 fbuf[] was not guaranteed to be aligned
> anyway.
>
> Signed-off-by: Den
From: Julien Gomes
Date: Mon, 19 Jun 2017 13:44:13 -0700
> Currently, all ipmr/ip6mr cache reports are sent through the
> mroute/mroute6 socket only.
> This forces the use of a single socket for mroute programming, cache
> reports and, regarding ipmr, IGMP messages without Router Alert option
> r
Hi!
While trying to get CLUT support for the atmel_hlcdc driver, and
specifically for the emulated fbdev interface, I received some
push-back that my feeble in-driver attempts should be solved
by the core. This is my attempt to do it right.
Boris and Daniel, was this approximately what you had in
The redundant fb helpers .gamma_set and .gamma_get are no longer
used. Remove the dead code and hook up the crtc .gamma_set
to use the crtc gamma_store directly instead of duplicating that
info locally.
It is a bit strange that the fb helper .load_lut was not hooked
up, so this change may well mak
The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
no longer used. Remove the dead code and hook up the crtc .gamma_set
to use the crtc gamma_store directly instead of duplicating that
info locally.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/ast/ast_drv.h | 1 -
drivers/gpu/
The driver stores lut values from the fbdev interface, and is able
to give them back, but does not appear to do anything with these
lut values. The generic fb helpers have replaced this function,
and may even have made the driver work for the C8 mode from the
fbdev interface. But that is untested.
Hi John,
Any chance you could test this patch?
I think it should fix this old bug report:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1571798
But I haven't seen any confirmation of it.
Bjorn
On Tue, Jun 20, 2017 at 02:02:07PM -0500, Bjorn Helgaas wrote:
> John reported that an Intel Q
The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
no longer used. Remove the dead code and hook up the crtc .gamma_set
to use the crtc gamma_store directly instead of duplicating that
info locally.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 26 ++
Drivers no longer have any need for these callbacks, and there are no
users. Zap. Zap-zap-zzzap-p-pp-p.
Signed-off-by: Peter Rosin
---
include/drm/drm_fb_helper.h | 32
include/drm/drm_modeset_helper_vtables.h | 16
2 files changed,
On Mon, Jun 19, 2017 at 11:56 PM, Christoph Hellwig wrote:
> On Mon, Jun 19, 2017 at 01:56:40PM -0700, Kees Cook wrote:
>> Since the ACPICA source is maintained externally to the kernel, we can
>> neither switch it to designated initializers nor mark it
>> __no_randomize_layout. Until ACPICA-upstr
The redundant fb helper .load_lut is no longer used, and can not
work right without also providing the fb helpers .gamma_set and
.gamma_get thus rendering the code in this driver suspect.
Just remove the dead code.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/stm/ltdc.c | 12
dri
On Tue, Jun 20, 2017 at 07:47:37PM +0530, Geetha sowjanya wrote:
> From: Linu Cherian
>
> Cavium ThunderX2 implementation doesn't support second page in SMMU
> register space. Hence, resource size is set as 64k for this model.
>
> Signed-off-by: Linu Cherian
> Signed-off-by: Geetha Sowjanya
>
The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
no longer used. Remove the dead code and hook up the crtc .gamma_set
to use the crtc gamma_store directly instead of duplicating that
info locally.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/radeon/atombios_crtc.c | 1 -
The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
no longer used. Remove the dead code and hook up the crtc .gamma_set
to use the crtc gamma_store directly instead of duplicating that
info locally.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/mgag200/mgag200_drv.h | 5 ---
dr
The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
no longer used. Remove the dead code and hook up the crtc .gamma_set
to use the crtc gamma_store directly instead of duplicating that
info locally.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 24 -
This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
totally obsolete.
I think the gamma_store can end up invalid on error. But the way I read
it, that can happen in drm_mode_gamma_set_ioctl as well, so why should
this pesky legacy fbdev stuff be any better?
drm_fb_helper_save
The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
no longer used. Remove the dead code and hook up the crtc .gamma_set
to use the crtc gamma_store directly instead of duplicating that
info locally.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/cirrus/cirrus_drv.h | 8
dr
On Tue, Jun 20, 2017 at 08:13:34PM +0200, Jarkko Sakkinen wrote:
> Consolidated all the "manual" TPM startup code to a single function
> in order to make code flows a bit cleaner and migrate to tpm_buf.
>
> Signed-off-by: Jarkko Sakkinen
> drivers/char/tpm/tpm-interface.c | 67
> +++
On Tue, 2017-06-20 at 15:17 -0400, Benjamin Coddington wrote:
> On 20 Jun 2017, at 13:06, Jeff Layton wrote:
> >
> > Now that I think about it a bit more, I don't think we really need a
> > flag here.
> >
> > Just have the ->lock operation set the fl_pid to a negative value. That
> > will never b
On Tue, Jun 20, 2017 at 07:12:49PM +, Dennis Zhou wrote:
> On 6/20/17, 1:45 PM, "Tejun Heo" t...@kernel.org> wrote:
> > Applied to percpu/for-4.13. I had to update 0002 because of the
> > recent __ro_after_init changes. Can you please see whether I made any
> > mistakes while updating it?
>
On Tue, Jun 20, 2017 at 10:51:58PM +0800, Jhih-Ming Huang wrote:
>
> Hi,
>
> This patch fix all coding style error in driver/staging/ccree/ssi_aead.c.
Much better. Thanks!
regards,
dan carpenter
Hello, Nikolay.
On Tue, Jun 20, 2017 at 09:02:00PM +0300, Nikolay Borisov wrote:
> Currently the writeback statistics code uses a percpu counters to hold
> various statistics. Furthermore we have 2 families of functions - those which
> disable local irq and those which doesn't and whose names begi
Commit-ID: 3f1d472055bbe914c9e54715fdbf2272851e23ff
Gitweb: http://git.kernel.org/tip/3f1d472055bbe914c9e54715fdbf2272851e23ff
Author: Mariusz Skamra
AuthorDate: Fri, 26 May 2017 15:00:47 +0200
Committer: Thomas Gleixner
CommitDate: Tue, 20 Jun 2017 21:33:55 +0200
ktime: Simplify ktime
On 20 Jun 2017, at 15:32, Jeff Layton wrote:
On Tue, 2017-06-20 at 15:17 -0400, Benjamin Coddington wrote:
On 20 Jun 2017, at 13:06, Jeff Layton wrote:
Now that I think about it a bit more, I don't think we really need a
flag here.
Just have the ->lock operation set the fl_pid to a negative
On Mon, 2017-06-19 at 16:36 -0700, Kees Cook wrote:
> This series is modified from Brad Spengler/PaX Team's PAX_USERCOPY
> code
> in the last public patch of grsecurity/PaX based on our understanding
> of the code. Changes or omissions from the original code are ours and
> don't reflect the origina
From: Niklas Cassel
Date: Tue, 20 Jun 2017 14:32:41 +0200
> When having the skb pointer in the first descriptor, stmmac_tx_clean
> can get called at a moment where the IP has only cleared the own bit
> of the first descriptor, thus freeing the skb, even though there can
> be several descriptors w
Commit-ID: d15bc69affc57d7985a01745ca28eafa0772325b
Gitweb: http://git.kernel.org/tip/d15bc69affc57d7985a01745ca28eafa0772325b
Author: Peter Meerwald-Stadler
AuthorDate: Tue, 30 May 2017 21:41:03 +0200
Committer: Thomas Gleixner
CommitDate: Tue, 20 Jun 2017 21:33:55 +0200
timers: Fix p
From: Kalle Valo
Date: Tue, 20 Jun 2017 16:39:59 +0300
> here's a pull request to net tree, few important fixes still I would
> like to have in 4.12. Please let me know if there are any problems.
Pulled, thanks Kalle.
Commit-ID: 098b0e01a91c42aaaf0425605cd126b03fcb0bcf
Gitweb: http://git.kernel.org/tip/098b0e01a91c42aaaf0425605cd126b03fcb0bcf
Author: Thomas Gleixner
AuthorDate: Tue, 20 Jun 2017 17:37:36 +0200
Committer: Thomas Gleixner
CommitDate: Tue, 20 Jun 2017 21:33:56 +0200
posix-cpu-timers: Ma
Commit-ID: 35eb7258c009dc478338e674a5a84d25d0929c56
Gitweb: http://git.kernel.org/tip/35eb7258c009dc478338e674a5a84d25d0929c56
Author: Thomas Gleixner
AuthorDate: Tue, 20 Jun 2017 17:37:35 +0200
Committer: Thomas Gleixner
CommitDate: Tue, 20 Jun 2017 21:33:56 +0200
itimer: Make timeval
Commit-ID: 9f93d87cba63e3d18629261243b1f633519eabb5
Gitweb: http://git.kernel.org/tip/9f93d87cba63e3d18629261243b1f633519eabb5
Author: Marcin Nowakowski
AuthorDate: Fri, 9 Jun 2017 09:04:05 +0200
Committer: Thomas Gleixner
CommitDate: Tue, 20 Jun 2017 21:41:58 +0200
irqchip/mips-gic: M
>From 104b4e5139fe384431ac11c3b8a6cf4a529edf4a Mon Sep 17 00:00:00 2001
From: Nikolay Borisov
Date: Tue, 20 Jun 2017 21:01:20 +0300
Currently, percpu_counter_add is a wrapper around __percpu_counter_add
which is preempt safe due to explicit calls to preempt_disable. Given
how __ prefix is used i
On Mon, Jun 19, 2017 at 5:33 PM, Luis Ressel wrote:
> For PF_UNIX, SOCK_RAW is synonymous with SOCK_DGRAM (cf.
> net/unix/af_unix.c). This is a tad obscure, but libpcap uses it.
>
> Signed-off-by: Luis Ressel
> Acked-by: Stephen Smalley
> ---
> security/selinux/hooks.c | 1 +
> 1 file changed,
On Tue, 2017-06-20 at 21:26 +0300, Michael S. Tsirkin wrote:
> On Tue, Jun 20, 2017 at 01:29:00PM -0400, Rik van Riel wrote:
> > I agree with that. Let me go into some more detail of
> > what Nitesh is implementing:
> >
> > 1) In arch_free_page, the being-freed page is added
> > to a per-cpu s
On 20-06-17 08:22, Christophe JAILLET wrote:
> If 'wiphy_new()' fails, we leak 'ops'. Add a new label in the error
> handling path to free it in such a case.
Thanks. Please add the following tags:
Cc: sta...@vger.kernel.org
> Fixes: 5c22fb85102a7 ("brcmfmac: add wowl gtk rekeying offload suppor
On Tue, 2017-06-20 at 20:59 +0200, Richard Weinberger wrote:
> Yu-cheng,
>
> Am 20.06.2017 um 20:17 schrieb Richard Weinberger:
> > Yu-cheng,
> >
> > Am 20.06.2017 um 20:04 schrieb Yu-cheng Yu:
> So to summarize:
>
> - PTRACE_GETREGSET with NT_X86_XSTATE gets 832 and return 832, wi
From: Tejun Heo
Date: Tue, 20 Jun 2017 15:47:59 -0400
> From 104b4e5139fe384431ac11c3b8a6cf4a529edf4a Mon Sep 17 00:00:00 2001
> From: Nikolay Borisov
> Date: Tue, 20 Jun 2017 21:01:20 +0300
>
> Currently, percpu_counter_add is a wrapper around __percpu_counter_add
> which is preempt safe due t
On Tue, Jun 20, 2017 at 8:33 PM, Stefan Berger
wrote:
> On 06/20/2017 08:19 AM, Stefan Berger wrote:
>>
>> On 06/20/2017 01:42 AM, Amir Goldstein wrote:
>>> Apropos stackable filesystems [cc some overlayfs folks], is there any
>>> way that parts of this work could be generalized towards ns a
On Tue, Jun 20, 2017 at 08:42:45AM +0300, Amir Goldstein wrote:
> On Tue, Jun 20, 2017 at 12:34 AM, Eric W. Biederman
> wrote:
> > "Serge E. Hallyn" writes:
> >
> >> Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
> >>> On 06/14/2017 11:05 PM, Serge E. Hallyn wrote:
> >>> >On Wed, Jun 14, 201
On Tue, Jun 20, 2017 at 01:37:15AM +0200, Thomas Gleixner wrote:
> static int vmd_enable_domain(struct vmd_dev *vmd)
> {
> struct pci_sysdata *sd = &vmd->sysdata;
> + struct fwnode_handle *fn;
> struct resource *res;
> u32 upper_bits;
> unsigned long flags;
> @@ -617,8
On Tue, 2017-06-20 at 15:49 -0400, Paul Moore wrote:
> On Mon, Jun 19, 2017 at 5:33 PM, Luis Ressel wrote:
> > For PF_UNIX, SOCK_RAW is synonymous with SOCK_DGRAM (cf.
> > net/unix/af_unix.c). This is a tad obscure, but libpcap uses it.
> >
> > Signed-off-by: Luis Ressel
> > Acked-by: Stephen Sm
1) Fix refcounting wrt. timers which hold onto inet6 address objects,
from Xin Long.
2) Fix an ancient bug in wireless wext ioctls, from Johannes Berg.
3) Firmware handling fixes in brcm80211 driver, from Arend Van Spriel.
4) Several mlx5 driver fixes (firmware readiness, timestamp cap repor
On Tue, Jun 20, 2017 at 06:50:13PM +0200, Dhananjay Balan wrote:
> The locking and unlocking code used by copy routines is common, so
> moved it to a macro.
>
> Signed-off-by: Dhananjay Balan
> ---
> drivers/staging/sm750fb/sm750.c | 81
> -
> 1 file chan
On Tue, 20 Jun 2017, Keith Busch wrote:
> On Tue, Jun 20, 2017 at 01:37:15AM +0200, Thomas Gleixner wrote:
> > static int vmd_enable_domain(struct vmd_dev *vmd)
> > {
> > struct pci_sysdata *sd = &vmd->sysdata;
> > + struct fwnode_handle *fn;
> > struct resource *res;
> > u32 upper_
On Mon, Jun 19, 2017 at 11:47:20PM +0300, Andy Shevchenko wrote:
> On Mon, Jun 19, 2017 at 11:32 PM, Sudip Mukherjee
> wrote:
>
>
> > +#ifdef CONFIG_X86
> > + primary = pdev->resource[PCI_ROM_RESOURCE].flags &
> > + IORESOURCE_ROM_SHADOW;
> > +#endif
>
On Tue, Jun 20, 2017 at 8:14 PM, Kees Cook wrote:
> How about doing this:
>
>default DEBUG_KERNEL
>
> Most distro kernel select DEBUG_KERNEL because it unhides a bunch of
> other useful configs. Since it doesn't strictly _depend_ on
> DEBUG_KERNEL, I think it's probably a mistake to enforce a
I see new warnings with gcc-7.0.1 with the modified container_of():
fs/f2fs/dir.c: In function 'F2FS_I':
fs/f2fs/f2fs.h:1122:385: note: found mismatched ssa struct pointer types:
'struct f2fs_inode_info' and 'struct inode'
This seems to happen for all structures that have a zero offset
between t
CONFIG_COMPILE_TEST allows building a configuration without
TI_SCI_PROTOCOL, which then fails to link:
drivers/clk/keystone/sci-clk.o: In function `ti_sci_clk_probe':
sci-clk.c:(.text.ti_sci_clk_probe+0x4c): undefined reference to
`devm_ti_sci_get_handle'
This makes it a hard dependency. Right n
Changing from a memcpy to per-member comparison left the
size variable unused:
net/ipv4/tcp_ipv4.c: In function 'tcp_md5_do_lookup':
net/ipv4/tcp_ipv4.c:910:15: error: unused variable 'size'
[-Werror=unused-variable]
This does not show up when CONFIG_IPV6 is enabled, but the
variable can be remo
> Am 20.06.2017 um 21:53 schrieb Yu-cheng Yu :
>
>> On Tue, 2017-06-20 at 20:59 +0200, Richard Weinberger wrote:
>> Yu-cheng,
>>
>>> Am 20.06.2017 um 20:17 schrieb Richard Weinberger:
>>> Yu-cheng,
>>>
>>> Am 20.06.2017 um 20:04 schrieb Yu-cheng Yu:
>> So to summarize:
>>
>> - PTRA
On Tue, 2017-06-20 at 15:39 -0400, Benjamin Coddington wrote:
> On 20 Jun 2017, at 15:32, Jeff Layton wrote:
>
> > On Tue, 2017-06-20 at 15:17 -0400, Benjamin Coddington wrote:
> > > On 20 Jun 2017, at 13:06, Jeff Layton wrote:
> > > >
> > > > Now that I think about it a bit more, I don't think w
Hey,
Two small fixes for Xen dom0 running on x86_64 EFI platforms.
I am CC-ing stable maintainers because similar stuff is needed for various
stable kernels too. Unfortunately, almost every version needs a bit different
set of fixes. So, please treat this email more as head up than real set of
pa
Otherwise e.g. Xen dom0 on x86_64 EFI platforms crashes.
In theory we can check EFI_PARAVIRT too, however,
EFI_MEMMAP looks more generic and covers more cases.
Signed-off-by: Daniel Kiper
---
drivers/firmware/efi/efi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dri
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Tuesday, June 20, 2017 12:22 PM
>
> From: Denys Vlasenko
> Date: Mon, 19 Jun 2017 21:50:52 +0200
>
> > Only compile-tested - I don't have the hardware.
> >
> > From code inspection, octeon_pci_write_core_mem() appears to be safe wrt
> > u
Current approach, wholesale efi struct initialization from efi_xen, is not
good. Usually if new member is defined then it is properly initialized in
drivers/firmware/efi/efi.c but not in arch/x86/xen/efi.c. As I saw it happened
a few times until now. So, let's initialize only efi struct members use
In zap_shader_load_mdt(), we pass a pointer to a phys_addr_t
into dmam_alloc_coherent, which the compiler warns about:
drivers/gpu/drm/msm/adreno/a5xx_gpu.c: In function 'zap_shader_load_mdt':
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:54:50: error: passing argument 3 of
'dmam_alloc_coherent' from inc
On Wed, Jun 14, 2017 at 6:12 PM, Thomas Garnier wrote:
> Ensure the address limit is a user-mode segment before returning to
> user-mode. Otherwise a process can corrupt kernel-mode memory and
> elevate privileges [1].
>
> The set_fs function sets the TIF_SETFS flag to force a slow path on
> retur
When compile-testing for something other than ARCH_QCOM,
we run into a link error:
drivers/gpu/drm/msm/adreno/a5xx_gpu.o: In function `a5xx_hw_init':
a5xx_gpu.c:(.text.a5xx_hw_init+0x600): undefined reference to
`qcom_mdt_get_size'
a5xx_gpu.c:(.text.a5xx_hw_init+0x93c): undefined reference to `qc
That's totally bogus. Just say you don't know. It's never a
reguirement that people fix AMD drivers before they can review code...
regards,
dan carpenter
On Wed, Jun 14, 2017 at 6:12 PM, Thomas Garnier wrote:
> Ensure the address limit is a user-mode segment before returning to
> user-mode. Otherwise a process can corrupt kernel-mode memory and elevate
> privileges [1].
>
> The set_fs function sets the TIF_SETFS flag to force a slow path on
> retur
Simplify return logic to avoid unnecessary variable assignment.
Signed-off-by: Gustavo A. R. Silva
---
drivers/usb/musb/musb_host.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index dbe617a..76decb8 100644
On 06/19/2017 04:36 PM, Kees Cook wrote:
> From: David Windsor
>
> Some userspace APIs (e.g. ipc, seq_file) provide precise control over
> the size of kernel kmallocs, which provides a trivial way to perform
> heap overflow attacks where the attacker must control neighboring
> allocations of a sp
On Tue, Jun 20, 2017 at 04:05:07PM +0200, Thomas Gleixner wrote:
> On Mon, 12 Jun 2017, Daniel Lezcano wrote:
> > But, the API request_percpu_irq does not allow to pass a flag, hence
> > specifying
> > if the interrupt type is a timer.
> >
> > Add a function request_percpu_irq_flags() where we ca
On Tue, Jun 20, 2017 at 01:42:27PM -0400, Rik van Riel wrote:
> On Mon, 2017-06-19 at 04:12 +0200, Frederic Weisbecker wrote:
> > Although idle load balancing obviously only concern idle CPUs, it can
> > be a disturbance on a busy nohz_full CPU. Indeed a CPU can only get
> > rid
> > of an idle load
On 20.06.2017 22:37, Tejun Heo wrote:
> Hello, Nikolay.
>
> On Tue, Jun 20, 2017 at 09:02:00PM +0300, Nikolay Borisov wrote:
>> Currently the writeback statistics code uses a percpu counters to hold
>> various statistics. Furthermore we have 2 families of functions - those which
>> disable local
Em Tue, Jun 20, 2017 at 01:43:56PM +, Liang, Kan escreveu:
> Hi Arnaldo and Jirka,
>
> Ping.
>> Any comments for the patch?
I thought there was a kernel part still outstanding, now I see it was
already merged, will try it and provide comments.
- Arnaldo
> Thanks,
> Kan
>
> > Subject: RE:
On 20/06/2017 22:29, Thomas Gleixner wrote:
> On Tue, 20 Jun 2017, Daniel Lezcano wrote:
>> On Tue, Jun 20, 2017 at 04:05:07PM +0200, Thomas Gleixner wrote:
>>> On Mon, 12 Jun 2017, Daniel Lezcano wrote:
But, the API request_percpu_irq does not allow to pass a flag, hence
specifying
Hello,
On Tue, Jun 20, 2017 at 11:28:30PM +0300, Nikolay Borisov wrote:
> > Heh, looks like I was confused. __percpu_counter_add() is not
> > irq-safe. It disables preemption and uses __this_cpu_read(), so
> > there's no protection against irq. If writeback statistics want
> > irq-safe operatio
On Tue, 20 Jun 2017, Daniel Lezcano wrote:
> On Tue, Jun 20, 2017 at 04:05:07PM +0200, Thomas Gleixner wrote:
> > On Mon, 12 Jun 2017, Daniel Lezcano wrote:
> > > But, the API request_percpu_irq does not allow to pass a flag, hence
> > > specifying
> > > if the interrupt type is a timer.
> > >
>
The last rework left behind two unused variables:
drm/arm/hdlcd_crtc.c: In function 'hdlcd_plane_atomic_update':
drm/arm/hdlcd_crtc.c:264:13: warning: unused variable 'src_y'
[-Wunused-variable]
drm/arm/hdlcd_crtc.c:264:6: warning: unused variable 'src_x' [-Wunused-variable]
This removes them.
On Tue, Jun 20, 2017 at 1:18 PM, Kees Cook wrote:
> On Wed, Jun 14, 2017 at 6:12 PM, Thomas Garnier wrote:
>> Ensure the address limit is a user-mode segment before returning to
>> user-mode. Otherwise a process can corrupt kernel-mode memory and
>> elevate privileges [1].
>>
>> The set_fs functi
On 20.06.2017 23:30, Tejun Heo wrote:
> Hello,
>
> On Tue, Jun 20, 2017 at 11:28:30PM +0300, Nikolay Borisov wrote:
>>> Heh, looks like I was confused. __percpu_counter_add() is not
>>> irq-safe. It disables preemption and uses __this_cpu_read(), so
>>> there's no protection against irq. If w
We get a warning when AA_BUG() compiles to an nothing:
security/apparmor/label.c: In function '__label_update':
security/apparmor/label.c:2055:3: error: suggest braces around empty body in an
'else' statement [-Werror=empty-body]
There are two things we can do about this:
- add the missing brac
TIOCGPTPEER is only used for unix98 PTYs, and we get a warning
when those are disabled:
drivers/tty/pty.c:466:12: error: 'pty_get_peer' defined but not used
[-Werror=unused-function]
This moves the respective functions inside of the existing #ifdef.
Fixes: 54ebbfb16034 ("tty: add TIOCGPTPEER io
On Tue, Jun 20, 2017 at 12:25:53PM -0700, Kees Cook wrote:
> Can you send the patch to https://github.com/acpica/acpica ? My change
> was finally accepted, so this whole issue will go away on the next
> refresh. Until then, I don't want to block the entire automatic
> structure selection logic of r
On Fri, Jun 16, 2017 at 01:53:26PM -0500, Tom Lendacky wrote:
> Boot data (such as EFI related data) is not encrypted when the system is
> booted because UEFI/BIOS does not run with SME active. In order to access
> this data properly it needs to be mapped decrypted.
>
> Update early_memremap() to
On Tue, 20 Jun 2017, Thomas Gleixner wrote:
> On Tue, 20 Jun 2017, Keith Busch wrote:
> > On Tue, Jun 20, 2017 at 01:37:15AM +0200, Thomas Gleixner wrote:
> > > static int vmd_enable_domain(struct vmd_dev *vmd)
> > > {
> > > struct pci_sysdata *sd = &vmd->sysdata;
> > > + struct fwnode_handle *
On Tue, Jun 20, 2017 at 11:20 PM, Dan Carpenter
wrote:
> That's totally bogus. Just say you don't know. It's never a
> reguirement that people fix AMD drivers before they can review code...
Agree. It's not a cargo cult.
If there any real thing behind that #ifdef I would like to hear.
--
With
701 - 800 of 1130 matches
Mail list logo