Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings
On Wed, Mar 1, 2017 at 10:34 AM, Arnd Bergmann wrote:
> On Tue, Oct 11, 2016 at 10:38 PM, Arnd Bergmann wrote:
>> On Tuesday, October 11, 2016 10:51:46 AM CEST Josh Poimboeuf wrote:
>>>
>>> 3) 0xFC244C03-config:
>>> drivers/scsi/fnic/fnic_main.o: warning: objtool: fnic_log_q_error() falls
>>> through to next function fnic_handle_link_event()
>>> drivers/scsi/snic/snic_res.o: warning: objtool: .text: unexpected end of
>>> section
>>>
>>> These look like another bad gcc bug which is truncating functions:
>>
>> Same bug for both of them?
>
> I ran into this one again today, after updating to the latest gcc-7.0.1:
>
> drivers/infiniband/sw/rxe/rxe_resp.o: warning: objtool:
> rxe_responder()+0xfe: sibling call from callable instruction with
> changed frame pointer
>
> Josh, did you get around to updating objtool the last time I reported it, or
> is it still the same problem? If this is a new variation, I can provide more
> details about the failure, otherwise I'll just ignore it for now.
Actually, something must have changed in gcc since last month, I also
just got a report in another file:
drivers/i2c/busses/i2c-img-scb.o: warning: objtool: img_i2c_probe()
falls through to next function img_i2c_read_fifo()
See below for the relevant snippet from the assembler output.
Arnd
# /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1176: if
(i2c->bitrate <= timings[i].max_bitrate) {
movl1648(%rbx), %edx# MEM[(struct img_i2c
*)_29].bitrate, _99
cmpltimings+8(%rip), %edx # timings[0].max_bitrate, _99
# /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1171:
i2c->need_wr_rd_fence = true;
movb$1, 1652(%rbx) #, MEM[(struct img_i2c *)_29].need_wr_rd_fence
movltimings+48(%rip), %ecx # timings[1].max_bitrate, pretmp_260
# /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1176: if
(i2c->bitrate <= timings[i].max_bitrate) {
jbe .L59#,
cmpl%ecx, %edx # pretmp_260, _99
jbe .L60#,
.L61:
# /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1182:
dev_warn(i2c->adap.dev.parent,
movq240(%rbx), %rdi # MEM[(struct img_i2c
*)_29].adap.dev.parent, MEM[(struct img_i2c *)_29].adap.dev.parent
movq$.LC12, %rsi#,
calldev_warn#
# /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1187:
i2c->bitrate = timing.max_bitrate;
movltimings+48(%rip), %eax # MEM[(struct img_i2c_timings
*)&timings + 48B], MEM[(struct img_i2c_timings *)&timings + 48B]
movl%eax, 1648(%rbx)# MEM[(struct img_i2c_timings
*)&timings + 48B], MEM[(struct img_i2c *)_29].bitrate
.L60:
ud2
.L66:
# /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1360:
dev_err(&pdev->dev, "can't request irq %d\n", irq);
movl%r13d, %edx # ,
movq$.LC6, %rsi #,
movq%r14, %rdi # _1,
calldev_err #
# /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1361: return ret;
movl-52(%rbp), %eax # %sfp, _62
movl%eax, %r13d # _62,
jmp .L52#
.L65:
# /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1341:
dev_err(&pdev->dev, "can't get irq number\n");
movq$.LC5, %rsi #,
movq%r14, %rdi # _1,
calldev_err #
# /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1342: return irq;
jmp .L52#
.L67:
# /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1162:
dev_info(i2c->adap.dev.parent,
movzbl %ah, %ecx # ret, tmp150
movq240(%rbx), %rdi # MEM[(struct img_i2c
*)_29].adap.dev.parent, MEM[(struct img_i2c *)_29].adap.dev.parent
movl%eax, %edx # ret, tmp153
movl%ecx, %r8d # tmp150, tmp150
movl%eax, %ecx # ret, tmp151
movzbl %al, %r9d # ret,
shrl$16, %ecx #, tmp151
shrl$24, %edx #, tmp153
movq$.LC11, %rsi#,
movzbl %cl, %ecx # tmp151, tmp152
# /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1404: return ret;
movl$-22, %r13d #,
# /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1162:
dev_info(i2c->adap.dev.parent,
call_dev_info #
# /git/arm-soc/include/linux/clk.h:210: might_sleep();
xorl%edx, %edx #
movl$210, %esi #,
movq$.LC0, %rdi #,
call__might_sleep #
xorl%edx, %edx #
movl$210, %esi #,
movq$.LC0, %rdi #,
call__might_sleep #
# /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1404: return ret;
jmp .L52#
.L62:
# /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1332: return -ENOMEM;
movl$-12, %r13d #,
jmp .L52#
.L59:
# /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1181: if
(i2c->bitrate > timings[ARRAY_SIZE(timings) - 1].max_bitrate) {
cmpl%ecx, %edx # pretmp_260, _99
Re: [PATCH] staging/fbtft: Hush checkpatch.pl warning about unnecessary line continuations.
On Tue, Feb 28, 2017 at 09:52:44PM +0200, Alexander Kapshuk wrote:
> Use a single fmt string with appropriate verbs as conversion specifiers,
> followed by the original string literals and the integer argument
> instead of using a backslash to escape a new line embedded inbetween
> quoted string literals passed as fmt arguments to dev_err() invoked in
> drivers/staging/fbtft/fb_ssd1331.c.
>
> Signed-off-by: Alexander Kapshuk
> ---
> drivers/staging/fbtft/fb_ssd1331.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/fbtft/fb_ssd1331.c
> b/drivers/staging/fbtft/fb_ssd1331.c
> index 26f24e3..6d03041 100644
> --- a/drivers/staging/fbtft/fb_ssd1331.c
> +++ b/drivers/staging/fbtft/fb_ssd1331.c
> @@ -129,17 +129,19 @@ static int set_gamma(struct fbtft_par *par, u32 *curves)
>
> for (i = 0; i < 63; i++) {
> if (i > 0 && curves[i] < 2) {
> - dev_err(par->info->device,
> - "Illegal value in Grayscale Lookup Table at
> index %d. " \
> - "Must be greater than 1\n", i);
> + dev_err(par->info->device, "%s %d. %s\n",
> + "Illegal value in Grayscale Lookup Table at
> index",
> + i,
> + "Must be greater than 1");
Huh? This should just be:
"Illegal value in Grayscale Lookup Table at
index %d. Must be greater than 1\n",
i);
Don't split the string for no good reason.
> return -EINVAL;
> }
> acc += curves[i];
> tmp[i] = acc;
> if (acc > 180) {
> - dev_err(par->info->device,
> - "Illegal value(s) in Grayscale Lookup Table. " \
> - "At index=%d, the accumulated value has
> exceeded 180\n", i);
> + dev_err(par->info->device, "%s%d, %s\n",
> + "Illegal value(s) in Grayscale Lookup Table. At
> index=",
> + i,
> + "the accumulated value has exceeded 180");
Same here.
please fix.
thanks,
greg k-h
Re: [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME
Add kexec list.. On 03/01/17 at 05:25pm, Dave Young wrote: > Hi Tom, > > On 02/17/17 at 10:43am, Tom Lendacky wrote: > > On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote: > > > On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote: > > > > Provide support so that kexec can be used to boot a kernel when SME is > > > > enabled. > > > > > > Is the point of kexec and kdump to ehh, dump memory ? But if the > > > rest of the memory is encrypted you won't get much, will you? > > > > Kexec can be used to reboot a system without going back through BIOS. > > So you can use kexec without using kdump. > > > > For kdump, just taking a quick look, the option to enable memory > > encryption can be provided on the crash kernel command line and then > > Is there a simple way to get the SME status? Probably add some sysfs > file for this purpose. > > > crash kernel can would be able to copy the memory decrypted if the > > pagetable is set up properly. It looks like currently ioremap_cache() > > is used to map the old memory page. That might be able to be changed > > to a memremap() so that the encryption bit is set in the mapping. That > > will mean that memory that is not marked encrypted (EFI tables, swiotlb > > memory, etc) would not be read correctly. > > Manage to store info about those ranges which are not encrypted so that > memremap can handle them? > > > > > > > > > Would it make sense to include some printk to the user if they > > > are setting up kdump that they won't get anything out of it? > > > > Probably a good idea to add something like that. > > It will break kdump functionality, it should be fixed instead of > just adding printk to warn user.. > > Thanks > Dave
Re: kvm: WARNING in nested_vmx_vmexit
On Wed, Mar 1, 2017 at 7:13 AM, Wanpeng Li wrote: > 2017-02-28 20:15 GMT+08:00 Dmitry Vyukov : >> Hello, >> >> The following program triggers WARNING in nested_vmx_vmexit: >> https://gist.githubusercontent.com/dvyukov/16b946d7dc703bb07b9b933f12fb8a6e/raw/dac60506feb8dd9dd22828c486e46ee8a5e30f13/gistfile1.txt >> >> >> [ cut here ] >> WARNING: CPU: 1 PID: 27742 at arch/x86/kvm/vmx.c:11029 >> nested_vmx_vmexit+0x5c35/0x74d0 arch/x86/kvm/vmx.c:11029 >> CPU: 1 PID: 27742 Comm: a.out Not tainted 4.10.0+ #229 >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 >> Call Trace: >> __dump_stack lib/dump_stack.c:15 [inline] >> dump_stack+0x2ee/0x3ef lib/dump_stack.c:51 >> panic+0x1fb/0x412 kernel/panic.c:179 >> __warn+0x1c4/0x1e0 kernel/panic.c:540 >> warn_slowpath_null+0x2c/0x40 kernel/panic.c:583 >> nested_vmx_vmexit+0x5c35/0x74d0 arch/x86/kvm/vmx.c:11029 >> vmx_leave_nested arch/x86/kvm/vmx.c:11136 [inline] >> vmx_set_msr+0x1565/0x1910 arch/x86/kvm/vmx.c:3324 >> kvm_set_msr+0xd4/0x170 arch/x86/kvm/x86.c:1099 >> do_set_msr+0x11e/0x190 arch/x86/kvm/x86.c:1128 >> __msr_io arch/x86/kvm/x86.c:2577 [inline] >> msr_io+0x24b/0x450 arch/x86/kvm/x86.c:2614 >> kvm_arch_vcpu_ioctl+0x35b/0x46a0 arch/x86/kvm/x86.c:3497 >> kvm_vcpu_ioctl+0x232/0x1120 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2721 >> vfs_ioctl fs/ioctl.c:43 [inline] >> do_vfs_ioctl+0x1bf/0x1790 fs/ioctl.c:683 >> SYSC_ioctl fs/ioctl.c:698 [inline] >> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:689 >> entry_SYSCALL_64_fastpath+0x1f/0xc2 >> RIP: 0033:0x451229 >> RSP: 002b:7fc1e7ebec98 EFLAGS: 0246 ORIG_RAX: 0010 >> RAX: ffda RBX: RCX: 00451229 >> RDX: 20aecfe8 RSI: 4008ae89 RDI: 0008 >> RBP: R08: R09: >> R10: R11: 0246 R12: >> R13: R14: 7fc1e7ebf9c0 R15: 7fc1e7ebf700 >> >> >> On commit e5d56efc97f8240d0b5d66c03949382b6d7e5570 > > I git checkout to this commit for linus tree, however the line number > 11029 doesn't match any warning, and there are several warnings in the > function nested_vmx_vmexit(), could you point out which one? Ah sorry, I have some local diff. So now I am on 86292b33d4b79ee03e2f43ea0381ef85f077c760 and here is my diff: https://gist.githubusercontent.com/dvyukov/6bb88c6e3584c3fd989df01386efcb74/raw/1ae08a3a682ad9467de5eb7fb96d457db514f9d2/gistfile1.txt The warning is: /* trying to cancel vmlaunch/vmresume is a bug */ WARN_ON_ONCE(vmx->nested.nested_run_pending);
Re: [PATCH 3/3] drivers:gpu: vga :vga_switcheroo.c : Fixed some coding style issues
On Wed, 01 Mar 2017, Daniel Vetter wrote:
> On Tue, Feb 28, 2017 at 06:59:52PM +, Joan Jani wrote:
>> Fixed the following style issues
>>
>> drivers/gpu/vga/vga_switcheroo.c:98: WARNING: please, no space before tabs
>> drivers/gpu/vga/vga_switcheroo.c:99: WARNING: please, no space before tabs
>> drivers/gpu/vga/vga_switcheroo.c:102: WARNING: please, no space before tabs
>> drivers/gpu/vga/vga_switcheroo.c:103: WARNING: please, no space before tabs
>> drivers/gpu/vga/vga_switcheroo.c:129: WARNING: please, no space before tabs
>> drivers/gpu/vga/vga_switcheroo.c:135: WARNING: please, no space before tabs
>> drivers/gpu/vga/vga_switcheroo.c:217: WARNING: line over 80 characters
>> drivers/gpu/vga/vga_switcheroo.c:218: WARNING: line over 80 characters
>> drivers/gpu/vga/vga_switcheroo.c:308: WARNING: please, no space before tabs
>> drivers/gpu/vga/vga_switcheroo.c:340: WARNING: line over 80 characters
>> drivers/gpu/vga/vga_switcheroo.c:1087: WARNING: Block comments use * on
>> subsequent lines
>> drivers/gpu/vga/vga_switcheroo.c:1087: WARNING: Block comments use a
>> trailing */ on a separate line
>>
>> Signed-off-by: Joan Jani
>
> Applied to drm-misc for 4.12, thanks.
Frankly, I wish you hadn't. The patch changed the perfectly fine:
int vga_switcheroo_register_handler(const struct vga_switcheroo_handler
*handler,
enum vga_switcheroo_handler_flags_t
handler_flags)
into horrendous:
int vga_switcheroo_register_handler(
const struct vga_switcheroo_handler *handler,
enum vga_switcheroo_handler_flags_t handler_flags)
Just to appease the 80 column rule. Ditto for
vga_switcheroo_register_audio_client. This is why we don't generally
want pure checkpatch fixes on existing files. They don't make things
better.
BR,
Jani.
> -Daniel
>
>> ---
>> drivers/gpu/vga/vga_switcheroo.c | 28 +++-
>> 1 file changed, 15 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/vga/vga_switcheroo.c
>> b/drivers/gpu/vga/vga_switcheroo.c
>> index 5f962bf..3cd153c 100644
>> --- a/drivers/gpu/vga/vga_switcheroo.c
>> +++ b/drivers/gpu/vga/vga_switcheroo.c
>> @@ -95,12 +95,12 @@
>> * @pwr_state: current power state
>> * @ops: client callbacks
>> * @id: client identifier. Determining the id requires the handler,
>> - * so gpus are initially assigned VGA_SWITCHEROO_UNKNOWN_ID
>> - * and later given their true id in vga_switcheroo_enable()
>> + * so gpus are initially assigned VGA_SWITCHEROO_UNKNOWN_ID
>> + * and later given their true id in vga_switcheroo_enable()
>> * @active: whether the outputs are currently switched to this client
>> * @driver_power_control: whether power state is controlled by the driver's
>> - * runtime pm. If true, writing ON and OFF to the vga_switcheroo debugfs
>> - * interface is a no-op so as not to interfere with runtime pm
>> + * runtime pm. If true, writing ON and OFF to the vga_switcheroo debugfs
>> + * interface is a no-op so as not to interfere with runtime pm
>> * @list: client list
>> *
>> * Registered client. A client can be either a GPU or an audio device on a
>> GPU.
>> @@ -126,13 +126,13 @@ static DEFINE_MUTEX(vgasr_mutex);
>> /**
>> * struct vgasr_priv - vga_switcheroo private data
>> * @active: whether vga_switcheroo is enabled.
>> - * Prerequisite is the registration of two GPUs and a handler
>> + * Prerequisite is the registration of two GPUs and a handler
>> * @delayed_switch_active: whether a delayed switch is pending
>> * @delayed_client_id: client to which a delayed switch is pending
>> * @debugfs_root: directory for vga_switcheroo debugfs interface
>> * @switch_file: file for vga_switcheroo debugfs interface
>> * @registered_clients: number of registered GPUs
>> - * (counting only vga clients, not audio clients)
>> + * (counting only vga clients, not audio clients)
>> * @clients: list of registered clients
>> * @handler: registered handler
>> * @handler_flags: flags of registered handler
>> @@ -214,8 +214,9 @@ static void vga_switcheroo_enable(void)
>> *
>> * Return: 0 on success, -EINVAL if a handler was already registered.
>> */
>> -int vga_switcheroo_register_handler(const struct vga_switcheroo_handler
>> *handler,
>> -enum vga_switcheroo_handler_flags_t
>> handler_flags)
>> +int vga_switcheroo_register_handler(
>> + const struct vga_switcheroo_handler *handler,
>> + enum vga_switcheroo_handler_flags_t handler_flags)
>> {
>> mutex_lock(&vgasr_mutex);
>> if (vgasr_priv.handler) {
>> @@ -305,7 +306,7 @@ static int register_client(struct pci_dev *pdev,
>> * @pdev: client pci device
>> * @ops: client callbacks
>> * @driver_power_control: whether power state is controlled by the driver's
>> - * runtime pm
>> + * runtime pm
>> *
>> * Register vga client (GPU). Enable vga_switcheroo if another GPU and a
>>
[tip:x86/asm] x86/entry/32: Relax a pvops stub clobber specification
Commit-ID: fdbd518adfaf2c10903250dffe70c61ed90b7dd7 Gitweb: http://git.kernel.org/tip/fdbd518adfaf2c10903250dffe70c61ed90b7dd7 Author: Jan Beulich AuthorDate: Fri, 3 Feb 2017 01:58:03 -0700 Committer: Ingo Molnar CommitDate: Wed, 1 Mar 2017 10:16:30 +0100 x86/entry/32: Relax a pvops stub clobber specification The code at .Lrestore_nocheck does not make any assumptions on register values, so all registers can be clobbered on code paths leading there. Signed-off-by: Jan Beulich Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/5894542b027800136...@prv-mh.provo.novell.com Signed-off-by: Ingo Molnar --- arch/x86/entry/entry_32.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S index 57f7ec3..5553475 100644 --- a/arch/x86/entry/entry_32.S +++ b/arch/x86/entry/entry_32.S @@ -585,7 +585,7 @@ ENTRY(iret_exc ) * will soon execute iret and the tracer was already set to * the irqstate after the IRET: */ - DISABLE_INTERRUPTS(CLBR_EAX) + DISABLE_INTERRUPTS(CLBR_ANY) lss (%esp), %esp/* switch to espfix segment */ jmp .Lrestore_nocheck #endif
Re: [PATCH v2] lockdep: Teach lockdep about memalloc_noio_save
On Wed, Mar 01, 2017 at 09:59:00AM +0200, Nikolay Borisov wrote:
> Commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O
> during memory allocation") added the memalloc_noio_(save|restore) functions
> to enable people to modify the MM behavior by disbaling I/O during memory
> allocation. This prevents allocation paths recursing back into the filesystem
> without explicitly changing the flags for every allocation site. Yet, lockdep
> not being aware of that is prone to showing false positives. Fix this
> by teaching it that the presence of PF_MEMALLOC_NOIO flag mean we are not
> going to issue any I/O
I'm not up to date on the specific, but GFP_IO is separate from GFP_FS.
And MEMALLOC_NOIO only clears GFP_IO but leaves GFP_FS set.
Therefore I think your change is wrong, but I might have overlooked a
detail. Added original authors to Cc to clarify.
> Signed-off-by: Nikolay Borisov
> ---
> kernel/locking/lockdep.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
>
> Turned out there was another place where RELCAIM_FS was being set, fix it
> by using the memalloc_noio_flags when setting ->lockdep_reclaim_gfp flags.
>
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 9812e5dd409e..87cf9910e66f 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -2866,7 +2866,8 @@ static void __lockdep_trace_alloc(gfp_t gfp_mask,
> unsigned long flags)
> return;
>
> /* this guy won't enter reclaim */
> - if ((curr->flags & PF_MEMALLOC) && !(gfp_mask & __GFP_NOMEMALLOC))
> + if (((curr->flags & PF_MEMALLOC) && !(gfp_mask & __GFP_NOMEMALLOC)) ||
> + curr->flags & PF_MEMALLOC_NOIO)
> return;
>
> /* We're only interested __GFP_FS allocations for now */
> @@ -3852,7 +3853,7 @@ EXPORT_SYMBOL_GPL(lock_unpin_lock);
>
> void lockdep_set_current_reclaim_state(gfp_t gfp_mask)
> {
> - current->lockdep_reclaim_gfp = gfp_mask;
> + current->lockdep_reclaim_gfp = memalloc_noio_flags(gfp_mask);
> }
>
> void lockdep_clear_current_reclaim_state(void)
> --
> 2.7.4
>
Re: [Xen-devel] [PATCH 1/5] x86/xen: start untangling PV and PVHVM guest support code
Juergen Gross writes: > On 24/02/17 17:14, Vitaly Kuznetsov wrote: >> Introduce CONFIG_XEN_PV config option and split enlighten.c into >> 4 files. Temporary add #ifdef CONFIG_XEN_PV to smp.c and mmu.c to >> not break the build and not make the patch even bigger. >> >> xen_cpu_up_prepare*/xen_cpu_die hooks require separation to support >> future xen_smp_intr_init() split. >> >> Signed-off-by: Vitaly Kuznetsov > > Could you please split pure code movement and functional changes into > different patches? This would make review much easier. > It's a bit hard with this series to make patches smaller and not break the build ... :-( > So 1 patch to split up enlightenment.c and at least one patch for the > rest of the changes (Kconfig, splitting of x86_hyper_xen, ...). This sounds doable, I'll try! -- Vitaly
[tip:x86/urgent] x86/selftests: Add clobbers for int80 on x86_64
Commit-ID: 2a4d0c627f5374f365a873dea4e10ae0bb437680
Gitweb: http://git.kernel.org/tip/2a4d0c627f5374f365a873dea4e10ae0bb437680
Author: Dmitry Safonov
AuthorDate: Mon, 13 Feb 2017 13:13:36 +0300
Committer: Ingo Molnar
CommitDate: Wed, 1 Mar 2017 10:24:56 +0100
x86/selftests: Add clobbers for int80 on x86_64
Kernel erases R8..R11 registers prior returning to userspace
from int80:
https://lkml.org/lkml/2009/10/1/164
GCC can reuse these registers and doesn't expect them to change
during syscall invocation. I met this kind of bug in CRIU once
GCC 6.1 and CLANG stored local variables in those registers
and the kernel zerofied them during syscall:
https://github.com/xemul/criu/commit/990d33f1a1cdd17bca6c2eb059ab3be2564f7fa2
By that reason I suggest to add those registers to clobbers
in selftests. Also, as noted by Andy - removed unneeded clobber
for flags in INT $0x80 inline asm.
Signed-off-by: Dmitry Safonov
Acked-by: Andy Lutomirski
Cc: 0x7f454...@gmail.com
Cc: Borislav Petkov
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Shuah Khan
Cc: Thomas Gleixner
Cc: linux-kselft...@vger.kernel.org
Link: http://lkml.kernel.org/r/20170213101336.20486-1-dsafo...@virtuozzo.com
Signed-off-by: Ingo Molnar
---
tools/testing/selftests/x86/fsgsbase.c| 2 +-
tools/testing/selftests/x86/ldt_gdt.c | 16 +++-
tools/testing/selftests/x86/ptrace_syscall.c | 3 ++-
tools/testing/selftests/x86/single_step_syscall.c | 5 -
4 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/x86/fsgsbase.c
b/tools/testing/selftests/x86/fsgsbase.c
index 5b2b4b3..b4967d8 100644
--- a/tools/testing/selftests/x86/fsgsbase.c
+++ b/tools/testing/selftests/x86/fsgsbase.c
@@ -245,7 +245,7 @@ void do_unexpected_base(void)
long ret;
asm volatile ("int $0x80"
: "=a" (ret) : "a" (243), "b" (low_desc)
- : "flags");
+ : "r8", "r9", "r10", "r11");
memcpy(&desc, low_desc, sizeof(desc));
munmap(low_desc, sizeof(desc));
diff --git a/tools/testing/selftests/x86/ldt_gdt.c
b/tools/testing/selftests/x86/ldt_gdt.c
index 4af4707..f612161 100644
--- a/tools/testing/selftests/x86/ldt_gdt.c
+++ b/tools/testing/selftests/x86/ldt_gdt.c
@@ -45,6 +45,12 @@
#define AR_DB (1 << 22)
#define AR_G (1 << 23)
+#ifdef __x86_64__
+# define INT80_CLOBBERS "r8", "r9", "r10", "r11"
+#else
+# define INT80_CLOBBERS
+#endif
+
static int nerrs;
/* Points to an array of 1024 ints, each holding its own index. */
@@ -588,7 +594,7 @@ static int invoke_set_thread_area(void)
asm volatile ("int $0x80"
: "=a" (ret), "+m" (low_user_desc) :
"a" (243), "b" (low_user_desc)
- : "flags");
+ : INT80_CLOBBERS);
return ret;
}
@@ -657,7 +663,7 @@ static void test_gdt_invalidation(void)
"+a" (eax)
: "m" (low_user_desc_clear),
[arg1] "r" ((unsigned int)(unsigned
long)low_user_desc_clear)
- : "flags");
+ : INT80_CLOBBERS);
if (sel != 0) {
result = "FAIL";
@@ -688,7 +694,7 @@ static void test_gdt_invalidation(void)
"+a" (eax)
: "m" (low_user_desc_clear),
[arg1] "r" ((unsigned int)(unsigned
long)low_user_desc_clear)
- : "flags");
+ : INT80_CLOBBERS);
if (sel != 0) {
result = "FAIL";
@@ -721,7 +727,7 @@ static void test_gdt_invalidation(void)
"+a" (eax)
: "m" (low_user_desc_clear),
[arg1] "r" ((unsigned int)(unsigned
long)low_user_desc_clear)
- : "flags");
+ : INT80_CLOBBERS);
#ifdef __x86_64__
syscall(SYS_arch_prctl, ARCH_GET_FS, &new_base);
@@ -774,7 +780,7 @@ static void test_gdt_invalidation(void)
"+a" (eax)
: "m" (low_user_desc_clear),
[arg1] "r" ((unsigned int)(unsigned
long)low_user_desc_clear)
- : "flags");
+ : INT80_CLOBBERS);
#ifdef __x86_64__
syscall(SYS_arch_prctl, ARCH_GET_GS, &new_base);
diff --git a/tools/testing/selftests/x86/ptrace_syscall.c
b/tools/testing/selftests/x86/ptrace_syscall.c
index b037ce9c..eaea924 100644
--- a/tools/testing/selftests/x86/ptrace_syscall.c
+++ b/tools/testing/selftests/x86/ptrace_syscall.c
@@ -58,7 +58,8 @@ static void do_full_int80(struct syscall_args32 *args)
asm volatile ("int $0x80"
: "+a" (args->nr),
"+b" (args
[tip:perf/urgent] perf/core: Rename CONFIG_[UK]PROBE_EVENT to CONFIG_[UK]PROBE_EVENTS
Commit-ID: 6b0b7551428e4caae1e2c023a529465a9a9ae2d4 Gitweb: http://git.kernel.org/tip/6b0b7551428e4caae1e2c023a529465a9a9ae2d4 Author: Anton Blanchard AuthorDate: Thu, 16 Feb 2017 17:00:50 +1100 Committer: Ingo Molnar CommitDate: Wed, 1 Mar 2017 10:26:39 +0100 perf/core: Rename CONFIG_[UK]PROBE_EVENT to CONFIG_[UK]PROBE_EVENTS We have uses of CONFIG_UPROBE_EVENT and CONFIG_KPROBE_EVENT as well as CONFIG_UPROBE_EVENTS and CONFIG_KPROBE_EVENTS. Consistently use the plurals. Signed-off-by: Anton Blanchard Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: a...@kernel.org Cc: alexander.shish...@linux.intel.com Cc: da...@davemloft.net Cc: sparcli...@vger.kernel.org Link: http://lkml.kernel.org/r/20170216060050.20866-1-an...@ozlabs.org Signed-off-by: Ingo Molnar --- Documentation/trace/kprobetrace.txt | 2 +- Documentation/trace/uprobetracer.txt| 2 +- arch/powerpc/configs/85xx/kmp204x_defconfig | 2 +- arch/s390/configs/default_defconfig | 2 +- arch/s390/configs/gcov_defconfig| 2 +- arch/s390/configs/performance_defconfig | 2 +- arch/s390/defconfig | 2 +- kernel/trace/Kconfig| 6 +++--- kernel/trace/Makefile | 4 ++-- kernel/trace/trace.c| 10 +- kernel/trace/trace_probe.h | 4 ++-- 11 files changed, 19 insertions(+), 19 deletions(-) diff --git a/Documentation/trace/kprobetrace.txt b/Documentation/trace/kprobetrace.txt index e4991fb..41ef9d8 100644 --- a/Documentation/trace/kprobetrace.txt +++ b/Documentation/trace/kprobetrace.txt @@ -12,7 +12,7 @@ kprobes can probe (this means, all functions body except for __kprobes functions). Unlike the Tracepoint based event, this can be added and removed dynamically, on the fly. -To enable this feature, build your kernel with CONFIG_KPROBE_EVENT=y. +To enable this feature, build your kernel with CONFIG_KPROBE_EVENTS=y. Similar to the events tracer, this doesn't need to be activated via current_tracer. Instead of that, add probe points via diff --git a/Documentation/trace/uprobetracer.txt b/Documentation/trace/uprobetracer.txt index fa7b680..bf526a7c 100644 --- a/Documentation/trace/uprobetracer.txt +++ b/Documentation/trace/uprobetracer.txt @@ -7,7 +7,7 @@ Overview Uprobe based trace events are similar to kprobe based trace events. -To enable this feature, build your kernel with CONFIG_UPROBE_EVENT=y. +To enable this feature, build your kernel with CONFIG_UPROBE_EVENTS=y. Similar to the kprobe-event tracer, this doesn't need to be activated via current_tracer. Instead of that, add probe points via diff --git a/arch/powerpc/configs/85xx/kmp204x_defconfig b/arch/powerpc/configs/85xx/kmp204x_defconfig index a60..34a4da2 100644 --- a/arch/powerpc/configs/85xx/kmp204x_defconfig +++ b/arch/powerpc/configs/85xx/kmp204x_defconfig @@ -210,7 +210,7 @@ CONFIG_DEBUG_SHIRQ=y CONFIG_DETECT_HUNG_TASK=y CONFIG_SCHEDSTATS=y CONFIG_RCU_TRACE=y -CONFIG_UPROBE_EVENT=y +CONFIG_UPROBE_EVENTS=y CONFIG_CRYPTO_NULL=y CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_MD4=y diff --git a/arch/s390/configs/default_defconfig b/arch/s390/configs/default_defconfig index 143b1e0..4b176fe 100644 --- a/arch/s390/configs/default_defconfig +++ b/arch/s390/configs/default_defconfig @@ -609,7 +609,7 @@ CONFIG_SCHED_TRACER=y CONFIG_FTRACE_SYSCALLS=y CONFIG_STACK_TRACER=y CONFIG_BLK_DEV_IO_TRACE=y -CONFIG_UPROBE_EVENT=y +CONFIG_UPROBE_EVENTS=y CONFIG_FUNCTION_PROFILER=y CONFIG_HIST_TRIGGERS=y CONFIG_TRACE_ENUM_MAP_FILE=y diff --git a/arch/s390/configs/gcov_defconfig b/arch/s390/configs/gcov_defconfig index f05d2d6..0de46cc 100644 --- a/arch/s390/configs/gcov_defconfig +++ b/arch/s390/configs/gcov_defconfig @@ -560,7 +560,7 @@ CONFIG_SCHED_TRACER=y CONFIG_FTRACE_SYSCALLS=y CONFIG_STACK_TRACER=y CONFIG_BLK_DEV_IO_TRACE=y -CONFIG_UPROBE_EVENT=y +CONFIG_UPROBE_EVENTS=y CONFIG_FUNCTION_PROFILER=y CONFIG_HIST_TRIGGERS=y CONFIG_TRACE_ENUM_MAP_FILE=y diff --git a/arch/s390/configs/performance_defconfig b/arch/s390/configs/performance_defconfig index 2358bf3..e167557 100644 --- a/arch/s390/configs/performance_defconfig +++ b/arch/s390/configs/performance_defconfig @@ -558,7 +558,7 @@ CONFIG_SCHED_TRACER=y CONFIG_FTRACE_SYSCALLS=y CONFIG_STACK_TRACER=y CONFIG_BLK_DEV_IO_TRACE=y -CONFIG_UPROBE_EVENT=y +CONFIG_UPROBE_EVENTS=y CONFIG_FUNCTION_PROFILER=y CONFIG_HIST_TRIGGERS=y CONFIG_TRACE_ENUM_MAP_FILE=y diff --git a/arch/s390/defconfig b/arch/s390/defconfig index 68bfd09..97189db 100644 --- a/arch/s390/defconfig +++ b/arch/s390/defconfig @@ -179,7 +179,7 @@ CONFIG_FTRACE_SYSCALLS=y CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP=y CONFIG_STACK_TRACER=y CONFIG_BLK_DEV_IO_TRACE=y -CONFIG_UPROBE_EVENT=y +CONFIG_UPROBE_EVENTS=y CONFIG_FUNCTION_PROFILER=y CONFIG_TRACE_ENUM_
Re: [PATCH] sched/rt: Document why has_pushable_tasks() isn't called with a runqueue lock
On Tue, Feb 28, 2017 at 04:48:56PM -0500, Steven Rostedt wrote:
> + /*
> + * Normally, has_pushable_tasks() would be performed within the
> + * runqueue lock being held. But if it was not set when entering
"not set" what? I'm having trouble parsing this.
> + * this hard interrupt handler function, then to have it set would
> + * require a wake up. A wake up of an RT task will either cause a
> + * schedule if the woken task is higher priority than the running
> + * task, or it would try to do a push from the CPU doing the wake
> + * up. Grabbing the runqueue lock in such a case would more likely
> + * just cause unnecessary contention.
> + */
> if (has_pushable_tasks(rq)) {
> raw_spin_lock(&rq->lock);
> push_rt_task(rq);
[tip:x86/asm] x86/asm: Optimize clear_page()
Commit-ID: 49ca7bb328c630dd43be626534b49e19513296fd Gitweb: http://git.kernel.org/tip/49ca7bb328c630dd43be626534b49e19513296fd Author: Borislav Petkov AuthorDate: Thu, 9 Feb 2017 01:34:49 +0100 Committer: Ingo Molnar CommitDate: Wed, 1 Mar 2017 10:18:32 +0100 x86/asm: Optimize clear_page() Currently, we CALL clear_page() which then JMPs to the proper function chosen by the alternatives. What we should do instead is CALL the proper function directly. (This was something Ingo suggested a while ago). So let's do that. Measuring our favourite kernel build workload shows that there are no significant changes in performance. AMD === -- /tmp/before 2017-02-09 18:01:46.451961188 +0100 ++ /tmp/after 2017-02-09 18:01:54.883961175 +0100 @@ -1,15 +1,15 @@ Performance counter stats for 'system wide' (5 runs): -1028960.373643 cpu-clock (msec) #6.000 CPUs utilized ( +- 1.41% ) +1023086.018961 cpu-clock (msec) #6.000 CPUs utilized ( +- 1.20% ) - 518,744 context-switches #0.504 K/sec ( +- 1.04% ) + 518,254 context-switches #0.507 K/sec ( +- 1.01% ) -38,112 cpu-migrations#0.037 K/sec ( +- 1.95% ) +37,917 cpu-migrations#0.037 K/sec ( +- 1.02% ) -20,874,266 page-faults #0.020 M/sec ( +- 0.07% ) +20,918,897 page-faults #0.020 M/sec ( +- 0.18% ) - 2,043,646,230,667 cycles#1.986 GHz ( +- 0.14% ) (66.67%) + 2,045,305,584,032 cycles#1.999 GHz ( +- 0.16% ) (66.67%) - 553,698,855,431 stalled-cycles-frontend # 27.09% frontend cycles idle ( +- 0.07% ) (66.67%) + 555,099,401,413 stalled-cycles-frontend # 27.14% frontend cycles idle ( +- 0.13% ) (66.67%) - 621,544,286,390 stalled-cycles-backend# 30.41% backend cycles idle ( +- 0.39% ) (66.67%) + 621,371,430,254 stalled-cycles-backend# 30.38% backend cycles idle ( +- 0.32% ) (66.67%) - 1,738,364,431,659 instructions #0.85 insn per cycle + 1,739,895,771,901 instructions #0.85 insn per cycle - #0.36 stalled cycles per insn ( +- 0.11% ) (66.67%) + #0.36 stalled cycles per insn ( +- 0.13% ) (66.67%) - 391,170,943,850 branches # 380.161 M/sec ( +- 0.13% ) (66.67%) + 391,398,551,757 branches # 382.567 M/sec ( +- 0.13% ) (66.67%) -22,567,810,411 branch-misses #5.77% of all branches ( +- 0.11% ) (66.67%) +22,574,726,683 branch-misses #5.77% of all branches ( +- 0.13% ) (66.67%) - 171.480741921 seconds time elapsed ( +- 1.41% ) + 170.509229451 seconds time elapsed ( +- 1.20% ) Intel = -- /tmp/before 2017-02-09 20:36:19.851947473 +0100 ++ /tmp/after 2017-02-09 20:36:30.151947458 +0100 @@ -1,15 +1,15 @@ Performance counter stats for 'system wide' (5 runs): -2207248.598126 cpu-clock (msec) #8.000 CPUs utilized ( +- 0.69% ) +2213300.106631 cpu-clock (msec) #8.000 CPUs utilized ( +- 0.73% ) - 899,342 context-switches #0.407 K/sec ( +- 0.68% ) + 898,381 context-switches #0.406 K/sec ( +- 0.79% ) -80,553 cpu-migrations#0.036 K/sec ( +- 1.13% ) +80,979 cpu-migrations#0.037 K/sec ( +- 1.11% ) -36,171,148 page-faults #0.016 M/sec ( +- 0.02% ) +36,179,791 page-faults #0.016 M/sec ( +- 0.02% ) - 6,665,288,826,484 cycles#3.020 GHz ( +- 0.07% ) (83.33%) + 6,671,638,410,799 cycles#3.014 GHz ( +- 0.06% ) (83.33%) - 5,065,975,115,197 stalled-cycles-frontend # 76.01% frontend cycles idle ( +- 0.11% ) (83.33%) + 5,076,835,183,223 stalled-cycles-frontend # 76.10% frontend cycles idle ( +- 0.11% ) (83.33%) - 3,841,556,350,614 stalled-cycles-backend# 57.64% backend cycles idle ( +- 0.13% ) (66.67%) +
Re: [PATCH 0/2] key payload access with just rcu_read_lock()
Jan Stancek wrote: > That problem didn't show up with my NFS based reproducer. > I re-run it again with latest version of your patch, plus also > keyutils testsuite. Both completed OK for me, dmesg looks clean. Can I put you down as a Tested-by? David
[tip:x86/urgent] x86/apic: Simplify enable_IR_x2apic(), remove try_to_enable_IR()
Commit-ID: 11277aabcbbe13916151af897d29a5e9f71ca73f
Gitweb: http://git.kernel.org/tip/11277aabcbbe13916151af897d29a5e9f71ca73f
Author: Dou Liyang
AuthorDate: Thu, 23 Feb 2017 17:16:41 +0800
Committer: Ingo Molnar
CommitDate: Wed, 1 Mar 2017 10:09:09 +0100
x86/apic: Simplify enable_IR_x2apic(), remove try_to_enable_IR()
The following commit:
2e63ad4bd5dd ("x86/apic: Do not init irq remapping if ioapic is disabled")
... added a check for skipped IO-APIC setup to enable_IR_x2apic(), but this
check is also duplicated in try_to_enable_IR() - and it will never succeed in
calling irq_remapping_enable().
Remove the whole irq_remapping_enable() complication: if the IO-APIC is
disabled we cannot enable IRQ remapping.
Signed-off-by: Dou Liyang
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: b...@alien8.de
Cc: nicsta...@gmail.com
Cc: wanpeng...@hotmail.com
Link:
http://lkml.kernel.org/r/1487841401-1543-1-git-send-email-douly.f...@cn.fujitsu.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/apic/apic.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 11088b8..aee7ded 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1610,24 +1610,15 @@ static inline void try_to_enable_x2apic(int remap_mode)
{ }
static inline void __x2apic_enable(void) { }
#endif /* !CONFIG_X86_X2APIC */
-static int __init try_to_enable_IR(void)
-{
-#ifdef CONFIG_X86_IO_APIC
- if (!x2apic_enabled() && skip_ioapic_setup) {
- pr_info("Not enabling interrupt remapping due to skipped
IO-APIC setup\n");
- return -1;
- }
-#endif
- return irq_remapping_enable();
-}
-
void __init enable_IR_x2apic(void)
{
unsigned long flags;
int ret, ir_stat;
- if (skip_ioapic_setup)
+ if (skip_ioapic_setup) {
+ pr_info("Not enabling interrupt remapping due to skipped
IO-APIC setup\n");
return;
+ }
ir_stat = irq_remapping_prepare();
if (ir_stat < 0 && !x2apic_supported())
@@ -1645,7 +1636,7 @@ void __init enable_IR_x2apic(void)
/* If irq_remapping_prepare() succeeded, try to enable it */
if (ir_stat >= 0)
- ir_stat = try_to_enable_IR();
+ ir_stat = irq_remapping_enable();
/* ir_stat contains the remap mode or an error code */
try_to_enable_x2apic(ir_stat);
Re: [PATCH v2] sched/rt: Add comments describing the RT IPI pull method
On Tue, Feb 28, 2017 at 03:50:30PM -0500, Steven Rostedt wrote: > + * The overloaded RT CPU, wher receiving an IPI, will try to push off its "wher" isn't in my dictionary, I'm thinking you mean: "when". Fixed that for you. > + * overloaded RT tasks and then send an IPI to the next CPU that has > + * overloaded RT tasks. This stops when all CPUs with overloaded RT tasks > + * have completed. Just because a CPU may have pushed off its own overloaded > + * RT task does not mean it should stop sending the IPI around to other > + * overloaded CPUs. There may be another RT task waiting to run on one of > + * those CPUs that are of higher priority than the one that was just > + * pushed. > + * > + * An optimization that could possibly be made is to make a CPU array similar > + * to the cpupri array mask of all running RT tasks, but for the overloaded > + * case, then the IPI could be sent to only the CPU with the highest priority > + * RT task waiting, and that CPU could send off further IPIs to the CPU with > + * the next highest waiting task. Since the overloaded case is much less > likely > + * to happen, the complexity of this implementation may not be worth it. > + * Instead, just send an IPI around to all overloaded CPUs. Yeah, not sure, I'll leave it in though.
Re: [PATCH 2/8] mfd: db8500-prcmu: fix stub helper interface
On Wed, Mar 1, 2017 at 12:24 AM, Guenter Roeck wrote: > On Tue, Feb 28, 2017 at 10:47:02PM +0100, Arnd Bergmann wrote: >> On Tue, Feb 28, 2017 at 10:42 PM, Guenter Roeck wrote: >> > On Tue, Feb 28, 2017 at 10:01:17PM +0100, Arnd Bergmann wrote: >> >> When the db8500 watchdog is enabled without the PRCMU, we get a lot of >> >> warnings about duplicate or missing helper functions: >> >> >> >> In file included from drivers/watchdog/ux500_wdt.c:21:0: >> >> include/linux/mfd/dbx500-prcmu.h:422:19: error: redefinition of >> >> 'prcmu_abb_read' >> >> static inline int prcmu_abb_read(u8 slave, u8 reg, u8 *value, u8 size) >> >> >> >> This removes the duplicate function definitions and moves the helpers in >> >> dbx500-prcmu outside of the #ifdef that hides them. >> >> >> > >> > Is that appropriate ? Maybe we should just disable COMPILE_TEST >> > for this driver instead. >> >> Or we could do both. The MFD driver was written to support this in principle, >> it just hasn't worked in a long time. >> > > Can you send me patches to disable COMPILE_TEST for this driver and for retu ? Done.
Re: [PATCH 5/9] dmaengine: sun6i: support V3s SoC variant
On Wed, Mar 01, 2017 at 01:58:33AM +0800, Icenowy Zheng wrote:
>
>
> 01.03.2017, 01:56, "Maxime Ripard" :
> > On Mon, Feb 27, 2017 at 06:48:01PM +0800, Icenowy Zheng wrote:
> >> 27.02.2017, 15:50, "Maxime Ripard" :
> >> > On Sat, Feb 25, 2017 at 08:30:25PM +0800, Icenowy Zheng wrote:
> >> >> Allwinner V3s has a DMA engine similar to the ones from A31, but with
> >> >> fewer channels and DRQs.
> >> >>
> >> >> Add support for it.
> >> >>
> >> >> As it also needs the special gate bit, make the gate bit generic.
> >> >
> >> > That should be part of a separate patch.
> >>
> >> OK.
> >>
> >> >
> >> >> According to BSP source code, SUN8IW6 (A83T) also needs the bit, so it
> >> >> have also been specified gate_needed property.
> >> >>
> >> >> Signed-off-by: Icenowy Zheng
> >> >> ---
> >> >> Documentation/devicetree/bindings/dma/sun6i-dma.txt | 1 +
> >> >> drivers/dma/sun6i-dma.c | 17 ++---
> >> >> 2 files changed, 15 insertions(+), 3 deletions(-)
> >> >>
> >> >> diff --git a/Documentation/devicetree/bindings/dma/sun6i-dma.txt
> >> b/Documentation/devicetree/bindings/dma/sun6i-dma.txt
> >> >> index 6b267045f522..98fbe1a5c6dd 100644
> >> >> --- a/Documentation/devicetree/bindings/dma/sun6i-dma.txt
> >> >> +++ b/Documentation/devicetree/bindings/dma/sun6i-dma.txt
> >> >> @@ -9,6 +9,7 @@ Required properties:
> >> >> "allwinner,sun8i-a23-dma"
> >> >> "allwinner,sun8i-a83t-dma"
> >> >> "allwinner,sun8i-h3-dma"
> >> >> + "allwinner,sun8i-v3s-dma"
> >> >> - reg: Should contain the registers base address and length
> >> >> - interrupts: Should contain a reference to the interrupt used by
> >> this device
> >> >> - clocks: Should contain a reference to the parent AHB clock
> >> >> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> >> >> index a2358780ab2c..1f38424c1b14 100644
> >> >> --- a/drivers/dma/sun6i-dma.c
> >> >> +++ b/drivers/dma/sun6i-dma.c
> >> >> @@ -101,6 +101,7 @@ struct sun6i_dma_config {
> >> >> u32 nr_max_channels;
> >> >> u32 nr_max_requests;
> >> >> u32 nr_max_vchans;
> >> >> + bool gate_needed;
> >> >> };
> >> >>
> >> >> /*
> >> >> @@ -1009,12 +1010,14 @@ static struct sun6i_dma_config
> >> sun8i_a23_dma_cfg = {
> >> >> .nr_max_channels = 8,
> >> >> .nr_max_requests = 24,
> >> >> .nr_max_vchans = 37,
> >> >> + .gate_needed = true,
> >> >> };
> >> >>
> >> >> static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
> >> >> .nr_max_channels = 8,
> >> >> .nr_max_requests = 28,
> >> >> .nr_max_vchans = 39,
> >> >> + .gate_needed = true,
> >> >> };
> >> >>
> >> >> /*
> >> >> @@ -1028,11 +1031,19 @@ static struct sun6i_dma_config
> >> sun8i_h3_dma_cfg = {
> >> >> .nr_max_vchans = 34,
> >> >> };
> >> >>
> >> >> +static struct sun6i_dma_config sun8i_v3s_dma_cfg = {
> >> >> + .nr_max_channels = 8,
> >> >> + .nr_max_requests = 23,
> >> >> + .nr_max_vchans = 24,
> >> >
> >> > This one is suspicious. There's just a single endpoint that can be
> >> > used in both directions?
> >>
> >> nr_max_vchans is the endpoint number. nr_max_requests is the
> >> maximum DRQ number, for V3s, according to the datasheet, it's
> >> 23: SPI0_{R,T}X.
> >
> > There's not a lot of endpoints indeed, but you need 28 vchans (2 *
> > 14).
>
> Sorry but I counted only 12 pairs of vchans:
> Port 0. SRAM
> Port 1. SDRAM
> Port 6. UART0
> Port 7. UART1
> Port 8. UART2
> Port 15. Audio Codec
> Port 16. CE
> Port 17. OTG EP1
> Port 18. OTG EP2
> Port 19. OTG EP3
> Port 20. OTG EP4
> Port 23. SPI0
It seems like I can't count anymore... Yes, you're right, sorry.
Having a comment on top of the structure, just like all the other SoCs
would be nice though.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME
Hi Tom, On 02/17/17 at 10:43am, Tom Lendacky wrote: > On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote: > > On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote: > > > Provide support so that kexec can be used to boot a kernel when SME is > > > enabled. > > > > Is the point of kexec and kdump to ehh, dump memory ? But if the > > rest of the memory is encrypted you won't get much, will you? > > Kexec can be used to reboot a system without going back through BIOS. > So you can use kexec without using kdump. > > For kdump, just taking a quick look, the option to enable memory > encryption can be provided on the crash kernel command line and then Is there a simple way to get the SME status? Probably add some sysfs file for this purpose. > crash kernel can would be able to copy the memory decrypted if the > pagetable is set up properly. It looks like currently ioremap_cache() > is used to map the old memory page. That might be able to be changed > to a memremap() so that the encryption bit is set in the mapping. That > will mean that memory that is not marked encrypted (EFI tables, swiotlb > memory, etc) would not be read correctly. Manage to store info about those ranges which are not encrypted so that memremap can handle them? > > > > > Would it make sense to include some printk to the user if they > > are setting up kdump that they won't get anything out of it? > > Probably a good idea to add something like that. It will break kdump functionality, it should be fixed instead of just adding printk to warn user.. Thanks Dave
Re: [PATCH v6 2/4] mm: Add functions to support extra actions on swap in/out
On 02/28/2017 07:35 PM, Khalid Aziz wrote:
> If a processor supports special metadata for a page, for example ADI
> version tags on SPARC M7, this metadata must be saved when the page is
> swapped out. The same metadata must be restored when the page is swapped
> back in. This patch adds two new architecture specific functions -
> arch_do_swap_page() to be called when a page is swapped in,
> arch_unmap_one() to be called when a page is being unmapped for swap
> out.
>
> Signed-off-by: Khalid Aziz
> Cc: Khalid Aziz
This looks much better than your original version.
Acked-by: Jerome Marchand
Thanks,
Jerome
> ---
> v5:
> - Replaced set_swp_pte() function with new architecture
> functions arch_do_swap_page() and arch_unmap_one()
>
> include/asm-generic/pgtable.h | 16
> mm/memory.c | 1 +
> mm/rmap.c | 2 ++
> 3 files changed, 19 insertions(+)
>
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index 18af2bc..5764d8f 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -282,6 +282,22 @@ static inline int pmd_same(pmd_t pmd_a, pmd_t pmd_b)
> #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
> #endif
>
> +#ifndef __HAVE_ARCH_DO_SWAP_PAGE
> +static inline void arch_do_swap_page(struct mm_struct *mm, unsigned long
> addr,
> + pte_t pte, pte_t orig_pte)
> +{
> +
> +}
> +#endif
> +
> +#ifndef __HAVE_ARCH_UNMAP_ONE
> +static inline void arch_unmap_one(struct mm_struct *mm, unsigned long addr,
> + pte_t pte, pte_t orig_pte)
> +{
> +
> +}
> +#endif
> +
> #ifndef __HAVE_ARCH_PGD_OFFSET_GATE
> #define pgd_offset_gate(mm, addr)pgd_offset(mm, addr)
> #endif
> diff --git a/mm/memory.c b/mm/memory.c
> index 6bf2b47..b086c76 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -2658,6 +2658,7 @@ int do_swap_page(struct vm_fault *vmf)
> if (pte_swp_soft_dirty(vmf->orig_pte))
> pte = pte_mksoft_dirty(pte);
> set_pte_at(vma->vm_mm, vmf->address, vmf->pte, pte);
> + arch_do_swap_page(vma->vm_mm, vmf->address, pte, vmf->orig_pte);
> vmf->orig_pte = pte;
> if (page == swapcache) {
> do_page_add_anon_rmap(page, vma, vmf->address, exclusive);
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 91619fd..192c41a 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1538,6 +1538,7 @@ static int try_to_unmap_one(struct page *page, struct
> vm_area_struct *vma,
> swp_pte = swp_entry_to_pte(entry);
> if (pte_soft_dirty(pteval))
> swp_pte = pte_swp_mksoft_dirty(swp_pte);
> + arch_unmap_one(mm, address, swp_pte, pteval);
> set_pte_at(mm, address, pte, swp_pte);
> } else if (PageAnon(page)) {
> swp_entry_t entry = { .val = page_private(page) };
> @@ -1571,6 +1572,7 @@ static int try_to_unmap_one(struct page *page, struct
> vm_area_struct *vma,
> swp_pte = swp_entry_to_pte(entry);
> if (pte_soft_dirty(pteval))
> swp_pte = pte_swp_mksoft_dirty(swp_pte);
> + arch_unmap_one(mm, address, swp_pte, pteval);
> set_pte_at(mm, address, pte, swp_pte);
> } else
> dec_mm_counter(mm, mm_counter_file(page));
>
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v3 20/25] ARM: owl: Implement CPU enable-method for S500
Hi Andreas, [auto build test ERROR on next-20170228] [also build test ERROR on v4.10] [cannot apply to robh/for-next linus/master linux/master v4.9-rc8 v4.9-rc7 v4.9-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Andreas-F-rber/ARM-Initial-Actions-Semi-S500-and-S900-enablement/20170301-110028 config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): arch/arm/mach-actions/headsmp.S: Assembler messages: >> arch/arm/mach-actions/headsmp.S:43: Error: selected processor does not >> support `dsb' in ARM mode >> arch/arm/mach-actions/headsmp.S:44: Error: selected processor does not >> support `isb' in ARM mode vim +43 arch/arm/mach-actions/headsmp.S 37 mov r6, r2, lsl r0 38 orr r5, r5, r6 @ Reg = (Temp< 43 dsb > 44 isb 45 mov pc, lr 46 ENDPROC(owl_v7_invalidate_l1) 47 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings
On Tue, Oct 11, 2016 at 10:38 PM, Arnd Bergmann wrote: > On Tuesday, October 11, 2016 10:51:46 AM CEST Josh Poimboeuf wrote: >> >> 3) 0xFC244C03-config: >> drivers/scsi/fnic/fnic_main.o: warning: objtool: fnic_log_q_error() falls >> through to next function fnic_handle_link_event() >> drivers/scsi/snic/snic_res.o: warning: objtool: .text: unexpected end of >> section >> >> These look like another bad gcc bug which is truncating functions: > > Same bug for both of them? I ran into this one again today, after updating to the latest gcc-7.0.1: drivers/infiniband/sw/rxe/rxe_resp.o: warning: objtool: rxe_responder()+0xfe: sibling call from callable instruction with changed frame pointer Josh, did you get around to updating objtool the last time I reported it, or is it still the same problem? If this is a new variation, I can provide more details about the failure, otherwise I'll just ignore it for now. Arnd
[PATCH] Net: openvswitch: actions: fixed a brace coding style warning
Fixed a brace coding style warning reported by checkpatch.pl
Signed-off-by: Peter Downs
---
net/openvswitch/actions.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index b1beb2b..c82301c 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -796,9 +796,8 @@ static void ovs_fragment(struct net *net, struct vport
*vport,
unsigned long orig_dst;
struct rt6_info ovs_rt;
- if (!v6ops) {
+ if (!v6ops)
goto err;
- }
prepare_frag(vport, skb, orig_network_offset,
ovs_key_mac_proto(key));
--
2.1.4
[PATCH 35/44] tools/power turbostat: use wide columns to display large numbers
From: Len Brown
When a counter overlfows 7 columns, it shifts the remaining
columns to the right, so they no longer line up under
their column header.
Update turbostat to dectect when it is handling large
numbers, and switch to wider columns where, necessary.
Reported-by: Artem Bityutskiy
Signed-off-by: Len Brown
---
tools/power/x86/turbostat/turbostat.c | 68 ---
1 file changed, 55 insertions(+), 13 deletions(-)
diff --git a/tools/power/x86/turbostat/turbostat.c
b/tools/power/x86/turbostat/turbostat.c
index 7b02fbb65893..cafc6bba6539 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -50,6 +50,7 @@ int *fd_percpu;
struct timespec interval_ts = {5, 0};
unsigned int debug;
unsigned int quiet;
+unsigned int sums_need_wide_columns;
unsigned int rapl_joules;
unsigned int summary_only;
unsigned int list_header_only;
@@ -154,7 +155,7 @@ struct thread_data {
unsigned long long aperf;
unsigned long long mperf;
unsigned long long c1;
- unsigned int irq_count;
+ unsigned long long irq_count;
unsigned int smi_count;
unsigned int cpu_id;
unsigned int flags;
@@ -489,8 +490,13 @@ void print_header(char *delim)
if (DO_BIC(BIC_TSC_MHz))
outp += sprintf(outp, "%sTSC_MHz", delim);
- if (DO_BIC(BIC_IRQ))
- outp += sprintf(outp, "%sIRQ", delim);
+ if (DO_BIC(BIC_IRQ)) {
+ if (sums_need_wide_columns)
+ outp += sprintf(outp, "%s IRQ", delim);
+ else
+ outp += sprintf(outp, "%sIRQ", delim);
+ }
+
if (DO_BIC(BIC_SMI))
outp += sprintf(outp, "%sSMI", delim);
@@ -501,7 +507,10 @@ void print_header(char *delim)
else
outp += sprintf(outp, "%s%10.10s", delim,
mp->name);
} else {
- outp += sprintf(outp, "%s%s", delim, mp->name);
+ if ((mp->type == COUNTER_ITEMS) &&
sums_need_wide_columns)
+ outp += sprintf(outp, "%s%8s", delim, mp->name);
+ else
+ outp += sprintf(outp, "%s%s", delim, mp->name);
}
}
@@ -527,7 +536,10 @@ void print_header(char *delim)
else
outp += sprintf(outp, "%s%10.10s", delim,
mp->name);
} else {
- outp += sprintf(outp, "%s%s", delim, mp->name);
+ if ((mp->type == COUNTER_ITEMS) &&
sums_need_wide_columns)
+ outp += sprintf(outp, "%s%8s", delim, mp->name);
+ else
+ outp += sprintf(outp, "%s%s", delim, mp->name);
}
}
@@ -596,7 +608,10 @@ void print_header(char *delim)
else
outp += sprintf(outp, "%s%10.10s", delim,
mp->name);
} else {
- outp += sprintf(outp, "%s%s", delim, mp->name);
+ if ((mp->type == COUNTER_ITEMS) &&
sums_need_wide_columns)
+ outp += sprintf(outp, "%s%8s", delim, mp->name);
+ else
+ outp += sprintf(outp, "%s%s", delim, mp->name);
}
}
@@ -620,7 +635,7 @@ int dump_counters(struct thread_data *t, struct core_data
*c,
outp += sprintf(outp, "c1: %016llX\n", t->c1);
if (DO_BIC(BIC_IRQ))
- outp += sprintf(outp, "IRQ: %d\n", t->irq_count);
+ outp += sprintf(outp, "IRQ: %lld\n", t->irq_count);
if (DO_BIC(BIC_SMI))
outp += sprintf(outp, "SMI: %d\n", t->smi_count);
@@ -755,8 +770,12 @@ int format_counters(struct thread_data *t, struct
core_data *c,
outp += sprintf(outp, "\t%.0f", 1.0 *
t->tsc/units/interval_float);
/* IRQ */
- if (DO_BIC(BIC_IRQ))
- outp += sprintf(outp, "\t%d", t->irq_count);
+ if (DO_BIC(BIC_IRQ)) {
+ if (sums_need_wide_columns)
+ outp += sprintf(outp, "\t%8lld", t->irq_count);
+ else
+ outp += sprintf(outp, "\t%lld", t->irq_count);
+ }
/* SMI */
if (DO_BIC(BIC_SMI))
@@ -770,7 +789,10 @@ int format_counters(struct thread_data *t, struct
core_data *c,
else
outp += sprintf(outp, "\t0x%016llx",
t->counter[i]);
} else if (mp->format == FORMAT_DELTA) {
- outp += sprintf(outp, "\t%lld", t->counter[i]);
+ if ((mp->type == COUNTER_ITEMS) &&
sums_need_wide_columns)
+ outp += sprintf(outp, "\t%8lld", t->counter[i]);
+
Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt
On 03/01/2017 09:30 AM, Gilad Ben-Yossef wrote: > On Tue, Feb 28, 2017 at 11:05 PM, Milan Broz wrote: >> >> On 02/22/2017 07:12 AM, Binoy Jayan wrote: >>> >>> I was wondering if this is near to be ready for submission (apart from >>> the testmgr.c >>> changes) or I need to make some changes to make it similar to the IPSec >>> offload? >> >> I just tried this and except it registers the IV for every new device again, >> it works... >> (After a while you have many duplicate entries in /proc/crypto.) >> >> But I would like to see some summary why such a big patch is needed in the >> first place. >> (During an internal discussions seems that people are already lost in mails >> and >> patches here, so Ondra promised me to send some summary mail soon here.) >> >> IIRC the first initial problem was dmcrypt performance on some embedded >> crypto processors that are not able to cope with small crypto requests >> effectively. >> >> >> Do you have some real performance numbers that proves that such a patch is >> adequate? >> >> I would really like to see the performance issue fixed but I am really not >> sure >> this approach works for everyone. It would be better to avoid repeating this >> exercise later. >> IIRC Ondra's "bulk" mode, despite rejected, shows that there is a potential >> to speedup things even for crypt drivers that do not support own IV >> generators. >> > > AFAIK the problem that we are trying to solve is that if the IV is > generated outside the crypto API > domain than you are forced to have an invocation of the crypto API per > each block because you > need to provide the IV for each block. > > By putting the IV generation responsibility in the Crypto API we open > the way to do a single invocation > of the crypto API for a whole sequence of blocks. Sure, but this is theory. Does it really work on some hw already? Do you have performance measurements or comparison? > For software implementation of XTS this doesn't matter much - but for > hardware based XTS providers It is not only embedded crypto, we have some more reports in the past that 512B sectors are not ideal even for other systems. (IIRC it was also with AES-NI that represents really big group of users). > This lead some vendors to ship hacked up versions of dm-crypt to match > the specific crypto hardware > they were using, or so I've heard at least - didn't see the code myself. I saw few version of that. There was a very hacky way to provide request-based dmcrypt (see old "Introduce the request handling for dm-crypt" thread on dm-devel). This is not the acceptable way but definitely it points to the same problem. > I believe Binoy is trying to address this in a generic upstream worthy > way instead. IIRC the problem is performance, if we can solve it by some generic way, good, but for now it seems to be a big change and just hope it helps later... > Anyway, you are only supposed to see s difference when using a > hardware based XTS provider algo > that supports IV generation. > >> I like the patch is now contained inside dmcrypt, but it still exposes IVs >> that >> are designed just for old, insecure, compatibility-only containers. >> >> I really do not think every compatible crap must be accessible through >> crypto API. >> (I wrote the dmcrypt lrw and tcw compatibility IVs and I would never do that >> this way >> if I know it is accessible outside of dmcrypt internals...) >> Even the ESSIV is something that was born to fix predictive IVs (CBC >> watermarking >> attacks) for disk encryption only, no reason to expose it outside of disk >> encryption. >> > > The point is that you have more than one implementation of these > "compatible crap" - the > software implementation that you wrote and potentially multiple > hardware implementations > and putting this in the crypto API domain is the way to abstract this > so you use the one > that works best of your platform. For XTS you need just simple linear IV. No problem with that, implementation in crypto API and hw is trivial. But for compatible IV (that provides compatibility with loopAES and very old TrueCrypt), these should be never ever implemented again anywhere. Specifically "tcw" is broken, insecure and provided here just to help people to migrate from old Truecrypt containers. Even Truecrypt followers removed it from the codebase. (It is basically combination of IV and slight modification of CBC mode. All recent version switched to XTS and plain IV.) So building abstraction over something known to be broken and that is now intentionally isolated inside dmcrypt is, in my opinion, really not a good idea. But please do get me wrong, I do not want to block any improvement. But it seems to me that this thread focused on creating nice crypto API interface for FDE IVs instead of demonstration that the proposed solution really solves the performance issue. And not only for your hw driver, maybe other systems could benefit from the better processing o
Re: [RFC PATCH v4 00/28] x86: Secure Memory Encryption (AMD)
Hi Tom,
On 02/16/17 at 09:41am, Tom Lendacky wrote:
> This RFC patch series provides support for AMD's new Secure Memory
> Encryption (SME) feature.
>
> SME can be used to mark individual pages of memory as encrypted through the
> page tables. A page of memory that is marked encrypted will be automatically
> decrypted when read from DRAM and will be automatically encrypted when
> written to DRAM. Details on SME can found in the links below.
>
> The SME feature is identified through a CPUID function and enabled through
> the SYSCFG MSR. Once enabled, page table entries will determine how the
> memory is accessed. If a page table entry has the memory encryption mask set,
> then that memory will be accessed as encrypted memory. The memory encryption
> mask (as well as other related information) is determined from settings
> returned through the same CPUID function that identifies the presence of the
> feature.
>
> The approach that this patch series takes is to encrypt everything possible
> starting early in the boot where the kernel is encrypted. Using the page
> table macros the encryption mask can be incorporated into all page table
> entries and page allocations. By updating the protection map, userspace
> allocations are also marked encrypted. Certain data must be accounted for
> as having been placed in memory before SME was enabled (EFI, initrd, etc.)
> and accessed accordingly.
>
> This patch series is a pre-cursor to another AMD processor feature called
> Secure Encrypted Virtualization (SEV). The support for SEV will build upon
> the SME support and will be submitted later. Details on SEV can be found
> in the links below.
>
> The following links provide additional detail:
>
> AMD Memory Encryption whitepaper:
>
> http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
>
> AMD64 Architecture Programmer's Manual:
>http://support.amd.com/TechDocs/24593.pdf
>SME is section 7.10
>SEV is section 15.34
>
> This patch series is based off of the master branch of tip.
> Commit a27cb9e1b2b4 ("Merge branch 'WIP.sched/core'")
>
> ---
>
> Still to do: IOMMU enablement support
>
> Changes since v3:
> - Broke out some of the patches into smaller individual patches
> - Updated Documentation
> - Added a message to indicate why the IOMMU was disabled
> - Updated CPU feature support for SME by taking into account whether
> BIOS has enabled SME
> - Eliminated redundant functions
> - Added some warning messages for DMA usage of bounce buffers when SME
> is active
> - Added support for persistent memory
> - Added support to determine when setup data is being mapped and be sure
> to map it un-encrypted
> - Added CONFIG support to set the default action of whether to activate
> SME if it is supported/enabled
> - Added support for (re)booting with kexec
Could you please add kexec list in cc when you updating the patches so
that kexec/kdump people do not miss them?
>
> Changes since v2:
> - Updated Documentation
> - Make the encryption mask available outside of arch/x86 through a
> standard include file
> - Conversion of assembler routines to C where possible (not everything
> could be converted, e.g. the routine that does the actual encryption
> needs to be copied into a safe location and it is difficult to
> determine the actual length of the function in order to copy it)
> - Fix SME feature use of scattered CPUID feature
> - Creation of SME specific functions for things like encrypting
> the setup data, ramdisk, etc.
> - New take on early_memremap / memremap encryption support
> - Additional support for accessing video buffers (fbdev/gpu) as
> un-encrypted
> - Disable IOMMU for now - need to investigate further in relation to
> how it needs to be programmed relative to accessing physical memory
>
> Changes since v1:
> - Added Documentation.
> - Removed AMD vendor check for setting the PAT write protect mode
> - Updated naming of trampoline flag for SME as well as moving of the
> SME check to before paging is enabled.
> - Change to early_memremap to identify the data being mapped as either
> boot data or kernel data. The idea being that boot data will have
> been placed in memory as un-encrypted data and would need to be accessed
> as such.
> - Updated debugfs support for the bootparams to access the data properly.
> - Do not set the SYSCFG[MEME] bit, only check it. The setting of the
> MemEncryptionModeEn bit results in a reduction of physical address size
> of the processor. It is possible that BIOS could have configured resources
> resources into a range that will now not be addressable. To prevent this,
> rely on BIOS to set the SYSCFG[MEME] bit and only then enable memory
> encryption support in the kernel.
>
> Tom Lendacky (28):
> x86: Documentation for AMD Secure Memory Encryption (SME)
> x86: Set the write-protect cache mode for full PAT support
> x86: Add the Secure
Re: [GIT PULL] HID for 4.11
On Feb 28 2017 or thereabouts, Linus Torvalds wrote: > On Tue, Feb 28, 2017 at 7:24 PM, Peter Hutterer > wrote: > > > > I suspect you're just triggering a bug that wasn't triggered by the ps/2 > > emulation. you can run linput-debug-events --verbose and have a look at the > > various state debugging information, that may hint at what's going on (e.g. > > a finger mistaken as palm touch, or something). Or record one such > > interaction with evemu-record and send it to me (preferrably here [1], if > > you're using libinput). Also, what version of libinput/synaptics are you on? > > bug reported (it's bug 100014). > Thanks for the report. As Peter mentioned in the bug, there is a missing property on the kernel node (INPUT_PROP_BUTTONPAD). The thing is this property is solely driven in the current driver by the provided platform_data, so there is no way we ever set it through hid-rmi. I wonder how we missed that. Anyway, the good news is that the evemu record shows only one exportted button, so we can infer the property quite easily in the module. Would something like that work for you? >From 5f28af88f2c67d1c533500765c5190cdd3006539 Mon Sep 17 00:00:00 2001 From: Benjamin Tissoires Date: Wed, 1 Mar 2017 09:57:00 +0100 Subject: [PATCH] Input: rmi4 - f30: detect INPUT_PROP_BUTTONPAD from the button count INPUT_PROP_BUTTONPAD is currently only set through the platform data. The RMI4 header doc says that this property is there to force the buttonpad property, so we also need to detect it by looking at the exported buttons count. Signed-off-by: Benjamin Tissoires --- drivers/input/rmi4/rmi_f30.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c index 3422464..1986786 100644 --- a/drivers/input/rmi4/rmi_f30.c +++ b/drivers/input/rmi4/rmi_f30.c @@ -258,9 +258,10 @@ static int rmi_f30_map_gpios(struct rmi_function *fn, /* * Buttonpad could be also inferred from f30->has_mech_mouse_btns, -* but I am not sure, so use only the pdata info. +* but I am not sure, so use only the pdata info and the number of +* mapped buttons. */ - if (pdata->f30_data.buttonpad) + if (pdata->f30_data.buttonpad || (button - BTN_LEFT == 1)) __set_bit(INPUT_PROP_BUTTONPAD, input->propbit); return 0; -- 2.9.3 Dmitry, Andrew, would this work for you too? Cheers, Benjamin
[PATCH] f2fs: skip scanning free nid bitmap of full NAT blocks
This patch adds to account free nids for each NAT blocks, and while
scanning all free nid bitmap, do check count and skip lookuping in
full NAT block.
Signed-off-by: Chao Yu
---
fs/f2fs/debug.c | 1 +
fs/f2fs/f2fs.h | 2 ++
fs/f2fs/node.c | 34 --
3 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
index a77df377e2e8..ee2d0a485fc3 100644
--- a/fs/f2fs/debug.c
+++ b/fs/f2fs/debug.c
@@ -196,6 +196,7 @@ static void update_mem_info(struct f2fs_sb_info *sbi)
si->base_mem += (NM_I(sbi)->nat_bits_blocks << F2FS_BLKSIZE_BITS);
si->base_mem += NM_I(sbi)->nat_blocks * NAT_ENTRY_BITMAP_SIZE;
si->base_mem += NM_I(sbi)->nat_blocks / 8;
+ si->base_mem += NM_I(sbi)->nat_blocks * sizeof(unsigned short);
get_cache:
si->cache_mem = 0;
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 7e2924981eeb..c0b33719dfa9 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -557,6 +557,8 @@ struct f2fs_nm_info {
struct mutex build_lock;/* lock for build free nids */
unsigned char (*free_nid_bitmap)[NAT_ENTRY_BITMAP_SIZE];
unsigned char *nat_block_bitmap;
+ unsigned short *free_nid_count; /* free nid count of NAT block */
+ spinlock_t free_nid_lock; /* protect updating of nid count */
/* for checkpoint */
char *nat_bitmap; /* NAT bitmap pointer */
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 94967171dee8..1a759d45b7e4 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1823,7 +1823,8 @@ static void remove_free_nid(struct f2fs_sb_info *sbi,
nid_t nid)
kmem_cache_free(free_nid_slab, i);
}
-void update_free_nid_bitmap(struct f2fs_sb_info *sbi, nid_t nid, bool set)
+void update_free_nid_bitmap(struct f2fs_sb_info *sbi, nid_t nid,
+ bool set, bool build)
{
struct f2fs_nm_info *nm_i = NM_I(sbi);
unsigned int nat_ofs = NAT_BLOCK_OFFSET(nid);
@@ -1836,6 +1837,13 @@ void update_free_nid_bitmap(struct f2fs_sb_info *sbi,
nid_t nid, bool set)
set_bit_le(nid_ofs, nm_i->free_nid_bitmap[nat_ofs]);
else
clear_bit_le(nid_ofs, nm_i->free_nid_bitmap[nat_ofs]);
+
+ spin_lock(&nm_i->free_nid_lock);
+ if (set)
+ nm_i->free_nid_count[nat_ofs]++;
+ else if (!build)
+ nm_i->free_nid_count[nat_ofs]--;
+ spin_unlock(&nm_i->free_nid_lock);
}
static void scan_nat_page(struct f2fs_sb_info *sbi,
@@ -1847,6 +1855,9 @@ static void scan_nat_page(struct f2fs_sb_info *sbi,
unsigned int nat_ofs = NAT_BLOCK_OFFSET(start_nid);
int i;
+ if (test_bit_le(nat_ofs, nm_i->nat_block_bitmap))
+ return;
+
set_bit_le(nat_ofs, nm_i->nat_block_bitmap);
i = start_nid % NAT_ENTRY_PER_BLOCK;
@@ -1861,7 +1872,7 @@ static void scan_nat_page(struct f2fs_sb_info *sbi,
f2fs_bug_on(sbi, blk_addr == NEW_ADDR);
if (blk_addr == NULL_ADDR)
freed = add_free_nid(sbi, start_nid, true);
- update_free_nid_bitmap(sbi, start_nid, freed);
+ update_free_nid_bitmap(sbi, start_nid, freed, true);
}
}
@@ -1877,6 +1888,8 @@ static void scan_free_nid_bits(struct f2fs_sb_info *sbi)
for (i = 0; i < nm_i->nat_blocks; i++) {
if (!test_bit_le(i, nm_i->nat_block_bitmap))
continue;
+ if (!nm_i->free_nid_count[i])
+ continue;
for (idx = 0; idx < NAT_ENTRY_PER_BLOCK; idx++) {
nid_t nid;
@@ -2081,7 +2094,7 @@ bool alloc_nid(struct f2fs_sb_info *sbi, nid_t *nid)
__insert_nid_to_list(sbi, i, ALLOC_NID_LIST, false);
nm_i->available_nids--;
- update_free_nid_bitmap(sbi, *nid, false);
+ update_free_nid_bitmap(sbi, *nid, false, false);
spin_unlock(&nm_i->nid_list_lock);
return true;
@@ -2137,7 +2150,7 @@ void alloc_nid_failed(struct f2fs_sb_info *sbi, nid_t nid)
nm_i->available_nids++;
- update_free_nid_bitmap(sbi, nid, true);
+ update_free_nid_bitmap(sbi, nid, true, false);
spin_unlock(&nm_i->nid_list_lock);
@@ -2467,11 +2480,11 @@ static void __flush_nat_entry_set(struct f2fs_sb_info
*sbi,
add_free_nid(sbi, nid, false);
spin_lock(&NM_I(sbi)->nid_list_lock);
NM_I(sbi)->available_nids++;
- update_free_nid_bitmap(sbi, nid, true);
+ update_free_nid_bitmap(sbi, nid, true, false);
spin_unlock(&NM_I(sbi)->nid_list_lock);
} else {
spin_lock(&NM_I(sbi)->nid_list_lock);
- update_free_nid_bitmap(sbi, nid, false);
+ update
Re: [PATCH v2 1/3] mtd: nand: Cleanup/rework the atmel_nand driver
On Wed, 1 Mar 2017 09:38:07 +0100 Hans-Christian Noren Egtvedt wrote: > Around Wed 01 Mar 2017 09:22:24 +0100 or thereabout, Boris Brezillon wrote: > > Hi Hans-Christian, > > > > On Fri, 24 Feb 2017 10:04:35 +0100 > > Hans-Christian Noren Egtvedt wrote: > > > >> Around Fri 24 Feb 2017 09:55:09 +0100 or thereabout, Boris Brezillon > >> wrote: > >> > On Fri, 24 Feb 2017 09:52:09 +0100 > >> > Hans-Christian Noren Egtvedt wrote: > >> >> Around Fri 24 Feb 2017 09:27:42 +0100 or thereabout, Boris Brezillon > >> >> wrote: > >> >> > On Fri, 24 Feb 2017 09:14:30 +0100 Hans-Christian Noren Egtvedt > >> >> > wrote: > >> >> >> Around Thu 23 Feb 2017 21:18:13 -0800 or thereabout, Håvard > >> >> >> Skinnemoen wrote: > >> >> >> > On Tue, Feb 21, 2017 at 9:14 AM, Alexandre Belloni > >> >> >> > wrote: > >> >> >> >> On 21/02/2017 at 18:43:35 +0200, Andy Shevchenko wrote: > >> >> > >> >> > >> >> > >> >> >> >> If nobody complains about the 4.10 breakage, You'll have plenty > >> >> >> >> of time > >> >> >> >> to remove it for 4.12 > >> >> >> > > >> >> >> > I'm fine with that, but I haven't put much effort into keeping it > >> >> >> > alive lately. If Hans-Christian agrees, I'm willing to post a > >> >> >> > patch to > >> >> >> > remove it, or ack someone else's patch. > >> >> >> > >> >> >> Then lets plan this for 4.12, either you Håvard whip up a patch or I > >> >> >> can > >> >> >> eventually do it. > >> >> >> > >> >> >> I can push it through the linux-avr32 git tree on kernel.org. > >> >> >> > >> >> > > >> >> > Can you do that just after 4.11-rc1 is released and provide a topic > >> >> > branch I can pull in my nand/next branch, so that I can rework this > >> >> > patch and drop all the pdata-compat code (as suggested by Andy). > >> >> > >> >> OK, I will try to prepare it during the weekend. > >> >> > >> >> Any reason to wait for 4.11-rc1? AFAIK Linus prefers the larger changes > >> >> before he starts tagging rc's. > >> >> > >> > > >> > Oh, so you want to queue it for 4.11, that's even better. > >> > >> Perhaps I misunderstood you, by after 4.11-rc1 you mean queue it for 4.12? > >> > >> I will see what I get around to do in the weekend, it should be pretty > >> straightforward, just want to make sure we remove all the bits. > >> > > > > Any progress on this? I plan to send a new version of this series soon > > and I'd like to know if I should drop pdata/avr32 support or not. Note > > that I'm targeting 4.12, so, as long as you drop avr32 support in 4.12 > > we should be good. > > I got around to make the patch series during the weekend, but I thought it > would be a good idea sending them to the kernel mailing list as a FYI. Definitely. > > Also, I was unsure if I should send the driver removals through the > sub-maintainers trees, or if I can push them through linux-avr32 tree. I think it should go through the sub-maintainers trees, but I guess you can remove the arch code without breaking the build, so it shouldn't be a problem if drivers removal don't go through the avr32 tree. > > I have a patch removing the pata driver for AVR32. > Great! Just send everything to the MLs (and relevant maintainers). Thanks, Boris
Re: [PATCH] hv: hide unused label
* Arnd Bergmann wrote:
> This new 32-bit warning just showed up:
>
> arch/x86/hyperv/hv_init.c: In function 'hyperv_init':
> arch/x86/hyperv/hv_init.c:167:1: error: label 'register_msr_cs' defined but
> not used [-Werror=unused-label]
>
> The easiest solution is to move the label up into the existing #ifdef that
> has the goto.
>
> Fixes: dee863b571b0 ("hv: export current Hyper-V clocksource")
> Signed-off-by: Arnd Bergmann
> ---
> arch/x86/hyperv/hv_init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> index db64baf0e500..8bef70e7f3cc 100644
> --- a/arch/x86/hyperv/hv_init.c
> +++ b/arch/x86/hyperv/hv_init.c
> @@ -158,13 +158,13 @@ void hyperv_init(void)
> clocksource_register_hz(&hyperv_cs_tsc, NSEC_PER_SEC/100);
> return;
> }
> +register_msr_cs:
> #endif
> /*
>* For 32 bit guests just use the MSR based mechanism for reading
>* the partition counter.
>*/
>
> -register_msr_cs:
Now the warning triggers upstream:
arch/x86/hyperv/hv_init.c: In function ‘hyperv_init’:
arch/x86/hyperv/hv_init.c:167:1: warning: label ‘register_msr_cs’ defined but
not used [-Wunused-label]
Thanks,
Ingo
Re: [PATCH V3 2/7] PM / OPP: Introduce "domain-performance-state" binding to OPP nodes
On 01-03-17, 09:45, Geert Uytterhoeven wrote: > On Wed, Mar 1, 2017 at 7:14 AM, Viresh Kumar wrote: > > On 28-02-17, 09:52, Rob Herring wrote: > >> On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson > >> wrote: > >> > This comes from the early design of the generic PM domain, thus I > >> > assume we have some HW with such complex PM topology. However, I don't > >> > know if it is actually being used. > >> > > >> > Moreover, the corresponding DT bindings for "power-domains" parents, > >> > can easily be extended to cover more than one parent. See more in > >> > Documentation/devicetree/bindings/power/power_domain.txt > >> > >> I could easily see device having 2 power domains. For example a cpu > >> may have separate domains for RAM/caches and logic. > > > > An important thing here is that PM domain doesn't support such devices. > > i.e. a > > device isn't allowed to have multiple PM domains today. So a way to support > > such > > devices can be to create a virtual PM domain, that has two parents and > > device as > > its child. > > As clock domains (and their support code) are fairly orthogonal to power > areas, currently our power area controller driver just forwards the > clock handling > to the clock driver (cfr. rcar-sysc). Perhaps Rajendra can explain better but Qcom have a case where they need to program two power domains as well. -- viresh
selftests broke upstream
Hi, The x86 selftests build broke upstream: triton:~/tip/tools/testing/selftests/x86> make Makefile:44: warning: overriding recipe for target 'clean' ../lib.mk:51: warning: ignoring old recipe for target 'clean' gcc -m32 -o /single_step_syscall_32 -O2 -g -std=gnu99 -pthread -Wall single_step_syscall.c -lrt -ldl -lm /usr/bin/ld: cannot open output file /single_step_syscall_32: Permission denied collect2: error: ld returned 1 exit status Makefile:47: recipe for target '/single_step_syscall_32' failed make: *** [/single_step_syscall_32] Error 1 It used to be possible to build only the x86 testcases in that directory. Another problem is that the pkeys testcases are still very noisy: gcc -m64 -o /home/mingo/tip/tools/testing/selftests/x86/protection_keys_64 -O2 -g -std=gnu99 -pthread -Wall protection_keys.c -lrt -ldl In file included from protection_keys.c:45:0: pkey-helpers.h: In function ‘sigsafe_printf’: pkey-helpers.h:41:3: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result] write(1, dprint_in_signal_buffer, len); ^ protection_keys.c: In function ‘dumpit’: protection_keys.c:407:3: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result] write(1, buf, nr_read); ^ gcc -m64 -o /home/mingo/tip/tools/testing/selftests/x86/test_vdso_64 -O2 -g -std=gnu99 -pthread -Wall test_vdso.c -lrt -ldl test_vdso.c: In function ‘main’: test_vdso.c:98:37: warning: ‘node’ may be used uninitialized in this function [-Wmaybe-uninitialized] if (!ret_vsys && (cpu_vsys != cpu || node_vsys != node)) ^ test_vdso.c:78:12: note: ‘node’ was declared here unsigned node; ^ I thought all this got already fixed? Thanks, Ingo
Re: [PATCH 3/3] mm, vmscan: Prevent kswapd sleeping prematurely due to mismatched classzone_idx
On 02/23/2017 04:01 PM, Mel Gorman wrote:
> On Mon, Feb 20, 2017 at 05:42:49PM +0100, Vlastimil Babka wrote:
>>> With this patch on top, all the latencies relative to the baseline are
>>> improved, particularly write latencies. The read latencies are still high
>>> for the number of threads but it's worth noting that this is mostly due
>>> to the IO scheduler and not directly related to reclaim. The vmstats are
>>> a bit of a mix but the relevant ones are as follows;
>>>
>>> 4.10.0-rc7 4.10.0-rc7 4.10.0-rc7
>>> mmots-20170209 clear-v1r25keepawake-v1r25
>>> Swap Ins 0 0 0
>>> Swap Outs0 608 0
>>> Direct pages scanned 6910672 3132699 6357298
>>> Kswapd pages scanned 570369468248866556986286
>>> Kswapd pages reclaimed559934886347432955939113
>>> Direct pages reclaimed 6905990 2964843 6352115
>>
>> These stats are confusing me. The earlier description suggests that this
>> patch
>> should cause less direct reclaim and more kswapd reclaim, but compared to
>> "clear-v1r25" it does the opposite? Was clear-v1r25 overreclaiming then?
>> (when
>> considering direct + kswapd combined)
>>
>
> The description is referring to the impact relative to baseline. It is
> true that relative to patch that direct reclaim is higher but there are
> a number of anomalies.
>
> Note that kswapd is scanning very aggressively in "clear-v1" and overall
> efficiency is down to 76%. It's also not clear in the stats but in
> "clear-v1", pgskip_* is active as the wrong zone is being reclaimed for
> due to the patch "mm, vmscan: fix zone balance check in
> prepare_kswapd_sleep". It's also doing a lot of writing of file-backed
> pages from reclaim context and some swapping due to the aggressiveness
> of the scan.
>
> While direct reclaim activity might be lower, it's due to kswapd scanning
> aggressively and trying to reclaim the world which is not the right thing
> to do. With the patches applied, there is still direct reclaim but the fast
> bulk of them are when the workload changes phase from "creating work files"
> to starting multiple threads that allocate a lot of anonymous memory with
> a sudden spike in memory pressure that kswapd does not keep ahead of with
> multiple allocating threads.
Thanks for the explanation.
>
>>> @@ -3328,6 +3330,22 @@ static int balance_pgdat(pg_data_t *pgdat, int
>>> order, int classzone_idx)
>>> return sc.order;
>>> }
>>>
>>> +/*
>>> + * pgdat->kswapd_classzone_idx is the highest zone index that a recent
>>> + * allocation request woke kswapd for. When kswapd has not woken recently,
>>> + * the value is MAX_NR_ZONES which is not a valid index. This compares a
>>> + * given classzone and returns it or the highest classzone index kswapd
>>> + * was recently woke for.
>>> + */
>>> +static enum zone_type kswapd_classzone_idx(pg_data_t *pgdat,
>>> + enum zone_type classzone_idx)
>>> +{
>>> + if (pgdat->kswapd_classzone_idx == MAX_NR_ZONES)
>>> + return classzone_idx;
>>> +
>>> + return max(pgdat->kswapd_classzone_idx, classzone_idx);
>>
>> A bit paranoid comment: this should probably read
>> pgdat->kswapd_classzone_idx to
>> a local variable with READ_ONCE(), otherwise something can set it to
>> MAX_NR_ZONES between the check and max(), and compiler can decide to reread.
>> Probably not an issue with current callers, but I'd rather future-proof it.
>>
>
> I'm a little wary of adding READ_ONCE unless there is a definite
> problem. Even if it was an issue, I think it would be better to protect
> thse kswapd_classzone_idx and kswapd_order with a spinlock that is taken
> if an update is required or a read to fully guarantee the ordering.
>
> The consequences as they are is that kswapd may miss reclaiming at a
> higher order or classzone than it should have although it is very
> unlikely and the update and read are made with a workqueue wake and
> scheduler wakeup which should be sufficient in terms of barriers.
OK then.
Acked-by: Vlastimil Babka
Re: [PATCH] x86/acpi: Fix a warning message in logical CPU IDs allocation
* Dou Liyang wrote:
> Current warning message regarded the "nr_cpu_ids - 1" as the limit
> number of the CPUs. It may be confused us, for example:
> we have two CPUs, nr_cpu_ids = 2, but the warning message may
> indicate that we just have 1 CPU, which likes that:
> Only 1 processors supported.Processor 2/0x2 and the rest
> are ignored.
>
> Fix the warning message, replace "nr_cpu_ids - 1" with "nr_cpu_ids".
> And the warning message can be like that:
> APIC: NR_CPUS/possible_cpus limit of 2 reached. Processor 2/0x2
> and the rest are ignored.
>
> Signed-off-by: Dou Liyang
The patch is correct, but the title is wrong (it's 'apic', not 'acpi'), plus
the
changelog is unreadable. Furthermore the changelog does not declare the
changing
of the return code to -EINVAL ...
I fixed all that in the commit below, but please be more careful in the future.
Thanks,
Ingo
===>
>From bb3f0a52630c84807fca9bdd76ac2f5dcec82689 Mon Sep 17 00:00:00 2001
From: Dou Liyang
Date: Tue, 28 Feb 2017 13:50:52 +0800
Subject: [PATCH] x86/apic: Fix a warning message in logical CPU IDs allocation
The current warning message in allocate_logical_cpuid() is somewhat confusing:
Only 1 processors supported.Processor 2/0x2 and the rest are ignored.
As it might imply that there's only one CPU in the system - while what we ran
into here is a kernel limitation.
Fix the warning message to clarify all that:
APIC: NR_CPUS/possible_cpus limit of 2 reached. Processor 2/0x2 and the rest
are ignored.
( Also update the error return from -1 to -EINVAL, which is the more
canonical return value. )
Signed-off-by: Dou Liyang
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: b...@alien8.de
Cc: nicsta...@gmail.com
Cc: wanpeng...@hotmail.com
Link:
http://lkml.kernel.org/r/1488261052-25753-1-git-send-email-douly.f...@cn.fujitsu.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/apic/apic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 4261b3282ad9..11088b86e5c7 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2062,10 +2062,10 @@ static int allocate_logical_cpuid(int apicid)
/* Allocate a new cpuid. */
if (nr_logical_cpuids >= nr_cpu_ids) {
- WARN_ONCE(1, "Only %d processors supported."
+ WARN_ONCE(1, "APIC: NR_CPUS/possible_cpus limit of %i reached. "
"Processor %d/0x%x and the rest are ignored.\n",
-nr_cpu_ids - 1, nr_logical_cpuids, apicid);
- return -1;
+nr_cpu_ids, nr_logical_cpuids, apicid);
+ return -EINVAL;
}
cpuid_to_apicid[nr_logical_cpuids] = apicid;
Re: [RFC PATCH 0/4] KVM: Emulate UMIP (or almost do so)
On 12/13/2016 7:03 PM, Paolo Bonzini wrote: On 13/12/2016 05:03, Li, Liang Z wrote: Hi Paolo, We intended to enable UMIP for KVM and found you had already worked on it. Do you have any plan for the following patch set? It's there anything else you expect us help to do? Yes, I plan to resend these patches for 4.11. Hi Paolo, Previously we saw your RFC patches of UMIP sent out, and we would like to try some unit test in Intel. I found a patch written by you in https://patchwork.kernel.org/patch/9225929/, guess this is for the kvm unit test(though I failed to git apply it directly). And I wonder, when will it be integrated to kvm unit test repo? Besides, is this all the test for UMIP unit test? I.e. do we need to construct a scenario in the test to trigger vm exit and let hypervisor inject a GP fault? - I did not see this scenario in this patch. Or any other suggestions? :-) Thanks Yu
[tip:x86/urgent] x86/apic: Fix a warning message in logical CPU IDs allocation
Commit-ID: bb3f0a52630c84807fca9bdd76ac2f5dcec82689
Gitweb: http://git.kernel.org/tip/bb3f0a52630c84807fca9bdd76ac2f5dcec82689
Author: Dou Liyang
AuthorDate: Tue, 28 Feb 2017 13:50:52 +0800
Committer: Ingo Molnar
CommitDate: Wed, 1 Mar 2017 10:09:08 +0100
x86/apic: Fix a warning message in logical CPU IDs allocation
The current warning message in allocate_logical_cpuid() is somewhat confusing:
Only 1 processors supported.Processor 2/0x2 and the rest are ignored.
As it might imply that there's only one CPU in the system - while what we ran
into here is a kernel limitation.
Fix the warning message to clarify all that:
APIC: NR_CPUS/possible_cpus limit of 2 reached. Processor 2/0x2 and the rest
are ignored.
( Also update the error return from -1 to -EINVAL, which is the more
canonical return value. )
Signed-off-by: Dou Liyang
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: b...@alien8.de
Cc: nicsta...@gmail.com
Cc: wanpeng...@hotmail.com
Link:
http://lkml.kernel.org/r/1488261052-25753-1-git-send-email-douly.f...@cn.fujitsu.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/apic/apic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 4261b32..11088b8 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2062,10 +2062,10 @@ static int allocate_logical_cpuid(int apicid)
/* Allocate a new cpuid. */
if (nr_logical_cpuids >= nr_cpu_ids) {
- WARN_ONCE(1, "Only %d processors supported."
+ WARN_ONCE(1, "APIC: NR_CPUS/possible_cpus limit of %i reached. "
"Processor %d/0x%x and the rest are ignored.\n",
-nr_cpu_ids - 1, nr_logical_cpuids, apicid);
- return -1;
+nr_cpu_ids, nr_logical_cpuids, apicid);
+ return -EINVAL;
}
cpuid_to_apicid[nr_logical_cpuids] = apicid;
[tip:x86/urgent] x86/kdebugfs: Move boot params hierarchy under (debugfs)/x86/
Commit-ID: 10bce8410607a18eb3adf5d2739db8c8593e110d
Gitweb: http://git.kernel.org/tip/10bce8410607a18eb3adf5d2739db8c8593e110d
Author: Borislav Petkov
AuthorDate: Mon, 27 Feb 2017 23:50:58 +0100
Committer: Ingo Molnar
CommitDate: Wed, 1 Mar 2017 09:57:02 +0100
x86/kdebugfs: Move boot params hierarchy under (debugfs)/x86/
... since this is all x86-specific data and it makes sense to have it
under x86/ logically instead in the toplevel debugfs dir.
Signed-off-by: Borislav Petkov
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/20170227225058.27289-1...@alien8.de
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/kdebugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/kdebugfs.c b/arch/x86/kernel/kdebugfs.c
index bdb83e4..38b6458 100644
--- a/arch/x86/kernel/kdebugfs.c
+++ b/arch/x86/kernel/kdebugfs.c
@@ -167,7 +167,7 @@ static int __init boot_params_kdebugfs_init(void)
struct dentry *dbp, *version, *data;
int error = -ENOMEM;
- dbp = debugfs_create_dir("boot_params", NULL);
+ dbp = debugfs_create_dir("boot_params", arch_debugfs_dir);
if (!dbp)
return -ENOMEM;
[PATCH v2] lockdep: Teach lockdep about memalloc_noio_save
Commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O
during memory allocation") added the memalloc_noio_(save|restore) functions
to enable people to modify the MM behavior by disbaling I/O during memory
allocation. This prevents allocation paths recursing back into the filesystem
without explicitly changing the flags for every allocation site. Yet, lockdep
not being aware of that is prone to showing false positives. Fix this
by teaching it that the presence of PF_MEMALLOC_NOIO flag mean we are not
going to issue any I/O
Signed-off-by: Nikolay Borisov
---
kernel/locking/lockdep.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Turned out there was another place where RELCAIM_FS was being set, fix it
by using the memalloc_noio_flags when setting ->lockdep_reclaim_gfp flags.
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 9812e5dd409e..87cf9910e66f 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -2866,7 +2866,8 @@ static void __lockdep_trace_alloc(gfp_t gfp_mask,
unsigned long flags)
return;
/* this guy won't enter reclaim */
- if ((curr->flags & PF_MEMALLOC) && !(gfp_mask & __GFP_NOMEMALLOC))
+ if (((curr->flags & PF_MEMALLOC) && !(gfp_mask & __GFP_NOMEMALLOC)) ||
+ curr->flags & PF_MEMALLOC_NOIO)
return;
/* We're only interested __GFP_FS allocations for now */
@@ -3852,7 +3853,7 @@ EXPORT_SYMBOL_GPL(lock_unpin_lock);
void lockdep_set_current_reclaim_state(gfp_t gfp_mask)
{
- current->lockdep_reclaim_gfp = gfp_mask;
+ current->lockdep_reclaim_gfp = memalloc_noio_flags(gfp_mask);
}
void lockdep_clear_current_reclaim_state(void)
--
2.7.4
[PATCH RFC] f2fs: combine nat_bits and free_nid_bitmap cache
Both nat_bits cache and free_nid_bitmap cache provide same functionality
as a intermediate cache between free nid cache and disk, but with
different granularity of indicating free nid range, and different
persistence policy. nat_bits cache provides better persistence ability,
and free_nid_bitmap provides better granularity.
In this patch we combine advantage of both caches, so finally policy of
the intermediate cache would be:
- init: load free nid status from nat_bits into free_nid_bitmap
- lookup: scan free_nid_bitmap before load NAT blocks
- update: update free_nid_bitmap in real-time
- persistence: udpate and persist nat_bits in checkpoint
Signed-off-by: Chao Yu
---
fs/f2fs/node.c | 109 +
1 file changed, 39 insertions(+), 70 deletions(-)
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 1a759d45b7e4..6c027b6833f4 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -338,9 +338,6 @@ static void set_node_addr(struct f2fs_sb_info *sbi, struct
node_info *ni,
set_nat_flag(e, IS_CHECKPOINTED, false);
__set_nat_cache_dirty(nm_i, e);
- if (enabled_nat_bits(sbi, NULL) && new_blkaddr == NEW_ADDR)
- clear_bit_le(NAT_BLOCK_OFFSET(ni->nid), nm_i->empty_nat_bits);
-
/* update fsync_mark if its inode nat entry is still alive */
if (ni->nid != ni->ino)
e = __lookup_nat_cache(nm_i, ni->ino);
@@ -1920,58 +1917,6 @@ static void scan_free_nid_bits(struct f2fs_sb_info *sbi)
up_read(&nm_i->nat_tree_lock);
}
-static int scan_nat_bits(struct f2fs_sb_info *sbi)
-{
- struct f2fs_nm_info *nm_i = NM_I(sbi);
- struct page *page;
- unsigned int i = 0;
- nid_t nid;
-
- if (!enabled_nat_bits(sbi, NULL))
- return -EAGAIN;
-
- down_read(&nm_i->nat_tree_lock);
-check_empty:
- i = find_next_bit_le(nm_i->empty_nat_bits, nm_i->nat_blocks, i);
- if (i >= nm_i->nat_blocks) {
- i = 0;
- goto check_partial;
- }
-
- for (nid = i * NAT_ENTRY_PER_BLOCK; nid < (i + 1) * NAT_ENTRY_PER_BLOCK;
- nid++) {
- if (unlikely(nid >= nm_i->max_nid))
- break;
- add_free_nid(sbi, nid, true);
- }
-
- if (nm_i->nid_cnt[FREE_NID_LIST] >= MAX_FREE_NIDS)
- goto out;
- i++;
- goto check_empty;
-
-check_partial:
- i = find_next_zero_bit_le(nm_i->full_nat_bits, nm_i->nat_blocks, i);
- if (i >= nm_i->nat_blocks) {
- disable_nat_bits(sbi, true);
- up_read(&nm_i->nat_tree_lock);
- return -EINVAL;
- }
-
- nid = i * NAT_ENTRY_PER_BLOCK;
- page = get_current_nat_page(sbi, nid);
- scan_nat_page(sbi, page, nid);
- f2fs_put_page(page, 1);
-
- if (nm_i->nid_cnt[FREE_NID_LIST] < MAX_FREE_NIDS) {
- i++;
- goto check_partial;
- }
-out:
- up_read(&nm_i->nat_tree_lock);
- return 0;
-}
-
static void __build_free_nids(struct f2fs_sb_info *sbi, bool sync, bool mount)
{
struct f2fs_nm_info *nm_i = NM_I(sbi);
@@ -1993,21 +1938,6 @@ static void __build_free_nids(struct f2fs_sb_info *sbi,
bool sync, bool mount)
if (nm_i->nid_cnt[FREE_NID_LIST])
return;
-
- /* try to find free nids with nat_bits */
- if (!scan_nat_bits(sbi) && nm_i->nid_cnt[FREE_NID_LIST])
- return;
- }
-
- /* find next valid candidate */
- if (enabled_nat_bits(sbi, NULL)) {
- int idx = find_next_zero_bit_le(nm_i->full_nat_bits,
- nm_i->nat_blocks, 0);
-
- if (idx >= nm_i->nat_blocks)
- set_sbi_flag(sbi, SBI_NEED_FSCK);
- else
- nid = idx * NAT_ENTRY_PER_BLOCK;
}
/* readahead nat pages to be scanned */
@@ -2590,6 +2520,41 @@ static int __get_nat_bitmaps(struct f2fs_sb_info *sbi)
return 0;
}
+inline void load_free_nid_bitmap(struct f2fs_sb_info *sbi)
+{
+ struct f2fs_nm_info *nm_i = NM_I(sbi);
+ unsigned int i = 0;
+ nid_t nid, last_nid;
+
+ for (i = 0; i < nm_i->nat_blocks; i++) {
+ i = find_next_bit_le(nm_i->empty_nat_bits, nm_i->nat_blocks, i);
+ if (i >= nm_i->nat_blocks)
+ break;
+
+ set_bit_le(i, nm_i->nat_block_bitmap);
+
+ nid = i * NAT_ENTRY_PER_BLOCK;
+ last_nid = (i + 1) * NAT_ENTRY_PER_BLOCK;
+
+ for (; nid < last_nid; nid++)
+ update_free_nid_bitmap(sbi, nid, true, true);
+ }
+
+ for (i = 0; i < nm_i->nat_blocks; i++) {
+ i = find_next_bit_le(nm_i->full_nat_bits, nm_i->nat_blocks, i);
+ if (i >= nm_i->nat_blocks)
+
Re: [PATCH] refcount: add refcount_t API kernel-doc comments
On Tue, Feb 28, 2017 at 10:34:45PM -0500, David Windsor wrote:
> diff --git a/lib/refcount.c b/lib/refcount.c
> index 1d33366..30e0927 100644
> --- a/lib/refcount.c
> +++ b/lib/refcount.c
> @@ -37,6 +37,15 @@
> #include
> #include
>
> +/**
> + * refcount_add_not_zero - add a value to a refcount unless the refcount is 0
> + * @i: the value to add to the refcount
> + * @r: the refcount
> + *
> + * Will saturate at UINT_MAX and WARN.
> + *
> + * Return: false if the refcount is 0, true otherwise.
> + */
> bool refcount_add_not_zero(unsigned int i, refcount_t *r)
> {
> unsigned int old, new, val = atomic_read(&r->refs);
> @@ -64,18 +73,30 @@ bool refcount_add_not_zero(unsigned int i, refcount_t *r)
> }
> EXPORT_SYMBOL_GPL(refcount_add_not_zero);
>
> +/**
> + * refcount_add - add a value to a refcount
> + * @i: the value to add to the refcount
> + * @r: the refcount
> + *
> + * Similar to atomic_add(), will saturate at UINT_MAX and WARN.
> + */
> void refcount_add(unsigned int i, refcount_t *r)
> {
> WARN(!refcount_add_not_zero(i, r), "refcount_t: addition on 0;
> use-after-free.\n");
> }
> EXPORT_SYMBOL_GPL(refcount_add);
Usage of both of these should be discouraged, add/sub on refcounts is
'odd'. Also, both these lack the comment on memory ordering, copy/paste
from inc_not_zero/inc.
> -/*
> +/**
> + * refcount_inc_not_zero - increment a refcount unless it is 0
> + * @r: the refcount to increment
> + *
> * Similar to atomic_inc_not_zero(), will saturate at UINT_MAX and WARN.
> *
> * Provides no memory ordering, it is assumed the caller has guaranteed the
> * object memory to be stable (RCU, etc.). It does provide a control
> dependency
> * and thereby orders future stores. See the comment on top.
> + *
> + * Return: false if the refcount is 0, true otherwise
An alternative interpretation is: return true if the increment happened,
false otherwise. But given the saturation semantics that might be
awkward, but its the one I find easier to work with.
> */
> bool refcount_inc_not_zero(refcount_t *r)
> {
> @@ -103,11 +124,16 @@ bool refcount_inc_not_zero(refcount_t *r)
> }
> EXPORT_SYMBOL_GPL(refcount_inc_not_zero);
>
> -/*
> +/**
> + * refcount_inc - increment a refcount
> + * @r: the refcount to increment
> + *
> * Similar to atomic_inc(), will saturate at UINT_MAX and WARN.
> *
> * Provides no memory ordering, it is assumed the caller already has a
> * reference on the object, will WARN when this is not so.
> + *
> + * Will WARN if refcount is 0.
I think that duplicates the final part of the prior sentence in intent.
Also, it might be useful to explain why.
> */
> void refcount_inc(refcount_t *r)
> {
> @@ -115,6 +141,22 @@ void refcount_inc(refcount_t *r)
> }
> EXPORT_SYMBOL_GPL(refcount_inc);
>
> +/**
> + * refcount_sub_and_test - subtract from a refcount and test if it is 0
> + * @i: amount to subtract from the refcount
> + * @r: the refcount
> + *
> + * Similar to atomic_dec_and_test(), it will WARN on underflow and fail to
> + * decrement when saturated at UINT_MAX.
It will equally fail the subtraction on underflow and return false
(didn't hit 0) and leak.
> + *
> + * Provides release memory ordering, such that prior loads and stores are
> done
> + * before, and provides a control dependency such that free() must come
> after.
> + * See the comment on top.
> + *
> + * Return: true if the resulting refcount is greater than 0, false if the
> + * resulting refcount is 0, the refcount is saturated at UINT_MAX or the
> + * subtraction operation causes an underflow.
I think you got that wrong, will return true when we hit 0, false
otherwise.
Remember; one writes:
if (dec_and_test(&obj->ref))
free(obj);
> + */
> bool refcount_sub_and_test(unsigned int i, refcount_t *r)
> {
> unsigned int old, new, val = atomic_read(&r->refs);
> @@ -140,13 +182,20 @@ bool refcount_sub_and_test(unsigned int i, refcount_t
> *r)
> }
> EXPORT_SYMBOL_GPL(refcount_sub_and_test);
As with add, sub should be discouraged.
> -/*
> +/**
> + * refcount_dec_and_test - decrement a refcount and test if it is 0
> + * @r: the refcount
> + *
> * Similar to atomic_dec_and_test(), it will WARN on underflow and fail to
> * decrement when saturated at UINT_MAX.
> *
> * Provides release memory ordering, such that prior loads and stores are
> done
> * before, and provides a control dependency such that free() must come
> after.
> * See the comment on top.
> + *
> + * Return: true if the resulting refcount is greater than 0, false if the
> + * resulting refcount is 0, the refcount is saturated at UINT_MAX or the
> + * decrement operation causes an underflow.
got that similarly wrong.
> */
> bool refcount_dec_and_test(refcount_t *r)
> {
> @@ -154,21 +203,26 @@ bool refcount_dec_and_test(refcount_t *r)
> }
> EXPORT_SYMBOL_GPL(refcount_dec_and_test);
>
> -/*
> +/**
> + * refcount_dec - decrement a refcount
> + * @r: the ref
[tip:perf/urgent] kprobes/x86: Fix kernel panic when certain exception-handling addresses are probed
Commit-ID: 75013fb16f8484898eaa8d0b08fed942d790f029
Gitweb: http://git.kernel.org/tip/75013fb16f8484898eaa8d0b08fed942d790f029
Author: Masami Hiramatsu
AuthorDate: Wed, 1 Mar 2017 01:23:24 +0900
Committer: Ingo Molnar
CommitDate: Wed, 1 Mar 2017 09:56:13 +0100
kprobes/x86: Fix kernel panic when certain exception-handling addresses are
probed
Fix to the exception table entry check by using probed address
instead of the address of copied instruction.
This bug may cause unexpected kernel panic if user probe an address
where an exception can happen which should be fixup by __ex_table
(e.g. copy_from_user.)
Unless user puts a kprobe on such address, this doesn't
cause any problem.
This bug has been introduced years ago, by commit:
464846888d9a ("x86/kprobes: Fix a bug which can modify kernel code
permanently").
Signed-off-by: Masami Hiramatsu
Cc: Borislav Petkov
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Fixes: 464846888d9a ("x86/kprobes: Fix a bug which can modify kernel code
permanently")
Link:
http://lkml.kernel.org/r/148829899399.28855.12581062400757221722.stgit@devbox
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/kprobes/common.h | 2 +-
arch/x86/kernel/kprobes/core.c | 6 +++---
arch/x86/kernel/kprobes/opt.c| 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/kprobes/common.h b/arch/x86/kernel/kprobes/common.h
index c6ee63f..d688826 100644
--- a/arch/x86/kernel/kprobes/common.h
+++ b/arch/x86/kernel/kprobes/common.h
@@ -67,7 +67,7 @@
#endif
/* Ensure if the instruction can be boostable */
-extern int can_boost(kprobe_opcode_t *instruction);
+extern int can_boost(kprobe_opcode_t *instruction, void *addr);
/* Recover instruction if given address is probed */
extern unsigned long recover_probed_instruction(kprobe_opcode_t *buf,
unsigned long addr);
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 520b8df..88b3c94 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -166,12 +166,12 @@ NOKPROBE_SYMBOL(skip_prefixes);
* Returns non-zero if opcode is boostable.
* RIP relative instructions are adjusted at copying time in 64 bits mode
*/
-int can_boost(kprobe_opcode_t *opcodes)
+int can_boost(kprobe_opcode_t *opcodes, void *addr)
{
kprobe_opcode_t opcode;
kprobe_opcode_t *orig_opcodes = opcodes;
- if (search_exception_tables((unsigned long)opcodes))
+ if (search_exception_tables((unsigned long)addr))
return 0; /* Page fault may occur on this address. */
retry:
@@ -416,7 +416,7 @@ static int arch_copy_kprobe(struct kprobe *p)
* __copy_instruction can modify the displacement of the instruction,
* but it doesn't affect boostable check.
*/
- if (can_boost(p->ainsn.insn))
+ if (can_boost(p->ainsn.insn, p->addr))
p->ainsn.boostable = 0;
else
p->ainsn.boostable = -1;
diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
index 3d1bee9..3e7c6e5 100644
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -178,7 +178,7 @@ static int copy_optimized_instructions(u8 *dest, u8 *src)
while (len < RELATIVEJUMP_SIZE) {
ret = __copy_instruction(dest + len, src + len);
- if (!ret || !can_boost(dest + len))
+ if (!ret || !can_boost(dest + len, src + len))
return -EINVAL;
len += ret;
}
Re: [kernel-hardening] [PATCH] refcount: add refcount_t API kernel-doc comments
On Tue, Feb 28, 2017 at 09:44:40PM -0800, Kees Cook wrote: > On Tue, Feb 28, 2017 at 7:34 PM, David Windsor wrote: > > This adds kernel-doc comments for the new refcount_t API. > > > > Signed-off-by: David Windsor > > Yay docs! :) > > Acked-by: Kees Cook Now if only they were accurate ;-)
[GIT PULL] Thermal management updates for v4.11-rc1
Hi, Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next to receive the latest Thermal Management updates for v4.11-rc1 with top-most commit 6fefe19f583625ca4ea3ecc9128baa51c31c60a4: Merge branches 'thermal-core', 'thermal-soc', 'thermal-intel' and 'ida-conversion' into next (2017-02-22 15:35:06 +0800) on top of commit d5adbfcd5f7bcc6fa58a41c5c5ada0e5c826ce2c: Linux 4.10-rc7 (2017-02-05 15:10:58 -0800) Specifics: - Add thermal driver for R-Car Gen3 thermal sensors. - Add thermal driver for ZTE' zx2967 family thermal sensors. - convert thermal ID allocation from IDR to IDA. - fix a possible NULL dereference in imx thermal driver. - fix a ti-soc-thermal driver dependency issue so that critical thermal control is still available when CPU_THERMAL is not defined. - update binding information for QorIQ thermal driver. - A couple of cleanups in thermal core, intel_powerclamp, exynos, dra752-thermal, mtk-thermal driver. thanks, rui Arnd Bergmann (1): thermal: use cpumask_var_t for on-stack cpu masks Augusto Mecking Caringi (1): thermal/intel_powerclamp: Remove set-but-not-used variables Baoyou Xie (2): dt: bindings: add documentation for zx2967 family thermal sensor thermal: zx2967: add thermal driver for ZTE's zx2967 family Hongtao Jia (2): powerpc/mpc85xx: Update TMU device tree node for T1040/T1042 powerpc/mpc85xx: Update TMU device tree node for T1023/T1024 Jia Hongtao (1): dt-bindings: Update QorIQ TMU thermal bindings Keerthy (3): thermal: ti-soc-thermal: Remove CPU_THERMAL Dependency from TI_THERMAL thermal: arm: dra752: Remove TSHUT configuration thermal: arm: dra752: Remove all TSHUT related definitions Krzysztof Kozlowski (1): thermal: exynos: Remove parsing unused samsung,tmu_cal_mode property Matthew Wilcox (4): thermal core: convert ID allocation to IDA thermal: convert clock cooling to use an IDA thermal: convert cpu_cooling to use an IDA thermal: convert devfreq_cooling to use an IDA Shailendra Verma (1): thermal: imx: Fix possible NULL dereference. Vivek Gautam (1): thermal: mtk_thermal: Staticise a number of data variables Wolfram Sang (2): thermal: rcar_gen3_thermal: Document the R-Car Gen3 thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver Zhang Rui (2): Merge branch 'linus' of git://git.kernel.org/.../evalenti/linux- soc-thermal into thermal-soc Merge branches 'thermal-core', 'thermal-soc', 'thermal-intel' and 'ida-conversion' into next .../devicetree/bindings/thermal/qoriq-thermal.txt | 7 + .../bindings/thermal/rcar-gen3-thermal.txt | 56 .../devicetree/bindings/thermal/zx2967-thermal.txt | 116 +++ arch/powerpc/boot/dts/fsl/t1023si-post.dtsi| 4 +- arch/powerpc/boot/dts/fsl/t1040si-post.dtsi| 4 +- drivers/thermal/Kconfig| 17 ++ drivers/thermal/Makefile | 2 + drivers/thermal/clock_cooling.c| 50 +-- drivers/thermal/cpu_cooling.c | 102 +++ drivers/thermal/devfreq_cooling.c | 53 +--- drivers/thermal/imx_thermal.c | 4 + drivers/thermal/intel_powerclamp.c | 4 - drivers/thermal/mtk_thermal.c | 16 +- drivers/thermal/rcar_gen3_thermal.c| 335 + drivers/thermal/samsung/exynos_tmu.c | 1 - drivers/thermal/samsung/exynos_tmu.h | 1 - drivers/thermal/thermal_core.c | 75 ++--- drivers/thermal/ti-soc-thermal/Kconfig | 1 - drivers/thermal/ti-soc-thermal/dra752-bandgap.h| 19 -- .../thermal/ti-soc-thermal/dra752-thermal-data.c | 28 +- drivers/thermal/zx2967_thermal.c | 258 include/linux/thermal.h| 4 +- 22 files changed, 890 insertions(+), 267 deletions(-) create mode 100644 Documentation/devicetree/bindings/thermal/rcar- gen3-thermal.txt create mode 100644 Documentation/devicetree/bindings/thermal/zx2967- thermal.txt create mode 100644 drivers/thermal/rcar_gen3_thermal.c create mode 100644 drivers/thermal/zx2967_thermal.c
Re: [PATCH] x86/apic: Remove the extra judgement of skipped IO APIC setup
* Dou Liyang wrote:
> As the commit 2e63ad4bd5dd ("x86/apic: Do not init irq remapping
> if ioapic is disabled") added the judgement of skipped IO APIC
> setup at the beginning of enable_IR_x2apic(). It may be redundant
> that we check it again when we try to enable the interrupt mapping.
>
> So, remove the one in try_to_enable_IR() and refine them for
> better readability.
>
> Signed-off-by: Dou Liyang
> ---
> arch/x86/kernel/apic/apic.c | 17 -
> 1 file changed, 4 insertions(+), 13 deletions(-)
>
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index 8567c85..86e7bd8 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -1610,24 +1610,15 @@ static inline void try_to_enable_x2apic(int
> remap_mode) { }
> static inline void __x2apic_enable(void) { }
> #endif /* !CONFIG_X86_X2APIC */
>
> -static int __init try_to_enable_IR(void)
> -{
> -#ifdef CONFIG_X86_IO_APIC
> - if (!x2apic_enabled() && skip_ioapic_setup) {
> - pr_info("Not enabling interrupt remapping due to skipped
> IO-APIC setup\n");
> - return -1;
> - }
> -#endif
> - return irq_remapping_enable();
> -}
> -
> void __init enable_IR_x2apic(void)
> {
> unsigned long flags;
> int ret, ir_stat;
>
> - if (skip_ioapic_setup)
> + if (skip_ioapic_setup) {
> + pr_info("Not init interrupt remapping due to skipped IO-APIC
> setup\n");
So you replaced a perfectly readable kernel message:
- pr_info("Not enabling interrupt remapping due to skipped
IO-APIC setup\n");
... with an unreadable one:
+ pr_info("Not init interrupt remapping due to skipped IO-APIC
setup\n");
Why?
Also, the changelog is pretty much unreadable as well:
> As the commit 2e63ad4bd5dd ("x86/apic: Do not init irq remapping
> if ioapic is disabled") added the judgement of skipped IO APIC
> setup at the beginning of enable_IR_x2apic(). It may be redundant
> that we check it again when we try to enable the interrupt mapping.
>
> So, remove the one in try_to_enable_IR() and refine them for
> better readability.
I edited it to:
The following commit:
2e63ad4bd5dd ("x86/apic: Do not init irq remapping if ioapic is disabled")
... added a check for skipped IO-APIC setup to enable_IR_x2apic(), but this
check is also duplicated in try_to_enable_IR() - and it will never succeed
in
calling irq_remapping_enable().
Remove the whole irq_remapping_enable() complication: if the IO-APIC is
disabled we cannot enable IRQ remapping.
And I restored the original pr_info() message as well.
Thanks,
Ingo
Re: [PATCH 1/2] vfs: implement fchmodat2() syscall
[CC += linux-...@vger.kernel.org]
Hello Greg,
Since this is a kernel-user-space API change, please CC linux-api@.
The kernel source file Documentation/SubmitChecklist notes that all
Linux kernel patches that change userspace interfaces should be CCed
to linux-...@vger.kernel.org, so that the various parties who are
interested in API changes are informed. For further information, see
https://www.kernel.org/doc/man-pages/linux-api-ml.html
Thanks,
Michael
On Tue, Feb 28, 2017 at 6:03 PM, Greg Kurz wrote:
> According to the POSIX.1-2008 manual page [1], the fchmodat() function has
> a flag argument which may be passed the following value:
>
> AT_SYMLINK_NOFOLLOW
> If path names a symbolic link, then the mode of the symbolic link is
> changed.
>
> and the following error may be returned:
>
> [EOPNOTSUPP]
> The AT_SYMLINK_NOFOLLOW bit is set in the flag argument, path names a
> symbolic link, and the system does not support changing the mode of a
> symbolic link.
>
> The linux kernel doesn't support changing the mode of a symbolic link, but
> the current implementation doesn't even have a flag argument. It is then
> up to userspace to deal with that. Unfortunately, it is impossible to
> implement the POSIX behavior in a race-free manner.
>
> This patch introduces a new fchmodat2() syscall with a flag argument to
> address the issue.
>
> [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/chmod.html
>
> Signed-off-by: Greg Kurz
> ---
> fs/open.c | 23 +++
> include/linux/syscalls.h |2 ++
> include/uapi/asm-generic/unistd.h |4 +++-
> scripts/checksyscalls.sh |3 ++-
> 4 files changed, 26 insertions(+), 6 deletions(-)
>
> diff --git a/fs/open.c b/fs/open.c
> index 9921f70bc5ca..66a8c19f72ca 100644
> --- a/fs/open.c
> +++ b/fs/open.c
> @@ -558,24 +558,39 @@ SYSCALL_DEFINE2(fchmod, unsigned int, fd, umode_t, mode)
> return err;
> }
>
> -SYSCALL_DEFINE3(fchmodat, int, dfd, const char __user *, filename, umode_t,
> mode)
> +SYSCALL_DEFINE4(fchmodat2, int, dfd, const char __user *, filename, umode_t,
> + mode, int, flag)
> {
> struct path path;
> - int error;
> - unsigned int lookup_flags = LOOKUP_FOLLOW;
> + int error = -EINVAL;
> + unsigned int lookup_flags;
> +
> + if ((flag & ~AT_SYMLINK_NOFOLLOW) != 0)
> + goto out;
> +
> + lookup_flags = (flag & AT_SYMLINK_NOFOLLOW) ? 0 : LOOKUP_FOLLOW;
> retry:
> error = user_path_at(dfd, filename, lookup_flags, &path);
> if (!error) {
> - error = chmod_common(&path, mode);
> + error = -EOPNOTSUPP;
> + if (!d_is_symlink(path.dentry))
> + error = chmod_common(&path, mode);
> path_put(&path);
> if (retry_estale(error, lookup_flags)) {
> lookup_flags |= LOOKUP_REVAL;
> goto retry;
> }
> }
> +out:
> return error;
> }
>
> +SYSCALL_DEFINE3(fchmodat, int, dfd, const char __user *, filename, umode_t,
> + mode)
> +{
> + return sys_fchmodat2(dfd, filename, mode, 0);
> +}
> +
> SYSCALL_DEFINE2(chmod, const char __user *, filename, umode_t, mode)
> {
> return sys_fchmodat(AT_FDCWD, filename, mode);
> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index 91a740f6b884..982089d55b31 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -775,6 +775,8 @@ asmlinkage long sys_futimesat(int dfd, const char __user
> *filename,
> asmlinkage long sys_faccessat(int dfd, const char __user *filename, int
> mode);
> asmlinkage long sys_fchmodat(int dfd, const char __user * filename,
> umode_t mode);
> +asmlinkage long sys_fchmodat2(int dfd, const char __user *filename,
> + umode_t mode, int flag);
> asmlinkage long sys_fchownat(int dfd, const char __user *filename, uid_t
> user,
> gid_t group, int flag);
> asmlinkage long sys_openat(int dfd, const char __user *filename, int flags,
> diff --git a/include/uapi/asm-generic/unistd.h
> b/include/uapi/asm-generic/unistd.h
> index 9b1462e38b82..e8b0a00908b1 100644
> --- a/include/uapi/asm-generic/unistd.h
> +++ b/include/uapi/asm-generic/unistd.h
> @@ -730,9 +730,11 @@ __SYSCALL(__NR_pkey_mprotect, sys_pkey_mprotect)
> __SYSCALL(__NR_pkey_alloc,sys_pkey_alloc)
> #define __NR_pkey_free 290
> __SYSCALL(__NR_pkey_free, sys_pkey_free)
> +#define __NR_fchmodat2 291
> +__SYSCALL(__NR_fchmodat2, sys_fchmodat2)
>
> #undef __NR_syscalls
> -#define __NR_syscalls 291
> +#define __NR_syscalls 292
>
> /*
> * All syscalls below here should go away really,
> diff --git a/scripts/checksyscalls.sh b/scripts/checksyscalls.sh
> index 2c9082ba6137..2e7471a1d308 100755
> --- a/scripts/checksyscalls.sh
> +++ b/scrip
Re: [PATCH -v4 00/10] FUTEX_UNLOCK_PI wobbles
On Wed, 22 Feb 2017, Peter Zijlstra wrote: > On Wed, Feb 22, 2017 at 12:02:44PM +0100, Peter Zijlstra wrote: > > OK, so after having not thought about this, and then spend the last two > > days trying to cram all this nonsense back into my head, I think I have > > a slightly simpler option. > > > > In any case, I'll go respin the patch-set and repost. > > That is; what is wrong with the below patch against mainline? After staring at it for a couple of hours and paging the futex horror back in, I don't see any problem with that. Thanks, tglx
Re: [GIT PULL] HID for 4.11
[I forgot to add Dmitry in the loop, sorry for the noise.] On Mar 01 2017 or thereabouts, Benjamin Tissoires wrote: > On Feb 28 2017 or thereabouts, Linus Torvalds wrote: > > On Tue, Feb 28, 2017 at 7:24 PM, Peter Hutterer > > wrote: > > > > > > I suspect you're just triggering a bug that wasn't triggered by the ps/2 > > > emulation. you can run linput-debug-events --verbose and have a look at > > > the > > > various state debugging information, that may hint at what's going on > > > (e.g. > > > a finger mistaken as palm touch, or something). Or record one such > > > interaction with evemu-record and send it to me (preferrably here [1], if > > > you're using libinput). Also, what version of libinput/synaptics are you > > > on? > > > > bug reported (it's bug 100014). > > > > Thanks for the report. > > As Peter mentioned in the bug, there is a missing property on the kernel > node (INPUT_PROP_BUTTONPAD). > > The thing is this property is solely driven in the current driver by the > provided platform_data, so there is no way we ever set it through > hid-rmi. I wonder how we missed that. > > Anyway, the good news is that the evemu record shows only one exportted > button, so we can infer the property quite easily in the module. Would > something like that work for you? > > From 5f28af88f2c67d1c533500765c5190cdd3006539 Mon Sep 17 00:00:00 2001 > From: Benjamin Tissoires > Date: Wed, 1 Mar 2017 09:57:00 +0100 > Subject: [PATCH] Input: rmi4 - f30: detect INPUT_PROP_BUTTONPAD from the > button count > > INPUT_PROP_BUTTONPAD is currently only set through the platform data. > The RMI4 header doc says that this property is there to force the > buttonpad property, so we also need to detect it by looking at > the exported buttons count. > > Signed-off-by: Benjamin Tissoires > --- > drivers/input/rmi4/rmi_f30.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c > index 3422464..1986786 100644 > --- a/drivers/input/rmi4/rmi_f30.c > +++ b/drivers/input/rmi4/rmi_f30.c > @@ -258,9 +258,10 @@ static int rmi_f30_map_gpios(struct rmi_function *fn, > > /* >* Buttonpad could be also inferred from f30->has_mech_mouse_btns, > - * but I am not sure, so use only the pdata info. > + * but I am not sure, so use only the pdata info and the number of > + * mapped buttons. >*/ > - if (pdata->f30_data.buttonpad) > + if (pdata->f30_data.buttonpad || (button - BTN_LEFT == 1)) > __set_bit(INPUT_PROP_BUTTONPAD, input->propbit); > > return 0; > -- > 2.9.3 > > Dmitry, Andrew, would this work for you too? > > Cheers, > Benjamin
[PATCH 1/5] fs, xfs: convert xfs_bui_log_item.bui_refcount from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
fs/xfs/xfs_bmap_item.c | 4 ++--
fs/xfs/xfs_bmap_item.h | 4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/xfs/xfs_bmap_item.c b/fs/xfs/xfs_bmap_item.c
index 9bf57c7..33104ad 100644
--- a/fs/xfs/xfs_bmap_item.c
+++ b/fs/xfs/xfs_bmap_item.c
@@ -199,7 +199,7 @@ xfs_bui_init(
buip->bui_format.bui_nextents = XFS_BUI_MAX_FAST_EXTENTS;
buip->bui_format.bui_id = (uintptr_t)(void *)buip;
atomic_set(&buip->bui_next_extent, 0);
- atomic_set(&buip->bui_refcount, 2);
+ refcount_set(&buip->bui_refcount, 2);
return buip;
}
@@ -215,7 +215,7 @@ void
xfs_bui_release(
struct xfs_bui_log_item *buip)
{
- if (atomic_dec_and_test(&buip->bui_refcount)) {
+ if (refcount_dec_and_test(&buip->bui_refcount)) {
xfs_trans_ail_remove(&buip->bui_item, SHUTDOWN_LOG_IO_ERROR);
xfs_bui_item_free(buip);
}
diff --git a/fs/xfs/xfs_bmap_item.h b/fs/xfs/xfs_bmap_item.h
index c867daa..988a6ae 100644
--- a/fs/xfs/xfs_bmap_item.h
+++ b/fs/xfs/xfs_bmap_item.h
@@ -20,6 +20,8 @@
#ifndef__XFS_BMAP_ITEM_H__
#define__XFS_BMAP_ITEM_H__
+#include
+
/*
* There are (currently) two pairs of bmap btree redo item types: map & unmap.
* The common abbreviations for these are BUI (bmap update intent) and BUD
@@ -61,7 +63,7 @@ struct kmem_zone;
*/
struct xfs_bui_log_item {
struct xfs_log_item bui_item;
- atomic_tbui_refcount;
+ refcount_t bui_refcount;
atomic_tbui_next_extent;
unsigned long bui_flags; /* misc flags */
struct xfs_bui_log_format bui_format;
--
2.7.4
[PATCH 2/5] fs, xfs: convert xfs_efi_log_item.efi_refcount from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
fs/xfs/xfs_extfree_item.c | 4 ++--
fs/xfs/xfs_extfree_item.h | 4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/xfs/xfs_extfree_item.c b/fs/xfs/xfs_extfree_item.c
index d7bc149..4e0acf0 100644
--- a/fs/xfs/xfs_extfree_item.c
+++ b/fs/xfs/xfs_extfree_item.c
@@ -220,7 +220,7 @@ xfs_efi_init(
efip->efi_format.efi_nextents = nextents;
efip->efi_format.efi_id = (uintptr_t)(void *)efip;
atomic_set(&efip->efi_next_extent, 0);
- atomic_set(&efip->efi_refcount, 2);
+ refcount_set(&efip->efi_refcount, 2);
return efip;
}
@@ -290,7 +290,7 @@ void
xfs_efi_release(
struct xfs_efi_log_item *efip)
{
- if (atomic_dec_and_test(&efip->efi_refcount)) {
+ if (refcount_dec_and_test(&efip->efi_refcount)) {
xfs_trans_ail_remove(&efip->efi_item, SHUTDOWN_LOG_IO_ERROR);
xfs_efi_item_free(efip);
}
diff --git a/fs/xfs/xfs_extfree_item.h b/fs/xfs/xfs_extfree_item.h
index a32c794..e6da63d 100644
--- a/fs/xfs/xfs_extfree_item.h
+++ b/fs/xfs/xfs_extfree_item.h
@@ -18,6 +18,8 @@
#ifndef__XFS_EXTFREE_ITEM_H__
#define__XFS_EXTFREE_ITEM_H__
+#include
+
/* kernel only EFI/EFD definitions */
struct xfs_mount;
@@ -64,7 +66,7 @@ struct kmem_zone;
*/
typedef struct xfs_efi_log_item {
xfs_log_item_t efi_item;
- atomic_tefi_refcount;
+ refcount_t efi_refcount;
atomic_tefi_next_extent;
unsigned long efi_flags; /* misc flags */
xfs_efi_log_format_tefi_format;
--
2.7.4
Re: [PATCH 1/1] drivers/misc: Add Intel System ID driver
On Wed, Mar 1, 2017 at 8:23 AM, Loh, Tien Hock wrote: > Arnd, Greg, Please don't top-post. > I checked the attributes returned by the soc attribute subsystem, but > it seems that it is lacking something equivalent to timestamp in the > Intel System ID controller. Do you think it is better to add a new > attribute (named timestamp) to soc or create a new sysfs entry like > what I did? It depends on how common and how important this attribute is. - if it's not overly important, just drop it entirely. - if it's important enough that other SoCs are likely to have the same kind of information, make it a standard attribute - if this SoC is most likely the only one that will ever need it, but it has important uses, I'd make it a custom attribute Another option would be to fold the timestamp into the revision attribute, but whether that is a reasonable place for it would in turn depend on what the timestamp signifies. Can you explain what the timestamp is used for? Does it identify the time that the hardware revision was made, the time that a software was built which was loaded into it, or something else? What kind of user space application would need this information? Arnd
[PATCH] mmc: core: Fix power sequence ordering in mmc_power_up
Currently, mmc_power_up calls the pre_power_on callback, enables the power supply of the mmc by calling mmc_set_ios() and then call post_power_on. WiFi chipsets like the AP6335 require a specific power sequence ordering before being used. You must enable the power supply and wait until it reaches its minimum voltage, gate the clock and wait at least two cycles and then assert the reset line. This commit prevents regulators to be enabled in the middle of or after the power sequencing. We this fix, mmc_set_ios is first call, the underlying regulators are enabled, then pre_power_on and post_power_on are called, so clock and reset line are enabled in the right order, after the regulator. Signed-off-by: Romain Perier --- drivers/mmc/core/core.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index 1076b9d..36df24f 100644 --- a/drivers/mmc/core/core.c +++ b/drivers/mmc/core/core.c @@ -1798,8 +1798,6 @@ void mmc_power_up(struct mmc_host *host, u32 ocr) if (host->ios.power_mode == MMC_POWER_ON) return; - mmc_pwrseq_pre_power_on(host); - host->ios.vdd = fls(ocr) - 1; host->ios.power_mode = MMC_POWER_UP; /* Set initial state and call mmc_set_ios */ @@ -1819,13 +1817,20 @@ void mmc_power_up(struct mmc_host *host, u32 ocr) */ mmc_delay(10); - mmc_pwrseq_post_power_on(host); - host->ios.clock = host->f_init; host->ios.power_mode = MMC_POWER_ON; mmc_set_ios(host); + mmc_pwrseq_pre_power_on(host); + + /* +* This delay should be sufficient to wait at least two cycles of clock +* gated by pre_power_on +*/ + mmc_delay(1); + mmc_pwrseq_post_power_on(host); + /* * This delay must be at least 74 clock sizes, or 1 ms, or the * time required to reach a stable voltage. -- 2.9.3
Re: [PATCH] usb: gadget: add RNDIS configfs option for Windows rndiscmp.inf compatibility
On 02/28/2017 10:58 PM, David Lechner wrote: This adds a new configfs attribute named `use_ms_rndiscmp`. It is a boolean value that is used to select the class/subclass/protocol used by the RNDIS function interface association descriptor. By default, this is 0x02 (Comm), 0x06 (Ethernet), 0xff (None). When the use_ms_rndiscmp attribute is set to true, the values 0xef (Misc), 0x04 (RNDIS), 0x01 (Ethernet) will be used instead. This class/subclass/ protocol combination is recognized by the rndiscmp.inf file in Windows Vista and newer and will cause Windows to load the correct RNDIS driver without the need for a custom (signed) .inf file. To be honest, I'm not very happy with this patch because it makes our ConfigFS interface inflexible. Let's assume that any other combination of this attributes will be needed in a future and then what we are going to do with use_ms_rndiscmp attribute? So instead of having single attribute which sets the whole triple of values to some hardcoded ones I would prefer to have one attribute per each of this values and allow user to set them to his own values from userspace. Best regards, -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics
Re: [PATCH v4] reset: Add i.MX7 SRC reset driver
On Tue, 2017-02-28 at 11:46 -0800, Andrey Smirnov wrote:
> On Tue, Feb 28, 2017 at 6:38 AM, Philipp Zabel wrote:
> > On Tue, 2017-02-21 at 08:13 -0800, Andrey Smirnov wrote:
> >> Add reset controller driver exposing various reset faculties,
> >> implemented by System Reset Controller IP block.
> >>
> >> Cc: Lucas Stach
> >> Cc: Rob Herring
> >> Cc: Mark Rutland
> >> Cc: devicet...@vger.kernel.org
> >> Cc: linux-kernel@vger.kernel.org
> >> Cc: linux-arm-ker...@lists.infradead.org
> >> Signed-off-by: Andrey Smirnov
> >> ---
> >>
> >> Changes since v3 (see [v3]):
> >>
> >> - Convert code IMX7_RESET_PCIEPHY to change G_RST and BTNRST
> >> simultaneously to make all resets be representable as
> >> signal->bit in signal->offset register
> >>
> >> - Convert assert/deassert subroutines to be special cases of a
> >> common reset subroutine
> >>
> >> Changes since v2 (see [v2]):
> >>
> >> - Fix typos
> >>
> >> - Kconfig/Makefile chagnes account for alphabetical sorting of
> >> those files
> >>
> >> - Remove redundant includes
> >>
> >> - Make use of regmap_attach_dev and avoid storing refernce to
> >> struct *dev in private data
> >>
> >> - Change code and headers to expose almost all of the reset
> >> related bits in SRC IP block
> >>
> >> Changes since v1 (see [v1]):
> >>
> >> - Various small DT bindings description fixes as per feedback
> >> from Rob Herring
> >>
> >>
> >> [v1] https://lkml.org/lkml/2017/2/6/554
> >> [v2] https://lkml.org/lkml/2017/2/13/488
> >> [v3] https://lkml.org/lkml/2017/2/20/344
> >>
> >>
> >> .../devicetree/bindings/reset/fsl,imx7-src.txt | 47 ++
> >> drivers/reset/Kconfig | 8 ++
> >> drivers/reset/Makefile | 2 +
> >> drivers/reset/reset-imx7.c | 158
> >> +
> >> include/dt-bindings/reset/imx7-reset.h | 62
> >> 5 files changed, 277 insertions(+)
> >> create mode 100644
> >> Documentation/devicetree/bindings/reset/fsl,imx7-src.txt
> >> create mode 100644 drivers/reset/reset-imx7.c
> >> create mode 100644 include/dt-bindings/reset/imx7-reset.h
> >>
> >> diff --git a/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt
> >> b/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt
> >> new file mode 100644
> >> index 000..5e1afc3
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt
> >> @@ -0,0 +1,47 @@
> >> +Freescale i.MX7 System Reset Controller
> >> +==
> >> +
> >> +Please also refer to reset.txt in this directory for common reset
> >> +controller binding usage.
> >> +
> >> +Required properties:
> >> +- compatible: Should be "fsl,imx7-src", "syscon"
> >> +- reg: should be register base and length as documented in the
> >> + datasheet
> >> +- interrupts: Should contain SRC interrupt
> >> +- #reset-cells: 1, see below
> >> +
> >> +example:
> >> +
> >> +src: reset-controller@3039 {
> >> + compatible = "fsl,imx7d-src", "syscon";
> >> + reg = <0x3039 0x2000>;
> >> + interrupts = ;
> >> + #reset-cells = <1>;
> >> +};
> >> +
> >> +
> >> +Specifying reset lines connected to IP modules
> >> +==
> >> +
> >> +The system reset controller can be used to reset various set of
> >> +peripherals. Device nodes that need access to reset lines should
> >> +specify them as a reset phandle in their corresponding node as
> >> +specified in reset.txt.
> >> +
> >> +Example:
> >> +
> >> + pcie: pcie@3380 {
> >> +
> >> + ...
> >> +
> >> + resets = <&src IMX7_RESET_PCIEPHY>,
> >> + <&src IMX7_RESET_PCIE_CTRL_APPS_EN>;
> >> + reset-names = "pciephy", "apps";
> >> +
> >> + ...
> >> +};
> >> +
> >> +
> >> +For list of all valid reset indicies see
> >> +
> >> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> >> index 172dc96..bea1800 100644
> >> --- a/drivers/reset/Kconfig
> >> +++ b/drivers/reset/Kconfig
> >> @@ -27,6 +27,14 @@ config RESET_BERLIN
> >> help
> >> This enables the reset controller driver for Marvell Berlin SoCs.
> >>
> >> +config RESET_IMX7
> >> + bool "i.MX7 Reset Driver"
> >> + depends on SOC_IMX7D || COMPILE_TEST
> >> + select MFD_SYSCON
> >> + default SOC_IMX7D
> >
> > Can we make this
> >
> > config RESET_IMX7
> > bool "i.MX7 Reset Driver" if COMPILE_TEST
> > default SOC_IMX7D
> > select MFD_SYSCON
> >
> > instead?
> >
> > If you agree, I can fix it up while applying.
>
> Sure, I have no problem with that change.
Ok, thank you. Applied to reset/next.
regards
Philipp
Bug fix for uid/gid in jffs2
As we kown that uid is u32(__kernel_uid32_t) in linux, but uid is u16(jint16_t) in jffs2 ，so jffs2 has the following problem, mount -t jffs2 /dev/mtdblock0 /mnt touch /mnt/a chown 65535.65535 /mnt/a;ls -n /mnt total 1 -rw-r--r-- 1 65535 65535 2 Mar 1 11:53 a chown 65536.65536 /mnt/a;ls -n /mnt total 1 -rw-r--r-- 1 0 0 2 Mar 1 11:53 a chown 65537.65537 /mnt/a;ls -n /mnt total 1 -rw-r--r-- 1 1 1 2 Mar 1 11:53 a The patch bellow will fix it. From 0ab0c9a341e642345b8cf02a029ddc44421379c3 Mon Sep 17 00:00:00 2001 From: Shukui Yang Date: Wed, 1 Mar 2017 16:06:33 +0800 Subject: [PATCH] uid/gid use jint32_t in jffs2 Signed-off-by: Shukui Yang --- fs/jffs2/debug.c | 4 ++-- fs/jffs2/file.c| 8 fs/jffs2/fs.c | 22 +++--- fs/jffs2/gc.c | 12 ++-- fs/jffs2/readinode.c | 4 ++-- fs/jffs2/super.c | 2 +- include/uapi/linux/jffs2.h | 4 ++-- 7 files changed, 28 insertions(+), 28 deletions(-) diff --git a/fs/jffs2/debug.c b/fs/jffs2/debug.c index 9d26b1b9..5e37393 100644 --- a/fs/jffs2/debug.c +++ b/fs/jffs2/debug.c @@ -814,8 +814,8 @@ void __jffs2_dbg_superblock_counts(struct jffs2_sb_info *c) printk(JFFS2_DBG "ino:\t%#08x\n", je32_to_cpu(node.i.ino)); printk(JFFS2_DBG "version:\t%#08x\n", je32_to_cpu(node.i.version)); printk(JFFS2_DBG "mode:\t%#08x\n", node.i.mode.m); -printk(JFFS2_DBG "uid:\t%#04x\n", je16_to_cpu(node.i.uid)); -printk(JFFS2_DBG "gid:\t%#04x\n", je16_to_cpu(node.i.gid)); +printk(JFFS2_DBG "uid:\t%#08x\n", je32_to_cpu(node.i.uid)); +printk(JFFS2_DBG "gid:\t%#08x\n", je32_to_cpu(node.i.gid)); printk(JFFS2_DBG "isize:\t%#08x\n", je32_to_cpu(node.i.isize)); printk(JFFS2_DBG "atime:\t%#08x\n", je32_to_cpu(node.i.atime)); printk(JFFS2_DBG "mtime:\t%#08x\n", je32_to_cpu(node.i.mtime)); diff --git a/fs/jffs2/file.c b/fs/jffs2/file.c index c12476e..c5266ba 100644 --- a/fs/jffs2/file.c +++ b/fs/jffs2/file.c @@ -172,8 +172,8 @@ static int jffs2_write_begin(struct file *filp, struct address_space *mapping, ri.ino = cpu_to_je32(f->inocache->ino); ri.version = cpu_to_je32(++f->highest_version); ri.mode = cpu_to_jemode(inode->i_mode); -ri.uid = cpu_to_je16(i_uid_read(inode)); -ri.gid = cpu_to_je16(i_gid_read(inode)); +ri.uid = cpu_to_je32(i_uid_read(inode)); +ri.gid = cpu_to_je32(i_gid_read(inode)); ri.isize = cpu_to_je32(max((uint32_t)inode->i_size, pageofs)); ri.atime = ri.ctime = ri.mtime = cpu_to_je32(get_seconds()); ri.offset = cpu_to_je32(inode->i_size); @@ -280,8 +280,8 @@ static int jffs2_write_end(struct file *filp, struct address_space *mapping, /* Set the fields that the generic jffs2_write_inode_range() code can't find */ ri->ino = cpu_to_je32(inode->i_ino); ri->mode = cpu_to_jemode(inode->i_mode); -ri->uid = cpu_to_je16(i_uid_read(inode)); -ri->gid = cpu_to_je16(i_gid_read(inode)); +ri->uid = cpu_to_je32(i_uid_read(inode)); +ri->gid = cpu_to_je32(i_gid_read(inode)); ri->isize = cpu_to_je32((uint32_t)inode->i_size); ri->atime = ri->ctime = ri->mtime = cpu_to_je32(get_seconds()); diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c index 567653f..f75ab395 100644 --- a/fs/jffs2/fs.c +++ b/fs/jffs2/fs.c @@ -99,9 +99,9 @@ int jffs2_do_setattr (struct inode *inode, struct iattr *iattr) ri->ino = cpu_to_je32(inode->i_ino); ri->version = cpu_to_je32(++f->highest_version); -ri->uid = cpu_to_je16((ivalid & ATTR_UID)? +ri->uid = cpu_to_je32((ivalid & ATTR_UID)? from_kuid(&init_user_ns, iattr->ia_uid):i_uid_read(inode)); -ri->gid = cpu_to_je16((ivalid & ATTR_GID)? +ri->gid = cpu_to_je32((ivalid & ATTR_GID)? from_kgid(&init_user_ns, iattr->ia_gid):i_gid_read(inode)); if (ivalid & ATTR_MODE) @@ -149,8 +149,8 @@ int jffs2_do_setattr (struct inode *inode, struct iattr *iattr) inode->i_ctime = ITIME(je32_to_cpu(ri->ctime)); inode->i_mtime = ITIME(je32_to_cpu(ri->mtime)); inode->i_mode = jemode_to_cpu(ri->mode); -i_uid_write(inode, je16_to_cpu(ri->uid)); -i_gid_write(inode, je16_to_cpu(ri->gid)); +i_uid_write(inode, je32_to_cpu(ri->uid)); +i_gid_write(inode, je32_to_cpu(ri->gid)); old_metadata = f->metadata; @@ -276,8 +276,8 @@ struct inode *jffs2_iget(struct super_block *sb, unsigned long ino) goto error; inode->i_mode = jemode_to_cpu(latest_node.mode); -i_uid_write(inode, je16_to_cpu(latest_node.uid)); -i_gid_write(inode, je16_to_cpu(latest_node.gid)); +i_uid_write(inode, je32_to_cpu(latest_node.uid)); +i_gid_write(inode, je32_to_cpu(latest_node.gid)); inode->i_size = je32_to_cpu(latest_node.isize); inode->i_atime = ITIME(je32_to_cpu(latest_node.atime)); inode->i_mtime = ITIME(je32_to_cpu(latest_node.mtime)); @@ -441,14 +441,14 @@ struct inode *jffs2_new_in
[PATCH 3/5] fs, xfs: convert xlog_ticket.t_ref from atomic_t to refcount_t
refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: Elena Reshetova
Signed-off-by: Hans Liljestrand
Signed-off-by: Kees Cook
Signed-off-by: David Windsor
---
fs/xfs/xfs_log.c | 10 +-
fs/xfs/xfs_log_priv.h | 4 +++-
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c
index b1469f0..c127fa0 100644
--- a/fs/xfs/xfs_log.c
+++ b/fs/xfs/xfs_log.c
@@ -3500,8 +3500,8 @@ void
xfs_log_ticket_put(
xlog_ticket_t *ticket)
{
- ASSERT(atomic_read(&ticket->t_ref) > 0);
- if (atomic_dec_and_test(&ticket->t_ref))
+ ASSERT(refcount_read(&ticket->t_ref) > 0);
+ if (refcount_dec_and_test(&ticket->t_ref))
kmem_zone_free(xfs_log_ticket_zone, ticket);
}
@@ -3509,8 +3509,8 @@ xlog_ticket_t *
xfs_log_ticket_get(
xlog_ticket_t *ticket)
{
- ASSERT(atomic_read(&ticket->t_ref) > 0);
- atomic_inc(&ticket->t_ref);
+ ASSERT(refcount_read(&ticket->t_ref) > 0);
+ refcount_inc(&ticket->t_ref);
return ticket;
}
@@ -3632,7 +3632,7 @@ xlog_ticket_alloc(
unit_res = xfs_log_calc_unit_res(log->l_mp, unit_bytes);
- atomic_set(&tic->t_ref, 1);
+ refcount_set(&tic->t_ref, 1);
tic->t_task = current;
INIT_LIST_HEAD(&tic->t_queue);
tic->t_unit_res = unit_res;
diff --git a/fs/xfs/xfs_log_priv.h b/fs/xfs/xfs_log_priv.h
index c2604a5..279afce 100644
--- a/fs/xfs/xfs_log_priv.h
+++ b/fs/xfs/xfs_log_priv.h
@@ -18,6 +18,8 @@
#ifndef__XFS_LOG_PRIV_H__
#define __XFS_LOG_PRIV_H__
+#include
+
struct xfs_buf;
struct xlog;
struct xlog_ticket;
@@ -168,7 +170,7 @@ typedef struct xlog_ticket {
struct list_head t_queue; /* reserve/write queue */
struct task_struct *t_task; /* task that owns this ticket */
xlog_tid_t t_tid;/* transaction identifier : 4 */
- atomic_t t_ref;/* ticket reference count : 4 */
+ refcount_t t_ref;/* ticket reference count : 4 */
intt_curr_res; /* current reservation in bytes : 4 */
intt_unit_res; /* unit reservation in bytes: 4 */
char t_ocnt; /* original count : 1 */
--
2.7.4
Re: [PATCH 3/3] drivers:gpu: vga :vga_switcheroo.c : Fixed some coding style issues
On Tue, Feb 28, 2017 at 06:59:52PM +, Joan Jani wrote:
> Fixed the following style issues
>
> drivers/gpu/vga/vga_switcheroo.c:98: WARNING: please, no space before tabs
> drivers/gpu/vga/vga_switcheroo.c:99: WARNING: please, no space before tabs
> drivers/gpu/vga/vga_switcheroo.c:102: WARNING: please, no space before tabs
> drivers/gpu/vga/vga_switcheroo.c:103: WARNING: please, no space before tabs
> drivers/gpu/vga/vga_switcheroo.c:129: WARNING: please, no space before tabs
> drivers/gpu/vga/vga_switcheroo.c:135: WARNING: please, no space before tabs
> drivers/gpu/vga/vga_switcheroo.c:217: WARNING: line over 80 characters
> drivers/gpu/vga/vga_switcheroo.c:218: WARNING: line over 80 characters
> drivers/gpu/vga/vga_switcheroo.c:308: WARNING: please, no space before tabs
> drivers/gpu/vga/vga_switcheroo.c:340: WARNING: line over 80 characters
> drivers/gpu/vga/vga_switcheroo.c:1087: WARNING: Block comments use * on
> subsequent lines
> drivers/gpu/vga/vga_switcheroo.c:1087: WARNING: Block comments use a trailing
> */ on a separate line
>
> Signed-off-by: Joan Jani
Applied to drm-misc for 4.12, thanks.
-Daniel
> ---
> drivers/gpu/vga/vga_switcheroo.c | 28 +++-
> 1 file changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/vga/vga_switcheroo.c
> b/drivers/gpu/vga/vga_switcheroo.c
> index 5f962bf..3cd153c 100644
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -95,12 +95,12 @@
> * @pwr_state: current power state
> * @ops: client callbacks
> * @id: client identifier. Determining the id requires the handler,
> - * so gpus are initially assigned VGA_SWITCHEROO_UNKNOWN_ID
> - * and later given their true id in vga_switcheroo_enable()
> + * so gpus are initially assigned VGA_SWITCHEROO_UNKNOWN_ID
> + * and later given their true id in vga_switcheroo_enable()
> * @active: whether the outputs are currently switched to this client
> * @driver_power_control: whether power state is controlled by the driver's
> - * runtime pm. If true, writing ON and OFF to the vga_switcheroo debugfs
> - * interface is a no-op so as not to interfere with runtime pm
> + * runtime pm. If true, writing ON and OFF to the vga_switcheroo debugfs
> + * interface is a no-op so as not to interfere with runtime pm
> * @list: client list
> *
> * Registered client. A client can be either a GPU or an audio device on a
> GPU.
> @@ -126,13 +126,13 @@ static DEFINE_MUTEX(vgasr_mutex);
> /**
> * struct vgasr_priv - vga_switcheroo private data
> * @active: whether vga_switcheroo is enabled.
> - * Prerequisite is the registration of two GPUs and a handler
> + * Prerequisite is the registration of two GPUs and a handler
> * @delayed_switch_active: whether a delayed switch is pending
> * @delayed_client_id: client to which a delayed switch is pending
> * @debugfs_root: directory for vga_switcheroo debugfs interface
> * @switch_file: file for vga_switcheroo debugfs interface
> * @registered_clients: number of registered GPUs
> - * (counting only vga clients, not audio clients)
> + * (counting only vga clients, not audio clients)
> * @clients: list of registered clients
> * @handler: registered handler
> * @handler_flags: flags of registered handler
> @@ -214,8 +214,9 @@ static void vga_switcheroo_enable(void)
> *
> * Return: 0 on success, -EINVAL if a handler was already registered.
> */
> -int vga_switcheroo_register_handler(const struct vga_switcheroo_handler
> *handler,
> - enum vga_switcheroo_handler_flags_t
> handler_flags)
> +int vga_switcheroo_register_handler(
> + const struct vga_switcheroo_handler *handler,
> + enum vga_switcheroo_handler_flags_t handler_flags)
> {
> mutex_lock(&vgasr_mutex);
> if (vgasr_priv.handler) {
> @@ -305,7 +306,7 @@ static int register_client(struct pci_dev *pdev,
> * @pdev: client pci device
> * @ops: client callbacks
> * @driver_power_control: whether power state is controlled by the driver's
> - * runtime pm
> + * runtime pm
> *
> * Register vga client (GPU). Enable vga_switcheroo if another GPU and a
> * handler have already registered. The power state of the client is assumed
> @@ -337,8 +338,8 @@ EXPORT_SYMBOL(vga_switcheroo_register_client);
> * Return: 0 on success, -ENOMEM on memory allocation error.
> */
> int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
> - const struct vga_switcheroo_client_ops
> *ops,
> - enum vga_switcheroo_client_id id)
> + const struct vga_switcheroo_client_ops *ops,
> + enum vga_switcheroo_client_id id)
> {
> return register_client(pdev, ops, id | ID_BIT_AUDIO, false, false);
> }
> @@ -1084,7 +1085,8 @@ static int
> vga_switcheroo_runtime_resume_hdmi_audio(struct device *dev)
>
Re: [PATCH V3 2/7] PM / OPP: Introduce "domain-performance-state" binding to OPP nodes
On Wed, Mar 1, 2017 at 7:14 AM, Viresh Kumar wrote:
> On 28-02-17, 09:52, Rob Herring wrote:
>> On Tue, Feb 28, 2017 at 9:14 AM, Ulf Hansson wrote:
>> > This comes from the early design of the generic PM domain, thus I
>> > assume we have some HW with such complex PM topology. However, I don't
>> > know if it is actually being used.
>> >
>> > Moreover, the corresponding DT bindings for "power-domains" parents,
>> > can easily be extended to cover more than one parent. See more in
>> > Documentation/devicetree/bindings/power/power_domain.txt
>>
>> I could easily see device having 2 power domains. For example a cpu
>> may have separate domains for RAM/caches and logic.
>
> An important thing here is that PM domain doesn't support such devices. i.e. a
> device isn't allowed to have multiple PM domains today. So a way to support
> such
> devices can be to create a virtual PM domain, that has two parents and device
> as
> its child.
As clock domains (and their support code) are fairly orthogonal to power
areas, currently our power area controller driver just forwards the
clock handling
to the clock driver (cfr. rcar-sysc).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 1/3] mtd: nand: Cleanup/rework the atmel_nand driver
Hi Hans-Christian, On Fri, 24 Feb 2017 10:04:35 +0100 Hans-Christian Noren Egtvedt wrote: > Around Fri 24 Feb 2017 09:55:09 +0100 or thereabout, Boris Brezillon wrote: > > On Fri, 24 Feb 2017 09:52:09 +0100 > > Hans-Christian Noren Egtvedt wrote: > >> Around Fri 24 Feb 2017 09:27:42 +0100 or thereabout, Boris Brezillon > >> wrote: > >> > On Fri, 24 Feb 2017 09:14:30 +0100 Hans-Christian Noren Egtvedt > >> > wrote: > >> >> Around Thu 23 Feb 2017 21:18:13 -0800 or thereabout, Håvard Skinnemoen > >> >> wrote: > >> >> > On Tue, Feb 21, 2017 at 9:14 AM, Alexandre Belloni > >> >> > wrote: > >> >> >> On 21/02/2017 at 18:43:35 +0200, Andy Shevchenko wrote: > >> > >> > >> > >> >> >> If nobody complains about the 4.10 breakage, You'll have plenty of > >> >> >> time > >> >> >> to remove it for 4.12 > >> >> > > >> >> > I'm fine with that, but I haven't put much effort into keeping it > >> >> > alive lately. If Hans-Christian agrees, I'm willing to post a patch to > >> >> > remove it, or ack someone else's patch. > >> >> > >> >> Then lets plan this for 4.12, either you Håvard whip up a patch or I can > >> >> eventually do it. > >> >> > >> >> I can push it through the linux-avr32 git tree on kernel.org. > >> >> > >> > > >> > Can you do that just after 4.11-rc1 is released and provide a topic > >> > branch I can pull in my nand/next branch, so that I can rework this > >> > patch and drop all the pdata-compat code (as suggested by Andy). > >> > >> OK, I will try to prepare it during the weekend. > >> > >> Any reason to wait for 4.11-rc1? AFAIK Linus prefers the larger changes > >> before he starts tagging rc's. > >> > > > > Oh, so you want to queue it for 4.11, that's even better. > > Perhaps I misunderstood you, by after 4.11-rc1 you mean queue it for 4.12? > > I will see what I get around to do in the weekend, it should be pretty > straightforward, just want to make sure we remove all the bits. > Any progress on this? I plan to send a new version of this series soon and I'd like to know if I should drop pdata/avr32 support or not. Note that I'm targeting 4.12, so, as long as you drop avr32 support in 4.12 we should be good. Thanks, Boris
Re: [Nouveau] [PATCH 3/3] gpu: drm: drivers: Convert printk(KERN_ to pr_
On Tue, Feb 28, 2017 at 04:55:54AM -0800, Joe Perches wrote:
> Use a more common logging style.
>
> Miscellanea:
>
> o Coalesce formats and realign arguments
> o Neaten a few macros now using pr_
>
> Signed-off-by: Joe Perches
Plenty acks, also merged for 4.12.
Thanks, Daniel
> ---
> drivers/gpu/drm/gma500/cdv_intel_lvds.c | 9 -
> drivers/gpu/drm/gma500/oaktrail_lvds.c| 18 +-
> drivers/gpu/drm/gma500/psb_drv.h | 5 ++---
> drivers/gpu/drm/gma500/psb_intel_lvds.c | 7 +++
> drivers/gpu/drm/i915/i915_sw_fence.c | 8
> drivers/gpu/drm/mgag200/mgag200_mode.c| 2 +-
> drivers/gpu/drm/msm/msm_drv.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_acpi.c| 7 ---
> drivers/gpu/drm/nouveau/nouveau_vga.c | 4 ++--
> drivers/gpu/drm/nouveau/nv50_display.c| 22 +++---
> drivers/gpu/drm/nouveau/nvkm/core/mm.c| 10 +-
> drivers/gpu/drm/omapdrm/dss/dsi.c | 17 -
> drivers/gpu/drm/omapdrm/dss/dss.c | 3 +--
> drivers/gpu/drm/omapdrm/dss/dss.h | 15 ++-
> drivers/gpu/drm/omapdrm/omap_gem.c| 5 ++---
> drivers/gpu/drm/r128/r128_cce.c | 7 +++
> drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 6 ++
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 3 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 4 ++--
> 20 files changed, 72 insertions(+), 84 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> index 5efdb7fbb7ee..e64960db3224 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> @@ -284,8 +284,7 @@ static bool cdv_intel_lvds_mode_fixup(struct drm_encoder
> *encoder,
> head) {
> if (tmp_encoder != encoder
> && tmp_encoder->crtc == encoder->crtc) {
> - printk(KERN_ERR "Can't enable LVDS and another "
> -"encoder on the same pipe\n");
> + pr_err("Can't enable LVDS and another encoder on the
> same pipe\n");
> return false;
> }
> }
> @@ -756,13 +755,13 @@ void cdv_intel_lvds_init(struct drm_device *dev,
>
> failed_find:
> mutex_unlock(&dev->mode_config.mutex);
> - printk(KERN_ERR "Failed find\n");
> + pr_err("Failed find\n");
> psb_intel_i2c_destroy(gma_encoder->ddc_bus);
> failed_ddc:
> - printk(KERN_ERR "Failed DDC\n");
> + pr_err("Failed DDC\n");
> psb_intel_i2c_destroy(gma_encoder->i2c_bus);
> failed_blc_i2c:
> - printk(KERN_ERR "Failed BLC\n");
> + pr_err("Failed BLC\n");
> drm_encoder_cleanup(encoder);
> drm_connector_cleanup(connector);
> kfree(lvds_priv);
> diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c
> b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> index f7038f12ac76..e6943fef0611 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> @@ -255,15 +255,15 @@ static void oaktrail_lvds_get_configuration_mode(struct
> drm_device *dev,
> ((ti->vblank_hi << 8) | ti->vblank_lo);
> mode->clock = ti->pixel_clock * 10;
> #if 0
> - printk(KERN_INFO "hdisplay is %d\n", mode->hdisplay);
> - printk(KERN_INFO "vdisplay is %d\n", mode->vdisplay);
> - printk(KERN_INFO "HSS is %d\n", mode->hsync_start);
> - printk(KERN_INFO "HSE is %d\n", mode->hsync_end);
> - printk(KERN_INFO "htotal is %d\n", mode->htotal);
> - printk(KERN_INFO "VSS is %d\n", mode->vsync_start);
> - printk(KERN_INFO "VSE is %d\n", mode->vsync_end);
> - printk(KERN_INFO "vtotal is %d\n", mode->vtotal);
> - printk(KERN_INFO "clock is %d\n", mode->clock);
> + pr_info("hdisplay is %d\n", mode->hdisplay);
> + pr_info("vdisplay is %d\n", mode->vdisplay);
> + pr_info("HSS is %d\n", mode->hsync_start);
> + pr_info("HSE is %d\n", mode->hsync_end);
> + pr_info("htotal is %d\n", mode->htotal);
> + pr_info("VSS is %d\n", mode->vsync_start);
> + pr_info("VSE is %d\n", mode->vsync_end);
> + pr_info("vtotal is %d\n", mode->vtotal);
> + pr_info("clock is %d\n", mode->clock);
> #endif
> mode_dev->panel_fixed_mode = mode;
> }
> diff --git a/drivers/gpu/drm/gma500/psb_drv.h
> b/drivers/gpu/drm/gma500/psb_drv.h
> index 83e22fd4cfc0..83667087d6e5 100644
> --- a/drivers/gpu/drm/gma500/psb_drv.h
> +++ b/drivers/gpu/drm/gma500/psb_drv.h
> @@ -905,9 +905,8 @@ static inline void REGISTER_WRITE8(struct drm_device *dev,
> #define PSB_RSGX32(_offs)
Re: [PATCH RESEND] drm/via: use get_user_pages_unlocked()
On Tue, Feb 28, 2017 at 08:28:08PM +, Lorenzo Stoakes wrote: > On 28 February 2017 at 19:35, Al Viro wrote: > > On Tue, Feb 28, 2017 at 10:01:10AM +0100, Daniel Vetter wrote: > > > >> > + ret = get_user_pages_unlocked((unsigned long)xfer->mem_addr, > >> > + vsg->num_pages, vsg->pages, > >> > + (vsg->direction == DMA_FROM_DEVICE) ? FOLL_WRITE : > >> > 0); > > > > Umm... Why not > > ret = get_user_pages_fast((unsigned long)xfer->mem_addr, > > vsg->num_pages, > > vsg->direction == DMA_FROM_DEVICE, > > vsg->pages); > > > > IOW, do you really need a warranty that ->mmap_sem will be grabbed and > > released? > > Daniel will be better placed to answer in this specific case, but more > generally is there any reason why we can't just use > get_user_pages_fast() in all such cases? These patches were simply a > mechanical/cautious replacement for code that is more or less exactly > equivalent but if this would make sense perhaps it'd be worth using > gup_fast() where possible? I have no idea. drm/via is unmaintained, it's a dri1 racy driver with problems probably everywhere, and I'm not sure we even have someone left who cares (there's an out-of-tree kms conversion of via, but it's stuck since years). In short, it's the drm dungeons and the only reason I merge patches is to give people an easy target for test driving the patch submission process to dri-devel. And to avoid drm being a blocker for tree-wide refactorings. Otherwise 0 reasons to change anything here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[tip:locking/urgent] locking/refcounts: Change WARN() to WARN_ONCE()
Commit-ID: 9dcfe2c75b51f454f39c2de4756e841228865b47
Gitweb: http://git.kernel.org/tip/9dcfe2c75b51f454f39c2de4756e841228865b47
Author: Ingo Molnar
AuthorDate: Wed, 1 Mar 2017 09:25:55 +0100
Committer: Ingo Molnar
CommitDate: Wed, 1 Mar 2017 09:25:55 +0100
locking/refcounts: Change WARN() to WARN_ONCE()
Linus noticed that the new refcount.h APIs used WARN(), which would turn
into a dmesg DoS if it triggers frequently on some buggy driver.
So make sure we only warn once. These warnings are never supposed to happen,
so it's typically not a problem to lose subsequent warnings.
Suggested-by: Linus Torvalds
Cc: Peter Zijlstra (Intel)
Cc: Elena Reshetova
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/CA+55aFzbYUTZ=oqz2ygdjy0c2_n6odhtfqj6v+m5xwmdxsu...@mail.gmail.com
Signed-off-by: Ingo Molnar
---
lib/refcount.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/lib/refcount.c b/lib/refcount.c
index 1d33366..aa09ad3 100644
--- a/lib/refcount.c
+++ b/lib/refcount.c
@@ -58,7 +58,7 @@ bool refcount_add_not_zero(unsigned int i, refcount_t *r)
val = old;
}
- WARN(new == UINT_MAX, "refcount_t: saturated; leaking memory.\n");
+ WARN_ONCE(new == UINT_MAX, "refcount_t: saturated; leaking memory.\n");
return true;
}
@@ -66,7 +66,7 @@ EXPORT_SYMBOL_GPL(refcount_add_not_zero);
void refcount_add(unsigned int i, refcount_t *r)
{
- WARN(!refcount_add_not_zero(i, r), "refcount_t: addition on 0;
use-after-free.\n");
+ WARN_ONCE(!refcount_add_not_zero(i, r), "refcount_t: addition on 0;
use-after-free.\n");
}
EXPORT_SYMBOL_GPL(refcount_add);
@@ -97,7 +97,7 @@ bool refcount_inc_not_zero(refcount_t *r)
val = old;
}
- WARN(new == UINT_MAX, "refcount_t: saturated; leaking memory.\n");
+ WARN_ONCE(new == UINT_MAX, "refcount_t: saturated; leaking memory.\n");
return true;
}
@@ -111,7 +111,7 @@ EXPORT_SYMBOL_GPL(refcount_inc_not_zero);
*/
void refcount_inc(refcount_t *r)
{
- WARN(!refcount_inc_not_zero(r), "refcount_t: increment on 0;
use-after-free.\n");
+ WARN_ONCE(!refcount_inc_not_zero(r), "refcount_t: increment on 0;
use-after-free.\n");
}
EXPORT_SYMBOL_GPL(refcount_inc);
@@ -125,7 +125,7 @@ bool refcount_sub_and_test(unsigned int i, refcount_t *r)
new = val - i;
if (new > val) {
- WARN(new > val, "refcount_t: underflow;
use-after-free.\n");
+ WARN_ONCE(new > val, "refcount_t: underflow;
use-after-free.\n");
return false;
}
@@ -164,7 +164,7 @@ EXPORT_SYMBOL_GPL(refcount_dec_and_test);
void refcount_dec(refcount_t *r)
{
- WARN(refcount_dec_and_test(r), "refcount_t: decrement hit 0; leaking
memory.\n");
+ WARN_ONCE(refcount_dec_and_test(r), "refcount_t: decrement hit 0;
leaking memory.\n");
}
EXPORT_SYMBOL_GPL(refcount_dec);
@@ -204,7 +204,7 @@ bool refcount_dec_not_one(refcount_t *r)
new = val - 1;
if (new > val) {
- WARN(new > val, "refcount_t: underflow;
use-after-free.\n");
+ WARN_ONCE(new > val, "refcount_t: underflow;
use-after-free.\n");
return true;
}
Re: [tip:core/urgent] objtool: Fix __unreachable section relocation size
On March 1, 2017 12:10:59 AM PST, tip-bot for Josh Poimboeuf
wrote:
>Commit-ID: 90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5
>Gitweb:
>http://git.kernel.org/tip/90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5
>Author: Josh Poimboeuf
>AuthorDate: Wed, 1 Mar 2017 00:05:04 -0600
>Committer: Ingo Molnar
>CommitDate: Wed, 1 Mar 2017 07:38:25 +0100
>
>objtool: Fix __unreachable section relocation size
>
>Linus reported the following commit broke module loading on his laptop:
>
>d1091c7fa3d5 ("objtool: Improve detection of BUG() and other dead
>ends")
>
>It showed errors like the following:
>
> module: overflow in relocation type 10 val c02afc81
> module: 'nvme' likely not compiled with -mcmodel=kernel
>
>The problem is that the __unreachable section addresses are stored
>using
>the '.long' asm directive, which isn't big enough for .text section
>relative kernel addresses. Use '.quad' instead.
>
>Suggested-by: Linus Torvalds
>Reported-by: Linus Torvalds
>Signed-off-by: Josh Poimboeuf
>Cc: Peter Zijlstra
>Cc: Peter Zijlstra
>Cc: Thomas Gleixner
>Fixes: d1091c7fa3d5 ("objtool: Improve detection of BUG() and other
>dead ends")
>Link: http://lkml.kernel.org/r/20170301060504.oltm3iws6fmubnom@treble
>Signed-off-by: Ingo Molnar
>---
> include/linux/compiler-gcc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/include/linux/compiler-gcc.h
>b/include/linux/compiler-gcc.h
>index 76e28c2..91a77a5 100644
>--- a/include/linux/compiler-gcc.h
>+++ b/include/linux/compiler-gcc.h
>@@ -201,7 +201,7 @@
> #define annotate_unreachable() ({ \
> asm("%c0:\t\n" \
> ".pushsection __unreachable, \"a\"\t\n" \
>- ".long %c0b\t\n"\
>+ ".quad %c0b\t\n"\
> ".popsection\t\n" : : "i" (__LINE__)); \
> })
> #else
Or perhaps better use relative addresses, so:
.long foo - (.+4)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[PATCH 02/10] perf, tools, stat: Collapse identically named events
From: Andi Kleen
The uncore PMU has a lot of duplicated PMUs for different subsystems.
When expanding an uncore alias we usually end up with a large
number of identically named aliases, which makes perf stat
output difficult to read.
Automatically sum them up in perf stat, unless --no-merge is specified.
This can be default because only the uncores generally have duplicated
aliases. Other PMUs have unique names.
Before:
% perf stat --no-merge -a -e unc_c_llc_lookup.any sleep 1
Performance counter stats for 'system wide':
694,976 Bytes unc_c_llc_lookup.any
706,304 Bytes unc_c_llc_lookup.any
956,608 Bytes unc_c_llc_lookup.any
782,720 Bytes unc_c_llc_lookup.any
605,696 Bytes unc_c_llc_lookup.any
442,816 Bytes unc_c_llc_lookup.any
659,328 Bytes unc_c_llc_lookup.any
509,312 Bytes unc_c_llc_lookup.any
263,936 Bytes unc_c_llc_lookup.any
592,448 Bytes unc_c_llc_lookup.any
672,448 Bytes unc_c_llc_lookup.any
608,640 Bytes unc_c_llc_lookup.any
641,024 Bytes unc_c_llc_lookup.any
856,896 Bytes unc_c_llc_lookup.any
808,832 Bytes unc_c_llc_lookup.any
684,864 Bytes unc_c_llc_lookup.any
710,464 Bytes unc_c_llc_lookup.any
538,304 Bytes unc_c_llc_lookup.any
1.002577660 seconds time elapsed
After:
% perf stat -a -e unc_c_llc_lookup.any sleep 1
Performance counter stats for 'system wide':
2,685,120 Bytes unc_c_llc_lookup.any
1.002648032 seconds time elapsed
v2: Split collect_aliases. Rename alias flag.
v3: Make sure unsupported/not counted is always printed.
v4: Factor out callback change into separate patch.
v5: Move check for bad results here
Signed-off-by: Andi Kleen
---
tools/perf/Documentation/perf-stat.txt | 3 +++
tools/perf/builtin-stat.c | 41 ++
tools/perf/util/evsel.h| 1 +
3 files changed, 45 insertions(+)
diff --git a/tools/perf/Documentation/perf-stat.txt
b/tools/perf/Documentation/perf-stat.txt
index d96ccd4844df..320d8020bc5b 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -237,6 +237,9 @@ To interpret the results it is usually needed to know on
which
CPUs the workload runs on. If needed the CPUs can be forced using
taskset.
+--no-merge::
+Do not merge results from same PMUs.
+
EXAMPLES
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index c71916eaa255..389c8e457bf0 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -140,6 +140,7 @@ static unsigned int unit_width
= 4; /* strlen("unit") */
static boolforever = false;
static boolmetric_only = false;
static boolforce_metric_only = false;
+static boolno_merge= false;
static struct timespec ref_time;
static struct cpu_map *aggr_map;
static aggr_get_id_t aggr_get_id;
@@ -1178,12 +1179,34 @@ static void aggr_update_shadow(void)
}
}
+static void collect_all_aliases(struct perf_evsel *counter,
+ void (*cb)(struct perf_evsel *counter, void *data,
+ bool first),
+ void *data)
+{
+ struct perf_evsel *alias;
+
+ alias = list_prepare_entry(counter, &(evsel_list->entries), node);
+ list_for_each_entry_continue (alias, &evsel_list->entries, node) {
+ if (strcmp(perf_evsel__name(alias), perf_evsel__name(counter))
||
+ alias->scale != counter->scale ||
+ alias->cgrp != counter->cgrp ||
+ strcmp(alias->unit, counter->unit) ||
+ nsec_counter(alias) != nsec_counter(counter))
+ break;
+ alias->merged_stat = true;
+ cb(alias, data, false);
+ }
+}
+
static void collect_data(struct perf_evsel *counter,
void (*cb)(struct perf_evsel *counter, void *data,
bool first),
void *data)
{
cb(counter, data, true);
+ if (!no_merge)
+ collect_all_aliases(counter, cb, data);
}
struct aggr_data {
@@ -1208,6 +1231,16 @@ static void aggr_cb(struct perf_evsel *counter, void
*data, bool first)
if (first)
ad->nr++;
counts = perf_counts(counter->counts, cpu, 0);
+ /*
+* When any result is bad, make them all to give
+* consistent output in interval mode.
+*/
+ if (counts->ena == 0 || counts->run == 0 ||
+ counter->counts->scaled == -1) {
+
Re: [PATCH] refcount: add refcount_t API kernel-doc comments
* David Windsor wrote:
> This adds kernel-doc comments for the new refcount_t API.
>
> Signed-off-by: David Windsor
> ---
> include/linux/refcount.h | 19 ++
> lib/refcount.c | 95
> +++-
> 2 files changed, 105 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/refcount.h b/include/linux/refcount.h
> index 0023fee..3c02135 100644
> --- a/include/linux/refcount.h
> +++ b/include/linux/refcount.h
> @@ -6,17 +6,36 @@
> #include
> #include
>
> +/**
> + * refcount_t - variant of atomic_t specialized for reference counts
> + * @refs: atomic_t counter field
> + *
> + * The counter saturates at UINT_MAX and will not move once
> + * there. This avoids wrapping the counter and causing 'spurious'
> + * use-after-free issues.
Let's not beat around the bush:
s/issues/bugs
> +/**
> + * refcount_add - add a value to a refcount
> + * @i: the value to add to the refcount
> + * @r: the refcount
> + *
> + * Similar to atomic_add(), will saturate at UINT_MAX and WARN.
I realize you picked it up from the existing comments, but if we push this into
docbook I'd phrase it this way:
* Similar to atomic_add(), but will saturate at UINT_MAX and WARN.
(The 'but' contasts the main difference to atomic_add().)
> + */
> void refcount_add(unsigned int i, refcount_t *r)
> {
> WARN(!refcount_add_not_zero(i, r), "refcount_t: addition on 0;
> use-after-free.\n");
> }
> EXPORT_SYMBOL_GPL(refcount_add);
>
> -/*
> +/**
> + * refcount_inc_not_zero - increment a refcount unless it is 0
> + * @r: the refcount to increment
So this is slightly different from the phrasing earlier on:
+/**
+ * refcount_add_not_zero - add a value to a refcount unless the refcount is 0
+ * @i: the value to add to the refcount
+ * @r: the refcount
+ *
Please harmonize it: either use 'a refcount unless it is 0' or 'a refcount
unless
the refcount is 0' - but not a mixture of the two.
Same goes for similar occurances further below.
> + *
> * Similar to atomic_inc_not_zero(), will saturate at UINT_MAX and WARN.
This should be updated similarly as above.
> *
> * Provides no memory ordering, it is assumed the caller has guaranteed the
> * object memory to be stable (RCU, etc.). It does provide a control
> dependency
> * and thereby orders future stores. See the comment on top.
> + *
> + * Return: false if the refcount is 0, true otherwise
> */
> bool refcount_inc_not_zero(refcount_t *r)
> {
> @@ -103,11 +124,16 @@ bool refcount_inc_not_zero(refcount_t *r)
> }
> EXPORT_SYMBOL_GPL(refcount_inc_not_zero);
>
> -/*
> +/**
> + * refcount_inc - increment a refcount
> + * @r: the refcount to increment
> + *
> * Similar to atomic_inc(), will saturate at UINT_MAX and WARN.
> *
> * Provides no memory ordering, it is assumed the caller already has a
> * reference on the object, will WARN when this is not so.
> + *
> + * Will WARN if refcount is 0.
s/if refcount/if the refcount
> */
> void refcount_inc(refcount_t *r)
> {
> @@ -115,6 +141,22 @@ void refcount_inc(refcount_t *r)
> }
> EXPORT_SYMBOL_GPL(refcount_inc);
>
> +/**
> + * refcount_sub_and_test - subtract from a refcount and test if it is 0
> + * @i: amount to subtract from the refcount
> + * @r: the refcount
> + *
> + * Similar to atomic_dec_and_test(), it will WARN on underflow and fail to
> + * decrement when saturated at UINT_MAX.
I'd insert the 'but' here too to highlight differences to the atomic APIs.
> +/**
> + * refcount_dec_and_mutex_lock - return holding mutex if able to decrement
> + * refcount to 0
> + * @r: the refcount
> + * @lock: the mutex to be locked
> + *
> * Similar to atomic_dec_and_mutex_lock(), it will WARN on underflow and fail
> * to decrement when saturated at UINT_MAX.
> *
> * Provides release memory ordering, such that prior loads and stores are
> done
> * before, and provides a control dependency such that free() must come
> after.
> * See the comment on top.
> + *
> + * Return: true and hold lock if able to decrement refcount to 0, false
> + * otherwise
If we refer to a function parameter then it should be quoted as 'lock', but
what
mean here is that we'll hold the mutex:
s/lock/mutex
> */
> bool refcount_dec_and_mutex_lock(refcount_t *r, struct mutex *lock)
> {
> @@ -242,13 +311,21 @@ bool refcount_dec_and_mutex_lock(refcount_t *r, struct
> mutex *lock)
> }
> EXPORT_SYMBOL_GPL(refcount_dec_and_mutex_lock);
>
> -/*
> +/**
> + * refcount_dec_and_lock - return holding spinlock if able to decrement
> + * refcount to 0
> + * @r: the refcount
> + * @lock: the spinlock to be locked
> + *
> * Similar to atomic_dec_and_lock(), it will WARN on underflow and fail to
> * decrement when saturated at UINT_MAX.
> *
> * Provides release memory ordering, such that prior loads and stores are
> done
> * before, and provides a control dependency such that free() m
Re: [PATCH v2 1/3] mtd: nand: Cleanup/rework the atmel_nand driver
Around Wed 01 Mar 2017 09:22:24 +0100 or thereabout, Boris Brezillon wrote: > Hi Hans-Christian, > > On Fri, 24 Feb 2017 10:04:35 +0100 > Hans-Christian Noren Egtvedt wrote: > >> Around Fri 24 Feb 2017 09:55:09 +0100 or thereabout, Boris Brezillon wrote: >> > On Fri, 24 Feb 2017 09:52:09 +0100 >> > Hans-Christian Noren Egtvedt wrote: >> >> Around Fri 24 Feb 2017 09:27:42 +0100 or thereabout, Boris Brezillon >> >> wrote: >> >> > On Fri, 24 Feb 2017 09:14:30 +0100 Hans-Christian Noren Egtvedt >> >> > wrote: >> >> >> Around Thu 23 Feb 2017 21:18:13 -0800 or thereabout, Håvard Skinnemoen >> >> >> wrote: >> >> >> > On Tue, Feb 21, 2017 at 9:14 AM, Alexandre Belloni >> >> >> > wrote: >> >> >> >> On 21/02/2017 at 18:43:35 +0200, Andy Shevchenko wrote: >> >> >> >> >> >> >> >> >> >> If nobody complains about the 4.10 breakage, You'll have plenty of >> >> >> >> time >> >> >> >> to remove it for 4.12 >> >> >> > >> >> >> > I'm fine with that, but I haven't put much effort into keeping it >> >> >> > alive lately. If Hans-Christian agrees, I'm willing to post a patch >> >> >> > to >> >> >> > remove it, or ack someone else's patch. >> >> >> >> >> >> Then lets plan this for 4.12, either you Håvard whip up a patch or I >> >> >> can >> >> >> eventually do it. >> >> >> >> >> >> I can push it through the linux-avr32 git tree on kernel.org. >> >> >> >> >> > >> >> > Can you do that just after 4.11-rc1 is released and provide a topic >> >> > branch I can pull in my nand/next branch, so that I can rework this >> >> > patch and drop all the pdata-compat code (as suggested by Andy). >> >> >> >> OK, I will try to prepare it during the weekend. >> >> >> >> Any reason to wait for 4.11-rc1? AFAIK Linus prefers the larger changes >> >> before he starts tagging rc's. >> >> >> > >> > Oh, so you want to queue it for 4.11, that's even better. >> >> Perhaps I misunderstood you, by after 4.11-rc1 you mean queue it for 4.12? >> >> I will see what I get around to do in the weekend, it should be pretty >> straightforward, just want to make sure we remove all the bits. >> > > Any progress on this? I plan to send a new version of this series soon > and I'd like to know if I should drop pdata/avr32 support or not. Note > that I'm targeting 4.12, so, as long as you drop avr32 support in 4.12 > we should be good. I got around to make the patch series during the weekend, but I thought it would be a good idea sending them to the kernel mailing list as a FYI. Also, I was unsure if I should send the driver removals through the sub-maintainers trees, or if I can push them through linux-avr32 tree. I have a patch removing the pata driver for AVR32. -- mvh Hans-Christian Noren Egtvedt
[PATCH] locking/refcounts: Change WARN() to WARN_ONCE()
* Linus Torvalds wrote:
> On Mon, Feb 27, 2017 at 11:57 PM, Ingo Molnar wrote:
> >
> > Note that the uninlining allowed us to enable the underflow/overflow
> > warnings
> > unconditionally and remove the debug Kconfig switch: this might trigger new
> > warnings in buggy code and turn crashes/use-after-free bugs into less
> > harmful
> > memory leaks.
>
> I'm ok with this, but that WARN() really needs to be a WARN_ON_ONCE().
>
> Because once an underflow (or overflow) is happening, it tends to
> _keep_ happening. And you may just have essentially DoS'ed the machine
> that is now spending all its time writing those logs to disk.
>
> Yes, yes, quiet independently of this we should limit WARN printouts
> (and do the reverse: turn a "once" to mean "once in a blue moon"
> rather than actually just once), but particularly for this kind of
> "never happens" thing, it really is better to just warn once.
Good point - I've done this in the attached patch.
Thanks,
Ingo
=>
>From 9dcfe2c75b51f454f39c2de4756e841228865b47 Mon Sep 17 00:00:00 2001
From: Ingo Molnar
Date: Wed, 1 Mar 2017 09:25:55 +0100
Subject: [PATCH] locking/refcounts: Change WARN() to WARN_ONCE()
Linus noticed that the new refcount.h APIs used WARN(), which would turn
into a dmesg DoS if it triggers frequently on some buggy driver.
So make sure we only warn once. These warnings are never supposed to happen,
so it's typically not a problem to lose subsequent warnings.
Suggested-by: Linus Torvalds
Cc: Peter Zijlstra (Intel)
Cc: Elena Reshetova
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/CA+55aFzbYUTZ=oqz2ygdjy0c2_n6odhtfqj6v+m5xwmdxsu...@mail.gmail.com
Signed-off-by: Ingo Molnar
---
lib/refcount.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/lib/refcount.c b/lib/refcount.c
index 1d33366189d1..aa09ad3c30b0 100644
--- a/lib/refcount.c
+++ b/lib/refcount.c
@@ -58,7 +58,7 @@ bool refcount_add_not_zero(unsigned int i, refcount_t *r)
val = old;
}
- WARN(new == UINT_MAX, "refcount_t: saturated; leaking memory.\n");
+ WARN_ONCE(new == UINT_MAX, "refcount_t: saturated; leaking memory.\n");
return true;
}
@@ -66,7 +66,7 @@ EXPORT_SYMBOL_GPL(refcount_add_not_zero);
void refcount_add(unsigned int i, refcount_t *r)
{
- WARN(!refcount_add_not_zero(i, r), "refcount_t: addition on 0;
use-after-free.\n");
+ WARN_ONCE(!refcount_add_not_zero(i, r), "refcount_t: addition on 0;
use-after-free.\n");
}
EXPORT_SYMBOL_GPL(refcount_add);
@@ -97,7 +97,7 @@ bool refcount_inc_not_zero(refcount_t *r)
val = old;
}
- WARN(new == UINT_MAX, "refcount_t: saturated; leaking memory.\n");
+ WARN_ONCE(new == UINT_MAX, "refcount_t: saturated; leaking memory.\n");
return true;
}
@@ -111,7 +111,7 @@ EXPORT_SYMBOL_GPL(refcount_inc_not_zero);
*/
void refcount_inc(refcount_t *r)
{
- WARN(!refcount_inc_not_zero(r), "refcount_t: increment on 0;
use-after-free.\n");
+ WARN_ONCE(!refcount_inc_not_zero(r), "refcount_t: increment on 0;
use-after-free.\n");
}
EXPORT_SYMBOL_GPL(refcount_inc);
@@ -125,7 +125,7 @@ bool refcount_sub_and_test(unsigned int i, refcount_t *r)
new = val - i;
if (new > val) {
- WARN(new > val, "refcount_t: underflow;
use-after-free.\n");
+ WARN_ONCE(new > val, "refcount_t: underflow;
use-after-free.\n");
return false;
}
@@ -164,7 +164,7 @@ EXPORT_SYMBOL_GPL(refcount_dec_and_test);
void refcount_dec(refcount_t *r)
{
- WARN(refcount_dec_and_test(r), "refcount_t: decrement hit 0; leaking
memory.\n");
+ WARN_ONCE(refcount_dec_and_test(r), "refcount_t: decrement hit 0;
leaking memory.\n");
}
EXPORT_SYMBOL_GPL(refcount_dec);
@@ -204,7 +204,7 @@ bool refcount_dec_not_one(refcount_t *r)
new = val - 1;
if (new > val) {
- WARN(new > val, "refcount_t: underflow;
use-after-free.\n");
+ WARN_ONCE(new > val, "refcount_t: underflow;
use-after-free.\n");
return true;
}
Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt
On Tue, Feb 28, 2017 at 11:05 PM, Milan Broz wrote: > > On 02/22/2017 07:12 AM, Binoy Jayan wrote: > > > > I was wondering if this is near to be ready for submission (apart from > > the testmgr.c > > changes) or I need to make some changes to make it similar to the IPSec > > offload? > > I just tried this and except it registers the IV for every new device again, > it works... > (After a while you have many duplicate entries in /proc/crypto.) > > But I would like to see some summary why such a big patch is needed in the > first place. > (During an internal discussions seems that people are already lost in mails > and > patches here, so Ondra promised me to send some summary mail soon here.) > > IIRC the first initial problem was dmcrypt performance on some embedded > crypto processors that are not able to cope with small crypto requests > effectively. > > > Do you have some real performance numbers that proves that such a patch is > adequate? > > I would really like to see the performance issue fixed but I am really not > sure > this approach works for everyone. It would be better to avoid repeating this > exercise later. > IIRC Ondra's "bulk" mode, despite rejected, shows that there is a potential > to speedup things even for crypt drivers that do not support own IV > generators. > AFAIK the problem that we are trying to solve is that if the IV is generated outside the crypto API domain than you are forced to have an invocation of the crypto API per each block because you need to provide the IV for each block. By putting the IV generation responsibility in the Crypto API we open the way to do a single invocation of the crypto API for a whole sequence of blocks. For software implementation of XTS this doesn't matter much - but for hardware based XTS providers that can do the IV generation themselves it's the difference between a sequence of small invocation, with all the overhead that that entails and a single big invocatio - and this can be big. This lead some vendors to ship hacked up versions of dm-crypt to match the specific crypto hardware they were using, or so I've heard at least - didn't see the code myself. I believe Binoy is trying to address this in a generic upstream worthy way instead. Anyway, you are only supposed to see s difference when using a hardware based XTS provider algo that supports IV generation. > I like the patch is now contained inside dmcrypt, but it still exposes IVs > that > are designed just for old, insecure, compatibility-only containers. > > I really do not think every compatible crap must be accessible through crypto > API. > (I wrote the dmcrypt lrw and tcw compatibility IVs and I would never do that > this way > if I know it is accessible outside of dmcrypt internals...) > Even the ESSIV is something that was born to fix predictive IVs (CBC > watermarking > attacks) for disk encryption only, no reason to expose it outside of disk > encryption. > The point is that you have more than one implementation of these "compatible crap" - the software implementation that you wrote and potentially multiple hardware implementations and putting this in the crypto API domain is the way to abstract this so you use the one that works best of your platform. Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
[PATCH] bpf: update the comment about the length of analysis
Commit 07016151a446 ("bpf, verifier: further improve search
pruning") increased the limit of processed instructions from
32k to 64k, but the comment still mentioned the 32k limit.
This commit updates the comment to reflect the change.
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Signed-off-by: Gary Lin
---
kernel/bpf/verifier.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index cdc43b899f28..0960f65c6da7 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -33,7 +33,7 @@
* - out of bounds or malformed jumps
* The second pass is all possible path descent from the 1st insn.
* Since it's analyzing all pathes through the program, the length of the
- * analysis is limited to 32k insn, which may be hit even if total number of
+ * analysis is limited to 64k insn, which may be hit even if total number of
* insn is less then 4K, but there are too many branches that change
stack/regs.
* Number of 'branches to be analyzed' is limited to 1k
*
--
2.12.0
[PATCH 06/10] perf, tools: Add a simple expression parser for JSON
From: Andi Kleen
Add a simple expression parser good enough to parse JSON relation
expressions. The parser is implemented using bison.
This is just intended as an simple parser for internal usage
in the event lists, not the beginning of a "perf scripting language"
v2: Use expr__ prefix instead of expr_
Support multiple free variables for parser
Signed-off-by: Andi Kleen
---
tools/perf/tests/Build | 1 +
tools/perf/tests/builtin-test.c | 4 +
tools/perf/tests/expr.c | 55 +
tools/perf/tests/tests.h| 1 +
tools/perf/util/Build | 5 ++
tools/perf/util/expr.h | 25 ++
tools/perf/util/expr.y | 173
7 files changed, 264 insertions(+)
create mode 100644 tools/perf/tests/expr.c
create mode 100644 tools/perf/util/expr.h
create mode 100644 tools/perf/util/expr.y
diff --git a/tools/perf/tests/Build b/tools/perf/tests/Build
index 1cb3d9b540e9..af58ebc243ef 100644
--- a/tools/perf/tests/Build
+++ b/tools/perf/tests/Build
@@ -38,6 +38,7 @@ perf-y += cpumap.o
perf-y += stat.o
perf-y += event_update.o
perf-y += event-times.o
+perf-y += expr.o
perf-y += backward-ring-buffer.o
perf-y += sdt.o
perf-y += is_printable_array.o
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index 37e326bfd2dc..db03e853ba7f 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -44,6 +44,10 @@ static struct test generic_tests[] = {
.func = test__parse_events,
},
{
+ .desc = "Simple expression parser",
+ .func = test__expr,
+ },
+ {
.desc = "PERF_RECORD_* events & perf_sample fields",
.func = test__PERF_RECORD,
},
diff --git a/tools/perf/tests/expr.c b/tools/perf/tests/expr.c
new file mode 100644
index ..554695c06c5b
--- /dev/null
+++ b/tools/perf/tests/expr.c
@@ -0,0 +1,55 @@
+#include "util/debug.h"
+#include "util/expr.h"
+#include "tests.h"
+
+static int test(struct parse_ctx *ctx, const char *e, double val2)
+{
+ double val;
+
+ if (expr__parse(&val, ctx, &e))
+ TEST_ASSERT_VAL("parse test failed", 0);
+ TEST_ASSERT_VAL("unexpected value", val == val2);
+ return 0;
+}
+
+int test__expr(int subtest __maybe_unused)
+{
+ const char *p;
+ const char **other;
+ double val;
+ int ret;
+ struct parse_ctx ctx;
+ int num_other;
+
+ expr__ctx_init(&ctx);
+ expr__add_id(&ctx, "FOO", 1);
+ expr__add_id(&ctx, "BAR", 2);
+
+ ret = test(&ctx, "1+1", 2);
+ ret |= test(&ctx, "FOO+BAR", 3);
+ ret |= test(&ctx, "(BAR/2)%2", 1);
+ ret |= test(&ctx, "1 - -4", 5);
+ ret |= test(&ctx, "(FOO-1)*2 + (BAR/2)%2 - -4", 5);
+
+ if (ret)
+ return ret;
+
+ p = "FOO/0";
+ ret = expr__parse(&val, &ctx, &p);
+ TEST_ASSERT_VAL("division by zero", ret == 1);
+
+ p = "BAR/";
+ ret = expr__parse(&val, &ctx, &p);
+ TEST_ASSERT_VAL("missing operand", ret == 1);
+
+ TEST_ASSERT_VAL("find other",
+ expr__find_other("FOO + BAR + BAZ + BOZO", "FOO",
&other, &num_other) == 0);
+ TEST_ASSERT_VAL("find other", num_other == 3);
+ TEST_ASSERT_VAL("find other", !strcmp(other[0], "BAR"));
+ TEST_ASSERT_VAL("find other", !strcmp(other[1], "BAZ"));
+ TEST_ASSERT_VAL("find other", !strcmp(other[2], "BOZO"));
+ TEST_ASSERT_VAL("find other", other[3] == NULL);
+ free((void *)other);
+
+ return 0;
+}
diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
index 1fa9b9d83aa5..631859629403 100644
--- a/tools/perf/tests/tests.h
+++ b/tools/perf/tests/tests.h
@@ -62,6 +62,7 @@ int test__sample_parsing(int subtest);
int test__keep_tracking(int subtest);
int test__parse_no_sample_id_all(int subtest);
int test__dwarf_unwind(int subtest);
+int test__expr(int subtest);
int test__hists_filter(int subtest);
int test__mmap_thread_lookup(int subtest);
int test__thread_mg_share(int subtest);
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 5da376bc1afc..3dff5f5960d9 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -88,6 +88,7 @@ libperf-y += mem-events.o
libperf-y += vsprintf.o
libperf-y += drv_configs.o
libperf-y += time-utils.o
+libperf-y += expr-bison.o
libperf-$(CONFIG_LIBBPF) += bpf-loader.o
libperf-$(CONFIG_BPF_PROLOGUE) += bpf-prologue.o
@@ -140,6 +141,10 @@ $(OUTPUT)util/parse-events-bison.c: util/parse-events.y
$(call rule_mkdir)
$(Q)$(call echo-cmd,bison)$(BISON) -v util/parse-events.y -d
$(PARSER_DEBUG_BISON) -o $@ -p parse_events_
+$(OUTPUT)util/expr-bison.c: util/expr.y
+ $(call rule_mkdir)
+ $(Q)$(call echo-cmd,bison)$(BISON) -v util/expr.y -d
$(PARSER_DEBUG_BISON) -o $@ -p expr__
+
$(OUTPUT)util/pmu-flex.c: util/pmu.l $(OUTPUT)util/pmu-bison.c
[PATCH] PCI/aspm: Fix link->downstream setting
~ # echo 1 > /sys/bus/pci/devices/\:0b\:00.0/remove
...
BUG: unable to handle kernel NULL pointer dereference at 0080
IP: pcie_config_aspm_link+0x5d/0x2b0
Call Trace:
pcie_aspm_exit_link_state+0x75/0x130
pci_stop_bus_device+0xa4/0xb0
pci_stop_and_remove_bus_device_locked+0x1a/0x30
remove_store+0x50/0x70
dev_attr_store+0x18/0x30
sysfs_kf_write+0x44/0x60
kernfs_fop_write+0x10e/0x190
__vfs_write+0x28/0x110
? rcu_read_lock_sched_held+0x5d/0x80
? rcu_sync_lockdep_assert+0x2c/0x60
? __sb_start_write+0x173/0x1a0
? vfs_write+0xb3/0x180
vfs_write+0xc4/0x180
SyS_write+0x49/0xa0
do_syscall_64+0xa6/0x1c0
entry_SYSCALL64_slow_path+0x25/0x25
---[ end trace bd187ee0267df5d9 ]---
set downstream even with blacklist path.
Signed-off-by: Yinghai Lu
---
drivers/pci/pcie/aspm.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Index: linux-2.6/drivers/pci/pcie/aspm.c
===
--- linux-2.6.orig/drivers/pci/pcie/aspm.c
+++ linux-2.6/drivers/pci/pcie/aspm.c
@@ -478,7 +478,7 @@ static void aspm_calc_l1ss_info(struct p
static void pcie_aspm_cap_init(struct pcie_link_state *link, int blacklist)
{
- struct pci_dev *child, *parent = link->pdev;
+ struct pci_dev *child = link->downstream, *parent = link->pdev;
struct pci_bus *linkbus = parent->subordinate;
struct aspm_register_info upreg, dwreg;
@@ -491,9 +491,7 @@ static void pcie_aspm_cap_init(struct pc
/* Get upstream/downstream components' register state */
pcie_get_aspm_reg(parent, &upreg);
- child = pci_function_0(linkbus);
pcie_get_aspm_reg(child, &dwreg);
- link->downstream = child;
/*
* If ASPM not supported, don't mess with the clocks and link,
@@ -800,6 +798,7 @@ static struct pcie_link_state *alloc_pci
INIT_LIST_HEAD(&link->children);
INIT_LIST_HEAD(&link->link);
link->pdev = pdev;
+ link->downstream = pci_function_0(pdev->subordinate);
/*
* Root Ports and PCI/PCI-X to PCIe Bridges are roots of PCIe
Re: rsync: page allocation stalls in kernel 4.9.10 to a VessRAID NAS
On Tue 28-02-17 14:32:18, Robert Kudyba wrote:
>
> > On Feb 28, 2017, at 11:56 AM, Michal Hocko wrote:
[...]
> >> Will do here’s a perf report:
> >
> > this will not tell us much. Tracepoints have much better chance to tell
> > us how reclaim is progressing.
>
> I have SystemTap configured are there any scripts in the
> SystemTap_Beginners_Guide.pdf that I can run to help? Sorry I’m
> brand new to tracepoints.
>
I am not familiar with systemtap much. What I meant was to
mount -t tracefs none /trace
echo 1 > /trace/events/vmscan/enable
but
> I do see these “vmscan” from this command:
> stap -L 'kernel.trace("*")'|sort
>
> kernel.trace("vmscan:mm_shrink_slab_end") $shr:struct shrinker* $nid:int
> $shrinker_retval:int $unused_scan_cnt:long int $new_scan_cnt:long int
> $total_scan:long int
> kernel.trace("vmscan:mm_shrink_slab_start") $shr:struct shrinker* $sc:struct
> shrink_control* $nr_objects_to_shrink:long int $pgs_scanned:long unsigned int
> $lru_pgs:long unsigned int $cache_items:long unsigned int $delta:long long
> unsigned int $total_scan:long unsigned int
> kernel.trace("vmscan:mm_vmscan_direct_reclaim_begin") $order:int
> $may_writepage:int $gfp_flags:gfp_t $classzone_idx:int
> kernel.trace("vmscan:mm_vmscan_direct_reclaim_end") $nr_reclaimed:long
> unsigned int
> kernel.trace("vmscan:mm_vmscan_kswapd_sleep") $nid:int
> kernel.trace("vmscan:mm_vmscan_kswapd_wake") $nid:int $zid:int $order:int
> kernel.trace("vmscan:mm_vmscan_lru_isolate") $classzone_idx:int $order:int
> $nr_requested:long unsigned int $nr_scanned:long unsigned int $nr_taken:long
> unsigned int $isolate_mode:isolate_mode_t $file:int
> kernel.trace("vmscan:mm_vmscan_lru_shrink_inactive") $nid:int
> $nr_scanned:long unsigned int $nr_reclaimed:long unsigned int $priority:int
> $file:int
> kernel.trace("vmscan:mm_vmscan_memcg_isolate") $classzone_idx:int $order:int
> $nr_requested:long unsigned int $nr_scanned:long unsigned int $nr_taken:long
> unsigned int $isolate_mode:isolate_mode_t $file:int
> kernel.trace("vmscan:mm_vmscan_memcg_reclaim_begin") $order:int
> $may_writepage:int $gfp_flags:gfp_t $classzone_idx:int
> kernel.trace("vmscan:mm_vmscan_memcg_reclaim_end") $nr_reclaimed:long
> unsigned int
> kernel.trace("vmscan:mm_vmscan_memcg_softlimit_reclaim_begin") $order:int
> $may_writepage:int $gfp_flags:gfp_t $classzone_idx:int
> kernel.trace("vmscan:mm_vmscan_memcg_softlimit_reclaim_end")
> $nr_reclaimed:long unsigned int
> kernel.trace("vmscan:mm_vmscan_wakeup_kswapd") $nid:int $zid:int $order:int
> kernel.trace("vmscan:mm_vmscan_writepage") $page:struct page*
this looks like it would achieve the same
--
Michal Hocko
SUSE Labs
[PATCH 09/44] tools/power turbostat: use new name for MSR_PKG_CST_CONFIG_CONTROL
From: Len Brown
Previously called MSR_NHM_SNB_PKG_CST_CFG_CTL
Signed-off-by: Len Brown
---
tools/power/x86/turbostat/turbostat.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/power/x86/turbostat/turbostat.c
b/tools/power/x86/turbostat/turbostat.c
index aedfaddbad30..d56f2b75dc58 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -1761,12 +1761,12 @@ dump_nhm_cst_cfg(void)
{
unsigned long long msr;
- get_msr(base_cpu, MSR_NHM_SNB_PKG_CST_CFG_CTL, &msr);
+ get_msr(base_cpu, MSR_PKG_CST_CONFIG_CONTROL, &msr);
#define SNB_C1_AUTO_UNDEMOTE (1UL << 27)
#define SNB_C3_AUTO_UNDEMOTE (1UL << 28)
- fprintf(outf, "cpu%d: MSR_NHM_SNB_PKG_CST_CFG_CTL: 0x%08llx", base_cpu,
msr);
+ fprintf(outf, "cpu%d: MSR_PKG_CST_CONFIG_CONTROL: 0x%08llx", base_cpu,
msr);
fprintf(outf, " (%s%s%s%s%slocked: pkg-cstate-limit=%d: %s)\n",
(msr & SNB_C3_AUTO_UNDEMOTE) ? "UNdemote-C3, " : "",
@@ -2383,7 +2383,7 @@ void check_permissions()
* MSR_SMI_COUNT 0x0034
*
* MSR_PLATFORM_INFO 0x00ce
- * MSR_NHM_SNB_PKG_CST_CFG_CTL 0x00e2
+ * MSR_PKG_CST_CONFIG_CONTROL 0x00e2
*
* MSR_MISC_PWR_MGMT 0x01aa
*
@@ -2393,7 +2393,7 @@ void check_permissions()
* MSR_CORE_C6_RESIDENCY 0x03fd
*
* Side effect:
- * sets global pkg_cstate_limit to decode MSR_NHM_SNB_PKG_CST_CFG_CTL
+ * sets global pkg_cstate_limit to decode MSR_PKG_CST_CONFIG_CONTROL
*/
int probe_nhm_msrs(unsigned int family, unsigned int model)
{
@@ -2462,7 +2462,7 @@ int probe_nhm_msrs(unsigned int family, unsigned int
model)
default:
return 0;
}
- get_msr(base_cpu, MSR_NHM_SNB_PKG_CST_CFG_CTL, &msr);
+ get_msr(base_cpu, MSR_PKG_CST_CONFIG_CONTROL, &msr);
pkg_cstate_limit = pkg_cstate_limits[msr & 0xF];
get_msr(base_cpu, MSR_PLATFORM_INFO, &msr);
--
2.11.0.161.g6610af872
Re: [PATCH 1/1] dma: imx-sdma: add 1ms delay to ensure SDMA channel is stopped
Hello Vinod
On 02/13/2017 07:22 PM, Vinod Koul wrote:
On Mon, Feb 13, 2017 at 03:30:19PM +0900, Jiada Wang wrote:
+static int sdma_disable_channel_with_delay(struct dma_chan *chan)
+{
+ sdma_disable_channel(chan);
+ mdelay(1);
what is the gaurantee that 1ms is fine? Shouldn't you poll the bit to see
channel is disabled properly..
I got the information from NXP (freescale) R&D team,
according to them, by write '1' to SDMA_H_STATSTOP, only disables
the related sdma channel (so poll HE bit will indicates the channel
has been disabled),
but it cannot ensure SDMA core stop to access modules' FIFO,
SDMA core may still is running, this is a bug in HW.
Okay b ut you are not doing the HE bit here..??
by calling sdma_disable_channel(chan) here, sdma driver clears
corresponding HE bit, thus disables the channel. But it can't ensure
SDMA core is stopped by this operation.
regarding if the '1ms' is enough to ensure SDMA core has stopped,
NXP R&D team mentioned:
"we should add some delay of one BD SDMA cost time after disable the
channel bit, the maximum is 1ms"
so I assume 1ms should work for all cases
At least please document this in changelog and comments in code.
I will update my patch to add comments once all concerns are addressed.
Thanks,
Jiada
[tip:core/urgent] objtool: Fix __unreachable section relocation size
Commit-ID: 90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5
Gitweb: http://git.kernel.org/tip/90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5
Author: Josh Poimboeuf
AuthorDate: Wed, 1 Mar 2017 00:05:04 -0600
Committer: Ingo Molnar
CommitDate: Wed, 1 Mar 2017 07:38:25 +0100
objtool: Fix __unreachable section relocation size
Linus reported the following commit broke module loading on his laptop:
d1091c7fa3d5 ("objtool: Improve detection of BUG() and other dead ends")
It showed errors like the following:
module: overflow in relocation type 10 val c02afc81
module: 'nvme' likely not compiled with -mcmodel=kernel
The problem is that the __unreachable section addresses are stored using
the '.long' asm directive, which isn't big enough for .text section
relative kernel addresses. Use '.quad' instead.
Suggested-by: Linus Torvalds
Reported-by: Linus Torvalds
Signed-off-by: Josh Poimboeuf
Cc: Peter Zijlstra
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Fixes: d1091c7fa3d5 ("objtool: Improve detection of BUG() and other dead ends")
Link: http://lkml.kernel.org/r/20170301060504.oltm3iws6fmubnom@treble
Signed-off-by: Ingo Molnar
---
include/linux/compiler-gcc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 76e28c2..91a77a5 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -201,7 +201,7 @@
#define annotate_unreachable() ({ \
asm("%c0:\t\n" \
".pushsection __unreachable, \"a\"\t\n" \
- ".long %c0b\t\n"\
+ ".quad %c0b\t\n"\
".popsection\t\n" : : "i" (__LINE__)); \
})
#else
[PATCH v2 4/4] platform/x86: fujitsu-laptop: cleanup error labels in fujitsu_init()
Error labels currently used in fujitsu_init() are really hard to follow:
some (fail_laptop) indicate which operation has failed, others
(fail_sysfs_group) indicate where unrolling should start and the rest
(fail_platform_driver) is simply confusing. Change them to follow the
pattern used throughout the rest of the module, i.e. make every label
indicate the first unrolling operation it leads to.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index 4fc14fbcfa8a..848725d90c8e 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -1241,60 +1241,60 @@ static int __init fujitsu_init(void)
ret = acpi_bus_register_driver(&acpi_fujitsu_bl_driver);
if (ret)
- goto fail_acpi;
+ goto err_free_fujitsu_bl;
/* Register platform stuff */
fujitsu_bl->pf_device = platform_device_alloc("fujitsu-laptop", -1);
if (!fujitsu_bl->pf_device) {
ret = -ENOMEM;
- goto fail_platform_driver;
+ goto err_unregister_acpi;
}
ret = platform_device_add(fujitsu_bl->pf_device);
if (ret)
- goto fail_platform_device1;
+ goto err_put_platform_device;
ret =
sysfs_create_group(&fujitsu_bl->pf_device->dev.kobj,
&fujitsu_pf_attribute_group);
if (ret)
- goto fail_platform_device2;
+ goto err_del_platform_device;
ret = platform_driver_register(&fujitsu_pf_driver);
if (ret)
- goto fail_sysfs_group;
+ goto err_remove_sysfs_group;
/* Register laptop driver */
fujitsu_laptop = kzalloc(sizeof(struct fujitsu_laptop), GFP_KERNEL);
if (!fujitsu_laptop) {
ret = -ENOMEM;
- goto fail_laptop;
+ goto err_unregister_platform_driver;
}
ret = acpi_bus_register_driver(&acpi_fujitsu_laptop_driver);
if (ret)
- goto fail_laptop1;
+ goto err_free_fujitsu_laptop;
pr_info("driver " FUJITSU_DRIVER_VERSION " successfully loaded\n");
return 0;
-fail_laptop1:
+err_free_fujitsu_laptop:
kfree(fujitsu_laptop);
-fail_laptop:
+err_unregister_platform_driver:
platform_driver_unregister(&fujitsu_pf_driver);
-fail_sysfs_group:
+err_remove_sysfs_group:
sysfs_remove_group(&fujitsu_bl->pf_device->dev.kobj,
&fujitsu_pf_attribute_group);
-fail_platform_device2:
+err_del_platform_device:
platform_device_del(fujitsu_bl->pf_device);
-fail_platform_device1:
+err_put_platform_device:
platform_device_put(fujitsu_bl->pf_device);
-fail_platform_driver:
+err_unregister_acpi:
acpi_bus_unregister_driver(&acpi_fujitsu_bl_driver);
-fail_acpi:
+err_free_fujitsu_bl:
kfree(fujitsu_bl);
return ret;
--
2.12.0
Re: [PATCH v2] mtd: Fix mtdblock for >4GB MTD devices
If checking some calling side, the len is from cache_size of struct mtdblk_dev, it's defined as unsigned int now. So it's not 64bit yet. BTW, seems it's just block size (512) at some other calling side. (Sorry for previous same content email, just found out it's html format and rejected by mail list) On Mon, Feb 27, 2017 at 1:31 AM, Marek Vasut wrote: > On 02/22/2017 03:15 AM, Lepton Wu wrote: >> Change to use loff_t instead of unsigned long in some functions >> to make sure mtdblock can handle offset bigger than 4G in 32 bits mode. >> >> Signed-off-by: Lepton Wu >> --- >> Changes in v2: >> - Make the commit message more clearer and fix some format issues. >> >> drivers/mtd/mtdblock.c| 35 ++- >> drivers/mtd/mtdblock_ro.c | 4 ++-- >> 2 files changed, 20 insertions(+), 19 deletions(-) >> >> diff --git a/drivers/mtd/mtdblock.c b/drivers/mtd/mtdblock.c >> index bb4c14f83c75..373c0edca803 100644 >> --- a/drivers/mtd/mtdblock.c >> +++ b/drivers/mtd/mtdblock.c >> @@ -61,8 +61,8 @@ static void erase_callback(struct erase_info *done) >> wake_up(wait_q); >> } >> >> -static int erase_write (struct mtd_info *mtd, unsigned long pos, >> - int len, const char *buf) >> +static int erase_write(struct mtd_info *mtd, loff_t pos, int len, >> +const char *buf) > > Can the length be 64bit too now ? > > [...] > > -- > Best regards, > Marek Vasut
[PATCH v2 3/4] platform/x86: fujitsu-laptop: only register backlight device if FUJ02B1 is present
As the backlight device registered by fujitsu-laptop relies on the
FUJ02B1 ACPI device being present, only register the backlight device
once that ACPI device is detected.
Suggested-by: Alan Jenkins
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index afcc451e21f6..4fc14fbcfa8a 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -787,6 +787,12 @@ static int acpi_fujitsu_bl_add(struct acpi_device *device)
fujitsu_bl->max_brightness = FUJITSU_LCD_N_LEVELS;
get_lcd_level();
+ if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
+ error = fujitsu_backlight_register();
+ if (error)
+ goto err_unregister_input_dev;
+ }
+
return 0;
err_unregister_input_dev:
@@ -803,6 +809,7 @@ static int acpi_fujitsu_bl_remove(struct acpi_device
*device)
struct fujitsu_bl *fujitsu_bl = acpi_driver_data(device);
struct input_dev *input = fujitsu_bl->input;
+ backlight_device_unregister(fujitsu_bl->bl_device);
input_unregister_device(input);
fujitsu_bl->acpi_handle = NULL;
@@ -1254,17 +1261,9 @@ static int __init fujitsu_init(void)
if (ret)
goto fail_platform_device2;
- /* Register backlight stuff */
-
- if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
- ret = fujitsu_backlight_register();
- if (ret)
- goto fail_sysfs_group;
- }
-
ret = platform_driver_register(&fujitsu_pf_driver);
if (ret)
- goto fail_backlight;
+ goto fail_sysfs_group;
/* Register laptop driver */
@@ -1286,8 +1285,6 @@ static int __init fujitsu_init(void)
kfree(fujitsu_laptop);
fail_laptop:
platform_driver_unregister(&fujitsu_pf_driver);
-fail_backlight:
- backlight_device_unregister(fujitsu_bl->bl_device);
fail_sysfs_group:
sysfs_remove_group(&fujitsu_bl->pf_device->dev.kobj,
&fujitsu_pf_attribute_group);
@@ -1311,8 +1308,6 @@ static void __exit fujitsu_cleanup(void)
platform_driver_unregister(&fujitsu_pf_driver);
- backlight_device_unregister(fujitsu_bl->bl_device);
-
sysfs_remove_group(&fujitsu_bl->pf_device->dev.kobj,
&fujitsu_pf_attribute_group);
--
2.12.0
[PATCH v2 2/4] platform/x86: fujitsu-laptop: do not use call_fext_func() for LCD blanking
fujitsu-laptop registers two ACPI drivers: one for ACPI device FUJ02B1
enabling backlight control and another for ACPI device FUJ02E3 which
handles various other stuff (hotkeys, LEDs, etc.) Sadly, one of the
functions exposed by call_fext_func() (i.e. through FUJ02E3) allows
probing and controlling LCD blanking (which is a backlight-related
feature that should logically be handled by FUJ02B1) and thus entangles
these two ACPI drivers, which is ugly.
Reverse engineering the DSDT table of a Lifebook S7020 shows that
current LCD blanking state can be:
- read from ACPI variable BLCT (0: LCD on, 1: LCD off),
- set using ACPI method SBLC belonging to ACPI device FUJ02E3.
Based on this information, reimplement LCD blanking without using
call_fext_func():
- read backlight power from BLCT in fujitsu_backlight_register(),
- grab a handle to SBLC in fujitsu_backlight_register() and then use
it for setting backlight power in bl_update_status().
Apart from untangling the two ACPI drivers, this also prevents bogus
"Unable to adjust backlight power" messages from appearing on machines
which do not support LCD blanking through FUJ02E3.
Finally, this change eliminates the need to define and use
FUNC_BACKLIGHT, so remove it.
Signed-off-by: Michał Kępień
---
Jonathan, this *really* needs testing on relevant hardware. After
applying this patch, you should be able to turn LCD backlight on and off
using /sys/class/backlight/fujitsu-laptop/bl_power. Also, the value
returned by that attribute upon read should be in sync with actual
backlight state even right after loading the module (i.e. before writing
anything to bl_power). Please let me know if any of the above is not
true and the module works correctly without this patch applied.
drivers/platform/x86/fujitsu-laptop.c | 32 +++-
1 file changed, 15 insertions(+), 17 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index 185c929898d9..afcc451e21f6 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -92,7 +92,6 @@
#define FUNC_FLAGS 0x1000
#define FUNC_LEDS 0x1001
#define FUNC_BUTTONS 0x1002
-#define FUNC_BACKLIGHT 0x1004
/* FUNC interface - responses */
#define UNSUPPORTED_CMD 0x8000
@@ -143,6 +142,7 @@
/* Device controlling the backlight and associated keys */
struct fujitsu_bl {
acpi_handle acpi_handle;
+ acpi_handle blank_handle;
struct acpi_device *dev;
struct input_dev *input;
char phys[32];
@@ -463,15 +463,12 @@ static int bl_get_brightness(struct backlight_device *b)
static int bl_update_status(struct backlight_device *b)
{
+ bool blank = b->props.power == FB_BLANK_POWERDOWN;
int ret;
- if (b->props.power == FB_BLANK_POWERDOWN)
- ret = call_fext_func(FUNC_BACKLIGHT, 0x1, 0x4, 0x3);
- else
- ret = call_fext_func(FUNC_BACKLIGHT, 0x1, 0x4, 0x0);
- if (ret != 0)
- vdbg_printk(FUJLAPTOP_DBG_ERROR,
- "Unable to adjust backlight power, error code %i\n",
- ret);
+
+ if (fujitsu_bl->blank_handle)
+ acpi_execute_simple_method(fujitsu_bl->blank_handle, NULL,
+ blank);
if (use_alt_lcd_levels)
ret = set_lcd_level_alt(b->props.brightness);
@@ -693,6 +690,15 @@ static int fujitsu_backlight_register(void)
.type = BACKLIGHT_PLATFORM
};
struct backlight_device *bd;
+ unsigned long long blank;
+ acpi_status status;
+
+ /* Sync backlight power status */
+ status = acpi_evaluate_integer(NULL, "\\BLCT", NULL, &blank);
+ if (ACPI_SUCCESS(status) && blank)
+ props.power = FB_BLANK_POWERDOWN;
+
+ acpi_get_handle(NULL, "\\_SB.FEXT.SBLC", &fujitsu_bl->blank_handle);
bd = backlight_device_register(KBUILD_MODNAME, NULL, NULL,
&fujitsu_bl_ops, &props);
@@ -1272,14 +1278,6 @@ static int __init fujitsu_init(void)
if (ret)
goto fail_laptop1;
- /* Sync backlight power status (needs FUJ02E3 device, hence deferred) */
- if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
- if (call_fext_func(FUNC_BACKLIGHT, 0x2, 0x4, 0x0) == 3)
- fujitsu_bl->bl_device->props.power = FB_BLANK_POWERDOWN;
- else
- fujitsu_bl->bl_device->props.power = FB_BLANK_UNBLANK;
- }
-
pr_info("driver " FUJITSU_DRIVER_VERSION " successfully loaded\n");
return 0;
--
2.12.0
[PATCH v2 1/4] platform/x86: fujitsu-laptop: register backlight device in a separate function
Move code responsible for backlight device registration to a separate
function in order to simplify error handling and decrease indentation.
Simplify initialization of struct backlight_properties. Use
KBUILD_MODNAME as device name to avoid repeating the same string literal
throughout the module.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 38 ---
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index e12cc3504d48..185c929898d9 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -685,6 +685,25 @@ static const struct dmi_system_id fujitsu_dmi_table[]
__initconst = {
/* ACPI device for LCD brightness control */
+static int fujitsu_backlight_register(void)
+{
+ struct backlight_properties props = {
+ .brightness = fujitsu_bl->brightness_level,
+ .max_brightness = fujitsu_bl->max_brightness - 1,
+ .type = BACKLIGHT_PLATFORM
+ };
+ struct backlight_device *bd;
+
+ bd = backlight_device_register(KBUILD_MODNAME, NULL, NULL,
+ &fujitsu_bl_ops, &props);
+ if (IS_ERR(bd))
+ return PTR_ERR(bd);
+
+ fujitsu_bl->bl_device = bd;
+
+ return 0;
+}
+
static int acpi_fujitsu_bl_add(struct acpi_device *device)
{
int state = 0;
@@ -1192,7 +1211,7 @@ MODULE_DEVICE_TABLE(acpi, fujitsu_ids);
static int __init fujitsu_init(void)
{
- int ret, max_brightness;
+ int ret;
if (acpi_disabled)
return -ENODEV;
@@ -1232,22 +1251,9 @@ static int __init fujitsu_init(void)
/* Register backlight stuff */
if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
- struct backlight_properties props;
-
- memset(&props, 0, sizeof(struct backlight_properties));
- max_brightness = fujitsu_bl->max_brightness;
- props.type = BACKLIGHT_PLATFORM;
- props.max_brightness = max_brightness - 1;
- fujitsu_bl->bl_device =
backlight_device_register("fujitsu-laptop",
- NULL, NULL,
-
&fujitsu_bl_ops,
- &props);
- if (IS_ERR(fujitsu_bl->bl_device)) {
- ret = PTR_ERR(fujitsu_bl->bl_device);
- fujitsu_bl->bl_device = NULL;
+ ret = fujitsu_backlight_register();
+ if (ret)
goto fail_sysfs_group;
- }
- fujitsu_bl->bl_device->props.brightness =
fujitsu_bl->brightness_level;
}
ret = platform_driver_register(&fujitsu_pf_driver);
--
2.12.0
[PATCH v2 0/4] fujitsu_init() cleanup
These patches should make fujitsu_init() a bit more palatable. No changes are made to platform device code yet, for clarity these will be posted in a separate series after this one gets applied. Changes from v1: - Rebase on top of reworked Alan Jenkins' cleanup patch series. - Drop patch 1/4 from v1 as it has already been applied in reworked Alan Jenkins' cleanup patch series. - Patch 3/4 from v1 has been replaced with a completely different one (patch 2/4). It needs to be tested on a relevant machine as it is based purely on a dump of a DSDT table (further details can be found in the patch itself). - Patch 3/4 in v2 is a rebased version of patch 8/10 from the reworked Alan Jenkins' cleanup patch series. Patch 2/4 from v2 (the one mentioned in the previous bullet point) ensures this one can be safely applied without causing a NULL dereference under any circumstances. drivers/platform/x86/fujitsu-laptop.c | 113 +- 1 file changed, 56 insertions(+), 57 deletions(-) -- 2.12.0
