[PATCH v2 1/3] x86/apic: Remove "focus disabled" for 64bit case

Disable processor focus for 64bit causes a crash, Call Trace as following: [] dump_stack+0x63/0x84 [] __warn+0xd1/0xf0 [] warn_slowpath_fmt+0x5f/0x80 [] ex_handler_wrmsr_unsafe+0x62/0x70 [] fixup_exception+0x39/0x50 [] do_general_protection+0x80/0x160 [] general_protection+0x28/0x30

[PATCH v2 1/3] x86/apic: Remove "focus disabled" for 64bit case

Disable processor focus for 64bit causes a crash, Call Trace as following: [] dump_stack+0x63/0x84 [] __warn+0xd1/0xf0 [] warn_slowpath_fmt+0x5f/0x80 [] ex_handler_wrmsr_unsafe+0x62/0x70 [] fixup_exception+0x39/0x50 [] do_general_protection+0x80/0x160 [] general_protection+0x28/0x30

[PATCH v2 2/3] x86/apic: Update comment about disabling processor focus

Fix references to discarded end_level_ioapic_irq(). Signed-off-by: Cao jin Signed-off-by: Wei Jiangang --- arch/x86/kernel/apic/apic.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/x86/kernel/apic/apic.c

[PATCH v2 3/3] x86/apic: Improved the setting of interrupt mode for bsp

If we specify the 'notsc' parameter for the dump-capture kernel, and then trigger a crash(panic) by using "ALT-SysRq-c" or "echo c > /proc/sysrq-trigger", the dump-capture kernel will hang in calibrate_delay_converge() and wait for jiffies changes. serial log as follows: tsc: Fast TSC

[PATCH v2 0/3] Fix dump-capture kernel hangs with notsc

v2: Just about the commit ("x86/apic: Improved the setting of interrupt mode for bsp") - Unify the name s/virtual_wire_via_*/virt_wire_through_* - Add check for PIC mode suggested-by Baoquan He - Add check enable/disable flag for IO-APIC suggested-by Xunlei Pang

[PATCH v2 2/3] x86/apic: Update comment about disabling processor focus

Fix references to discarded end_level_ioapic_irq(). Signed-off-by: Cao jin Signed-off-by: Wei Jiangang --- arch/x86/kernel/apic/apic.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c index 0273b652c689..8e25b9b2d351 100644 ---

[PATCH v2 3/3] x86/apic: Improved the setting of interrupt mode for bsp

If we specify the 'notsc' parameter for the dump-capture kernel, and then trigger a crash(panic) by using "ALT-SysRq-c" or "echo c > /proc/sysrq-trigger", the dump-capture kernel will hang in calibrate_delay_converge() and wait for jiffies changes. serial log as follows: tsc: Fast TSC

[PATCH v2 0/3] Fix dump-capture kernel hangs with notsc

v2: Just about the commit ("x86/apic: Improved the setting of interrupt mode for bsp") - Unify the name s/virtual_wire_via_*/virt_wire_through_* - Add check for PIC mode suggested-by Baoquan He - Add check enable/disable flag for IO-APIC suggested-by Xunlei Pang - Update comments v1:

Re: [RFC PATCH v7 1/7] Restartable sequences system call

- On Jul 25, 2016, at 7:02 PM, Andy Lutomirski l...@amacapital.net wrote: > On Thu, Jul 21, 2016 at 2:14 PM, Mathieu Desnoyers > wrote: >> Man page associated: >> >> RSEQ(2)Linux Programmer's Manual RSEQ(2) >> >> NAME >>

Re: [RFC PATCH v7 1/7] Restartable sequences system call

- On Jul 25, 2016, at 7:02 PM, Andy Lutomirski l...@amacapital.net wrote: > On Thu, Jul 21, 2016 at 2:14 PM, Mathieu Desnoyers > wrote: >> Man page associated: >> >> RSEQ(2)Linux Programmer's Manual RSEQ(2) >> >> NAME >>rseq - Restartable sequences and

[PATCH] clocksource: sun4i: Clear interrupts after stopping timer in probe function

The bootloader (U-boot) sometimes uses this timer for various delays. It uses it as a ongoing counter, and does comparisons on the current counter value. The timer counter is never stopped. In some cases when the user interacts with the bootloader, or lets it idle for some time before loading

[PATCH] clocksource: sun4i: Clear interrupts after stopping timer in probe function

The bootloader (U-boot) sometimes uses this timer for various delays. It uses it as a ongoing counter, and does comparisons on the current counter value. The timer counter is never stopped. In some cases when the user interacts with the bootloader, or lets it idle for some time before loading

