Re: [PATCH v8 2/6] module: allow symbol exports to be disabled

On Sun, 11 Mar 2018, Ard Biesheuvel wrote: > To allow existing C code to be incorporated into the decompressor or > the UEFI stub, introduce a CPP macro that turns all EXPORT_SYMBOL_xxx > declarations into nops, and #define it in places where such exports > are undesirable. Note that this gets

Re: [PATCH v8 2/6] module: allow symbol exports to be disabled

On Sun, 11 Mar 2018, Ard Biesheuvel wrote: > To allow existing C code to be incorporated into the decompressor or > the UEFI stub, introduce a CPP macro that turns all EXPORT_SYMBOL_xxx > declarations into nops, and #define it in places where such exports > are undesirable. Note that this gets

Re: [RFC v2 14/83] Add range node kmem cache.

On Sun, Mar 11, 2018 at 4:55 AM, Nikolay Borisov wrote: > > > On 10.03.2018 20:17, Andiry Xu wrote: >> From: Andiry Xu >> >> Range node specifies a range of [start, end]. and is managed by a red-black >> tree. >> NOVA uses range node to manage NVM

Re: [RFC v2 14/83] Add range node kmem cache.

On Sun, Mar 11, 2018 at 4:55 AM, Nikolay Borisov wrote: > > > On 10.03.2018 20:17, Andiry Xu wrote: >> From: Andiry Xu >> >> Range node specifies a range of [start, end]. and is managed by a red-black >> tree. >> NOVA uses range node to manage NVM allocator and inodes being used. >> >>

Re: [PATCH] proc: reject "." and ".." as filenames

On Sat 2018-03-10 03:12:23, Alexey Dobriyan wrote: > Various subsystems can create files and directories in /proc > with names directly controlled by userspace. > > Which means "/", "." and ".." are no-no. > > "/" split is already taken care of, do the other 2 prohibited names. Hmm, patch is

Re: [PATCH] proc: reject "." and ".." as filenames

On Sat 2018-03-10 03:12:23, Alexey Dobriyan wrote: > Various subsystems can create files and directories in /proc > with names directly controlled by userspace. > > Which means "/", "." and ".." are no-no. > > "/" split is already taken care of, do the other 2 prohibited names. Hmm, patch is

Re: [RFC v2 16/83] Initialize block map and free lists in nova_init().

On Sun, Mar 11, 2018 at 5:12 AM, Nikolay Borisov wrote: > > > On 10.03.2018 20:17, Andiry Xu wrote: >> From: Andiry Xu >> >> NOVA divides the pmem range equally among per-CPU free lists, >> and format the red-black trees by inserting the initial free

Re: [RFC v2 16/83] Initialize block map and free lists in nova_init().

On Sun, Mar 11, 2018 at 5:12 AM, Nikolay Borisov wrote: > > > On 10.03.2018 20:17, Andiry Xu wrote: >> From: Andiry Xu >> >> NOVA divides the pmem range equally among per-CPU free lists, >> and format the red-black trees by inserting the initial free range. >> >> Signed-off-by: Andiry Xu >> ---

Re: [PATCH v8 1/6] arch: enable relative relocations for arm64, power and x86

On Sun, Mar 11, 2018 at 1:35 PM, Ard Biesheuvel wrote: > > I'm sure all of these architectures define some kind of 32-bit place > relative relocation in their ELF psABI, and I see how it would be > cleaner to change everything at once, but I anticipate a long tail of >

Re: [PATCH v8 1/6] arch: enable relative relocations for arm64, power and x86

On Sun, Mar 11, 2018 at 1:35 PM, Ard Biesheuvel wrote: > > I'm sure all of these architectures define some kind of 32-bit place > relative relocation in their ELF psABI, and I see how it would be > cleaner to change everything at once, but I anticipate a long tail of > issues with toolchains for

[PATCH] net: llc: drop VLA in llc_sap_mcast()

Avoid a VLA[1] by using a real constant expression instead of a variable. The compiler should be able to optimize the original code and avoid using an actual VLA. Anyway this change is useful because it will avoid a false positive with -Wvla, it might also help the compiler generating better code.

[PATCH] net: llc: drop VLA in llc_sap_mcast()

Avoid a VLA[1] by using a real constant expression instead of a variable. The compiler should be able to optimize the original code and avoid using an actual VLA. Anyway this change is useful because it will avoid a false positive with -Wvla, it might also help the compiler generating better code.

[PATCH 2/2] net: rds: drop VLA in rds_walk_conn_path_info()

