On Thu, Oct 15, 2020 at 10:01:54AM -0500, Christopher M. Riedl wrote:
> Functions called between user_*_access_begin() and user_*_access_end()
> should be either inlined or marked 'notrace' to prevent leaving
> userspace access exposed. Mark any such functions relevant to signal
> handling so that
On Thu, Oct 15, 2020 at 10:01:52AM -0500, Christopher M. Riedl wrote:
> Implement raw_copy_from_user_allowed() which assumes that userspace read
> access is open. Use this new function to implement raw_copy_from_user().
> Finally, wrap the new function to follow the usual "unsafe_" convention
> of
>
> Fixes: 75eaa498c99e (“usb: gadget: Correct NULL pointer checking in fsl
> gadget”)
> Signed-off-by: Ran Wang
> ---
> drivers/usb/gadget/udc/fsl_udc_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c
> b/drivers/usb/gadget/
fsl_ep_fifo_status() should return error if _ep->desc is null.
Fixes: 75eaa498c99e (“usb: gadget: Correct NULL pointer checking in fsl gadget”)
Signed-off-by: Ran Wang
---
drivers/usb/gadget/udc/fsl_udc_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget
Hi Michal,
On 10/15/20 8:16 PM, Michal Suchánek wrote:
Hello,
On Thu, Feb 06, 2020 at 12:25:18AM -0300, Leonardo Bras wrote:
On Thu, 2020-02-06 at 00:08 -0300, Leonardo Bras wrote:
gup_pgd_range(addr, end, gup_flags, pages, &nr);
- local_irq_enable();
+
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Linus,
Please pull powerpc updates for 5.10.
Just two minor conflicts I'm aware of. The only slight subtlety is the conflict
in kasan_init() where "int ret" needs to move out of the for_each_mem_range()
and up to the function scope.
Notable out
Hi all,
On Tue, 6 Oct 2020 18:35:06 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the char-misc tree got a conflict in:
>
> drivers/misc/ocxl/Kconfig
>
> between commit:
>
> dde6f18a8779 ("ocxl: Don't return trigger page when allocating an
> interrupt")
>
> from the pow
On Thu, Oct 15, 2020 at 01:15:37PM +0300, Felipe Balbi wrote:
> Serge Semin writes:
>
> > On Wed, Oct 14, 2020 at 05:09:37PM +0300, Felipe Balbi wrote:
> >>
> >> Hi Serge,
> >>
> >> Serge Semin writes:
> >> > In accordance with the DWC USB3 bindings the corresponding node name is
> >> > suppos
https://bugzilla.kernel.org/show_bug.cgi?id=195755
Marco Descher (ma...@descher.at) changed:
What|Removed |Added
CC||ma...@descher.at
--- C
On 10/14/20 3:13 AM, Serge Semin wrote:
> For some reason the "brcm,xhci-brcm-v2" compatible string has been missing
> in the original bindings file. Add it to the Generic xHCI Controllers DT
> schema since the controller driver expects it to be supported.
>
> Signed-off-by: Serge Semin
Acked-by
On 10/14/20 3:14 AM, Serge Semin wrote:
> In accordance with the Generic EHCI/OHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Let's fix the DTS files, whic
Functions called between user_*_access_begin() and user_*_access_end()
should be either inlined or marked 'notrace' to prevent leaving
userspace access exposed. Mark any such functions relevant to signal
handling so that subsequent patches can call them inside uaccess blocks.
Signed-off-by: Christ
Implement raw_copy_from_user_allowed() which assumes that userspace read
access is open. Use this new function to implement raw_copy_from_user().
Finally, wrap the new function to follow the usual "unsafe_" convention
of taking a label argument. The new raw_copy_from_user_allowed() calls
__copy_tof
From: Daniel Axtens
Add uaccess blocks and use the 'unsafe' versions of functions doing user
access where possible to reduce the number of times uaccess has to be
opened/closed.
There is no 'unsafe' version of copy_siginfo_to_user, so move it
slightly to allow for a "longer" uaccess block.
Sign
From: Daniel Axtens
Add uaccess blocks and use the 'unsafe' versions of functions doing user
access where possible to reduce the number of times uaccess has to be
opened/closed.
Signed-off-by: Daniel Axtens
Signed-off-by: Christopher M. Riedl
---
arch/powerpc/kernel/signal_64.c | 23 +
Reuse the "safe" implementation from signal.c except for calling
unsafe_copy_from_user() to copy into a local buffer. Unlike the
unsafe_copy_{vsx,fpr}_to_user() functions the "copy from" functions
cannot use unsafe_get_user() directly to bypass the local buffer since
doing so significantly reduces
Previously setup_sigcontext() performed a costly KUAP switch on every
uaccess operation. These repeated uaccess switches cause a significant
drop in signal handling performance.
Rewrite setup_sigcontext() to assume that a userspace write access window
is open. Replace all uaccess functions with th
Previously restore_sigcontext() performed a costly KUAP switch on every
uaccess operation. These repeated uaccess switches cause a significant
drop in signal handling performance.
Rewrite restore_sigcontext() to assume that a userspace read access
window is open. Replace all uaccess functions with
From: Daniel Axtens
Previously setup_trampoline() performed a costly KUAP switch on every
uaccess operation. These repeated uaccess switches cause a significant
drop in signal handling performance.
Rewrite setup_trampoline() to assume that a userspace write access
window is open. Replace all uac
As reported by Anton, there is a large penalty to signal handling
performance on radix systems using KUAP. The signal handling code
performs many user access operations, each of which needs to switch the
KUAP permissions bit to open and then close user access. This involves a
costly 'mtspr' operati
On 10/15/20 3:05 AM, Catalin Marinas wrote:
> On Wed, Oct 14, 2020 at 03:21:16PM -0600, Khalid Aziz wrote:
>> What FreeBSD does seems like a reasonable thing to do. Any way first
>> thing to do is to update sparc to use arch_validate_flags() and update
>> sparc_validate_prot() to not peek into vma
Hello,
On Thu, Feb 06, 2020 at 12:25:18AM -0300, Leonardo Bras wrote:
> On Thu, 2020-02-06 at 00:08 -0300, Leonardo Bras wrote:
> > gup_pgd_range(addr, end, gup_flags, pages, &nr);
> > - local_irq_enable();
> > + end_lockless_pgtbl_walk(IRQS_ENABLED);
>
On Thu, Oct 15, 2020 at 08:14:39AM +0200, Krzysztof Kozlowski wrote:
> On Thu, Oct 15, 2020 at 02:51:05AM +0300, Serge Semin wrote:
> > >
> > > > So to speak thanks for suggesting it. I'll try it to validate the
> > > > proposed
> > > > changes.
> > > >
> > > > Two questions:
> > > > 1) Any advis
Le 15/10/2020 à 15:25, Segher Boessenkool a écrit :
Hi!
On Thu, Oct 15, 2020 at 10:52:20AM +, Christophe Leroy wrote:
With gcc9 I get:
With gcc10 I get:
gcc10 defines multiple versions of csum_partial() which are just
an unconditionnal branch to __csum_partial().
It doesn't i
On Thu, Oct 15, 2020 at 01:15:37PM +0300, Felipe Balbi wrote:
> Serge Semin writes:
>
> > On Wed, Oct 14, 2020 at 05:09:37PM +0300, Felipe Balbi wrote:
> >>
> >> Hi Serge,
> >>
> >> Serge Semin writes:
> >> > In accordance with the DWC USB3 bindings the corresponding node name is
> >> > suppos
Le 15/10/2020 à 15:25, Segher Boessenkool a écrit :
Hi!
On Thu, Oct 15, 2020 at 10:52:20AM +, Christophe Leroy wrote:
With gcc9 I get:
With gcc10 I get:
gcc10 defines multiple versions of csum_partial() which are just
an unconditionnal branch to __csum_partial().
It doesn't i
Hi!
On Thu, Oct 15, 2020 at 10:52:20AM +, Christophe Leroy wrote:
> With gcc9 I get:
> With gcc10 I get:
> gcc10 defines multiple versions of csum_partial() which are just
> an unconditionnal branch to __csum_partial().
It doesn't inline it, yes.
Could you open a GCC PR for this please
On Wed, Oct 14, 2020 at 07:38:50AM -0400, Mimi Zohar wrote:
> On Wed, 2020-10-14 at 17:35 +0800, Chester Lin wrote:
> > Hi Ard & Mimi,
> >
> > On Tue, Oct 13, 2020 at 06:59:21PM +0200, Ard Biesheuvel wrote:
> > > On Tue, 13 Oct 2020 at 18:46, Mimi Zohar wrote:
> > > >
> > > > [Cc'ing linuxppc-dev
ppc-linux-objdump -d vmlinux | grep -e "" -e
"<__csum_partial>"
With gcc9 I get:
c0017ef8 <__csum_partial>:
c00182fc: 4b ff fb fd bl c0017ef8 <__csum_partial>
c0018478: 4b ff fa 80 b c0017ef8 <__csum_partial>
c03e8458:
Serge Semin writes:
> On Wed, Oct 14, 2020 at 05:09:37PM +0300, Felipe Balbi wrote:
>>
>> Hi Serge,
>>
>> Serge Semin writes:
>> > In accordance with the DWC USB3 bindings the corresponding node name is
>> > suppose to comply with Generic USB HCD DT schema, which requires the USB
>>
>
>> DWC3
Hi Serge,
On 10/14/20 12:14 PM, Serge Semin wrote:
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Let's fix the DTS file
On Wed, Oct 14, 2020 at 03:21:16PM -0600, Khalid Aziz wrote:
> On 10/13/20 3:16 AM, Catalin Marinas wrote:
> > On Mon, Oct 12, 2020 at 01:14:50PM -0600, Khalid Aziz wrote:
> >> On 10/12/20 11:22 AM, Catalin Marinas wrote:
> >>> On Mon, Oct 12, 2020 at 11:03:33AM -0600, Khalid Aziz wrote:
> On
32 matches
Mail list logo