Re: [PATCH v2 02/10] userns: Add per user namespace sysctls.

From: ebied...@xmission.com (Eric W. Biederman) Date: Mon, 25 Jul 2016 19:44:50 -0500 > User namespaces have enabled unprivileged users access to a lot more > data structures and so to catch programs that go crazy we need a lot > more limits. I believe some of those limits make sense per

Re: [PATCH v2 02/10] userns: Add per user namespace sysctls.

From: ebied...@xmission.com (Eric W. Biederman) Date: Mon, 25 Jul 2016 19:44:50 -0500 > User namespaces have enabled unprivileged users access to a lot more > data structures and so to catch programs that go crazy we need a lot > more limits. I believe some of those limits make sense per

Re: [PATCH] iio: adc: rockchip_saradc: Explicitly disable ADC on probe

Hi Guenter, Thanks for fixing it. On 2016年07月26日 03:39, Guenter Roeck wrote: If the ADC is read for the first time, the caller gets a timeout error, and the kernel log shows read channel() error: -110 The ADC may be enabled on boot, and needs to be explicitly disabled for a read sequence to

Re: [PATCH] iio: adc: rockchip_saradc: Explicitly disable ADC on probe

Hi Guenter, Thanks for fixing it. On 2016年07月26日 03:39, Guenter Roeck wrote: If the ADC is read for the first time, the caller gets a timeout error, and the kernel log shows read channel() error: -110 The ADC may be enabled on boot, and needs to be explicitly disabled for a read sequence to

Re: [PATCH 4.6 000/203] 4.6.5-stable review

On Mon, Jul 25, 2016 at 07:49:58PM -0600, Shuah Khan wrote: > On 07/25/2016 02:53 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.6.5 release. > > There are 203 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.6 000/203] 4.6.5-stable review

On Mon, Jul 25, 2016 at 07:49:58PM -0600, Shuah Khan wrote: > On 07/25/2016 02:53 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.6.5 release. > > There are 203 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 1/3] memory: mediatek: Add a new interface mtk_smi_larb_is_ready

Hi, On Mon, Jul 25, 2016 at 5:39 PM, Matthias Brugger wrote: > > > On 20/07/16 05:01, Yong Wu wrote: >> >> Currently the iommu consumer always call iommu_present to get whether >> the iommu is ready. But in MTK IOMMU, this function can't indicate >> this. The IOMMU call

Re: [PATCH 1/3] memory: mediatek: Add a new interface mtk_smi_larb_is_ready

Hi, On Mon, Jul 25, 2016 at 5:39 PM, Matthias Brugger wrote: > > > On 20/07/16 05:01, Yong Wu wrote: >> >> Currently the iommu consumer always call iommu_present to get whether >> the iommu is ready. But in MTK IOMMU, this function can't indicate >> this. The IOMMU call

Re: [Qemu-devel] [PATCH v2 0/2] vfio: add aer process

ping On 2016/7/19 16:13, Zhou Jie wrote: From: Chen Fan v1-v2: 1. Add aer process to vfio driver. Chen Fan (2): vfio : add aer process vfio : resume notifier drivers/vfio/pci/vfio_pci.c | 58 -

Re: [Qemu-devel] [PATCH v2 0/2] vfio: add aer process

ping On 2016/7/19 16:13, Zhou Jie wrote: From: Chen Fan v1-v2: 1. Add aer process to vfio driver. Chen Fan (2): vfio : add aer process vfio : resume notifier drivers/vfio/pci/vfio_pci.c | 58 - drivers/vfio/pci/vfio_pci_intrs.c | 18

Re: [PATCH v2] ceph: Mark the file cache as unreclaimable

> On Jul 26, 2016, at 01:12, Nikolay Borisov wrote: > > Ceph creates multiple caches with the SLAB_RECLAIMABLE flag set, so > that it can satisfy its internal needs. Inspecting the code shows that > most of the caches are indeed reclaimable since they are directly >

Re: [PATCH v2] ceph: Mark the file cache as unreclaimable

> On Jul 26, 2016, at 01:12, Nikolay Borisov wrote: > > Ceph creates multiple caches with the SLAB_RECLAIMABLE flag set, so > that it can satisfy its internal needs. Inspecting the code shows that > most of the caches are indeed reclaimable since they are directly > related to the generic

Re: [PATCH] randomize_range: use random long instead of int

Hi William, Kees, On Mon, Jul 25, 2016 at 11:25:41AM -0700, william.c.robe...@intel.com wrote: > From: William Roberts > > Use a long when generating the random range rather than > an int. This will produce better random distributions as > well as matching all the

Re: [PATCH] randomize_range: use random long instead of int

