On Tue, 19 Nov 2013, tip-bot for Srikar Dronamraju wrote:
> Commit-ID: 9abf24d465180f5f2eb26a43545348262f16b771
> Gitweb: http://git.kernel.org/tip/9abf24d465180f5f2eb26a43545348262f16b771
> Author: Srikar Dronamraju
> AuthorDate: Tue, 12 Nov 2013 22:11:26 +0530
> Committer: Ingo
(2013/11/28 2:41), Oleg Nesterov wrote:
> On 11/27, Masami Hiramatsu wrote:
>>
>> (2013/11/27 2:43), Oleg Nesterov wrote:
>>>
>>> This doesn't allow to read the data from other CPUs, but at least
>>> the changes are simple and this_cpu_ is better than the reading
>>> from the obviously wrong
On Wed, 27 Nov 2013, Johannes Weiner wrote:
> The long-standing, user-visible definition of the current line agrees
> with me. You can't just redefine this, period.
>
> I tried to explain to you how insane the motivation for this patch is,
> but it does not look like you are reading what I
(2013/11/28 2:05), Oleg Nesterov wrote:
> On 11/27, Masami Hiramatsu wrote:
>>
>> (2013/11/27 2:23), Oleg Nesterov wrote:
>>> On 11/26, Masami Hiramatsu wrote:
(2013/11/26 4:29), Oleg Nesterov wrote:
> +#define PSEUDO_REG_OFFSET4096/* arbitrary value >
>
On Thu, Nov 28, 2013 at 1:47 AM, Rhyland Klein wrote:
> On 11/26/2013 5:05 AM, Mika Westerberg wrote:
>> From: Heikki Krogerus
>>
>> This makes it possible to request the gpio descriptors in
>> rfkill_gpio driver regardless of the platform.
>>
>> Signed-off-by: Heikki Krogerus
>> Signed-off-by:
On Wed, Nov 27, 2013 at 10:54 AM, Ezequiel Garcia
wrote:
> On Tue, Nov 26, 2013 at 03:03:03PM -0800, Tim Kryger wrote:
>> An external device may be keeping the UART busy and preventing LCR
>> from being written.
>>
>> What device is attached to ttyS1?
>
> There's no device attached at ttyS1.
This patch uses the generic early_ioremap code to implement
early_ioremap for ARM. The ARM-specific bits come mostly from
an earlier patch from Leif Lindholm
here:
https://lkml.org/lkml/2013/10/3/279
Signed-off-by: Mark Salter
Tested-by: Leif Lindholm
CC: Russell King
CC:
This patch copies generic bits of x86 early_ioremap() support
into a library for potential use by other architectures.
Signed-off-by: Mark Salter
CC: Arnd Bergmann
CC: Ingo Molnar
CC: linux-a...@vger.kernel.org
---
include/asm-generic/early_ioremap.h | 40 ++
lib/Kconfig
Signed-off-by: Mark Salter
CC: Catalin Marinas
CC: Will Deacon
CC: Rob Landley
CC: linux-arm-ker...@lists.infradead.org
CC: linux-...@vger.kernel.org
---
Documentation/arm64/memory.txt | 4 +--
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/Kbuild| 1 +
Signed-off-by: Mark Salter
CC: Thomas Gleixner
CC: Ingo Molnar
CC: "H. Peter Anvin"
CC: x...@kernel.org
---
arch/x86/Kconfig | 1 +
arch/x86/include/asm/Kbuild | 1 +
arch/x86/include/asm/fixmap.h | 6 ++
arch/x86/include/asm/io.h | 14 +--
arch/x86/mm/ioremap.c
This patch series takes the common bits from the x86 early ioremap
implementation and creates a generic library which may be used by
other architectures. The early ioremap interfaces are intended for
situations where boot code needs to make temporary virtual mappings
before the normal ioremap
On Wed, 27 Nov 2013, Johannes Weiner wrote:
> > The task that is bypassing the memcg charge to the root memcg may not be
> > the process that is chosen by the oom killer, and it's possible the amount
> > of memory freed by killing the victim is less than the amount of memory
> > bypassed.
>
>
On Thursday, November 28, 2013 11:28 AM, Jingoo Han wrote:
> This macro is used to create a struct pci_device_id array.
>
> Signed-off-by: Jingoo Han
Oops,
Please ignore this patch.
I was confused, so I sent the patch to wrong cc-list.
Sorry.
Best regards,
Jingoo Han
> ---
>
This macro is used to create a struct pci_device_id array.
Signed-off-by: Jingoo Han
---
drivers/mtd/maps/amd76xrom.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/maps/amd76xrom.c b/drivers/mtd/maps/amd76xrom.c
index f7207b0..6a0582e 100644
---
On Wed, Nov 27, 2013 at 04:22:18PM -0800, David Rientjes wrote:
> On Wed, 27 Nov 2013, Johannes Weiner wrote:
>
> > > The patch is drawing the line at "the kernel can no longer do anything to
> > > free memory", and that's the line where userspace should be notified or a
> > > process killed by
Hi all,
Changes since 20131127:
My fixes tree is empty again.
Non-merge commits (relative to Linus' tree): 1504
1680 files changed, 67682 insertions(+), 32808 deletions(-)
I have created today's linux-next tree
On Wed, Nov 27, 2013 at 04:56:04PM -0800, David Rientjes wrote:
> On Wed, 27 Nov 2013, Johannes Weiner wrote:
>
> > > The memcg oom killer has incurred a serious regression since the 3.12-rc6
> > > kernel where this was merged as 4942642080ea ("mm: memcg: handle
> > > non-error
> > > OOM
m...@console-pimps.org writes:
> On Sat, 23 Nov, at 07:55:37PM, Madper Xie wrote:
>>
>> Pstore fs expects that backends provide a uniqued id which could avoid
>> pstore making entries as duplication or denominating entries the same
>> name. So I combine the timestamp, part and count into id.
>>
This macro is used to create a struct pci_device_id array.
Signed-off-by: Jingoo Han
---
drivers/uio/uio_sercos3.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/uio/uio_sercos3.c b/drivers/uio/uio_sercos3.c
index 9cfdfca..f233b03 100644
---
This macro is used to create a struct pci_device_id array.
Signed-off-by: Jingoo Han
---
drivers/uio/uio_netx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/uio/uio_netx.c b/drivers/uio/uio_netx.c
index 4c345db..8e85bfb 100644
--- a/drivers/uio/uio_netx.c
+++
On Tue, Nov 26 2013, Konrad Rzeszutek Wilk wrote:
>
> Hey Jens,
>
> Please git pull the following branch:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> stable/for-jens-3.13-take-two
>
> which has bug-fixes. It is based on todays on your 'for-3.13/drivers'
>
This macro is used to create a struct pci_device_id array.
Signed-off-by: Jingoo Han
---
drivers/uio/uio_cif.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/uio/uio_cif.c b/drivers/uio/uio_cif.c
index 30f533c..07dba37 100644
--- a/drivers/uio/uio_cif.c
+++
This macro is used to create a struct pci_device_id array.
Signed-off-by: Jingoo Han
---
drivers/uio/uio_aec.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/uio/uio_aec.c b/drivers/uio/uio_aec.c
index 1549fab..c06f800 100644
--- a/drivers/uio/uio_aec.c
+++
ftrace is the flagship example.
And yes, agreed about timeouts.
Linus Torvalds wrote:
>On Wed, Nov 27, 2013 at 3:28 PM, H. Peter Anvin wrote:
>>
>> The timeout bit was an acknowledgment that some kind of batching
>> interface is necessary.
>
>That's just moronic. People would make up totally
On 11/27/13 at 12:50pm, Matt Fleming wrote:
> On Tue, 26 Nov, at 01:57:45PM, Dave Young wrote:
> > Hi,
> >
> > Here is the V4 resend for supporting kexec kernel efi runtime.
> > Per pervious discussion I pass the 1st kernel efi runtime mapping
> > via setup_data to 2nd kernel. Besides of the
(2013/11/27 22:35), Oleg Nesterov wrote:
> On 11/27, Masami Hiramatsu wrote:
>>
>> (2013/11/27 2:50), Oleg Nesterov wrote:
>>> On 11/26, Oleg Nesterov wrote:
Note: this doesn't work for modules, but module's per-cpu data is
not visible for kallsyms_lookup_name() anyway.
>>>
>>>
On Wed, Nov 27, 2013 at 3:28 PM, H. Peter Anvin wrote:
>
> The timeout bit was an acknowledgment that some kind of batching
> interface is necessary.
That's just moronic. People would make up totally random timeouts, so
from an interface standpoint it's just horrid, horrid.
Giving user space
From: Wu Zhangjin
During the booting of an embedded Linux system, before decompressing the kernel
image, the bootloader(E.g. Uboot) loads the compressed kernel image and ramdisk
image into two contiguous memory spaces, these two memory spaces are fixed
after the Uboot is released, as a result,
On 11/27/2013 06:43 PM, Dan Carpenter wrote:
> On Wed, Nov 27, 2013 at 12:24:22PM +0800, Chen Gang wrote:
>> On 11/27/2013 12:03 PM, Greg KH wrote:
>>> On Wed, Nov 27, 2013 at 11:48:08AM +0800, Chen Gang wrote:
dev_*() assumes 'go' is already initialized, so need use pr_*() instead
of
This patch is to allow kdump 2nd kernel to wake up multiple CPUs,
a continuing work from:
[PATCH v3 0/2] x86, apic, kdump: Disable BSP if boot cpu is AP
https://lkml.org/lkml/2013/10/16/300.
At v4, basic design has changed. Now users need to figure out initial
APIC ID of BSP in the 1st
From: Zhi Yong Wu
Since vhost_dev_init() forever return 0, some branches are never run,
therefore need to be removed.
Signed-off-by: Zhi Yong Wu
Acked-by: Michael S. Tsirkin
---
drivers/vhost/net.c |5 -
drivers/vhost/scsi.c |5 -
drivers/vhost/test.c |5 -
3 files
From: Zhi Yong Wu
Signed-off-by: Zhi Yong Wu
---
drivers/net/macvtap.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index eeb1a97..155d60e 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -588,7
From: Zhi Yong Wu
Signed-off-by: Zhi Yong Wu
---
drivers/net/macvtap.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index dc76670..eeb1a97 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -780,8 +780,6
From: Zhi Yong Wu
Per David's request, it's time to resend them now.
Zhi Yong Wu (4):
vhost: remove the dead branch
vhost: adjust vhost_dev_init() to be void
macvtap: remove the dead branch
macvtap: adjust macvtap_skb_to_vnet_hdr() to be void
drivers/net/macvtap.c |8 ++--
From: Zhi Yong Wu
Signed-off-by: Zhi Yong Wu
Acked-by: Michael S. Tsirkin
---
drivers/vhost/net.c |4 ++--
drivers/vhost/scsi.c |2 +-
drivers/vhost/test.c |3 +--
drivers/vhost/vhost.c |4 +---
drivers/vhost/vhost.h |2 +-
5 files changed, 6 insertions(+), 9
Hi Kim,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
> Sent: Wednesday, November 27, 2013 4:19 PM
> To: Chao Yu
> Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net; '谭姝'
> Subject: RE: [f2fs-dev] [PATCH]
This patch removes CONFIG_MTD_PARTITIONS in config files for arm.
Because CONFIG_MTD_PARTITIONS was removed by commit
6a8a98b22b10f1560d5f90aded4a54234b9b2724.
---
I resend this patch because i forgot signoff.
--
arch/arm/configs/acs5k_defconfig|1 -
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki
> Sent: Wednesday, November 27, 2013 8:29 AM
>
> On Tuesday, November 26, 2013 03:29:05 PM Konrad Rzeszutek Wilk wrote:
> > On Tue, Nov 26, 2013 at 09:29:33PM +0100, Rafael J.
> Hi Eunbong,
>Acked-by: Greg Ungerer
>Did you want me to pick this up for the m68knommu git tree?
Hello, Greg.
I'm glad if you pick up this patch.
Thanks
EunBong
On Wed, 27 Nov 2013, Johannes Weiner wrote:
> > The memcg oom killer has incurred a serious regression since the 3.12-rc6
> > kernel where this was merged as 4942642080ea ("mm: memcg: handle non-error
> > OOM situations more gracefully"). It cc'd sta...@kernel.org although it
> > doesn't
Hi Eunbong,
On 27/11/13 11:48, Eunbong Song wrote:
> This patch removes CONFIG_MTD_PARTITIONS in config files for m68k.
> Because CONFIG_MTD_PARTITIONS was removed by commit
> 6a8a98b22b10f1560d5f90aded4a54234b9b2724.
>
> Signed-off-by: Eunbong Song
Acked-by: Greg Ungerer
Did you want me to
Hi Kent,
On Tue, 26 Nov 2013 16:39:49 -0800 Kent Overstreet wrote:
>
> From 46e7081430f5f483906f496733a23f8e9d898879 Mon Sep 17 00:00:00 2001
> From: Kent Overstreet
> Date: Tue, 26 Nov 2013 16:36:49 -0800
> Subject: [PATCH] block: Silence spurious compiler warnings
>
> Signed-off-by: Kent
On Tuesday, November 26, 2013 7:00 AM, Bjorn Helgaas wrote:
> On Sat, Nov 23, 2013 at 5:17 PM, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > After commit bcdde7e221a8 (sysfs: make __sysfs_remove_dir() recursive)
> > I'm seeing traces analogous to the one below in Thunderbolt
On 11/26/13 07:19, Masanari Iida wrote:
> Correct spelling typo within various drivers.
>
> Signed-off-by: Masanari Iida
> ---
> diff --git a/net/atm/Kconfig b/net/atm/Kconfig
> index 754ea10..1e6de99 100644
> --- a/net/atm/Kconfig
> +++ b/net/atm/Kconfig
> @@ -35,7 +35,7 @@ config
On Wed, Nov 27, 2013 at 10:16:47PM +0100, Pali Rohár wrote:
> On Monday 25 November 2013 22:50:01 Sebastian Reichel wrote:
> > > 2 seems more generic to me, but as rx51-battery is missing
> > > the functionality to send events on temperature change, I
> > > guess 1 will be easier to implement.
> >
On Wed, 27 Nov 2013, Johannes Weiner wrote:
> > The patch is drawing the line at "the kernel can no longer do anything to
> > free memory", and that's the line where userspace should be notified or a
> > process killed by the kernel.
> >
> > Giving current access to memory reserves in the oom
(2013/11/28 0:10), Vivek Goyal wrote:
On Wed, Nov 27, 2013 at 11:00:48AM +0900, HATAYAMA Daisuke wrote:
Add disable_cpu_apicid kernel parameter. To use this kernel parameter,
specify an initial APIC ID of the corresponding CPU you want to
disable.
This is mostly used for the kdump 2nd kernel
On Wed, Nov 27, 2013 at 11:45:24AM -0800, Olof Johansson wrote:
> On Mon, Nov 25, 2013 at 11:46 AM, Jason Cooper wrote:
> > On Mon, Nov 25, 2013 at 07:39:25PM +, Jason Cooper wrote:
> >> The following commit:
> >>
> >> 54f8d501e842 dmaengine: remove DMA unmap from drivers
> >>
> >> removed
On Sat, Nov 23, 2013 at 12:09:24AM +, Mel Gorman wrote:
> On Fri, Nov 22, 2013 at 11:05:24PM +, Mel Gorman wrote:
> > On Fri, Nov 22, 2013 at 03:28:07PM -0600, Alex Thorlton wrote:
> > > > If the warning added by that patch does *not* trigger than can you also
> > > > test this patch? It
On 11/27/2013 03:40 PM, Borislav Petkov wrote:
>
> But I'd guess that depends on the uarch because Bulldozer, reportedly,
> implements MFENCE by causing a pipeline stall which controls the
> prefetches too:
>
An implementation can always make the memory model stronger, but not weaker.
One reason why I like having a syscall is that if there is some
CPU which needs additional workarounds here it could be all
done in a central place (I don't know of any that does right now
but traditionally it has been a bug intensive area)
> Hmm? It doesn't sound too bad. And I really don't see
On Wed, Nov 27, 2013 at 03:20:07PM -0800, H. Peter Anvin wrote:
> No. MFENCE doesn't serialize the front end.
So my manual says
"The MFENCE instruction is weakly-ordered with respect to data and
instruction prefetches. Speculative loads initiated by the processor, or
specified explicitly using
PHY configuration set in pch_gbe_phy_init_setting() by mii_ethtool_sset() was
immedeiately reset by two calls of pch_gbe_phy_sw_reset().
Result of this bug was that module parameters like AutoNeg were ignored
silently.
Signed-off-by: Ondrej Puzman
---
The driver should not touch netdev tx_queue_len when changing link speed.
Signed-off-by: Ondrej Puzman
---
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h|2 --
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c |5 -
2 files changed, 0 insertions(+), 7 deletions(-)
diff --git
According to Documentation/networking/driver.txt the ndo_start_xmit method
should not return NETDEV_TX_BUSY under normal circumstances.
Stop the transmit queue when tx_ring is full.
Signed-off-by: Ondrej Puzman
---
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c |4
1 files
Add dynamic queue limits support to the driver.
Signed-off-by: Ondrej Puzman
---
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
Update efi-stub.txt documentation to be more general
and not x86 specific. Add ARM only "dtb=" command
line option description.
Signed-off-by: Roy Franz
---
Documentation/efi-stub.txt | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git
On Wed, 27 Nov 2013, Johannes Weiner wrote:
> > We don't give __GFP_NOFAIL allocations access to memory reserves in the
> > page allocator and we do call the oom killer for them so that a process is
> > killed so that memory is freed. Why do we have a different policy for
> > memcg?
>
> Oh
On Wed, Nov 27, 2013 at 03:08:30PM -0800, David Rientjes wrote:
> On Thu, 17 Oct 2013, a...@linux-foundation.org wrote:
>
> > diff -puN
> > mm/memcontrol.c~mm-memcg-handle-non-error-oom-situations-more-gracefully
> > mm/memcontrol.c
> > ---
> >
On Wed, Nov 27, 2013 at 02:44:58PM +0100, Thomas Gleixner wrote:
> On Wed, 27 Nov 2013, Russell King - ARM Linux wrote:
>
> > On Wed, Nov 27, 2013 at 01:32:31PM +, Russell King - ARM Linux wrote:
> > > On Wed, Nov 27, 2013 at 02:29:41PM +0100, Thomas Gleixner wrote:
> > > > Though the kobject
On Wed, Nov 27, 2013 at 12:08:04PM -0500, Johannes Weiner wrote:
> On Tue, Nov 26, 2013 at 10:17:16AM +1100, Dave Chinner wrote:
> > On Sun, Nov 24, 2013 at 06:38:25PM -0500, Johannes Weiner wrote:
> > > Reclaim will be leaving shadow entries in the page cache radix tree
> > > upon evicting the
This patch series adds EFI stub support for the ARM architecture. The
stub for ARM is implemented in a similar manner to x86 in that it is a
shim layer between EFI and the normal zImage/bzImage boot process, and
that an image with the stub configured is bootable as both a zImage and
EFI
Both ARM and ARM64 stubs will update the device tree
that they pass to the kernel. In both cases they
primarily need to add the same UEFI related information,
so the function can be shared.
Create a new FDT related file for this to avoid use
of architecture #ifdefs in efi-stub-helper.c
Change EFI
The shared efi-stub-helper.c functions require a strstr
implementation.
Implementation copied from arch/x86/boot/string.c
Signed-off-by: Roy Franz
Reviewed-by: Grant Likely
---
arch/arm/boot/compressed/string.c | 21 +
1 file changed, 21 insertions(+)
diff --git
Signed-off-by: Roy Franz
---
arch/arm/Kconfig | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a1b4758..6601985 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1857,6 +1857,16 @@ config EFI
This option is only useful
This patch adds EFI stub support for the ARM Linux kernel. The EFI stub
operates similarly to the x86 stub: it is a shim between the EFI firmware
and the normal zImage entry point, and sets up the environment that the
zImage is expecting. This includes loading the initrd (optionaly) and
device
The ARM decompressor/EFI stub do not implement the functions
(__stack_chk_guard_setup, etc) that are required for support of
stack protection. The actual enablement of stack protection is
controlled by heuristics in GCC, which the code added for the EFI
stub triggers when CONFIG_STACKPROTECTOR is
On 11/27/2013 03:15 PM, Linus Torvalds wrote:
>
> Oh, I agree. The interface of the original patch was just inane/insane.
>
> The timeout and the callback is pointless. The only thing the system
> call should get as an argument is the address and the replacement
> instruction. So
>
> int
On 11/27/2013 03:10 PM, Borislav Petkov wrote:
> On Wed, Nov 27, 2013 at 02:40:04PM -0800, H. Peter Anvin wrote:
>> Also don't forget we need the IPIs, too...
>
> Yeah, I was simply looking at whether we could get away with executing
> an empty syscall, i.e. save us the CPUID and rely only on the
On Wed, Nov 27, 2013 at 01:51:20PM -0800, David Rientjes wrote:
> On Wed, 27 Nov 2013, Johannes Weiner wrote:
>
> > > > But more importantly, OOM handling is just inherently racy. A task
> > > > might receive the kill signal a split second *after* userspace was
> > > > notified. Or a task may
On Tue, Nov 26, 2013 at 04:44:08PM +0900, Chanwoo Choi wrote:
> Hi Greg,
>
> This is extcon fixes pull request for 3.13-rc2. I add detailed description of
> this pull request on below. Please pull extcon fixes with following updates.
>
> The following changes since commit
Change in subject line + wider forum
On 19:24-20131127, Sekhar Nori wrote:
> On Wednesday 27 November 2013 07:17 PM, Daniel Mack wrote:
> > On 11/27/2013 02:35 PM, Sekhar Nori wrote:
> >> On Monday 18 November 2013 03:49 AM, Daniel Mack wrote:
> >>> +static int edma
On Wed, Nov 27, 2013 at 2:53 PM, H. Peter Anvin wrote:
>
> If we are going to go down that route, I would like to see a list of
> patch sites, not just one with a "timeout" that won't get used.
Oh, I agree. The interface of the original patch was just inane/insane.
The timeout and the callback
On Wed, Nov 27, 2013 at 03:04:41PM -0800, Linus Torvalds wrote:
> So sysexit/sysret doesn't count as a serializing instruction, no.
> But it doesn't need to, because *self*-modifying code doesn't need a
> serializing instruction, only a branch. It's only *cross*-modifying
> code that needs a
Um, do you have a definition somewhere (like in comments) of the definition
of the accuracy you're using? So multiple people can add consistent values?
Is this the standard deviation (67% confidence), 2 standard deviations
(95%), 3 (99%), or something else?
What averaging time is this computed
On Wed, Nov 27, 2013 at 02:40:04PM -0800, H. Peter Anvin wrote:
> Also don't forget we need the IPIs, too...
Yeah, I was simply looking at whether we could get away with executing
an empty syscall, i.e. save us the CPUID and rely only on the IPIs and
IRET.
But we don't IPI ourselves in
On Thu, 17 Oct 2013, a...@linux-foundation.org wrote:
> diff -puN
> mm/memcontrol.c~mm-memcg-handle-non-error-oom-situations-more-gracefully
> mm/memcontrol.c
> --- a/mm/memcontrol.c~mm-memcg-handle-non-error-oom-situations-more-gracefully
> +++ a/mm/memcontrol.c
> @@ -2161,110 +2161,59 @@
On Wed, Nov 27, 2013 at 2:31 PM, H. Peter Anvin wrote:
> No, we're not... sysexit/sysret doesn't count.
So sysexit/sysret doesn't count as a serializing instruction, no. But
it doesn't need to, because *self*-modifying code doesn't need a
serializing instruction, only a branch. It's only
At Wed, 27 Nov 2013 14:45:04 +,
Ben Hutchings wrote:
>
> [1 ]
> [1.1 ]
> This is the combined patch for 3.2.53-rc1 relative to 3.2.52.
This kernel can be built and boot without any problem.
- Build Machine: debian jessy x86_64
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
On Wed, Nov 27, 2013 at 03:13:40AM -0800, Christoph Hellwig wrote:
> Thanks Aurelien,
>
> the added comment looks good and very useful,
>
> Reviewed-by: Christoph Hellwig
>
Thanks for the review.
> We don't have any man pages documenting these ioctls or other user
> visible documentation, do
On Wed, Nov 27, 2013 at 01:38:59PM -0800, David Rientjes wrote:
> On Wed, 27 Nov 2013, Johannes Weiner wrote:
>
> > > Ah, this is because of 3168ecbe1c04 ("mm: memcg: use proper memcg in
> > > limit
> > > bypass") which just bypasses all of these allocations and charges the
> > > root
> > >
On 11/27/2013 02:41 PM, Linus Torvalds wrote:
> On Wed, Nov 27, 2013 at 2:02 PM, H. Peter Anvin wrote:
>> For the record, this is the entire patch necessary to do the
>> sync_cores() system call -- and no potential interactions with security
>> frameworks or whatnot, simply because no
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/
tags/tty-3.13-rc2
for you to fetch changes up to
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/
tags/staging-3.13-rc2
for you to fetch changes up to
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/
tags/driver-core-3.13-rc2
for you to fetch changes up to
On Wed, Nov 27, 2013 at 05:16:34PM -0300, Arnaldo Carvalho de Melo wrote:
> From: Jean Pihet
>
> Use the per-feature check flags for the unwinding feature in order to
> correctly compile the libunwind and libunwind-debug-frame feature
> checks.
>
> Tested on ARMv7 and ARMv8 with 'make DEBUG=1
On Wed, Nov 27, 2013 at 2:02 PM, H. Peter Anvin wrote:
> For the record, this is the entire patch necessary to do the
> sync_cores() system call -- and no potential interactions with security
> frameworks or whatnot, simply because no security-sensitive operations
> are performed of any kind.
>
>
On 11/27/2013 02:29 PM, Borislav Petkov wrote:
> On Wed, Nov 27, 2013 at 02:25:29PM -0800, H. Peter Anvin wrote:
>> Actually the CPUID is superfluous on anything than the executing CPU
>> since IRET is serializing.
>
> Why not on the executing core too? We're IRET-ting there too.
>
> Which would
This fixes the following compilation error when compiling in module:
drivers/i2c/busses/i2c-bcm-kona.c:894:1: error: ‘__mod_of_device_table’
aliased to undefined symbol ‘kona_i2c_of_match’
Signed-off-by: Vincent Stehlé
Cc: Wolfram Sang
Cc: triv...@kernel.org
---
Hi,
Compilation breakage
On Wed, Nov 27, 2013 at 12:13:25PM -0500, Matt Porter wrote:
> On Tue, Nov 26, 2013 at 03:53:32PM +0530, Kishon Vijay Abraham I wrote:
> > Hi,
> >
> > On Monday 25 November 2013 11:46 PM, Matt Porter wrote:
> > > If a generic phy is present, call phy_init()/phy_exit(). This supports
> > > generic
No, we're not... sysexit/sysret doesn't count.
Borislav Petkov wrote:
>On Wed, Nov 27, 2013 at 02:25:29PM -0800, H. Peter Anvin wrote:
>> Actually the CPUID is superfluous on anything than the executing CPU
>> since IRET is serializing.
>
>Why not on the executing core too? We're IRET-ting there
On 11/26/2013 11:12 AM, Greg Kroah-Hartman wrote:
-
NOTE:
This is the LAST 3.11.x kernel I will be releasing. Everyone should
be moving to the 3.12.x series at this point in time. After this
kernel is released, 3.11 will be end-of-life.
On 11/26/2013 05:56 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.10.21 release.
There are 80 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 know.
Responses should be
On Wed, Nov 27, 2013 at 02:25:29PM -0800, H. Peter Anvin wrote:
> Actually the CPUID is superfluous on anything than the executing CPU
> since IRET is serializing.
Why not on the executing core too? We're IRET-ting there too.
Which would mean that a dummy empty syscall would be enough too since
On 11/26/2013 05:56 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.4.71 release.
There are 39 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 know.
Responses should be
Add a flag to tell the PCI subsystem that kernel is shutting down
in prepapration to kexec a kernel. Add code in PCI subsystem to use
this flag to clear Bus Master bit on PCI devices only in case of
kexec reboot. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=63861
and avoids any other
On 11/26/2013 05:56 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.12.2 release.
There are 116 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 know.
Responses should be
A strictly monotonically increasing sequence is normally used in
numbered lists as they provide an intuitive ordering of the elements.
However, in situations where race conditions can appear, this assumption
breaks down and you can end up with unpredictable results, leading to a
rather confusing
Correct.
Borislav Petkov wrote:
>On Wed, Nov 27, 2013 at 02:02:50PM -0800, H. Peter Anvin wrote:
>> For the record, this is the entire patch necessary to do the
>> sync_cores() system call -- and no potential interactions with
>security
>> frameworks or whatnot, simply because no
Actually the CPUID is superfluous on anything than the executing CPU since IRET
is serializing.
Borislav Petkov wrote:
>On Wed, Nov 27, 2013 at 02:02:50PM -0800, H. Peter Anvin wrote:
>> For the record, this is the entire patch necessary to do the
>> sync_cores() system call -- and no potential
101 - 200 of 1372 matches
Mail list logo
