The !32bit+fxsr case loads the new state from user memory. In case we
restore the FPU state on return to userland we can't do this. It would
be required to disable preemption in order to avoid a context switch
which would set TIF_NEED_FPU_LOAD. If this happens before the "restore"
operation then th
If the CPU holds the FPU register for the current task then we can try to save
them directly to the userland stack frame. This has to be done with the
pagefault disabled because we can't fault (while the FPU registers are locked)
and therefore the operation might fail.
If it fails try the slowpath
The ia32_fxstate case (32bit with fxsr) and the other (64bit, 32bit
without fxsr) restore both from kernel memory and sanitize the content.
The !ia32_fxstate version restores missing xstates from "init state"
while the ia32_fxstate doesn't and skips it.
Merge the two code paths and keep the !ia32_
write_pkru() checks if the current value is the same as the expected
value. So instead just checking if the current and new value is zero
(and skip the write in such a case) we can benefit from that.
Remove the zero check of PKRU, write_pkru() provides a similar check.
Signed-off-by: Sebastian An
Start refactoring __fpu__restore_sig() by inlining
copy_user_to_fpregs_zeroing(). The orignal function remains and will be
used to restore from userland memory if possible.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/kernel/fpu/signal.c | 20 +++-
1 file changed, 19 ins
From: Rik van Riel
Defer loading of FPU state until return to userspace. This gives
the kernel the potential to skip loading FPU state for tasks that
stay in kernel mode, or for tasks that end up with repeated
invocations of kernel_fpu_begin() & kernel_fpu_end().
The __fpregs_changes_{begin|end}
From: Rik van Riel
The FPU registers need only to be saved if TIF_NEED_FPU_LOAD is not set.
Otherwise this has been already done and can be skipped.
Signed-off-by: Rik van Riel
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/kernel/fpu/signal.c | 12 +++-
1 file changed, 11 inse
During the context switch the xstate is loaded which also includes the
PKRU value.
If xstate is restored on return to userland it is required that the
PKRU value in xstate is the same as the one in the CPU.
Save the PKRU in xstate during modification.
Signed-off-by: Sebastian Andrzej Siewior
---
Add TIF_NEED_FPU_LOAD. This is reserved for loading the FPU registers
before returning to userland. This flag must not be set for systems
without a FPU.
If this flag is cleared, the CPU's FPU register hold the current content
of current()'s FPU register. The in-memory copy (union fpregs_state) is
n
From: Rik van Riel
copy_fpstate_to_sigframe() stores the registers directly to user space.
This is okay because the FPU register are valid and saving it directly
avoids saving it into kernel memory and making a copy.
However… We can't keep doing this if we are going to restore the FPU
registers o
Most users of __raw_xsave_addr() use a feature number, shift it to a
mask and then __raw_xsave_addr() shifts it back to the feature number.
Make __raw_xsave_addr() use the feature number as an argument.
Signed-off-by: Sebastian Andrzej Siewior
Reviewed-by: Borislav Petkov
---
arch/x86/kernel/f
Dave Hansen says that the `wrpkru' is more expensive than `rdpkru'. It
has a higher cycle cost and it's also practically a (light) speculation
barrier.
As an optimisation read the current PKRU value and only write the new
one if it is different.
Signed-off-by: Sebastian Andrzej Siewior
---
arch
Dave Hansen has asked for __read_pkru() and __write_pkru() to be symmetrical.
As part of the series __write_pkru() will read back the value and only write it
if it is different.
In order to make both functions symmetrical move the function containing only
the opcode into a function with _isn() suff
hi Will:
>
> [+Ard in case I'm missing something]
>
> On Mon, Apr 01, 2019 at 10:59:53PM +0800, pierre kuo wrote:
> > > > With CONFIG_RANDOMIZE_BASE we can get a further change to memstart_addr
> > > > after the place where you moved the initrd_{start,end} setting, which
> > > > would result in a d
The `initialized' member of the fpu struct is always set to one for user
tasks and zero for kernel tasks. This avoids saving/restoring the FPU
registers for kernel threads.
The ->initialized = 0 case for user tasks has been removed in previous changes
for instance by always an explicit init at for
user_fpu_begin() sets fpu_fpregs_owner_ctx to task's fpu struct. This is
always the case since there is no lazy FPU anymore.
fpu_fpregs_owner_ctx is used during context switch to decide if it needs
to load the saved registers or if the currently loaded registers are
valid. It could be skipped duri
On 4/3/19 9:34 AM, Eugeniy Paltsev wrote:
>> -reg = <0x8000 0x4000>; /* 1 GiB */
>> +reg = <0x0 0x8000 0x0 0x4000>; /* 1 GB lowmem */
>> +/* 0x1 0x 0x0 0x4000>; 1 GB highmem */
> Could you please get rid of comment with refer
With lazy-FPU support the (now named variable) ->initialized was set to true if
the CPU's FPU registers were holding the a valid state of the FPU registers for
the active process. If it was set to false then the FPU state was saved in
fpu->state and the FPU was deactivated.
With lazy-FPU gone, ->in
fpu__clear() only initializes the `state' if the FPU is present. This
initialisation is also required for the FPU-less system and takes place
in math_emulate(). Since fpu__initialize() only performs the
initialization if ->initialized is zero it does not matter that it is
invoked each time an opcod
This is a preparation for the removal of the ->initialized member in the
fpu struct.
__fpu__restore_sig() is deactivating the FPU via fpu__drop() and then
setting manually ->initialized followed by fpu__restore(). The result is
that it is possible to manipulate fpu->state and the state of registers
There are no users of fpu__restore() so it is time to remove it.
The comment regarding fpu__restore() and TS bit is stale since commit
b3b0870ef3ffe ("i387: do not preload FPU state at task switch time")
and has no meaning since.
Signed-off-by: Sebastian Andrzej Siewior
---
Documentation/preem
In commit
72a671ced66db ("x86, fpu: Unify signal handling code paths for x86 and x86_64
kernels")
the 32bit and 64bit path of the signal delivery code were merged. The 32bit
version:
|int save_i387_xstate_ia32(void __user *buf)
|…
| if (cpu_has_xsave)
| return save_i387_xs
The preempt_disable() section was introduced in commit
a10b6a16cdad8 ("x86/fpu: Make the fpu state change in fpu__clear()
scheduler-atomic")
and it was said to be temporary.
fpu__initialize() initializes the FPU struct to its "init" value and
then sets ->initialized to 1. The last part is the
Hi,
This series adds support for software fwnode reference handling. In
practice it means making fwnode_property_get_reference_args() function
usable in the drivers also with software nodes. I send the series
originally as RFC [1].
As the first user for the software node references, I'm convertin
Software nodes are not forced to have device properties.
Adding check to property_entries_dup() to make it possible
to create software nodes that don't have any properties.
Signed-off-by: Heikki Krogerus
---
drivers/base/swnode.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/bas
It's possible to release the node ID immediately when
fwnode_remove_software_node() is called, no need to wait for
software_node_release() with that. This change has no
functional effect.
Signed-off-by: Heikki Krogerus
---
drivers/base/swnode.c | 20 ++--
1 file changed, 10 inser
This is a refurbished series originally started by by Rik van Riel. The
goal is load the FPU registers on return to userland and not on every
context switch. By this optimisation we can:
- avoid loading the registers if the task stays in kernel and does
not return to userland
- make kernel_fpu_be
Introducing functions that can be used for adding and
removing references to other software nodes. The goal is to
support fwnode_property_get_reference_args() also with
software nodes, however, get_reference_args fwnode operation
callback is not yet implemented in this commit for the
software nodes
Supplying also external devices - the DisplayPort connector
and the USB role switch - software fwnodes. After this the
driver has access to all the components tied to the USB
Type-C connector and can start creating software node
references to actually associate them with the USB Type-C
connector de
Now that the software nodes support references, and the
device connection API support parsing fwnode references,
replacing the old connection descriptions with software node
references. Relying on device names when matching the
connection would not have been possible to link the USB
Type-C connecto
There is no reason why we should limit the use of
fwnode_get_named_child_node() to data nodes only.
Signed-off-by: Heikki Krogerus
---
drivers/acpi/property.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/property.c b/drivers/acpi/pr
In ACPI, and now also in DT, the USB connectors usually have
their own device nodes. In case of USB Type-C, those
connector (port) nodes are child nodes of the controller or
PHY device, in our case the fusb302. The software fwnodes
allow us to create a similar child node for fusb302 that
represents
Software nodes provide two features that we will need later.
1) Software nodes can have references to other software nodes.
2) Software nodes can exist before a device entry is created.
Signed-off-by: Heikki Krogerus
---
drivers/platform/x86/intel_cht_int33fe.c | 122 +--
1 f
This makes it possible to support drivers that use
fwnode_property_get_reference_args() function.
Signed-off-by: Heikki Krogerus
---
drivers/base/swnode.c | 56 +++
1 file changed, 56 insertions(+)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.
We can also use this API to find named references that the
device nodes have by using fwnode_property_get_reference_args()
function.
Signed-off-by: Heikki Krogerus
---
drivers/base/devcon.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/base/devcon.c b/
Registering real device entries (struct device) for the mode
muxes as well as for the orientation switches.
The Type-C mux code was deliberately attempting to avoid
creation of separate device entries for the orientation
switch and the mode switch (alternate modes) because they
are not physical de
On Tue, Apr 02, 2019 at 07:59:25AM -0700, Moritz Fischer wrote:
> Hi Wu,
>
> On Mon, Mar 25, 2019 at 11:07:41AM +0800, Wu Hao wrote:
> > This patch adds support to thermal management private feature for DFL
> > FPGA Management Engine (FME). As thermal throttling is handled by
> > hardware automati
Hi Richard,
On Wed, Apr 03, 2019 at 11:43:26AM -0500, Richard Gong wrote:
> Hi Moritz,
>
>
> On 4/3/19 9:20 AM, Moritz Fischer wrote:
> > Hi Richard,
> >
> > On Tue, Apr 02, 2019 at 05:25:43PM -0500, richard.g...@linux.intel.com
> > wrote:
> > > From: Richard Gong
> > >
> > > Add a log for u
Hi Jeremy,
On Thu, Mar 21, 2019 at 06:05:56PM -0500, Jeremy Linton wrote:
> Return status based on ssbd_state and the arm64 SSBS feature. If
> the mitigation is disabled, or the firmware isn't responding then
> return the expected machine state based on a new blacklist of known
> vulnerable cores.
Hi Oleg,
On Tue, Mar 19, 2019 at 06:32:33PM +0100, Oleg Nesterov wrote:
> On 03/19, Oleg Nesterov wrote:
> >
> > Well, personally I see no point... Again, after the trivial simplification
> > x86 does
> >
> > if (work & (_TIF_SYSCALL_EMU | _TIF_SYSCALL_TRACE)) {
> > ret = tracehook
美好的一天
我以万能的耶和华的名，向你们问候一切善行的人。良好的一天和季节的赞美，我知道这是真的，这封信可能会来到你一个惊喜。然而，我谦恭地要求你给我注意，并听到我很好，但我恳求你花时间仔细阅读这个消息，因为你做出的决定将有很长的路要确定我的未来存在。我是Julian
Worker夫人，一个58岁的寡妇，来自美国拉斯维加斯，与联合国合作;我患有肺癌，目前住院在布基纳法索普通医院。我有一些资金，我继承了我已故的丈夫，总和（USD
$
14.5百万美元），我需要一个非常诚实和神害怕谁可以提取这笔钱，然后使用的资金用于慈善工作。我想把这些基金给你的慈善工作。我发现你的电子邮件地址从互联网
On Tue, Apr 02, 2019 at 08:17:03PM -0700, Guenter Roeck wrote:
> On Tue, Apr 2, 2019 at 4:38 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Tue, Apr 2, 2019 at 4:19 PM Matthias Kaehlcke wrote:
> > >
> > > Hi Doug,
> > >
> > > On Tue, Apr 02, 2019 at 03:44:44PM -0700, Douglas Anderson wrote:
> > >
Hyper-V TLFS suggests an optimization to avoid imminent VMExit on EOI:
"The OS performs an EOI by atomically writing zero to the EOI Assist field
of the virtual VP assist page and checking whether the "No EOI required"
field was previously zero. If it was, the OS must write to the
HV_X64_APIC_EOI M
I know some of this was hashed out last night, but I wasn't reading my
email then to interject ;)
On Wed, Apr 3, 2019 at 9:05 AM Douglas Anderson wrote:
> +static int cros_ec_xfer_high_pri(struct cros_ec_device *ec_dev,
> +struct cros_ec_command *ec_msg,
> +
Hi Will,
On Wed, Apr 3, 2019 at 9:45 PM Will Deacon wrote:
>
> Hi Masahiro,
>
> On Wed, Apr 03, 2019 at 05:48:22PM +0900, Masahiro Yamada wrote:
> > - $(call if_changed,...) must have FORCE as a prerequisite
> >
> > - vdso.lds is a generated file, so it should be prefixed with
> > $(obj)/ inste
> On Apr 3, 2019, at 7:37 AM, Jiri Olsa wrote:
>
> hi,
> perf script --call-trace stop working for me recently,
> and displays only user space functions
>
> I bisected that to:
> 7b612e291a5a perf tools: Synthesize PERF_RECORD_* for loaded BPF programs
>
> data from following comands will d
> On Apr 2, 2019, at 6:37 AM, Peter Zijlstra wrote:
>
> On Fri, Mar 29, 2019 at 11:20:05AM -0400, Alex Kogan wrote:
>> @@ -25,6 +29,18 @@
>>
>> #define MCS_NODE(ptr) ((struct mcs_spinlock *)(ptr))
>>
>> +/* Per-CPU pseudo-random number seed */
>> +static DEFINE_PER_CPU(u32, seed);
>> +
>> +/*
Function sta2sta_data_frame() is only used in rtw_recv.c.
So make it static.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_recv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_recv.c
b/drivers/staging/rtl8188e
The declaration of sta2sta_data_frame() is directly above
the function definition. Remove the unnecessary declaration.
This also clears a checkpatch issue.
CHECK: Lines should not end with a '('
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_recv.c | 6 --
1 file chan
On 03/04/2019 at 18:22, Alexandre Belloni wrote:
> The X11 license text [1] is explicitly for the X Consortium and has a
> couple of extra clauses. The MIT license text [2] is actually what the
> current DT files claim.
>
> [1] https://spdx.org/licenses/X11.html
> [2] https://spdx.org/licenses/MIT
On Thu, Apr 04, 2019 at 02:04:23AM +0900, Masahiro Yamada wrote:
> On Wed, Apr 3, 2019 at 9:45 PM Will Deacon wrote:
> > On Wed, Apr 03, 2019 at 05:48:22PM +0900, Masahiro Yamada wrote:
> > > - $(call if_changed,...) must have FORCE as a prerequisite
> > >
> > > - vdso.lds is a generated file, so
On Wed, Apr 03, 2019 at 03:21:27PM +1100, Tobin C. Harding wrote:
> The dentry slab cache is susceptible to internal fragmentation. Now
> that we have Slab Movable Objects we can defragment the dcache. Object
> migration is only possible for dentry objects that are not currently
> referenced by a
On Wed, 2019-04-03 at 18:22 +0200, Alexandre Belloni wrote:
> The X11 license text [1] is explicitly for the X Consortium and has a
> couple of extra clauses. The MIT license text [2] is actually what the
> current DT files claim.
[]
> diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts
Hi all,
After a converstaion with Thomas a while back, it felt like the best way
forward here is just to resolve the pressing preemption violation, and
not make things more complicated by trying to manage theoretical races
within perf core from a distance.
Thus v2 simply nukes the offending logic
On Wed, Apr 3, 2019 at 6:40 PM Matteo Croce wrote:
>
> On Wed, Apr 3, 2019 at 5:51 PM Matthew Wilcox wrote:
> >
> > On Wed, Apr 03, 2019 at 05:24:26PM +0200, Matteo Croce wrote:
> > > On Wed, Apr 3, 2019 at 4:02 PM Christian Brauner
> > > wrote:
> > > > Yeah, maybe but it still feels cleaner an
Like arm-cci, arm-ccn has the same issue of disabling preemption around
operations which can take mutexes. Again, remove the definite bug by
simply not trying to fight the theoretical races. And since we are
touching the hotplug handling code, take the opportunity to streamline
it, as there's reall
Uncore PMU drivers face an awkward cyclic dependency wherein:
- They have to pick a valid online CPU to associate with before
registering the PMU device, since it will get exposed to userspace
immediately.
- The PMU registration has to be be at least partly complete before
hotplug event
On Thu, Mar 21, 2019 at 03:29:19PM +0530, Kishon Vijay Abraham I wrote:
> This series tries to address the comments discussed in [1] w.r.t
> removing Keystone specific callbacks defined in dw_pcie_host_ops.
>
> This series also tries to cleanup the Keystone interrupt handling
> part.
>
> Changes
Dear Robin,
I have made additional tests on another exemplar of board with
absolutely same hardware.
The spidev_test failed on eCSPI2 and eCSPI5 interfaces, but works
successfully on eCSPI1 interface.
So, it looks, issue does not correspond to fixed interface number.
This is generic issue
> On Apr 1, 2019, at 5:09 AM, Peter Zijlstra wrote:
>
> On Fri, Mar 29, 2019 at 11:20:01AM -0400, Alex Kogan wrote:
>> The following locktorture results are from an Oracle X5-4 server
>> (four Intel Xeon E7-8895 v3 @ 2.60GHz sockets with 18 hyperthreaded
>> cores each).
>
> The other interest
On Wed, Apr 03, 2019 at 12:33:20PM -0400, Waiman Long wrote:
> static inline void queued_spin_lock_slowpath(struct qspinlock *lock, u32
> val)
> {
> if (static_branch_unlikely(&use_numa_spinlock))
> numa_queued_spin_lock_slowpath(lock, val);
> else
>
On Mon, 25 Mar 2019 11:20:47 -0500
Tom Zanussi wrote:
> > Is it OK if I add the following tags to that patch?
> >
> > Reported-by: Tom Zanussi
> > Tested-by: Tom Zanussi
> >
>
> Yep, fine with me.
I modified the patch slightly. Can you test this too. There should be
no reason that it wont
On Thu, Mar 21, 2019 at 03:29:27PM +0530, Kishon Vijay Abraham I wrote:
> Platforms which populate msi_host_init, has it's own MSI controller
> logic. Writing to MSI control registers on platforms which doesn't use
> Designware's MSI controller logic might have side effects. To
> be safe, do not wr
On Wed, Apr 03, 2019 at 06:08:11PM +0100, Al Viro wrote:
> Oh, *brilliant*
>
> Let's do d_invalidate() on random dentries and hope they go away.
> With convoluted and brittle logics for deciding which ones to
> spare, which is actually wrong. This will pick mountpoints
> and tear them out, to st
On Wed, Apr 03, 2019 at 03:21:22PM +1100, Tobin C. Harding wrote:
> +void xa_object_migrate(struct xa_node *node, int numa_node)
> +{
> + struct xarray *xa = READ_ONCE(node->array);
> + void __rcu **slot;
> + struct xa_node *new_node;
> + int i;
> +
> + /* Freed or not yet in tr
Hi Christian,
On Wed, Apr 03, 2019 at 05:40:45PM +0200, Christian Brauner wrote:
> On Wed, Apr 03, 2019 at 04:34:09PM +0100, Will Deacon wrote:
> > Commit 32a5ad9c2285 ("sysctl: handle overflow for file-max") hooked
> > up min/max values for the file-max sysctl parameter via the .extra1
> > and .e
On Thu, Apr 04, 2019 at 12:44:25AM +0800, pierre kuo wrote:
> > On Mon, Apr 01, 2019 at 10:59:53PM +0800, pierre kuo wrote:
> > > > > With CONFIG_RANDOMIZE_BASE we can get a further change to
> > > > > memstart_addr
> > > > > after the place where you moved the initrd_{start,end} setting, which
>
On 4/3/19 10:24 AM, Will Deacon wrote:
> On Thu, Apr 04, 2019 at 12:44:25AM +0800, pierre kuo wrote:
>>> On Mon, Apr 01, 2019 at 10:59:53PM +0800, pierre kuo wrote:
>> With CONFIG_RANDOMIZE_BASE we can get a further change to memstart_addr
>> after the place where you moved the initrd_{star
Hi Nick,
Thank you for the patch.
I have one comment for the kbd_led_backlight.c
On 4/3/19 4:05 AM, Nick Crews wrote:
The EC is in charge of controlling the keyboard backlight on
the Wilco platform. We expose a standard LED class device at
/sys/class/leds/chromeos::kbd_backlight. This driver i
On Wed, Apr 03, 2019 at 08:48:02AM -0700, Bart Van Assche wrote:
> On Wed, 2019-04-03 at 13:44 +0100, Will Deacon wrote:
> > On Tue, Mar 26, 2019 at 12:59:12PM -0700, Bart Van Assche wrote:
> > > Commit a0b0fd53e1e6 ("locking/lockdep: Free lock classes that are no
> > > longer
> > > in use") chang
On 2019-04-02 10:30 p.m., Anshuman Khandual wrote:
> Memory removal from an arch perspective involves tearing down two different
> kernel based mappings i.e vmemmap and linear while releasing related page
> table pages allocated for the physical memory range to be removed.
>
> Define a common k
On Wed, Apr 03, 2019 at 03:13:09PM +0530, Vidya Sagar wrote:
> On 4/3/2019 12:01 AM, Bjorn Helgaas wrote:
> > On Tue, Apr 02, 2019 at 12:47:48PM +0530, Vidya Sagar wrote:
> > > On 3/30/2019 2:22 AM, Bjorn Helgaas wrote:
> > > > On Tue, Mar 26, 2019 at 08:43:26PM +0530, Vidya Sagar wrote:
> > > > >
On Wed, Apr 3, 2019 at 9:36 PM Thierry Reding wrote:
>
> On Wed, Apr 03, 2019 at 04:11:09PM +0200, Alexandre Belloni wrote:
> > Move linux/atmel_tc.h to the SoC specific folder include/soc/at91.
> >
> > Cc: Thierry Reding
> > Signed-off-by: Alexandre Belloni
>
> Acked-by: Thierry Reding
Acked
On 04/03/2019 01:16 PM, Peter Zijlstra wrote:
> On Wed, Apr 03, 2019 at 12:33:20PM -0400, Waiman Long wrote:
>> static inline void queued_spin_lock_slowpath(struct qspinlock *lock, u32
>> val)
>> {
>> if (static_branch_unlikely(&use_numa_spinlock))
>> numa_queued_spin_lock_s
On Thu, Mar 28, 2019 at 6:03 AM Matteo Croce wrote:
>
> fs.file-max sysctl uses proc_doulongvec_minmax() as proc handler, which
> accesses *extra1 and *extra2 as unsigned long, but commit 32a5ad9c2285
> ("sysctl: handle overflow for file-max") assigns &zero, which is an int,
> to extra1, generatin
On 4/3/19 9:57 AM, Lee Jones wrote:
On Mon, 25 Mar 2019, Jacek Anaszewski wrote:
On 3/25/19 8:53 AM, Lee Jones wrote:
On Sat, 23 Mar 2019, Jacek Anaszewski wrote:
Hi Lee,
Can we have your ack for this going via LED tree, please?
Patch looks okay.
You can take it through the LED, but if y
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core/objtool
head: 64604d54d3115fee89598bfb6d8d2252f8a2d114
commit: 37686b1353cfc30e127cef811959cdbcd0495d98 [2/25] tracing: Improve "if"
macro code generation
config: x86_64-randconfig-e2-03311307 (attached as .config)
compiler
Hi,
On Wed, Apr 3, 2019 at 10:04 AM Brian Norris wrote:
>
> I know some of this was hashed out last night, but I wasn't reading my
> email then to interject ;)
>
> On Wed, Apr 3, 2019 at 9:05 AM Douglas Anderson wrote:
> > +static int cros_ec_xfer_high_pri(struct cros_ec_device *ec_dev,
> > +
On Wed, Apr 03, 2019 at 06:19:21PM +0100, Al Viro wrote:
> On Wed, Apr 03, 2019 at 06:08:11PM +0100, Al Viro wrote:
>
> > Oh, *brilliant*
> >
> > Let's do d_invalidate() on random dentries and hope they go away.
> > With convoluted and brittle logics for deciding which ones to
> > spare, which is
Hello Dmitry,
I may have found a potential bug in the "gpio_keys" driver. FYI, I am running
the 4.14 LTS kernel on my system, but from my understanding of the issue, it
seems that this would still occur in the latest version of the kernel.
The problem:
In the 4.14 LTS kernel, both key press and
On Thu, Feb 21, 2019 at 09:37:38AM -0600, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct f
On Tue, Apr 02, 2019 at 07:13:52PM +, Winkler, Tomas wrote:
>
>
> > On Tue, Apr 02, 2019 at 02:46:25AM +0300, Jarkko Sakkinen wrote:
> > > On Mon, Apr 01, 2019 at 12:06:07PM -0700, Kees Cook wrote:
> > > > A "get random" may fail with a TPM error, but those codes were
> > > > returned as-is t
On Wed, Apr 3, 2019 at 10:49 AM Doug Anderson wrote:
> On Wed, Apr 3, 2019 at 10:04 AM Brian Norris wrote:
> > Does anybody know what the definition of "too long" is for the phrase
> > "Don't queue works which can run for too long" in the documentation?
...
> So I think the summary is that I'm ba
Understanding why of_phandle_iterator_next() returns an error can
sometimes be hard to decipher based solely on the error message, a
typical error example is that #foo-cells = and the phandle property
used has a smaller number of cells specified, e.g.:
#thermal-sensor-cells = <1>;
On Wed, Apr 03, 2019 at 10:46:01AM -0700, Daniel Colascione wrote:
> On Wed, Apr 3, 2019 at 10:20 AM Joel Fernandes wrote:
> >
> > On Wed, Apr 03, 2019 at 04:48:37PM +0900, Masahiro Yamada wrote:
> > > On Thu, Mar 28, 2019 at 2:32 AM Joel Fernandes
> > > wrote:
> > > >
> > > > On Mon, Mar 25, 20
On Wed, 3 Apr 2019, Al Viro wrote:
> Let's do d_invalidate() on random dentries and hope they go away.
> With convoluted and brittle logics for deciding which ones to
> spare, which is actually wrong. This will pick mountpoints
> and tear them out, to start with.
>
> NAKed-by: Al Viro
>
> And th
On 03/04/2019 18:32, Logan Gunthorpe wrote:
On 2019-04-02 10:30 p.m., Anshuman Khandual wrote:
Memory removal from an arch perspective involves tearing down two different
kernel based mappings i.e vmemmap and linear while releasing related page
table pages allocated for the physical memory ran
On Wed, Apr 03, 2019 at 10:05:39AM +1100, Tobin C. Harding wrote:
> Currently if we wish to rotate a list until a specific item is at the
> front of the list we can call list_move_tail(head, list). Note that the
> arguments are the reverse way to the usual use of list_move_tail(list,
> head). Thi
On Wed, Apr 03, 2019 at 10:05:40AM +1100, Tobin C. Harding wrote:
> Currently we reach inside the list_head. This is a violation of the
> layer of abstraction provided by the list_head. It makes the code
> fragile. More importantly it makes the code wicked hard to understand.
>
> The code reach
* Tony Lindgren [190325 22:00]:
> Let's also add error handling to shut down already enabled clocks
> while at it.
...
> --- a/drivers/bus/ti-sysc.c
> +++ b/drivers/bus/ti-sysc.c
> +err_disable:
> + for (; i >= 0; i--) {
> + clock = ddata->clocks[i];
> +
> + /* Main cl
Please pull the following changes since commit
5e7a8ca319268a70a6c7c3c1fde5bea38e1e5539:
Merge branch 'work.aio' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2019-04-01
08:28:36 -0700)
are available in the Git repository at:
git://git.samba.org/sfrench/cifs-2.6.git tags/5.1-rc3
On Wed, Apr 3, 2019 at 11:47 AM Moritz Fischer wrote:
>
> Hi Richard,
>
> On Wed, Apr 03, 2019 at 11:43:26AM -0500, Richard Gong wrote:
> > Hi Moritz,
> >
> >
> > On 4/3/19 9:20 AM, Moritz Fischer wrote:
> > > Hi Richard,
> > >
> > > On Tue, Apr 02, 2019 at 05:25:43PM -0500, richard.g...@linux.int
Hi Hao,
On Thu, Apr 04, 2019 at 12:31:47AM +0800, Wu Hao wrote:
> On Tue, Apr 02, 2019 at 07:59:25AM -0700, Moritz Fischer wrote:
> > Hi Wu,
> >
> > On Mon, Mar 25, 2019 at 11:07:41AM +0800, Wu Hao wrote:
> > > This patch adds support to thermal management private feature for DFL
> > > FPGA Manag
On Tue, Apr 2, 2019 at 9:30 PM Anshuman Khandual
wrote:
>
> This series enables memory hot remove on arm64, fixes a memblock removal
> ordering problem in generic __remove_memory(), enables sysfs memory probe
> interface on arm64. It also enables ZONE_DEVICE with struct vmem_altmap
> support.
>
>
On Wed, Apr 03, 2019 at 05:05:02PM +, Song Liu wrote:
>
>
> > On Apr 3, 2019, at 7:37 AM, Jiri Olsa wrote:
> >
> > hi,
> > perf script --call-trace stop working for me recently,
> > and displays only user space functions
> >
> > I bisected that to:
> > 7b612e291a5a perf tools: Synthesize
Hi,
On Wed, Apr 03, 2019 at 04:33:15AM +0100, Mark Rutland wrote:
> On Mon, Apr 01, 2019 at 09:14:43PM +0300, Aaro Koskinen wrote:
> > From: Aaro Koskinen
> >
> > Add support for warm reset using SYSTEM_RESET2 introduced in PSCI
> > 1.1 specification.
>
> For reference, how do you intend to use
On Wed, Apr 03, 2019 at 10:04:16AM -0700, Brian Norris wrote:
> I know some of this was hashed out last night, but I wasn't reading my
> email then to interject ;)
>
> On Wed, Apr 3, 2019 at 9:05 AM Douglas Anderson wrote:
> > +static int cros_ec_xfer_high_pri(struct cros_ec_device *ec_dev,
> > +
On Tue, Apr 02, 2019 at 03:33:15PM -0400, Sasha Levin wrote:
> Signed-off-by: Sasha Levin
> ---
Acked-by: Jarkko Sakkinen
/Jarkko
Hi Ken,
On Wed, Apr 03, 2019 at 05:50:09PM +, Ken Sloat wrote:
> Hello Dmitry,
>
> I may have found a potential bug in the "gpio_keys" driver. FYI, I am
> running the 4.14 LTS kernel on my system, but from my understanding of
> the issue, it seems that this would still occur in the latest ver
Hi,
On Wed, Apr 3, 2019 at 11:14 AM Matthias Kaehlcke wrote:
> Each transfer has it's own work struct (allocated on the stack), hence
> a) does not occur. b) is still true, but shouldn't be a problem on
> its own.
Actually, it could be much worse _because_ it's on the stack. The
worker could wr
501 - 600 of 957 matches
Mail list logo
