Control-flow Enforcement Technology (CET) introduces these MSRs:
MSR_IA32_U_CET (user-mode CET settings),
MSR_IA32_PL3_SSP (user-mode shadow stack pointer),
MSR_IA32_PL0_SSP (kernel-mode shadow stack pointer),
MSR_IA32_PL1_SSP (Privilege Level 1 shadow stack pointer),
A control-protection fault is triggered when a control-flow transfer
attempt violates Shadow Stack or Indirect Branch Tracking constraints.
For example, the return address for a RET instruction differs from the copy
on the shadow stack; or an indirect JMP instruction, without the NOTRACK
prefix,
Shadow Stack provides protection against function return address
corruption. It is active when the processor supports it, the kernel has
CONFIG_X86_CET enabled, and the application is built for the feature.
This is only implemented for the 64-bit kernel. When it is enabled, legacy
non-Shadow
Explain no_user_shstk/no_user_ibt kernel parameters, and introduce a new
document on Control-flow Enforcement Technology (CET).
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
.../admin-guide/kernel-parameters.txt | 6 +
Documentation/x86/index.rst | 1 +
init_groups is declared in both cred.h and init_task.h, but it is not
actually referenced anywhere outside of cred.c where it is defined. So
make it static and remove the declarations.
Signed-off-by: Rasmus Villemoes
---
include/linux/cred.h | 1 -
include/linux/init_task.h | 1 -
On 3/10/21 6:24 AM, gre...@linuxfoundation.org wrote:
From: Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.261 release.
There are 11 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
On Thu, 11 Mar 2021, Singh, Balbir wrote:
> On 9/3/21 7:28 pm, Michal Hocko wrote:
> > On Tue 09-03-21 09:37:29, Balbir Singh wrote:
> >> On 4/3/21 6:40 pm, Zhou Guanghui wrote:
> > [...]
> >>> -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> >>> /*
> >>> - * Because page_memcg(head) is not set on compound
On Mon, Feb 22, 2021 at 09:17:17AM +0800, Qiuxu Zhuo wrote:
> Function rcec_assoc_rciep() incorrectly used "rciep->devfn" (a single
> byte encoding the device and function number) as the device number to
> check whether the corresponding bit was set in the RCiEPBitmap of the
> RCEC (Root Complex
Hello:
This patch was applied to bpf/bpf-next.git (refs/heads/master):
On Wed, 10 Mar 2021 15:18:34 +0800 you wrote:
> Fix the following coccicheck warning:
>
> ./tools/testing/selftests/bpf/progs/fentry_test.c:67:12-13: WARNING
> comparing pointer to 0.
>
> Reported-by: Abaci Robot
>
Hello:
This patch was applied to bpf/bpf-next.git (refs/heads/master):
On Wed, 10 Mar 2021 14:22:46 +0800 you wrote:
> Fix the following coccicheck warning:
>
> ./tools/testing/selftests/bpf/progs/test_global_func10.c:17:12-13:
> WARNING comparing pointer to 0.
>
> Reported-by: Abaci Robot
>
On 3/10/21 6:24 AM, gre...@linuxfoundation.org wrote:
From: Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.105 release.
There are 24 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
On 3/10/21 6:23 AM, gre...@linuxfoundation.org wrote:
From: Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.11.6 release.
There are 36 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
On 3/10/21 11:29 AM, gre...@linuxfoundation.org wrote:
From: Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.23 release.
There are 47 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
On Wed, Mar 10, 2021 at 04:51:44PM +0100, Greg KH wrote:
> On Wed, Mar 10, 2021 at 04:37:21PM +0100, Fabio Aiuto wrote:
> > fix the following checkpatch warnings:
> >
> > WARNING: Block comments use * on subsequent lines
> > + /*
> > + AMPDU_para [1:0]:Max AMPDU Len => 0:8k , 1:16k,
On Wed, Mar 10, 2021 at 06:58:26PM +0100, David Hildenbrand wrote:
> Thinking again, I guess it might be a good idea to factor out the core
> functions into common code. For the optimization part, it might make sense
> too pass some "state" structure that contains e.g., "unused_pmd_start".
Yeah,
On Wed, Mar 10, 2021 at 10:47 PM Nicolas Pitre wrote:
...
> > With CONFIG_TRIM_UNUSED_KSYMS=y I see a 3x-loops of building .version
> > and folowing steps - got no answer if this is intended.
>
> Yes it is intended. I explained it here:
>
> https://lkml.org/lkml/2021/3/9/1099
>
Ah, cool.
Thanks
Thomas Gleixner writes:
> On Thu, Mar 04 2021 at 21:58, Thomas Gleixner wrote:
>> On Thu, Mar 04 2021 at 13:04, Eric W. Biederman wrote:
>>> Thomas Gleixner writes:
We could of course do the caching unconditionally for all tasks.
>>>
>>> Is there any advantage to only doing this for
On Wed, Mar 10, 2021 at 07:55:35AM -0800, Dave Hansen wrote:
> On 3/10/21 7:11 AM, Jarkko Sakkinen wrote:
> >>> - section = _epc_sections[epc_page->section];
> >>> - spin_lock(>lock);
> >>> - list_add_tail(_page->list, >page_list);
> >>> - section->free_cnt++;
> >>>
On Wed, 10 Mar 2021, Sedat Dilek wrote:
> The best results on size-reduction of vmlinux I got with Clang-CFI on x86-64.
>
> Clang-LTO and Clang-CFI:
> I was able to build with CONFIG_TRIM_UNUSED_KSYMS=y which needs to add
> a whitelist file or add a whitelist to scripts/gen_autoksyms.sh.
> And
On Mon, Dec 21, 2020 at 12:10 PM Peiyong Lin wrote:
>
> Historically there is no common trace event for GPU frequency, in
> downstream Android each different hardware vendor implements their own
> way to expose GPU frequency, for example as a debugfs node. This patch
> standardize it as a common
On Wed, Mar 10, 2021 at 07:49:29AM -0800, Sean Christopherson wrote:
> On Wed, Mar 10, 2021, Jarkko Sakkinen wrote:
> > On Wed, Mar 03, 2021 at 08:56:52AM -0800, Dave Hansen wrote:
> > > On 3/3/21 7:03 AM, Jarkko Sakkinen wrote:
> > > > If sgx_page_cache_init() fails in the middle, a trivial
On Wed, Mar 10, 2021 at 12:12 PM Andrii Nakryiko
wrote:
>
> On Wed, Mar 10, 2021 at 8:59 AM Yonghong Song wrote:
> >
> >
> >
> > On 3/10/21 3:48 AM, Florent Revest wrote:
> > > On Wed, Mar 10, 2021 at 6:16 AM Yonghong Song wrote:
> > >> On 3/9/21 7:43 PM, Yonghong Song wrote:
> > >>> On 3/9/21
This patch introduces a new flag to eventfd, called EFD_ZERO_ON_WAKE.
This change is primarily introduced for use cases which do not care about
the value stored in the eventfd itself. Such existing use cases require an
additional read syscall to clear the count.
This flag provides the following
On Wed, Mar 10, 2021 at 07:44:39AM -0800, Dave Hansen wrote:
> >>> + * node.
> >>> + */
> >>> +static struct sgx_numa_node *sgx_numa_nodes;
> >>> +
> >>> +/*
> >>> + * sgx_free_epc_page() uses this to find out the correct struct
> >>> sgx_numa_node,
> >>> + * to put the page in.
> >>> + */
> >>>
On Wed, Mar 10, 2021 at 10:11:22PM +0100, Michal Hocko wrote:
> On Wed 10-03-21 10:56:08, Mike Kravetz wrote:
> > On 3/10/21 7:19 AM, Michal Hocko wrote:
> > > On Mon 08-03-21 18:28:02, Muchun Song wrote:
> > > [...]
> > >> @@ -1447,7 +1486,7 @@ void free_huge_page(struct page *page)
> > >>
On 10/03/21 6:06 pm, Guenter Roeck wrote:
> On 3/9/21 6:19 PM, Chris Packham wrote:
>> On 9/03/21 9:27 am, Chris Packham wrote:
>>> On 8/03/21 5:59 pm, Guenter Roeck wrote:
Other than that, the only other real idea I have would be to monitor
the i2c bus.
>>> I am in the fortunate
Hi,
On 3/10/21 9:55 PM, Filipe Laíns wrote:
> On Wed, 2021-03-10 at 15:24 -0500, Mark Hounschell wrote:
>>
>> That is correct, I don't have any buttons bound to keyboard events. With
>> the original patch the G4(forward) and G5(Backward) buttons work in a
>> browser. I guess G7, G8, and G9
Hi Christophe,
Thanks for the answers to my questions on v1.
This all looks good to me.
Reviewed-by: Daniel Axtens
Kind regards,
Daniel
> Those two macros have only one user which is unsafe_get_user().
>
> Put everything in one place and remove them.
>
> Signed-off-by: Christophe Leroy
>
On Wed, Mar 10, 2021 at 08:16:24PM +0100, Alejandro Colomar (man-pages) wrote:
> Hi Peter,
>
> Please see a few comments below.
>
> Thanks,
>
> Alex
>
> On 3/4/21 5:31 PM, Peter Xu wrote:
> > Write-protect mode is supported starting from Linux 5.7.
> >
> > Signed-off-by: Peter Xu
> > ---
> >
On 10/03/2021 21.49, Masahiro Yamada wrote:
> On Mon, Mar 1, 2021 at 10:11 AM Nicholas Piggin wrote:
>
> I tested LD_DEAD_CODE_DATA_ELIMINATION for the latest kernel.
>
> I added an unused function, this_func_is_unused(),
> then built the ppc kernel with LD_DEAD_CODE_DATA_ELIMINATION.
>
> It
On 9/3/21 7:28 pm, Michal Hocko wrote:
> On Tue 09-03-21 09:37:29, Balbir Singh wrote:
>> On 4/3/21 6:40 pm, Zhou Guanghui wrote:
> [...]
>>> -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>> /*
>>> - * Because page_memcg(head) is not set on compound tails, set it now.
>>> + * Because page_memcg(head) is
The rtc device node is always or at the very least can possibly be NULL.
Since v5.12-rc1-dontuse/3c9ea42802a1fbf7ef29660ff8c6e526c58114f6 this
will lead to a NULL pointer dereference.
To fix this we fallback to using the parent node which is the i2c client
node as set by
On Wed, Mar 10, 2021 at 1:08 PM Shakeel Butt wrote:
>
> On Wed, Mar 10, 2021 at 10:54 AM Yang Shi wrote:
> >
> > On Wed, Mar 10, 2021 at 10:24 AM Shakeel Butt wrote:
> > >
> > > On Wed, Mar 10, 2021 at 9:46 AM Yang Shi wrote:
> > > >
> > > > The number of deferred objects might get windup to
On Wed, Mar 10, 2021 at 01:38:12PM -0500, Stefan Berger wrote:
>
> On 3/10/21 10:35 AM, Jarkko Sakkinen wrote:
> > On Fri, Mar 05, 2021 at 03:59:47PM -0500, Stefan Berger wrote:
> > > From: Stefan Berger
> > >
> > > Add OIDs for ECDSA with sha224/256/384/512.
> > Nit: SHA224/256/384/512 (sorry
On Wed, Mar 10, 2021 at 9:08 AM Will Deacon wrote:
>
> Hi Claire,
>
> On Tue, Feb 09, 2021 at 02:21:30PM +0800, Claire Chang wrote:
> > Introduce the new compatible string, restricted-dma-pool, for restricted
> > DMA. One can specify the address and length of the restricted DMA memory
> > region
On Wed, Mar 10, 2021 at 08:44:44PM +0800, Jia Zhang wrote:
>
>
> On 2021/3/2 下午9:47, Jarkko Sakkinen wrote:
> > On Mon, Mar 01, 2021 at 09:54:37PM -0800, Andy Lutomirski wrote:
> >> On Mon, Mar 1, 2021 at 9:06 PM Tianjia Zhang
> >> wrote:
> >>>
> >>>
> >>>
> >>> On 3/1/21 5:54 PM, Jarkko
Invoke the MMU notifier's .invalidate_range_end() callbacks even if one
of the .invalidate_range_start() callbacks failed. If there are multiple
notifiers, the notifier that did not fail may have performed actions in
its ...start() that it expects to unwind via ...end(). Per the
mmu_notifier_ops
When parsing the structures in the shared memory, there are values which
come from the remote device. For example, a transfer completion event
will have a pointer to the tre in the relevant channel's transfer ring.
As another example, event ring elements may specify a channel in which
the event
On Mon, 1 Mar 2021, Nicholas Piggin wrote:
> Excerpts from Arnd Bergmann's message of February 27, 2021 7:49 pm:
> > Unlike what Nick expected in his submission, I now think the annotations
> > will be needed for LTO just like they are for --gc-sections.
>
> Yeah I wasn't sure exactly what LTO
These look like good cleanups to me! I reviewed all of the patches,
and tried out the resulting selftest program, it seems to work
correctly. So, for what it's worth:
Reviewed-by: Axel Rasmussen
On Tue, Mar 9, 2021 at 4:45 PM Peter Xu wrote:
>
> Based on v5.12-rc2-mmots-2021-03-08-21-54.
>
>
On Wed, Mar 10, 2021 at 01:11:15PM +, Luis Chamberlain wrote:
> I can try to modify it to include second patch first, as that is
> required. There are two separate bugs here.
I tried this, applying the syfs required changes first and then
applying your idea as a secondary patch ends up like
On Wed, Mar 10, 2021 at 10:08 PM Arnd Bergmann wrote:
>
> On Wed, Mar 10, 2021 at 9:50 PM Masahiro Yamada wrote:
> > On Mon, Mar 1, 2021 at 10:11 AM Nicholas Piggin wrote:
> > > Excerpts from Arnd Bergmann's message of February 27, 2021 7:49 pm:
>
> >
> > masahiro@oscar:~/ref/linux$ echo 'void
Hi all,
In commit
1103e2826a9f ("xen/events: don't unmask an event channel when an eoi is
pending")
Fixes tag
Fixes: 54c9de89895e0a36047 ("xen/events: add a new late EOI evtchn framework")
has these problem(s):
- Subject does not match target commit subject
Just use
git
On Mon, Mar 08, 2021 at 06:55:30PM -0800, Minchan Kim wrote:
> If I understand correctly, bugs you found were related to module
> unloading race while the zram are still working.
No, that is a simplifcation of the issue. The issue consists of
two separate issues:
a) race against module
The pull request you sent on Wed, 10 Mar 2021 20:40:44 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-5.12-3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a74e6a014c9d4d4161061f770c9b4f98372ac778
Thank you!
--
Deet-doot-dot, I am a
On Wed, Mar 10, 2021 at 4:01 AM Alexey Gladkov wrote:
>
>
> +/* 127: arbitrary random number, small enough to assemble well */
> +#define refcount_zero_or_close_to_overflow(ucounts) \
> + ((unsigned int) atomic_read(>count) + 127u <= 127u)
> +
> +struct ucounts *get_ucounts(struct ucounts
When disabling PLL, there is no need to call core_write_mmd_indirect
directly, use the core_write wrapper instead like the rest of the code
in the function does. This change helps with consistency and
readability.
Signed-off-by: Ilya Lipnitskiy
---
drivers/net/dsa/mt7530.c | 5 +
1 file
3f9ef7785a9c ("MIPS: ralink: manage low reset lines") made it so mt7530
actually resets the switch on platforms such as mt7621 (where bit 2 is
the reset line for the switch). That exposed an issue where the switch
would not function properly in TRGMII mode after a reset.
Reconfigure core clock in
In RGMII mode, the REG_GSWCK_EN bit of CORE_TRGMII_GSW_CLK_CG gets
set three times in a row. In TRGMII mode, two times. Simplify the code
and only set it once for both modes.
Signed-off-by: Ilya Lipnitskiy
---
drivers/net/dsa/mt7530.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
On Wed, Mar 10, 2021, Paolo Bonzini wrote:
> On 10/03/21 01:30, Sean Christopherson wrote:
> > diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
> > index 50ef757c5586..f0c99fa04ef2 100644
> > --- a/arch/x86/kvm/mmu/tdp_mmu.c
> > +++ b/arch/x86/kvm/mmu/tdp_mmu.c
> > @@ -323,7
The extra space before tab space has been removed.
Signed-off-by: Shubhankar Kuranagatti
---
net/ipv4/route.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 02d81d79deeb..55f2813a000d 100644
--- a/net/ipv4/route.c
+++
On Wed, Mar 10, 2021 at 6:33 AM Shengjiu Wang wrote:
>
> Hi Rob
>
> On Wed, Mar 10, 2021 at 10:49 AM Rob Herring wrote:
> >
> > On Mon, Mar 08, 2021 at 09:22:27PM +0800, Shengjiu Wang wrote:
> > > fsl_rpmsg cpu dai driver is driver for rpmsg audio, which is mainly used
> >
> > Bindings describe
On Wed 10-03-21 10:56:08, Mike Kravetz wrote:
> On 3/10/21 7:19 AM, Michal Hocko wrote:
> > On Mon 08-03-21 18:28:02, Muchun Song wrote:
> > [...]
> >> @@ -1447,7 +1486,7 @@ void free_huge_page(struct page *page)
> >>/*
> >> * Defer freeing if in non-task context to avoid hugetlb_lock
Add a new get_loaded_rsc_table() operation in order to support
scenarios where the remoteproc core has booted a remote processor
and detaches from it. When re-attaching to the remote processor,
the core needs to know where the resource table has been placed
in memory.
Signed-off-by: Mathieu
Refactor function rproc_cdev_release() to take into account the
current state of the remote processor when choosing the state to
transition to.
Signed-off-by: Mathieu Poirier
---
New for V7:
Keep the behavior of the shutdown operation in rproc_del() intact.
---
This patch introduces the capability to detach a remote processor
that has been attached to by the remoteproc core. For that to happen
a rproc::ops::detach() operation needs to be available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_cdev.c
Add an new detach() operation in order to support scenarios where
the remoteproc core is going away but the remote processor is
kept operating. This could be the case when the system is
rebooted or when the platform driver is removed.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
There is a need to know when a remote processor has been attached
to rather than booted by the remoteproc core. In order to avoid
manipulating two variables, i.e rproc::autonomous and
rproc::state, get rid of the former and simply use the newly
introduced RPROC_ATTACHED state.
Signed-off-by:
Allow a remote processor that was started by another entity to be
switched off by the remoteproc core. For that to happen a
rproc::ops::stop() operation needs to be available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_cdev.c | 3 ++-
The panic handler operation of registered remote processors
should also be called when remote processors have been
attached to.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 6 +-
1 file changed, 5
When a remote processor that was attached to is stopped, special care
must be taken to make sure the shutdown process is similar to what
it would be had it been started by the remoteproc core.
This patch takes care of that by making a copy of the resource
table currently used by the remote
This patch takes into account scenarios where a remote processor
has been attached to when receiving a "start" command from sysfs.
As with the case with the running state, the command can't be
carried out if the remote processor is already in operation.
Signed-off-by: Mathieu Poirier
Whether started at probe() time or thereafter from the command
line, a remote processor needs to be shut down before the final
cleanup phases can happen. Otherwise the system may be left in
an unpredictable state where the remote processor is expecting
the remoteproc core to be providing services
Introduce function __rproc_detach() to perform the same kind of
operation as rproc_stop(), but instead of switching off the
remote processor using rproc->ops->stop(), it uses
rproc->ops->detach(). That way it is possible for the core
to release the resources associated with a remote processor
If it is possible to detach the remote processor, keep an untouched
copy of the resource table. That way we can start from the same
resource table without having to worry about original values or what
elements the startup code has changed when re-attaching to the remote
processor.
Signed-off-by:
Introduce function rproc_detach() to enable the remoteproc
core to release the resources associated with a remote processor
without stopping its operation.
Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 58 +++-
From: Arnaud POULIQUEN
Some actions such as memory resources reallocation are needed when
trying to reattach a co-processor. Use the prepare() operation for
these actions.
Co-developed-by: Mathieu Poirier
Signed-off-by: Mathieu Poirier
Signed-off-by: Arnaud POULIQUEN
---
Move the setting of the resource table installed by an external
entity to rproc_ops::get_loaded_rsc_table(). This is to support
scenarios where a remote processor has been attached to but is
detached at a later stage. To re-attach the remote processor,
the address of the resource table needs to
Add a new RPROC_ATTACHED state to take into account scenarios
where the remoteproc core needs to attach to a remote processor
that is booted by another entity.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_sysfs.c | 1 +
Rename function rproc_actuate() to rproc_attach(). That way it is
easy to understand that it does the opposite of rproc_detach().
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 8
1 file changed, 4
This set provides support for the remoteproc core to release resources
associated with a remote processor without having to switch it off. That
way a platform driver can be removed or the application processor power
cycled while the remote processor is still operating.
The main difference in this
On Wed, Mar 10, 2021 at 10:54 AM Yang Shi wrote:
>
> On Wed, Mar 10, 2021 at 10:24 AM Shakeel Butt wrote:
> >
> > On Wed, Mar 10, 2021 at 9:46 AM Yang Shi wrote:
> > >
> > > The number of deferred objects might get windup to an absurd number, and
> > > it
> > > results in clamp of slab
On Wed, Mar 10, 2021 at 9:50 PM Masahiro Yamada wrote:
> On Mon, Mar 1, 2021 at 10:11 AM Nicholas Piggin wrote:
> > Excerpts from Arnd Bergmann's message of February 27, 2021 7:49 pm:
>
> masahiro@oscar:~/ref/linux$ echo 'void this_func_is_unused(void) {}'
> >> kernel/cpu.c
>
Drop $nodename restriction as now mtd partition can also be used as
nvmem provider.
Signed-off-by: Ansuel Smith
---
Documentation/devicetree/bindings/nvmem/nvmem.yaml | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
Hi Eric,
Can you check this patch? I rolled your changes into it.
David
Partitions that contains the nvmem-cells compatible will register
their direct subonodes as nvmem cells and the node will be treated as a
nvmem provider.
Signed-off-by: Ansuel Smith
---
drivers/mtd/mtdcore.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Document nvmem-cells compatible used to treat mtd partitions as a
nvmem provider.
Signed-off-by: Ansuel Smith
---
.../bindings/mtd/partitions/nvmem-cells.yaml | 96 +++
1 file changed, 96 insertions(+)
create mode 100644
Hi Taniya,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on clk/clk-next]
[also build test WARNING on v5.12-rc2 next-20210310]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base
On 3/10/21 1:52 PM, Nathan Chancellor wrote:
> On Wed, Mar 10, 2021 at 01:40:25PM -0700, Jens Axboe wrote:
>> On 3/10/21 1:33 PM, Nathan Chancellor wrote:
>>> On Wed, Mar 10, 2021 at 01:21:52PM -0700, Jens Axboe wrote:
On 3/10/21 11:23 AM, Nathan Chancellor wrote:
> Hi Jens,
>
>
On Wed, Mar 10, 2021 at 01:52:04PM +0100, Andrey Konovalov wrote:
> On Tue, Mar 9, 2021 at 10:43 PM Kees Cook wrote:
> >
> > Right now, the state of CONFIG_INIT_ON_ALLOC_DEFAULT_ON (and
> > ...ON_FREE...) did not change the assembly ordering of the static branch
> > tests. Use the new jump_label
On Wed, Mar 10, 2021 at 8:32 PM Bjorn Helgaas wrote:
>
> On Mon, Mar 08, 2021 at 04:24:46PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > Compile-testing this driver without ECAM support results in a link
> > failure:
> >
> > ld.lld: error: undefined symbol: pci_ecam_map_bus
> >
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Wed, 10 Mar 2021 11:06:46 +0800 you wrote:
> rewriteing -> rewriting
>
> Signed-off-by: Wang Qing
> ---
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Tue, 9 Mar 2021 17:51:35 -0800 you wrote:
> From: Menglong Dong
>
> The bit mask for MSG_* seems a little confused here. Replace it
> with BIT() to make it clear to understand.
>
> Signed-off-by: Menglong Dong
>
>
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Wed, 10 Mar 2021 11:06:03 +0800 you wrote:
> wheter -> whether
>
> Signed-off-by: Wang Qing
> ---
> drivers/isdn/mISDN/l1oip_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Here is the summary with
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Wed, 10 Mar 2021 16:28:58 +0800 you wrote:
> From: Yunsheng Lin
>
> gro list uses skb_shinfo(skb)->frag_list to link two skb together,
> and NAPI_GRO_CB(p)->last->next is used when there are more skb,
> see
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Thu, 11 Mar 2021 02:03:14 +0530 you wrote:
> The series of space has been replaced by tab space
> wherever required.
>
> Signed-off-by: Shubhankar Kuranagatti
> ---
> net/ipv6/route.c | 26 +-
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Wed, 10 Mar 2021 11:23:43 +0800 you wrote:
> There is no need to assign the msg->msg_name to sin or sin6,
> because there is DECLARE_SOCKADDR statement.
>
> Signed-off-by: Yejune Deng
> ---
> net/rds/recv.c | 4
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Wed, 10 Mar 2021 16:53:04 +0800 you wrote:
> Fix the following coccicheck warning:
> ./drivers/isdn/mISDN/dsp_core.c:956:6-9: Unneeded variable: "err".
> Return "0" on line 1001
>
> Reported-by: Abaci Robot
>
On Wed, Mar 10, 2021 at 02:51:24PM -0500, Jes Sorensen wrote:
> On 3/10/21 2:45 PM, Kees Cook wrote:
> > On Wed, Mar 10, 2021 at 02:31:57PM -0500, Jes Sorensen wrote:
> >> On 3/10/21 2:14 PM, Kees Cook wrote:
> >>> Hm, this conversation looks like a miscommunication, mainly? I see
> >>> Gustavo,
Currently only the tracing thread can call ptrace on a given pid. This
patch allows any task in the tracing thread's thread group to also call
ptrace. This makes it easier and more performant to write multi-threaded
applications that use ptrace.
In our ptrace-based simulator, we currently
On 3/10/2021 10:17 AM, Mickaël Salaün wrote:
> On 10/03/2021 18:22, Casey Schaufler wrote:
>> On 3/10/2021 8:09 AM, Mickaël Salaün wrote:
>>> Hi,
>>>
>>> The chroot system call is currently limited to be used by processes with
>>> the CAP_SYS_CHROOT capability. This protects against malicious
>>>
On 3/10/21 12:41 PM, Jeffrey Hugo wrote:
After the device has signaled the end of reset by clearing the reset bit,
it will automatically reinit MHI and the internal device structures. Once
That is done, the device will signal it has entered the ready state.
Signaling the ready state
On Wed, 10 Mar 2021 10:01:04 -0800 Minchan Kim wrote:
> Currently, debugging CMA allocation failures is quite limited.
> The most commong source of these failures seems to be page
> migration which doesn't provide any useful information on the
> reason of the failure by itself.
On Wed, 2021-03-10 at 15:24 -0500, Mark Hounschell wrote:
>
> That is correct, I don't have any buttons bound to keyboard events. With
> the original patch the G4(forward) and G5(Backward) buttons work in a
> browser. I guess G7, G8, and G9 buttons are programmable to keyboard events?
>
>
This patch extends MRP support for Ocelot. It allows to have multiple
rings and when the node has the MRC role it forwards MRP Test frames in
HW. For MRM there is no change.
Signed-off-by: Horatiu Vultur
---
drivers/net/ethernet/mscc/ocelot.c | 6 -
drivers/net/ethernet/mscc/ocelot_mrp.c
On Wed, Mar 10, 2021 at 01:40:25PM -0700, Jens Axboe wrote:
> On 3/10/21 1:33 PM, Nathan Chancellor wrote:
> > On Wed, Mar 10, 2021 at 01:21:52PM -0700, Jens Axboe wrote:
> >> On 3/10/21 11:23 AM, Nathan Chancellor wrote:
> >>> Hi Jens,
> >>>
> >>> There is a new clang warning added in the
On 03/09, Chao Yu wrote:
> On 2021/3/9 8:01, Jaegeuk Kim wrote:
> > On 03/05, Chao Yu wrote:
> > > On 2021/3/5 4:20, Jaegeuk Kim wrote:
> > > > On 02/27, Jaegeuk Kim wrote:
> > > > > On 02/04, Chao Yu wrote:
> > > > > > Jaegeuk,
> > > > > >
> > > > > > On 2021/2/2 16:00, Chao Yu wrote:
> > > > >
On Wed, Mar 10, 2021 at 12:10 PM Álvaro Fernández Rojas
wrote:
>
> Hi Rob,
>
> > El 10 mar 2021, a las 19:45, Rob Herring escribió:
> >
> > On Wed, Mar 10, 2021 at 11:03 AM Álvaro Fernández Rojas
> > wrote:
> >>
> >> Hi Rob,
> >>
> >>> El 10 mar 2021, a las 18:45, Rob Herring escribió:
> >>>
>
On Mon, Mar 1, 2021 at 10:11 AM Nicholas Piggin wrote:
>
> Excerpts from Arnd Bergmann's message of February 27, 2021 7:49 pm:
> > On Fri, Feb 26, 2021 at 10:13 PM 'Fangrui Song' via Clang Built Linux
> > wrote:
> >>
> >> For folks who are interested in --gc-sections on metadata sections,
> >> I
We cannot process a power_down if the power state is DISABLED. There is
no valid mhi_ctxt in that case, so attepting to process the power_down
will likely result in a null pointer dereference. If the power state is
DISABLED, there is nothing to do anyways, so just bail early.
Signed-off-by:
501 - 600 of 1854 matches
Mail list logo
