[PATCH v2 1/1] usb: xhci: dbc: Add SPDX identifiers to dbc files

Update the xhci dbc files with the correct SPDX license identifiers. Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Cc: Philippe Ombredanne Signed-off-by: Lu Baolu --- changes from v1: * Use plain C style comments in header

[PATCH v2 1/1] usb: xhci: dbc: Add SPDX identifiers to dbc files

Update the xhci dbc files with the correct SPDX license identifiers. Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Cc: Philippe Ombredanne Signed-off-by: Lu Baolu --- changes from v1: * Use plain C style comments in header file. drivers/usb/host/xhci-dbgcap.c | 1 +

[PATCH] clk: mediatek: Fix all warnings for missing struct clk_onecell_data

From: Sean Wang In fact, the clk-mtk.h header is unnecessary for reset.c and thus it's safe to remove it from the file to get rid of below build warnings. All warnings (new ones prefixed by >>): In file included from drivers/clk/mediatek/reset.c:22:0:

[PATCH] clk: mediatek: Fix all warnings for missing struct clk_onecell_data

From: Sean Wang In fact, the clk-mtk.h header is unnecessary for reset.c and thus it's safe to remove it from the file to get rid of below build warnings. All warnings (new ones prefixed by >>): In file included from drivers/clk/mediatek/reset.c:22:0: >>drivers/clk/mediatek/clk-mtk.h:44:19:

Re: [PATCH] arm: dts: mt7623: enable all four available UARTs on bananapi-r2

On 12/22/2017 07:06 AM, sean.w...@mediatek.com wrote: > From: Sean Wang > > On bpi-r2 board, totally there're four uarts which we usually called > uart[0-3] helpful to extend slow I/O devices. Among those ones, uart2 has > dedicated pin slot which is used to conolse

Re: [PATCH] arm: dts: mt7623: enable all four available UARTs on bananapi-r2

On 12/22/2017 07:06 AM, sean.w...@mediatek.com wrote: > From: Sean Wang > > On bpi-r2 board, totally there're four uarts which we usually called > uart[0-3] helpful to extend slow I/O devices. Among those ones, uart2 has > dedicated pin slot which is used to conolse log. uart[0-1] appear at

Re: [PATCH 1/1] usb: xhci: dbc: Add SPDX identifiers to dbc files

Hi, On 12/22/2017 04:32 PM, Philippe Ombredanne wrote: > Lu, > > On Fri, Dec 22, 2017 at 2:34 AM, Lu Baolu wrote: >> Update the xhci dbc files with the correct SPDX license identifiers. >> >> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") >>

Re: [PATCH 1/1] usb: xhci: dbc: Add SPDX identifiers to dbc files

Hi, On 12/22/2017 04:32 PM, Philippe Ombredanne wrote: > Lu, > > On Fri, Dec 22, 2017 at 2:34 AM, Lu Baolu wrote: >> Update the xhci dbc files with the correct SPDX license identifiers. >> >> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") >> Signed-off-by: Lu Baolu >> --- >>

Re: [PATCH 04/11] x86: geode: constify gpio_led

Hi Arvind, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on arm-soc/for-next] [also build test WARNING on v4.15-rc4 next-20171222] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com

Re: [PATCH 04/11] x86: geode: constify gpio_led

Hi Arvind, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on arm-soc/for-next] [also build test WARNING on v4.15-rc4 next-20171222] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com

Re: [PATCH 0/1] Re: kernel BUG at fs/userfaultfd.c:LINE!

On Sat, Dec 23, 2017 at 1:25 AM, Andrea Arcangeli wrote: > Hello, > > Thanks for the CC, I'm temporarily very busy so if there's something > urgent, safer to CC. Hi, syzbot uses get_maintainer.pl and for fs/userfaultfd.c you are not there, so if you want to be CCed please

Re: [PATCH 0/1] Re: kernel BUG at fs/userfaultfd.c:LINE!

On Sat, Dec 23, 2017 at 1:25 AM, Andrea Arcangeli wrote: > Hello, > > Thanks for the CC, I'm temporarily very busy so if there's something > urgent, safer to CC. Hi, syzbot uses get_maintainer.pl and for fs/userfaultfd.c you are not there, so if you want to be CCed please add yourself to

Re: [PATCH v16 3/5] mfd: Add driver for RAVE Supervisory Processor

Hi Andrey, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.15-rc4] [cannot apply to next-20171222] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: [PATCH v16 3/5] mfd: Add driver for RAVE Supervisory Processor

Hi Andrey, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.15-rc4] [cannot apply to next-20171222] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: platform/x86/thinkpad_acpi: Adjustments for four function implementations

