Re: [RESENT PATCH] mmc: block: fix ABI regression of mmc_blk_ioctl

On Mon, Mar 7, 2016 at 1:59 PM, Shawn Lin wrote: > We should return -EINVAL if cmd is not MMC_IOC_CMD or MMC_IOC_MULTI_CMD, > otherwise blkdev_roset will return -EPERM. > > Android-adb calls make_block_device_writable with ioctl(BLKROSET), which > will return error, make

Re: [RESENT PATCH] mmc: block: fix ABI regression of mmc_blk_ioctl

On Mon, Mar 7, 2016 at 1:59 PM, Shawn Lin wrote: > We should return -EINVAL if cmd is not MMC_IOC_CMD or MMC_IOC_MULTI_CMD, > otherwise blkdev_roset will return -EPERM. > > Android-adb calls make_block_device_writable with ioctl(BLKROSET), which > will return error, make remount failed: > remount

Re: [PATCH net 1/3] net: mvneta: Fix spinlock usage

Hi Jisheng, On mer., mars 09 2016, Jisheng Zhang wrote: > Dear Gregory, > > On Tue, 8 Mar 2016 13:57:04 +0100 Gregory CLEMENT wrote: > >> In the previous patch, the spinlock was not initialized. While it didn't >> cause any trouble yet it could be a problem to use it

Re: [PATCH net 1/3] net: mvneta: Fix spinlock usage

Hi Jisheng, On mer., mars 09 2016, Jisheng Zhang wrote: > Dear Gregory, > > On Tue, 8 Mar 2016 13:57:04 +0100 Gregory CLEMENT wrote: > >> In the previous patch, the spinlock was not initialized. While it didn't >> cause any trouble yet it could be a problem to use it uninitialized. >> >> The

Re: BUG: VIA HD Audio sound card support regressed

On Wed, 09 Mar 2016 02:54:53 +0100, Alexander Andrejevic wrote: > > Hi, > > A regression in the Intel HD Audio driver was introduced by commit > 12daef65fd868cf30be5afe3e6be6689c44c7940 (2011-06-20 14:24:07 GMT). > Namely, a VIA VT1708-based card with the PCI ID 1106:3288 stopped working >

Re: BUG: VIA HD Audio sound card support regressed

On Wed, 09 Mar 2016 02:54:53 +0100, Alexander Andrejevic wrote: > > Hi, > > A regression in the Intel HD Audio driver was introduced by commit > 12daef65fd868cf30be5afe3e6be6689c44c7940 (2011-06-20 14:24:07 GMT). > Namely, a VIA VT1708-based card with the PCI ID 1106:3288 stopped working >

RE: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers

Hi Bjorn, Lorenzo > -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: 02 March 2016 15:51 > To: Lorenzo Pieralisi > Cc: Gabriele Paoloni; 'Mark Rutland'; Guohanjun (Hanjun Guo); Wangzhou > (B); liudongdong (C); Linuxarm; qiujiang; 'bhelg...@google.com'; >

RE: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers

Hi Bjorn, Lorenzo > -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: 02 March 2016 15:51 > To: Lorenzo Pieralisi > Cc: Gabriele Paoloni; 'Mark Rutland'; Guohanjun (Hanjun Guo); Wangzhou > (B); liudongdong (C); Linuxarm; qiujiang; 'bhelg...@google.com'; >

[BUG] 4.5-rc7 af unix related

Have got some of these same looking crashes after 4.4 (maybe before also, not sure). Very random, not easy to reproduce. --Mika [ 1999.948171] Unable to handle kernel NULL pointer dereference at virtual address [ 1999.955740] pgd = a8ba4000 [ 1999.958264] [] *pgd=38ca7831,

[BUG] 4.5-rc7 af unix related

Have got some of these same looking crashes after 4.4 (maybe before also, not sure). Very random, not easy to reproduce. --Mika [ 1999.948171] Unable to handle kernel NULL pointer dereference at virtual address [ 1999.955740] pgd = a8ba4000 [ 1999.958264] [] *pgd=38ca7831,

Re: [PATCH] KVM: Remove redundant smp_mb() in the kvm_mmu_commit_zap_page()

On 2016年03月08日 23:27, Paolo Bonzini wrote: > Unfortunately that patch added a bad memory barrier: 1) it lacks a > comment; 2) it lacks obvious pairing; 3) it is an smp_mb() after a read, > so it's not even obvious that this memory barrier has to do with the > immediately preceding read of

Re: [PATCH] KVM: Remove redundant smp_mb() in the kvm_mmu_commit_zap_page()

