Re: Improving documentation of parent-ID field in /proc/PID/mountinfo

On Mon, Nov 13, 2017 at 07:02:21AM +0100, Michael Kerrisk (man-pages) wrote: > Hello Ram, > > Long ago (2.6.29) you added the /proc/PID/mountinfo file and > associated documentation in Documentation/filesystems/proc.txt. Later, > I pasted much of that documentation into the proc(5) manual page. >

Re: Improving documentation of parent-ID field in /proc/PID/mountinfo

On Mon, Nov 13, 2017 at 07:02:21AM +0100, Michael Kerrisk (man-pages) wrote: > Hello Ram, > > Long ago (2.6.29) you added the /proc/PID/mountinfo file and > associated documentation in Documentation/filesystems/proc.txt. Later, > I pasted much of that documentation into the proc(5) manual page. >

[GIT PULL] RAS updates for v4.15

Linus, Please pull the latest ras-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git ras-core-for-linus # HEAD: 783ca517bfd62ca516178712775e4b273292d5b1 x86/MCE/AMD: Fix mce_severity_amd_smca() signature Two minor updates to AMD SMCA support, plus a

[GIT PULL] RAS updates for v4.15

Linus, Please pull the latest ras-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git ras-core-for-linus # HEAD: 783ca517bfd62ca516178712775e4b273292d5b1 x86/MCE/AMD: Fix mce_severity_amd_smca() signature Two minor updates to AMD SMCA support, plus a

RE: [PATCH v5 0/5] fw_cfg: add DMA operations & etc/vmcoreinfo support

Marc-Andre, It looks to me that the 4th and 5th patches somehow has not been sent. Could you send them, too? I'd like them to actually build and run the kernel for testing. > -Original Message- > From: linux-kernel-ow...@vger.kernel.org > [mailto:linux-kernel-ow...@vger.kernel.org] On

RE: [PATCH v5 0/5] fw_cfg: add DMA operations & etc/vmcoreinfo support

Marc-Andre, It looks to me that the 4th and 5th patches somehow has not been sent. Could you send them, too? I'd like them to actually build and run the kernel for testing. > -Original Message- > From: linux-kernel-ow...@vger.kernel.org > [mailto:linux-kernel-ow...@vger.kernel.org] On

[GIT PULL] perf updates for v4.15

Linus, Please pull the latest perf-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-core-for-linus # HEAD: fcdfafcb73be8fa45909327bbddca46fb362a675 kprobes: Don't spam the build log with deprecation warnings The main changes in this cycle

[GIT PULL] perf updates for v4.15

Linus, Please pull the latest perf-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-core-for-linus # HEAD: fcdfafcb73be8fa45909327bbddca46fb362a675 kprobes: Don't spam the build log with deprecation warnings The main changes in this cycle

[PATCH] perf tool: Fix build failure when NO_AUXTRACE=1

Perf tool fails with following build failure when AUXTRACE is not set: $ make NO_AUXTRACE=1 builtin-script.c: In function 'perf_script__process_auxtrace_info': util/auxtrace.h:608:44: error: called object is not a function or function pointer #define perf_event__process_auxtrace_info 0

[PATCH] perf tool: Fix build failure when NO_AUXTRACE=1

Perf tool fails with following build failure when AUXTRACE is not set: $ make NO_AUXTRACE=1 builtin-script.c: In function 'perf_script__process_auxtrace_info': util/auxtrace.h:608:44: error: called object is not a function or function pointer #define perf_event__process_auxtrace_info 0

Re: [PATCH] perf/core: fast breakpoint modification via _IOC_MODIFY_BREAKPOINT

On Sun, Nov 12, 2017 at 11:09:23AM -0800, Milind Chabbi wrote: > , > > On Thu, Nov 9, 2017 at 10:59 AM, Milind Chabbi > wrote: > > SNIP > > > > On Thu, Nov 9, 2017 at 5:12 AM, Jiri Olsa wrote: > >> > >> > >> how about something like below (untested)

Re: [PATCH] perf/core: fast breakpoint modification via _IOC_MODIFY_BREAKPOINT

On Sun, Nov 12, 2017 at 11:09:23AM -0800, Milind Chabbi wrote: > , > > On Thu, Nov 9, 2017 at 10:59 AM, Milind Chabbi > wrote: > > SNIP > > > > On Thu, Nov 9, 2017 at 5:12 AM, Jiri Olsa wrote: > >> > >> > >> how about something like below (untested) > >> > >> looks like there's no irq caller

Crypto Update for 4.15