Hi William, Kees, On Mon, Jul 25, 2016 at 11:25:41AM -0700, william.c.robe...@intel.com wrote: > From: William Roberts > > Use a long when generating the random range rather than > an int. This will produce better random distributions as > well as matching all the types at hand. > >

Re: [PATCH] tools lib bpf: Use official ELF e_machine value

Hi Arnaldo, Please don't forget this patch. Thank you. On 2016/7/19 5:37, Alexei Starovoitov wrote: On Mon, Jul 18, 2016 at 06:01:08AM +, Wang Nan wrote: New LLVM will issue newly assigned EM_BPF machine code. The new code will be propogated to glibc and libelf. This patch introduces

Re: [PATCH] tools lib bpf: Use official ELF e_machine value

Hi Arnaldo, Please don't forget this patch. Thank you. On 2016/7/19 5:37, Alexei Starovoitov wrote: On Mon, Jul 18, 2016 at 06:01:08AM +, Wang Nan wrote: New LLVM will issue newly assigned EM_BPF machine code. The new code will be propogated to glibc and libelf. This patch introduces

Re: [PATCH 04/32] x86/intel_rdt: Add L3 cache capacity bitmask management

On Fri, Jul 22, 2016 at 02:43:23PM -0700, Luck, Tony wrote: > On Fri, Jul 22, 2016 at 04:12:04AM -0300, Marcelo Tosatti wrote: > > How does this patchset handle the following condition: > > > > 6) Create reservations in such a way that the sum is larger than > > total amount of cache, and CPU

Re: [PATCH 04/32] x86/intel_rdt: Add L3 cache capacity bitmask management

On Fri, Jul 22, 2016 at 02:43:23PM -0700, Luck, Tony wrote: > On Fri, Jul 22, 2016 at 04:12:04AM -0300, Marcelo Tosatti wrote: > > How does this patchset handle the following condition: > > > > 6) Create reservations in such a way that the sum is larger than > > total amount of cache, and CPU

RE: [PATCH v3 02/11] mm: Hardened usercopy

David Laight writes: > From: Josh Poimboeuf >> Sent: 22 July 2016 18:46 >> > >> > e.g. then if the pointer was in the thread_info, the second test would >> > fail, triggering the protection. >> >> FWIW, this won't work right on x86 after Andy's >>

RE: [PATCH v3 02/11] mm: Hardened usercopy

David Laight writes: > From: Josh Poimboeuf >> Sent: 22 July 2016 18:46 >> > >> > e.g. then if the pointer was in the thread_info, the second test would >> > fail, triggering the protection. >> >> FWIW, this won't work right on x86 after Andy's >> CONFIG_THREAD_INFO_IN_TASK patches get merged.

Re: [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces

On Sun, Jul 24, 2016 at 12:10:21AM -0500, Eric W. Biederman wrote: > Andrey Vagin writes: > > > Hello, > > > > I forgot to add --cc-cover for git send-email, so everyone who is in > > Cc got only a cover letter. All messages were sent in mail lists. > > > > Sorry for

Re: [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces

On Sun, Jul 24, 2016 at 12:10:21AM -0500, Eric W. Biederman wrote: > Andrey Vagin writes: > > > Hello, > > > > I forgot to add --cc-cover for git send-email, so everyone who is in > > Cc got only a cover letter. All messages were sent in mail lists. > > > > Sorry for inconvenience. > > Mostly

RE: [Patch v3 1/3] irqchip/qeic: move qeic driver from drivers/soc/fsl/qe

Hi Jason, On Mon, Jul 26, 2016 at 03:24AM, Jason Cooper wrote: > -Original Message- > From: Jason Cooper [mailto:ja...@lakedaemon.net] > Sent: Tuesday, July 26, 2016 3:24 AM > To: Qiang Zhao > Cc: o...@buserror.net; linuxppc-...@lists.ozlabs.org; linux- >

RE: [Patch v3 1/3] irqchip/qeic: move qeic driver from drivers/soc/fsl/qe

Hi Jason, On Mon, Jul 26, 2016 at 03:24AM, Jason Cooper wrote: > -Original Message- > From: Jason Cooper [mailto:ja...@lakedaemon.net] > Sent: Tuesday, July 26, 2016 3:24 AM > To: Qiang Zhao > Cc: o...@buserror.net; linuxppc-...@lists.ozlabs.org; linux- > ker...@vger.kernel.org; Xiaobo

Re: [PATCH 3.14 00/53] 3.14.74-stable review

On 07/25/2016 02:54 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.14.74 release. > There are 53 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 3.14 00/53] 3.14.74-stable review

On 07/25/2016 02:54 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.14.74 release. > There are 53 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 000/146] 4.4.16-stable review