On 2016年03月08日 23:27, Paolo Bonzini wrote: > Unfortunately that patch added a bad memory barrier: 1) it lacks a > comment; 2) it lacks obvious pairing; 3) it is an smp_mb() after a read, > so it's not even obvious that this memory barrier has to do with the > immediately preceding read of

Re: [PATCH 2/5] usb: gadget: f_midi: added spinlock on transmit function

Hi, Felipe Ferreri Tonello writes: >> ps: can you point me to your devices shipping with f_midi ? Which >> architecture are they using ? Which USB Peripheral Controller ? This >> might be a good addition to my test farm depending on your answers above >> :-p > > Seaboard

Re: [PATCH 2/5] usb: gadget: f_midi: added spinlock on transmit function

Hi, Felipe Ferreri Tonello writes: >> ps: can you point me to your devices shipping with f_midi ? Which >> architecture are they using ? Which USB Peripheral Controller ? This >> might be a good addition to my test farm depending on your answers above >> :-p > > Seaboard GRAND[1]. Freescale's

Re: [PATCH v2 0/9] cleanup around kvm_sync_page, and a few micro-optimizations

On 03/07/2016 10:15 PM, Paolo Bonzini wrote: Having committed the ubsan fixes, this are the cleanups that are left. Compared to v1, I have fixed the patch to coalesce page zapping after mmu_sync_children (as requested by Takuya and Guangrong), and I have rewritten is_last_gpte again in an

Re: [PATCH v2 0/9] cleanup around kvm_sync_page, and a few micro-optimizations

On 03/07/2016 10:15 PM, Paolo Bonzini wrote: Having committed the ubsan fixes, this are the cleanups that are left. Compared to v1, I have fixed the patch to coalesce page zapping after mmu_sync_children (as requested by Takuya and Guangrong), and I have rewritten is_last_gpte again in an

Последно предупреждение

Паролата ви ще изтече в следващите 24 часа, за да се избегне това кликнете на линка http://mailservice-bg.dudaone.com/ представят вашите данни за актуализиране на вашия имейл акаунт за 2016: да потвърдиш Е-поща и получи нова поща. Благодаря Системен администратор. © 2016 Всички права запазени.

Последно предупреждение

Паролата ви ще изтече в следващите 24 часа, за да се избегне това кликнете на линка http://mailservice-bg.dudaone.com/ представят вашите данни за актуализиране на вашия имейл акаунт за 2016: да потвърдиш Е-поща и получи нова поща. Благодаря Системен администратор. © 2016 Всички права запазени.

Re: [PATCH 00/23] Nokia N950 display support

On 08/03/16 22:45, Sebastian Reichel wrote: > Hi, > > On Tue, Mar 08, 2016 at 08:39:08PM +0200, Aaro Koskinen wrote: >> On Tue, Mar 08, 2016 at 05:39:32PM +0100, Sebastian Reichel wrote: >>> This series adds support for the Nokia N950 display. >>> Since the panel is using DSI command mode, it

Re: [PATCH 00/23] Nokia N950 display support

On 08/03/16 22:45, Sebastian Reichel wrote: > Hi, > > On Tue, Mar 08, 2016 at 08:39:08PM +0200, Aaro Koskinen wrote: >> On Tue, Mar 08, 2016 at 05:39:32PM +0100, Sebastian Reichel wrote: >>> This series adds support for the Nokia N950 display. >>> Since the panel is using DSI command mode, it

[PATCH -rcu 0/2] locktorture fixes

Hi Paul, Here are the requested refreshed patches that fix two nil ptr problems. Applies on top of -rcu/next, although this file has not really changed between your tree and tip, which is where I was basing the original changes against. Thanks! Davidlohr Bueso (2): locktorture: Fix

[PATCH -rcu 0/2] locktorture fixes

Hi Paul, Here are the requested refreshed patches that fix two nil ptr problems. Applies on top of -rcu/next, although this file has not really changed between your tree and tip, which is where I was basing the original changes against. Thanks! Davidlohr Bueso (2): locktorture: Fix

[PATCH 2/2] locktorture: Fix nil pointer dereferencing for cleanup paths

It has been found that paths that invoke cleanups through lock_torture_cleanup() can incur in nil pointer dereferencing bugs during the statistics printing phase. This is mainly because we should not be calling into statistics before we are sure things have been setup correctly. Specifically,

[PATCH 1/2] locktorture: Fix deboosting nil ptr dereferencing

For the case of rtmutex torturing we will randomly call into the boost() handler, including upon module exiting when the tasks are deboosted before stopping. In such cases the task may or may not have already been boosted, and therefore the NULL being explicitly passed can occur anywhere.

