Re: [PATCH 2/3] userfaultfd: use fault_wqh lock

Hi, On Thu, Dec 14, 2017 at 04:23:43PM +0100, Christoph Hellwig wrote: > From: Matthew Wilcox > > The epoll code currently uses the unlocked waitqueue helpers for managing The userfaultfd code > fault_wqh, but instead of holding the waitqueue lock for this waitqueue >

Re: [PATCH 2/3] userfaultfd: use fault_wqh lock

Hi, On Thu, Dec 14, 2017 at 04:23:43PM +0100, Christoph Hellwig wrote: > From: Matthew Wilcox > > The epoll code currently uses the unlocked waitqueue helpers for managing The userfaultfd code > fault_wqh, but instead of holding the waitqueue lock for this waitqueue > around these calls, it

Re: Detecting RWF_NOWAIT support

On 12/16/2017 08:12 PM, vcap...@pengaru.com wrote: On Sat, Dec 16, 2017 at 10:03:38AM -0800, vcap...@pengaru.com wrote: On Sat, Dec 16, 2017 at 04:49:08PM +0200, Avi Kivity wrote: On 12/14/2017 09:15 PM, Goldwyn Rodrigues wrote: On 12/14/2017 11:38 AM, Avi Kivity wrote: I'm looking to add

Re: Detecting RWF_NOWAIT support

On 12/16/2017 08:12 PM, vcap...@pengaru.com wrote: On Sat, Dec 16, 2017 at 10:03:38AM -0800, vcap...@pengaru.com wrote: On Sat, Dec 16, 2017 at 04:49:08PM +0200, Avi Kivity wrote: On 12/14/2017 09:15 PM, Goldwyn Rodrigues wrote: On 12/14/2017 11:38 AM, Avi Kivity wrote: I'm looking to add

Re: [PATCH 04/10] staging: ccree: staging: ccree: replace sysfs by debugfs interface

On Thu, Dec 14, 2017 at 4:30 PM, Philippe Ombredanne wrote: > Gilad, > > On Thu, Dec 14, 2017 at 3:02 PM, Gilad Ben-Yossef wrote: >> The ccree driver has had a none standard sysfs interface for debugging. >> Replace it with a proper debugfs interface.

Re: [PATCH 04/10] staging: ccree: staging: ccree: replace sysfs by debugfs interface

On Thu, Dec 14, 2017 at 4:30 PM, Philippe Ombredanne wrote: > Gilad, > > On Thu, Dec 14, 2017 at 3:02 PM, Gilad Ben-Yossef wrote: >> The ccree driver has had a none standard sysfs interface for debugging. >> Replace it with a proper debugfs interface. >> >> Signed-off-by: Gilad Ben-Yossef > >

RE: [PATCH v4 2/2] misc: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP init driver

Hi Randy, Thanks a lot for the review. > -Original Message- > From: Randy Dunlap [mailto:rdun...@infradead.org] > Sent: Saturday, December 16, 2017 2:18 PM > To: Dhaval Rajeshbhai Shah ; a...@arndb.de; > gre...@linuxfoundation.org; robh...@kernel.org;

RE: [PATCH v4 2/2] misc: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP init driver

Hi Randy, Thanks a lot for the review. > -Original Message- > From: Randy Dunlap [mailto:rdun...@infradead.org] > Sent: Saturday, December 16, 2017 2:18 PM > To: Dhaval Rajeshbhai Shah ; a...@arndb.de; > gre...@linuxfoundation.org; robh...@kernel.org; mark.rutl...@arm.com > Cc:

Re: [PATCH v19 3/7] xbitmap: add more operations

On 12/16/2017 07:28 PM, Tetsuo Handa wrote: Wei Wang wrote: On 12/16/2017 02:42 AM, Matthew Wilcox wrote: On Tue, Dec 12, 2017 at 07:55:55PM +0800, Wei Wang wrote: +int xb_preload_and_set_bit(struct xb *xb, unsigned long bit, gfp_t gfp); I'm struggling to understand when one would use this.

Re: [PATCH v19 3/7] xbitmap: add more operations

On 12/16/2017 07:28 PM, Tetsuo Handa wrote: Wei Wang wrote: On 12/16/2017 02:42 AM, Matthew Wilcox wrote: On Tue, Dec 12, 2017 at 07:55:55PM +0800, Wei Wang wrote: +int xb_preload_and_set_bit(struct xb *xb, unsigned long bit, gfp_t gfp); I'm struggling to understand when one would use this.

Re: mailbox: ti-msgmgr: Switch to SPDX Licensing

