Now that thread_info is similar to task_struct, its address is in r2
so CURRENT_THREAD_INFO() macro is useless. This patch removes it.
At the same time, as the 'cpu' field is not anymore in thread_info,
this patch renames it to TASK_CPU.
Signed-off-by: Christophe Leroy
---
thread_info is not anymore in the stack, so the entire stack
can now be used.
There is also no risk anymore of corrupting task_cpu(p) with a
stack overflow so the patch removes the test.
When doing this, an explicit test for NULL stack pointer is
needed in validate_sp() as it is not anymore
Since only the virtual address of allocated blocks is used,
lets use functions returning directly virtual address.
Those functions have the advantage of also zeroing the block.
Suggested-by: Mike Rapoport
Acked-by: Mike Rapoport
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/irq.c
Hi Mimi,
On Fri, 2019-01-11 at 10:40 -0500, Mimi Zohar wrote:
> Hi Michael,
>
> On Sun, 2018-11-11 at 19:50 +0100, Michael Niewöhner wrote:
>
> > Well, there are at least two implementations I know of:
> > For my Lenovo X260 I can choose between Infineon TPM 1.2 or Intel PTT TPM
> > 2.0
> >
On Fri, Jan 11, 2019 at 03:53:58PM -0500, Sebastien Bourdelin wrote:
> This commit allow the driver to work with device-tree.
>
> Signed-off-by: Sebastien Bourdelin
> ---
I get the following compilation failure:
Below I have `allyesconfig` except 'BME680' configure as [M]
in case you wish to
Hi Ted,
I'm still regularly using a Linux rev 0.0 ext2 filesystem as a ramdisk
on m68k, containing mid-90's binaries, from right after the a.out-to-ELF
transition, so I notice if someone breaks old syscall support.
Recently I wanted to change /dev/console on that ramdisk from a symlink
to
On Fri, Jan 11, 2019 at 1:37 AM Guenter Roeck wrote:
> On Wed, Jan 02, 2019 at 09:07:25PM +0530, Firoz Khan wrote:
> > Unified system call table generation script must be run to
> > generate unistd_32.h and syscall_table.h files. This patch
> > will have changes which will invokes the script.
> >
On Sat, Jan 12, 2019 at 12:09:14PM +1100, Balbir Singh wrote:
> Could you please define interesting frame on top a bit more? Usually
> the topmost return address is in LR
There is no reliable way (other than DWARF unwind info) to find out where
the value of LR at function entry currently lives
In the linux kernel MAINTAINERS file, largely
"xen-de...@lists.xenproject.org (moderated for non-subscribers)"
is used to refer to the xen-devel mailing list.
The DRM DRIVERS FOR XEN section entry mentions
xen-de...@lists.xen.org instead, but that is just the same
mailing list as the mailing
Since this is going to be used on more SoCs than just i.MX8MQ, make
the dependency here more generic by using ARCH_MXC instead.
Also remove the SOC_IMX7D since it is also included by the ARCH_MXC.
Signed-off-by: Abel Vesa
Reviewed-by: Dong Aisheng
---
Changes since v2:
* fixed the commit
* Lukas Bulwahn wrote:
> The PREEMPTIBLE KERNEL section entry seems quite outdated:
>
> Robert Love is not actively maintaining the file anymore, nor a recorded
> contributor to the files in the PREEMPTIBLE KERNEL section for the last
> few years.
>
> The mailing list
HI Peter, Oleg,
as per flag and state this seems to be possible only from below code:
XXX: 0 1 0x40844c
PF_NOFREEZE
PF_RANDOMIZE
PF_SIGNALED
PF_FORKNOEXEC
PF_EXITING
PF_EXITPIDONE
above state shows do_exit runs properely and if somehow after parked
stated , TASK_WAKEKILL got set and
* Linus Torvalds wrote:
> On Thu, Jan 10, 2019 at 11:46 PM Ingo Molnar wrote:
> >
> > A single fix that adds an annotation to resolve a kmemleak false
> > positive.
>
> This one is apparently obviated by commit 80424b02d42b ("efi: Reduce
> the amount of memblock reservations for persistent
* Linus Torvalds wrote:
> On Fri, Jan 11, 2019 at 6:22 AM Ard Biesheuvel
> wrote:
> >
> > I was hoping we could merge this patch (so we can backport it), but
> > resolve the conflict by dropping the kmemleak_ignore() again [..]
>
> Well, we'd drop the new #include line also, since it would
Commit-ID: 927185c124d62a9a4d35878d7f6d432a166b74e3
Gitweb: https://git.kernel.org/tip/927185c124d62a9a4d35878d7f6d432a166b74e3
Author: George Rimar
AuthorDate: Fri, 11 Jan 2019 12:10:12 -0800
Committer: Borislav Petkov
CommitDate: Sat, 12 Jan 2019 00:11:39 +0100
x86/build: Specify
On Sat, Jan 12, 2019 at 3:47 AM William Breathitt Gray
wrote:
>
> This macro iterates for each 8-bit group of bits (clump) with set bits,
> within a bitmap memory region. For each iteration, "start" is set to the
> bit offset of the found clump, while the respective clump value is
> stored to the
On Fri, 11 Jan 2019 at 20:13, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.20.2 release.
> There are 65 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.
>
>
On Fri, 11 Jan 2019 at 20:06, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.19.15 release.
> There are 148 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.
>
>
On Fri, 11 Jan 2019 at 20:01, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.14.93 release.
> There are 105 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.
>
>
From: Guo Ren
max_low_pfn should be pfn_size not byte_size.
Signed-off-by: Guo Ren
Signed-off-by: Mao Han
Cc: Palmer Dabbelt
Cc: Albert Ou
---
arch/riscv/kernel/setup.c | 2 +-
arch/riscv/mm/init.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git
Dne sobota, 12. januar 2019 ob 02:56:11 CET je Chen-Yu Tsai napisal(a):
> On Sat, Jan 12, 2019 at 1:30 AM Jernej Skrabec
wrote:
> > A64 IR is compatible with A13, so add A64 compatible with A13 as a
> > fallback.
>
> We ask people to add the SoC-specific compatible as a contigency,
> in case
On Fri, Jan 11, 2019 at 03:10:04PM -0500, Nicolas Pitre wrote:
> On Fri, 11 Jan 2019, Greg Kroah-Hartman wrote:
>
> > On Fri, Jan 11, 2019 at 01:33:09PM -0500, Nicolas Pitre wrote:
> > > I use Linux with the help of a braille display and the brltty daemon. It
> > > turns out that the latest
On Fri, 11 Jan 2019 at 19:58, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.9.150 release.
> There are 63 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.
>
>
On Fri, 11 Jan 2019 at 19:46, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.4.170 release.
> There are 88 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.
>
>
On Fri, Jan 11, 2019 at 10:02:57AM -0800, Nick Desaulniers wrote:
> On Fri, Jan 11, 2019 at 6:34 AM Greg Kroah-Hartman
> wrote:
> >
> > 4.14-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Ard Biesheuvel
> >
> > commit
On Fri, Jan 11, 2019 at 02:35:25PM -0700, shuah wrote:
> On 1/11/19 7:14 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.20.2 release.
> > There are 65 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with
201 - 226 of 226 matches
Mail list logo
