Re: [PATCH] PCI: Allow PCI express root ports to find themselves

From: Thierry Reding Date: Thu, 17 Aug 2017 13:06:14 +0200 > From: Thierry Reding > > If the pci_find_pcie_root_port() function is called on a root port > itself, return the root port rather than NULL. > > This effectively reverts commit 0e405232871d6 ("PCI: fix oops when > try to find Root Po

Re: [PATCH] arm64: dts: rockchip: Assign mic irq to correct device for Gru

Am Mittwoch, 16. August 2017, 17:24:32 CEST schrieb Jeffy Chen: > Currently we are assigning mic irq to rt5514 i2c driver, which is wrong. > Assign it to rt5514 spi driver instead. > > Signed-off-by: Jeffy Chen applied for 4.14 Thanks Heiko

Re: [RFC PATCH] mm: fadvise: avoid fadvise for fs without backing device

On Fri, Aug 18, 2017 at 2:34 PM, Andrew Morton wrote: > On Thu, 17 Aug 2017 18:20:17 -0700 Shakeel Butt wrote: > >> +linux-mm, linux-kernel >> >> On Thu, Aug 17, 2017 at 6:10 PM, Shakeel Butt wrote: >> > The fadvise() manpage is silent on fadvise()'s effect on >> > memory-based filesystems (shme

[PATCH v4] ACPI / sysfs: Extend ACPI sysfs to provide access to boot error region

From: Tony Luck The ACPI sysfs interface provides a way to read each ACPI table from userspace via entries in /sys/firmware/acpi/tables/ The BERT table simply provides the size and address of the error record in BIOS reserved memory and users may want access to this record. In an earlier age we

Re: [PATCH] irda: do not leak initialized list.dev to userspace

From: Colin King Date: Thu, 17 Aug 2017 23:14:58 +0100 > From: Colin Ian King > > list.dev has not been initialized and so the copy_to_user is copying > data from the stack back to user space which is a potential > information leak. Fix this ensuring all of list is initialized to > zero. > > D

[RFC][PATCH] kselftests: timers: leap-a-day: Change default arguments to help test runs

Change default arguments for leap-a-day to always set the time each iteration (rather then waiting for midnight UTC), and to only run 10 interations (rather then infinite). If one wants to wait for midnight UTC, they can use the new -w flag, and we add a note to the argument help that -i -1 will r

Re: [PATCH net] rxrpc: Fix oops when discarding a preallocated service call

From: David Howells Date: Fri, 18 Aug 2017 00:19:42 +0100 > rxrpc_service_prealloc_one() doesn't set the socket pointer on any new call > it preallocates, but does add it to the rxrpc net namespace call list. > This, however, causes rxrpc_put_call() to oops when the call is discarded > when the s

Re: [PATCH] platform/x86: intel_pmc_core: Add Package C-states residency info

Hello, On Fri, Aug 18, 2017 at 10:47 AM, Rajneesh Bhardwaj wrote: > On Fri, Aug 18, 2017 at 08:17:32PM +0300, Andy Shevchenko wrote: >> +PeterZ (since I mentioned his name) >> >> On Fri, Aug 18, 2017 at 5:58 PM, Rajneesh Bhardwaj >> wrote: >> > On Fri, Aug 18, 2017 at 03:57:34PM +0300, Andy Shev

[PATCH] net: ibm: emac: Fix some error handling path in 'emac_probe()'

If 'irq_of_parse_and_map()' or 'of_address_to_resource()' fail, 'err' is known to be 0 at this point. So return -ENODEV instead in the first case and propagate the error returned by 'of_address_to_resource()' in the 2nd case. While at it, turn a 'err != 0' test into an equivalent 'err' to be more

Re: [PATCH] mlx5: ensure 0 is returned when vport is zero

From: Colin King Date: Fri, 18 Aug 2017 14:49:25 +0100 > From: Colin Ian King > > Currently, if vport is zero then then an uninialized return status > in err is returned. Since the only return status at the end of the > function esw_add_uc_addr is zero for the current set of return paths > we

Re: Urgent

German *** Brauchen Sie ein dringendes Darlehen oder Hilfe? Wenn ja, schreiben Sie uns bitte mit Ihrem Namen, Betrag, Dauer, Telefonnummer zurück. Dutch * Heb je een dringende lening of hulp nodig? Zo ja, schrijf ons terug met uw naam, bedrag, duur, telefoonnummer. English *** Do

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 8/18/17 7:16 AM, Edward Cree wrote: On 18/08/17 04:21, Alexei Starovoitov wrote: On 8/15/17 12:34 PM, Edward Cree wrote: State of a register doesn't matter if it wasn't read in reaching an exit; a write screens off all reads downstream of it from all explored_states upstream of it. This al

[PATCH 3/3] MIPS,bpf: Cache value of BPF_OP(insn->code) in eBPF JIT.

The code looks a little cleaner if we replace BPF_OP(insn->code) with the local variable bpf_op. Caching the value this way also saves 300 bytes (about 1%) in the code size of the JIT. Signed-off-by: David Daney --- arch/mips/net/ebpf_jit.c | 67

[PATCH 0/3] MIPS,bpf: Improvements for MIPS eBPF JIT

Here are several improvements and bug fixes for the MIPS eBPF JIT. The main change is the addition of support for JLT, JLE, JSLT and JSLE ops, that were recently added. Also fix WARN output when used with preemptable kernel, and a small cleanup/optimization in the use of BPF_OP(insn->code). I su

[PATCH 1/3] MIPS,bpf: Fix using smp_processor_id() in preemptible splat.

If the kernel is configured with preemption enabled we were getting warning stack traces for use of current_cpu_type(). Fix by moving the test between preempt_disable()/preempt_enable() and caching the results of the CPU type tests for use during code generation. Signed-off-by: David Daney ---

[PATCH 2/3] MIPS,bpf: Implement JLT, JLE, JSLT and JSLE ops in the eBPF JIT.

Signed-off-by: David Daney --- arch/mips/net/ebpf_jit.c | 101 +-- 1 file changed, 72 insertions(+), 29 deletions(-) diff --git a/arch/mips/net/ebpf_jit.c b/arch/mips/net/ebpf_jit.c index 721216b..c1e21cb 100644 --- a/arch/mips/net/ebpf_jit.c +++ b/arc

Re: [PATCH v8 09/14] lockdep: Apply crossrelease to completions

Hi Arnd, On Mon, Aug 14, 2017 at 10:50:24AM +0200, Arnd Bergmann wrote: > On Mon, Aug 7, 2017 at 9:12 AM, Byungchul Park wrote: > > Although wait_for_completion() and its family can cause deadlock, the > > lock correctness validator could not be applied to them until now, > > because things like

[PATCH v2] sched/fair: Make PELT signal more accurate

The PELT signal (sa->load_avg and sa->util_avg) are not updated if the amount accumulated during a single update doesn't cross a period boundary. This is fine in cases where the amount accrued is much smaller than the size of a single PELT window (1ms) however if the amount accrued is high then the

Re: [PATCH] Input: elan_i2c - Support two physical button touchapd for elan_i2c

On Fri, Aug 18, 2017 at 05:47:16PM +0800, KT Liao wrote: > Extend information accessing to get button setting information > and support L/R button-pad for I2C touchpad > > Signed-off-by: KT Liao Applied, thank you. > --- > drivers/input/mouse/elan_i2c.h | 2 +- > drivers/input/mouse/ela

Re: [PATCH] staging: lustre: fix structure size for ARM OABI

On Aug 17, 2017, at 10:26, Greg KH wrote: > > On Wed, Aug 16, 2017 at 05:44:15PM +0300, Cihangir Akturk wrote: >> When building the kernel for the ARM architecture without setting >> CONFIG_AEABI, size of struct lov_user_md_v3 and struct lov_mds_md_v3 >> differs, due to different alignment requir

Re: [PATCH] Input: elan_i2c - Add antoher Lenovo ACPI ID for Yoga310 Add ELAN0602 in ACPI mapping table to support Yoga310's ELAN touchpad Signed-off-by: KT Liao

On Thu, Jul 27, 2017 at 08:57:23PM +0800, KT Liao wrote: > --- Applied, thank you. > drivers/input/mouse/elan_i2c_core.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/input/mouse/elan_i2c_core.c > b/drivers/input/mouse/elan_i2c_core.c > index 3b616cb..88fc0f8 100644 > --- a/

Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

On Fri, 2017-08-18 at 11:15 -0700, Andrew Morton wrote: > On Fri, 18 Aug 2017 12:28:29 -0400 Rik van Riel > wrote: > > > On Thu, 2017-08-17 at 15:50 -0700, Andrew Morton wrote: > > > On Tue, 15 Aug 2017 22:18:19 -0400 Rik van Riel > > > wrote: > > > > > > > > > --- a/mm/madvise.c > > > > > > ++

Re: [PATCH] iio: accel: mma8452: Bugfix to enbale and allow different events to work parallely.

This patch fixes by detaching the event related information from chip_info struct, and based on channel type and event direction the corresponding event configuration registers are picked dynamically. Hence multiple events can be handled in read/write callbacks. which chip can have which even

[PATCH v8 10/28] x86/insn-eval: Add a utility function to get register offsets

The function get_reg_offset() returns the offset to the register the argument specifies as indicated in an enumeration of type offset. Callers of this function would need the definition of such enumeration. This is not needed. Instead, add helper functions for this purpose. These functions are usef

[PATCH v8 17/28] x86/insn-eval: Incorporate segment base in linear address computation

insn_get_addr_ref() returns the effective address as defined by the section 3.7.5.1 Vol 1 of the Intel 64 and IA-32 Architectures Software Developer's Manual. In order to compute the linear address, we must add to the effective address the segment base address as set in the segment descriptor. The

[PATCH v8 18/28] x86/insn-eval: Add support to resolve 32-bit address encodings

32-bit and 64-bit address encodings are identical. Thus, the same logic could be used to resolve the effective address. However, there are two key differences: address size and enforcement of segment limits. If running a 32-bit process on a 64-bit kernel, it is best to perform the address calculat

[PATCH v8 08/28] x86/mpx, x86/insn: Relocate insn util functions to a new insn-eval file

Other kernel submodules can benefit from using the utility functions defined in mpx.c to obtain the addresses and values of operands contained in the general purpose registers. An instance of this is the emulation code used for instructions protected by the Intel User-Mode Instruction Prevention fe

[PATCH v8 11/28] x86/insn-eval: Add utility function to identify string instructions

String instructions are special because, in protected mode, the linear address is always obtained via the ES segment register in operands that use the (E)DI register; the DS segment register in operands that use the (E)SI register. Furthermore, segment override prefixes are ignored when calculating

[PATCH v8 27/28] selftests/x86: Add tests for User-Mode Instruction Prevention

Certain user space programs that run on virtual-8086 mode may utilize instructions protected by the User-Mode Instruction Prevention (UMIP) security feature present in new Intel processors: SGDT, SIDT and SMSW. In such a case, a general protection fault is issued if UMIP is enabled. When such a fau

[PATCH v8 28/28] selftests/x86: Add tests for instruction str and sldt

The instructions str and sldt are not recognized when running on virtual- 8086 mode and generate an invalid operand exception. These two instructions are protected by the Intel User-Mode Instruction Prevention (UMIP) security feature. In protected mode, if UMIP is enabled, these instructions genera

[PATCH v8 26/28] x86/traps: Fixup general protection faults caused by UMIP

If the User-Mode Instruction Prevention CPU feature is available and enabled, a general protection fault will be issued if the instructions sgdt, sldt, sidt, str or smsw are executed from user-mode context (CPL > 0). If the fault was caused by any of the instructions protected by UMIP, fixup_umip_e

[PATCH v8 25/28] x86: Enable User-Mode Instruction Prevention

User-Mode Instruction Prevention (UMIP) is enabled by setting/clearing a bit in %cr4. It makes sense to enable UMIP at some point while booting, before user spaces come up. Like SMAP and SMEP, is not critical to have it enabled very early during boot. This is because UMIP is relevant only when the

[PATCH v8 09/28] x86/insn-eval: Do not BUG on invalid register type

We are not in a critical failure path. The invalid register type is caused when trying to decode invalid instruction bytes from a user-space program. Thus, simply print an error message. To prevent this warning from being abused from user space programs, use the rate-limited variant of pr_err(). C

[PATCH v8 23/28] x86: Add emulation code for UMIP instructions

The feature User-Mode Instruction Prevention present in recent Intel processor prevents a group of instructions (sgdt, sidt, sldt, smsw, and str) from being executed with CPL > 0. Otherwise, a general protection fault is issued. Rather than relaying to the user space the general protection fault c

[PATCH v8 22/28] x86/cpufeature: Add User-Mode Instruction Prevention definitions

User-Mode Instruction Prevention is a security feature present in new Intel processors that, when set, prevents the execution of a subset of instructions if such instructions are executed in user mode (CPL > 0). Attempting to execute such instructions causes a general protection exception. The sub

[PATCH v8 24/28] x86/umip: Force a page fault when unable to copy emulated result to user

fixup_umip_exception() will be called from do_general_protection(). If the former returns false, the latter will issue a SIGSEGV with SEND_SIG_PRIV. However, when emulation is successful but the emulated result cannot be copied to user space memory, it is more accurate to issue a SIGSEGV with SEGV_

[PATCH v8 05/28] x86/mpx: Use signed variables to compute effective addresses

Even though memory addresses are unsigned, the operands used to compute the effective address do have a sign. This is true for ModRM.rm, SIB.base, SIB.index as well as the displacement bytes. Thus, signed variables shall be used when computing the effective address from these operands. Once the sig

[PATCH v8 20/28] x86/insn-eval: Handle 32-bit address encodings in virtual-8086 mode

It is possible to utilize 32-bit address encodings in virtual-8086 mode via an address override instruction prefix. However, the range of the effective address is still limited to [0x-0x]. In such a case, return error. Also, linear addresses in virtual-8086 mode are limited to 20 bits. Enforce

[PATCH v8 21/28] x86/insn-eval: Add support to resolve 16-bit addressing encodings

Tasks running in virtual-8086 mode, in protected mode with code segment descriptors that specify 16-bit default address sizes via the D bit, or via an address override prefix will use 16-bit addressing form encodings as described in the Intel 64 and IA-32 Architecture Software Developer's Manual Vo

[PATCH v8 19/28] x86/insn-eval: Add wrapper function for 32 and 64-bit addresses

The function insn_get_addr_ref() is capable of handling only 64-bit addresses. A previous commit introduced a function to handle 32-bit addresses. Invoke these two functions from a third wrapper function that calls the appropriate routine based on the address size specified in the instruction struc

[PATCH v8 04/28] uprobes/x86: Use existing definitions for segment override prefixes

Rather than using hard-coded values of the segment override prefixes, leverage the existing definitions provided in inat.h. Suggested-by: Borislav Petkov Cc: Andy Lutomirski Cc: Andrew Morton Cc: Borislav Petkov Cc: Masami Hiramatsu Cc: Denys Vlasenko Cc: Srikar Dronamraju Cc: Ravi V. Shank

[PATCH v8 16/28] x86/insn-eval: Indicate a 32-bit displacement if ModRM.mod is 0 and ModRM.rm is 101b

Section 2.2.1.3 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when ModRM.mod is zero and ModRM.rm is 101b, a 32-bit displacement follows the ModRM byte. This means that none of the registers are used in the computation of the effective address. A return v

[PATCH v8 14/28] x86/insn-eval: Add utility functions to get segment descriptor base address and limit

With segmentation, the base address of the segment is needed to compute a linear address. This base address is obtained from the applicable segment descriptor. Such segment descriptor is referenced from a segment selector. The segment selector is stored in the segment register associated with opera

[PATCH v8 13/28] x86/insn-eval: Add utility function to get segment descriptor

The segment descriptor contains information that is relevant to how linear addresses need to be computed. It contains the default size of addresses as well as the base address of the segment. Thus, given a segment selector, we ought look at segment descriptor to correctly calculate the linear addre

[PATCH v8 15/28] x86/insn-eval: Add function to get default params of code segment

Obtain the default values of the address and operand sizes as specified in the D and L bits of the the segment descriptor selected by the register CS. The function can be used for both protected and long modes. For virtual-8086 mode, the default address and operand sizes are always 2 bytes. The re

[PATCH v8 12/28] x86/insn-eval: Add utility functions to get segment selector

When computing a linear address and segmentation is used, we need to know the base address of the segment involved in the computation. In most of the cases, the segment base address will be zero as in USER_DS/USER32_DS. However, it may be possible that a user space program defines its own segments

[PATCH v8 03/28] ptrace,x86: Make user_64bit_mode() available to 32-bit builds

In its current form, user_64bit_mode() can only be used when CONFIG_X86_64 is selected. This implies that code built with CONFIG_X86_64=n cannot use it. If a piece of code needs to be built for both CONFIG_X86_64=y and CONFIG_X86_64=n and wants to use this function, it needs to wrap it in an #ifdef

[PATCH v8 00/28] x86: Enable User-Mode Instruction Prevention

This is v8 of this series. The seven previous submissions can be found here [1], here [2], here[3], here[4], here[5], here[6] and here[7]. This version addresses the feedback comments from Borislav Petkov received on v7. Please see details in the change log. === What is UMIP? User-Mode Instructio

[PATCH v8 02/28] x86/boot: Relocate definition of the initial state of CR0

Both head_32.S and head_64.S utilize the same value to initialize the control register CR0. Also, other parts of the kernel might want to access to this initial definition (e.g., emulation code for User-Mode Instruction Prevention uses this state to provide a sane dummy value for CR0 when emulating

[PATCH v8 07/28] x86/mpx: Do not use SIB.base if its value is 101b and ModRM.mod = 0

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that if a SIB byte is used and SIB.base is 101b and ModRM.mod is zero, then the base part of the base part of the effective address computation is null. To signal this situation, a -EDOM error is re

[PATCH v8 06/28] x86/mpx: Do not use SIB.index if its value is 100b and ModRM.mod is not 11b

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when ModRM.mod !=11b and ModRM.rm = 100b indexed register-indirect addressing is used. In other words, a SIB byte follows the ModRM byte. In the specific case of SIB.index = 100b, the scale*ind

[PATCH v8 01/28] x86/mm: Relocate page fault error codes to traps.h

Up to this point, only fault.c used the definitions of the page fault error codes. Thus, it made sense to keep them within such file. Other portions of code might be interested in those definitions too. For instance, the User- Mode Instruction Prevention emulation code will use such definitions to

Re: [PATCH] selftests: timers: Fix run_destructive_tests target to handle skipped tests

On Thu, Aug 17, 2017 at 3:48 PM, Shuah Khan wrote: > When a test exits with skip exit code of 4, "make run_destructive_tests" > halts testing. Fix run_destructive_tests target to handle error exit codes. > > Reported-by: John Stultz > Signed-off-by: Shuah Khan > --- > tools/testing/selftests/ti

Re: [GIT PULL] apparmor updates for next

On Fri, 18 Aug 2017, John Johansen wrote: > Hi James, > > Please pull these apparmor changes for next. > Pulled, thanks. -- James Morris

Re: [PATCH 1/2] iommu/amd: Fix compiler warning in copy_device_table()

On 08/19/17 at 12:40am, Joerg Roedel wrote: > From: Joerg Roedel > > This was reported by the kbuild bot. The condition in which > entry would be used uninitialized can not happen, because > when there is no iommu this function would never be called. > But its no fast-path, so fix the warning any

Re: [PATCH 0/3] MIPS,bpf: Improvements for MIPS eBPF JIT

On 08/19/2017 01:40 AM, David Daney wrote: Here are several improvements and bug fixes for the MIPS eBPF JIT. The main change is the addition of support for JLT, JLE, JSLT and JSLE ops, that were recently added. Also fix WARN output when used with preemptable kernel, and a small cleanup/optimiz

Re: [PATCH v9 2/2] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

On 08/18/17 at 04:10pm, Ard Biesheuvel wrote: > On 17 August 2017 at 14:04, Baoquan He wrote: > > Thanks a lot for helping improving the patch log, Ingo! Will pay more > > attention to the description in words and paragraph partition of log. > > > >> > >> So if EFI is detected, iterate EFI memory

Re: [patch v3 2/3] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver

-core-driver/20170818-114739 config: um-allyesconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=um All errors (new ones prefixed by >>): arch/um/drivers/vde.o: In fu

[PATCH] serial: earlycon: Only try fdt when specify 'earlycon' exactly

When moving earlycon early_param handling to serial, the devicetree earlycons enable condition changed slightly. We used to only do that for 'console'/'earlycon', but now would also for 'console='/'earlycon='. Fix it by using the same condition like before. Fixes: d503187b6cc4 (of/serial: move e

[PATCH] iio: accel: mma8452: code improvements to handle more than one event

This driver supports multiple devices like mma8653, mma8652, mma8452, mma8453 and fxls8471. Almost all these devices have more than one event. Current driver design hardcodes the event specific information, so only one event can be supported by this driver and current design doesn't have the fle

Re: [PATCH] dts: Make it easier to enable __symbols__ generation in dtb files

On Wed, Aug 16, 2017 at 11:32:08PM -0700, Frank Rowand wrote: > Hi Tom, > > Some nit picking on the patch comment. :-) > > > On 08/16/17 17:35, Tom Rini wrote: > > This introduces the variabe DTC_EXTRA_FLAGS to allow for additional > > flags to be passed to dtc. While this can have many uses (

Re: [RFC PATCH v3] pci: Concurrency issue during pci enable bridge

On Wed, Aug 16, 2017 at 10:33:12PM +0530, Srinath Mannam wrote: > Hi Bjorn, > > Thank you for the feedback. > > My comments are in lined. > > On Wed, Aug 16, 2017 at 7:13 PM, Bjorn Helgaas wrote: > > On Fri, Aug 04, 2017 at 08:27:28PM +0530, Srinath Mannam wrote: > >> Concurrency issue is obser

[PATCH] staging: lustre: uapi: properly include lustre_errno.h

The path for lustre_errno.h was not updated to the new path for errno.c. Also the header lustre_net.h uses code found in lustre_errno.h but doesn't include the header directly. It is easy to forget to add the header lustre_errno.h before including lustre_net.h so it is just easier to include lustre

Re: [f2fs-dev] [PATCH v3] f2fs: add cur_reserved_blocks to support soft block reservation

On 2017/8/18 23:09, Yunlong Song wrote: > This patch adds cur_reserved_blocks to extend reserved_blocks sysfs > interface to be soft threshold, which allows user configure it exceeding > current available user space. To ensure there is enough space for > supporting system's activation, this patch d

Re: [PATCH] staging: lustre: uapi: properly include lustre_errno.h

On Fri, Aug 18, 2017 at 11:04:14PM -0400, James Simmons wrote: > The path for lustre_errno.h was not updated to the new path > for errno.c. Also the header lustre_net.h uses code found in > lustre_errno.h but doesn't include the header directly. It > is easy to forget to add the header lustre_errno

[PATCH v2 1/1] usb:xhci: update condition to select bus->sysdev from parent device

From: "Thang Q. Nguyen" For commit 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA configuration"), sysdev points to devices known to the system firmware or hardware for DMA parameters. However, the parent of the system firmware/hardware device checking logic does not work in ACPI boot mode. Th

Re: [PATCH v2 3/3] vfio/pci: Don't probe devices that can't be reset

On Fri, 18 Aug 2017 08:57:09 -0700 David Daney wrote: > On 08/18/2017 07:12 AM, Alex Williamson wrote: > > On Fri, 18 Aug 2017 15:42:31 +0200 > > Jan Glauber wrote: > > > >> On Thu, Aug 17, 2017 at 07:00:17AM -0600, Alex Williamson wrote: > >>> On Thu, 17 Aug 2017 10:14:23 +0200 > >>> Jan G

[PATCH] X.509: Fix the buffer overflow in the utility function for OID string

From: Takashi Iwai The sprint_oid() utility function doesn't properly check the buffer size that it causes that the warning in vsnprintf() be triggered. For example on v4.1 kernel: [ 49.612536] [ cut here ] [ 49.612543] WARNING: CPU: 0 PID: 2357 at lib/vsprintf.c:1867

[PATCH v2] membarrier: Document scheduler barrier requirements

Document the membarrier requirement on having a full memory barrier in __schedule() after coming from user-space, before storing to rq->curr. It is provided by smp_mb__before_spinlock() in __schedule(). Document that membarrier requires a full barrier on transition from kernel thread to userspace

Re: [PATCH v2] sched/fair: Make PELT signal more accurate

On Fri, 2017-08-18 at 16:50 -0700, Joel Fernandes wrote: > The PELT signal (sa->load_avg and sa->util_avg) are not updated if the amount > accumulated during a single update doesn't cross a period boundary. This is > fine in cases where the amount accrued is much smaller than the size of a > single

Re: [PATCH] X.509: Fix the buffer overflow in the utility function for OID string

On Sat, 19 Aug 2017 06:19:44 +0200, Lee, Chun-Yi wrote: > > From: Takashi Iwai > > The sprint_oid() utility function doesn't properly check the buffer > size that it causes that the warning in vsnprintf() be triggered. > For example on v4.1 kernel: > > [ 49.612536] [ cut here ]---

Re: 32-bit powerpc, aty128fb: vmap allocation for size 135168 failed

> Meelis Roos writes: > > > I was trying 4.13.0-rc5-00075-gac9a40905a61 on my PowerMac G4 with 1G > > RAM and after some time of sddm respawning and X trying to restart, > > dmesg is full of messages about vmap allocation failures. > > Did it just start happening? ie. did rc4 work? It goes ba

[rfc patch] sched/topology: fix domain reconstruction memory leakage

Greetings, While beating on cpu hotplug with the shiny new topology fixes backported, my memory poor 8 socket box fairly quickly leaked itself to death, 0c0e776a9b0f being the culprit.  With the below applied, box took a severe beating overnight without a whimper. I'm wondering (ergo rfc) if free

Re: [PATCH RESEND 0/2] enable hires timer to timeout datagram socket

On Fri, Aug 18, 2017 at 10:27:56PM +, Vallish Vaidyeshwara wrote: > We have a on-demand application that uses long timeouts and needs to react to > events within milliseconds. Huh? The test program you posted does not react to any event. Thanks, Richard

Re: [rfc patch] sched/topology: fix domain reconstruction memory leakage

On Sat, 2017-08-19 at 08:10 +0200, Mike Galbraith wrote: > > Signed-off-by: Mike Galbraith (grr, wrong /me autographed the damn thing)

Re: [PATCH 3.16 084/134] usb: misc: legousbtower: Fix buffers on stack

On Fri, 18 Aug 2017 14:13:20 +0100 Ben Hutchings wrote: > 3.16.47-rc1 review patch. If anyone has any objections, please let me know. > > -- > > From: Maksim Salau > > commit 942a48730faf149ccbf3e12ac718aee120bb3529 upstream. > > Allocate buffers on HEAP instead of STACK for

[PATCH 0/5] constify net eisa_device_id

eisa_device_id are not supposed to change at runtime. All functions working with eisa_device_id provided by work with const eisa_device_id. So mark the non-const structs as const. Arvind Yadav (5): [PATCH 1/5] net: 3c509: constify eisa_device_id [PATCH 2/5] net: 3c59x: constify eisa_device_id

[PATCH 1/5] net: 3c509: constify eisa_device_id

eisa_device_id are not supposed to change at runtime. All functions working with eisa_device_id provided by work with const eisa_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/net/ethernet/3com/3c509.c | 2 +- 1 file changed, 1 insertion(+), 1 deletio

[PATCH 2/5] net: 3c59x: constify eisa_device_id

eisa_device_id are not supposed to change at runtime. All functions working with eisa_device_id provided by work with const eisa_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/net/ethernet/3com/3c59x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletio

[PATCH 3/5] net: de4x5: constify eisa_device_id

eisa_device_id are not supposed to change at runtime. All functions working with eisa_device_id provided by work with const eisa_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/net/ethernet/dec/tulip/de4x5.c | 2 +- 1 file changed, 1 insertion(+), 1 de

[PATCH 4/5] net: hp100: constify eisa_device_id

eisa_device_id are not supposed to change at runtime. All functions working with eisa_device_id provided by work with const eisa_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/net/ethernet/hp/hp100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(

[PATCH 5/5] net: defxx: constify eisa_device_id

eisa_device_id are not supposed to change at runtime. All functions working with eisa_device_id provided by work with const eisa_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/net/fddi/defxx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) dif

<    5   6   7   8   9   10