On Sun, Dec 17, 2017 at 3:19 AM, Nishanth Menon wrote: > On 08:21-20171213, Lokesh Vutla wrote: >> >> >> On Saturday 02 December 2017 03:52 PM, Nishanth Menon wrote: >> > Switch to SPDX licensing and drop the GPL text which comes redundant. >> > >> > Signed-off-by: Nishanth Menon

Re: mailbox: ti-msgmgr: Switch to SPDX Licensing

On Sun, Dec 17, 2017 at 3:19 AM, Nishanth Menon wrote: > On 08:21-20171213, Lokesh Vutla wrote: >> >> >> On Saturday 02 December 2017 03:52 PM, Nishanth Menon wrote: >> > Switch to SPDX licensing and drop the GPL text which comes redundant. >> > >> > Signed-off-by: Nishanth Menon >> >> >>

[PATCH] KVM: x86: Assign separate names for Intel and AMD to LBR MSRs

Some of the MSRs related to LBR (Last Branch Record) have different names and layouts among Intel and AMD, but the kernel does not distinguish them. Currently it does not invoke any bugs, but it is better to assign them separate macros in order to avoid confusion. Signed-off-by: Soramichi Akiyama

[PATCH] KVM: x86: Assign separate names for Intel and AMD to LBR MSRs

Some of the MSRs related to LBR (Last Branch Record) have different names and layouts among Intel and AMD, but the kernel does not distinguish them. Currently it does not invoke any bugs, but it is better to assign them separate macros in order to avoid confusion. Signed-off-by: Soramichi Akiyama

[alsa-devel][PATCH v6] ASoC: TSCS42xx: Support Tempo Semiconductor's TSCS42xx audio CODECs

Currently there is no support for TSCS42xx audio CODECs. Add support for TSCS42xx audio CODECs. Acked-by: Philippe Ombredanne Signed-off-by: Steven Eckhoff --- .../devicetree/bindings/sound/tscs42xx.txt | 16 +

[alsa-devel][PATCH v6] ASoC: TSCS42xx: Support Tempo Semiconductor's TSCS42xx audio CODECs

Currently there is no support for TSCS42xx audio CODECs. Add support for TSCS42xx audio CODECs. Acked-by: Philippe Ombredanne Signed-off-by: Steven Eckhoff --- .../devicetree/bindings/sound/tscs42xx.txt | 16 + .../devicetree/bindings/vendor-prefixes.txt|1 + MAINTAINERS

Re: [PATCH] ipv6: icmp6: Allow icmp messages to be looped back

From: Brendan McGrath Date: Wed, 13 Dec 2017 22:14:57 +1100 > One example of when an ICMPv6 packet is required to be looped back is > when a host acts as both a Multicast Listener and a Multicast Router. > > A Multicast Router will listen on address ff02::16 for

Re: [PATCH] ipv6: icmp6: Allow icmp messages to be looped back

From: Brendan McGrath Date: Wed, 13 Dec 2017 22:14:57 +1100 > One example of when an ICMPv6 packet is required to be looped back is > when a host acts as both a Multicast Listener and a Multicast Router. > > A Multicast Router will listen on address ff02::16 for MLDv2 messages. > > Currently,

Re: [linus:master] BUILD REGRESSION f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051

On Sat, 16 Dec 2017, Linus Torvalds wrote: > Nico, > > On Sat, Dec 16, 2017 at 7:00 PM, kbuild test robot > wrote: > > > > fs/cramfs/inode.c:641: undefined reference to `mtd_point' > > fs/cramfs/inode.c:658: undefined reference to `mtd_unpoint' > > fs/cramfs/inode.c:959:

Re: [linus:master] BUILD REGRESSION f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051

On Sat, 16 Dec 2017, Linus Torvalds wrote: > Nico, > > On Sat, Dec 16, 2017 at 7:00 PM, kbuild test robot > wrote: > > > > fs/cramfs/inode.c:641: undefined reference to `mtd_point' > > fs/cramfs/inode.c:658: undefined reference to `mtd_unpoint' > > fs/cramfs/inode.c:959: undefined reference to

Re: [GIT PULL] x86 fixes

On Fri, Dec 15, 2017 at 8:07 AM, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > >> On Fri, Dec 15, 2017 at 7:43 AM, Ingo Molnar wrote: >> > Linus, >> >> > >> > - two 5-level paging related fixes >> >> Which reminds me: can you grab this

Re: [GIT PULL] x86 fixes

On Fri, Dec 15, 2017 at 8:07 AM, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > >> On Fri, Dec 15, 2017 at 7:43 AM, Ingo Molnar wrote: >> > Linus, >> >> > >> > - two 5-level paging related fixes >> >> Which reminds me: can you grab this one, too? >> >>

Re: [linus:master] BUILD REGRESSION f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051

