OK, nobody has comments. Ingo, please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/oleg/misc uprobes/core
Changes:
- fix the conflict with d24d7dbf which added the (unsafe) check
into create_trace_uprobe()
- drop "Kill the "uprobe != NULL" check in
The function nohz_kick_needed modifies NOHZ_IDLE flag that is used to update
the nr_busy_cpus of the sched_group.
When the sched_domain are updated (during the boot or because of the unplug of
a CPUs as an example) a null_domain is attached to CPUs. We have to test
likely(!on_null_domain(cpu)
The nr_busy_cpus field of the sched_group_power is sometime different from 0
whereas the platform is fully idle. This serie fixes 3 use cases:
- when some CPUs enter idle state while booting all CPUs
- when a CPU is unplug and/or replug
Change since V2:
- change the initialization to idle
On my smp platform which is made of 5 cores in 2 clusters, I have the
nr_busy_cpu field of sched_group_power struct that is not null when the
platform is fully idle. The root cause seems to be:
During the boot sequence, some CPUs reach the idle loop and set their
NOHZ_IDLE flag while waiting for
On 02/08/2013 10:14 PM, Srivatsa S. Bhat wrote:
> On 02/08/2013 09:11 PM, Russell King - ARM Linux wrote:
>> On Thu, Feb 07, 2013 at 11:41:34AM +0530, Srivatsa S. Bhat wrote:
>>> On 02/07/2013 09:44 AM, Rusty Russell wrote:
"Srivatsa S. Bhat" writes:
> On 01/22/2013 01:03 PM, Srivatsa S.
On Fri, Feb 8, 2013 at 6:57 PM, Mauro Carvalho Chehab
wrote:
> Em Wed, 06 Feb 2013 18:18:22 +0100
> Sebastian Hesselbarth escreveu:
>> On 02/06/2013 02:48 PM, Sylwester Nawrocki wrote:
>> > On 02/06/2013 09:03 AM, Sebastian Hesselbarth wrote:
>> >> This patch adds device tree parsing for
This driver adds support for Infineon's new SLB 9645 TT 1.2 I2C TPMs,
which supports clockstretching, combined reads and a bus speed of
up to 400khz. The device also has a new device id.
The driver works now also fine with device trees, so you can
instantiate your device by adding:
+ tpm {
On Thu, Feb 07, 2013 at 07:35:01PM -0500, Josh Boyer wrote:
> On Thu, Feb 07, 2013 at 02:15:02PM -0800, Andrew Morton wrote:
> > On Thu, 7 Feb 2013 16:57:42 -0500
> > Josh Boyer wrote:
> >
> > > Hi All,
> > >
> > > We've hit a weird error in Fedora using the 3.8-rcX kernels. It seems
> > > the
On Fri, Feb 08, 2013 at 09:30:05AM -0800, H. Peter Anvin wrote:
> On 02/08/2013 08:24 AM, Ville Syrjälä wrote:
> >>
> >> How have you tested it?
> >
> > I've tried it with my drm/kms atomic pageflip/modeset code. I also had
> > a small test module that did a couple of different sized get_user()
>
On Fri, 8 Feb 2013, Russell King - ARM Linux wrote:
> On Fri, Feb 08, 2013 at 03:51:25PM +0900, Joonsoo Kim wrote:
> > I try to put it into patch tracker, but I fail to put it.
> > I use following command.
> >
> > git send-email --to patc...@arm.linux.org.uk 0001-ARM-sched-correct~
> >
> >
This patch updates the UV HUB info for UV3. The "is_uv3_hub" and
"is_uvx_hub" (UV2 or UV3) functions are added as well as the addresses
and sizes of the MMR regions for UV3.
Signed-off-by: Mike Travis
Acked-by: Russ Anderson
Reviewed-by: Dimitri Sivanich
---
arch/x86/include/asm/uv/uv_hub.h
Add UV3 to exclusion list. Instead of adding every new series of
SGI UV systems, just check oem_id to have a prefix of "SGI".
Signed-off-by: Mike Travis
Acked-by: Russ Anderson
Reviewed-by: Dimitri Sivanich
Cc: Jiang Liu
Cc: Bjorn Helgaas
Cc: Yinghai Lu
Cc: Greg Kroah-Hartman
---
This patch checks current hub support to avoid panicing the
system until all the GRU changes for UV3+ are in place.
Signed-off-by: Dimitri Sivanich
Signed-off-by: Mike Travis
---
drivers/misc/sgi-gru/grufile.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
Kernel updates for SGI Ultraviolet system 3 (UV3).
The new MMR definitions are added, and then the updates to each module
are applied. Afterwards, a "trim" patch reduces the size of the MMR
definitions file by about a third. This keeps "bi-sectability" in place.
--
To unsubscribe from this
This patch adds support for the SGI UV3 hub to the common x2apic
functions. The primary changes are to account for the similarities
between UV2 and UV3 which are encompassed within the "UVX" nomenclature.
One significant difference within UV3 is the handling of the MMIOH
regions which are
This patch updates time support for the SGI UV3 hub. Since the UV2
and UV3 time support is identical, "is_uvx_hub" is used instead of
having both "is_uv2_hub" and "is_uv3_hub".
Signed-off-by: Mike Travis
Acked-by: Russ Anderson
Reviewed-by: Dimitri Sivanich
---
arch/x86/platform/uv/uv_time.c
On Fri, 25 Jan 2013 18:10:18 -0800 (PST)
Hugh Dickins wrote:
> Complaints are rare, but lockdep still does not understand the way
> ksm_memory_callback(MEM_GOING_OFFLINE) takes ksm_thread_mutex, and
> holds it until the ksm_memory_callback(MEM_OFFLINE): that appears
> to be a problem because
=
[ 313.271340] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
[ 313.277542] 3.8.0-rc6-next-20130208-sasha-00028-ge4e162d #278 Tainted: G
W
[ 313.277542] --
[ 313.277542] kworker/u:3/4490 [HC0[0]:SC0[0]
From: syrine tlili
Date: Fri, 8 Feb 2013 15:35:52 +0100
> --- linux-3.8-rc6-vanilla/arch/x86/platform/efi/efi.c 2013-02-01
> 02:08:14.0 +0100
Your email client corrupted the patch by breaking up long lines
amongst other things.
Please read Documentation/email-clients.txt to learn how
On Fri, Feb 08, 2013 at 09:06:52AM -0800, H. Peter Anvin wrote:
> On 02/08/2013 07:28 AM, Russell King - ARM Linux wrote:
> >
> > Whether that's safe for x86 or not, I don't know, but my suspicions are
> > that it's unsafe on x86 as it's possible to refer to the various bytes/
> > half-words of
On 01/16/2013 07:53 AM, Peter Ujfalusi wrote:
> Gather the global variables under a single structure and allocate it with
> devm_kzalloc(). It is easier to see them and if in the future we try to add
> support for multiple instance of twl in the system it is going to be much
> simpler.
>
>
On Fri, 8 Feb 2013 16:53:17 +0100
Frederic Weisbecker wrote:
> 2013/2/7 Christoph Lameter :
> > On Thu, 7 Feb 2013, Frederic Weisbecker wrote:
> >
> >> Not with hrtick.
> >
> > hrtick? Did we not already try that a couple of years back and it turned
> > out that the overhead of constantly
On 02/06/2013 06:18 PM, Sebastian Hesselbarth wrote:
>>> +Optional properties:
>>> +- linux,allowed-rc-protocols: Linux specific u64 bitmask of allowed
>>> +rc protocols.
>>
>> You likely need to specify in these bindings documentation which bit
>> corresponds to which RC protocol.
>>
Em Fri, 8 Feb 2013 19:12:31 +0100
Sebastian Hesselbarth escreveu:
> On Fri, Feb 8, 2013 at 6:57 PM, Mauro Carvalho Chehab
> wrote:
> > Em Wed, 06 Feb 2013 18:18:22 +0100
> > Sebastian Hesselbarth escreveu:
> >> On 02/06/2013 02:48 PM, Sylwester Nawrocki wrote:
> >> > On 02/06/2013 09:03 AM,
I just wanted to give a heads up so you knew where I'm at and that I
haven't forgotten to do the bisection. Well, I'm doing the bisection - and
it's having me chase wild geese. This bug is apparently not always occuring
when it's possible for it to, confusing the issue.
Currently
Yes, or anything else getting a pointer in memory from user space.
"Ville Syrjälä" wrote:
>On Fri, Feb 08, 2013 at 09:30:05AM -0800, H. Peter Anvin wrote:
>> On 02/08/2013 08:24 AM, Ville Syrjälä wrote:
>> >>
>> >> How have you tested it?
>> >
>> > I've tried it with my drm/kms atomic
On 02/08, Andrey Wagin wrote:
>
> 2013/2/7 Oleg Nesterov :
> > Andrey, sorry for delay.
> >
> > As for API, I leave this to you and Michael. Not that I like these
> > new flags, but I agree that pread() hack was not pretty too.
> >
> > On 01/29, Andrey Vagin wrote:
> >> +static ssize_t
Writing to MSRs should not be allowed unless CAP_COMPROMISE_KERNEL is
set since it could lead to execution of arbitrary code in kernel mode.
Signed-off-by: Kees Cook
---
This would be used on top of Matthew Garrett's existing "Secure boot
policy support" patch series.
---
arch/x86/kernel/msr.c
On 02/08, Michael Kerrisk (man-pages) wrote:
>
> I'd greatly prefer names that really say what these things are. Thus:
>
> SFD_PROCESS_QUEUE + SFD_THREAD_QUEUE
> or
> SFD_PROCESS_WIDE_QUEUE + SFD_PER_THREAD_QUEUE
> or
> SFD_PROCESS_Q + SFD_THREAD_Q
> or
> [some consistent variation of the above]
We already have CAP_RAWIO for this in mainline; I am not sure if this should be
harder than that...
Kees Cook wrote:
>Writing to MSRs should not be allowed unless CAP_COMPROMISE_KERNEL is
>set since it could lead to execution of arbitrary code in kernel mode.
>
>Signed-off-by: Kees Cook
>---
On Fri, 2013-02-08 at 11:12 -0800, Kees Cook wrote:
> Writing to MSRs should not be allowed unless CAP_COMPROMISE_KERNEL is
> set since it could lead to execution of arbitrary code in kernel mode.
Willing to buy this, but do you have a description of one potential
approach? We should probably
No. CAP_RAWIO is for reading. Writing needs a much stronger check.
-Kees
On Fri, Feb 8, 2013 at 11:17 AM, H. Peter Anvin wrote:
> We already have CAP_RAWIO for this in mainline; I am not sure if this should
> be harder than that...
>
> Kees Cook wrote:
>
>>Writing to MSRs should not be
On Fri, Feb 8, 2013 at 11:17 AM, Matthew Garrett
wrote:
> On Fri, 2013-02-08 at 11:12 -0800, Kees Cook wrote:
>> Writing to MSRs should not be allowed unless CAP_COMPROMISE_KERNEL is
>> set since it could lead to execution of arbitrary code in kernel mode.
>
> Willing to buy this, but do you have
From: chas williams - CONTRACTOR
Date: Fri, 8 Feb 2013 09:58:42 -0500
> On Fri, 8 Feb 2013 11:19:11 +0100
> Heiko Carstens wrote:
>
>> We have conflicting type qualifiers for "freg_t" in s390's ptrace.h and the
>> iphase atm device driver, which causes the compile error below.
>> Unfortunately
From: "David Laight"
Date: Fri, 8 Feb 2013 10:23:08 -
> It is much better to define constants for the bit values and
> explicitly mask them as required.
Yes, __be32/__le32 along with bit define macros is the only reasonable
way to do this kind of stuff.
--
To unsubscribe from this list:
On Fri, Feb 08, 2013 at 01:38:29AM +, Cong Wang wrote:
> On Thu, 07 Feb 2013 at 19:32 GMT, Sasha Levin wrote:
> > Hi guys,
> >
> > I got the following while fuzzing with trinity inside a KVM tools guest:
> >
> > [ 51.680236] ===
> > [ 51.681914] [ INFO:
On Fri, 2013-02-08 at 11:21 -0800, Kees Cook wrote:
> On Fri, Feb 8, 2013 at 11:17 AM, Matthew Garrett
> wrote:
> > On Fri, 2013-02-08 at 11:12 -0800, Kees Cook wrote:
> >> Writing to MSRs should not be allowed unless CAP_COMPROMISE_KERNEL is
> >> set since it could lead to execution of arbitrary
Hi Linus,
On Fri, Feb 08, 2013 at 02:37:58PM +0100, Linus Walleij wrote:
> Hi Sam,
>
> could you please pull these changes into your MFD branch for the
> next merge window?
>
> These should be merged on top of Lee Jones' patch stack and
> deal with how the GPIO IRQs are handled.
>
> I based
irq_alloc_descs and irq_reserve_irqs are almost the same.
Separate code out to __irq_reserved_irqs, and other two reuse
__irq_reserve_irqs.
And will use __irq_reserve_irqs for coming ioapic hotplug support.
Signed-off-by: Yinghai Lu
---
include/linux/irq.h |1 +
kernel/irq/irqdesc.c |
create_irq() will return -1 when fail to allocate.
create_irq_nr() will return 0 when fail to allocate.
Will use it to fix one return vaule checking for dmar_msi irq.
Signed-off-by: Yinghai Lu
Cc: Tony Luck
Cc: Fenghua Yu
Cc: linux-i...@vger.kernel.org
---
arch/ia64/kernel/irq_ia64.c | 10
For physical hot plug should be ok, but for remove/rescan path will
need us to disable that.
otherwise rescan mmio resource for pci ioapic device will not be
sized and allocated, aka skiped.
For ioapic_probe:pci_enable_device will not enable the device
correctly, and will bail out early.
So we
Address compiling problem that Fengguang report.
Reported-by: Fengguang Wu
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/mpspec.h | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
index
We need to have ioapic setup before normal pci drivers.
otherwise other pci driver can not setup irq.
Make ioapic built-in, so can call add/remove during host-bridge add/remove
the same as the booting path.
Also need to make it depends on X86_IO_APIC.
Signed-off-by:
---
Now MSI-X is shown as MSI in /proc/interrupt.
We could use new added irq_print_chip() interface to append -X for MSI-X.
-v2: do not need to check if msi_desc is null in msi_irq_print_chip().
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
For ioapic hotplug support, we need to reserve irq range for hot
added ioapic controller. After that we need to allocate those
pre-reserved one.
Add realloc_irq_and_cfg_at() to really allocate irq_desc and cfg
as pre-reserved only hold bit in allocate_irqs bit maps.
Signed-off-by: Yinghai Lu
All others are using "-" instead of "_".
Change dmar_msi and hpet_msi to use "-".
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Change position only.
Prepare to update arch_early_irq_init(), it needs call some static functions.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 89
1 file
1. check overlaping gsi range
for hotplug ioapic case, BIOS may have some entries in MADT
and also have setting in pci root bus with _GSB of DSDT.
2. make bad_ioapics check idx instead of nr_ioapics.
for hotadd ioapic could find spare slot in the middle later.
3. check if entries is in right
It needs to reserve irq range in allocated_irqs bitmaps
and irq_base will be used to get right irq for ioapic/pin or gsi.
Signed-off-by: Yinghai Lu
Cc: Paul Gortmaker
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/include/asm/mpspec.h |1 +
create_irq() will return -1 when fail to allocate.
create_irq_nr() will return 0 when fail to allocate.
It only causes confusing.
Now we have no user for create_irq(), so remove create_irq() for x86.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej
Now irq_2_pin list is own grown list.
We can use generic list to replace it so we could generic helper
functions to operate it.
Also make free_irq_cfg() free irq_2_pin list to support coming ioapic
hotplug.
Signed-off-by: Yinghai Lu
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
Cc:
Print out exact MSI or MSI-X instead of MSI/MSI-X.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/io_apic.c
Checking the id in register, if that is duplicated, will pick one and
update that to register.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 41 +---
1 file
We could find out which device is using that MSI/MSI-X.
Use irq_print_chip() to append pci device name.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c |9 ++---
drivers/iommu/irq_remapping.c |
It will free ioapic related irq_desc and also clear allocated_irqs bits.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/include/asm/mpspec.h |1 +
arch/x86/kernel/apic/io_apic.c | 42
When multiple ioapics get added and removed, we could have blank slots
in middle of ioapics array.
Add skip code for this case by checking nr_registers.
Signed-off-by: Yinghai Lu
Cc: Paul Gortmaker
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
Split alloc_ioapic_save_registers() from early_irq_init(),
so it will be per ioapic.
Will call that later for hot added ioapic.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/kernel/apic/io_apic.c | 22 +++---
For hot add ioapic, irq_base is not equal to gsi_base.
So we need a way to do mapping between gsi and irq.
Also remove irq_to_gsi that is causing confusing, just use that array
directly as only caller already check input irq before.
Signed-off-by: Yinghai Lu
Cc: Pavel Machek
Cc: Joerg Roedel
Hi Wei,
On Fri, Feb 08, 2013 at 03:24:27PM +0800, wei_w...@realsil.com.cn wrote:
> From: Wei WANG
>
> Realtek card reader supports both SD and MS card. According to the
> settings of rtsx MFD driver, SD host will be probed before MS host.
> If we boot/reboot Linux with SD card inserted, the
On Thu, Jan 03, 2013 at 06:54:18PM +0100, Michal Hocko wrote:
> Now that per-node-zone-priority iterator caches memory cgroups rather
> than their css ids we have to be careful and remove them from the
> iterator when they are on the way out otherwise they might hang for
> unbounded amount of time
On Tue, 5 Feb 2013, Mel Gorman wrote:
> On Fri, Jan 25, 2013 at 06:01:59PM -0800, Hugh Dickins wrote:
> > Switching merge_across_nodes after running KSM is liable to oops on stale
> > nodes still left over from the previous stable tree. It's not something
> > that people will often want to do,
Hi,
Current x86 code does not support iapic hotplug yet.
This patcheset will try to pre-reserve irq block in allocated_irqs bitmap.
for hot add ioapic controller, also record irq_base in gsi_config, so later
could use it to convert gsi to irq for pci device using that ioapic controller.
Need to
iommu irq's irq_desc should be on local node ram.
Fix the return value checking problem.
create_irq() will return -1 when fail to allocate.
create_irq_nr() will return 0 when fail to allocate.
here only check !irq, so need to change it to use create_irq_nr instead.
Signed-off-by: Yinghai Lu
We pre-reserve irq range for hot-added ioapic, and later only
some are used via realloc.
So during hot-remove, we need to clear bits in allocated_irqs
for both case.
Check if the irq_desc is there at first, and bail out early if
irq_desc is not allocated yet.
So we can use irq_free_descs to
We will use reserve/realloc_irq_and_cfg_at for hotplug ioapic path.
To make thing simple, we could make booting path use same code.
So all gsi range will be reserved at first, and realloc will really
allocated those irq_desc/cfg when it is used.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc:
Now after irq remapping is enabled, irq_chip fields are modified during
every irq setup.
Only need to change them one during we enable irq mapping.
Also change irq_remap_modify_chip_defaults() to __init.
We don't need to use #ifdef in irq_remap_modify_chips(), as
IRQ_REMAP only support x86_64
Change irq_remap_modify_chip_defaults() to static, as we have no
outside user.
Signed-off-by: Yinghai Lu
Cc: Joerg Roedel
Cc: Konrad Rzeszutek Wilk
Cc: Sebastian Andrzej Siewior
---
arch/x86/include/asm/irq_remapping.h |6 --
drivers/iommu/irq_remapping.c|2 +-
2 files
We will pre-reserve irq for all gsi at first for x86, so we have to
use realloc with it.
Signed-off-by: Yinghai Lu
Cc: Konrad Rzeszutek Wilk
Cc: xen-de...@lists.xensource.com
---
drivers/xen/events.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git
Hi,
This patch adds very basic support for OMAP4 Blaze Tablet
software development platform.
The machine for this board is already registered under number 4516:
http://www.arm.linux.org.uk/developer/machines/list.php?id=4516
The work on this platform was going internally during last two years
The OMAP4 Blaze Tablet is TI OMAP4 processor-based
development platform in a tablet formfactor.
The platform contains many of the features found in
present-day handsets (such as audio, video, wireless
functions and user interfaces) and in addition
contains features for software development and
On 02/08/2013 11:18 AM, Kees Cook wrote:
No. CAP_RAWIO is for reading. Writing needs a much stronger check.
-Kees
If so, I suspect we need to do this for *all* raw I/O... but I keep
wondering how much more sensitive writing really is than reading.
-hpa
--
H. Peter Anvin, Intel
On Fri, 8 Feb 2013, Clark Williams wrote:
> I was a little apprehensive when you started talking about multiple
> tasks in Adaptive NOHZ mode on a core but the more I started thinking
> about it, I realized that we might end up in a cooperative multitasking
> mode with no tick at all going.
On Friday, February 08, 2013 09:57:18 AM Toshi Kani wrote:
> On Fri, 2013-02-08 at 01:24 +0100, Rafael J. Wysocki wrote:
> > On Monday, February 04, 2013 12:47:31 AM Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki
> > >
> > > The only useful thing that the ACPI container driver does is to
On Friday, February 08, 2013 08:06:52 PM Viresh Kumar wrote:
> On 8 February 2013 18:02, Rafael J. Wysocki wrote:
> > So as I said, please rework the fixes on top of linux-pm.git/pm-cpufreq.
>
> I already did. Please check for-rafael branch
Cool. This is the one I'm supposed to apply, then?
>
x86_schedule_events() creates a 512 byte automatic variable
when compiled for 64 bit. Dynamically allocate this array
to avoid possible stack corruption. Smatch analysis:
arch/x86/kernel/cpu/perf_event.c:727 x86_schedule_events() warn:
'constraints' puts 512 bytes on stack
Cc: Peter Zijlstra
On Fri, 8 Feb 2013, Woodhouse, David wrote:
> On Thu, 2013-02-07 at 18:13 +, Russell King - ARM Linux wrote:
> >
> > However, the biggest reason not to use libgcc is that we want to control
> > what gets used in the kernel - for example, no floating point, and no
> > use of 64 x 64bit
From: Stephen Warren
The intent is to ensure that all Tegra-related patches are sent to the
linux-tegra@ mailing list, so people can keep up-to-date on all misc
driver changes.
Doing this with a keyword is far simpler and more compact than listing
all Tegra-related drivers, even if wildcards
Josh Boyer writes:
> On Thu, Feb 07, 2013 at 07:35:01PM -0500, Josh Boyer wrote:
>> On Thu, Feb 07, 2013 at 02:15:02PM -0800, Andrew Morton wrote:
>> > On Thu, 7 Feb 2013 16:57:42 -0500
>> > Josh Boyer wrote:
>> >
>> > > Hi All,
>> > >
>> > > We've hit a weird error in Fedora using the
On Fri, Feb 8, 2013 at 11:42 AM, H. Peter Anvin wrote:
> On 02/08/2013 11:18 AM, Kees Cook wrote:
>>
>> No. CAP_RAWIO is for reading. Writing needs a much stronger check.
>
> If so, I suspect we need to do this for *all* raw I/O... but I keep
> wondering how much more sensitive writing really is
On Fri, Feb 8, 2013 at 8:10 PM, Oleg Nesterov wrote:
> On 02/08, Andrey Wagin wrote:
>>
>> 2013/2/7 Oleg Nesterov :
>> > Andrey, sorry for delay.
>> >
>> > As for API, I leave this to you and Michael. Not that I like these
>> > new flags, but I agree that pread() hack was not pretty too.
>> >
>>
On Mon, 4 Feb 2013 12:32:16 +0100, Philipp Zabel
wrote:
> This driver requests and remaps a memory region as configured in the
> device tree. It serves memory from this region via the genalloc API.
> It optionally enables the SRAM clock.
>
> Other drivers can retrieve the genalloc pool from a
1) Revert iwlwifi reclaimed packet tracking, it causes problems for a bunch
of folks. From Emmanuel Grumbach.
2) Work limiting code in brcmsmac wifi driver can clear tx status without
processing the event. From Arend van Spriel.
3) rtlwifi USB driver processes wrong SKB, fix from Larry
Analogy fail. The /dev/mem lockout applies to system RAM, not MMIO.
I fear COMPROMISE_KERNEL is becoming the new SYS_ADMIN, which in turn is the
new root. Why? Because it is inhebtly about a usage model, not about a
specific resource.
Kees Cook wrote:
>On Fri, Feb 8, 2013 at 11:42 AM, H.
On Fri, Feb 08, 2013 at 01:19:49PM -0500, Josh Boyer wrote:
> On Thu, Feb 07, 2013 at 07:35:01PM -0500, Josh Boyer wrote:
> > On Thu, Feb 07, 2013 at 02:15:02PM -0800, Andrew Morton wrote:
> > > On Thu, 7 Feb 2013 16:57:42 -0500
> > > Josh Boyer wrote:
> > >
> > > > Hi All,
> > > >
> > > >
On Wed, Feb 06, 2013 at 05:23:56PM +0100, Heiko Carstens wrote:
> CB710_CORE (drivers/misc/cb710/core.c) calls devm_request_irq() and
> therefore needs a GENERIC_HARDIRQS dependency to prevent a link
> error on s390.
>
> Cc: Arnd Bergmann
> Signed-off-by: Heiko Carstens
> ---
>
On Fri, Feb 08, 2013 at 12:23:00PM -0800, Greg KH wrote:
> On Wed, Feb 06, 2013 at 05:23:56PM +0100, Heiko Carstens wrote:
> > CB710_CORE (drivers/misc/cb710/core.c) calls devm_request_irq() and
> > therefore needs a GENERIC_HARDIRQS dependency to prevent a link
> > error on s390.
> >
> > Cc:
On Fri, Feb 08, 2013 at 12:13:09PM -0800, Eric W. Biederman wrote:
> Josh Boyer writes:
> >> Right, agreed. As I said, I think that is mostly a secondary issue.
> >> Hopefully it will be easy to fix once we figure out why we're getting
> >> the ENOMEM error.
> >>
> >> Python backtrace below.
Hi Michel,
On Sun, Feb 03, 2013 at 11:17:12PM -0800, Michel Lespinasse wrote:
> munlock_vma_pages_range() was always incrementing addresses by PAGE_SIZE
> at a time. When munlocking THP pages (or the huge zero page), this resulted
> in taking the mm->page_table_lock 512 times in a row.
>
> We
On Fri, Feb 8, 2013 at 12:18 PM, H. Peter Anvin wrote:
> Analogy fail. The /dev/mem lockout applies to system RAM, not MMIO.
Well, that's what I meant by it being "stronger".
> I fear COMPROMISE_KERNEL is becoming the new SYS_ADMIN, which in turn is the
> new root. Why? Because it is
On Thu, Feb 7, 2013 at 5:57 PM, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 3.0.63 release.
> There are 16 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.
>
>
Boris, could you check that this series also fixes the /dev/mem
problem you were seeing?
--
We have a new debugging check on x86 that has caught a number
of long-standing bugs. However, there is a _bit_ of collateral
damage with things that call __pa(high_memory).
We are now checking that any
On Thu, Feb 7, 2013 at 5:57 PM, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 3.4.30 release.
> There are 26 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.
>
>
I was auding the /dev/mem code for more questionable uses of
__pa(), and ran across this.
My assumption is that if you use /dev/kmem, you expect to be
able to read the kernel virtual mappings. However, those
mappings _stop_ as soon as we hit high memory. The
pfn_valid() check in here is good
On Thu, Feb 7, 2013 at 5:56 PM, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 3.7.7 release.
> There are 34 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.
>
>
This buffer overflow was introduced with
91e0c5f3dad47838cb2ecc1865ce789a0b7182b1
(2.6.24).
Cc: Konrad Rzeszutek Wilk
Cc: Jeremy Fitzhardinge
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: xen-de...@lists.xensource.com
Cc:
Josh Boyer writes:
> On Fri, Feb 08, 2013 at 01:19:49PM -0500, Josh Boyer wrote:
>> On Thu, Feb 07, 2013 at 07:35:01PM -0500, Josh Boyer wrote:
>> > On Thu, Feb 07, 2013 at 02:15:02PM -0800, Andrew Morton wrote:
>> > > On Thu, 7 Feb 2013 16:57:42 -0500
>> > > Josh Boyer wrote:
>> > >
>> > > >
On Fri, Feb 08, 2013 at 12:36:08PM -0800, Eric W. Biederman wrote:
> Josh Boyer writes:
> >> OK. I've bisected this down to:
> >>
> >> 50804fe3737ca6a5942fdc2057a18a8141d00141 is the first bad commit
> >> commit 50804fe3737ca6a5942fdc2057a18a8141d00141
> >> Author: Eric W. Biederman
> >> Date:
Josh Boyer writes:
> < Two emails fly past each other in the night >
Yep.
>> My best guess in some dark corner of mock has untested code to unshare a
>> pid namespace, and that corner started doing something now that
>> unsharing of the pid namespace actually works.
>>
>> If mock has called
On 02/08/2013 02:28 PM, Yinghai Lu wrote:
iommu irq's irq_desc should be on local node ram.
Fix the return value checking problem.
create_irq() will return -1 when fail to allocate.
create_irq_nr() will return 0 when fail to allocate.
here only check !irq, so need to change it to use
On 02/08/2013 12:28 PM, Dave Hansen wrote:
I was auding the /dev/mem code for more questionable uses of
__pa(), and ran across this.
My assumption is that if you use /dev/kmem, you expect to be
able to read the kernel virtual mappings. However, those
mappings _stop_ as soon as we hit high
801 - 900 of 1103 matches
Mail list logo