Avoid VLA[1] by using an already allocated buffer passed by the caller. [1] https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Salvatore Mesoraca --- net/rds/connection.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/net/rds/connection.c

[PATCH 2/2] net: rds: drop VLA in rds_walk_conn_path_info()

Avoid VLA[1] by using an already allocated buffer passed by the caller. [1] https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Salvatore Mesoraca --- net/rds/connection.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/net/rds/connection.c b/net/rds/connection.c index

[PATCH 1/2] net: rds: drop VLA in rds_for_each_conn_info()

Avoid VLA[1] by using an already allocated buffer passed by the caller. [1] https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Salvatore Mesoraca --- net/rds/connection.c | 2 +- net/rds/ib.c | 3 +++ net/rds/rds.h| 1 + 3 files changed, 5 insertions(+),

[PATCH 1/2] net: rds: drop VLA in rds_for_each_conn_info()

Avoid VLA[1] by using an already allocated buffer passed by the caller. [1] https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Salvatore Mesoraca --- net/rds/connection.c | 2 +- net/rds/ib.c | 3 +++ net/rds/rds.h| 1 + 3 files changed, 5 insertions(+), 1 deletion(-) diff

[PATCH] scsi: eata: drop VLA in reorder()

n_ready will always be less than or equal to MAX_MAILBOXES. So we avoid a VLA[1] and use fixed-length arrays instead. [1] https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Salvatore Mesoraca --- drivers/scsi/eata.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH] scsi: eata: drop VLA in reorder()

n_ready will always be less than or equal to MAX_MAILBOXES. So we avoid a VLA[1] and use fixed-length arrays instead. [1] https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Salvatore Mesoraca --- drivers/scsi/eata.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

Also, Alexei you never answered my questions out aliases with the umh modules. Long term this important to consider. Luis

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

Also, Alexei you never answered my questions out aliases with the umh modules. Long term this important to consider. Luis

[PATCH 3/3 v2] selftests: add devpts selftests

This adds a simple test to check whether /proc//fd/ symlinks are correctly pointing to /dev/pts/ devices when attached to a terminal. Signed-off-by: Christian Brauner --- ChangeLog v1->v2: * patch added ChangeLog v0->v1: * patch not present ---

[PATCH 0/3 v2] devpts: handle /dev/ptmx bind-mounts

Hey everyone, This is the second iteration of this patch. Please note, that I added a selftest for correct /proc//fd/{0,1,2} symlinks and added it to tools/testing/selftests/filesystem because the root cause of the problem is located in the devpts filesystem. But I'm not sure if this is the right

[PATCH 2/3 v2] devpts: resolve devpts bind-mounts

Most libcs will still look at /dev/ptmx when opening the master fd of a pty device. When /dev/ptmx is a bind-mount of /dev/pts/ptmx and the TIOCGPTPEER ioctl() is used to safely retrieve a file descriptor for the slave side of the pty based on the master fd, the /proc/self/fd/{0,1,2} symlinks will

[PATCH 3/3 v2] selftests: add devpts selftests

This adds a simple test to check whether /proc//fd/ symlinks are correctly pointing to /dev/pts/ devices when attached to a terminal. Signed-off-by: Christian Brauner --- ChangeLog v1->v2: * patch added ChangeLog v0->v1: * patch not present --- tools/testing/selftests/Makefile |

[PATCH 0/3 v2] devpts: handle /dev/ptmx bind-mounts

Hey everyone, This is the second iteration of this patch. Please note, that I added a selftest for correct /proc//fd/{0,1,2} symlinks and added it to tools/testing/selftests/filesystem because the root cause of the problem is located in the devpts filesystem. But I'm not sure if this is the right

[PATCH 2/3 v2] devpts: resolve devpts bind-mounts

Most libcs will still look at /dev/ptmx when opening the master fd of a pty device. When /dev/ptmx is a bind-mount of /dev/pts/ptmx and the TIOCGPTPEER ioctl() is used to safely retrieve a file descriptor for the slave side of the pty based on the master fd, the /proc/self/fd/{0,1,2} symlinks will

[PATCH 1/3 v2] devpts: hoist out check for DEVPTS_SUPER_MAGIC

Hoist the check whether we have already found a suitable devpts filesystem out of devpts_ptmx_path() in preparation for the devpts bind-mount resolution patch. This is a non-functional change. Signed-off-by: Christian Brauner --- ChangeLog v1->v2: * patch added

[PATCH 1/3 v2] devpts: hoist out check for DEVPTS_SUPER_MAGIC