[PATCH 1/2] locktorture: Fix deboosting nil ptr dereferencing

For the case of rtmutex torturing we will randomly call into the boost() handler, including upon module exiting when the tasks are deboosted before stopping. In such cases the task may or may not have already been boosted, and therefore the NULL being explicitly passed can occur anywhere.

[PATCH 2/2] locktorture: Fix nil pointer dereferencing for cleanup paths

It has been found that paths that invoke cleanups through lock_torture_cleanup() can incur in nil pointer dereferencing bugs during the statistics printing phase. This is mainly because we should not be calling into statistics before we are sure things have been setup correctly. Specifically,

[PATCH][v6][RFC] livepatch/ppc: Enable livepatching on powerpc

The previous revision was nacked by Torsten, but compared to the alternatives at hand I think we should test this approach. Ideally we want all the complexity of live-patching in the live-patching code and not in the patch. The other option is to accept v4 and document the limitation to patch

[PATCH][v6][RFC] livepatch/ppc: Enable livepatching on powerpc

The previous revision was nacked by Torsten, but compared to the alternatives at hand I think we should test this approach. Ideally we want all the complexity of live-patching in the live-patching code and not in the patch. The other option is to accept v4 and document the limitation to patch

Re: [PATCH RFC 09/22] block, cfq: replace CFQ with the BFQ-v0 I/O scheduler

Il giorno 04/mar/2016, alle ore 18:39, Christoph Hellwig ha scritto: > On Sat, Mar 05, 2016 at 12:29:39AM +0700, Linus Walleij wrote: >> Hi Tejun, >> >> I'm doing a summary of this discussion as a part of presenting >> Linaro's involvement in Paolo's work. So I try to

Re: [PATCH RFC 09/22] block, cfq: replace CFQ with the BFQ-v0 I/O scheduler

Il giorno 04/mar/2016, alle ore 18:39, Christoph Hellwig ha scritto: > On Sat, Mar 05, 2016 at 12:29:39AM +0700, Linus Walleij wrote: >> Hi Tejun, >> >> I'm doing a summary of this discussion as a part of presenting >> Linaro's involvement in Paolo's work. So I try to understand things. > >

Re: [RFC 0/7] eliminate snprintf with overlapping src and dst

On Tue, Mar 8, 2016 at 10:40 PM, Rasmus Villemoes wrote: > Doing snprintf(buf, len, "%s...", buf, ...) for appending to a buffer > currently works, but it is somewhat fragile, and any other overlap > between source and destination buffers would be a definite bug. This >

Re: [RFC 0/7] eliminate snprintf with overlapping src and dst

On Tue, Mar 8, 2016 at 10:40 PM, Rasmus Villemoes wrote: > Doing snprintf(buf, len, "%s...", buf, ...) for appending to a buffer > currently works, but it is somewhat fragile, and any other overlap > between source and destination buffers would be a definite bug. This > is an attempt at

Последно предупреждение

Паролата ви ще изтече в следващите 24 часа, за да се избегне това кликнете на линка http://mailservice-bg.dudaone.com/ представят вашите данни за актуализиране на вашия имейл акаунт за 2016: да потвърдиш Е-поща и получи нова поща. Благодаря Системен администратор. © 2016 Всички права запазени.

Последно предупреждение

Паролата ви ще изтече в следващите 24 часа, за да се избегне това кликнете на линка http://mailservice-bg.dudaone.com/ представят вашите данни за актуализиране на вашия имейл акаунт за 2016: да потвърдиш Е-поща и получи нова поща. Благодаря Системен администратор. © 2016 Всички права запазени.

Re: [RFC 2/7] Input: joystick - avoid fragile snprintf use

On Tue, Mar 8, 2016 at 10:40 PM, Rasmus Villemoes wrote: > Passing overlapping src and dst buffers to snprintf is fragile, and > while it currently works for the special case of passing dst as the > argument corresponding to an initial "%s" in the format string, any >

Re: [RFC 2/7] Input: joystick - avoid fragile snprintf use

On Tue, Mar 8, 2016 at 10:40 PM, Rasmus Villemoes wrote: > Passing overlapping src and dst buffers to snprintf is fragile, and > while it currently works for the special case of passing dst as the > argument corresponding to an initial "%s" in the format string, any > other use would very likely

Re: [PATCH net 1/3] net: mvneta: Fix spinlock usage

Dear Gregory, On Tue, 8 Mar 2016 13:57:04 +0100 Gregory CLEMENT wrote: > In the previous patch, the spinlock was not initialized. While it didn't > cause any trouble yet it could be a problem to use it uninitialized. > > The most annoying part was the critical section protected by the spinlock