Hi Linus: Here is the crypto update for 4.15: API: - Disambiguate EBUSY when queueing crypto request by adding ENOSPC. This change touches code outside the crypto API. - Reset settings when empty string is written to rng_current. Algorithms: - Add OSCCA SM3 secure hash. Drivers: - Remove

Crypto Update for 4.15

Hi Linus: Here is the crypto update for 4.15: API: - Disambiguate EBUSY when queueing crypto request by adding ENOSPC. This change touches code outside the crypto API. - Reset settings when empty string is written to rng_current. Algorithms: - Add OSCCA SM3 secure hash. Drivers: - Remove

[PATCH] spi: spi-fsl-dspi: add SPI_LSB_FIRST to driver capabilities

The driver as well as the controller support the SPI lsb first mode. However, it's not possible to configure it e.g. when using spidev. Adding this flag to mode_bits resolves the issue and lsb first mode can be used. Signed-off-by: Kurt Kanzenbach ---

[PATCH] spi: spi-fsl-dspi: add SPI_LSB_FIRST to driver capabilities

The driver as well as the controller support the SPI lsb first mode. However, it's not possible to configure it e.g. when using spidev. Adding this flag to mode_bits resolves the issue and lsb first mode can be used. Signed-off-by: Kurt Kanzenbach --- drivers/spi/spi-fsl-dspi.c | 2 +- 1 file

Re: [PATCH v4 4/4] ARM64: dts: meson: drop "sana" clock from SAR ADC

Hi Kevin & others I'd like to just re-send the patch [4/4] (while leave others[1-3/4] unchanged), to have separated DT patch the for 32bit / 64bit platform. is this ok for you? On 11/12/17 09:33, Martin Blumenstingl wrote: > Hi Yixun, > > On Tue, Nov 7, 2017 at 3:10 PM, Yixun Lan

Re: [PATCH v4 4/4] ARM64: dts: meson: drop "sana" clock from SAR ADC

Hi Kevin & others I'd like to just re-send the patch [4/4] (while leave others[1-3/4] unchanged), to have separated DT patch the for 32bit / 64bit platform. is this ok for you? On 11/12/17 09:33, Martin Blumenstingl wrote: > Hi Yixun, > > On Tue, Nov 7, 2017 at 3:10 PM, Yixun Lan wrote:

RE: [PATCH 1/2] mm: drop migrate type checks from has_unmovable_pages

Hello Michal, > Date: Fri, 13 Oct 2017 14:00:12 +0200 > > From: Michal Hocko > > Michael has noticed that the memory offline tries to migrate kernel code > pages when doing echo 0 > /sys/devices/system/memory/memory0/online > > The current implementation will fail the

RE: [PATCH 1/2] mm: drop migrate type checks from has_unmovable_pages

Hello Michal, > Date: Fri, 13 Oct 2017 14:00:12 +0200 > > From: Michal Hocko > > Michael has noticed that the memory offline tries to migrate kernel code > pages when doing echo 0 > /sys/devices/system/memory/memory0/online > > The current implementation will fail the operation after

[GIT PULL] locking changes for v4.15

Linus, Please pull the latest locking-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking-core-for-linus # HEAD: 450cbdd0125cfa5d7bbf9e2a6b6961cc48d29730 locking/x86: Use LOCK ADD for smp_mb() instead of MFENCE The main changes in this cycle

[GIT PULL] locking changes for v4.15

Linus, Please pull the latest locking-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking-core-for-linus # HEAD: 450cbdd0125cfa5d7bbf9e2a6b6961cc48d29730 locking/x86: Use LOCK ADD for smp_mb() instead of MFENCE The main changes in this cycle

[GIT PULL] usercopy whitelisting for v4.15-rc1

Hi, Please pull these hardened usercopy whitelisting changes for v4.15-rc1. This significantly narrows the areas of memory that can be copied to/from userspace in the face of usercopy bugs. Thanks! -Kees The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff: Linux

[GIT PULL] usercopy whitelisting for v4.15-rc1

Hi, Please pull these hardened usercopy whitelisting changes for v4.15-rc1. This significantly narrows the areas of memory that can be copied to/from userspace in the face of usercopy bugs. Thanks! -Kees The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff: Linux

Re: [PATCH 4/4] kbuild: optimize object directory creation for incremental build

Hi Cao, 2017-11-10 19:58 GMT+09:00 Cao jin : > Masahiro-san > > On 11/09/2017 11:41 PM, Masahiro Yamada wrote: >> The previous commit largely optimized the object directory creation. >> We can optimize it more for incremental build. >> >> There are already *.cmd files

