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
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 +
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:
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:
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
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
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")
>>
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
>> ---
>>
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
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
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
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
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
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
>> 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
>> 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
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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:
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:
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
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
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
>
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
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
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
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.
>
>
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:
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
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?
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
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
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
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
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
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
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 ==
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 ==
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
---
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 |
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
---
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
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
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
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
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
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
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
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
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
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
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
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
> >
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):
>
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:
> >>
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
> >> >>
> >> >>
> 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
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 - 100 of 1842 matches
Mail list logo