Nico, On Sat, Dec 16, 2017 at 7:00 PM, kbuild test robot wrote: > > fs/cramfs/inode.c:641: undefined reference to `mtd_point' > fs/cramfs/inode.c:658: undefined reference to `mtd_unpoint' > fs/cramfs/inode.c:959: undefined reference to `mount_mtd' This does seem to be

Re: [linus:master] BUILD REGRESSION f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051

Nico, On Sat, Dec 16, 2017 at 7:00 PM, kbuild test robot wrote: > > fs/cramfs/inode.c:641: undefined reference to `mtd_point' > fs/cramfs/inode.c:658: undefined reference to `mtd_unpoint' > fs/cramfs/inode.c:959: undefined reference to `mount_mtd' This does seem to be real. As of 99c18ce580c6

Re: [v3 PATCH 3/3] powernv-cpufreq: Treat pstates as opaque 8-bit values

On Wed, Dec 13, 2017 at 5:57 PM, Gautham R. Shenoy wrote: > From: "Gautham R. Shenoy" > > On POWER8 and POWER9, the PMSR and the PMCR registers define pstates > to be 8-bit wide values. The device-tree exports pstates as 32-bit > wide values of

Re: [v3 PATCH 3/3] powernv-cpufreq: Treat pstates as opaque 8-bit values

On Wed, Dec 13, 2017 at 5:57 PM, Gautham R. Shenoy wrote: > From: "Gautham R. Shenoy" > > On POWER8 and POWER9, the PMSR and the PMCR registers define pstates > to be 8-bit wide values. The device-tree exports pstates as 32-bit > wide values of which the lower byte is the actual pstate. > > The

Re: [v3 PATCH 2/3] powernv-cpufreq: Fix pstate_to_idx() to handle non-continguous pstates

On Wed, Dec 13, 2017 at 5:57 PM, Gautham R. Shenoy wrote: > From: "Gautham R. Shenoy" > > The code in powernv-cpufreq, makes the following two assumptions which > are not guaranteed by the device-tree bindings: > > 1) Pstate ids are

Re: [v3 PATCH 2/3] powernv-cpufreq: Fix pstate_to_idx() to handle non-continguous pstates

On Wed, Dec 13, 2017 at 5:57 PM, Gautham R. Shenoy wrote: > From: "Gautham R. Shenoy" > > The code in powernv-cpufreq, makes the following two assumptions which > are not guaranteed by the device-tree bindings: > > 1) Pstate ids are continguous: This is used in pstate_to_idx() to >

Re: [v3 PATCH 1/3] powernv-cpufreq: Add helper to extract pstate from PMSR

On Wed, Dec 13, 2017 at 5:57 PM, Gautham R. Shenoy wrote: > From: "Gautham R. Shenoy" > > On POWERNV platform, the fields for pstates in the Power Management > Status Register (PMSR) and the Power Management Control Register > (PMCR) are 8-bits

Re: [v3 PATCH 1/3] powernv-cpufreq: Add helper to extract pstate from PMSR

On Wed, Dec 13, 2017 at 5:57 PM, Gautham R. Shenoy wrote: > From: "Gautham R. Shenoy" > > On POWERNV platform, the fields for pstates in the Power Management > Status Register (PMSR) and the Power Management Control Register > (PMCR) are 8-bits wide. On POWER8 the pstates are negatively numbered

[linus:master] BUILD REGRESSION f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master branch HEAD: f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma Regressions in current branch: cc1: error: '-march=r3900' requires

[linus:master] BUILD REGRESSION f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master branch HEAD: f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma Regressions in current branch: cc1: error: '-march=r3900' requires

[no subject]

This is the second time i am sending you this mail. I, Friedrich Mayrhofer Donates the sum of $ 1,000,000.00 to You, Email Me personally for more details. Regards. Friedrich Mayrhofer

[no subject]

This is the second time i am sending you this mail. I, Friedrich Mayrhofer Donates the sum of $ 1,000,000.00 to You, Email Me personally for more details. Regards. Friedrich Mayrhofer

Re: [tip:WIP.x86/pti-upstream 38/50] arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared

On Sat, Dec 16, 2017 at 3:35 PM, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > WIP.x86/pti-upstream > head: 78e4da51f7c77587cc6f419af4f63a21b289bdb7 > commit: 7e482cfe4a23ead21215423c4566c8516ba21025 [38/50] x86/pti:

Re: [tip:WIP.x86/pti-upstream 38/50] arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared

On Sat, Dec 16, 2017 at 3:35 PM, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > WIP.x86/pti-upstream > head: 78e4da51f7c77587cc6f419af4f63a21b289bdb7 > commit: 7e482cfe4a23ead21215423c4566c8516ba21025 [38/50] x86/pti: Put the LDT > in its own