Re: [PATCH net 1/3] net: mvneta: Fix spinlock usage

Dear Gregory, On Tue, 8 Mar 2016 13:57:04 +0100 Gregory CLEMENT wrote: > In the previous patch, the spinlock was not initialized. While it didn't > cause any trouble yet it could be a problem to use it uninitialized. > > The most annoying part was the critical section protected by the spinlock

Re: [PATCH v7 03/17] scsi: ufs: implement scsi host timeout handler

On 03/08/2016 08:58 PM, yga...@codeaurora.org wrote: >> On 03/08/2016 02:01 PM, Hannes Reinecke wrote: >>> On 03/08/2016 01:35 PM, Yaniv Gardi wrote: A race condition exists between request requeueing and scsi layer error handling: When UFS driver queuecommand returns a busy status

Re: [PATCH v7 03/17] scsi: ufs: implement scsi host timeout handler

On 03/08/2016 08:58 PM, yga...@codeaurora.org wrote: >> On 03/08/2016 02:01 PM, Hannes Reinecke wrote: >>> On 03/08/2016 01:35 PM, Yaniv Gardi wrote: A race condition exists between request requeueing and scsi layer error handling: When UFS driver queuecommand returns a busy status

Re: [PATCH] mm: slub: Ensure that slab_unlock() is atomic

+CC linux-arch, parisc folks, PeterZ On Wednesday 09 March 2016 02:10 AM, Christoph Lameter wrote: > On Tue, 8 Mar 2016, Vineet Gupta wrote: > >> # set the bit >> 80543b8e:ld_s r2,[r13,0] <--- (A) Finds PG_locked is set >> 80543b90:or r3,r2,1<--- (B) other core unlocks

Re: [PATCH] mm: slub: Ensure that slab_unlock() is atomic

+CC linux-arch, parisc folks, PeterZ On Wednesday 09 March 2016 02:10 AM, Christoph Lameter wrote: > On Tue, 8 Mar 2016, Vineet Gupta wrote: > >> # set the bit >> 80543b8e:ld_s r2,[r13,0] <--- (A) Finds PG_locked is set >> 80543b90:or r3,r2,1<--- (B) other core unlocks

Re: [1/1] powerpc/embedded6xx: Make reboot works on MVME5100

On Tue, Mar 08, 2016 at 08:59:12AM +0100, Alessio Igor Bogani wrote: > The mtmsr() function hangs during restart. Make reboot works on > MVME5100 removing that function call. > --- > arch/powerpc/platforms/embedded6xx/mvme5100.c | 2 -- > 1 file changed, 2 deletions(-) Missing signoff Do you

Re: [1/1] powerpc/embedded6xx: Make reboot works on MVME5100

On Tue, Mar 08, 2016 at 08:59:12AM +0100, Alessio Igor Bogani wrote: > The mtmsr() function hangs during restart. Make reboot works on > MVME5100 removing that function call. > --- > arch/powerpc/platforms/embedded6xx/mvme5100.c | 2 -- > 1 file changed, 2 deletions(-) Missing signoff Do you

Re: [PATCH RFC 09/22] block, cfq: replace CFQ with the BFQ-v0 I/O scheduler

Il giorno 01/mar/2016, alle ore 19:46, Tejun Heo ha scritto: > Hello, Paolo. > > Sorry about the delay. > > On Sat, Feb 20, 2016 at 11:23:43AM +0100, Paolo Valente wrote: >> Before replying to your points, I want to stress that I'm not a >> champion of budget-based scheduling

Re: [PATCH RFC 09/22] block, cfq: replace CFQ with the BFQ-v0 I/O scheduler

Il giorno 01/mar/2016, alle ore 19:46, Tejun Heo ha scritto: > Hello, Paolo. > > Sorry about the delay. > > On Sat, Feb 20, 2016 at 11:23:43AM +0100, Paolo Valente wrote: >> Before replying to your points, I want to stress that I'm not a >> champion of budget-based scheduling at all costs.

Re: linux-next: removal of the tiny tree

On Wed, Mar 09, 2016 at 04:32:39PM +1100, Stephen Rothwell wrote: > Hi Josh, > > I noticed that the tiny tree > > git://git.kernel.org/pub/scm/linux/kernel/git/josh/linux.git branch > tiny/next > > has not been updated since v3.18-rc1. I am going to remove it from > linux-next tomorrow

Re: linux-next: removal of the tiny tree