On 07/25/2016 02:54 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.16 release. > There are 146 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 000/146] 4.4.16-stable review

On 07/25/2016 02:54 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.16 release. > There are 146 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.6 000/203] 4.6.5-stable review

On 07/25/2016 02:53 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.6.5 release. > There are 203 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.6 000/203] 4.6.5-stable review

On 07/25/2016 02:53 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.6.5 release. > There are 203 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH v3 3/9] media: adv7180: add support for NEWAVMODE

On 07/25/2016 03:24 PM, Ian Arkver wrote: > On 25/07/16 23:04, Steve Longerbeam wrote: >> >> >> On 07/25/2016 12:36 PM, Ian Arkver wrote: >>> On 25/07/16 18:55, Steve Longerbeam wrote: On 07/25/2016 05:04 AM, Ian Arkver wrote: > On 23/07/16 18:00, Steve Longerbeam wrote: >> >>

Re: [PATCH v3 3/9] media: adv7180: add support for NEWAVMODE

On 07/25/2016 03:24 PM, Ian Arkver wrote: > On 25/07/16 23:04, Steve Longerbeam wrote: >> >> >> On 07/25/2016 12:36 PM, Ian Arkver wrote: >>> On 25/07/16 18:55, Steve Longerbeam wrote: On 07/25/2016 05:04 AM, Ian Arkver wrote: > On 23/07/16 18:00, Steve Longerbeam wrote: >> >>

Re: [PATCH 1/4] usb: gadget: f_midi: fixed endianness when using wMaxPacketSize

Hi, On 26 July 2016 at 07:15, Felipe F. Tonello wrote: > USB spec specifies wMaxPacketSize to be little endian (as other properties), > so when using this variable in the driver we should convert to the current > CPU endianness if necessary. > > Signed-off-by: Felipe F.

Re: [PATCH 1/4] usb: gadget: f_midi: fixed endianness when using wMaxPacketSize

Hi, On 26 July 2016 at 07:15, Felipe F. Tonello wrote: > USB spec specifies wMaxPacketSize to be little endian (as other properties), > so when using this variable in the driver we should convert to the current > CPU endianness if necessary. > > Signed-off-by: Felipe F. Tonello > --- >

Re: [PATCH 12/15] staging/lustre: Add spaces preferred around that '{+,-,*,/,|,<<,>>,&}'

On Sat, 2016-07-23 at 14:01 -0400, Oleg Drokin wrote: > On Jul 23, 2016, at 1:31 PM, Joe Perches wrote: [] > > And lustre seems to use types with unnecessary __ prefixes. > Need to see if this file is included in userspace where the __ is needed. Maybe it'd be good to change the top level

Re: [PATCH 12/15] staging/lustre: Add spaces preferred around that '{+,-,*,/,|,<<,>>,&}'

On Sat, 2016-07-23 at 14:01 -0400, Oleg Drokin wrote: > On Jul 23, 2016, at 1:31 PM, Joe Perches wrote: [] > > And lustre seems to use types with unnecessary __ prefixes. > Need to see if this file is included in userspace where the __ is needed. Maybe it'd be good to change the top level

Re: [PATCH v3] mem-hotplug: alloc new page from a nearest neighbor node when mem-offline

On 2016/7/26 4:51, Andrew Morton wrote: > On Mon, 25 Jul 2016 17:53:15 +0800 Xishi Qiu wrote: > >> Subject: [PATCH v3] mem-hotplug: alloc new page from a nearest neighbor node >> when mem-offline > > argh. > > This is "v3" but there is no v1 and no v2. Please don't

Re: [PATCH v3] mem-hotplug: alloc new page from a nearest neighbor node when mem-offline

On 2016/7/26 4:51, Andrew Morton wrote: > On Mon, 25 Jul 2016 17:53:15 +0800 Xishi Qiu wrote: > >> Subject: [PATCH v3] mem-hotplug: alloc new page from a nearest neighbor node >> when mem-offline > > argh. > > This is "v3" but there is no v1 and no v2. Please don't change the > name of

Re: [PATCH 1/3] memory: mediatek: Add a new interface mtk_smi_larb_is_ready

On Mon, 2016-07-25 at 10:39 +0200, Matthias Brugger wrote: > > On 20/07/16 05:01, Yong Wu wrote: > > Currently the iommu consumer always call iommu_present to get whether > > the iommu is ready. But in MTK IOMMU, this function can't indicate > > this. The IOMMU call

Re: [PATCH 1/3] memory: mediatek: Add a new interface mtk_smi_larb_is_ready