[PATCH] dt-bindings: display: panel: Fix compatible string for Toshiba LT089AC29000

The compatible string for this panel was specified as toshiba,lt089ac29000.txt. I believe this is a mistake. Fixes: 06e733e41f87 ("drm/panel: simple: add Toshiba LT089AC19000") Cc: Lucas Stach Signed-off-by: Jonathan Neuschäfer ---

[PATCH] dt-bindings: display: panel: Fix compatible string for Toshiba LT089AC29000

The compatible string for this panel was specified as toshiba,lt089ac29000.txt. I believe this is a mistake. Fixes: 06e733e41f87 ("drm/panel: simple: add Toshiba LT089AC19000") Cc: Lucas Stach Signed-off-by: Jonathan Neuschäfer --- .../devicetree/bindings/display/panel/toshiba,lt089ac29000.txt

Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program

On Sat, 2017-12-16 at 09:47 -0800, Stephen Hemminger wrote: > On Sat, 16 Dec 2017 15:42:25 +0100 > Knut Omang wrote: > > > This patch series implements features to make it easier to run checkers on > > the > > entire kernel as part of automatic and developer testing. > >

Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program

On Sat, 2017-12-16 at 09:47 -0800, Stephen Hemminger wrote: > On Sat, 16 Dec 2017 15:42:25 +0100 > Knut Omang wrote: > > > This patch series implements features to make it easier to run checkers on > > the > > entire kernel as part of automatic and developer testing. > > > > This is done by

Re: [PATCH v2 4/5] rds: Add runchecks.cfg for net/rds

On Sat, 2017-12-16 at 10:24 -0800, Joe Perches wrote: > On Sat, 2017-12-16 at 09:45 -0800, Stephen Hemminger wrote: > > On Sat, 16 Dec 2017 15:42:29 +0100 Knut Omang wrote: > > > +# Code simplification: > > > +# > > > +except ALLOC_WITH_MULTIPLY ib.c > > > +except

Re: [PATCH v2 4/5] rds: Add runchecks.cfg for net/rds

On Sat, 2017-12-16 at 10:24 -0800, Joe Perches wrote: > On Sat, 2017-12-16 at 09:45 -0800, Stephen Hemminger wrote: > > On Sat, 16 Dec 2017 15:42:29 +0100 Knut Omang wrote: > > > +# Code simplification: > > > +# > > > +except ALLOC_WITH_MULTIPLY ib.c > > > +except PREFER_PR_LEVEL ib_cm.c

Re: [PATCH v2 4/5] rds: Add runchecks.cfg for net/rds

On Sat, 2017-12-16 at 12:00 -0800, santosh.shilim...@oracle.com wrote: > On 12/16/17 10:24 AM, Joe Perches wrote: > > On Sat, 2017-12-16 at 09:45 -0800, Stephen Hemminger wrote: > >> On Sat, 16 Dec 2017 15:42:29 +0100 Knut Omang > >> wrote: > >>> +# Code simplification: >

Re: [PATCH v2 4/5] rds: Add runchecks.cfg for net/rds

On Sat, 2017-12-16 at 12:00 -0800, santosh.shilim...@oracle.com wrote: > On 12/16/17 10:24 AM, Joe Perches wrote: > > On Sat, 2017-12-16 at 09:45 -0800, Stephen Hemminger wrote: > >> On Sat, 16 Dec 2017 15:42:29 +0100 Knut Omang > >> wrote: > >>> +# Code simplification: > >>> +# > >>> +except

Re: [PATCH v4] KVM: Fix stack-out-of-bounds read in write_mmio

2017-12-15 19:06 GMT+08:00 Marc Zyngier : > On 15/12/17 01:40, Wanpeng Li wrote: >> From: Wanpeng Li >> >> Reported by syzkaller: >> >> BUG: KASAN: stack-out-of-bounds in write_mmio+0x11e/0x270 [kvm] >> Read of size 8 at addr 8803259df7f8 by

Re: [PATCH v4] KVM: Fix stack-out-of-bounds read in write_mmio

2017-12-15 19:06 GMT+08:00 Marc Zyngier : > On 15/12/17 01:40, Wanpeng Li wrote: >> From: Wanpeng Li >> >> Reported by syzkaller: >> >> BUG: KASAN: stack-out-of-bounds in write_mmio+0x11e/0x270 [kvm] >> Read of size 8 at addr 8803259df7f8 by task syz-executor/32298 >> >> CPU: 6 PID:

[GIT PULL] ext4 bug fixes for 4.15