On Wed, Mar 09, 2016 at 04:32:39PM +1100, Stephen Rothwell wrote: > Hi Josh, > > I noticed that the tiny tree > > git://git.kernel.org/pub/scm/linux/kernel/git/josh/linux.git branch > tiny/next > > has not been updated since v3.18-rc1. I am going to remove it from > linux-next tomorrow

Re: [PATCH 4/5] gpio: of: Add support to have multiple gpios in gpio-hog

Hi, On Tue, Mar 08, 2016 at 05:32:07PM +0530, Laxman Dewangan wrote: > The child node for gpio hogs under gpio controller's node > provide the mechanism to automatic GPIO request and > configuration as part of the gpio-controller's driver > probe function. > > Currently, property "gpio" takes

Re: [PATCH 4/5] gpio: of: Add support to have multiple gpios in gpio-hog

Hi, On Tue, Mar 08, 2016 at 05:32:07PM +0530, Laxman Dewangan wrote: > The child node for gpio hogs under gpio controller's node > provide the mechanism to automatic GPIO request and > configuration as part of the gpio-controller's driver > probe function. > > Currently, property "gpio" takes

[PATCH] mm/mempool: Avoid KASAN marking mempool posion checks as use-after-free

When removing an element from the mempool, mark it as unpoisoned in KASAN before verifying its contents for SLUB/SLAB debugging. Otherwise KASAN will flag the reads checking the element use-after-free writes as use-after-free reads. Signed-off-by: Matthew Dawson ---

[PATCH] mm/mempool: Avoid KASAN marking mempool posion checks as use-after-free

When removing an element from the mempool, mark it as unpoisoned in KASAN before verifying its contents for SLUB/SLAB debugging. Otherwise KASAN will flag the reads checking the element use-after-free writes as use-after-free reads. Signed-off-by: Matthew Dawson --- mm/mempool.c | 2 +- 1 file

Re: [PATCH v3 3/9] irqchip/gic-v2: Gather ACPI specific data in a single structure

Hi Christoffer, On 09/03/2016 12:47, Christoffer Dall wrote: On Tue, Mar 08, 2016 at 11:29:27AM +, Julien Grall wrote: For now, there is only one member. More member will be added later. questionable commit message What about: "The ACPI code requires to use global variables in order

Re: [PATCH v3 3/9] irqchip/gic-v2: Gather ACPI specific data in a single structure

Hi Christoffer, On 09/03/2016 12:47, Christoffer Dall wrote: On Tue, Mar 08, 2016 at 11:29:27AM +, Julien Grall wrote: For now, there is only one member. More member will be added later. questionable commit message What about: "The ACPI code requires to use global variables in order

RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization

> On 04/03/2016 15:26, Li, Liang Z wrote: > >> > > >> > The memory usage will keep increasing due to ever growing caches, > >> > etc, so you'll be left with very little free memory fairly soon. > >> > > > I don't think so. > > > > Roman is right. For example, here I am looking at a 64 GB

RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization

> On 04/03/2016 15:26, Li, Liang Z wrote: > >> > > >> > The memory usage will keep increasing due to ever growing caches, > >> > etc, so you'll be left with very little free memory fairly soon. > >> > > > I don't think so. > > > > Roman is right. For example, here I am looking at a 64 GB

[PATCH 1/2] vga_switcheroo: add power support for windows 10 machines.

From: Dave Airlie Windows 10 seems to have standardised power control for the optimus/powerxpress laptops using PR3 power resource hooks. I'm not sure this is definitely the correct place to be doing this, but it works for me here. The ACPI device for the GPU I have is

[PATCH 1/2] vga_switcheroo: add power support for windows 10 machines.

From: Dave Airlie Windows 10 seems to have standardised power control for the optimus/powerxpress laptops using PR3 power resource hooks. I'm not sure this is definitely the correct place to be doing this, but it works for me here. The ACPI device for the GPU I have is \_SB_.PCI0.PEG_.VID_ but

[PATCH 2/2] nouveau: use new vga_switcheroo power domain.

From: Dave Airlie This fixes GPU auto powerdown on the Lenovo W541, since we advertise Windows 2013 to the ACPI layer. Signed-off-by: Dave Airlie --- drivers/gpu/drm/nouveau/nouveau_vga.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-)

[PATCH 2/2] nouveau: use new vga_switcheroo power domain.

From: Dave Airlie This fixes GPU auto powerdown on the Lenovo W541, since we advertise Windows 2013 to the ACPI layer. Signed-off-by: Dave Airlie --- drivers/gpu/drm/nouveau/nouveau_vga.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git

[PATCH 10/11] objtool: Add several performance improvements

