On Fri, Mar 30, 2018 at 09:55:44AM -0700, Kees Cook wrote:
> On the quest to remove all VLAs from the kernel[1], this avoids VLAs
> by just using the maximum allocation size (4 bytes) for stack arrays.
> All the VLAs in ecc were either 3 or 4 bytes (or a multiple), so just
> make it 4 bytes all the
On 04/20/2018 02:35 AM, Viresh Kumar wrote:
> On 20-04-18, 10:15, Sudeep Holla wrote:
>> It still doesn't give the flexibility to switch between the two
>> implementations boot time based on some firmware config(e.g. DT status
>> property).
>
> I agree, but it didn't look like they need flexibilit
On Fri, Mar 30, 2018 at 12:14:53PM -0700, Nick Terrell wrote:
> Adds zstd support to crypto and scompress. Only supports the default
> level.
>
> Previously we held off on this patch, since there weren't any users.
> Now zram is ready for zstd support, but depends on CONFIG_CRYPTO_ZSTD,
> which is
On Fri, 2018-04-20 at 17:50 +0200, Peter Zijlstra wrote:
> On Tue, Apr 10, 2018 at 09:27:50AM -0700, Davidlohr Bueso wrote:
> > By applying well known spin-on-lock-owner techniques, we can avoid the
> > blocking overhead during the process of when the task is trying to take
> > the rtmutex. The ide
On Fri, Apr 20, 2018 at 03:28:26PM +0200, Geert Uytterhoeven wrote:
> The first 6 patches can be applied independently by subsystem
> maintainers.
> The last two patches depend on the first 6 patches, and are thus marked
> RFC.
Would it not make sense to try to apply everything en masse rather th
Quoting Rob Herring (2018-04-18 15:29:05)
> diff --git a/Documentation/devicetree/bindings/example-schema.yaml
> b/Documentation/devicetree/bindings/example-schema.yaml
> new file mode 100644
> index ..fe0a3bd1668e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/example-schem
On Fri, Apr 20, 2018 at 05:08:23PM +0300, Andrey Ryabinin wrote:
>
>
> On 04/19/2018 06:01 AM, Fengguang Wu wrote:
> > Hello,
> >
> > FYI this happens in mainline kernel 4.17.0-rc1.
> > It at least dates back to v4.8 .
> >
> > [ 25.697463]
> > [ 25.697463] Start testing find_bit() with rand
On Fri, Apr 20, 2018 at 03:39:46PM +0300, Andy Shevchenko wrote:
> On Wed, 2018-04-18 at 15:35 +0530, Amit Pundir wrote:
>
> > if (skb->data[transaction->aid_len + 2] !=
> > - NFC_EVT_TRANSACTION_PARAMS_TAG)
> > + NFC_EVT_TRANSACTION_PARAMS_TAG ||
> > +
On Fri, Apr 20, 2018 at 9:36 AM Marc Zyngier wrote:
> On 20/04/18 17:30, Nick Desaulniers wrote:
> > On Fri, Apr 20, 2018 at 1:13 AM Marc Zyngier
wrote:
> >> Clang isn't
> >> really supported to build the arm64 kernel anyway
> >
> > Can you expand on this? There are millions of arm64 devices sh
Add MSI interrupt support if the SD host device can support MSI interrupt.
Changes in V5:
1. Because pci_enable_msi is marked as deprecated and should not be
used in new code, use pci_alloc_irq_vectors instead.
2. Remove unneeded CONFIG_PCI_MSI macro check
Changes in V4:
From: Bartosz Golaszewski
I'm using the early_platform infrastructure for converting the davinci
timer support to a real platform_driver. I noticed that it would be
nice to have these two helpers for more code brevity.
Bartosz Golaszewski (2):
platform: provide early_platform_add_device()
pl
From: Bartosz Golaszewski
Currently we only have early_platform_add_devices() which takes struct
platform_device ** as argument, requiring the users to have an
intermediate array of platform_device pointers even if we're only
adding a single device. Provide a helper for adding a single device at
From: Bartosz Golaszewski
All users of early_platform_driver_register_all() subsequently call
early_platform_driver_probe(). Provide a helper that calls both
functions.
Signed-off-by: Bartosz Golaszewski
---
include/linux/platform_device.h | 9 +
1 file changed, 9 insertions(+)
diff -
Instead of implementing our own version of a SR-IOV configuration stub in
the nvme driver we can just reuse the existing
pci_sriov_configure_simple function.
Reviewed-by: Christoph Hellwig
Signed-off-by: Alexander Duyck
---
v5: Replaced call to pci_sriov_configure_unmanaged with
pci_sri
Add hardware tuning function instead of software tuning because O2/Bayhub
SD host controller support hardware tuning.
Changes in V5:
In function sdhci_o2_send_tuning, mrq.data should set to NULL for
cmd.data has been set to NULL.
Changes in V4:
Patch V3 delete register SDH
When use eMMC as boot device, the eMMC signaling voltage is tied to 1.8v
fixed output voltage, bios can set o2 sd host controller PCI configuration
register 0x308 bit4 to 1 to let driver skip 3.3v signaling voltage and
direct use 1.8v singling voltage in eMMC initialize process.
Changes in V5:
Add a new driver called "pci-pf-stub" to act as a "white-list" for PF
devices that provide no other functionality other then acting as a means of
allocating a set of VFs. For now I only have one example ID provided by
Amazon in terms of devices that require this functionality. The general
idea is t
Instead of implementing our own version of a SR-IOV configuration stub in
the ena driver we can just reuse the existing
pci_sriov_configure_simple function.
Signed-off-by: Alexander Duyck
---
v5: Replaced call to pci_sriov_configure_unmanaged with
pci_sriov_configure_simple
v6: Dropped "
We do store memory.min, memory.low and memory.max actual values
in struct page_counter fields, while memory.high value is located
in the struct mem_cgroup directly, which is not very consistent.
This patch moves the high field from struct mem_cgroup to
struct page_counter to simplify the code and
Memory controller implements the memory.low best-effort memory
protection mechanism, which works perfectly in many cases and
allows protecting working sets of important workloads from
sudden reclaim.
But it's semantics has a significant limitation: it works
only until there is a supply of reclaima
On 20/04/18 17:30, Nick Desaulniers wrote:
> On Fri, Apr 20, 2018 at 1:13 AM Marc Zyngier wrote:
>> Clang isn't
>> really supported to build the arm64 kernel anyway
>
> Can you expand on this? There are millions of arm64 devices shipping with
> Clang built Linux kernels.
How many of these devic
This series is meant to add support for SR-IOV on devices when the VFs are
not managed by the kernel. Examples of recent patches attempting to do this
include:
virto - https://patchwork.kernel.org/patch/10241225/
pci-stub - https://patchwork.kernel.org/patch/10109935/
vfio - https://patchwork.kerne
This patch adds a common configuration function called
pci_sriov_configure_simple that will allow for managing VFs on devices
where the PF is not capable of managing VF resources.
Signed-off-by: Alexander Duyck
Tested-by: Mark Rustad
---
v5: New patch replacing pci_sriov_configure_unmanaged wit
Since tmpfs THP was supported in 4.8, hugetlbfs is not the only
filesystem with huge page support anymore. tmpfs can use huge page via
THP when mounting by "huge=" mount option.
When applications use huge page on hugetlbfs, it just need check the
filesystem magic number, but it is not enough for t
From: Tomasz Figa
This patch adds support for FIMD variant found on S5PV210 SoC.
Except CLKSEL bit availability, it is identical to Exynos4210.
Tested-by: Paweł Chmiel
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 8
1 file changed, 8 insertions(+)
diff -
This patch series compose of 2 patches.
First patch, adding support for S5PV210 FIMD variant to Exynos driver.
Compatible for this soc was already existing in documentation.
Second patch, brings back possibility to use drivers depending on
DRM_EXYNOS, on Samsung S5PV210/S5PC110 series based syste
This patch brings back possibility to use drivers depending on
DRM_EXYNOS, on Samsung S5PV210/S5PC110 series based systems.
Fixes: dbbc925bb83a ("drm/exynos: depend on ARCH_EXYNOS for DRM_EXYNOS")
Signed-off-by: Paweł Chmiel
---
drivers/gpu/drm/exynos/Kconfig | 2 +-
1 file changed, 1 insertion(
A couple of fixes to our references and comments: the first updating
ASPLOS information, the second adding a reference.
Cheers,
Andrea
Cc: Alan Stern
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: Nicholas Piggin
Cc: David Howells
Cc: Jade Alglave
Cc: Luc Maranget
Cc: "Paul E. Mc
The paper discusses the revised ARMv8 memory model; such revision
had an important impact on the design of the LKMM.
Signed-off-by: Andrea Parri
Cc: Alan Stern
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: Nicholas Piggin
Cc: David Howells
Cc: Jade Alglave
Cc: Luc Maranget
Cc: "Pa
ASPLOS 2018 was held in March: make sure this is reflected in
header comments and references.
Signed-off-by: Andrea Parri
Cc: Alan Stern
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: Nicholas Piggin
Cc: David Howells
Cc: Jade Alglave
Cc: Luc Maranget
Cc: "Paul E. McKenney"
Cc: Ak
On Fri, Apr 20, 2018 at 9:00 AM, Vincent Guittot
wrote:
[..]
>
> Le Saturday 14 Apr 2018 à 13:24:20 (+0200), Vincent Guittot a écrit :
>> Hi Niklas,
>>
>> On 13 April 2018 at 00:39, Niklas Söderlund
>> wrote:
>> > Hi Vincent,
>> >
>> > Thanks for helping trying to figure this out.
>> >
>> > On 20
On Fri, Apr 20, 2018 at 1:13 AM Marc Zyngier wrote:
> Clang isn't
> really supported to build the arm64 kernel anyway
Can you expand on this? There are millions of arm64 devices shipping with
Clang built Linux kernels.
--
Thanks,
~Nick Desaulniers
On Fri, Apr 20, 2018 at 03:42:45PM +0100, Quentin Perret wrote:
> Hi Leo,
>
> On Wednesday 18 Apr 2018 at 20:15:47 (+0800), Leo Yan wrote:
> > Sorry I introduce mess at here to spread my questions in several
> > replying, later will try to ask questions in one replying. Below are
> > more questio
On 20.04.2018 09:57, Peter Zijlstra wrote:
> On Mon, Apr 16, 2018 at 10:54:26AM +0200, Philipp Klocke wrote:
>
>> This patch is motivated by the clang warning Wconstant-logical-operand,
>> issued when logically comparing a variable to a constant integer that is
>> neither 1 nor 0. It happens for
On Fri, Apr 20, 2018 at 7:38 AM, Eric W. Biederman
wrote:
> Filling in struct siginfo before calling force_sig_info a tedious and
> error prone process, where once in a great while the wrong fields
> are filled out, and siginfo has been inconsistently cleared.
>
> Simplify this process by using th
On Thu, Apr 19, 2018 at 9:23 PM, Richard Guy Briggs wrote:
> On 2018-04-18 20:39, Paul Moore wrote:
>> On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs wrote:
>> > Standalone audit records have the timestamp and serial number generated
>> > on the fly and as such are unique, making them standa
Hi Matt,
On 4/17/2018 2:43 PM, Sinan Kaya wrote:
> On 4/16/2018 6:16 PM, Sinan Kaya wrote:
>> memory-barriers.txt has been updated with the following requirement.
>>
>> "When using writel(), a prior wmb() is not needed to guarantee that the
>> cache coherent memory writes have completed before wri
Hello Linus,
Here are a couple of fixes on thermal subsystem.
Please consider pulling from
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal fixes
to receive Thermal Management updates for v4.17-rc2 with top-most
e04907dbc25930b88ee2328fe692c776f63ddf2c:
dt-bindings:
I moved to Amarula Solutions; switch to work e-mail address.
Signed-off-by: Andrea Parri
Cc: Alan Stern
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: Nicholas Piggin
Cc: David Howells
Cc: Jade Alglave
Cc: Luc Maranget
Cc: "Paul E. McKenney"
Cc: Akira Yokosawa
---
MAINTAINERS |
On Fri, Apr 20, 2018 at 03:56:28PM +0200, Christian Brauner wrote:
> On Wed, Apr 18, 2018 at 11:52:47PM +0200, Christian Brauner wrote:
> > On Wed, Apr 18, 2018 at 11:55:52AM -0500, Eric W. Biederman wrote:
> > > Christian Brauner writes:
> > >
> > > > Now that it's possible to have a different s
Remove dead code that bails on `attr->value_size > KMALLOC_MAX_SIZE` - the
previous check already bails on `attr->value_size != 4`.
Signed-off-by: Jann Horn
---
kernel/bpf/sockmap.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index 8dd9210d7d
The loongson1 platform is 32-bit, so storing a time value in 32 bits
suffers from limited range. In this case it is likely to be correct
until 2106, but it's better to avoid the limitation and just use
the time64_t based mktime64() and rtc_time64_to_tm() interfaces.
The hardware uses a 32-bit year
The tps6586x use a 64-bit 'epoch_start' value, but then computes that
value using an 'mktime()', which has a smaller range and overflows
in 2106 at the latest. As both the hardware and the subsystem interface
support wider than 32-bit ranges for rtc times here, let's change all
the operations on 's
This driver uses mktime() and rtc_time_to_tm() to convert between time
values. This works fine on 64-bit kernels over the whole supported
range, and the vr41xx chip is a 64-bit MIPS implementation, but it is
inconsistent because it doesn't do the same thing on 32-bit kernels that
overflow in 2106 o
On Fri, Apr 20, 2018 at 09:08:51AM -0700, Alexander Duyck wrote:
> On Fri, Apr 20, 2018 at 8:28 AM, Michael S. Tsirkin wrote:
> > On Fri, Apr 20, 2018 at 07:56:14AM -0700, Alexander Duyck wrote:
> >> > I think for virtio it should include the feature bit, yes.
> >> > Adding feature bit is very eas
On Thu, Apr 19, 2018 at 9:03 PM, Richard Guy Briggs wrote:
> On 2018-04-18 20:32, Paul Moore wrote:
>> On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs wrote:
...
>> > /*
>> > * audit_log_container_info - report container info
>> > - * @tsk: task to be recorded
>> > * @context: task or
On Thu, Apr 19, 2018 at 8:42 PM, Richard Guy Briggs wrote:
> On 2018-04-18 21:31, Paul Moore wrote:
>> On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs wrote:
>> > Add container ID auxiliary records to secure computing and abnormal end
>> > standalone records.
>> >
>> > Signed-off-by: Richard
On 20 April 2018 at 17:38, Mark Rutland wrote:
> Hi Andrey,
>
> On Fri, Apr 20, 2018 at 04:59:35PM +0200, Andrey Konovalov wrote:
>> On Fri, Apr 20, 2018 at 10:13 AM, Marc Zyngier wrote:
>> >> The issue is that
>> >> clang doesn't know about the "S" asm constraint. I reported this to
>> >> clang
On Fri, Apr 20, 2018 at 8:28 AM, Michael S. Tsirkin wrote:
> On Fri, Apr 20, 2018 at 07:56:14AM -0700, Alexander Duyck wrote:
>> > I think for virtio it should include the feature bit, yes.
>> > Adding feature bit is very easy - post a patch to the virtio TC mailing
>> > list, wait about a week to
On 04/20/18 15:38, Eric W. Biederman wrote:
Today user mode linux only works on x86 and x86_64 and this allows
simplifications of relay_signal.
I believe someone recently fixed the ARM port. I have not had the time
to try the fixes though.
I have added the new list we are migrating to the c
On Fri, Apr 20, 2018 at 7:38 AM, Eric W. Biederman
wrote:
> While working on changing this code to use force_sig_fault I
> discovered that do_unaliged_user is sets si_signo to SIGBUS and passes
> SIGSEGV to force_sig_info. Which is just b0rked.
>
> The code is reporting a SIGBUS error so replace
do_gettimeofday() is deprecated since it will stop working in 2038 on
32-bit platforms, leading to incorrect times passed to the firmware.
On 64-bit platforms the current code appears to be fine, as the
calculation passes an 8-bit century number into the firmware that can
represent times long in th
do_gettimeofday() is deprecated because of the y2038 overflow.
Here, we use the result to pass into a 32-bit field in the firmware,
which still risks an overflow, but if the firmware is written
to expect unsigned values, it can at least last until y2106,
and there is not much we can do about it.
T
On Thu 19 Apr 22:43 PDT 2018, kgu...@codeaurora.org wrote:
> On 2018-04-19 21:28, Bjorn Andersson wrote:
> > On Thu 19 Apr 03:45 PDT 2018, kgu...@codeaurora.org wrote:
> > > On 2017-12-05 11:10, Bjorn Andersson wrote:
[..]
> > > > When is this feature needed?
> > > >
> > > This feature is needed i
On Fri, Apr 20, 2018 at 12:37:08PM +0200, Borislav Petkov wrote:
> Vitezslav reported a case where the
>
> "Timeout during microcode update!"
>
> panic would hit. After a deeper look, it turned out that his .config had
> CONFIG_HOTPLUG_CPU disabled which practically made save_mc_for_early() a
>
Hi Heiner and Niklas,
Le Saturday 14 Apr 2018 à 13:24:20 (+0200), Vincent Guittot a écrit :
> Hi Niklas,
>
> On 13 April 2018 at 00:39, Niklas Söderlund
> wrote:
> > Hi Vincent,
> >
> > Thanks for helping trying to figure this out.
> >
> > On 2018-04-12 15:30:31 +0200, Vincent Guittot wrote:
> >
On Fri, Apr 20, 2018 at 12:34:28PM +0200, Borislav Petkov wrote:
> save_mc_for_early() was a no-op on !CONFIG_HOTPLUG_CPU but the
> generic_load_microcode() path saves the microcode patches it has found
> into our cache of patches which is used for late loading too. Regardless
> of whether we do CP
Assorted fixes. Some of that is only a matter with fault injection
(broken handling of small allocation failure in various mount-related places),
but the last one is a root-triggerable stack overflow, and combined with
userns it gets really nasty ;-/
The following changes since commit 60c
On Fri, Apr 20, 2018 at 9:46 AM, Richard Guy Briggs wrote:
> On 2018-04-17 18:06, Paul Moore wrote:
>> On Wed, Apr 11, 2018 at 8:46 AM, Richard Guy Briggs wrote:
>> > Tie syscall information to FEATURE_CHANGE calls since it is a result of
>> > user action.
>> >
>> > See: https://github.com/linux-
From: Patrice Chotard
Since commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of
IRQ_TYPE_NONE")
kernel is complaining about the IRQ_TYPE_NONE usage which shouldn't
be used.
Use IRQ_TYPE_LEVEL_HIGH instead.
Signed-off-by: Patrice Chotard
---
arch/arm/boot/dts/stih410.dtsi | 18
From: Patrice Chotard
Since commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of
IRQ_TYPE_NONE")
kernel is complaining about the IRQ_TYPE_NONE usage which shouldn't
be used.
Use IRQ_TYPE_LEVEL_HIGH instead.
Signed-off-by: Patrice Chotard
---
arch/arm/boot/dts/stihxxx-b2120.dts
From: Patrice Chotard
Fix the STi following DT files which make usage of IRQ_TYPE_NONE flag:
_ stih407-family.dtsi
_ stih407-pinctrl.dtsi
_ stih407.dtsi
_ stih410.dtsi
_ stihxxx-b2120.dtsi
Patrice Chotard (5):
ARM: dts: stih407-family: Fix complain about IRQ_TYPE_NONE usage
ARM: dts:
From: Patrice Chotard
Since commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of
IRQ_TYPE_NONE")
kernel is complaining about the IRQ_TYPE_NONE usage which shouldn't
be used.
Use IRQ_TYPE_LEVEL_HIGH instead.
Signed-off-by: Patrice Chotard
---
arch/arm/boot/dts/stih407-family.dt
From: Patrice Chotard
Since commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of
IRQ_TYPE_NONE")
kernel is complaining about the IRQ_TYPE_NONE usage which shouldn't
be used.
Use IRQ_TYPE_LEVEL_HIGH instead.
Signed-off-by: Patrice Chotard
---
arch/arm/boot/dts/stih407-pinctrl.d
From: Patrice Chotard
Since commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of
IRQ_TYPE_NONE")
kernel is complaining about the IRQ_TYPE_NONE usage which shouldn't
be used.
Use IRQ_TYPE_LEVEL_HIGH instead.
Signed-off-by: Patrice Chotard
---
arch/arm/boot/dts/stih407.dtsi | 2
Freeing all skbs and sending ACK is time consuming.
This is currently done while both current->mm->mmap_sem and socket
lock are held, in tcp_mmap()
Thanks to mmap_hook infrastructure, we can perform the cleanup
after current->mm->mmap_sem has been released, thus allowing
other threads to perform
sock_mmap_hook() is the mmap_hook handler provided for socket_file_ops
Following patch will provide tcp_mmap_hook() for TCP protocol.
Signed-off-by: Eric Dumazet
---
include/linux/net.h | 1 +
net/socket.c| 9 +
2 files changed, 10 insertions(+)
diff --git a/include/linux/net.h
When adding tcp mmap() implementation, I forgot that socket lock
had to be taken before current->mm->mmap_sem. syzbot eventually caught
the bug.
This patch provides a new mmap_hook() method in struct file_operations
that might be provided by fs to implement a finer control of whats
to be done befo
This patch series provide a new mmap_hook to fs willing to grab
a mutex before mm->mmap_sem is taken, to ensure lockdep sanity.
This hook allows us to shorten tcp_mmap() execution time (while mmap_sem
is held), and improve multi-threading scalability.
Eric Dumazet (4):
mm: provide a mmap_hook
Many socket operations can copy data between user and kernel space
while socket lock is held. This means mm->mmap_sem can be taken
after socket lock.
When implementing tcp mmap(), I forgot this and syzbot was kind enough
to point this to my attention.
This patch adds tcp_mmap_hook(), allowing us
Hi Ulf,
On Fri, 2018-04-20 at 09:35 +0200, Ulf Hansson wrote:
> [...]
>
> >
> > 2. Add missing stuff to support multislot mode in DesignWare MMC driver.
> > * Add missing slot switch to __dw_mci_start_request() function.
> > * Refactor set_ios function:
> >a) Calculate common clock which i
The only remaining user of board_time_init() is the of-generic
machine, and that just calls the global timer_init() function.
Calling that one has no effect on non-DT platforms, so we can
simply call it unconditionally in place of board_time_init().
Signed-off-by: Arnd Bergmann
---
Documentation
All platforms are now converted to RTC drivers, so this has become
obsolete. The board_time_init() callback still has one caller, but
could otherwise also get killed.
This removes one more usage of the deprecated timespec structure,
which overflows in y2038.
Signed-off-by: Arnd Bergmann
---
arc
The dreamcast RTC support has an extra level of indirection to
provide either the old read_persistent_clock/update_persistent_clock
interface or the rtc-generic device for hctosys/systohc.
By removing the indirection and always using the RTC_CLASS interface,
we can avoid the lossy double conversio
On Thu, 19 Apr 2018 14:54:24 -0700
Long Li wrote:
> From: Long Li
>
> This is a best effort for estimating on how busy the ring buffer is for
> that channel, based on available buffer to write in percentage. It is still
> possible that at the time of actual ring buffer write, the space may not
On Tue, Apr 10, 2018 at 09:27:50AM -0700, Davidlohr Bueso wrote:
> By applying well known spin-on-lock-owner techniques, we can avoid the
> blocking overhead during the process of when the task is trying to take
> the rtmutex. The idea is that as long as the owner is running, there is a
> fair chan
The dreamcast RTC support has an extra level of indirection to
provide either the old read_persistent_clock/update_persistent_clock
interface or the rtc-generic device for hctosys/systohc.
Both do the same thing here, so we can do away with the abstraction
and simply enable the RTC core code to ta
Based on discussion with Kate Stewart this license is not a
BSD-2-Clause, but is now formally identified as Linux-OpenIB
by SPDX.
The key difference between the licenses is in the 'warranty'
paragraph.
if_infiniband.h refers to the 'OpenIB.org' license, but
does not include the text, instead it l
Replace magic numbers with IRQ_TYPE_* constants to improve
DT readability.
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/imx53-ppd.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx53-ppd.dts b/arch/arm/boot/dts/imx53-ppd.dts
index d5628a
I have root caused the issue, and will submit a fix shortly. The fix
also fixes the per_cpu_ptr_to_phys bug that is sent in a separate
thread.
The issue arises in this stack:
start_kernel()
trap_init()
setup_cpu_entry_areas()
setup_cpu_entry_area(cpu)
get_cpu_gdt_paddr(cpu)
per_cpu
From: Phil Elwell
Date: Thu, 19 Apr 2018 17:59:37 +0100
> The Microchip LAN78XX family of devices are Ethernet controllers with
> a USB interface. Despite being discoverable devices it can be useful to
> be able to configure them from Device Tree, particularly in low-cost
> applications without a
... we already use these for regular mutexes, rtmutex can
also use it, and while at it rename the whole thing since
this is specific to waiters.
Signed-off-by: Davidlohr Bueso
---
include/linux/poison.h | 4 ++--
kernel/locking/mutex-debug.c | 4 ++--
kernel/locking/rtmutex-debug.c | 4 +
Hi Andrey,
On Fri, Apr 20, 2018 at 04:59:35PM +0200, Andrey Konovalov wrote:
> On Fri, Apr 20, 2018 at 10:13 AM, Marc Zyngier wrote:
> >> The issue is that
> >> clang doesn't know about the "S" asm constraint. I reported this to
> >> clang [2], and hopefully this will get fixed. In the meantime,
On Fri, 20 Apr 2018 20:37:58 +0530
Ravi Bangoria wrote:
> Kernel is crashing when user tries to record 'ftrace:function' event
> with empty filter:
>
> # perf record -e ftrace:function --filter="" ls
>
> # dmesg
> BUG: unable to handle kernel NULL pointer dereference at 0008
>
Paul Moore wrote:
> Adding the SELinux mailing list to the CC line; in the future please
> include the SELinux mailing list on patches like this. It would also
> be very helpful to include "selinux" somewhere in the subject line
> when the patch is predominately SELinux related (much like you di
On Thu, Apr 19, 2018 at 11:55:55PM -0400, Doug Ledford wrote:
> On Wed, 2018-04-18 at 16:24 +0200, Håkon Bugge wrote:
> > Two kernel threads may get the same value for agent.hi_tid, if the
> > agents are registered for different ports. As of now, this works, as
> > the agent list is per port.
> >
Add the possibility to apply and query the clock signal duty cycle ratio.
This is useful when the duty cycle of the clock signal depends on some
other parameters controlled by the clock framework.
For example, the duty cycle of a divider may depends on the raw divider
setting (ratio = N / div) ,
On Fri, Apr 20, 2018 at 07:56:14AM -0700, Alexander Duyck wrote:
> > I think for virtio it should include the feature bit, yes.
> > Adding feature bit is very easy - post a patch to the virtio TC mailing
> > list, wait about a week to give people time to respond (two weeks if it
> > is around holid
On 20/04/18 17:30, Kirill Tkhai wrote:
> On 20.04.2018 17:11, Juri Lelli wrote:
> > On 20/04/18 13:06, Kirill Tkhai wrote:
> >> From: Kirill Tkhai
> >>
> >> tg_rt_schedulable() iterates over all child task groups,
> >> while tg_has_rt_tasks() iterates over all linked tasks.
> >> In case of systems
On 04/20/18 07:29, mario.limoncie...@dell.com wrote:
>> -Original Message-
>> From: Randy Dunlap [mailto:rdun...@infradead.org]
>> Sent: Thursday, April 19, 2018 1:00 PM
>> To: Stephen Rothwell; Linux-Next Mailing List
>> Cc: Linux Kernel Mailing List; Platform Driver; Limonciello, Mario
>>
On Thu, Apr 19, 2018 at 9:21 AM, Baolin Wang wrote:
> The dummy read_persistent_clock() uses a timespec, which is not year 2038
> safe on 32bit systems. Thus remove this obsolete interface.
>
> Signed-off-by: Baolin Wang
Looks good to me. I have a larger but incomplete patch for arch/mips
handli
On Fri, Apr 20, 2018 at 11:21 PM, David Miller wrote:
>
> Why are you sending this same patch twice?
>
> Thank you.
Some mistake.
Sorry about that.
Pls. use the second patch.
Thanks
Yafang
On Fri, 20 Apr 2018 16:34:25 +0200
Miklos Szeredi wrote:
> This corner case is simply not interesting (modifying a binary while
> it is being debugged with uprobe). Let's just concentrate on making
> this crash and leak free.
Yes please. I'm waiting for a final patch to run my tests. I have oth
On Thu, Apr 19, 2018 at 8:51 AM, Baolin Wang wrote:
> The read_persistent_clock() uses a timespec, which is not year 2038 safe
> on 32bit systems. On parisc architecture, we have implemented generic RTC
> drivers that can be used to compensate the system suspend time, but the
> RTC time can not re
On Thu, Apr 19, 2018 at 8:22 AM, Baolin Wang wrote:
> The read_persistent_clock() uses a timespec, which is not year 2038 safe
> on 32bit systems. Moreover on m68k architecture, we have implemented generic
> RTC drivers that can be used to compensate the system suspend time. So
> we can remove the
On 04/20/2018 04:28 PM, Geert Uytterhoeven wrote:
> Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
> CONFIG_ARCH_SHMOBILE, hence use the former.
>
> Renesas SuperH SH-Mobile SoCs are still covered
[fixing up Christoffer's address]
On 20/04/18 15:59, Andrey Konovalov wrote:
> On Fri, Apr 20, 2018 at 10:13 AM, Marc Zyngier wrote:
>>> The issue is that
>>> clang doesn't know about the "S" asm constraint. I reported this to
>>> clang [2], and hopefully this will get fixed. In the meantime, wou
On Fri, Apr 20, 2018 at 05:46:25AM -0700, Christoph Hellwig wrote:
> On Fri, Apr 20, 2018 at 12:44:01PM +0200, Christian König wrote:
> > > > What we need is an sg_alloc_table_from_resources(dev, resources,
> > > > num_resources) which does the handling common to all drivers.
> > > A structure that
Why are you sending this same patch twice?
Thank you.
tcp_rcv_space_adjust is called every time data is copied to user space,
introducing a tcp tracepoint for which could show us when the packet is
copied to user.
When a tcp packet arrives, tcp_rcv_established() will be called and with
the existed tracepoint tcp_probe we could get the time when this
301 - 400 of 936 matches
Mail list logo