Hoist the check whether we have already found a suitable devpts filesystem out of devpts_ptmx_path() in preparation for the devpts bind-mount resolution patch. This is a non-functional change. Signed-off-by: Christian Brauner --- ChangeLog v1->v2: * patch added ChangeLog v0->v1: * patch not

Re: [PATCH] kbuild: check for pkg-config on make menu/n/g/xconfig

On 11 March 2018 at 21:12, Randy Dunlap wrote: > +pkgcfg=`which pkg-config >/dev/null 2>&1` Please use "command -v" instead of "which". command -v is in POSIX, so the shell will have it for sure (builtin). which is not a builtin, it is an external command that may or may

Re: [PATCH] kbuild: check for pkg-config on make menu/n/g/xconfig

On 11 March 2018 at 21:12, Randy Dunlap wrote: > +pkgcfg=`which pkg-config >/dev/null 2>&1` Please use "command -v" instead of "which". command -v is in POSIX, so the shell will have it for sure (builtin). which is not a builtin, it is an external command that may or may not be installed on the

Re: [PATCH] rsi: Remove stack VLA usage

On Fri, Mar 09, 2018 at 12:37:06PM +0200, Kalle Valo wrote: > "Tobin C. Harding" writes: > > > The kernel would like to have all stack VLA usage removed[1]. rsi uses > > a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size > > is defined using a magic number.

Re: [PATCH] rsi: Remove stack VLA usage

On Fri, Mar 09, 2018 at 12:37:06PM +0200, Kalle Valo wrote: > "Tobin C. Harding" writes: > > > The kernel would like to have all stack VLA usage removed[1]. rsi uses > > a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size > > is defined using a magic number. We can use a

Re: [PATCH v2] net: netfilter: Replace printk() with appropriate pr_*() macro

Hi Joe, On Sun, Mar 11, 2018 at 12:52:41PM -0700, Joe Perches wrote: > On Mon, 2018-03-12 at 01:11 +0530, Arushi Singhal wrote: > > Using pr_() is more concise than > > printk(KERN_). > > Replace printks having a log level with the appropriate > > pr_*() macros. > > > > Signed-off-by: Arushi

Re: [PATCH v2] net: netfilter: Replace printk() with appropriate pr_*() macro

Hi Joe, On Sun, Mar 11, 2018 at 12:52:41PM -0700, Joe Perches wrote: > On Mon, 2018-03-12 at 01:11 +0530, Arushi Singhal wrote: > > Using pr_() is more concise than > > printk(KERN_). > > Replace printks having a log level with the appropriate > > pr_*() macros. > > > > Signed-off-by: Arushi

Re: [PATCH v8 1/6] arch: enable relative relocations for arm64, power and x86

On 11 March 2018 at 20:20, Linus Torvalds wrote: > On Sun, Mar 11, 2018 at 5:38 AM, Ard Biesheuvel > wrote: >> Before updating certain subsystems to use place relative 32-bit >> relocations in special sections, to save space and reduce

Re: [PATCH v8 1/6] arch: enable relative relocations for arm64, power and x86

On 11 March 2018 at 20:20, Linus Torvalds wrote: > On Sun, Mar 11, 2018 at 5:38 AM, Ard Biesheuvel > wrote: >> Before updating certain subsystems to use place relative 32-bit >> relocations in special sections, to save space and reduce the >> number of absolute relocations that need to be

Re: [PATCH v8 1/6] arch: enable relative relocations for arm64, power and x86

On Sun, Mar 11, 2018 at 5:38 AM, Ard Biesheuvel wrote: > Before updating certain subsystems to use place relative 32-bit > relocations in special sections, to save space and reduce the > number of absolute relocations that need to be processed at runtime > by

Re: [PATCH v8 1/6] arch: enable relative relocations for arm64, power and x86

On Sun, Mar 11, 2018 at 5:38 AM, Ard Biesheuvel wrote: > Before updating certain subsystems to use place relative 32-bit > relocations in special sections, to save space and reduce the > number of absolute relocations that need to be processed at runtime > by relocatable kernels, introduce the

Re: ivtv: use arch_phys_wc_add() and require PAT disabled

> On Mar 11, 2018, at 12:51 PM, Nick French wrote: > > On Sat, Mar 10, 2018 at 10:20:23AM -0800, Andy Lutomirski wrote: Perhaps the easy answer is to change the fatal is-pat-enabled check to just a warning like "you have PAT enabled, so wc is disabled for the

Re: ivtv: use arch_phys_wc_add() and require PAT disabled