>> Do you find the Linux allocation failure report insufficient in this case? > > Leave those pr_ messages alone, please, Have you got special software development concerns? > unless they are really causing some sort of issue (which?). Can the code be redundant here? > Doing it just for

Re: platform/x86/thinkpad_acpi: Adjustments for four function implementations

>> Do you find the Linux allocation failure report insufficient in this case? > > Leave those pr_ messages alone, please, Have you got special software development concerns? > unless they are really causing some sort of issue (which?). Can the code be redundant here? > Doing it just for

Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT

On 12/23/2017 03:43 AM, Ross Zwisler wrote: > On Fri, Dec 22, 2017 at 08:39:41AM +0530, Anshuman Khandual wrote: >> On 12/14/2017 07:40 AM, Ross Zwisler wrote: >>> Quick Summary >>> >>> Platforms exist today which have multiple types of memory attached to a >>> single CPU. These

Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT

On 12/23/2017 03:43 AM, Ross Zwisler wrote: > On Fri, Dec 22, 2017 at 08:39:41AM +0530, Anshuman Khandual wrote: >> On 12/14/2017 07:40 AM, Ross Zwisler wrote: >>> Quick Summary >>> >>> Platforms exist today which have multiple types of memory attached to a >>> single CPU. These

Re: Prototype patch for Linux-kernel memory model

Hi, On Fri, Dec 22, 2017 at 09:41:32AM +0530, afzal mohammed wrote: > On Thu, Dec 21, 2017 at 08:15:02AM -0800, Paul E. McKenney wrote: > > Have you installed and run the herd tool? Doing so would allow you > > to experiment with changes to the litmus tests. > > Yes, i installed herd tool and

Re: Prototype patch for Linux-kernel memory model

Hi, On Fri, Dec 22, 2017 at 09:41:32AM +0530, afzal mohammed wrote: > On Thu, Dec 21, 2017 at 08:15:02AM -0800, Paul E. McKenney wrote: > > Have you installed and run the herd tool? Doing so would allow you > > to experiment with changes to the litmus tests. > > Yes, i installed herd tool and

Re: [RFC][PATCH][REGRESSION FIX] x86/ftrace: Add ORC annotation to 64 bit ftrace assembly

On Fri, 22 Dec 2017 20:43:37 -0600 Josh Poimboeuf wrote: > Objtool doesn't like the fact that save_mcount_regs pushes rbp at the > beginning, but it's never restored (directly, at least). > > How about something like this instead, where it skips the original rbp > push? I

Re: [RFC][PATCH][REGRESSION FIX] x86/ftrace: Add ORC annotation to 64 bit ftrace assembly

On Fri, 22 Dec 2017 20:43:37 -0600 Josh Poimboeuf wrote: > Objtool doesn't like the fact that save_mcount_regs pushes rbp at the > beginning, but it's never restored (directly, at least). > > How about something like this instead, where it skips the original rbp > push? I didn't test it, but I

Re: [RFC] does ioremap() cause memory leak?

On 2017/12/21 16:55, Xishi Qiu wrote: > When we use iounmap() to free the mapping, it calls unmap_vmap_area() to > clear page table, > but do not free the memory of page table, right? > > So when use ioremap() to mapping another area(incluce the area before), it > may use > large mapping(e.g.

Re: [RFC] does ioremap() cause memory leak?

On 2017/12/21 16:55, Xishi Qiu wrote: > When we use iounmap() to free the mapping, it calls unmap_vmap_area() to > clear page table, > but do not free the memory of page table, right? > > So when use ioremap() to mapping another area(incluce the area before), it > may use > large mapping(e.g.

Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114

On Wed, Dec 20, 2017 at 01:33:45AM +0100, Thomas Gleixner wrote: > On Tue, 19 Dec 2017, vcap...@pengaru.com wrote: > > On Wed, Dec 20, 2017 at 12:22:12AM +0100, Pavel Machek wrote: > > > You forgot to mention commit id :-). > > > > > > > That is very strange, anyhow: > > > > commit

Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114

On Wed, Dec 20, 2017 at 01:33:45AM +0100, Thomas Gleixner wrote: > On Tue, 19 Dec 2017, vcap...@pengaru.com wrote: > > On Wed, Dec 20, 2017 at 12:22:12AM +0100, Pavel Machek wrote: > > > You forgot to mention commit id :-). > > > > > > > That is very strange, anyhow: > > > > commit

Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT

On 12/22/2017 10:43 PM, Dave Hansen wrote: > On 12/21/2017 07:09 PM, Anshuman Khandual wrote: >> I had presented a proposal for NUMA redesign in the Plumbers Conference this >> year where various memory devices with different kind of memory attributes >> can be represented in the kernel and be

Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT

On 12/22/2017 10:43 PM, Dave Hansen wrote: > On 12/21/2017 07:09 PM, Anshuman Khandual wrote: >> I had presented a proposal for NUMA redesign in the Plumbers Conference this >> year where various memory devices with different kind of memory attributes >> can be represented in the kernel and be

Re: [PATCH v11 2/6] mailbox: qcom: Create APCS child device for clock controller

On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov wrote: > There is a clock controller functionality provided by the APCS hardware > block of msm8916 devices. The device-tree would represent an APCS node > with both mailbox and clock provider properties. > The spec might

Re: [PATCH v11 2/6] mailbox: qcom: Create APCS child device for clock controller

On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov wrote: > There is a clock controller functionality provided by the APCS hardware > block of msm8916 devices. The device-tree would represent an APCS node > with both mailbox and clock provider properties. > The spec might depict a 'clock' box and

Re: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop

I was just now trying to track down my other issue, whereby somewhere along the tree kexec stops working properly. In the process of doing that I realized I had initially made one change to the original 4.9 config beyond oldconfig: I'd turned off WX debugging. I've now compiled a bunch of

Re: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop

I was just now trying to track down my other issue, whereby somewhere along the tree kexec stops working properly. In the process of doing that I realized I had initially made one change to the original 4.9 config beyond oldconfig: I'd turned off WX debugging. I've now compiled a bunch of

Re: [PATCH RESEND 1/1] cpufreq: imx6q: switch to Use clk_bulk_get to refine clk operations

On Fri, Dec 22, 2017 at 07:34:57PM +0100, Rafael J. Wysocki wrote: > On Thursday, December 21, 2017 2:18:01 PM CET Dong Aisheng wrote: > > Hi Rafael, > > > > On Thu, Sep 14, 2017 at 02:40:32PM -0700, Viresh Kumar wrote: > > > On 31-08-17, 19:43, Dong Aisheng wrote: > > > > Use clk_bulk_get to

Re: [PATCH RESEND 1/1] cpufreq: imx6q: switch to Use clk_bulk_get to refine clk operations

On Fri, Dec 22, 2017 at 07:34:57PM +0100, Rafael J. Wysocki wrote: > On Thursday, December 21, 2017 2:18:01 PM CET Dong Aisheng wrote: > > Hi Rafael, > > > > On Thu, Sep 14, 2017 at 02:40:32PM -0700, Viresh Kumar wrote: > > > On 31-08-17, 19:43, Dong Aisheng wrote: > > > > Use clk_bulk_get to

kasan for bpf

Hi All, the recent bugs make people question the safety of bpf and not a surprise that some folks propose to set kernel.unprivileged_bpf_disabled = 1 by default. I think it will be wrong long term decision, since it will steer bpf into "root only" mentality. The verifier checks will become

kasan for bpf

Hi All, the recent bugs make people question the safety of bpf and not a surprise that some folks propose to set kernel.unprivileged_bpf_disabled = 1 by default. I think it will be wrong long term decision, since it will steer bpf into "root only" mentality. The verifier checks will become

[PATCH] mm/fadvise: discard partial pages iff endbyte is also eof

From: "shidao.ytt" in commit 441c228f817f7 ("mm: fadvise: document the fadvise(FADV_DONTNEED) behaviour for partial pages") Mel Gorman explained why partial pages should be preserved instead of discarded when using fadvise(FADV_DONTNEED), however the actual codes to

[PATCH] mm/fadvise: discard partial pages iff endbyte is also eof

From: "shidao.ytt" in commit 441c228f817f7 ("mm: fadvise: document the fadvise(FADV_DONTNEED) behaviour for partial pages") Mel Gorman explained why partial pages should be preserved instead of discarded when using fadvise(FADV_DONTNEED), however the actual codes to calcuate end_index was

Re: [PATCH 11/11] evm: Don't update hmacs in user ns mounts

On Fri, Dec 22, 2017 at 03:32:35PM +0100, Dongsu Park wrote: > From: Seth Forshee > > The kernel should not calculate new hmacs for mounts done by > non-root users. Update evm_calc_hmac_or_hash() to refuse to > calculate new hmacs for mounts for non-init user

Re: [PATCH 11/11] evm: Don't update hmacs in user ns mounts

On Fri, Dec 22, 2017 at 03:32:35PM +0100, Dongsu Park wrote: > From: Seth Forshee > > The kernel should not calculate new hmacs for mounts done by > non-root users. Update evm_calc_hmac_or_hash() to refuse to > calculate new hmacs for mounts for non-init user namespaces. > > Cc:

Re: [PATCH] On ppc64le we HAVE_RELIABLE_STACKTRACE

