On 7/13/2018 10:50 PM, John Stultz wrote:
On Fri, Jul 13, 2018 at 12:13 AM, Mukesh Ojha wrote:
Hi John,
Thanks for your response
Please find my comments inline.
On 7/11/2018 1:43 AM, John Stultz wrote:
On Fri, Jul 6, 2018 at 6:17 AM, Mukesh Ojha wrote:
Currently, there exists a corner
On Mon, Jul 16, 2018 at 8:08 AM Eric W. Biederman wrote:
>
> The change for global init is it will now die if init is a member of the
> session or init is using this tty as it's controlling tty.
>
> Semantically killing init with SAK is completely appropriate.
No.
Semtnaitcally killing init is
On 07/16/2018 06:10 AM, Baolin Wang wrote:
From: Bjorn Andersson
Some LED controllers have support for autonomously controlling
brightness over time, according to some preprogrammed pattern or
function.
This adds a new optional operator that LED class drivers can implement
if they support
Quoting Taniya Das (2018-05-08 22:56:07)
> Add the RPMh clock driver to control the RPMh managed clock resources on
> some of the Qualcomm Technologies, Inc. SoCs.
>
> Signed-off-by: Taniya Das
> ---
Applied to clk-next
On Fri, Jul 13, 2018 at 12:42:02AM +0300, Tomer Maimon wrote:
> Added device tree binding documentation for Nuvoton BMC
> NPCM750/730/715/705 pinmux and GPIO controller.
>
> Signed-off-by: Tomer Maimon
> ---
> .../bindings/pinctrl/nuvoton,npcm7xx-pinctrl.txt | 216
> +
>
Hello!
This series contains updates to the Linux kernel's formal memory model
in tools/memory-model, along with corresponding changes in documentation
and Linux-kernel code. These patches are ready for inclusion into -tip.
1. Add a litmus test for full multi-copy atomicity.
2. Fix
On Mon, Jul 16, 2018 at 07:43:32PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jul 16, 2018 at 09:41:23AM -0700, Guenter Roeck wrote:
> > On Mon, Jul 16, 2018 at 06:31:36PM +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Jul 16, 2018 at 09:25:38AM -0700, Guenter Roeck wrote:
> > > > On Mon, Jul 16,
Linus Torvalds writes:
> On Mon, Jul 16, 2018 at 7:50 AM Eric W. Biederman
> wrote:
>>
>> In practice since glibc does not make thread id's available I don't
>> expect anyone relies on this behavior. Since no one relies on it we
>> can change it without creating a regression.
>
> Maybe.
>
>
The names on the first line of the litmus tests are arbitrary,
but the convention is that they be the filename without the trailing
".litmus". This commit therefore removes the stray trailing ".litmus"
from ISA2+pooncelock+pooncelock+pombonce.litmus's name.
Reported-by: Andrea Parri
On Sat, Jul 14, 2018 at 11:27:53PM +, Yixun Lan wrote:
> Add new compatible name for Amlogic's Meson-G12A pin controllers,
> add a dt-binding header file which document the detail pin names.
>
> Acked-by: Martin Blumenstingl
> Signed-off-by: Xingyu Chen
> Signed-off-by: Yixun Lan
> ---
>
On 2018-07-13 17:08, Joe Perches wrote:
On Fri, 2018-07-13 at 16:28 -0700, pher...@codeaurora.org wrote:
On 2018-07-13 14:46, Joe Perches wrote:
> On Fri, 2018-07-13 at 14:40 -0700, Prakruthi Deepak Heragu wrote:
> > Commit text is almost always necessary to explain why a change is
> > needed.
On Mon, Jul 16, 2018 at 11:02 AM Eric W. Biederman
wrote:
>
> There are two questions.
> a) Can we use the pid of a thread to find the thread group?
Yes. Just find the thread, and then use p->tgid.
However, that's not what the code used to do. It used to just find the
thread, and then do
This is an attempt to implement Memory ROE discussed by me earlier as a
way to prevent Rootkits. I have already explained in details in this
thread:
https://www.mail-archive.com/kernelnewbies@kernelnewbies.org/msg18826.html
So I think there is no need for saying the exact same thing again.
The
On Mon, Jul 16, 2018 at 9:17 AM, Mukesh Ojha wrote:
> On 7/13/2018 10:50 PM, John Stultz wrote:
>> On Fri, Jul 13, 2018 at 12:13 AM, Mukesh Ojha
>>> On 7/11/2018 1:43 AM, John Stultz wrote:
I worry this upside-down logic is too subtle to be easily reasoned
about, and will just lead to
> Everything below here is is 'bad', which can be an indication that you
> misclassified one of
> the commits above as 'good' when it should have been 'bad'. The most likely
> explanations are that you either typed the 'git bisect good' by accident, or
> that the failure is not 100% reliable, and
On 07/16/2018 12:09 PM, Michal Hocko wrote:
> On Mon 16-07-18 11:16:30, Pavel Tatashin wrote:
>> Moving zero_resv_unavail before memmap_init_zone(), caused a regression on
>> x86-32.
>>
>> The cause is that we access struct pages before they are allocated when
>> CONFIG_FLAT_NODE_MEM_MAP is
On Mon, Jul 16, 2018 at 7:50 AM Eric W. Biederman wrote:
>
> In practice since glibc does not make thread id's available I don't
> expect anyone relies on this behavior. Since no one relies on it we
> can change it without creating a regression.
Maybe.
However, possibly not.
The thing is,
On Mon, Jul 16, 2018 at 08:31:20PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jul 16, 2018 at 11:02:19AM -0700, Guenter Roeck wrote:
> > On Mon, Jul 16, 2018 at 07:43:32PM +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Jul 16, 2018 at 09:41:23AM -0700, Guenter Roeck wrote:
> > > > On Mon, Jul 16,
On Monday, July 16, 2018 12:00:03 PM CEST Rob Herring wrote:
> On Sat, Jul 14, 2018 at 02:26:53PM +0200, Paweł Chmiel wrote:
> > This patch adds devicetree bindings documentation for
> > battery charging controller as the subnode of MAX8998 PMIC.
> >
> > Signed-off-by: Paweł Chmiel
> > ---
> >
On Mon, 16 Jul 2018, Alan Cox wrote:
> On Mon, 2018-07-16 at 10:28 -0700, Dave Hansen wrote:
> > On 07/16/2018 09:56 AM, Thomas Gleixner wrote:
> > > On Mon, 16 Jul 2018, Rich Felker wrote:
> > > > At least the Centerton (late-generation Bonnell uarch) Atom
> > > > family is
> > > > omitted from
On 13/07/18 16:39, Aapo Vienamo wrote:
...
>>> that it returns the current clock rate of the host instead of the
>>> maximum one, which can lead to unnecessarily small clock rates.
>>>
>>> This differs from the previous implementation of
>>> tegra_sdhci_get_max_clock() in that it doesn't
At least the Centerton (late-generation Bonnell uarch) Atom family is
omitted from the cpu_no_speculation table added by commit fec9434a12f3
to arch/x86/kernel/cpu/common.c. Is this intentional? Would a patch
adding it and possibly other omissions be welcome?
Rich
On Mon, Jul 16, 2018 at 09:34:57AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.56 release.
> There are 54 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
On 7/16/2018 11:07 AM, Masayoshi Mizuma wrote:
On 07/16/2018 10:29 AM, Liang, Kan wrote:
On 7/15/2018 6:34 PM, Ingo Molnar wrote:
* Masayoshi Mizuma wrote:
From: Masayoshi Mizuma
commit 15a3e845b01c ("perf/x86/intel/uncore: Fix SBOX support for
Broadwell CPUs") introduced PCU.3
On Mon, Jul 16, 2018 at 09:25:38AM -0700, Guenter Roeck wrote:
> On Mon, Jul 16, 2018 at 09:36:08AM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.113 release.
> > There are 32 patches in this series, all will be posted as a response
> > to this one.
Hi Olof,
On Mon, Jul 16, 2018 at 07:34:05AM -0700, Olof Johansson wrote:
> On Mon, Jul 16, 2018 at 2:17 AM, Marc Zyngier wrote:
> > On 15/07/18 04:53, Olof Johansson wrote:
> >> There's some use in printing out what the implementer and part numbers
> >> decode to for cases where they're known.
>
On 07/16/2018 09:56 AM, Thomas Gleixner wrote:
> On Mon, 16 Jul 2018, Rich Felker wrote:
>> At least the Centerton (late-generation Bonnell uarch) Atom family is
>> omitted from the cpu_no_speculation table added by commit fec9434a12f3
>> to arch/x86/kernel/cpu/common.c. Is this intentional? Would
sparse_init() requires to temporary allocate two large buffers: usemap_map
and map_map. Baoquan He has identified that these buffers are so large
that Linux is not bootable on small memory machines, such as a kdump boot.
The buffers are especially large when CONFIG_X86_5LEVEL is set, as they
are
Rename new_sparse_init() to sparse_init() which enables it. Delete old
sparse_init() and all the code that became obsolete with.
Signed-off-by: Pavel Tatashin
Tested-by: Michael Ellerman (powerpc)
---
include/linux/mm.h | 6 --
mm/Kconfig | 4 -
mm/sparse-vmemmap.c | 21
non-vmemmap sparse also allocated large contiguous chunk of memory, and if
fails falls back to smaller allocations. Use the same functions to
allocate buffer as the vmemmap-sparse
Signed-off-by: Pavel Tatashin
---
mm/sparse.c | 41 ++---
1 file changed, 14
Now, that both variants of sparse memory use the same buffers to populate
memory map, we can move sparse_buffer_init()/sparse_buffer_fini() to the
common place.
Signed-off-by: Pavel Tatashin
---
include/linux/mm.h | 3 ---
mm/sparse-vmemmap.c | 2 --
mm/sparse.c | 14 +++---
When struct pages are allocated for sparse-vmemmap VA layout, we first try
to allocate one large buffer, and than if that fails allocate struct pages
for each section as we go.
The code that allocates buffer is uses global variables and is spread
across several call sites.
Cleanup the code by
> On 16 Jul 2018, at 18:19, Jan Dakinevich wrote:
>
> On Mon, 9 Jul 2018 16:51:03 +0300
> Jan Dakinevich wrote:
>
>> This table by default takes 32KiB which is 3rd memory order.
Only if PAGE_SIZE is 4KiB...
>> Meanwhile, this memory is not aimed for DMA operation and could be
>> safely
On Mon, Jul 16, 2018 at 12:46:21PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jul 16, 2018 at 05:46:12PM +0800, 陈华才 wrote:
> > Just change "call_single_data_t" to "struct call_single_data" and
> > everything is OK.
>
> Ok, I've done that now, thanks.
And I messed it up. So I've just dropped it
On Mon, 2018-07-16 at 03:04 +0200, Ingo Molnar wrote:
> * Rik van Riel wrote:
>
> > On Mon, 2018-07-16 at 01:04 +0200, Ingo Molnar wrote:
> > > * Rik van Riel wrote:
> > >
> > > > + /*
> > > > +* Stop remote flushes for the previous mm.
> > > > +*
Rename the struct TS_COMMON_INFO member variable TClasProc to
t_clas_proc. This change clears the checkpatch issue with CamelCase variable
names. There should be no impact on runtime execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_TS.h | 2 +-
Rename the TX_COMMON_INFO structure's member Addr to addr. This change
clears the checkpatch issue with CamelCase naming. This is a coding style
change only and should not impact runtime execution.
Signed-off-by: John Whitmore
---
.../staging/rtl8192u/ieee80211/rtl819x_BAProc.c| 10
Rename the struct TS_COMMON_INFO member variable TClasNum to t_clas_num. This
change clears the checkpatch issue with CamelCase naming. There should be no
impact on runtime execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_TS.h | 2 +-
Simple coding style changes to avoid CamelCase.
John Whitmore (10):
staging:rtl8192u: remove typedef of enumeration TR_SELECT - Style
staging:rtl8192u: remove typedef of struct TS_COMMON_INFO - Style
staging:rtl8192u: Rename List > list - Coding style
staging:rtl8192u: rename SetupTimer >
Rename the TS_COMMON_INFO structure's member TSpec to t_spec. This change
clears the checkpatch issue with CamelCase naming of variables. There should
be no impact on runtime execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c | 2 +-
Rename the struct TS_COMMON_INFO member variable from TClass to t_class. This
change clears the checkpatch issue with CamelCase Variable names. There should
be no impact on runtime execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_TS.h | 2 +-
Rename the struct TS_COMMON_INFO member InactTimer to inact_timer.
This change clears the checkpatch issue with CamelCase naming. The change
should not have any impact on runtime execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_TS.h | 2 +-
Rename the struct TS_COMMON_INFO member SetupTimer to setup_timer. This
clears the checkpatch issue with CamelCase variable names.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_TS.h | 2 +-
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c | 8
2
In struct TS_COMMON_INFO rename the member List to list. This clears the
checkpatch issue concerning CamelCase naming of variables.
Signed-off-by: John Whitmore
---
.../staging/rtl8192u/ieee80211/rtl819x_TS.h | 2 +-
.../rtl8192u/ieee80211/rtl819x_TSProc.c | 64 +--
2
To clear a checkpatch issue removed the typedef of the structure
TS_COMMON_INFO.
This change removes the previous declaration, which defined two types, both
TS_COMMON_INFO and a pointer type PTS_COMMON_INFO:
typedef struct _TS_COMMON_INFO {
...
} TS_COMMON_INFO, *PTS_COMMON_INFO;
The
To clear a checkpatch issue removed the typedef of the enumeration TR_SELECT
this should not impact runtime code as it's only a coding style change.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/ieee80211.h | 4 ++--
Our Ref:FGN-GOV/IMF/2018
Attention:Beneficiary
Instruction was given by the Office of Presidency and United Nations(UN) and
also (IMF)to transfer Sum of $10m through ATM Debit Card to you which you can
use it in near cash point,shopping mall or banking.
You can withdrawal money from your ATM
On Mon, Jul 16, 2018 at 7:40 AM Michael Ellerman wrote:
>
> If the numbers can be trusted it is actually slower to put the sync in
> lock, at least on one of the machines:
>
> Time
> lwsync_sync 84,932,987,977
> sync_lwsync 93,185,930,333
Very funky.
> I guess arguably it's
Hi Chanwoo,
On Thu, Jul 12, 2018 at 06:08:36PM +0900, Chanwoo Choi wrote:
> Hi Matthias,
>
> On 2018년 07월 07일 03:09, Matthias Kaehlcke wrote:
> > Hi,
> >
> > On Wed, Jul 04, 2018 at 02:30:32PM +0900, Chanwoo Choi wrote:
> >
> >> I didn't see any framework which exporting the class instance.
>
On 11.06.2018 14:33, David Hildenbrand wrote:
> On 11.06.2018 13:56, Michal Hocko wrote:
>> On Mon 11-06-18 13:53:49, David Hildenbrand wrote:
>>> On 24.05.2018 23:07, David Hildenbrand wrote:
On 24.05.2018 16:22, Michal Hocko wrote:
> I will go over the rest of the email later I just
On Mon, Jul 16, 2018 at 09:36:05AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.141 release.
> There are 43 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
On Mon, Jul 16, 2018 at 09:33:38AM -0700, Guenter Roeck wrote:
> On Mon, Jul 16, 2018 at 09:34:29AM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.17.7 release.
> > There are 67 patches in this series, all will be posted as a response
> > to this one.
Texas Instrument's System Control Interface (TISCI) permits the
ability for Operating Systems to running in virtual machines to be
able to independently communicate with the firmware without the need
going through an hypervisor.
The "host-id" in effect is the hardware representation of the
host
Please find attached series to enable host-id as an optional dt property.
This is a minor update to V1 -> Mostly to pick up Greet's feedback and Rob's
Ack.
V1: https://patchwork.ozlabs.org/cover/931822/
The series is based on v4.18-rc1 and is available here:
On Mon, Jul 16, 2018 at 9:30 AM, John Stultz wrote:
> On Mon, Jul 16, 2018 at 9:17 AM, Mukesh Ojha wrote:
>> On 7/13/2018 10:50 PM, John Stultz wrote:
>>> On Fri, Jul 13, 2018 at 12:13 AM, Mukesh Ojha
On 7/11/2018 1:43 AM, John Stultz wrote:
> I worry this upside-down logic is too
Texas Instrument's System Control Interface (TISCI) permits
the ability for OSs running in virtual machines to be able to
independently communicate with the firmware without the need going
through an hypervisor.
The "host-id" in effect is the hardware representation of the
host (example: VMs
Changelog:
v6 - v5
- Removed one more obsolete function, as Oscar noticed
- Replaced BUG_ON with WARN_ON, ALIGN with PTR_ALIGN.
- Added review-by, and test-by.
v5 - v4
- Fixed the issue that was reported on ppc64 when
From: Mark Rutland
Since commit:
b899a850431e2dd0 ("compiler.h: Remove ACCESS_ONCE()")
... there has been no definition of ACCESS_ONCE() in the kernel tree,
and it has been necessary to use READ_ONCE() or WRITE_ONCE() instead.
Let's update the exmaples in recipes.txt likewise for
From: Palmer Dabbelt
Dan runs the RISC-V memory model working group. I've been forwarding
him LKMM emails that end up in my inbox, but I'm far from an expert in
this stuff. He requested to be added as a reviewer, which seems sane to
me as it'll take a human out of the loop.
CC: Daniel Lustig
This commit makes the scripts executable to avoid the need for everyone
to do so manually in their archive.
Signed-off-by: Paul E. McKenney
Acked-by: Akira Yokosawa
---
tools/memory-model/scripts/checkalllitmus.sh | 2 +-
tools/memory-model/scripts/checklitmus.sh| 2 +-
2 files changed, 2
From: Mark Rutland
Since commit:
b899a850431e2dd0 ("compiler.h: Remove ACCESS_ONCE()")
... there has been no definition of ACCESS_ONCE() in the kernel tree,
and it has been necessary to use READ_ONCE() or WRITE_ONCE() instead.
Correspondingly, let's remove ACCESS_ONCE() from the kernel
On 06/01/2018 12:18 PM, Konstantin Khlebnikov wrote:
Each process have different pids, one for each pid namespace it belongs.
When interaction happens within single pid-ns translation isn't required.
More complicated scenarios needs special handling.
For example:
- reading pid-files or logs
From: Andrea Parri
Both the implementation and the users' expectation [1] for the various
wakeup primitives have evolved over time, but the documentation has not
kept up with these changes: brings it into 2018.
[1]
http://lkml.kernel.org/r/20180424091510.gb4...@hirez.programming.kicks-ass.net
From: Andrea Parri
norm7 produces the 'normalized' name of a litmus test, when the test
can be generated from a single cycle that passes through each process
exactly once. The commit renames such tests in order to comply to the
naming scheme implemented by this tool.
Signed-off-by: Andrea
The Linux-kernel memory model has been informal, with a number of
text files documenting it. It would be good to make sure that these
informal descriptions are kept up to date and/or pruned appropriately.
This commit therefore brings more of those text files into the LKMM
MAINTAINERS file entry.
From: Jonathan Neuschäfer
The atomic_set() and ATOMIC_INIT() operations are writes, so this
commit changes their description from "reads" to "writes".
Signed-off-by: Jonathan Neuschäfer
Signed-off-by: Paul E. McKenney
Reviewed-by: Andrea Parri
---
Documentation/core-api/atomic_ops.rst | 2
From: Andrea Parri
There are 11 interpretations of the requirements described in the header
comment for smp_mb__after_spinlock(): one for each LKMM maintainer, and
one currently encoded in the Cat file. Stick to the latter (until a more
satisfactory solution is available).
This also reworks
This commit adds a litmus test suggested by Alan Stern that is forbidden
on fully multicopy atomic systems, but allowed on other-multicopy and
on non-multicopy atomic systems. For reference, s390 is fully multicopy
atomic, x86 and ARMv8 are other-multicopy atomic, and ARMv7 and powerpc
are
From: SeongJae Park
Translate this commit to Korean:
5846581e3563 ("locking/memory-barriers.txt: Fix broken DMA vs. MMIO ordering
example")
Signed-off-by: SeongJae Park
Signed-off-by: Paul E. McKenney
[ paulmck: Updated based on feedback from Byungchul Park. ]
Acked-by: Byungchul Park
From: Yauheni Kaliuta
The tools/memory-model/Documentation/explanation.txt file says
"For each other CPU C', smb_wmb() forces all po-earlier stores"
This commit therefore replaces the "smb_wmb()" with "smp_wmb()".
Signed-off-by: Yauheni Kaliuta
Signed-off-by: Paul E. McKenney
Acked-by: Alan
From: Andrea Parri
wake_woken_function() synchronizes with wait_woken() as follows:
[wait_woken] [wake_woken_function]
entry->flags &= ~wq_flag_woken;condition = true;
smp_mb(); smp_wmb();
if (condition)
On 7/16/2018 10:44 PM, John Stultz wrote:
On Mon, Jul 16, 2018 at 9:30 AM, John Stultz wrote:
On Mon, Jul 16, 2018 at 9:17 AM, Mukesh Ojha wrote:
On 7/13/2018 10:50 PM, John Stultz wrote:
On Fri, Jul 13, 2018 at 12:13 AM, Mukesh Ojha
On 7/11/2018 1:43 AM, John Stultz wrote:
I worry
On Mon, Jul 16, 2018 at 11:30 AM, Mukesh Ojha wrote:
>
>
> On 7/16/2018 10:44 PM, John Stultz wrote:
>>
>> On Mon, Jul 16, 2018 at 9:30 AM, John Stultz
>> wrote:
>>>
>>> On Mon, Jul 16, 2018 at 9:17 AM, Mukesh Ojha
>>> wrote:
On 7/13/2018 10:50 PM, John Stultz wrote:
>
> On
Lazy TLB mode can result in an idle CPU being woken up by a TLB flush,
when all it really needs to do is reload %CR3 at the next context switch,
assuming no page table pages got freed.
Memory ordering is used to prevent race conditions between switch_mm_irqs_off,
which checks whether .tlb_gen
CPUs in !is_lazy have either received TLB flush IPIs earlier on during
the munmap (when the user memory was unmapped), or have context switched
and reloaded during that stage of the munmap.
Page table free TLB flushes only need to be sent to CPUs in lazy TLB
mode, which TLB contents might not yet
Song noticed switch_mm_irqs_off taking a lot of CPU time in recent
kernels,using 1.8% of a 48 CPU system during a netperf to localhost run.
Digging into the profile, we noticed that cpumask_clear_cpu and
cpumask_set_cpu together take about half of the CPU time taken by
switch_mm_irqs_off.
Now that CPUs in lazy TLB mode no longer receive TLB shootdown IPIs, except
at page table freeing time, and idle CPUs will no longer get shootdown IPIs
for things like mprotect and madvise, we can always use lazy TLB mode.
Signed-off-by: Rik van Riel
Acked-by: Dave Hansen
Tested-by: Song Liu
Move some code that will be needed for the lazy -> !lazy state
transition when a lazy TLB CPU has gotten out of date.
No functional changes, since the if (real_prev == next) branch
always returns.
Signed-off-by: Rik van Riel
Acked-by: Dave Hansen
Suggested-by: Andy Lutomirski
---
Linus Torvalds writes:
> On Mon, Jul 16, 2018 at 8:08 AM Eric W. Biederman
> wrote:
>>
>> The change for global init is it will now die if init is a member of the
>> session or init is using this tty as it's controlling tty.
>>
>> Semantically killing init with SAK is completely appropriate.
>
This is my first patch, an attempt to implement Memory ROE discussed by me
earlier as a way to prevent Rootkits. I have already explained in details
in this thread:
https://www.mail-archive.com/kernelnewbies@kernelnewbies.org/msg18826.html
So I think there is no need for saying the exact same
On Mon, Jul 16, 2018 at 12:17 PM Eric W. Biederman
wrote:
>
> I should have said it doesn't matter because init does not open ttys and
> become a member of session groups. Or at least it never has in my
> experience. The only way I know to get that behavior is to boot with
> init=/bin/bash.
On 16/07/18 15:34, Aapo Vienamo wrote:
> Tegra SDHCI controllers require the SDHCI clock divider to be configured
> to divide the clock by two in DDR50/52 modes. Incorrectly configured
> clock divider results in corrupted data.
>
> Prevent the possibility of incorrectly calculating the divider
On Mon, 9 Jul 2018 16:51:03 +0300
Jan Dakinevich wrote:
> This table by default takes 32KiB which is 3rd memory order.
> Meanwhile, this memory is not aimed for DMA operation and could be
> safely allocated by vmalloc.
>
> Signed-off-by: Jan Dakinevich
> ---
>
On Mon, Jul 16, 2018 at 09:34:29AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.17.7 release.
> There are 67 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
On Mon 16-07-18 17:47:39, Kirill A. Shutemov wrote:
> On Mon, Jul 16, 2018 at 04:22:45PM +0200, Michal Hocko wrote:
> > On Mon 16-07-18 17:04:41, Kirill A. Shutemov wrote:
> > > On Mon, Jul 16, 2018 at 01:30:28PM +, Michal Hocko wrote:
> > > > On Tue 10-07-18 13:48:58, Andrew Morton wrote:
> >
* Peter Zijlstra wrote:
> On Sun, Jul 15, 2018 at 04:36:17PM -0700, tip-bot for Xunlei Pang wrote:
> > Commit-ID: 8d4c00dc38a8aa30dae8402955e55e7b34e74bc8
> > Gitweb:
> > https://git.kernel.org/tip/8d4c00dc38a8aa30dae8402955e55e7b34e74bc8
> > Author: Xunlei Pang
> > AuthorDate: Mon,
Hello, Ingo!
This pull request contains the following changes:
1. An optimization and a fix for RCU expedited grace periods, with
the fix being from Boqun Feng.
http://lkml.kernel.org/r/20180625224308.ga10...@linux.vnet.ibm.com
2. Miscellaneous fixes, including a
On Sat, Jul 14, 2018 at 02:26:53PM +0200, Paweł Chmiel wrote:
> This patch adds devicetree bindings documentation for
> battery charging controller as the subnode of MAX8998 PMIC.
>
> Signed-off-by: Paweł Chmiel
> ---
> Changes from v1:
> - Removed unneeded Fixes tag
> - Correct description
On Mon, Jul 16, 2018 at 11:02:19AM -0700, Guenter Roeck wrote:
> On Mon, Jul 16, 2018 at 07:43:32PM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Jul 16, 2018 at 09:41:23AM -0700, Guenter Roeck wrote:
> > > On Mon, Jul 16, 2018 at 06:31:36PM +0200, Greg Kroah-Hartman wrote:
> > > > On Mon, Jul 16,
On Tue, 17 Jul 2018, Mukesh Ojha wrote:
> On 7/16/2018 10:44 PM, John Stultz wrote:
> > > So, I think with the logic bug above it will work out properly, but
> > > let me know if I'm still missing something.
>
> Please give it thought to a case where very first suspend fails with your
> logic.
>
On Mon, Jul 16, 2018 at 09:36:08AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.113 release.
> There are 32 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
Hi,
Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1601529
with 4.18-rc4:
Steps to Reproduce:
1.echo 'int f;' | gcc -include linux/aio_abi.h -xc -c - -o /dev/null
Actual results:
/usr/include/asm/signal.h:127:2: error: unknown type name ‘size_t’
size_t ss_size;
^~
On Mon, Jul 16, 2018 at 09:33:38AM -0700, Guenter Roeck wrote:
> On Mon, Jul 16, 2018 at 09:34:29AM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.17.7 release.
> > There are 67 patches in this series, all will be posted as a response
> > to this one.
On Sun, Jul 15, 2018 at 08:56:57PM -0700, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> removes the discouraged use of AHASH_REQUEST_ON_STACK by switching to
> shash directly and allocating the descriptor in heap memory (which should
> be fine: the tfm
On Thu, Jul 12, 2018 at 05:44:33PM +0900, Chanwoo Choi wrote:
> Hi Matthias,
>
> On 2018년 07월 07일 02:53, Matthias Kaehlcke wrote:
> > Hi Chanwoo,
> >
> > On Wed, Jul 04, 2018 at 03:41:46PM +0900, Chanwoo Choi wrote:
> >
> >> Firstly,
> >> I'm not sure why devfreq needs the
On Fri, Jul 13, 2018 at 02:50:01PM +0200, Marco Felsch wrote:
> This binding is used to keep the backward compatibility with the current
> dtb's [1]. The binding informs the driver that the unused switch regulators
> can be disabled.
> If it is not specified, the driver doesn't disable the switch
On Mon, 2018-07-16 at 10:28 -0700, Dave Hansen wrote:
> On 07/16/2018 09:56 AM, Thomas Gleixner wrote:
> > On Mon, 16 Jul 2018, Rich Felker wrote:
> > > At least the Centerton (late-generation Bonnell uarch) Atom
> > > family is
> > > omitted from the cpu_no_speculation table added by commit
> > >
On Mon, Jul 16, 2018 at 06:31:36PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jul 16, 2018 at 09:25:38AM -0700, Guenter Roeck wrote:
> > On Mon, Jul 16, 2018 at 09:36:08AM +0200, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.9.113 release.
> > > There are
On Fri, 2 Mar 2018, Sebastian Andrzej Siewior wrote:
> From: Ingo Molnar
> Date: Fri, 3 Jul 2009 08:29:27 -0500
>
> With threaded interrupts we might see an interrupt in progress on
> migration. Do not unmask it when this is the case.
It took me quite a while to wrap my head around this one.
On Mon, 16 Jul 2018, Rich Felker wrote:
> At least the Centerton (late-generation Bonnell uarch) Atom family is
> omitted from the cpu_no_speculation table added by commit fec9434a12f3
> to arch/x86/kernel/cpu/common.c. Is this intentional? Would a patch
> adding it and possibly other omissions
1 - 100 of 1772 matches
Mail list logo