> On Mar 11, 2018, at 12:51 PM, Nick French wrote: > > On Sat, Mar 10, 2018 at 10:20:23AM -0800, Andy Lutomirski wrote: Perhaps the easy answer is to change the fatal is-pat-enabled check to just a warning like "you have PAT enabled, so wc is disabled for the framebuffer.

Re: [PATCH bpf-next v8 01/11] fs,security: Add a security blob to nameidata

On 02/27/2018 02:23 AM, Al Viro wrote: > On Tue, Feb 27, 2018 at 12:57:21AM +, Al Viro wrote: >> On Tue, Feb 27, 2018 at 01:41:11AM +0100, Mickaël Salaün wrote: >>> The function current_nameidata_security(struct inode *) can be used to >>> retrieve a blob's pointer address tied to the inode

Re: [PATCH bpf-next v8 01/11] fs,security: Add a security blob to nameidata

On 02/27/2018 02:23 AM, Al Viro wrote: > On Tue, Feb 27, 2018 at 12:57:21AM +, Al Viro wrote: >> On Tue, Feb 27, 2018 at 01:41:11AM +0100, Mickaël Salaün wrote: >>> The function current_nameidata_security(struct inode *) can be used to >>> retrieve a blob's pointer address tied to the inode

Re: [RFC PATCH 00/35] remove in-kernel syscall invocations