Re: [PATCH 4/4] kbuild: optimize object directory creation for incremental build

Hi Cao, 2017-11-10 19:58 GMT+09:00 Cao jin : > Masahiro-san > > On 11/09/2017 11:41 PM, Masahiro Yamada wrote: >> The previous commit largely optimized the object directory creation. >> We can optimize it more for incremental build. >> >> There are already *.cmd files in the output directory.

Re: [PATCH 2/3] Input: twl6040-vibra: fix child-node lookup

On 2017-11-11 17:43, Johan Hovold wrote: > Fix child-node lookup during probe, which ended up searching the whole > device tree depth-first starting at parent rather than just matching on > its children. > > Later sanity checks on node properties (which would likely be missing) > should prevent

Re: [PATCH 2/3] Input: twl6040-vibra: fix child-node lookup

On 2017-11-11 17:43, Johan Hovold wrote: > Fix child-node lookup during probe, which ended up searching the whole > device tree depth-first starting at parent rather than just matching on > its children. > > Later sanity checks on node properties (which would likely be missing) > should prevent

Re: [PATCH 1/3] Input: twl4030-vibra: fix sibling-node lookup

On 2017-11-11 17:43, Johan Hovold wrote: > A helper purported to look up a child node based on its name was using > the wrong of-helper and ended up prematurely freeing the parent of-node > while searching the whole device tree depth-first starting at the parent > node. > > Fixes: 64b9e4d803b1

Re: [PATCH 1/3] Input: twl4030-vibra: fix sibling-node lookup

On 2017-11-11 17:43, Johan Hovold wrote: > A helper purported to look up a child node based on its name was using > the wrong of-helper and ended up prematurely freeing the parent of-node > while searching the whole device tree depth-first starting at the parent > node. > > Fixes: 64b9e4d803b1

Re: [PATCH] KVM: x86: inject exceptions produced by x86_decode_insn

2017-11-10 17:49 GMT+08:00 Paolo Bonzini : > Sometimes, a processor might execute an instruction while another > processor is updating the page tables for that instruction's code page, > but before the TLB shootdown completes. The interesting case happens > if the page is in

Re: [PATCH] KVM: x86: inject exceptions produced by x86_decode_insn

2017-11-10 17:49 GMT+08:00 Paolo Bonzini : > Sometimes, a processor might execute an instruction while another > processor is updating the page tables for that instruction's code page, > but before the TLB shootdown completes. The interesting case happens > if the page is in the TLB. > > In

[GIT PULL] RCU updates for v4.15

Linus, Please pull the latest core-rcu-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-rcu-for-linus # HEAD: 72bc286b81d21404cdfecddf76b64c7163aac764 Merge branch 'for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into

[GIT PULL] RCU updates for v4.15

Linus, Please pull the latest core-rcu-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-rcu-for-linus # HEAD: 72bc286b81d21404cdfecddf76b64c7163aac764 Merge branch 'for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into

Re: [PATCHv4 3/6] powerpc64: Add .opd based function descriptor dereference

* Sergey Senozhatsky wrote (on 2017-11-10 08:48:27 +0900): > We are moving towards separate kernel and module function descriptor > dereference callbacks. This patch enables it for powerpc64. > > For pointers that belong to the kernel > - Added __start_opd and

Re: [PATCHv4 3/6] powerpc64: Add .opd based function descriptor dereference

* Sergey Senozhatsky wrote (on 2017-11-10 08:48:27 +0900): > We are moving towards separate kernel and module function descriptor > dereference callbacks. This patch enables it for powerpc64. > > For pointers that belong to the kernel > - Added __start_opd and __end_opd pointers, to track the

Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl

On Mon, Nov 13, 2017 at 11:38 AM, Tobin C. Harding wrote: > On Mon, Nov 13, 2017 at 11:16:28AM +0530, kaiwan.billimo...@gmail.com wrote: >> On Mon, 2017-11-13 at 09:21 +1100, Tobin C. Harding wrote: >> > On Fri, Nov 10, 2017 at 07:26:34PM +0530, kaiwan.billimo...@gmail.com >> >

Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl

On Mon, Nov 13, 2017 at 11:38 AM, Tobin C. Harding wrote: > On Mon, Nov 13, 2017 at 11:16:28AM +0530, kaiwan.billimo...@gmail.com wrote: >> On Mon, 2017-11-13 at 09:21 +1100, Tobin C. Harding wrote: >> > On Fri, Nov 10, 2017 at 07:26:34PM +0530, kaiwan.billimo...@gmail.com >> > wrote: >> > > On