On Thu, Dec 21, 2017 at 11:10:46PM +1100, Michael Ellerman wrote: > Josh Poimboeuf writes: > > > On Tue, Dec 19, 2017 at 12:28:33PM +0100, Torsten Duwe wrote: > >> On Mon, Dec 18, 2017 at 12:56:22PM -0600, Josh Poimboeuf wrote: > >> > On Mon, Dec 18, 2017 at 03:33:34PM

Re: [PATCH] On ppc64le we HAVE_RELIABLE_STACKTRACE

On Thu, Dec 21, 2017 at 11:10:46PM +1100, Michael Ellerman wrote: > Josh Poimboeuf writes: > > > On Tue, Dec 19, 2017 at 12:28:33PM +0100, Torsten Duwe wrote: > >> On Mon, Dec 18, 2017 at 12:56:22PM -0600, Josh Poimboeuf wrote: > >> > On Mon, Dec 18, 2017 at 03:33:34PM +1000, Nicholas Piggin

Re: [PATCH 10/11] fuse: Allow user namespace mounts

On Fri, Dec 22, 2017 at 03:32:34PM +0100, Dongsu Park wrote: > From: Seth Forshee > > To be able to mount fuse from non-init user namespaces, it's necessary > to set FS_USERNS_MOUNT flag to fs_flags. > > Patch v4 is available:

Re: [PATCH 10/11] fuse: Allow user namespace mounts

On Fri, Dec 22, 2017 at 03:32:34PM +0100, Dongsu Park wrote: > From: Seth Forshee > > To be able to mount fuse from non-init user namespaces, it's necessary > to set FS_USERNS_MOUNT flag to fs_flags. > > Patch v4 is available: https://patchwork.kernel.org/patch/8944681/ > > Cc:

Re: [PATCH 09/11] fuse: Restrict allow_other to the superblock's namespace or a descendant

On Fri, Dec 22, 2017 at 03:32:33PM +0100, Dongsu Park wrote: > From: Seth Forshee > > Unprivileged users are normally restricted from mounting with the > allow_other option by system policy, but this could be bypassed > for a mount done with user namespace root

Re: [PATCH 09/11] fuse: Restrict allow_other to the superblock's namespace or a descendant

On Fri, Dec 22, 2017 at 03:32:33PM +0100, Dongsu Park wrote: > From: Seth Forshee > > Unprivileged users are normally restricted from mounting with the > allow_other option by system policy, but this could be bypassed > for a mount done with user namespace root permissions. In such > cases

Re: [PATCH 08/11] fuse: Support fuse filesystems outside of init_user_ns

On Fri, Dec 22, 2017 at 03:32:32PM +0100, Dongsu Park wrote: > From: Seth Forshee > > In order to support mounts from namespaces other than > init_user_ns, fuse must translate uids and gids to/from the > userns of the process servicing requests on /dev/fuse. This >

Re: [PATCH 08/11] fuse: Support fuse filesystems outside of init_user_ns

On Fri, Dec 22, 2017 at 03:32:32PM +0100, Dongsu Park wrote: > From: Seth Forshee > > In order to support mounts from namespaces other than > init_user_ns, fuse must translate uids and gids to/from the > userns of the process servicing requests on /dev/fuse. This > patch does that, with a couple

Re: [PATCH v4] fsck.f2fs: check and fix i_namelen to avoid double free

And there is en[namelen] = '\0', should fix namelen to its right value. On 2017/12/23 11:35, Chao Yu wrote: On 2017/12/23 11:19, Yunlong Song wrote: Double free problem: Since ddr bit jump makes i_namelen a larger value (> 255)，when file is not encrypted, the convert_encrypted_name will memcpy

Re: [PATCH v4] fsck.f2fs: check and fix i_namelen to avoid double free

And there is en[namelen] = '\0', should fix namelen to its right value. On 2017/12/23 11:35, Chao Yu wrote: On 2017/12/23 11:19, Yunlong Song wrote: Double free problem: Since ddr bit jump makes i_namelen a larger value (> 255)，when file is not encrypted, the convert_encrypted_name will memcpy

Re: [PATCH 07/11] fs: Allow CAP_SYS_ADMIN in s_user_ns to freeze and thaw filesystems

On Fri, Dec 22, 2017 at 03:32:31PM +0100, Dongsu Park wrote: > From: Seth Forshee > > The user in control of a super block should be allowed to freeze > and thaw it. Relax the restrictions on the FIFREEZE and FITHAW > ioctls to require CAP_SYS_ADMIN in s_user_ns. > >

Re: [PATCH 07/11] fs: Allow CAP_SYS_ADMIN in s_user_ns to freeze and thaw filesystems

On Fri, Dec 22, 2017 at 03:32:31PM +0100, Dongsu Park wrote: > From: Seth Forshee > > The user in control of a super block should be allowed to freeze > and thaw it. Relax the restrictions on the FIFREEZE and FITHAW > ioctls to require CAP_SYS_ADMIN in s_user_ns. > > Cc:

Re: [PATCH v2] fsck.f2fs: check nid range before use to avoid segmentation fault

Both are OK, since nid < root_ino cannot trigger segmentation fault (nat_block->entries[nid%NAT_ENTRY_PER_BLOCK]). On 2017/12/23 11:14, Chao Yu wrote: On 2017/12/18 19:53, Yunlong Song wrote: Signed-off-by: Yunlong Song How about introducing IS_AVAILABLE_NID as

Re: [PATCH v2] fsck.f2fs: check nid range before use to avoid segmentation fault

Both are OK, since nid < root_ino cannot trigger segmentation fault (nat_block->entries[nid%NAT_ENTRY_PER_BLOCK]). On 2017/12/23 11:14, Chao Yu wrote: On 2017/12/18 19:53, Yunlong Song wrote: Signed-off-by: Yunlong Song How about introducing IS_AVAILABLE_NID as below, and use it instead?

Re: [PATCH v4] fsck.f2fs: check and fix i_namelen to avoid double free

On 2017/12/23 11:19, Yunlong Song wrote: > Double free problem: > Since ddr bit jump makes i_namelen a larger value (> 255)，when file is > not encrypted, > the convert_encrypted_name will memcpy out range of en[255], when en is > freed, there > will be double free problem. It looks there is

Re: [PATCH v4] fsck.f2fs: check and fix i_namelen to avoid double free

On 2017/12/23 11:19, Yunlong Song wrote: > Double free problem: > Since ddr bit jump makes i_namelen a larger value (> 255)，when file is > not encrypted, > the convert_encrypted_name will memcpy out range of en[255], when en is > freed, there > will be double free problem. It looks there is

Re: [PATCH 06/11] capabilities: Allow privileged user in s_user_ns to set security.* xattrs

On Fri, Dec 22, 2017 at 03:32:30PM +0100, Dongsu Park wrote: > From: Seth Forshee > > A privileged user in s_user_ns will generally have the ability to > manipulate the backing store and insert security.* xattrs into > the filesystem directly. Therefore the kernel

Re: [PATCH 06/11] capabilities: Allow privileged user in s_user_ns to set security.* xattrs

On Fri, Dec 22, 2017 at 03:32:30PM +0100, Dongsu Park wrote: > From: Seth Forshee > > A privileged user in s_user_ns will generally have the ability to > manipulate the backing store and insert security.* xattrs into > the filesystem directly. Therefore the kernel must be prepared to > handle

Re: [PATCH 05/11] fs: Allow superblock owner to access do_remount_sb()

On Fri, Dec 22, 2017 at 03:32:29PM +0100, Dongsu Park wrote: > From: Seth Forshee > > Superblock level remounts are currently restricted to global > CAP_SYS_ADMIN, as is the path for changing the root mount to > read only on umount. Loosen both of these permission

Re: [PATCH 05/11] fs: Allow superblock owner to access do_remount_sb()

On Fri, Dec 22, 2017 at 03:32:29PM +0100, Dongsu Park wrote: > From: Seth Forshee > > Superblock level remounts are currently restricted to global > CAP_SYS_ADMIN, as is the path for changing the root mount to > read only on umount. Loosen both of these permission checks to > also allow

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