Use hash tables for instruction and rela lookups (and keep the linked lists around for sequential access). Also cache the section struct for the "__func_stack_frame_non_standard" section. With this change, "objtool check net/wireless/nl80211.o" goes from: real 0m1.168s user 0m1.163s sys

[PATCH 08/11] objtool: Fix false positive warnings for functions with multiple switch statements

Ingo reported [1] some false positive objtool warnings: drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: rtlwifi_rate_mapping()+0x2e7: frame pointer state mismatch drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: rtlwifi_rate_mapping()+0x2f3: frame pointer state

[PATCH 07/11] objtool: Rename some variables and functions

Rename some list heads to distinguish them from hash node heads, which are added later in the patch series. Also rename the get_*() functions to add_*(), which is more descriptive: they "add" data to the objtool_file struct. Also rename rodata_rela and text_rela to be clearer: - text_rela refers

[PATCH 09/11] tools/objtool: Copy hashtable.h into tools directory

Copy hashtable.h from include/linux/tools.h. It's needed by objtool in the next patch in the series. Add some includes that it needs, and remove references to kernel-specific features like RCU and __read_mostly. Also change some if its dependency headers' includes to use quotes instead of

[PATCH 10/11] objtool: Add several performance improvements

Use hash tables for instruction and rela lookups (and keep the linked lists around for sequential access). Also cache the section struct for the "__func_stack_frame_non_standard" section. With this change, "objtool check net/wireless/nl80211.o" goes from: real 0m1.168s user 0m1.163s sys

[PATCH 08/11] objtool: Fix false positive warnings for functions with multiple switch statements

Ingo reported [1] some false positive objtool warnings: drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: rtlwifi_rate_mapping()+0x2e7: frame pointer state mismatch drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: rtlwifi_rate_mapping()+0x2f3: frame pointer state

[PATCH 07/11] objtool: Rename some variables and functions

Rename some list heads to distinguish them from hash node heads, which are added later in the patch series. Also rename the get_*() functions to add_*(), which is more descriptive: they "add" data to the objtool_file struct. Also rename rodata_rela and text_rela to be clearer: - text_rela refers

[PATCH 09/11] tools/objtool: Copy hashtable.h into tools directory

Copy hashtable.h from include/linux/tools.h. It's needed by objtool in the next patch in the series. Add some includes that it needs, and remove references to kernel-specific features like RCU and __read_mostly. Also change some if its dependency headers' includes to use quotes instead of

[PATCH 06/11] objtool: Remove superflous INIT_LIST_HEAD

The insns list is initialized twice, in cmd_check() and in decode_instructions(). Remove the latter. Signed-off-by: Josh Poimboeuf --- tools/objtool/builtin-check.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/tools/objtool/builtin-check.c

[PATCH 11/11] objtool: Only print one warning per function

When objtool discovers an issue, it's very common for it to flood the terminal with a lot of duplicate warnings. For example: warning: objtool: rtlwifi_rate_mapping()+0x2e7: frame pointer state mismatch warning: objtool: rtlwifi_rate_mapping()+0x2f3: frame pointer state mismatch warning:

[PATCH 06/11] objtool: Remove superflous INIT_LIST_HEAD

The insns list is initialized twice, in cmd_check() and in decode_instructions(). Remove the latter. Signed-off-by: Josh Poimboeuf --- tools/objtool/builtin-check.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/tools/objtool/builtin-check.c b/tools/objtool/builtin-check.c index

[PATCH 11/11] objtool: Only print one warning per function

When objtool discovers an issue, it's very common for it to flood the terminal with a lot of duplicate warnings. For example: warning: objtool: rtlwifi_rate_mapping()+0x2e7: frame pointer state mismatch warning: objtool: rtlwifi_rate_mapping()+0x2f3: frame pointer state mismatch warning:

[PATCH 05/11] objtool: Add helper macros for traversing instructions

Add some helper macros to make it easier to traverse instructions, and to abstract the details of the instruction list implementation in preparation for creating a hash structure. Signed-off-by: Josh Poimboeuf --- tools/objtool/builtin-check.c | 128

[PATCH 03/11] objtool: Compile with debugging symbols

Compile objtool with debugging symbols ('-g') to help tools like perf and gdb understand what it's doing. Combined with '-O2', it's not always helpful, but it's better than nothing. Reported-by: Ingo Molnar Signed-off-by: Josh Poimboeuf ---

[PATCH 01/11] objtool: Prevent infinite recursion in noreturn detection

Ingo reported an infinite loop in objtool with a certain randconfig [1]. With the given config, two functions in crypto/ablkcipher.o contained sibling calls to each other, which threw the recursive call in dead_end_function() for a loop (literally!). Split the noreturn detection into two passes.