[PATCH] KVM: X86: Avoid to handle first-time write when updating the pv stuffs each time

From: Wanpeng Li There is a logic to handle first-time write when updating the pvclock/wall clock/steal time shared memory pages each time, actually we should do this logic during pv stuffs setup if we suspect the version-field can't be guranteed to be initialized to

[PATCH] KVM: X86: Avoid to handle first-time write when updating the pv stuffs each time

From: Wanpeng Li There is a logic to handle first-time write when updating the pvclock/wall clock/steal time shared memory pages each time, actually we should do this logic during pv stuffs setup if we suspect the version-field can't be guranteed to be initialized to an even number by the

[GIT PULL] s390 updates for v4.15

Hello Linus, since Martin is on vacation you get the s390 pull request for the v4.15 merge window this time from me. Please pull from the 'for-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus to receive the following updates: Besides a lot of

[GIT PULL] s390 updates for v4.15

Hello Linus, since Martin is on vacation you get the s390 pull request for the v4.15 merge window this time from me. Please pull from the 'for-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus to receive the following updates: Besides a lot of

drivers/firmware/google/vpd.c: duplicate sysfs file

sysfs: cannot create duplicate filename '/devices/platform/vpd' on the second load of this driver. I.e., modprobe vpd-sysfs rmmod vpd-sysfs modprobe vpd-sysfs [boom] on 4.14-rc8 -- ~Randy

drivers/firmware/google/vpd.c: duplicate sysfs file

sysfs: cannot create duplicate filename '/devices/platform/vpd' on the second load of this driver. I.e., modprobe vpd-sysfs rmmod vpd-sysfs modprobe vpd-sysfs [boom] on 4.14-rc8 -- ~Randy

[PATCH IMPROVEMENT/BUGFIX 0/4] block, bfq: increase sustainable IOPS and fix a bug

Hi, these patches address the following issue, raised and discussed in [1]. BFQ provides a proportional share policy for the blkio controller. In this respect, BFQ updates the I/O accounting related to its policy, i.e., the statistics contained in the special files blkio.bfq.* in blkio groups

[PATCH BUGFIX/IMPROVEMENT 2/4] block, bfq: add missing invocations of bfqg_stats_update_io_add/remove

From: Luca Miccio bfqg_stats_update_io_add and bfqg_stats_update_io_remove are to be invoked, respectively, when an I/O request enters and when an I/O request exits the scheduler. Unfortunately, bfq does not fully comply with this scheme, because it does not invoke these

[PATCH IMPROVEMENT/BUGFIX 0/4] block, bfq: increase sustainable IOPS and fix a bug

Hi, these patches address the following issue, raised and discussed in [1]. BFQ provides a proportional share policy for the blkio controller. In this respect, BFQ updates the I/O accounting related to its policy, i.e., the statistics contained in the special files blkio.bfq.* in blkio groups

[PATCH BUGFIX/IMPROVEMENT 2/4] block, bfq: add missing invocations of bfqg_stats_update_io_add/remove

From: Luca Miccio bfqg_stats_update_io_add and bfqg_stats_update_io_remove are to be invoked, respectively, when an I/O request enters and when an I/O request exits the scheduler. Unfortunately, bfq does not fully comply with this scheme, because it does not invoke these functions for requests

[PATCH BUGFIX/IMPROVEMENT 4/4] block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP

From: Luca Miccio BFQ currently creates, and updates, its own instance of the whole set of blkio statistics that cfq creates. Yet, from the comments of Tejun Heo in [1], it turned out that most of these statistics are meant/useful only for debugging. This commit makes BFQ

[PATCH BUGFIX/IMPROVEMENT 4/4] block, bfq: move debug blkio stats behind CONFIG_DEBUG_BLK_CGROUP

From: Luca Miccio BFQ currently creates, and updates, its own instance of the whole set of blkio statistics that cfq creates. Yet, from the comments of Tejun Heo in [1], it turned out that most of these statistics are meant/useful only for debugging. This commit makes BFQ create the latter,

[PATCH BUGFIX/IMPROVEMENT 1/4] doc, block, bfq: update max IOPS sustainable with BFQ

We have investigated more deeply the performance of BFQ, in terms of number of IOPS that can be processed by the CPU when BFQ is used as I/O scheduler. In more detail, using the script [1], we have measured the number of IOPS reached on top of a null block device configured with zero latency, as a

[PATCH BUGFIX/IMPROVEMENT 1/4] doc, block, bfq: update max IOPS sustainable with BFQ

