Re: can't oom-kill zap the victim's memory?

On Sat 19-09-15 15:24:02, Linus Torvalds wrote: > On Sat, Sep 19, 2015 at 8:03 AM, Oleg Nesterov wrote: > > + > > +static void oom_unmap_func(struct work_struct *work) > > +{ > > + struct mm_struct *mm = xchg(_unmap_mm, NULL); > > + > > + if

Re: First kernel patch (optimization)

Am 20.09.2015 um 04:21 schrieb Theodore Ts'o: On Sat, Sep 19, 2015 at 07:47:22PM +0200, Alexander Holler wrote: Perhaps not so surprisingly, over a decade later, it is not currently at the top of the priority list of any of the current file system or VFS developers, as far as I know. One of

Re: [PATCH] x86/math-emu: Add support for FISTTP insns

* Denys Vlasenko wrote: > These FPU instructions were added in SSE3-enabled CPUs. > > Run-tested by booting with "no387 nofxsr" and running test program: > > [RUN] Testing fisttp instructions > [OK] fisttp Btw., I think you forgot to submit the FISTTP testcase? Thanks,

[PATCH 1/1] Add to .gitignore file certs/x509_certificate_list

After compiling the kernel git status shows: Unchecked files: certs/x509_certificate_list Signed-off-by: Krzysztof Kolasa --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index fd3a355..c4f94bc 100644 --- a/.gitignore +++

Re: [PATCH 1/2] iio: adc: twl6030-gpadc: Fix module autoload for OF platform driver

On 17/09/15 18:02, Luis de Bethencourt wrote: > This platform driver has a OF device ID table but the OF module > alias information is not created so module autoloading won't work. > > Signed-off-by: Luis de Bethencourt Applied to the togreg branch of iio.git as I am

Re: [RFC v2 3/7] powerpc: atomic: Implement atomic{,64}_{add,sub}_return_* variants

On Sat, Sep 19, 2015 at 11:33:10PM +0800, Boqun Feng wrote: > Hi Will, > > On Fri, Sep 18, 2015 at 05:59:02PM +0100, Will Deacon wrote: > > On Wed, Sep 16, 2015 at 04:49:31PM +0100, Boqun Feng wrote: > > > On powerpc, we don't need a general memory barrier to achieve acquire and > > > release

Re: [PATCH 26/26] x86, pkeys: Documentation

* Dave Hansen wrote: > +Memory Protection Keys for Userspace (PKU aka PKEYs) is a CPU feature > +which will be found on future Intel CPUs. > + > +Memory Protection Keys provides a mechanism for enforcing page-based > +protections, but without requiring modification of the page

[PATCH 4/5] locking/rwsem: Relax to acquire/release semantics

... by using acquire semantics where appropiate. As such, weakly ordered archs can benefit from more relaxed use of barriers when issuing atomics. Signed-off-by: Davidlohr Bueso --- include/asm-generic/rwsem.h | 14 +++--- kernel/locking/rwsem-xadd.c | 5 +++-- 2 files

[PATCH 1/5] asm-generic: Add _{relaxed|acquire|release}() variants for inc/dec atomics

Similar to what we have for regular add/sub calls. For now, no actual arch implements them, so everyone falls back to the default atomics... iow, nothing changes. These will be used in future primitives. Signed-off-by: Davidlohr Bueso --- include/asm-generic/atomic-long.h | 29

[PATCH 3/5] locking/rtmutex: Relax to acquire/release semantics

... by using acquire semantics where appropiate. As such, weakly ordered archs can benefit from more relaxed use of barriers when issuing atomics. Signed-off-by: Davidlohr Bueso --- kernel/locking/rtmutex.c | 30 +- 1 file changed, 21 insertions(+), 9

[PATCH 5/5] locking/mcs: Relax to atomic/release semantics

... by using acquire semantics where appropriate As such, weakly ordered archs can benefit from more relaxed use of barriers when issuing atomics. Signed-off-by: Davidlohr Bueso --- kernel/locking/mcs_spinlock.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

[PATCH 0/5] locking: Adopt relaxed barrier semantics

Hi, This series continues porting users to Will's new _{acquire|release|relaxed} optimizations for weakly ordered archs -- and in practice, arm64 being the only actual user we have, thus could use a _lot_ more testing. While we have osq in -tip recently, along with Waiman's one for native

[PATCH 2/5] locking/mutex: Relax to atomic/release semantics

... by using acquire semantics where appropriate As such, weakly ordered archs can benefit from more relaxed use of barriers when issuing atomics. Signed-off-by: Davidlohr Bueso --- include/asm-generic/mutex-dec.h | 8 include/asm-generic/mutex-xchg.h | 10 +-

Re: [PATCH v6 2/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status

On Thu 17-09-15 09:09:31, Naoya Horiguchi wrote: > Currently there's no easy way to get per-process usage of hugetlb pages, which > is inconvenient because userspace applications which use hugetlb typically > want > to control their processes on the basis of how much memory (including hugetlb) >

Re: [PATCH 4.1 000/102] 4.1.8-stable review

On Sun, Sep 20, 2015 at 07:28:44AM +0200, Willy Tarreau wrote: > Hi Guenter, > > On Sat, Sep 19, 2015 at 05:25:59PM -0700, Guenter Roeck wrote: > > On 09/19/2015 10:27 AM, Greg Kroah-Hartman wrote: > > >This is the start of the stable review cycle for the 4.1.8 release. > > >There are 102 patches

Re: [PATCH 3.10 00/20] 3.10.89-stable review

On Sat, Sep 19, 2015 at 10:27:15AM -0700, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.10.89 release. > There are 20 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

Re: PCIe bus (re-)numbering

>> The current algorithm seems to allocate 8 extra busnumbers at the >> hotplug switch, but clearly 8 is not sufficient for the whole tree >> when it is discovered after initial numbering has been assigned. As >> the PCIe routing requires the bus numbers to be consecutive as it >> describes ranges

Re: [PATCH 1/3] mfd: axp20x: Rename supply names for AXP221 DC1SW and DC5LDO regulators

Hi Lee, On Sun, Sep 20, 2015 at 12:17 PM, Lee Jones wrote: > On Wed, 16 Sep 2015, Chen-Yu Tsai wrote: > >> The DC1SW and DC5LDO regulators in the AXP221 are internally chained >> to DCDC1 and DCDC5, hence the names. The original bindings used the >> parent regulator names

Re: [PATCH 1/2] perf tools: Use postorder rbtree iteration when removing symbols

* Alex Snast wrote: > Avoid using rb_erase when removing symbols as it requires rbtree > rebalancing, instead preform a post order iteration when deleting tree > symbols. > > Signed-off-by: Alex Snast > --- > tools/include/linux/rbtree.h | 14

Re: [PATCH] Staging: comedi: Fix coding style issues

On Sun, Sep 20, 2015 at 6:50 AM, Jaime Arrocha wrote: > > On 09/19/2015 01:13 PM, punit vara wrote: >> >> [PATCH] Staging: comedi: Fix block comment warning > > > [PATCH] Staging: comedi: Coding style warnings fix for block comments > Thank you for suggestion sir .I would

[lkp] [nfsd] 07d2931094: -6.0% fsmark.files_per_sec

FYI, we noticed the below changes on git://git.samba.org/jlayton/linux nfsd-4.4 commit 07d29310940bf676822715efd4be3c769cae97c2 ("nfsd: convert nfs4_file->fi_fds array to use nfsd_files") =

Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource

On 15/09/2015 06:45, Jason Gunthorpe wrote: > No, I'm saying the resource pool is *well defined* and *fixed* by each > hardware. > > The only question is how do we expose the N resource limits, the list > of which is totally vendor specific. I don't see why you say the limits are vendor

Re: [PATCH 2/2] iio: dac: max5821: Fix module autoload for OF platform driver

On 17/09/15 18:02, Luis de Bethencourt wrote: > This platform driver has a OF device ID table but the OF module > alias information is not created so module autoloading won't work. > > Signed-off-by: Luis de Bethencourt Thanks Applied to the togreg branch of iio.git. As

[PATCH] Staging: rtl8712: Coding style warning fix for block comment

This is a patch to mlme_linux.c that fixes up following warning reported by checkpatch.pl : -Block comments use a trailing */ on a separate line Signed-off-by: Punit Vara --- drivers/staging/rtl8712/mlme_linux.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

Re: [PATCH 00/16] usb: gadget: amd5536udc: fix memory leaks

On Sat, Sep 19, 2015 at 09:24:38AM +0530, Sudip Mukherjee wrote: > On Fri, Sep 18, 2015 at 01:39:54PM -0500, Felipe Balbi wrote: > > On Mon, Sep 14, 2015 at 08:42:47PM +0530, Sudip Mukherjee wrote: > > > This amd5536udc was a complete mess. The major problems that i could > > > find are: > > > >

Re: [PATCH 1/2] x86/math-emu: Add support for FCMOVcc and F[U]COMI[P] insns

* Denys Vlasenko wrote: > >> arch/x86/math-emu/fpu_aux.c | 70 ++ > >> arch/x86/math-emu/fpu_entry.c | 49 +-- > >> arch/x86/math-emu/fpu_proto.h | 12 > >> arch/x86/math-emu/reg_compare.c | 128 > >>

Re: [PATCH 00/15] RDS: connection scalability and performance improvements

On 9/20/2015 2:04 AM, Santosh Shilimkar wrote: This series addresses RDS connection bottlenecks on massive workloads and improve the RDMA performance almost by 3X. RDS TCP also gets a small gain of about 12%. RDS is being used in massive systems with high scalability where several hundred

[PATCH] Staging: comedi: Coding style warning fix for block comments

This patch is to comedidev.h file that fixes up following warnings reported by checkpatch.pl : -Block comments use a trailing */ on a separate line -Block comments use * on subsequent lines Signed-off-by: Punit Vara --- drivers/staging/comedi/comedidev.h | 62

Drop IPC_OLD for direct ipc syscalls? (was: Re: [PATCH v2 3/4] m68k: Wire up direct ipc calls)

Hi Andreas, On Thu, Sep 17, 2015 at 5:39 PM, Andreas Schwab wrote: > Geert Uytterhoeven writes: > > > > > It would be nice if the direct syscalls would drop the use of > > > > > ipc_parse_version. Currently, apart from going through the ipc > > > >

Re: [PATCH v3] crypto: omap-aes: Add support for GCM mode

On 15 September 2015 at 15:28, Lokesh Vutla wrote: > --- a/drivers/crypto/Kconfig > +++ b/drivers/crypto/Kconfig > @@ -293,6 +293,7 @@ config CRYPTO_DEV_OMAP_AES > depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP2PLUS > select CRYPTO_AES > select

Re: Drop IPC_OLD for direct ipc syscalls?

Geert Uytterhoeven writes: > Should I postpone wiring up the direct ipc syscalls on m68k (and thus renumber > __NR_membarrier) until the above is resolved, or can they go in in v4.3? If you wire up the direct ipc calls know you create an ABI that is harder to get rid of.

[tip:x86/fpu] x86/fpu/math-emu, selftests: Add tests for FCMOV and FCOMI insns

Commit-ID: 57ca6897cd134efd8914cc230f602abad431c7db Gitweb: http://git.kernel.org/tip/57ca6897cd134efd8914cc230f602abad431c7db Author: Denys Vlasenko AuthorDate: Thu, 17 Sep 2015 15:02:13 +0200 Committer: Ingo Molnar CommitDate: Sun, 20 Sep 2015

[tip:x86/fpu] x86/fpu/math-emu: Add support for F[U]COMI[P] insns

Commit-ID: b8e4a910e576961009a87d07f6b7eff67c5c2e34 Gitweb: http://git.kernel.org/tip/b8e4a910e576961009a87d07f6b7eff67c5c2e34 Author: Denys Vlasenko AuthorDate: Fri, 18 Sep 2015 16:53:29 +0200 Committer: Ingo Molnar CommitDate: Sun, 20 Sep 2015

[tip:x86/asm] x86/entry/vsyscall: Add CONFIG to control default

Commit-ID: 3dc33bd30f3e1c1bcaaafa3482737694debf0f0b Gitweb: http://git.kernel.org/tip/3dc33bd30f3e1c1bcaaafa3482737694debf0f0b Author: Kees Cook AuthorDate: Wed, 12 Aug 2015 17:55:19 -0700 Committer: Ingo Molnar CommitDate: Sun, 20 Sep 2015

[tip:x86/fpu] x86/fpu/math-emu: Add support for FCMOVcc insns

Commit-ID: 9a9d8642d03a7512f78cbe7ed6a2011fad3cbca3 Gitweb: http://git.kernel.org/tip/9a9d8642d03a7512f78cbe7ed6a2011fad3cbca3 Author: Denys Vlasenko AuthorDate: Fri, 18 Sep 2015 16:53:30 +0200 Committer: Ingo Molnar CommitDate: Sun, 20 Sep 2015

[PATCHv3 02/15] staging: rtl8192u: r8192U_core: add temporary variables to keep lines under 80 characters

Add some temporary variables to reduce line length under the maximum of 80 characters, as per the kernel code style. Signed-off-by: Raphaël Beamonte --- drivers/staging/rtl8192u/r8192U_core.c | 139 ++--- 1 file changed, 94 insertions(+),

[PATCHv3 09/15] staging: rtl8192u: r8192U_core: rtl8192_process_phyinfo: remove unneeded variable

Local variable last_beacon_adc_pwdb was used to store a value that wasn't used after. This patch removes that variable. Signed-off-by: Raphaël Beamonte --- drivers/staging/rtl8192u/r8192U_core.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git

Re: [PATCH] Thunderbolt 2 driver for recent Apple MacBooks

On Sun, Sep 20, 2015 at 06:11:25PM +0200, Knuth Posern wrote: > Hi, > > This patch is submitted for upstream inclusion. > This is a first for me, so I hope the format of this mail is convenient. > > Thanks to Greg and Andreas the attached patch (diff -up) fixes the bug: >

Re: [PATCH] ARM: pxa: Remove unused clock_enable field from struct pxa2xx_spi_master

Jarkko Nikula writes: > Use for struct pxa2xx_spi_master clock_enable field was removed years ago > from the pxa2xx-spi driver by the commit 2f1a74e5a2de ("[ARM] pxa: make > pxa2xx_spi driver use ssp_request()/ssp_free()"). > > Therefore remove it from structure

Re: [PATCH v6 1/5] pwm: add the Berlin pwm controller driver

On 17.09.2015 12:13, Antoine Tenart wrote: Add a PWM controller driver for the Marvell Berlin SoCs. This PWM controller has 4 channels. Signed-off-by: Antoine Tenart Acked-by: Sebastian Hesselbarth Thierry, if you are also

Re: [RFCv5 PATCH 32/46] sched: Energy-aware wake-up task placement

On 09/18/2015 03:34 AM, Dietmar Eggemann wrote: >> Here should consider scenario for two groups have same capacity? >> This will benefit for the case LITTLE.LITTLE. So the code will be >> looks like below: >> >> int target_sg_cpu = INT_MAX; >> >> if (capacity_of(max_cap_cpu) <=

[PATCH] ti-st: use worker instead of calling st_int_write in wake up

From: Muhammad Hamza Farooq The wake up method is called with the port lock held. The st_int_write method calls port->ops->write with tries to acquire the lock again, causing CPU to wait infinitely. Right way to do is to write data to port in worker thread. Signed-off-by:

[PATCH] thunderbolt: Allow loading of module on recent Apple MacBooks with thunderbolt 2 controller

The pci device ids listed in the thunderbolt driver are to restrictive, which prevents the driver from being loaded on recent Apple MacBooks using a thunderbolt 2 controller. In particular this prevented any hot-plugging functionality for thunderbolt based ethernet dongles (i.e. Apples thunderbolt

Re: [PATCH 4.2 000/120] 4.2.1-stable review

Dear Greg, FYI, this revision seems to be missing https://lkml.org/lkml/2015/9/3/411 [PATCH 4.2-rc5] workqueue: Make flush_workqueue() available again to non GPL modules which actually defers 4.2 rollout for some cases, hence for 4.2.1 too. Cheers, Pete On Samstag, 19. September 2015

[PATCH 1/9] staging: rtl8192e: rtl_wx: Fix BRACES warning

Fix checkpatch BRACES warning. Signed-off-by: Mateusz Kulikowski --- drivers/staging/rtl8192e/rtl8192e/rtl_wx.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_wx.c

[PATCH 2/9] staging: rtl8192e: Fix SUSPECT_CODE_INDENT warnings

Fix SUSPECT_CODE_INDENT warnings (indentation). Signed-off-by: Mateusz Kulikowski --- drivers/staging/rtl8192e/rtl8192e/r8190P_rtl8256.c | 4 ++-- drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c | 4 ++-- drivers/staging/rtl8192e/rtl8192e/rtl_dm.c | 10

Re: [PATCH] thunderbolt: Allow loading of module on recent Apple MacBooks with thunderbolt 2 controller

On Sun, Sep 20, 2015 at 08:16:11PM +0200, Knuth Posern wrote: > The pci device ids listed in the thunderbolt driver are to restrictive, > which prevents the driver from being loaded on recent Apple MacBooks > using a thunderbolt 2 controller. In particular this prevented any > hot-plugging

[PATCH 0/9] staging: rtl8192e: Various cleanups

This series contains various cleanups for rtl8192e driver. It will apply cleanly to staging-next/testing only after static function rename series is applied. Series was target tested (although only patches #8 and #9 may affect driver behavior). Patches #2, #8 and #9 generate some checkpatch

Re: can't oom-kill zap the victim's memory?

On 09/20/15 11:05, Linus Torvalds wrote: On Sun, Sep 20, 2015 at 5:56 AM, Oleg Nesterov wrote: In this case the workqueue thread will block. What workqueue thread? pagefault_out_of_memory -> out_of_memory -> oom_kill_process as far as I can tell, this

[PATCH] thunderbolt: Allow loading of module on recent Apple MacBooks with thunderbolt 2 controller

The pci device ids listed in the thunderbolt driver are to restrictive, which prevents the driver from being loaded on recent Apple MacBooks using a thunderbolt 2 controller. In particular this prevented any hot-plugging functionality for thunderbolt based ethernet dongles (i.e. Apples thunderbolt

Re: [PATCH 2/5] pinctrl: berlin: add the berlin4ct pinctrl driver

On 19.09.2015 12:02, Jisheng Zhang wrote: Add the pin-controller driver for Marvell Berlin BG4CT SoC, with definition of its groups and functions. This uses the core Berlin pinctrl driver. Signed-off-by: Jisheng Zhang --- [...] diff --git

Re: [RFC PATCH 0/2] kvmclock: fix ABI breakage from PVCLOCK_COUNTS_FROM_ZERO.

On Fri, Sep 18, 2015 at 05:54:28PM +0200, Radim Krčmář wrote: > This patch series will be disabling PVCLOCK_COUNTS_FROM_ZERO flag and is > RFC because I haven't explored many potential problems or tested it. The justification to disable PVCLOCK_COUNTS_FROM_ZERO is because you haven't explored

[PATCH 0/2] x86: NMI vs paravirt fixes

These are for x86/urgent. This fixes at least one problem that Sasha can trigger using some crazy configuration + Trinity. I can't reproduce the full file of nastiness that he's seeing, but these patches both look legit to me, they fix what look like real bugs, and they seem to help Sasha's

[PATCH 2/2] x86/nmi/64: Fix a paravirt stack-clobbering bug in the NMI code

The NMI entry code that switches to the normal kernel stack needs to be very careful not to clobber any extra stack slots on the NMI stack. The code is fine under the assumption that SWAPGS is just a normal instruction, but that assumption isn't really true. Use SWAPGS_UNSAFE_STACK instead.

[PATCH 1/2] x86/paravirt: Replace the paravirt nop with a bona fide empty function

PARAVIRT_ADJUST_EXCEPTION_FRAME generates this code (using nmi as an example, trimmed for readability): ff 15 00 00 00 00 callq *0x0(%rip)# 2796 2792: R_X86_64_PC32 pv_irq_ops+0x2c That's a call through a function pointer to regular C function that

Re: [PATCH v3 7/9] zram: pass zstrm down to decompression path

On Fri, Sep 18, 2015 at 02:19:22PM +0900, Joonsoo Kim wrote: > From: Sergey Senozhatsky > > Introduce zcomp_decompress_begin()/zcomp_decompress_end() as a > preparation for crypto API-powered zcomp. > > Change zcomp_decompress() signature to require zstrm

Re: [PATCH v3 6/9] zram: make stream find and release functions static

On Fri, Sep 18, 2015 at 02:19:21PM +0900, Joonsoo Kim wrote: > From: Sergey Senozhatsky > > Hide (make static) zstrm find and release function and introduce > zcomp_compress_begin()/zcomp_compress_end(). We will have begin > and end functions around compression

[PATCH v2 2/2] x86/msr: Set the return value to zero when native_rdmsr_safe fails

This will cause unchecked native_rdmsr_safe failures to return deterministic results. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/msr.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h

[PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

This demotes an OOPS and likely panic due to a failed non-"safe" MSR access to a WARN_ON_ONCE and a return of zero (in the RDMSR case). We still write a pr_info entry unconditionally for debugging. To be clear, this type of failure should *not* happen. This patch exists to minimize the chance of

[PATCH v2 0/2] x86/msr: MSR access failure changes

This applies on top of my earlier paravirt MSR series. Changes from v1: - Return zero instead of poison on bad RDMSRs. Andy Lutomirski (2): x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops x86/msr: Set the return value to zero when native_rdmsr_safe fails

Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Sep 20, 2015 5:15 PM, "Linus Torvalds" wrote: > > On Sun, Sep 20, 2015 at 5:02 PM, Andy Lutomirski wrote: > > This demotes an OOPS and likely panic due to a failed non-"safe" MSR > > access to a WARN_ON_ONCE and a return of zero (in the RDMSR

linux-next: build failure after merge of the sound-asoc tree

Hi all, After merging the sound-asoc tree, today's linux-next build (x86_64 allmodconfig) failed like this: sound/soc/codecs/rt5645.c: In function 'rt5645_i2c_probe': sound/soc/codecs/rt5645.c:3277:21: error: 'dmi_platform_intel_broadwel' undeclared (first use in this function)

Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps

On Sun, 2015-09-20 at 19:19 -0600, David Ahern wrote: > On 9/20/15 6:30 AM, kernel test robot wrote: > > FYI, we noticed the below changes on > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > master > > commit 192132b9a034d87566294be0fba5f8f75c2cf16b ("net: Add

Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Sun, Sep 20, 2015 at 5:02 PM, Andy Lutomirski wrote: > This demotes an OOPS and likely panic due to a failed non-"safe" MSR > access to a WARN_ON_ONCE and a return of zero (in the RDMSR case). > We still write a pr_info entry unconditionally for debugging. No, this is wrong.

[PATCH 2/2] perf record: Synthesize COMM event for a command line workload

When perf creates a new child to profile, the events are enabled on exec(). And in this case, it doesn't synthesize any event for the child since they'll be generated during exec(). But there's an window between the enabling and the event generation. It used to be overcome since samples are

[PATCH 1/2] perf tools: Introduce perf_evlist__start_workload_ex()

The perf_evlist__start_workload_ex() does same as __start_work() but also invokes callback which does additional work for each command. Acked-by: Jiri Olsa Signed-off-by: Namhyung Kim --- tools/perf/util/evlist.c | 11 +++ tools/perf/util/evlist.h

Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps

On 9/20/15 6:30 AM, kernel test robot wrote: FYI, we noticed the below changes on https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 192132b9a034d87566294be0fba5f8f75c2cf16b ("net: Add support for VRFs to inetpeer cache")

Re: [PATCH] ARM: at91/dt: ov2640: add hsync/vsync-active property

Hi, Nicolas On 9/18/2015 10:09 PM, Nicolas Ferre wrote: Le 18/09/2015 13:28, Josh Wu a écrit : On at91sam9x5ek/at91sam9m10g45ek/sama5d3xek boards, we use the parallel connection for ov2640. So we must set the hsync/vsync property (1 means active high). Otherwise, the connection would be seen

Re: [PATCH 0/2] extcon: Fix module autoload for OF platform drivers

Hello Luis, On 2015년 09월 17일 20:58, Javier Martinez Canillas wrote: > Hello Luis, > > On 09/17/2015 01:54 PM, Luis de Bethencourt wrote: >> Hello, >> >> These patches add the missing MODULE_DEVICE_TABLE() for OF to export >> the information so modules have the correct aliases built-in and >>

Re: Drop IPC_OLD for direct ipc syscalls?

Hi Andreas, On Sun, Sep 20, 2015 at 12:38 PM, Andreas Schwab wrote: > Geert Uytterhoeven writes: > >> Should I postpone wiring up the direct ipc syscalls on m68k (and thus >> renumber >> __NR_membarrier) until the above is resolved, or can they go

[PATCH 1/2] drm/vmwgfx: make vmw_kms_helper_dirty return an initialized value

In vmw_kms_helper_dirty(), local variable ret is never initialized before begin used in a return statement when vmw_fifo_reserve() fails. Instead of returning an uninitialized value, return -ENOMEM here and remove the useless variable. Signed-off-by: Nicolas Iooss

[PATCH 2/2] drm/vmwgfx: make vmw_cotable_unbind return an initialized value

In vmw_cotable_unbind(), local variable ret is never initialized before being used in a return statement at the end of the function. Fix this by directly returning zero and removing the variable. Signed-off-by: Nicolas Iooss ---

[PATCH] crypto: crc32c-pclmul: use .rodata instead of .rotata

Module crc32c-intel uses a special read-only data section named .rotata. This section is defined for K_table, and its name seems to be a spelling mistake for .rodata. Fixes: 473946e674eb ("crypto: crc32c-pclmul - Shrink K_table to 32-bit words") Signed-off-by: Nicolas Iooss

[lkp] [x86, crypto] a2e120a9ac: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC

FYI, we noticed the below changes on https://git.kernel.org/pub/scm/linux/kernel/git/daveh/x86-pkeys.git pkeys-v005-protsyscalls commit a2e120a9ac7c83f3a1598f41150e5acf66017936 ("x86, crypto: clean up feature detection in aesni-intel_glue")

Re: can't oom-kill zap the victim's memory?

On 09/19, Michal Hocko wrote: > > On Sat 19-09-15 17:03:16, Oleg Nesterov wrote: > > > > Stupid idea. Can't we help the memory hog to free its memory? This is > > orthogonal to other improvements we can do. > > > > Please don't tell me the patch below is ugly, incomplete and suboptimal > > in many

[PATCH] x86/math-emu, selftests: Add test for FISTTP insns

$ ./test_FISTTP_32 [RUN] Testing fisttp instructions [OK]fisttp Signed-off-by: Denys Vlasenko CC: Ingo Molnar CC: Borislav Petkov CC: "H. Peter Anvin" CC: Andy Lutomirski CC: Kees Cook

[PATCH 2/2] [media] c8sectpfe: forward err instead of returning an uninitialized variable

When load_c8sectpfe_fw_step1() tests whether the return value of request_firmware_nowait(), stored in variable err, indicates an error, it then returns the value hold by uninitialized variable ret, which seems incorrect. Fix this by forwarding the error returned by request_firmware_nowait() to

Re: can't oom-kill zap the victim's memory?

Oleg Nesterov wrote: > On 09/17, Kyle Walker wrote: > > > > Currently, the oom killer will attempt to kill a process that is in > > TASK_UNINTERRUPTIBLE state. For tasks in this state for an exceptional > > period of time, such as processes writing to a frozen filesystem during > > a lengthy

Re: [PATCH 2/3] usb: gadget: at91_udc: mention proper dependency

On Sat, Sep 19, 2015 at 10:42:58PM +0530, Sudip Mukherjee wrote: > While building allmodconfig on avr32 the build failed with the error: > "at91_pmc_base" [drivers/usb/gadget/udc/atmel_usba_udc.ko] undefined! > > On checking the code it turned out that if CONFIG_OF is defined then it > is using

[PATCH] Thunderbolt 2 driver for recent Apple MacBooks

Hi, This patch is submitted for upstream inclusion. This is a first for me, so I hope the format of this mail is convenient. Thanks to Greg and Andreas the attached patch (diff -up) fixes the bug: https://bugzilla.kernel.org/show_bug.cgi?id=100191 The pci device ids listed in the tb driver are

Re: [PATCH] clk: readd refcounting for struct clk instances [when used in pm_clk_add_clk(), genpd]

Hi Stephen, Am Mittwoch, 16. September 2015, 11:18:05 schrieb Heiko Stübner: > Am Dienstag, 15. September 2015, 17:39:31 schrieb Stephen Boyd: > > On 09/15, Heiko Stübner wrote: > > > With the split into struct clk and struct clk_core, clocks lost the > > > ability for nested __clk_get clkdev

Second email notice to you (€950,000.00 Euro)

Sehr geehrte Empfänger, Sie haben gewählt, um zu empfangen (€ 950,000.00 Euro) als Charity-Spenden aus der Qatar Foundation. Somit, Sie sind verpflichtet, zurück antworten an die unten genannten Kontaktinformationen E-Mail Adresse für weitere Informationen. Mit freundlichen Grüßen, Herr Rashid

Re: can't oom-kill zap the victim's memory?

On 09/19, Linus Torvalds wrote: > > On Sat, Sep 19, 2015 at 8:03 AM, Oleg Nesterov wrote: > > + > > +static void oom_unmap_func(struct work_struct *work) > > +{ > > + struct mm_struct *mm = xchg(_unmap_mm, NULL); > > + > > + if (!atomic_inc_not_zero(>mm_users)) > > +

[PATCH] dma-mapping: Deinline dma_[un]map_single_attrs()

With this .config: http://busybox.net/~vda/kernel_config_ALLYES_Os, after deinlining these functions have sizes and callsite counts as follows: dma_map_single_attrs: 214 bytes, 587 calls dma_unmap_single_attrs: 115 bytes, 771 calls This patch reduces kernel size by 152310 bytes. text

Re: [PATCH v2 2/2] ARM: irqchip: mxs: add Alpascale ASM9260 support

Am 20.09.2015 um 13:28 schrieb Marc Zyngier: > On Sat, 19 Sep 2015 07:53:34 +0200 > Oleksij Rempel wrote: > >> Am 18.09.2015 um 12:42 schrieb Marc Zyngier: >>> On Fri, 18 Sep 2015 11:18:42 +0200 >>> Oleksij Rempel wrote: >> > > [...] >

[PATCH 1/2] [media] c8sectpfe: initialize err in load_slim_core_fw

load_slim_core_fw() uses a for loop with !err in its condition without first initializing err. Fix this by setting err to 0 in its definition. Signed-off-by: Nicolas Iooss --- drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 2 +- 1 file changed, 1

Re: [PATCH 3.10 00/20] 3.10.89-stable review

On 09/20/2015 01:53 AM, Sudip Mukherjee wrote: On Sat, Sep 19, 2015 at 10:27:15AM -0700, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.89 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues

[PATCH] pinctrl: sort dt_params array in the same order as pin_config_param

Sort this array in the same order as enum pin_config_param and conf_items array for consistency. Signed-off-by: Masahiro Yamada --- drivers/pinctrl/pinconf-generic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH 00/16] usb: gadget: amd5536udc: fix memory leaks

Hi, On Sat, Sep 19, 2015 at 09:24:38AM +0530, Sudip Mukherjee wrote: > On Fri, Sep 18, 2015 at 01:39:54PM -0500, Felipe Balbi wrote: > > On Mon, Sep 14, 2015 at 08:42:47PM +0530, Sudip Mukherjee wrote: > > > This amd5536udc was a complete mess. The major problems that i could > > > find are: > >

Re: can't oom-kill zap the victim's memory?

On 09/20, Tetsuo Handa wrote: > > Oleg Nesterov wrote: > > On 09/17, Kyle Walker wrote: > > > > > > Currently, the oom killer will attempt to kill a process that is in > > > TASK_UNINTERRUPTIBLE state. For tasks in this state for an exceptional > > > period of time, such as processes writing to a

Re: [PATCH tip/core/rcu 14/19] rcu: Extend expedited funnel locking to rcu_data structure

On 07/17/2015 07:29 PM, Paul E. McKenney wrote: > From: "Paul E. McKenney" > > The strictly rcu_node based funnel-locking scheme works well in many > cases, but systems with CONFIG_RCU_FANOUT_LEAF=64 won't necessarily get > all that much concurrency. This commit

[tip:x86/fpu] x86/fpu/math-emu: Remove define layer for undocumented opcodes

Commit-ID: 4aef363e48177d451b4d263c69dd2c86437e988b Gitweb: http://git.kernel.org/tip/4aef363e48177d451b4d263c69dd2c86437e988b Author: Denys Vlasenko AuthorDate: Fri, 18 Sep 2015 16:53:28 +0200 Committer: Ingo Molnar CommitDate: Sun, 20 Sep 2015

Re: [PATCH v2 2/2] ARM: irqchip: mxs: add Alpascale ASM9260 support

On Sat, 19 Sep 2015 07:53:34 +0200 Oleksij Rempel wrote: > Am 18.09.2015 um 12:42 schrieb Marc Zyngier: > > On Fri, 18 Sep 2015 11:18:42 +0200 > > Oleksij Rempel wrote: > [...] > >> +static void asm9260_mask_irq(struct irq_data *d) > >> +{ > >>

Re: [PATCH] PCI/MSI: Fix MSI IRQ domains for SR-IOV

On Fri, 18 Sep 2015 15:08:54 -0600 Alex Williamson wrote: Hi Alex, > SR-IOV creates a virtual bus where bus->self is NULL. This results > in a segfault as VFs are added and we scan for an MSI domain without > taking that into account. Detect this and scan up to the

[PATCH] SubmittingPatches: make Subject examples match the de facto standard

The examples should better match what kernel developers actually expect, so that they set a good example both for this project and for other projects with similar development processes. Signed-off-by: Alex Henrie --- Documentation/SubmittingPatches | 8 1 file

Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device

On Fri, Aug 14, 2015 at 6:24 PM, Lina Iyer wrote: > Would you rather query the hwspinlock driver to see if the framework > should take a s/w spinlock or not, IOW, raw-accessible or not? Sorry, I'm afraid I rather not. This seems to make things even more complicated without

Re: can't oom-kill zap the victim's memory?

On 09/20, Michal Hocko wrote: > > On Sat 19-09-15 15:24:02, Linus Torvalds wrote: > > On Sat, Sep 19, 2015 at 8:03 AM, Oleg Nesterov wrote: > > > + > > > +static void oom_unmap_func(struct work_struct *work) > > > +{ > > > + struct mm_struct *mm = xchg(_unmap_mm, NULL); > >

[PATCH] staging/rdma/hfi1: do not use u8 to store a 32-bit integer

hfi1_rc_hdrerr() stores the result of be32_to_cpu() into opcode, which is a local variable declared as u8. Later this variable is used in a 24-bit logical right shift, which makes clang complains (when building an allmodconfig kernel with LLVMLinux patches):

Re: [PATCH 00/16] usb: gadget: amd5536udc: fix memory leaks

On Sun, Sep 20, 2015 at 01:42:42PM +0530, Sudip Mukherjee wrote: > On Sat, Sep 19, 2015 at 09:24:38AM +0530, Sudip Mukherjee wrote: > > On Fri, Sep 18, 2015 at 01:39:54PM -0500, Felipe Balbi wrote: > > > On Mon, Sep 14, 2015 at 08:42:47PM +0530, Sudip Mukherjee wrote: > > > > This amd5536udc was a

Re: Please suggest proper format for DT properties.

On Fri, Sep 18, 2015 at 5:36 PM, Constantine Shulyupin wrote: > Hi, > > I am designing DT support for a hwmon chip. > It has some sensors, each of them can be: > - "disabled" > - "thermal diode" > - "thermistor" > - "voltage" > > Four possible options for DT properties

  1   2   3   4   5   >