On Mon, 2016-07-25 at 10:39 +0200, Matthias Brugger wrote: > > On 20/07/16 05:01, Yong Wu wrote: > > Currently the iommu consumer always call iommu_present to get whether > > the iommu is ready. But in MTK IOMMU, this function can't indicate > > this. The IOMMU call

Re: [RFC PATCH 0/5] USB Audio Gadget refactoring

On Fri, Jul 15, 2016 at 10:43 AM, Clemens Ladisch wrote: >>> On Tue, May 24, 2016 at 2:50 AM, Ruslan Bilovol >>> wrote: it may break current usecase for some people > > And what are the benefits that justify breaking the kernel API? Main

Re: [RFC PATCH 0/5] USB Audio Gadget refactoring

On Fri, Jul 15, 2016 at 10:43 AM, Clemens Ladisch wrote: >>> On Tue, May 24, 2016 at 2:50 AM, Ruslan Bilovol >>> wrote: it may break current usecase for some people > > And what are the benefits that justify breaking the kernel API? Main limitation with current f_uac1 design is - it can

Re: [RFC] mm: bail out in shrin_inactive_list

On Mon, Jul 25, 2016 at 10:29:09AM +0100, Mel Gorman wrote: > There is a typo in the subject line. > > On Mon, Jul 25, 2016 at 04:51:59PM +0900, Minchan Kim wrote: > > With node-lru, if there are enough reclaimable pages in highmem > > but nothing in lowmem, VM can try to shrink inactive list

Re: [RFC] mm: bail out in shrin_inactive_list

On Mon, Jul 25, 2016 at 10:29:09AM +0100, Mel Gorman wrote: > There is a typo in the subject line. > > On Mon, Jul 25, 2016 at 04:51:59PM +0900, Minchan Kim wrote: > > With node-lru, if there are enough reclaimable pages in highmem > > but nothing in lowmem, VM can try to shrink inactive list

Re: [RFC PATCH v3 00/13] ACPI IORT ARM SMMU v3 support

On Mon, Jul 25, 2016 at 09:36:41AM +0100, Lorenzo Pieralisi wrote: > On Mon, Jul 25, 2016 at 01:53:32PM +0800, Dennis Chen wrote: > > Hi > > On Wed, Jul 20, 2016 at 12:23:22PM +0100, Lorenzo Pieralisi wrote: > > > This RFC patch series is v3 of a previous posting: > > > > > >

Re: [RFC PATCH v3 00/13] ACPI IORT ARM SMMU v3 support

On Mon, Jul 25, 2016 at 09:36:41AM +0100, Lorenzo Pieralisi wrote: > On Mon, Jul 25, 2016 at 01:53:32PM +0800, Dennis Chen wrote: > > Hi > > On Wed, Jul 20, 2016 at 12:23:22PM +0100, Lorenzo Pieralisi wrote: > > > This RFC patch series is v3 of a previous posting: > > > > > >

Re: [PATCH v2] include: mman: Use bool instead of int for the return value of arch_validate_prot

Andrew Morton writes: > On Mon, 25 Jul 2016 15:10:06 +1000 Michael Ellerman > wrote: >> cheng...@emindsoft.com.cn writes: >> > From: Chen Gang >> > >> > For pure bool function's return value, bool is a little better

Re: [PATCH v2] include: mman: Use bool instead of int for the return value of arch_validate_prot

Andrew Morton writes: > On Mon, 25 Jul 2016 15:10:06 +1000 Michael Ellerman > wrote: >> cheng...@emindsoft.com.cn writes: >> > From: Chen Gang >> > >> > For pure bool function's return value, bool is a little better more or >> > less than int. >> > >> > Signed-off-by: Chen Gang >> >> LGTM.

Re: [PATCH v3 6/7] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc

Hi Chanwoo Choi, On 2016年07月25日 17:45, Chanwoo Choi wrote: Hi Lin, On 2016년 07월 25일 17:47, hl wrote: Hi Chanwoo Choi, On 2016年07月25日 14:01, Chanwoo Choi wrote: Hi Lin, I'm glad to support the for dmc ddr clock scaling with devfreq/devfreq-event. But, I think that you have to use the

Re: [PATCH v3 6/7] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc

Hi Chanwoo Choi, On 2016年07月25日 17:45, Chanwoo Choi wrote: Hi Lin, On 2016년 07월 25일 17:47, hl wrote: Hi Chanwoo Choi, On 2016年07月25日 14:01, Chanwoo Choi wrote: Hi Lin, I'm glad to support the for dmc ddr clock scaling with devfreq/devfreq-event. But, I think that you have to use the