We have investigated more deeply the performance of BFQ, in terms of number of IOPS that can be processed by the CPU when BFQ is used as I/O scheduler. In more detail, using the script [1], we have measured the number of IOPS reached on top of a null block device configured with zero latency, as a

[PATCH BUGFIX/IMPROVEMENT 3/4] block, bfq: update blkio stats outside the scheduler lock

bfq invokes various blkg_*stats_* functions to update the statistics contained in the special files blkio.bfq.* in the blkio controller groups, i.e., the I/O accounting related to the proportional-share policy provided by bfq. The execution of these functions takes a considerable percentage, about

[PATCH BUGFIX/IMPROVEMENT 3/4] block, bfq: update blkio stats outside the scheduler lock

bfq invokes various blkg_*stats_* functions to update the statistics contained in the special files blkio.bfq.* in the blkio controller groups, i.e., the I/O accounting related to the proportional-share policy provided by bfq. The execution of these functions takes a considerable percentage, about

linux-next: Tree for Nov 13

Hi all, Please do not add any v4.16 material to your linux-next included trees until v4.15-rc1 has been released. Changes since 20171110: The powerpc tree still had its build failure for which I applied a patch The keys tree gained a build failure so I used the version from next-20171110.

linux-next: Tree for Nov 13

Hi all, Please do not add any v4.16 material to your linux-next included trees until v4.15-rc1 has been released. Changes since 20171110: The powerpc tree still had its build failure for which I applied a patch The keys tree gained a build failure so I used the version from next-20171110.

Re: linux-next: manual merge of the arm64 tree with Linus' tree

Hi all, On Wed, 1 Nov 2017 07:57:23 +1100 Stephen Rothwell wrote: > > Today's linux-next merge of the arm64 tree got a conflict in: > > drivers/acpi/arm64/iort.c > > between commit: > > 37f6b42e9c29 ("ACPI/IORT: Fix PCI ACS enablement") > > from Linus' tree and

Re: linux-next: manual merge of the arm64 tree with Linus' tree

Hi all, On Wed, 1 Nov 2017 07:57:23 +1100 Stephen Rothwell wrote: > > Today's linux-next merge of the arm64 tree got a conflict in: > > drivers/acpi/arm64/iort.c > > between commit: > > 37f6b42e9c29 ("ACPI/IORT: Fix PCI ACS enablement") > > from Linus' tree and commit: > >

Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl

On Mon, Nov 13, 2017 at 11:16:28AM +0530, kaiwan.billimo...@gmail.com wrote: > On Mon, 2017-11-13 at 09:21 +1100, Tobin C. Harding wrote: > > On Fri, Nov 10, 2017 at 07:26:34PM +0530, kaiwan.billimo...@gmail.com > > wrote: > > > On Tue, 2017-11-07 at 21:32 +1100, Tobin C. Harding wrote: > > > >

Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl

On Mon, Nov 13, 2017 at 11:16:28AM +0530, kaiwan.billimo...@gmail.com wrote: > On Mon, 2017-11-13 at 09:21 +1100, Tobin C. Harding wrote: > > On Fri, Nov 10, 2017 at 07:26:34PM +0530, kaiwan.billimo...@gmail.com > > wrote: > > > On Tue, 2017-11-07 at 21:32 +1100, Tobin C. Harding wrote: > > > >

Improving documentation of parent-ID field in /proc/PID/mountinfo