On Sat, Dec 23, 2017 at 11:59:54AM +0900, Tetsuo Handa wrote: > Matthew Wilcox wrote: > > + bit %= IDA_BITMAP_BITS; > > + radix_tree_iter_init(, index); > > + slot = idr_get_free_cmn(root, , GFP_NOWAIT | __GFP_NOWARN, index); > > + if (IS_ERR(slot)) { > > + if (slot ==

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

On Sat, Dec 23, 2017 at 11:59:54AM +0900, Tetsuo Handa wrote: > Matthew Wilcox wrote: > > + bit %= IDA_BITMAP_BITS; > > + radix_tree_iter_init(, index); > > + slot = idr_get_free_cmn(root, , GFP_NOWAIT | __GFP_NOWARN, index); > > + if (IS_ERR(slot)) { > > + if (slot ==

Re: [PATCH 04/11] fs: Don't remove suid for CAP_FSETID for userns root

On Fri, Dec 22, 2017 at 03:32:28PM +0100, Dongsu Park wrote: > From: Seth Forshee > > Expand the check in should_remove_suid() to keep privileges for I realize this description came from Seth, but reading it now, 'Expand' seems wrong. Expanding a check brings to my

Re: [PATCH 04/11] fs: Don't remove suid for CAP_FSETID for userns root

On Fri, Dec 22, 2017 at 03:32:28PM +0100, Dongsu Park wrote: > From: Seth Forshee > > Expand the check in should_remove_suid() to keep privileges for I realize this description came from Seth, but reading it now, 'Expand' seems wrong. Expanding a check brings to my mind making it stricter, not

Re: [PATCH v4] fsck.f2fs: check and fix i_namelen to avoid double free

Double free problem: Since ddr bit jump makes i_namelen a larger value (> 255)，when file is not encrypted, the convert_encrypted_name will memcpy out range of en[255], when en is freed, there will be double free problem. On 2017/12/23 11:05, Chao Yu wrote: On 2017/12/18 21:25, Yunlong Song

Re: [PATCH v4] fsck.f2fs: check and fix i_namelen to avoid double free

Double free problem: Since ddr bit jump makes i_namelen a larger value (> 255)，when file is not encrypted, the convert_encrypted_name will memcpy out range of en[255], when en is freed, there will be double free problem. On 2017/12/23 11:05, Chao Yu wrote: On 2017/12/18 21:25, Yunlong Song

Re: [PATCH 03/11] fs: Allow superblock owner to change ownership of inodes

On Fri, Dec 22, 2017 at 03:32:27PM +0100, Dongsu Park wrote: > From: Eric W. Biederman > > Allow users with CAP_SYS_CHOWN over the superblock of a filesystem to Note it is CAP_CHOWN > chown files. Ordinarily the capable_wrt_inode_uidgid check is > sufficient to allow

Re: [PATCH 03/11] fs: Allow superblock owner to change ownership of inodes

On Fri, Dec 22, 2017 at 03:32:27PM +0100, Dongsu Park wrote: > From: Eric W. Biederman > > Allow users with CAP_SYS_CHOWN over the superblock of a filesystem to Note it is CAP_CHOWN > chown files. Ordinarily the capable_wrt_inode_uidgid check is > sufficient to allow access to files but when

Re: [PATCH v2] fsck.f2fs: check nid range before use to avoid segmentation fault

On 2017/12/18 19:53, Yunlong Song wrote: > Signed-off-by: Yunlong Song How about introducing IS_AVAILABLE_NID as below, and use it instead? #define IS_AVAILABLE_NID(sbi, nid) (IS_VALID_NID(sbi, nid) && (nid >= root_ino)) Thanks, > --- > fsck/fsck.c | 2 +- > 1

Re: [PATCH v2] fsck.f2fs: check nid range before use to avoid segmentation fault

On 2017/12/18 19:53, Yunlong Song wrote: > Signed-off-by: Yunlong Song How about introducing IS_AVAILABLE_NID as below, and use it instead? #define IS_AVAILABLE_NID(sbi, nid) (IS_VALID_NID(sbi, nid) && (nid >= root_ino)) Thanks, > --- > fsck/fsck.c | 2 +- > 1 file changed, 1

Re: [PATCH v4] fsck.f2fs: check and fix i_namelen to avoid double free

On 2017/12/18 21:25, Yunlong Song wrote: > v1 -> v2: use child_info to pass dentry namelen > v2 -> v3: check child != NULL to include the F2FS_FT_ORPHAN file type > v3 -> v4: fix the i_namelen problem of dump.f2fs、 There is no commit log, so what do you mean about "avoid double free"? Other than

Re: [PATCH v4] fsck.f2fs: check and fix i_namelen to avoid double free

On 2017/12/18 21:25, Yunlong Song wrote: > v1 -> v2: use child_info to pass dentry namelen > v2 -> v3: check child != NULL to include the F2FS_FT_ORPHAN file type > v3 -> v4: fix the i_namelen problem of dump.f2fs、 There is no commit log, so what do you mean about "avoid double free"? Other than

Re: [PATCH 02/11] mtd: Check permissions towards mtd block device inode when mounting

On Fri, Dec 22, 2017 at 03:32:26PM +0100, Dongsu Park wrote: > From: Seth Forshee > > Unprivileged users should not be able to mount mtd block devices > when they lack sufficient privileges towards the block device > inode. Update mount_mtd() to validate that the

Re: [PATCH 02/11] mtd: Check permissions towards mtd block device inode when mounting

On Fri, Dec 22, 2017 at 03:32:26PM +0100, Dongsu Park wrote: > From: Seth Forshee > > Unprivileged users should not be able to mount mtd block devices > when they lack sufficient privileges towards the block device > inode. Update mount_mtd() to validate that the user has the > required access

Re: [PATCH 01/11] block_dev: Support checking inode permissions in lookup_bdev()

On Fri, Dec 22, 2017 at 03:32:25PM +0100, Dongsu Park wrote: > From: Seth Forshee > > When looking up a block device by path no permission check is > done to verify that the user has access to the block device inode > at the specified path. In some cases it may be

Re: [PATCH 01/11] block_dev: Support checking inode permissions in lookup_bdev()

On Fri, Dec 22, 2017 at 03:32:25PM +0100, Dongsu Park wrote: > From: Seth Forshee > > When looking up a block device by path no permission check is > done to verify that the user has access to the block device inode > at the specified path. In some cases it may be necessary to > check

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

Matthew Wilcox wrote: > +/** > + * xb_set_bit() - Set a bit in the XBitmap. > + * @xb: The XBitmap. > + * @bit: Index of the bit to set. > + * > + * This function is used to set a bit in the xbitmap. > + * > + * Return: 0 on success. -ENOMEM if memory could not be allocated. > + */ > +int

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

Matthew Wilcox wrote: > +/** > + * xb_set_bit() - Set a bit in the XBitmap. > + * @xb: The XBitmap. > + * @bit: Index of the bit to set. > + * > + * This function is used to set a bit in the xbitmap. > + * > + * Return: 0 on success. -ENOMEM if memory could not be allocated. > + */ > +int

Re: [RFC][PATCH][REGRESSION FIX] x86/ftrace: Add ORC annotation to 64 bit ftrace assembly

On Fri, Dec 22, 2017 at 01:38:01PM -0500, Steven Rostedt wrote: > On Fri, 22 Dec 2017 12:30:24 -0600 > Josh Poimboeuf wrote: > > > I'm officially on vacation but I got a chance to look at this myself a > > few minutes ago. This looks mostly right. In theory, you should

Re: [RFC][PATCH][REGRESSION FIX] x86/ftrace: Add ORC annotation to 64 bit ftrace assembly

On Fri, Dec 22, 2017 at 01:38:01PM -0500, Steven Rostedt wrote: > On Fri, 22 Dec 2017 12:30:24 -0600 > Josh Poimboeuf wrote: > > > I'm officially on vacation but I got a chance to look at this myself a > > few minutes ago. This looks mostly right. In theory, you should able > > to mark those

[PATCH] usbip: fix vudc_rx: harden CMD_SUBMIT path to handle malicious input

Harden CMD_SUBMIT path to handle malicious input that could trigger large memory allocations. Add checks to validate transfer_buffer_length and number_of_packets to protect against bad input requesting for unbounded memory allocations. Signed-off-by: Shuah Khan ---

[PATCH] usbip: fix vudc_rx: harden CMD_SUBMIT path to handle malicious input

Harden CMD_SUBMIT path to handle malicious input that could trigger large memory allocations. Add checks to validate transfer_buffer_length and number_of_packets to protect against bad input requesting for unbounded memory allocations. Signed-off-by: Shuah Khan --- drivers/usb/usbip/vudc_rx.c |

[PATCH] usbip: vudc_tx: fix v_send_ret_submit() vulnerability to null xfer buffer

v_send_ret_submit() handles urb with a null transfer_buffer, when it replays a packet with potential malicious data that could contain a null buffer. Add a check for the condition when actual_length > 0 and transfer_buffer is null. Signed-off-by: Shuah Khan ---

[PATCH] usbip: vudc_tx: fix v_send_ret_submit() vulnerability to null xfer buffer

v_send_ret_submit() handles urb with a null transfer_buffer, when it replays a packet with potential malicious data that could contain a null buffer. Add a check for the condition when actual_length > 0 and transfer_buffer is null. Signed-off-by: Shuah Khan --- drivers/usb/usbip/vudc_tx.c | 11

mmotm 2017-12-22-17-55 uploaded

The mm-of-the-moment snapshot 2017-12-22-17-55 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

mmotm 2017-12-22-17-55 uploaded

The mm-of-the-moment snapshot 2017-12-22-17-55 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

Re: [PATCH 04/17] mm: pass the vmem_altmap to arch_add_memory and __add_pages

On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig wrote: > We can just pass this on instead of having to do a radix tree lookup > without proper locking 2 levels into the callchain. > > Signed-off-by: Christoph Hellwig [..] > diff --git a/arch/x86/mm/init_64.c

Re: [PATCH 04/17] mm: pass the vmem_altmap to arch_add_memory and __add_pages

On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig wrote: > We can just pass this on instead of having to do a radix tree lookup > without proper locking 2 levels into the callchain. > > Signed-off-by: Christoph Hellwig [..] > diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c > index

Re: [PATCH v2 1/3] phy: core: Move runtime PM reference counting to the parent device

On Sat, Dec 23, 2017 at 2:35 AM, Rafael J. Wysocki wrote: > On Thu, Dec 21, 2017 at 11:50 AM, Ulf Hansson wrote: >> On 21 December 2017 at 02:39, Rafael J. Wysocki wrote: >>> On Wed, Dec 20, 2017 at 3:09 PM, Ulf Hansson

Re: [PATCH v2 1/3] phy: core: Move runtime PM reference counting to the parent device

On Sat, Dec 23, 2017 at 2:35 AM, Rafael J. Wysocki wrote: > On Thu, Dec 21, 2017 at 11:50 AM, Ulf Hansson wrote: >> On 21 December 2017 at 02:39, Rafael J. Wysocki wrote: >>> On Wed, Dec 20, 2017 at 3:09 PM, Ulf Hansson wrote: The runtime PM deployment in the phy core is deployed using

Re: [PATCH 04/17] mm: pass the vmem_altmap to arch_add_memory and __add_pages

On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig wrote: > We can just pass this on instead of having to do a radix tree lookup > without proper locking 2 levels into the callchain. > > Signed-off-by: Christoph Hellwig [..] > diff --git a/kernel/memremap.c

Re: [PATCH 04/17] mm: pass the vmem_altmap to arch_add_memory and __add_pages

On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig wrote: > We can just pass this on instead of having to do a radix tree lookup > without proper locking 2 levels into the callchain. > > Signed-off-by: Christoph Hellwig [..] > diff --git a/kernel/memremap.c b/kernel/memremap.c > index

Re: platform/x86/thinkpad_acpi: Adjustments for four function implementations

On Tue, 19 Dec 2017, SF Markus Elfring wrote: > >> Delete an error message for a failed memory allocation in three functions > > > > This one is questionable since it prints error messages at ->init() stage. > > I would rather not touch this. > > Do you find the Linux allocation failure report

Re: platform/x86/thinkpad_acpi: Adjustments for four function implementations

On Tue, 19 Dec 2017, SF Markus Elfring wrote: > >> Delete an error message for a failed memory allocation in three functions > > > > This one is questionable since it prints error messages at ->init() stage. > > I would rather not touch this. > > Do you find the Linux allocation failure report

Re: [PATCH 0/2] platform/x86/thinkpad_acpi: Adjustments for four function implementations

On Tue, 19 Dec 2017, Andy Shevchenko wrote: > On Mon, Dec 18, 2017 at 11:26 PM, SF Markus Elfring > wrote: > > From: Markus Elfring > > Date: Mon, 18 Dec 2017 22:23:45 +0100 > > > > Two update suggestions were taken into account > >

Re: [PATCH 0/2] platform/x86/thinkpad_acpi: Adjustments for four function implementations

On Tue, 19 Dec 2017, Andy Shevchenko wrote: > On Mon, Dec 18, 2017 at 11:26 PM, SF Markus Elfring > wrote: > > From: Markus Elfring > > Date: Mon, 18 Dec 2017 22:23:45 +0100 > > > > Two update suggestions were taken into account > > from static source code analysis. > > > > Markus Elfring (2): >

Re: [PATCH -V4 -mm] mm, swap: Fix race between swapoff and some swap operations

On Fri, Dec 22, 2017 at 10:14:43PM +0800, Huang, Ying wrote: > Minchan Kim writes: > > > On Thu, Dec 21, 2017 at 03:48:56PM +0800, Huang, Ying wrote: > >> Minchan Kim writes: > >> > >> > On Wed, Dec 20, 2017 at 09:26:32AM +0800, Huang, Ying wrote: > >>

Re: [PATCH -V4 -mm] mm, swap: Fix race between swapoff and some swap operations

On Fri, Dec 22, 2017 at 10:14:43PM +0800, Huang, Ying wrote: > Minchan Kim writes: > > > On Thu, Dec 21, 2017 at 03:48:56PM +0800, Huang, Ying wrote: > >> Minchan Kim writes: > >> > >> > On Wed, Dec 20, 2017 at 09:26:32AM +0800, Huang, Ying wrote: > >> >> From: Huang Ying > >> >> > >> >>

RE: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop

> From: Alexandru Chirvasitu [mailto:achirva...@gmail.com] > Sent: Friday, December 22, 2017 14:29 > > The output of that precise command run just now on a freshly-compiled > copy of that commit is attached. > > On Fri, Dec 22, 2017 at 09:31:28PM +, Dexuan Cui wrote: > > > From: Alexandru

Re: [PATCH v2 1/3] phy: core: Move runtime PM reference counting to the parent device

On Thu, Dec 21, 2017 at 11:50 AM, Ulf Hansson wrote: > On 21 December 2017 at 02:39, Rafael J. Wysocki wrote: >> On Wed, Dec 20, 2017 at 3:09 PM, Ulf Hansson wrote: >>> The runtime PM deployment in the phy core is deployed using

  1   2   3   4   5   6   7   8   9   10   >