Re: [PATCH v3 1/7] firmware: rockchip: sip: Add rockchip SIP runtime service

Hi Sudeep Holla, On 2016年07月26日 01:36, Sudeep Holla wrote: On 22/07/16 21:50, Heiko Stübner wrote: Hi again, one bigger thing I noticed only now. Am Freitag, 22. Juli 2016, 17:07:14 schrieben Sie: diff --git a/drivers/firmware/rockchip_sip.c b/drivers/firmware/rockchip_sip.c new file mode

Re: [PATCH v3 1/7] firmware: rockchip: sip: Add rockchip SIP runtime service

Hi Sudeep Holla, On 2016年07月26日 01:36, Sudeep Holla wrote: On 22/07/16 21:50, Heiko Stübner wrote: Hi again, one bigger thing I noticed only now. Am Freitag, 22. Juli 2016, 17:07:14 schrieben Sie: diff --git a/drivers/firmware/rockchip_sip.c b/drivers/firmware/rockchip_sip.c new file mode

Re: [PATCH net-next v7 0/2] bpf: add bpf_probe_write_user helper & example

From: Sargun Dhillon Date: Mon, 25 Jul 2016 05:54:29 -0700 > This patch series contains two patches that add support for a probe_write > helper to BPF programs. This allows them to manipulate user memory during > the course of tracing. The second patch in the series has an

Re: [PATCH net-next v7 0/2] bpf: add bpf_probe_write_user helper & example

From: Sargun Dhillon Date: Mon, 25 Jul 2016 05:54:29 -0700 > This patch series contains two patches that add support for a probe_write > helper to BPF programs. This allows them to manipulate user memory during > the course of tracing. The second patch in the series has an example that > uses

Re: [PATCH v9 0/7] Make cpuid <-> nodeid mapping persistent

Hello, On Mon, Jul 25, 2016 at 05:25:49PM -0700, Andrew Morton wrote: > > Yeah, that was one of the early approaches. The issue isn't limited > > to wq. Any memory allocation can have similar issues of underlying > > node association changing and we don't have any synchronization > > mechanism

Re: [PATCH v9 0/7] Make cpuid <-> nodeid mapping persistent

Hello, On Mon, Jul 25, 2016 at 05:25:49PM -0700, Andrew Morton wrote: > > Yeah, that was one of the early approaches. The issue isn't limited > > to wq. Any memory allocation can have similar issues of underlying > > node association changing and we don't have any synchronization > > mechanism

Re: [PATCH v2 02/10] userns: Add per user namespace sysctls.

David Miller writes: > From: ebied...@xmission.com (Eric W. Biederman) > Date: Mon, 25 Jul 2016 19:02:01 -0500 > >>Which means this change gets has to wait for next cycle. > > Ok. For clarity I intend to merge these changes through the userns tree, when the

Re: [PATCH v4 12/12] mm: SLUB hardened usercopy support

On 07/25/2016 01:45 PM, Kees Cook wrote: On Mon, Jul 25, 2016 at 12:16 PM, Laura Abbott wrote: On 07/20/2016 01:27 PM, Kees Cook wrote: Under CONFIG_HARDENED_USERCOPY, this adds object size checking to the SLUB allocator to catch any copies that may span objects. Includes

Re: [PATCH] gtp: #define #define _GTP_H_ and not #define _GTP_H

From: Colin King Date: Sun, 24 Jul 2016 19:24:09 +0100 > From: Colin Ian King > > Fix clang build warning: > > ./include/net/gtp.h:1:9: warning: '_GTP_H_' is used as a header > guard here, followed by #define of a different macro

Re: [PATCH v4 12/12] mm: SLUB hardened usercopy support

On 07/25/2016 01:45 PM, Kees Cook wrote: On Mon, Jul 25, 2016 at 12:16 PM, Laura Abbott wrote: On 07/20/2016 01:27 PM, Kees Cook wrote: Under CONFIG_HARDENED_USERCOPY, this adds object size checking to the SLUB allocator to catch any copies that may span objects. Includes a redzone handling

Re: [PATCH] gtp: #define #define _GTP_H_ and not #define _GTP_H

From: Colin King Date: Sun, 24 Jul 2016 19:24:09 +0100 > From: Colin Ian King > > Fix clang build warning: > > ./include/net/gtp.h:1:9: warning: '_GTP_H_' is used as a header > guard here, followed by #define of a different macro [-Wheader-guard] > > fix by defining _GTP_H_ and not _GTP_H >

Re: [PATCH v2 02/10] userns: Add per user namespace sysctls.