The following changes since commit ae64f9bd1d3621b5e60d7363bc20afb46aede215: Linux 4.15-rc2 (2017-12-03 11:01:47 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_stable for you to fetch changes up to

[GIT PULL] ext4 bug fixes for 4.15

The following changes since commit ae64f9bd1d3621b5e60d7363bc20afb46aede215: Linux 4.15-rc2 (2017-12-03 11:01:47 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_stable for you to fetch changes up to

Re: [PATCH v2 4/5] rds: Add runchecks.cfg for net/rds

On Sat, 2017-12-16 at 09:45 -0800, Stephen Hemminger wrote: > On Sat, 16 Dec 2017 15:42:29 +0100 > Knut Omang wrote: > > > + > > +# Important to fix from a quality perspective: > > +# > > +except AVOID_BUG connection.c ib.c ib_cm.c ib_rdma.c ib_recv.c ib_ring.c > >

Re: [PATCH v2 4/5] rds: Add runchecks.cfg for net/rds

On Sat, 2017-12-16 at 09:45 -0800, Stephen Hemminger wrote: > On Sat, 16 Dec 2017 15:42:29 +0100 > Knut Omang wrote: > > > + > > +# Important to fix from a quality perspective: > > +# > > +except AVOID_BUG connection.c ib.c ib_cm.c ib_rdma.c ib_recv.c ib_ring.c > > ib_send.c > info.c loop.c

[PATCH] ARM: dts: sun8i-a83t-tbs-a711: Add missing axp813 compatible

From: Ondrej Jirman Without this the AXP813 PMIC fails to probe on TBS A711. Signed-off-by: Ondrej Jirman --- arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts

[PATCH] ARM: dts: sun8i-a83t-tbs-a711: Add missing axp813 compatible

From: Ondrej Jirman Without this the AXP813 PMIC fails to probe on TBS A711. Signed-off-by: Ondrej Jirman --- arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts

[RFC patch] checkpatch: Add a test for long function definitions (>200 lines)

On Mon, 2017-12-11 at 14:43 -0800, Matthew Wilcox wrote: > - There's no warning for the first paragraph of section 6: > > 6) Functions > > > Functions should be short and sweet, and do just one thing. They should > fit on one or two screenfuls of text (the ISO/ANSI screen size is

[RFC patch] checkpatch: Add a test for long function definitions (>200 lines)

On Mon, 2017-12-11 at 14:43 -0800, Matthew Wilcox wrote: > - There's no warning for the first paragraph of section 6: > > 6) Functions > > > Functions should be short and sweet, and do just one thing. They should > fit on one or two screenfuls of text (the ISO/ANSI screen size is

[tip:WIP.x86/pti-upstream 38/50] arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared; did you mean '_ASM_ADD'?

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/pti-upstream head: 78e4da51f7c77587cc6f419af4f63a21b289bdb7 commit: 7e482cfe4a23ead21215423c4566c8516ba21025 [38/50] x86/pti: Put the LDT in its own PGD if PTI is on config: i386-alldefconfig (attached as .config)

[tip:WIP.x86/pti-upstream 38/50] arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared; did you mean '_ASM_ADD'?

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/pti-upstream head: 78e4da51f7c77587cc6f419af4f63a21b289bdb7 commit: 7e482cfe4a23ead21215423c4566c8516ba21025 [38/50] x86/pti: Put the LDT in its own PGD if PTI is on config: i386-alldefconfig (attached as .config)

Re: [PATCH v2 01/19] fs: new API for handling inode->i_version

On Sun, 2017-12-17 at 09:37 +1100, Dave Chinner wrote: > On Sat, Dec 16, 2017 at 08:46:38AM -0500, Jeff Layton wrote: > > From: Jeff Layton > > > > Add a documentation blob that explains what the i_version field is, how > > it is expected to work, and how it is currently

Re: [PATCH v2 01/19] fs: new API for handling inode->i_version

On Sun, 2017-12-17 at 09:37 +1100, Dave Chinner wrote: > On Sat, Dec 16, 2017 at 08:46:38AM -0500, Jeff Layton wrote: > > From: Jeff Layton > > > > Add a documentation blob that explains what the i_version field is, how > > it is expected to work, and how it is currently implemented by various >

Hello Dear,

Hello Dear, Greetings,I'm here to meet a serious man who is ready to keep a serious relationship with me. I know its hard to find a serious man on internet, I believe dream come through with one mind. I need reliable person who is honest. I am looking for the right man for me who is sincere,

Hello Dear,

Hello Dear, Greetings,I'm here to meet a serious man who is ready to keep a serious relationship with me. I know its hard to find a serious man on internet, I believe dream come through with one mind. I need reliable person who is honest. I am looking for the right man for me who is sincere,

fs/cramfs/inode.c:698: undefined reference to `mount_mtd'

Hi Nicolas, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051 commit: 99c18ce580c6cc6763e694b4ce320d7b226ab59b cramfs: direct memory access support date: 9 weeks ago config:

fs/cramfs/inode.c:698: undefined reference to `mount_mtd'

Hi Nicolas, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051 commit: 99c18ce580c6cc6763e694b4ce320d7b226ab59b cramfs: direct memory access support date: 9 weeks ago config:

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Saturday, December 16, 2017 5:47:07 PM CET Viresh Kumar wrote: > On 16 December 2017 at 22:10, Rafael J. Wysocki wrote: > > On Wed, Dec 13, 2017 at 10:53 AM, Viresh Kumar > > wrote: > > >> +#define SCHED_CPUFREQ_CLEAR(1U << 31) > > > > I'm not

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Saturday, December 16, 2017 5:47:07 PM CET Viresh Kumar wrote: > On 16 December 2017 at 22:10, Rafael J. Wysocki wrote: > > On Wed, Dec 13, 2017 at 10:53 AM, Viresh Kumar > > wrote: > > >> +#define SCHED_CPUFREQ_CLEAR(1U << 31) > > > > I'm not thrilled by this, because schedutil is not

[PATCH 2/3] x86/efi: Replace efi_pgd with efi_mm.pgd

From: Sai Praneeth Since the previous patch added support for efi_mm, let's handle efi_pgd through efi_mm and remove global variable efi_pgd. Signed-off-by: Sai Praneeth Prakhya Cc: Lee, Chun-Yi Cc: Borislav Petkov

[PATCH 2/3] x86/efi: Replace efi_pgd with efi_mm.pgd

From: Sai Praneeth Since the previous patch added support for efi_mm, let's handle efi_pgd through efi_mm and remove global variable efi_pgd. Signed-off-by: Sai Praneeth Prakhya Cc: Lee, Chun-Yi Cc: Borislav Petkov Cc: Tony Luck Cc: Andy Lutomirski Cc: Michael S. Tsirkin Cc: Bhupesh

[PATCH 3/3] x86/efi: Use efi_switch_mm() rather than manually twiddling with %cr3

From: Sai Praneeth Use helper function (efi_switch_mm()) to switch to/from efi_mm. We switch to efi_mm before calling 1. efi_set_virtual_address_map() and 2. Invoking any efi_runtime_service() Likewise, we need to switch back to previous mm (mm context stolen by

[PATCH 3/3] x86/efi: Use efi_switch_mm() rather than manually twiddling with %cr3

From: Sai Praneeth Use helper function (efi_switch_mm()) to switch to/from efi_mm. We switch to efi_mm before calling 1. efi_set_virtual_address_map() and 2. Invoking any efi_runtime_service() Likewise, we need to switch back to previous mm (mm context stolen by efi_mm) after the above calls

[PATCH 1/3] efi: Use efi_mm in x86 as well as ARM

From: Sai Praneeth Presently, only ARM uses mm_struct to manage efi page tables and efi runtime region mappings. As this is the preferred approach, let's make this data structure common across architectures. Specially, for x86, using this data structure improves

[PATCH 1/3] efi: Use efi_mm in x86 as well as ARM

From: Sai Praneeth Presently, only ARM uses mm_struct to manage efi page tables and efi runtime region mappings. As this is the preferred approach, let's make this data structure common across architectures. Specially, for x86, using this data structure improves code maintainability and

[PATCH 0/3] Use mm_struct and switch_mm() instead of manually

From: Sai Praneeth Presently, in x86, to invoke any efi function like efi_set_virtual_address_map() or any efi_runtime_service() the code path typically involves read_cr3() (save previous pgd), write_cr3() (write efi_pgd) and calling efi function. Likewise after

[PATCH 0/3] Use mm_struct and switch_mm() instead of manually

From: Sai Praneeth Presently, in x86, to invoke any efi function like efi_set_virtual_address_map() or any efi_runtime_service() the code path typically involves read_cr3() (save previous pgd), write_cr3() (write efi_pgd) and calling efi function. Likewise after returning from efi function the

Re: [RFC GIT PULL] x86 Page Table Isolation (PTI) syscall entry code preparatory patches

* Linus Torvalds wrote: > On Fri, Dec 15, 2017 at 5:58 PM, Ingo Molnar wrote: > > > > These are the x86-64 low level entry code preparatory patches for the page > > table > > isolation patches - which are required for PTI, which addresses KASLR

Re: [RFC GIT PULL] x86 Page Table Isolation (PTI) syscall entry code preparatory patches

* Linus Torvalds wrote: > On Fri, Dec 15, 2017 at 5:58 PM, Ingo Molnar wrote: > > > > These are the x86-64 low level entry code preparatory patches for the page > > table > > isolation patches - which are required for PTI, which addresses KASLR and > > similar > > information leaks. > >

[PATCH][next] mei: fix spelling mistake: "botther" -> "bother"

From: Colin Ian King Trivial fix to spelling mistake in dev_dbg debug message. Also add in a missing comma. Signed-off-by: Colin Ian King --- drivers/misc/mei/bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH][next] mei: fix spelling mistake: "botther" -> "bother"

From: Colin Ian King Trivial fix to spelling mistake in dev_dbg debug message. Also add in a missing comma. Signed-off-by: Colin Ian King --- drivers/misc/mei/bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c index

[tip:WIP.x86/pti-upstream 38/50] arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/pti-upstream head: 78e4da51f7c77587cc6f419af4f63a21b289bdb7 commit: 7e482cfe4a23ead21215423c4566c8516ba21025 [38/50] x86/pti: Put the LDT in its own PGD if PTI is on config: i386-randconfig-h0-12170619 (attached as

[tip:WIP.x86/pti-upstream 38/50] arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/pti-upstream head: 78e4da51f7c77587cc6f419af4f63a21b289bdb7 commit: 7e482cfe4a23ead21215423c4566c8516ba21025 [38/50] x86/pti: Put the LDT in its own PGD if PTI is on config: i386-randconfig-h0-12170619 (attached as

Re: [PATCH] ext4: delayed inode update for the consistency of file size after a crash

On Sat, Dec 16, 2017 at 01:33:26PM +0900, Seongbae Son wrote: > > > Details can be found as follows. > > > > > > Son et al. "Guaranteeing the Metadata Update Atomicity in EXT4 > > > Filesystem”, > > > In Proc. of APSYS 2017, Mumbai, India > > > This is behind a paywall, so I can't access it. I

Re: [PATCH] ext4: delayed inode update for the consistency of file size after a crash

On Sat, Dec 16, 2017 at 01:33:26PM +0900, Seongbae Son wrote: > > > Details can be found as follows. > > > > > > Son et al. "Guaranteeing the Metadata Update Atomicity in EXT4 > > > Filesystem”, > > > In Proc. of APSYS 2017, Mumbai, India > > > This is behind a paywall, so I can't access it. I

Re: BUG: bad usercopy in ___sys_sendmsg

On Sat, Dec 16, 2017 at 12:29 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 5c13e07580c8bd2af6aa902d6b62faa968c360bc > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master >

Re: BUG: bad usercopy in ___sys_sendmsg

On Sat, Dec 16, 2017 at 12:29 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 5c13e07580c8bd2af6aa902d6b62faa968c360bc > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is

Re: [RFC GIT PULL] x86 Page Table Isolation (PTI) syscall entry code preparatory patches

On Fri, Dec 15, 2017 at 5:58 PM, Ingo Molnar wrote: > > These are the x86-64 low level entry code preparatory patches for the page > table > isolation patches - which are required for PTI, which addresses KASLR and > similar > information leaks. Ugh. Ok, I've read through

Re: [RFC GIT PULL] x86 Page Table Isolation (PTI) syscall entry code preparatory patches

On Fri, Dec 15, 2017 at 5:58 PM, Ingo Molnar wrote: > > These are the x86-64 low level entry code preparatory patches for the page > table > isolation patches - which are required for PTI, which addresses KASLR and > similar > information leaks. Ugh. Ok, I've read through this, and while I

Re: [PATCH] divers/soc/ti: fix max dup length for kstrndup

On 12/12/17 1:29 AM, Ma Shimiao wrote: If source string longer than max, kstrndup will alloc max+1 space. So, we should make sure the result will not over limit. Signed-off-by: Ma Shimiao --- Applied. Thanks !!

Re: [PATCH] divers/soc/ti: fix max dup length for kstrndup

On 12/12/17 1:29 AM, Ma Shimiao wrote: If source string longer than max, kstrndup will alloc max+1 space. So, we should make sure the result will not over limit. Signed-off-by: Ma Shimiao --- Applied. Thanks !!

Re: Linux & FAT32 label

On Thursday 09 November 2017 22:21:31 Pali Rohár wrote: > So from all tests and discussion I would propose new unification: > > 1. Read label only from the root directory. If label in root directory >is missing then disk would be treated as without label. Label from >boot sector would not

Re: Linux & FAT32 label

On Thursday 09 November 2017 22:21:31 Pali Rohár wrote: > So from all tests and discussion I would propose new unification: > > 1. Read label only from the root directory. If label in root directory >is missing then disk would be treated as without label. Label from >boot sector would not

Re: [PATCH V2 0/8] ARM: dts: keystone*: Stage 1 cleanup for W=1

On 12/16/17 12:40 PM, Nishanth Menon wrote: Hi, The following changes have been done in the updated series: * Updates for couple few typo errors in commit messages * copyrights are now always behind description * rebased to maintainer branch (was previously against master) Rebased to:

Re: [PATCH V2 0/8] ARM: dts: keystone*: Stage 1 cleanup for W=1

On 12/16/17 12:40 PM, Nishanth Menon wrote: Hi, The following changes have been done in the updated series: * Updates for couple few typo errors in commit messages * copyrights are now always behind description * rebased to maintainer branch (was previously against master) Rebased to:

Re: [PATCH] firmware: ti_sci: Use %zu for size_t print format

On 12/2/17 2:20 AM, Nishanth Menon wrote: mbox_msg->len is of type size_t and %d is incorrect format. Instead use %zu for handling size_t correctly. Signed-off-by: Nishanth Menon --- Applied to 'for_4.16/drivers-soc' with Lokesh's ack.

Re: [PATCH] firmware: ti_sci: Use %zu for size_t print format

On 12/2/17 2:20 AM, Nishanth Menon wrote: mbox_msg->len is of type size_t and %d is incorrect format. Instead use %zu for handling size_t correctly. Signed-off-by: Nishanth Menon --- Applied to 'for_4.16/drivers-soc' with Lokesh's ack.

Re: [PATCH v2 01/19] fs: new API for handling inode->i_version

On Sat, Dec 16, 2017 at 08:46:38AM -0500, Jeff Layton wrote: > From: Jeff Layton > > Add a documentation blob that explains what the i_version field is, how > it is expected to work, and how it is currently implemented by various > filesystems. > > We already have

Re: [PATCH v2 01/19] fs: new API for handling inode->i_version

On Sat, Dec 16, 2017 at 08:46:38AM -0500, Jeff Layton wrote: > From: Jeff Layton > > Add a documentation blob that explains what the i_version field is, how > it is expected to work, and how it is currently implemented by various > filesystems. > > We already have inode_inc_iversion. Add

[BUG] Build error for 4.15-rc3 kernel caused by patch "kbuild: Add a cache for generated variables"

Hi folks, I just upgraded gcc to 6.4 on my centos 7 machine by Arnd's suggestion. But, I ran into the below compile error with 4.15-rc3 kernel: In file included from ./include/uapi/linux/uuid.h:21:0, from ./include/linux/uuid.h:19, from

[BUG] Build error for 4.15-rc3 kernel caused by patch "kbuild: Add a cache for generated variables"

Hi folks, I just upgraded gcc to 6.4 on my centos 7 machine by Arnd's suggestion. But, I ran into the below compile error with 4.15-rc3 kernel: In file included from ./include/uapi/linux/uuid.h:21:0, from ./include/linux/uuid.h:19, from

Re: powerpc64 kernel panic if you disable CONFIG_PPC_TRANSACTIONAL_MEM?

On Sun, Dec 17, 2017 at 8:34 AM, Rob Landley wrote: > I just added a ppc64 target to https://github.com/landley/mkroot which > means I built 4.14 with the attached miniconfig and ran it with the > attached qemu command line, and it works fine as is but if you remove > the

Re: powerpc64 kernel panic if you disable CONFIG_PPC_TRANSACTIONAL_MEM?

On Sun, Dec 17, 2017 at 8:34 AM, Rob Landley wrote: > I just added a ppc64 target to https://github.com/landley/mkroot which > means I built 4.14 with the attached miniconfig and ran it with the > attached qemu command line, and it works fine as is but if you remove > the transactional mem line

Re: [PATCH] mm: thp: avoid uninitialized variable use

On 12/16/17 4:24 AM, Arnd Bergmann wrote: On Fri, Dec 15, 2017 at 7:01 PM, Yang Shi wrote: On 12/15/17 4:51 AM, Arnd Bergmann wrote: When the down_read_trylock() fails, 'vma' has not been initialized yet, which gcc now warns about: mm/khugepaged.c: In function

Re: [PATCH] mm: thp: avoid uninitialized variable use

On 12/16/17 4:24 AM, Arnd Bergmann wrote: On Fri, Dec 15, 2017 at 7:01 PM, Yang Shi wrote: On 12/15/17 4:51 AM, Arnd Bergmann wrote: When the down_read_trylock() fails, 'vma' has not been initialized yet, which gcc now warns about: mm/khugepaged.c: In function 'khugepaged':

  1   2   3   4   5   6   7   >