Hi Daniel,
First of all, thank you for all your work on this. I see that Mauro merged
this v10, and after testing I posted a patch for the Kconfig, since that
seems to be wrong.
I have some more questions below, my apologies if that's been asked before.
On 21/08/2020 14:58, Daniel W. S. Almeida
We found a set but not used variable 'ring_cons' in mlx4_en_xmit(), it will
cause a warning when build the kernel. And after checking the commit record
of this function, we found that it was introduced by a previous patch.
So, We delete this redundant assignment code.
Fixes: 488a9b48e398 ("net/ml
On Fri, 11 Sep 2020 at 18:24, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.4.236 release.
> There are 62 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Res
On Fri, 11 Sep 2020 at 18:27, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.9.236 release.
> There are 71 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Res
Hello,
syzbot found the following issue on:
HEAD commit:3b3ea602 x86: add failure injection to get/put/clear_user
git tree: https://github.com/google/kmsan.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=177d733590
kernel config: https://syzkaller.appspot.com/x
Hello,
syzbot found the following issue on:
HEAD commit:3b3ea602 x86: add failure injection to get/put/clear_user
git tree: https://github.com/google/kmsan.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=1357bd3e90
kernel config: https://syzkaller.appspot.com/x
On Sat, Sep 12, 2020 at 10:03:23AM +1000, James Morris wrote:
> On Thu, 10 Sep 2020, Kees Cook wrote:
>
> > [kees: re-sending this series on behalf of John Wood
> > also visible at https://github.com/johwood/linux fbfam]
> >
> > From: John Wood
>
> Why are you resending this? The author of th
On 27/08/20 18:27, Maxim Levitsky wrote:
> However in nested_svm_vmexit we were first were setting GIF to false,
> but then we overwrite this with value from the hsave area.
Do you mean we are overwriting the resulting intercepts with values from
the hsave area? If so, I can rewrite the commit me
On Fri, Sep 11, 2020 at 04:48:06PM +0200, John Wood wrote:
> In other words, a late reply to this serie comments is not a lack of
> interest. Moreover, I think it would be better that I try to understand and
> to implement your ideas before anything else.
Understood! :)
> My original patch serie
Christoph Hellwig writes:
> On Sat, Sep 12, 2020 at 03:05:49AM -0400, Gabriel Krisman Bertazi wrote:
>> When allocating user memory space for a compat system call, don't
>> consider whether the originating code is IA32 or X32, just allocate from
>> a safe region for both, beyond the redzone. Thi
Hi Alexandre,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on linus/master v5.9-rc4 next-20200911]
[cannot apply to remoteproc/for-next rpmsg/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And
On Fri, 11 Sep 2020 at 18:29, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.14.198 release.
> There are 12 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Re
On Fri, 11 Sep 2020 at 18:31, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.19.145 release.
> There are 8 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Res
On Tue, Sep 08, 2020 at 11:36:23PM +0200, Arnd Bergmann wrote:
> There have been several attempts to fix serious problems
> in the compat handling in megasas_mgmt_compat_ioctl_fw(),
> and it also uses the compat_alloc_user_space() function.
I just looked into this a few weeks ago but didn't get th
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below and has been
hand modified to replace GFP_ with a correct flag.
It has been compile tested.
When memory is allocated in 'tlan_init()' GFP_KERNEL can be used because
it is o
On 11-09-2020 15:20, Dmitry Vyukov wrote:
> On Sat, Aug 8, 2020 at 8:56 AM syzbot
> wrote:
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit:d6efb3ac Merge tag 'tty-5.9-rc1' of git://git.kernel.org/p..
>> git tree: upstream
>> console output: https://syzkaller.apps
On Fri, 11 Sep 2020 at 18:30, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 5.4.65 release.
> There are 8 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Respo
On Fri, 11 Sep 2020 at 18:30, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 5.8.9 release.
> There are 16 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Respo
On Tue, Sep 08, 2020 at 11:36:22PM +0200, Arnd Bergmann wrote:
> It sounds unwise to let user space pass an unchecked 32-bit
> offset into a kernel structure in an ioctl. This is an unsigned
> variable, so checking the upper bound for the size of the structure
> it points into is sufficient to avoi
于2020年9月11日周五 下午11:55写道：
>
> On Wed, Sep 09, 2020 at 05:09:31PM +0800, qianjun.ker...@gmail.com wrote:
> > From: jun qian
> >
> > When get the pending softirqs, it need to process all the pending
> > softirqs in the while loop. If the processing time of each pending
> > softirq is need more than
On Tue, Sep 08, 2020 at 11:36:21PM +0200, Arnd Bergmann wrote:
> @@ -243,8 +244,23 @@ static int next_getadapter_fib(struct aac_dev * dev,
> void __user *arg)
> struct list_head * entry;
> unsigned long flags;
>
> - if(copy_from_user((void *)&f, arg, sizeof(struct fib_ioctl)))
>
On Sat, Sep 12, 2020 at 03:05:49AM -0400, Gabriel Krisman Bertazi wrote:
> When allocating user memory space for a compat system call, don't
> consider whether the originating code is IA32 or X32, just allocate from
> a safe region for both, beyond the redzone. This should be safe for
> IA32, and
In preparation to remove TIF_IA32, stop using it in oprofile code.
Signed-off-by: Gabriel Krisman Bertazi
---
arch/x86/oprofile/backtrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/oprofile/backtrace.c b/arch/x86/oprofile/backtrace.c
index a2488b6e27d6..1d8391
Since TIF_X32 is going away, avoid using it to find the ELF type when
choosing which additional pages to set up.
According to SysV AMD64 ABI Draft, an AMD64 ELF object using ILP32 must
have ELFCLASS32 with (E_MACHINE == EM_X86_64), so use that ELF field to
differentiate a x32 object from a IA32 ob
Since TIF_X32 is going away, avoid using it to find the ELF type on
compat_start_thread
According to SysV AMD64 ABI Draft, an AMD64 ELF object using ILP32 must
have ELFCLASS32 with (E_MACHINE == EM_X86_64), so use that ELF field to
differentiate a x32 object from a IA32 object when executing
start
In preparation to remove TIF_IA32, stop using it in perf events code.
Tested by running perf on 32-bit, 64-bit and x32 applications.
Suggested-by: Andy Lutomirski
Signed-off-by: Gabriel Krisman Bertazi
---
arch/x86/events/core.c | 2 +-
arch/x86/events/intel/ds.c | 2 +-
arch/x86/events/
When allocating user memory space for a compat system call, don't
consider whether the originating code is IA32 or X32, just allocate from
a safe region for both, beyond the redzone. This should be safe for
IA32, and has the benefit of avoiding TIF_IA32, which we want to drop.
Suggested-by: Andy
Since TIF_X32 is going away, avoid using it to find the ELF type on
ARCH_DLINFO.
According to SysV AMD64 ABI Draft, an AMD64 ELF object using ILP32 must
have ELFCLASS32 with (E_MACHINE == EM_X86_64), so use that ELF field to
differentiate a x32 object from a IA32 object when loading ARCH_DLINFO
in
We are running out of TI flags for x86. This patchset removes several
usages of TIF_IA32 and TIF_x32 in preparation to reclaim these flags.
After these cleanups, there is still one more user for both of them,
which I need to take a better look before removing.
Many of the ideas for this patchset
Perfect!
I can confirm it resolves the issue as well, thank you very much.
Have a great day,
Alejandro Sior.
On Fri, 11 Sep 2020 at 07:58, Zhenyu Wang wrote:
>
> On 2020.09.08 20:11:21 +0200, Alejandro Sior wrote:
> > In the function intel_vgpu_reg_rw_edid of kvmgt.c, pos can be equal
> > to NU
301 - 330 of 330 matches
Mail list logo