David Miller writes: > From: ebied...@xmission.com (Eric W. Biederman) > Date: Mon, 25 Jul 2016 19:02:01 -0500 > >>Which means this change gets has to wait for next cycle. > > Ok. For clarity I intend to merge these changes through the userns tree, when the issues are resolved. I

[PATCHv1, RFC 12/33] truncate: make sure invalidate_mapping_pages() can discard huge pages

invalidate_inode_page() has expectation about page_count() of the page -- if it's not 2 (one to caller, one to radix-tree), it will not be dropped. That condition almost never met for THPs -- tail pages are pinned to the pagevec. Let's drop them, before calling invalidate_inode_page().

[PATCHv1, RFC 33/33] ext4, vfs: add huge= mount option

The same four values as in tmpfs case. Signed-off-by: Kirill A. Shutemov --- fs/ext4/ext4.h | 5 + fs/ext4/inode.c | 26 +- fs/ext4/super.c | 19 +++ 3 files changed, 45 insertions(+), 5 deletions(-) diff --git

[PATCHv1, RFC 12/33] truncate: make sure invalidate_mapping_pages() can discard huge pages

invalidate_inode_page() has expectation about page_count() of the page -- if it's not 2 (one to caller, one to radix-tree), it will not be dropped. That condition almost never met for THPs -- tail pages are pinned to the pagevec. Let's drop them, before calling invalidate_inode_page().

[PATCHv1, RFC 33/33] ext4, vfs: add huge= mount option

The same four values as in tmpfs case. Signed-off-by: Kirill A. Shutemov --- fs/ext4/ext4.h | 5 + fs/ext4/inode.c | 26 +- fs/ext4/super.c | 19 +++ 3 files changed, 45 insertions(+), 5 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h

[PATCHv1, RFC 01/33] tools: Add WARN_ON_ONCE

From: Matthew Wilcox The radix tree uses its own buggy WARN_ON_ONCE. Replace it with the definition from asm-generic/bug.h Signed-off-by: Matthew Wilcox Signed-off-by: Kirill A. Shutemov ---

[PATCHv1, RFC 28/33] ext4: handle huge pages in __ext4_block_zero_page_range()

As the function handles zeroing range only within one block, the required changes are trivial, just remove assuption on page size. Signed-off-by: Kirill A. Shutemov --- fs/ext4/inode.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git

[PATCHv1, RFC 16/33] filemap: handle huge pages in filemap_fdatawait_range()

We writeback whole huge page a time. Signed-off-by: Kirill A. Shutemov --- mm/filemap.c | 5 + 1 file changed, 5 insertions(+) diff --git a/mm/filemap.c b/mm/filemap.c index ad73b99c5ba7..3d46db277e73 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -371,9

[PATCHv1, RFC 00/33] ext4: support of huge pages

Here's the first version of my patchset which intended to bring huge pages to ext4. It's not yet ready for applying or serious use, but good enough to show the approach. The basics are the same as with tmpfs[1] which is in -mm tree and ext4 built on of it. The main difference is that we need to

[PATCHv1, RFC 21/33] fs: make block_read_full_page() be able to read huge page

The approach is straight-forward: for compound pages we read out whole huge page. For huge page we cannot have array of buffer head pointers on stack -- it's 4096 pointers on x86-64 -- 'arr' is allocated with kmalloc() for huge pages. Signed-off-by: Kirill A. Shutemov

[PATCHv1, RFC 09/33] page-flags: relax page flag poliry for PG_error and PG_writeback

These flags are in use for filesystems with backing storage. Signed-off-by: Kirill A. Shutemov --- include/linux/page-flags.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h index

[PATCHv1, RFC 16/33] filemap: handle huge pages in filemap_fdatawait_range()

We writeback whole huge page a time. Signed-off-by: Kirill A. Shutemov --- mm/filemap.c | 5 + 1 file changed, 5 insertions(+) diff --git a/mm/filemap.c b/mm/filemap.c index ad73b99c5ba7..3d46db277e73 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -371,9 +371,14 @@ static int

[PATCHv1, RFC 00/33] ext4: support of huge pages

Here's the first version of my patchset which intended to bring huge pages to ext4. It's not yet ready for applying or serious use, but good enough to show the approach. The basics are the same as with tmpfs[1] which is in -mm tree and ext4 built on of it. The main difference is that we need to

[PATCHv1, RFC 21/33] fs: make block_read_full_page() be able to read huge page

The approach is straight-forward: for compound pages we read out whole huge page. For huge page we cannot have array of buffer head pointers on stack -- it's 4096 pointers on x86-64 -- 'arr' is allocated with kmalloc() for huge pages. Signed-off-by: Kirill A. Shutemov --- fs/buffer.c