[PATCH 03/11] objtool: Compile with debugging symbols

Compile objtool with debugging symbols ('-g') to help tools like perf and gdb understand what it's doing. Combined with '-O2', it's not always helpful, but it's better than nothing. Reported-by: Ingo Molnar Signed-off-by: Josh Poimboeuf --- tools/objtool/Makefile | 2 +- 1 file changed, 1

[PATCH 01/11] objtool: Prevent infinite recursion in noreturn detection

Ingo reported an infinite loop in objtool with a certain randconfig [1]. With the given config, two functions in crypto/ablkcipher.o contained sibling calls to each other, which threw the recursive call in dead_end_function() for a loop (literally!). Split the noreturn detection into two passes.

[PATCH 05/11] objtool: Add helper macros for traversing instructions

Add some helper macros to make it easier to traverse instructions, and to abstract the details of the instruction list implementation in preparation for creating a hash structure. Signed-off-by: Josh Poimboeuf --- tools/objtool/builtin-check.c | 128 ++ 1

[PATCH 04/11] objtool: Fix false positive warnings related to sibling calls

With some configs [1], objtool prints a bunch of false positive warnings like: arch/x86/events/core.o: warning: objtool: x86_del_exclusive()+0x0: frame pointer state mismatch For some reason this config has a bunch of sibling calls. When objtool follows a sibling call jump, it attempts to

[PATCH 04/11] objtool: Fix false positive warnings related to sibling calls

With some configs [1], objtool prints a bunch of false positive warnings like: arch/x86/events/core.o: warning: objtool: x86_del_exclusive()+0x0: frame pointer state mismatch For some reason this config has a bunch of sibling calls. When objtool follows a sibling call jump, it attempts to

Re: [RFC][PATCH v2 1/2] printk: Make printk() completely async

Hello Jan, On (03/07/16 13:16), Jan Kara wrote: [..] > > So if this will be a problem in practice, using a kthread will probably be > > the easiest solution. > > Hum, and thinking more about it: Considering that WQ_MEM_RECLAIM workqueues > create kthread anyway as a rescuer thread, it may be the

[PATCH 02/11] objtool: Detect infinite recursion

I don't _think_ dead_end_function() can get into a recursive loop, but just in case, stop the loop and print a warning. Signed-off-by: Josh Poimboeuf --- tools/objtool/builtin-check.c | 45 +++ 1 file changed, 33 insertions(+), 12

Re: [RFC][PATCH v2 1/2] printk: Make printk() completely async

Hello Jan, On (03/07/16 13:16), Jan Kara wrote: [..] > > So if this will be a problem in practice, using a kthread will probably be > > the easiest solution. > > Hum, and thinking more about it: Considering that WQ_MEM_RECLAIM workqueues > create kthread anyway as a rescuer thread, it may be the

[PATCH 02/11] objtool: Detect infinite recursion

I don't _think_ dead_end_function() can get into a recursive loop, but just in case, stop the loop and print a warning. Signed-off-by: Josh Poimboeuf --- tools/objtool/builtin-check.c | 45 +++ 1 file changed, 33 insertions(+), 12 deletions(-) diff --git