On Sun, Mar 11, 2018 at 3:55 AM, Dominik Brodowski wrote: > Here is a first set of patches which reduce the number of syscall invocations > from within the kernel. This all looks ok to me. I think there may be some room for cleanup and bikeshedding later (the

Re: [RFC PATCH 00/35] remove in-kernel syscall invocations

On Sun, Mar 11, 2018 at 3:55 AM, Dominik Brodowski wrote: > Here is a first set of patches which reduce the number of syscall invocations > from within the kernel. This all looks ok to me. I think there may be some room for cleanup and bikeshedding later (the "ksys_mmap_pgoff()" name made me go

Re: [PATCH 5/5] media: MAINTAINERS: Add entry for Aptina MT9T112

Hi Jacopo, On Fri, Mar 02, 2018 at 05:35:41PM +0100, Jacopo Mondi wrote: > Add entry for Aptina/Micron MT9T112 camera sensor. The driver is > currently orphaned. > > Signed-off-by: Jacopo Mondi > --- > MAINTAINERS | 7 +++ > 1 file changed, 7 insertions(+) > >

Re: [PATCH 5/5] media: MAINTAINERS: Add entry for Aptina MT9T112

Hi Jacopo, On Fri, Mar 02, 2018 at 05:35:41PM +0100, Jacopo Mondi wrote: > Add entry for Aptina/Micron MT9T112 camera sensor. The driver is > currently orphaned. > > Signed-off-by: Jacopo Mondi > --- > MAINTAINERS | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/MAINTAINERS

[PATCH] kbuild: check for pkg-config on make menu/n/g/xconfig

From: Randy Dunlap Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure that other required files are present, but none of these check that pkg-config itself is present. Add a check for all 4 of these targets. Fixes kernel bugzilla #77511:

[PATCH] kbuild: check for pkg-config on make menu/n/g/xconfig

From: Randy Dunlap Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure that other required files are present, but none of these check that pkg-config itself is present. Add a check for all 4 of these targets. Fixes kernel bugzilla #77511:

Re: [PATCH v4 14/24] fpga: dfl: fme: add partial reconfiguration sub feature support

On Mon, 5 Mar 2018, Alan Tull wrote: Hi Hao, I do think we should consider different hw implementations with this code because it does look like most of it is generic. Specifically, I think we should consider DFH based fpga images that have been shipped already, and I think we need to

Re: [PATCH v4 14/24] fpga: dfl: fme: add partial reconfiguration sub feature support

On Mon, 5 Mar 2018, Alan Tull wrote: Hi Hao, I do think we should consider different hw implementations with this code because it does look like most of it is generic. Specifically, I think we should consider DFH based fpga images that have been shipped already, and I think we need to

Re: [GIT PULL] CRIS: Drop support for the CRIS-port

On Mon, Mar 12, 2018 at 01:13:44AM +1100, Stephen Rothwell wrote: > Hi Jesper, > > On Sun, 11 Mar 2018 12:05:51 +0100 Jesper Nilsson > wrote: > > > > As promised, pull the below tag for the removal of the CRIS-port. > > I guess the easiest thing for me to do is just

Re: [GIT PULL] CRIS: Drop support for the CRIS-port

On Mon, Mar 12, 2018 at 01:13:44AM +1100, Stephen Rothwell wrote: > Hi Jesper, > > On Sun, 11 Mar 2018 12:05:51 +0100 Jesper Nilsson > wrote: > > > > As promised, pull the below tag for the removal of the CRIS-port. > > I guess the easiest thing for me to do is just remove the cris tree > from

[PATCH v5 0/4] new driver for Valve Steam Controller

This patchset implements a driver for Valve Steam Controller, based on a reverse analysis by myself. Sorry, I've been out of town for a few weeks and couldn't keep up with this... @Pierre-Loup and @Clément, could you please have another look at this and check if it is worthy? Benjamin will not

[PATCH v5 0/4] new driver for Valve Steam Controller

This patchset implements a driver for Valve Steam Controller, based on a reverse analysis by myself. Sorry, I've been out of town for a few weeks and couldn't keep up with this... @Pierre-Loup and @Clément, could you please have another look at this and check if it is worthy? Benjamin will not

[PATCH v5 3/4] HID: steam: command to check wireless connection

The wireless adaptor does not tell if a device is already connected when steam_probe() is run. Use a command to request the connection status. Signed-off-by: Rodrigo Rivas Costa --- drivers/hid/hid-steam.c | 16 1 file changed, 16 insertions(+)

[PATCH v5 3/4] HID: steam: command to check wireless connection

The wireless adaptor does not tell if a device is already connected when steam_probe() is run. Use a command to request the connection status. Signed-off-by: Rodrigo Rivas Costa --- drivers/hid/hid-steam.c | 16 1 file changed, 16 insertions(+) diff --git

[PATCH v5 4/4] HID: steam: add battery device.

The wireless Steam Controller is battery operated, so add the battery device and power information. Signed-off-by: Rodrigo Rivas Costa --- drivers/hid/hid-steam.c | 141 +++- 1 file changed, 140 insertions(+), 1

[PATCH v5 4/4] HID: steam: add battery device.

The wireless Steam Controller is battery operated, so add the battery device and power information. Signed-off-by: Rodrigo Rivas Costa --- drivers/hid/hid-steam.c | 141 +++- 1 file changed, 140 insertions(+), 1 deletion(-) diff --git

[PATCH v5 1/4] HID: add driver for Valve Steam Controller

There are two ways to connect the Steam Controller: directly to the USB or with the USB wireless adapter. Both methods are similar, but the wireless adapter can connect up to 4 devices at the same time. The wired device will appear as 3 interfaces: a virtual mouse, a virtual keyboard and a

[PATCH v5 1/4] HID: add driver for Valve Steam Controller

There are two ways to connect the Steam Controller: directly to the USB or with the USB wireless adapter. Both methods are similar, but the wireless adapter can connect up to 4 devices at the same time. The wired device will appear as 3 interfaces: a virtual mouse, a virtual keyboard and a

[PATCH v5 2/4] HID: steam: add serial number information.

This device has a feature report to send and receive commands. Use it to get the serial number and set the device's uniq value. Signed-off-by: Rodrigo Rivas Costa --- drivers/hid/hid-steam.c | 108 ++-- 1 file changed, 105

[PATCH v5 2/4] HID: steam: add serial number information.

This device has a feature report to send and receive commands. Use it to get the serial number and set the device's uniq value. Signed-off-by: Rodrigo Rivas Costa --- drivers/hid/hid-steam.c | 108 ++-- 1 file changed, 105 insertions(+), 3

Re: [RESEND PATCH v3] crypto: add zBeWalgo compression for zram

Hi Benjamin, On Wed, Mar 07, 2018 at 12:50:08PM +0100, Benjamin Warnke wrote: > Hi Eric, > > > On 06.03.2018 at 23:13, Eric Biggers wrote: > > > > Hi Benjamin, > > > > On Tue, Mar 06, 2018 at 09:23:08PM +0100, Benjamin Warnke wrote: > >> Currently ZRAM uses compression-algorithms from the

Re: [RESEND PATCH v3] crypto: add zBeWalgo compression for zram

Hi Benjamin, On Wed, Mar 07, 2018 at 12:50:08PM +0100, Benjamin Warnke wrote: > Hi Eric, > > > On 06.03.2018 at 23:13, Eric Biggers wrote: > > > > Hi Benjamin, > > > > On Tue, Mar 06, 2018 at 09:23:08PM +0100, Benjamin Warnke wrote: > >> Currently ZRAM uses compression-algorithms from the

Re: [PATCH 0/3] tracing: Rewrite the function filter code

On Fri, Mar 09, 2018 at 09:34:42PM -0500, Steven Rostedt wrote: SNIP > Special thanks goes out to Al for his patience and his time that he spent in > educating us in a proper logical parser. > > Two patches were added to do some initial clean up. The last patch > implements Al's suggestions. I

Re: [PATCH 0/3] tracing: Rewrite the function filter code

On Fri, Mar 09, 2018 at 09:34:42PM -0500, Steven Rostedt wrote: SNIP > Special thanks goes out to Al for his patience and his time that he spent in > educating us in a proper logical parser. > > Two patches were added to do some initial clean up. The last patch > implements Al's suggestions. I

Re: [PATCH v2] net: netfilter: Replace printk() with appropriate pr_*() macro

On Mon, 2018-03-12 at 01:11 +0530, Arushi Singhal wrote: > Using pr_() is more concise than > printk(KERN_). > Replace printks having a log level with the appropriate > pr_*() macros. > > Signed-off-by: Arushi Singhal > --- > changes in v2 > *in v1 printk() were

Re: [PATCH v2] net: netfilter: Replace printk() with appropriate pr_*() macro

On Mon, 2018-03-12 at 01:11 +0530, Arushi Singhal wrote: > Using pr_() is more concise than > printk(KERN_). > Replace printks having a log level with the appropriate > pr_*() macros. > > Signed-off-by: Arushi Singhal > --- > changes in v2 > *in v1 printk() were replaced with netdev_*() >

Re: ivtv: use arch_phys_wc_add() and require PAT disabled

On Sat, Mar 10, 2018 at 10:20:23AM -0800, Andy Lutomirski wrote: >>> Perhaps the easy answer is to change the fatal is-pat-enabled check to just >>> a warning like "you have PAT enabled, so wc is disabled for the framebuffer. >>> if you want wc, use the nopat parameter"? >> >> I like this idea

Re: ivtv: use arch_phys_wc_add() and require PAT disabled

On Sat, Mar 10, 2018 at 10:20:23AM -0800, Andy Lutomirski wrote: >>> Perhaps the easy answer is to change the fatal is-pat-enabled check to just >>> a warning like "you have PAT enabled, so wc is disabled for the framebuffer. >>> if you want wc, use the nopat parameter"? >> >> I like this idea

Re: [PATCH] mm/slab.c: remove duplicated check of colour_next

On Sun, 11 Mar 2018, Roman Lakeev wrote: > Sorry for strange message in previous mail. > > remove check that offset greater than cachep->colour > bacause this is already checked in previous lines > > Signed-off-by: Roman Lakeev Acked-by: David Rientjes

Re: [PATCH] mm/slab.c: remove duplicated check of colour_next

On Sun, 11 Mar 2018, Roman Lakeev wrote: > Sorry for strange message in previous mail. > > remove check that offset greater than cachep->colour > bacause this is already checked in previous lines > > Signed-off-by: Roman Lakeev Acked-by: David Rientjes

Re: [PATCH v2] perf machine: Fix load kernel symbol with '-k' option

On Sat, Mar 10, 2018 at 05:50:56PM +0800, Leo Yan wrote: SNIP > > > diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c > > > index 12b7427..3125871 100644 > > > --- a/tools/perf/util/machine.c > > > +++ b/tools/perf/util/machine.c > > > @@ -1299,9 +1299,18 @@ static int > > >

Re: [PATCH v2] perf machine: Fix load kernel symbol with '-k' option

On Sat, Mar 10, 2018 at 05:50:56PM +0800, Leo Yan wrote: SNIP > > > diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c > > > index 12b7427..3125871 100644 > > > --- a/tools/perf/util/machine.c > > > +++ b/tools/perf/util/machine.c > > > @@ -1299,9 +1299,18 @@ static int > > >

[PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Currently the VDSO does not handle clock_gettime( CLOCK_MONOTONIC_RAW, ) on Intel / AMD - it calls vdso_fallback_gettime() for this clock, which issues a syscall, having an unacceptably high latency (minimum measurable time or time between measurements) of 300-700ns on 2

[PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Currently the VDSO does not handle clock_gettime( CLOCK_MONOTONIC_RAW, ) on Intel / AMD - it calls vdso_fallback_gettime() for this clock, which issues a syscall, having an unacceptably high latency (minimum measurable time or time between measurements) of 300-700ns on 2

Re: [RFCv4,19/21] media: vim2m: add request support

Hello, On 07.03.2018 19:37, Paul Kocialkowski wrote: > Hi, > > First off, I'd like to take the occasion to say thank-you for your work. > This is a major piece of plumbing that is required for me to add support > for the Allwinner CedarX VPU hardware in upstream Linux. Other drivers, > such as

Re: [RFCv4,19/21] media: vim2m: add request support

Hello, On 07.03.2018 19:37, Paul Kocialkowski wrote: > Hi, > > First off, I'd like to take the occasion to say thank-you for your work. > This is a major piece of plumbing that is required for me to add support > for the Allwinner CedarX VPU hardware in upstream Linux. Other drivers, > such as

Re: [PATCH v3 14/15] arm64: dts: mt7622: add High-Speed DMA device nodes

On 02/17/2018 08:54 PM, sean.w...@mediatek.com wrote: > From: Sean Wang > > add High-Speed DMA (HSDMA) nodes > > Signed-off-by: Sean Wang NAK. AFAIK the driver is not yest upstream Regards, Matthias > --- >

Re: [PATCH v3 14/15] arm64: dts: mt7622: add High-Speed DMA device nodes

On 02/17/2018 08:54 PM, sean.w...@mediatek.com wrote: > From: Sean Wang > > add High-Speed DMA (HSDMA) nodes > > Signed-off-by: Sean Wang NAK. AFAIK the driver is not yest upstream Regards, Matthias > --- > arch/arm64/boot/dts/mediatek/mt7622.dtsi | 10 ++ > 1 file changed, 10

[PATCH v2] net: netfilter: Replace printk() with appropriate pr_*() macro

Using pr_() is more concise than printk(KERN_). Replace printks having a log level with the appropriate pr_*() macros. Signed-off-by: Arushi Singhal --- changes in v2 *in v1 printk() were replaced with netdev_*() net/netfilter/nf_conntrack_acct.c | 2 +-

[PATCH v2] net: netfilter: Replace printk() with appropriate pr_*() macro

Using pr_() is more concise than printk(KERN_). Replace printks having a log level with the appropriate pr_*() macros. Signed-off-by: Arushi Singhal --- changes in v2 *in v1 printk() were replaced with netdev_*() net/netfilter/nf_conntrack_acct.c | 2 +-

Re: [RFCv4,19/21] media: vim2m: add request support

Hello, On 07.03.2018 19:37, Paul Kocialkowski wrote: > Hi, > > First off, I'd like to take the occasion to say thank-you for your work. > This is a major piece of plumbing that is required for me to add support > for the Allwinner CedarX VPU hardware in upstream Linux. Other drivers, > such as

Re: [RFCv4,19/21] media: vim2m: add request support

Hello, On 07.03.2018 19:37, Paul Kocialkowski wrote: > Hi, > > First off, I'd like to take the occasion to say thank-you for your work. > This is a major piece of plumbing that is required for me to add support > for the Allwinner CedarX VPU hardware in upstream Linux. Other drivers, > such as

Re: [PATCH 0/2] mtd: use put_device() if device_register fail

Am Freitag, 9. März 2018, 11:50:47 CET schrieb Arvind Yadav: > if device_register() returned an error! Always use put_device() > to give up the reference initialized. > > Arvind Yadav (2): > [PATCH 1/2] mtd: use put_device() if device_register fail > [PATCH 2/2] mtd: ubi: use put_device() if

Re: [PATCH 0/2] mtd: use put_device() if device_register fail

Am Freitag, 9. März 2018, 11:50:47 CET schrieb Arvind Yadav: > if device_register() returned an error! Always use put_device() > to give up the reference initialized. > > Arvind Yadav (2): > [PATCH 1/2] mtd: use put_device() if device_register fail > [PATCH 2/2] mtd: ubi: use put_device() if

[PATCH v2] media: ivtv: add parameter to enable ivtvfb on x86 PAT systems

ivtvfb was previously disabled for x86 PAT-enabled systems by commit 1bf1735b4780 ("x86/mm/pat, drivers/media/ivtv: Use arch_phys_wc_add() and require PAT disabled") as a workaround to abstract MTRR code away from device drivers. The driver is not easily upgradable to the PAT-aware ioremap_wc()

[PATCH v2] media: ivtv: add parameter to enable ivtvfb on x86 PAT systems

ivtvfb was previously disabled for x86 PAT-enabled systems by commit 1bf1735b4780 ("x86/mm/pat, drivers/media/ivtv: Use arch_phys_wc_add() and require PAT disabled") as a workaround to abstract MTRR code away from device drivers. The driver is not easily upgradable to the PAT-aware ioremap_wc()

[PATCH 1/1] net: check dev->reg_state before deref of napi netdev_ops

init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads to a NULL pointer dereference when sk_busy_loop fires against an iwlwifi wireless adapter and checks napi->dev->netdev_ops->ndo_busy_poll. Avoid this by ensuring that napi->dev is not a dummy device before dereferencing napi

[PATCH 0/1] net: avoid a kernel panic during sk_busy_loop

Hi Dave, I stumbled across a reproducible kernel panic while playing around with busy_poll on a Linux 4.9.86 kernel. There's an unfortunate interaction between init_dummy_netdev, which doesn't bother to fill in netdev_ops, and sk_busy_loop, which assumes netdev_ops is a valid pointer. To

[PATCH 1/1] net: check dev->reg_state before deref of napi netdev_ops

init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads to a NULL pointer dereference when sk_busy_loop fires against an iwlwifi wireless adapter and checks napi->dev->netdev_ops->ndo_busy_poll. Avoid this by ensuring that napi->dev is not a dummy device before dereferencing napi

[PATCH 0/1] net: avoid a kernel panic during sk_busy_loop

Hi Dave, I stumbled across a reproducible kernel panic while playing around with busy_poll on a Linux 4.9.86 kernel. There's an unfortunate interaction between init_dummy_netdev, which doesn't bother to fill in netdev_ops, and sk_busy_loop, which assumes netdev_ops is a valid pointer. To

[PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Currently the VDSO does not handle clock_gettime( CLOCK_MONOTONIC_RAW, ) on Intel / AMD - it calls vdso_fallback_gettime() for this clock, which issues a syscall, having an unacceptably high latency (minimum measurable time or time between measurements) of 300-700ns on 2

[PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Currently the VDSO does not handle clock_gettime( CLOCK_MONOTONIC_RAW, ) on Intel / AMD - it calls vdso_fallback_gettime() for this clock, which issues a syscall, having an unacceptably high latency (minimum measurable time or time between measurements) of 300-700ns on 2

Re: [RFC v2 05/83] Add NOVA filesystem definitions and useful helper routines.

On Sun, Mar 11, 2018 at 02:00:13PM +0200, Nikolay Borisov wrote: > [Adding Herbert Xu to CC since he is the maintainer of the crypto subsys > maintainer] > > On 10.03.2018 20:17, Andiry Xu wrote: > > > > +static inline u32 nova_crc32c(u32 crc, const u8 *data, size_t len) > > +{ > > + u8 *ptr

Re: [RFC v2 05/83] Add NOVA filesystem definitions and useful helper routines.

On Sun, Mar 11, 2018 at 02:00:13PM +0200, Nikolay Borisov wrote: > [Adding Herbert Xu to CC since he is the maintainer of the crypto subsys > maintainer] > > On 10.03.2018 20:17, Andiry Xu wrote: > > > > +static inline u32 nova_crc32c(u32 crc, const u8 *data, size_t len) > > +{ > > + u8 *ptr

Re: [PATCH v5 02/11] xfs, dax: introduce xfs_dax_aops

On Sat, Mar 10, 2018 at 9:40 AM, Dan Williams wrote: > On Sat, Mar 10, 2018 at 1:46 AM, Christoph Hellwig wrote: >>> +int dax_set_page_dirty(struct page *page) >>> +{ >>> + /* >>> + * Unlike __set_page_dirty_no_writeback that handles dirty page >>>

Re: [PATCH v5 02/11] xfs, dax: introduce xfs_dax_aops

On Sat, Mar 10, 2018 at 9:40 AM, Dan Williams wrote: > On Sat, Mar 10, 2018 at 1:46 AM, Christoph Hellwig wrote: >>> +int dax_set_page_dirty(struct page *page) >>> +{ >>> + /* >>> + * Unlike __set_page_dirty_no_writeback that handles dirty page >>> + * tracking in the page object,

Re: [PATCH v3 01/15] dt-bindings: clock: mediatek: add missing required #reset-cells

On 02/17/2018 08:54 PM, sean.w...@mediatek.com wrote: > From: Sean Wang > > All ethsys, pciesys and ssusbsys internally include reset controller, so > explicitly add back these missing cell definitions to related bindings > and examples. > > Signed-off-by: Sean Wang

Re: [PATCH v3 01/15] dt-bindings: clock: mediatek: add missing required #reset-cells

On 02/17/2018 08:54 PM, sean.w...@mediatek.com wrote: > From: Sean Wang > > All ethsys, pciesys and ssusbsys internally include reset controller, so > explicitly add back these missing cell definitions to related bindings > and examples. > > Signed-off-by: Sean Wang > Cc: Rob Herring > Cc:

<    2   3   4   5   6   7   8   9   10   >