[PATCHv1, RFC 01/33] tools: Add WARN_ON_ONCE

From: Matthew Wilcox The radix tree uses its own buggy WARN_ON_ONCE. Replace it with the definition from asm-generic/bug.h Signed-off-by: Matthew Wilcox Signed-off-by: Kirill A. Shutemov --- tools/include/asm/bug.h | 11 +++ tools/testing/radix-tree/Makefile| 2 +-

[PATCHv1, RFC 28/33] ext4: handle huge pages in __ext4_block_zero_page_range()

As the function handles zeroing range only within one block, the required changes are trivial, just remove assuption on page size. Signed-off-by: Kirill A. Shutemov --- fs/ext4/inode.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c

[PATCHv1, RFC 09/33] page-flags: relax page flag poliry for PG_error and PG_writeback

These flags are in use for filesystems with backing storage. Signed-off-by: Kirill A. Shutemov --- include/linux/page-flags.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h index 74e4dda91238..de90abb7c84e 100644

[PATCHv1, RFC 07/33] mm, shmem: swich huge tmpfs to multi-order radix-tree entries

We would need to use multi-order radix-tree entires for ext4 and other filesystems to have coherent view on tags (dirty/towrite) in the tree. This patch converts huge tmpfs implementation to multi-order entries, so we will be able to use the same code patch for all filesystems. Signed-off-by:

[PATCHv1, RFC 11/33] thp: allow splitting non-shmem file-backed THPs

split_huge_page() is ready to handle file-backed huge pages, we only need to remove one guarding VM_BUG_ON_PAGE(). Signed-off-by: Kirill A. Shutemov --- mm/huge_memory.c | 1 - 1 file changed, 1 deletion(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index

[PATCHv1, RFC 32/33] mm, fs, ext4: expand use of page_mapping() and page_to_pgoff()

With huge pages in page cache we see tail pages in more code paths. This patch replaces direct access to struct page fields with macros which can handle tail pages properly. Signed-off-by: Kirill A. Shutemov --- fs/buffer.c | 2 +- fs/ext4/inode.c |

[PATCHv1, RFC 20/33] thp: introduce hpage_size() and hpage_mask()

Introduce new helpers which return size/mask of the page: HPAGE_PMD_SIZE/HPAGE_PMD_MASK if the page is PageTransHuge() and PAGE_SIZE/PAGE_MASK otherwise. Signed-off-by: Kirill A. Shutemov --- include/linux/huge_mm.h | 16 1 file changed, 16

Re: [PATCH v5 00/15] allow BFLT executables on systems with a MMU

On 25/07/16 01:30, Nicolas Pitre wrote: > This series provides the necessary changes to allow "flat" executable > binaries meant for no-MMU systems to actually run on systems with a MMU. > Also thrown in are various cleanups to binfmt_flat.c. > > This can also be found in the following git repo:

[PATCHv1, RFC 14/33] filemap: handle huge pages in do_generic_file_read()

Most of work happans on head page. Only when we need to do copy data to userspace we find relevant subpage. We are still limited by PAGE_SIZE per iteration. Lifting this limitation would require some more work. Signed-off-by: Kirill A. Shutemov --- mm/filemap.c

[PATCHv1, RFC 31/33] WIP: ext4: handle writeback with huge pages

Modify mpage_map_and_submit_buffers() to do writeback with huge pages. This is somewhat unstable. I have hard time see full picture yet. More work is required. Not-yet-signed-off-by: Kirill A. Shutemov --- fs/ext4/inode.c | 40

[PATCHv1, RFC 29/33] ext4: handle huge pages in ext4_da_write_end()

Call ext4_da_should_update_i_disksize() for head page with offset relative to head page. Signed-off-by: Kirill A. Shutemov --- fs/ext4/inode.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index

[PATCHv1, RFC 02/33] radix tree test suite: Allow GFP_ATOMIC allocations to fail

From: Matthew Wilcox In order to test the preload code, it is necessary to fail GFP_ATOMIC allocations, which requires defining GFP_KERNEL and GFP_ATOMIC properly. Remove the obsolete __GFP_WAIT and copy the definitions of the __GFP flags which are used from the kernel

[PATCHv1, RFC 25/33] ext4: make ext4_mpage_readpages() hugepage-aware

This patch modifies ext4_mpage_readpages() to deal with huge pages. We read out 2M at once, so we have to alloc (HPAGE_PMD_NR * blocks_per_page) sector_t for that. I'm not entirely happy with kmalloc in this codepath, but don't see any other option. Signed-off-by: Kirill A. Shutemov

<    1   2   3   4   5   6   7   8   9   10   >