Hello Ram, Long ago (2.6.29) you added the /proc/PID/mountinfo file and associated documentation in Documentation/filesystems/proc.txt. Later, I pasted much of that documentation into the proc(5) manual page. That documentation says of the second field in the file: [[ This file contains lines

Improving documentation of parent-ID field in /proc/PID/mountinfo

Hello Ram, Long ago (2.6.29) you added the /proc/PID/mountinfo file and associated documentation in Documentation/filesystems/proc.txt. Later, I pasted much of that documentation into the proc(5) manual page. That documentation says of the second field in the file: [[ This file contains lines

Re: linux-next: manual merge of the tip tree with the net-next tree

Hi all, On Mon, 30 Oct 2017 20:55:47 + Mark Brown wrote: > > Today's linux-next merge of the tip tree got a conflict in: > > net/ipv4/tcp_output.c > > between commit: > > 6aa7de059173a ("locking/atomics: COCCINELLE/treewide: Convert trivial > ACCESS_ONCE()

Re: linux-next: manual merge of the tip tree with the net-next tree

Hi all, On Mon, 30 Oct 2017 20:55:47 + Mark Brown wrote: > > Today's linux-next merge of the tip tree got a conflict in: > > net/ipv4/tcp_output.c > > between commit: > > 6aa7de059173a ("locking/atomics: COCCINELLE/treewide: Convert trivial > ACCESS_ONCE() patterns to

Re: linux-next: manual merge of the devicetree tree with the drm tree

Hi all, On Mon, 30 Oct 2017 20:37:56 + Mark Brown wrote: > > Today's linux-next merge of the devicetree tree got a conflict in: > > drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c > > between commit: > > 44cd3939c111b7 ("drm/tilcdc: Remove redundant OF_DETACHED flag

Re: linux-next: manual merge of the devicetree tree with the drm tree

Hi all, On Mon, 30 Oct 2017 20:37:56 + Mark Brown wrote: > > Today's linux-next merge of the devicetree tree got a conflict in: > > drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c > > between commit: > > 44cd3939c111b7 ("drm/tilcdc: Remove redundant OF_DETACHED flag setting") > > from

Re: linux-next: manual merge of the ext4 tree with the fscrypt tree

Hi all, On Mon, 30 Oct 2017 14:48:04 + Mark Brown wrote: > > Today's linux-next merge of the ext4 tree got a conflict in: > > fs/ext4/inode.c > > between commit: > > 2ee6a576be564272 ("fs, fscrypt: add an S_ENCRYPTED inode flag") > > from the fscrypt tree and

Re: linux-next: manual merge of the ext4 tree with the fscrypt tree

Hi all, On Mon, 30 Oct 2017 14:48:04 + Mark Brown wrote: > > Today's linux-next merge of the ext4 tree got a conflict in: > > fs/ext4/inode.c > > between commit: > > 2ee6a576be564272 ("fs, fscrypt: add an S_ENCRYPTED inode flag") > > from the fscrypt tree and commit: > >

linux-next: build warning after merge of the akpm-current tree

Hi Andrew, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: In file included from include/linux/printk.h:7:0, from include/linux/kernel.h:14, from lib/test_find_bit.c:28: lib/test_find_bit.c: In function

linux-next: build warning after merge of the akpm-current tree

Hi Andrew, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: In file included from include/linux/printk.h:7:0, from include/linux/kernel.h:14, from lib/test_find_bit.c:28: lib/test_find_bit.c: In function

[PATCH v2] coccinelle: orplus: reorganize to improve performance

Adding two #define constants is less common than performing & and | operations on them, so put the addition first to reduce the set of cases that have to be considered in detail. At the same time, add & and | patterns for both arguments of +, to account for commutativity and obtain more results.

[PATCH v2] coccinelle: orplus: reorganize to improve performance

Adding two #define constants is less common than performing & and | operations on them, so put the addition first to reduce the set of cases that have to be considered in detail. At the same time, add & and | patterns for both arguments of +, to account for commutativity and obtain more results.

[PATCH] timekeeping: Eliminate the useless declaration of ktime_get_raw_and_real_ts64()

Commit: ba26621e63ce ("time: Remove duplicated code in ktime_get_raw_and_real()") ... got rid of ktime_get_raw_and_real_ts64(), but left its declaration behind. Remove it. Signed-off-by: Dou Liyang --- include/linux/timekeeping.h | 6 -- 1 file changed, 6

[PATCH] timekeeping: Eliminate the useless declaration of ktime_get_raw_and_real_ts64()

Commit: ba26621e63ce ("time: Remove duplicated code in ktime_get_raw_and_real()") ... got rid of ktime_get_raw_and_real_ts64(), but left its declaration behind. Remove it. Signed-off-by: Dou Liyang --- include/linux/timekeeping.h | 6 -- 1 file changed, 6 deletions(-) diff --git

Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl

On Mon, 2017-11-13 at 09:21 +1100, Tobin C. Harding wrote: > On Fri, Nov 10, 2017 at 07:26:34PM +0530, kaiwan.billimo...@gmail.com > wrote: > > On Tue, 2017-11-07 at 21:32 +1100, Tobin C. Harding wrote: > > > Currently we are leaking addresses from the kernel to user space. > > > This > > >

Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl

On Mon, 2017-11-13 at 09:21 +1100, Tobin C. Harding wrote: > On Fri, Nov 10, 2017 at 07:26:34PM +0530, kaiwan.billimo...@gmail.com > wrote: > > On Tue, 2017-11-07 at 21:32 +1100, Tobin C. Harding wrote: > > > Currently we are leaking addresses from the kernel to user space. > > > This > > >

linux-next: build warning after merge of the akpm-current tree

Hi Andrew, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: In file included from include/linux/mmzone.h:17:0, from include/linux/mempolicy.h:10, from mm/mempolicy.c:70: mm/mempolicy.c: In function

linux-next: build warning after merge of the akpm-current tree

Hi Andrew, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: In file included from include/linux/mmzone.h:17:0, from include/linux/mempolicy.h:10, from mm/mempolicy.c:70: mm/mempolicy.c: In function

[PATCH] powerpc/perf: Add debugfs interface for imc-mode and imc-command

In memory Collection (IMC) counter pmu driver controls the ucode's execution state. At the system boot, IMC perf driver pause the ucode. Ucode state is changed to "running" only when any of the nest units are monitored or profiled using perf tool.

[PATCH] powerpc/perf: Add debugfs interface for imc-mode and imc-command

In memory Collection (IMC) counter pmu driver controls the ucode's execution state. At the system boot, IMC perf driver pause the ucode. Ucode state is changed to "running" only when any of the nest units are monitored or profiled using perf tool.

Re: [PATCH] powerpc/perf: Add debugfs interface for imc run-mode and run-status

Hi, Kindly ignore this version Thanks, Anju On Monday 13 November 2017 11:06 AM, Anju T Sudhakar wrote: In memory Collection (IMC) counter pmu driver controls the ucode's execution state. At the system boot, IMC perf driver pause the ucode. Ucode state is changed to "running" only when any

Re: [PATCH] powerpc/perf: Add debugfs interface for imc run-mode and run-status

Hi, Kindly ignore this version Thanks, Anju On Monday 13 November 2017 11:06 AM, Anju T Sudhakar wrote: In memory Collection (IMC) counter pmu driver controls the ucode's execution state. At the system boot, IMC perf driver pause the ucode. Ucode state is changed to "running" only when any

Re: linux-next: manual merge of the powerpc tree with Linus' tree

Hi all, On Mon, 30 Oct 2017 12:51:33 + Mark Brown wrote: > > Hi all, > > Today's linux-next merge of the powerpc tree got a conflict in: > > arch/powerpc/kvm/powerpc.c > > between commit: > > ac64115a66c1 ("KVM: PPC: Fix oops when checking KVM_CAP_PPC_HTM") > >

Re: linux-next: manual merge of the powerpc tree with Linus' tree

Hi all, On Mon, 30 Oct 2017 12:51:33 + Mark Brown wrote: > > Hi all, > > Today's linux-next merge of the powerpc tree got a conflict in: > > arch/powerpc/kvm/powerpc.c > > between commit: > > ac64115a66c1 ("KVM: PPC: Fix oops when checking KVM_CAP_PPC_HTM") > > from Linus' tree and

[PATCH] powerpc/perf: Add debugfs interface for imc run-mode and run-status

In memory Collection (IMC) counter pmu driver controls the ucode's execution state. At the system boot, IMC perf driver pause the ucode. Ucode state is changed to "running" only when any of the nest units are monitored or profiled using perf tool.

[PATCH] powerpc/perf: Add debugfs interface for imc run-mode and run-status

In memory Collection (IMC) counter pmu driver controls the ucode's execution state. At the system boot, IMC perf driver pause the ucode. Ucode state is changed to "running" only when any of the nest units are monitored or profiled using perf tool.

Re: linux-next: manual merge of the integrity tree with the jc-docs tree

Hi all, On Wed, 18 Oct 2017 11:50:25 +0100 Mark Brown wrote: > > Today's linux-next merge of the integrity tree got a conflict in: > > Documentation/ABI/testing/evm > > between commit: > > c7f66400f504fd5 ("Documentation: fix security related doc refs") > > from the

Re: linux-next: manual merge of the integrity tree with the jc-docs tree

Hi all, On Wed, 18 Oct 2017 11:50:25 +0100 Mark Brown wrote: > > Today's linux-next merge of the integrity tree got a conflict in: > > Documentation/ABI/testing/evm > > between commit: > > c7f66400f504fd5 ("Documentation: fix security related doc refs") > > from the jc-docs tree and

Re: [kernel-hardening] Re: [PATCH v4] scripts: add leaking_addresses.pl

On Mon, Nov 13, 2017 at 10:05 AM, Tobin C. Harding wrote: > On Mon, Nov 13, 2017 at 06:37:28AM +0300, Kirill A. Shutemov wrote: >> On Mon, Nov 13, 2017 at 10:06:46AM +1100, Tobin C. Harding wrote: >> > On Sun, Nov 12, 2017 at 02:10:07AM +0300, Kirill A. Shutemov wrote: ... >> > >>

Re: [kernel-hardening] Re: [PATCH v4] scripts: add leaking_addresses.pl

On Mon, Nov 13, 2017 at 10:05 AM, Tobin C. Harding wrote: > On Mon, Nov 13, 2017 at 06:37:28AM +0300, Kirill A. Shutemov wrote: >> On Mon, Nov 13, 2017 at 10:06:46AM +1100, Tobin C. Harding wrote: >> > On Sun, Nov 12, 2017 at 02:10:07AM +0300, Kirill A. Shutemov wrote: ... >> > >> > Thanks for

Re: linux-next: manual merge of the tip tree with the FIXME tree

Hi Mark, On Wed, 11 Oct 2017 17:10:35 +0100 Mark Brown wrote: > > Today's linux-next merge of the tip tree got a conflict in: > > arch/s390/include/asm/spinlock.h > > between a series of commits adding wait queuing to s390 spinlocks > from the s390 tree: > >

Re: linux-next: manual merge of the tip tree with the FIXME tree

Hi Mark, On Wed, 11 Oct 2017 17:10:35 +0100 Mark Brown wrote: > > Today's linux-next merge of the tip tree got a conflict in: > > arch/s390/include/asm/spinlock.h > > between a series of commits adding wait queuing to s390 spinlocks > from the s390 tree: > > eb3b7b848fb3dd00f7a57d633

RE: [PATCH] mm/hugetlb: Implement ASLR and topdown for hugetlb mappings

Hi, Russell, Have you any time to check this patch? I found this issue/missing in my works, the application cannot mmap big hugepage (about 360MB) due to no more contiguous vm from the default "TASK_UNMMAPPED_AREA" by legacy bottom-up. We need this patch to fix this issue. Could you please

RE: [PATCH] mm/hugetlb: Implement ASLR and topdown for hugetlb mappings

Hi, Russell, Have you any time to check this patch? I found this issue/missing in my works, the application cannot mmap big hugepage (about 360MB) due to no more contiguous vm from the default "TASK_UNMMAPPED_AREA" by legacy bottom-up. We need this patch to fix this issue. Could you please

Re: linux-next: manual merge of the tip tree with the s390 tree

Hi all, On Wed, 11 Oct 2017 16:51:45 +0100 Mark Brown wrote: > > Today's linux-next merge of the tip tree got a conflict in: > > arch/s390/include/asm/rwsem.h > > between commit: > >91a1fad759ffd ("s390: use generic rwsem implementation") > > from the s390 tree and

Re: linux-next: manual merge of the tip tree with the s390 tree

Hi all, On Wed, 11 Oct 2017 16:51:45 +0100 Mark Brown wrote: > > Today's linux-next merge of the tip tree got a conflict in: > > arch/s390/include/asm/rwsem.h > > between commit: > >91a1fad759ffd ("s390: use generic rwsem implementation") > > from the s390 tree and commit: > >

Re: linux-next: manual merge of the drivers-x86 tree with the net-next tree

Hi all, On Mon, 9 Oct 2017 18:56:33 +0100 Mark Brown wrote: > > Today's linux-next merge of the drivers-x86 tree got a conflict in: > > Documentation/admin-guide/thunderbolt.rst > > between commit: > >e69b6c02b4c3b ("net: Add support for networking over Thunderbolt

Re: linux-next: manual merge of the drivers-x86 tree with the net-next tree

Hi all, On Mon, 9 Oct 2017 18:56:33 +0100 Mark Brown wrote: > > Today's linux-next merge of the drivers-x86 tree got a conflict in: > > Documentation/admin-guide/thunderbolt.rst > > between commit: > >e69b6c02b4c3b ("net: Add support for networking over Thunderbolt cable") > > from the

Re: [PATCH 2/3] X86/kdump: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM

On 10/24/17 at 01:31pm, Dave Young wrote: > Now crashkernel=X will fail if there's not enough memory at low region > (below 896M) when trying to reserve large memory size. One can use > crashkernel=xM,high to reserve it at high region (>4G) but it is more > convinient to improve crashkernel=X to:

Re: [PATCH 2/3] X86/kdump: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM

On 10/24/17 at 01:31pm, Dave Young wrote: > Now crashkernel=X will fail if there's not enough memory at low region > (below 896M) when trying to reserve large memory size. One can use > crashkernel=xM,high to reserve it at high region (>4G) but it is more > convinient to improve crashkernel=X to:

  1   2   3   4   5   6   7   >