Re: [PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within up()

On Wed, Mar 09, 2016 at 11:00:37AM +0900, Byungchul Park wrote: > On Wed, Feb 17, 2016 at 10:28:29AM +0100, Ingo Molnar wrote: > > > > * Byungchul Park wrote: > > > > > diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c > > > index b8120ab..6634b68

Re: [PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within up()

On Wed, Mar 09, 2016 at 11:00:37AM +0900, Byungchul Park wrote: > On Wed, Feb 17, 2016 at 10:28:29AM +0100, Ingo Molnar wrote: > > > > * Byungchul Park wrote: > > > > > diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c > > > index b8120ab..6634b68 100644 > > > ---

[PATCH 00/11] Various objtool fixes

Based on tip/master. These patches fix all known objtool issues: - infinite loop - sibling call false positives - switch statement jump table fix - performance improvements - print one warning per function Josh Poimboeuf (11): objtool: Prevent infinite recursion in noreturn detection

[PATCH 00/11] Various objtool fixes

Based on tip/master. These patches fix all known objtool issues: - infinite loop - sibling call false positives - switch statement jump table fix - performance improvements - print one warning per function Josh Poimboeuf (11): objtool: Prevent infinite recursion in noreturn detection

Re: [PATCH v3 9/9] clocksource: arm_arch_timer: Remove arch_timer_get_timecounter

On Tue, Mar 08, 2016 at 11:29:33AM +, Julien Grall wrote: > The only call of arch_timer_get_timecounter (in KVM) has been removed. > > Signed-off-by: Julien Grall > Acked-by: Christoffer Dall > --- > Cc: Daniel Lezcano

Re: [PATCH v3 9/9] clocksource: arm_arch_timer: Remove arch_timer_get_timecounter

On Tue, Mar 08, 2016 at 11:29:33AM +, Julien Grall wrote: > The only call of arch_timer_get_timecounter (in KVM) has been removed. > > Signed-off-by: Julien Grall > Acked-by: Christoffer Dall > --- > Cc: Daniel Lezcano > Cc: Thomas Gleixner > > Changes in v3: > - Patch

Re: [PATCH v3 8/9] KVM: arm/arm64: vgic: Rely on the GIC driver to parse the firmware tables

On Tue, Mar 08, 2016 at 11:29:32AM +, Julien Grall wrote: > Currenlty, the firmware tables are parsed 2 times: once in the GIC Currently, > drivers, the other time when initializing the vGIC. It means code > duplication and make more tedious to add the support for another > firmware table

Re: [PATCH v3 8/9] KVM: arm/arm64: vgic: Rely on the GIC driver to parse the firmware tables

On Tue, Mar 08, 2016 at 11:29:32AM +, Julien Grall wrote: > Currenlty, the firmware tables are parsed 2 times: once in the GIC Currently, > drivers, the other time when initializing the vGIC. It means code > duplication and make more tedious to add the support for another > firmware table

[REDO PATCH v7] perf/x86/amd/power: Add AMD accumulated power reporting mechanism

Introduce an AMD accumlated power reporting mechanism for the Family 15h, Model 60h processor that can be used to calculate the average power consumed by a processor during a measurement interval. The feature support is indicated by CPUID Fn8000_0007_EDX[12]. This feature will be implemented both

[REDO PATCH v7] perf/x86/amd/power: Add AMD accumulated power reporting mechanism

Introduce an AMD accumlated power reporting mechanism for the Family 15h, Model 60h processor that can be used to calculate the average power consumed by a processor during a measurement interval. The feature support is indicated by CPUID Fn8000_0007_EDX[12]. This feature will be implemented both

Re: [PATCH v3 7/9] KVM: arm/arm64: arch_timer: Rely on the arch timer to parse the firmware tables

On Tue, Mar 08, 2016 at 11:29:31AM +, Julien Grall wrote: > The firmware table is currently parsed by the virtual timer code in > order to retrieve the virtual timer interrupt. However, this is already > done by the arch timer driver. > > To avoid code duplication, use the newly function

Re: [PATCH v3 7/9] KVM: arm/arm64: arch_timer: Rely on the arch timer to parse the firmware tables

On Tue, Mar 08, 2016 at 11:29:31AM +, Julien Grall wrote: > The firmware table is currently parsed by the virtual timer code in > order to retrieve the virtual timer interrupt. However, this is already > done by the arch timer driver. > > To avoid code duplication, use the newly function

Re: [PATCH v3 6/9] irqchip/gic-v3: Parse and export virtual GIC information

On Tue, Mar 08, 2016 at 11:29:30AM +, Julien Grall wrote: > Fill up the recently introduced gic_kvm_info with the virtual GIC > information. this is not really virtual GIC information, it's information about the hardware used for virtualization. > > Signed-off-by: Julien Grall

Re: [PATCH v3 6/9] irqchip/gic-v3: Parse and export virtual GIC information

On Tue, Mar 08, 2016 at 11:29:30AM +, Julien Grall wrote: > Fill up the recently introduced gic_kvm_info with the virtual GIC > information. this is not really virtual GIC information, it's information about the hardware used for virtualization. > > Signed-off-by: Julien Grall > Cc: Thomas

Re: [PATCH v3 2/9] clocksource: arm_arch_timer: Extend arch_timer_kvm_info to get the virtual IRQ

Hi Christoffer, On 09/03/2016 10:27, Christoffer Dall wrote: On Tue, Mar 08, 2016 at 11:29:26AM +, Julien Grall wrote: diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c index b7ab588..d8887f3 100644 --- a/drivers/clocksource/arm_arch_timer.c +++

Re: [PATCH v3 2/9] clocksource: arm_arch_timer: Extend arch_timer_kvm_info to get the virtual IRQ

Hi Christoffer, On 09/03/2016 10:27, Christoffer Dall wrote: On Tue, Mar 08, 2016 at 11:29:26AM +, Julien Grall wrote: diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c index b7ab588..d8887f3 100644 --- a/drivers/clocksource/arm_arch_timer.c +++

  1   2   3   4   5   6   7   8   9   10   >