On Tue, Mar 19, 2013 at 03:20:57PM +0100, Peter Zijlstra wrote:
> On Thu, 2013-02-14 at 14:48 +0900, Joonsoo Kim wrote:
> > Commit 88b8dac0 makes load_balance() consider other cpus in its group,
> > regardless of idle type. When we do NEWLY_IDLE balancing, we should not
> > consider it, because a m
Process connector can now also detect coredumping events.
Main aim of patch is get notified at start of coredumping, instead of having to
wait for it to finish and then being notified through EXIT event.
Could be used for instance by process-managers that want to get notified as
soon as possible
Hello, Peter.
On Tue, Mar 19, 2013 at 03:02:21PM +0100, Peter Zijlstra wrote:
> On Thu, 2013-02-14 at 14:48 +0900, Joonsoo Kim wrote:
> > After commit 88b8dac0, dst-cpu can be changed in load_balance(),
> > then we can't know cpu_idle_type of dst-cpu when load_balance()
> > return positive. So, ad
Add da850 EHRPWM & ECAP DT node.
Also adds OF_DEV_AUXDATA for EHRPWM & ECAP driver to use EHRPWM & ECAP
clock.
Signed-off-by: Philip Avinash
---
Changes since v1:
- Reusing ti,am33xx as compatible field as both IP's are
same with am33xx platform and da850 has no platform specifi
DAVINCI clock framework currently not supporting clock enable/disable
functionality on clock nodes. In DAVINCI platform EHRPWM module requires
support for clock enable/disable for TBCLK support. Hence this patch
adds support for enabling/disabling clocks depends on the availability
of the functiona
Add clock node support for ECAP and EHRPWM modules.
Also adds TBCLK for EHRWPM TBCLK to comply with pwm-tiehrpwm
driver.
Signed-off-by: Philip Avinash
---
Changes Since v1:
- TBCLK make it as actual clock with enable/disable feature.
:100644 100644 0c4a26d... dbed75c... M arch/arm/mach-
Add platform support for EHRPWM and ECAP by providing clock nodes and
device tree nodes.
This series depends on [1] and [2] and is available for testing at [3].
Tested for backlight support in da850 EVM with EHRPWM PWM device.
[1] http://gitorious.org/linux-davinci/linux-davinci/trees/davinci-for-
Add EHRPWM and ECAP support build support for DAVINCI_DA8XX platforms.
Also, since DAVINCI platforms doesn't support TI-PWM-Subsystem module,
remove the select option for CONFIG_PWM_TIPWMSS.
Also, update CONFIG_PWM_TIPWMSS compiler directive appropriately in
pwm-tipwmss.h to fix the below compile
On 03/20/2013 12:40 AM, Peter Hurley wrote:
with the hope of having the right people on CC now (finally, thanks
Lucas :-)), here's the same splat on -rc3. Someone better take a look
soonish, please:
Also happens in next (on nv50 hardware).
I think this is same as https://lkml.org/lkml/2013/3
the smp_release_cpus is a normal funciton and called in normal environments,
but it calls the __initdata spinning_secondaries.
need modify spinning_secondaries to match smp_release_cpus.
the related warning:
(the linker report boot_paca.33377, but it should be spinning_secondaries)
-
On 03/19/2013 08:58 PM, Eric Dumazet wrote:
> On Tue, 2013-03-19 at 05:10 -0700, Eric Dumazet wrote:
>> On Tue, 2013-03-19 at 17:25 +0800, Jason Wang wrote:
>>
>>> I believe before doing header check for untrusted packets, the only
>>> thing we can trust is skb->len and that's we've used before
>>>
On Tue, Mar 19, 2013 at 08:11:13AM +0100, Michal Hocko wrote:
> On Mon 18-03-13 20:07:16, Naoya Horiguchi wrote:
> > On Mon, Mar 18, 2013 at 04:40:57PM +0100, Michal Hocko wrote:
> > > On Thu 21-02-13 14:41:44, Naoya Horiguchi wrote:
...
> > > > @@ -536,6 +557,11 @@ static inline int check_pmd_rang
On 3/14/2013 12:20 AM, Ingo Molnar wrote:
>
> * Mike Travis wrote:
>
>>
>> There is an exception where the NMI_LOCAL notifier chain is used. When
>> the perf tools are in use, it's possible that our NMI was captured by
>> some other NMI handler and then ignored. We set a per_cpu flag for
>
2013/3/17 Huacai Chen :
> Currently, init_new_context() only for each online CPU, this may cause
> memory corruption when CPU hotplug and fork() happens at the same time.
> To avoid this, we make init_new_context() cover each possible CPU.
>
> Scenario:
> 1, CPU#1 is being offline;
> 2, On CPU#0, d
> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Wednesday, March 20, 2013 1:22 AM
> To: Venu Byravarasu
> Cc: gre...@linuxfoundation.org; st...@rowland.harvard.edu;
> ba...@ti.com; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-te...@vger
Hi Sedat,
On Wed, 20 Mar 2013 06:44:45 +0100 Sedat Dilek wrote:
>
> again I can read this offline before I have received it online (in my
> Gmail-account).
> Why shall I subscribe a ML when I am faster reading it offline?
> Whom to contact in such a case (ML-admin)?
Probably postmas...@vger.kern
On Tue, Mar 19, 2013 at 11:48 PM, Alan Stern wrote:
> On Tue, 19 Mar 2013, Yuan-Hsin Chen wrote:
>
>> > What about the port_status registers? They're not between command and
>> > async_next. If they aren't consistent with EHCI, it makes things a lot
>> > more complicated.
>>
>> fusbh200 has only
On Sat, Mar 16, 2013 at 02:33:23AM -0700, Raymond Jennings wrote:
> On Sat, Mar 16, 2013 at 2:25 AM, Hillf Danton wrote:
> >> Some system specifications:
> >> - CPU: i7 860 at 2.8 GHz
> >> - Mainboard: Advantech AIMB-780
> >> - RAM: 4 GB
> >> - Kernel: 2.6.35.11 SMP, 32 bit (kernel.org kernel, no
On 4 March 2013 13:07, Viresh Kumar wrote:
> Currently, there can't be multiple instances of single governor_type. If we
> have
> a multi-package system, where we have multiple instances of struct policy (per
> package), we can't have multiple instances of same governor. i.e. We can't
> have
> m
From: Lad, Prabhakar
export the symbols which are used by two modules vpif_capture and
vpif_display. renamed "ch_params" to "vpif_ch_params" so as to avoid
name collision.
This patch fixes following error:
ERROR: "ch_params" [drivers/media/platform/davinci/vpif_display.ko] undefined!
ERROR: "vpi
Lucas De Marchi writes:
> Hi Rusty,
>
> On Mon, Mar 18, 2013 at 11:32 PM, Rusty Russell wrote:
>> Andy Lutomirski writes:
>>> On Sun, Mar 17, 2013 at 7:24 PM, Rusty Russell
>>> wrote:
Andy Lutomirski writes:
> On Thu, Mar 14, 2013 at 10:03 PM, Rusty Russell
> wrote:
>> Err,
On Tue, 2013-03-19 at 23:16 -0400, Chen Gong wrote:
> On Tue, Mar 19, 2013 at 06:44:08PM -0400, Dave Jones wrote:
> > Date: Tue, 19 Mar 2013 18:44:08 -0400
> > From: Dave Jones
> > To: Linux Kernel
> > Cc: x...@kernel.org
> > Subject: cpu offline causes backtrace from cmci_rediscover
> > U
Hi Mauro,
On Wed, Mar 20, 2013 at 12:00 AM, Mauro Carvalho Chehab
wrote:
> Em Fri, 8 Mar 2013 16:19:07 +0530
> Prabhakar lad escreveu:
>
>> From: Lad, Prabhakar
>>
>> export the symbols which are used by two modules vpif_capture and
>> vpif_display.
>>
>> This patch fixes following error:
>> E
Hi Vinod,
On Wed, Mar 13, 2013 at 9:39 PM, Maxin B. John wrote:
> On Wed, Mar 13, 2013 at 1:53 AM, Fabio Estevam wrote:
>> From: Fabio Estevam
>>
>> Since commit 84c1e63c12 (dma: Remove erroneous __exit and __exit_p()
>> references)
>> the following section mismatch happens:
>>
>> WARNING: dri
On 20 March 2013 09:53, Viresh Kumar wrote:
> But when do you want me to call this function
Guess what, i got answer to this question: struct cpufreq_driver :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More ma
On Fri, 15 Mar 2013, Casey Schaufler wrote:
> Capabilities aren't just random attribute bits. They
> indicate that a task has permission to violate a
> system policy (e.g. change the mode bits of a file
> the user doesn't own).
Casey's right here, as well he should be.
--
James Morris
--
To u
Hi all,
Changes since 20130319:
The cgroup tree regained its build failure for which I have reverted a
commit.
The tty tree gained 2 build failures so I used the version from
next-20130319.
The char-misc tree lost its build failure.
The gpio tree still had its build failure for which I
Hi Alex,
Please note one point below.
On 02/18/2013 10:37 AM, Alex Shi wrote:
> This patch enabled the power aware consideration in load balance.
>
> As mentioned in the power aware scheduler proposal, Power aware
> scheduling has 2 assumptions:
> 1, race to idle is helpful for power saving
> 2,
RBC is to control whether some ANATOP sub modules
can enter lpm mode when SOC is into STOP mode, if
RBC is enabled and PMIC_VSTBY_REQ is set, ANATOP
will have below behaviors:
1. Digital LDOs(CORE, SOC and PU) are bypassed;
2. Analog LDOs(1P1, 2P5, 3P0) are disabled;
As the 2P5 is necessary for D
enable periphery charge pump for well biasing
at suspend to reduce periphery leakage.
Signed-off-by: Anson Huang
---
arch/arm/mach-imx/clk-imx6q.c | 22 +-
arch/arm/mach-imx/common.h|4 ++--
arch/arm/mach-imx/pm-imx6q.c |4 +++-
3 files changed, 26 insertions(+
Hi all,
On Wed, 13 Mar 2013 14:33:15 +0800 Li Zefan wrote:
>
> On 2013/3/13 13:12, Stephen Rothwell wrote:
> >
> > After merging the final tree, today's linux-next build (powerpc
> > allnoconfig) failed like this:
> >
> > In file included from include/linux/memcontrol.h:22:0,
> >
anatop module have sereval configurations for user
to reduce the power consumption in suspend, provide
suspend/resume interface for further use and enable
fet_odrive to reduce CORE LDO leakage during suspend.
Signed-off-by: Anson Huang
---
arch/arm/mach-imx/Kconfig |4
arch/arm/mac
On Wed, 2013-03-20 at 11:31 +0800, Mike Turquette wrote:
> Quoting Bill Huang (2013-03-19 19:55:49)
> > On Wed, 2013-03-20 at 01:01 +0800, Mike Turquette wrote:
> > > Quoting Bill Huang (2013-03-19 06:28:32)
> > > > Add notifier calls in clk_prepare and clk_unprepare so drivers which are
> > > > in
On 20 March 2013 05:50, Rafael J. Wysocki wrote:
> On Thursday, March 14, 2013 08:39:55 AM Viresh Kumar wrote:
>> On 14 March 2013 03:11, Rafael J. Wysocki wrote:
>> > On Tuesday, March 12, 2013 08:55:12 AM Viresh Kumar wrote:
>> >> On 12 March 2013 07:38, Rafael J. Wysocki wrote:
>> >> > One mo
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
include/linux/hyperv.h between commit 96dd86fa5881 ("Drivers: hv: Add a
new driver to support host initiated backup") from the char-misc tree
and commit "drivers/video: add Hyper-V Synthetic Video Frame Buffer
Driver" from the
On Wed, 20 Mar 2013, Martin Steigerwald wrote:
Am Dienstag, 29. Januar 2013 schrieb Daniel Phillips:
On Mon, Jan 28, 2013 at 5:40 PM, Theodore Ts'o wrote:
On Mon, Jan 28, 2013 at 04:20:11PM -0800, Darrick J. Wong wrote:
On Mon, Jan 28, 2013 at 03:27:38PM -0800, David Lang wrote:
The situati
On Tue, Mar 19, 2013 at 9:04 PM, David Lang wrote:
> On Wed, 20 Mar 2013, Martin Steigerwald wrote:
>
>> Am Dienstag, 29. Januar 2013 schrieb Daniel Phillips:
>>>
>>> On Mon, Jan 28, 2013 at 5:40 PM, Theodore Ts'o wrote:
On Mon, Jan 28, 2013 at 04:20:11PM -0800, Darrick J. Wong wrote:
>
On Mon, Mar 18, 2013 at 05:07:37PM +0100, Michal Hocko wrote:
> On Thu 21-02-13 14:41:47, Naoya Horiguchi wrote:
> > Currently we can't offline memory blocks which contain hugepages because
> > a hugepage is considered as an unmovable page. But now with this patch
> > series, a hugepage has become
On Wed, 20 Mar 2013 13:41:07 +1030 Rusty Russell wrote:
> Fengguang Wu writes:
> > On Tue, Mar 19, 2013 at 09:10:25AM -0400, Konrad Rzeszutek Wilk wrote:
> >> On Mon, Mar 18, 2013 at 11:50:58PM -0700, Andrew Morton wrote:
> >> > On Tue, 19 Mar 2013 14:31:40 +0800 kbuild test robot
> >> > wrote
On Tue, 2013-03-19 at 20:22 -0700, H. Peter Anvin wrote:
> On 03/19/2013 08:18 PM, Alex Williamson wrote:
> >>
> >> The "pinning" process needs to involve a call to the kernel to process
> >> the page for DMA (pinning the page and opening it in the iommu) and
> >> return a transaction address, of c
On 03/19/2013 08:18 PM, Alex Williamson wrote:
>>
>> The "pinning" process needs to involve a call to the kernel to process
>> the page for DMA (pinning the page and opening it in the iommu) and
>> return a transaction address, of course.
>>
>> I think we have the interface for that in vfio, but I
On Tue, Mar 19, 2013 at 06:44:08PM -0400, Dave Jones wrote:
> Date: Tue, 19 Mar 2013 18:44:08 -0400
> From: Dave Jones
> To: Linux Kernel
> Cc: x...@kernel.org
> Subject: cpu offline causes backtrace from cmci_rediscover
> User-Agent: Mutt/1.5.21 (2010-09-15)
>
> offlining a CPU in 3.9-rc3 gets
From: Sahara
Somehow tracepoint_entry_add/remove_probe functions allow a null probe
function. Especially on getting a null probe in remove function, it seems
to be used to remove all probe functions in the entry.
But, the code is not handled as expected. Since the tracepoint_entry
maintains funcs
On Tue, 2013-03-19 at 20:08 -0700, H. Peter Anvin wrote:
> On 03/19/2013 07:48 PM, H. Peter Anvin wrote:
> > On 03/19/2013 06:28 PM, Matthew Garrett wrote:
> >> Mm. The question is whether we can reliably determine the ranges a
> device should be able to access without having to trust userspace
> (
Ben Hutchings writes:
> This should also go to stable, so the downgrading issue doesn't continue
> to bite people.
Andy was complaining about experimental params going away: I haven't
heard a single complaint about the downgrading issue. I think it's a
nice to have, which is why I mentioned it.
Fengguang Wu writes:
> On Tue, Mar 19, 2013 at 09:10:25AM -0400, Konrad Rzeszutek Wilk wrote:
>> On Mon, Mar 18, 2013 at 11:50:58PM -0700, Andrew Morton wrote:
>> > On Tue, 19 Mar 2013 14:31:40 +0800 kbuild test robot
>> > wrote:
>> >
>> > > tree: git://git.kernel.org/pub/scm/linux/kernel/git
On Wed, 2013-03-20 at 12:00 +0900, Namhyung Kim wrote:
> On Tue, 19 Mar 2013 21:55:02 -0400, Steven Rostedt wrote:
> > On Wed, 2013-03-20 at 10:14 +0900, Namhyung Kim wrote:
> >> On Tue, 19 Mar 2013 10:50:02 -0400, Steven Rostedt wrote:
> >> > On Tue, 2013-03-19 at 17:53 +0900, Namhyung Kim wrote:
Commit-ID: c83a9d5e425d4678b05ca058fec6254f18601474
Gitweb: http://git.kernel.org/tip/c83a9d5e425d4678b05ca058fec6254f18601474
Author: Fenghua Yu
AuthorDate: Tue, 19 Mar 2013 08:04:44 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 19 Mar 2013 19:51:08 -0700
x86-32, microcode_intel_ea
ivers/usb/serial/quatech2.c:705:15: error: 'struct qt2_port_private' has no
member named 'is_open'
Caused by commit e4408ce3c23f ("TTY: quatech2, remove unneeded
is_open"). grep is your friend (or searching while editting the file).
I have used the tty tree
On 03/19/2013 07:48 PM, H. Peter Anvin wrote:
> On 03/19/2013 06:28 PM, Matthew Garrett wrote:
>> Mm. The question is whether we can reliably determine the ranges a device
>> should be able to access without having to trust userspace (and, ideally,
>> without having to worry about whether iommu v
On 03/19/2013 07:14 PM, Ren, Qiaowei wrote:
> Any comments on this patch?
>
> Thanks,
> Qiaowei
The biggest question is probably if we can use an existing hook of some
sort.
Overriding the apic method is probably not the right way to go, though.
tglx, do you have any opinions here?
Furthermore
On Tue, 19 Mar 2013 21:55:02 -0400, Steven Rostedt wrote:
> On Wed, 2013-03-20 at 10:14 +0900, Namhyung Kim wrote:
>> On Tue, 19 Mar 2013 10:50:02 -0400, Steven Rostedt wrote:
>> > On Tue, 2013-03-19 at 17:53 +0900, Namhyung Kim wrote:
>> >> free(version);
>> >> @@ -331,11 +354,12 @@ ssize_t trac
As the title indicates, I want to know how to add
a system call under the source code of version 3.8.2,
As It really puzzles me a lot on how the sys_call_table
get initialized,
Thanks.
--
--
To unsubscribe from this list: send the line "unsubscr
On Wed, 2013-03-20 at 01:01 +0800, Mike Turquette wrote:
> Quoting Bill Huang (2013-03-19 06:28:32)
> > Add notifier calls in clk_prepare and clk_unprepare so drivers which are
> > interested in knowing that clk_prepare/unprepare call can act accordingly.
> >
> > The existing "clk_set_rate" notifi
On 03/19/2013 06:28 PM, Matthew Garrett wrote:
> Mm. The question is whether we can reliably determine the ranges a device
> should be able to access without having to trust userspace (and, ideally,
> without having to worry about whether iommu vendors have done their job).
> It's pretty importa
On Tue, Mar 19, 2013 at 10:10:32PM +, Al Viro wrote:
> OK, it's going to be an interesting series - aforementioned tentative patch
> was badly incomplete ;-/
The interesting question is how far do we want to lift that. ->aio_write()
part is trivial - see vfs.git#experimental; the trouble beg
On Wed, 2013-03-20 at 09:50 +0800, Stephen Warren wrote:
> On 03/19/2013 07:39 PM, Danny Huang wrote:
> > On Wed, 2013-03-20 at 02:05 +0800, Stephen Warren wrote:
> >> On 03/18/2013 08:33 PM, Danny Huang wrote:
> >>> Add functions to read the speedo and process id of both cpu and soc.
> >>> There m
The current code makes the assumption that a cpu_base lock won't
be held if the CPU corresponding to that cpu_base is offline,
which isn't always true.
If a hrtimer is not queued, then it will not be migrated by
migrate_hrtimers() when a CPU is offlined. Therefore, the
hrtimer's cpu_base may still
Any comments on this patch?
Thanks,
Qiaowei
-Original Message-
From: Ren, Qiaowei
Sent: Thursday, October 11, 2012 6:11 PM
To: Thomas Gleixner; Ingo Molnar; H. Peter Anvin; x...@kernel.org
Cc: Maliszewski, Richard L; linux-kernel@vger.kernel.org;
tboot-de...@lists.sourceforge.net; Ren,
Hi Gregory,
>On 03/19/2013 05:43 PM, Gregory CLEMENT wrote:
>> On Tue, Mar 19, 2013 at 10:12:37PM +0900, Masami Hiramatsu wrote:
>>>
>>> Here I've hit a bug on the recent kernel. As far as I know, this bug
>>> exists on 3.9-rc1 too.
>>>
>>> When I tried the latest mvebu for-next tree
>>> (git://gi
Fenghua Yu wrote:
> From: Fenghua Yu
>
> In 32-bit, __pa_symbol() in CONFIG_DEBUG_VIRTUAL accesses kernel data (e.g.
> max_low_pfn) that haven't been setup yet in such early boot phase. To fix the
> issue, __pa_nodebug() replaces __pa_symbol() to get a global symbol's physical
> address.
>
> Sig
Hi Samuel,
On Tue, Mar 19, 2013 at 6:12 PM, Samuel Ortiz wrote:
> On Wed, Mar 20, 2013 at 01:56:52AM +0100, Samuel Ortiz wrote:
>> Hi Simon,
>>
>> On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote:
>> > The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
>> > used
Correct spelling typo in various drivers.
Signed-off-by: Masanari Iida
---
drivers/ata/sata_fsl.c| 2 +-
drivers/clk/mvebu/clk-core.c | 4 ++--
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/media/usb/dvb-usb/opera1.c| 2 +-
drivers/net/ethernet/ti/cpts.c
On Wed, 2013-03-20 at 10:24 +0900, Namhyung Kim wrote:
> >> @@ -61,8 +61,10 @@ static int do_read(int fd, void *buf, int size)
> >>if (repipe) {
> >>int retw = write(STDOUT_FILENO, buf, ret);
> >>
> >> - if (retw <= 0 || retw != ret)
> >> -
On Wed, 2013-03-20 at 10:14 +0900, Namhyung Kim wrote:
> On Tue, 19 Mar 2013 10:50:02 -0400, Steven Rostedt wrote:
> > On Tue, 2013-03-19 at 17:53 +0900, Namhyung Kim wrote:
> >>free(version);
> >> @@ -331,11 +354,12 @@ ssize_t trace_report(int fd, struct pevent
> >> **ppevent, bool __repipe)
On Wed, 2013-03-20 at 10:12 +0900, Namhyung Kim wrote:
> >> +++ b/tools/perf/util/trace-event-read.c
> >> @@ -293,7 +293,10 @@ ssize_t trace_report(int fd, struct pevent **ppevent,
> >> bool __repipe)
> >>int show_version = 0;
> >>int show_funcs = 0;
> >>int show_printk = 0;
> >> - s
On 03/19/2013 07:39 PM, Danny Huang wrote:
> On Wed, 2013-03-20 at 02:05 +0800, Stephen Warren wrote:
>> On 03/18/2013 08:33 PM, Danny Huang wrote:
>>> Add functions to read the speedo and process id of both cpu and soc.
>>> There might be some drivers need the information as well.
>>
>> What code
On 03/19/2013 07:42 PM, Danny Huang wrote:
> On Wed, 2013-03-20 at 01:54 +0800, Stephen Warren wrote:
>> On 03/18/2013 05:17 AM, Danny Huang wrote:
>>> Add speedo-based process identifictaion for Tegra114.
>>
>> I have applied this to Tegra's for-3.10/soc branch, with one addition below:
>>
>>> dif
This looks pretty good!
I rather like the (lack of) locking in I/O completion (around the req
count vs. target/queue binding). It is unfortunate that you need to
hold the per-target lock in virtscsi_pick_vq() though; have any idea
how much that lock hurts?
Just two minor comments:
(in struct
On Wed, 2013-03-20 at 01:54 +0800, Stephen Warren wrote:
> On 03/18/2013 05:17 AM, Danny Huang wrote:
> > Add speedo-based process identifictaion for Tegra114.
>
> I have applied this to Tegra's for-3.10/soc branch, with one addition below:
>
> > diff --git a/arch/arm/mach-tegra/tegra114_speedo.c
On Wed, 2013-03-20 at 02:05 +0800, Stephen Warren wrote:
> On 03/18/2013 08:33 PM, Danny Huang wrote:
> > Add functions to read the speedo and process id of both cpu and soc.
> > There might be some drivers need the information as well.
>
> What code wants to use these functions? It'd be best to s
On 03/19/2013 06:03 PM, Andreas Bombe wrote:
> The named commit (6402c796d3) causes a process to hang indefinitely in
> usb_kill_urb(). Reverting it fixes the problem. The bug also prevents
> suspend/shutdown/reboot from completing, presumably due to the hanging
> process.
>
> (Cc'ing Stephen Warr
Mm. The question is whether we can reliably determine the ranges a device
should be able to access without having to trust userspace (and, ideally,
without having to worry about whether iommu vendors have done their job). It's
pretty important for PCI passthrough, so we do need to care.
--
Mat
On Tue, 19 Mar 2013 10:55:28 -0400, Steven Rostedt wrote:
> On Tue, 2013-03-19 at 17:53 +0900, Namhyung Kim wrote:
>> From: Namhyung Kim
>>
>> Convert them to pr_debug() and propagate error code.
>
> Shouldn't they be pr_err(). I mean, if the old code would kill the
> process, why just keep it as
On Tue, 19 Mar 2013 10:54:27 -0400, Steven Rostedt wrote:
> On Tue, 2013-03-19 at 17:53 +0900, Namhyung Kim wrote:
>> From: Namhyung Kim
>>
>> Rename it to do_read and original do_read to __do_read, and check
>> their return value.
>>
>> Cc: Steven Rostedt
>> Cc: Frederic Weisbecker
>> Signed-
On Tue, 19 Mar 2013 10:50:02 -0400, Steven Rostedt wrote:
> On Tue, 2013-03-19 at 17:53 +0900, Namhyung Kim wrote:
>> free(version);
>> @@ -331,11 +354,12 @@ ssize_t trace_report(int fd, struct pevent **ppevent,
>> bool __repipe)
>>
>> page_size = read4(pevent);
>>
>> -read_heade
On Wed, Mar 20, 2013 at 01:56:52AM +0100, Samuel Ortiz wrote:
> Hi Simon,
>
> On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote:
> > The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
> > used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
>
On Tue, 19 Mar 2013 10:47:53 -0400, Steven Rostedt wrote:
> On Tue, 2013-03-19 at 17:53 +0900, Namhyung Kim wrote:
>
>> @@ -3100,7 +3105,7 @@ int perf_event__process_tracing_data(union perf_event
>> *event,
>> }
>> }
>>
>> -if (size_read + padding != size) {
>> +if (siz
On 03/19/2013 06:07 PM, Matthew Garrett wrote:
> Yeah, I'd like the option of relaxing restrictions when drivers explicitly
> opt in based on iommu support.
When drivers opt in they can provide an interface. The interesting case
becomes non-drivers.
-hpa
--
H. Peter Anvin, Intel Open
On Mon, Mar 18, 2013 at 1:11 PM, Mauro Carvalho Chehab
wrote:
> Em Tue, 26 Feb 2013 22:06:45 -0800
> Andrey Smirnov escreveu:
>
>> This patch adds all the functions used for exchanging commands with
>> the chip.
>
> Please run checkpatch.pl over those patches. There are a number of compliants
> o
Hi Kirill,
On 03/15/2013 01:50 AM, Kirill A. Shutemov wrote:
From: "Kirill A. Shutemov"
Here's the second version of the patchset.
The intend of the work is get code ready to enable transparent huge page
cache for the most simple fs -- ramfs.
We have read()/write()/mmap() functionality now. S
The cases I'd looked at seemed to mostly involve obsolete hardware or only
allow command submission to SCSI targets, so I wasn't too worried about them -
but, like I said, I've no inherent objection to using CAP_SYS_RAWIO as long as
we modify any cases where userspace really does need that acces
Yeah, I'd like the option of relaxing restrictions when drivers explicitly opt
in based on iommu support.
--
Matthew Garrett | matthew.garr...@nebula.com
On 03/19/2013 06:02 PM, H. Peter Anvin wrote:
>
> Looking at it in detail, EVERYTHING in CAP_SYS_RAWIO has the possibility
> of compromising the kernel, because they let device drivers be bypassed,
> which means arbitrary DMA, which means you have everything.
>
Well, *unless* you have an iommu t
Easiest way to do that would be to replace some existing users of CAP_RAW_IO
with CAP_SYS_ADMIN and then just insert a couple of extra RAW_IO checks. That
would break some existing userspace, but so would introducing a new capability.
I'm happy to go that way, but would appreciate some broader f
On 03/18/2013 09:47 PM, James Morris wrote:
> On Mon, 18 Mar 2013, Matthew Garrett wrote:
>
>> This patch introduces CAP_COMPROMISE_KERNEL.
>
> I'd like to see this named CAP_MODIFY_KERNEL, which is more accurate and
> less emotive. Otherwise I think core kernel developers will be scratching
Hi Naoya,
On 02/22/2013 03:41 AM, Naoya Horiguchi wrote:
Currently we can't offline memory blocks which contain hugepages because
a hugepage is considered as an unmovable page. But now with this patch
series, a hugepage has become movable, so by using hugepage migration we
can offline such memory
On 03/18/2013 02:32 PM, Matthew Garrett wrote:
>
> This means we can return our focus to the kernel. There's currently a number
> of kernel interfaces that permit privileged userspace to modify the running
> kernel. These are currently protected by CAP_SYS_RAWIO, but unfortunately
> the semantics
Hi Sasha,
On Wed, Mar 20, 2013 at 12:28 AM, Sasha Levin wrote:
> On 03/19/2013 07:54 AM, Ming Lei wrote:
>
> With v3 of the patch:
>
> [ 1275.665758] sysfs_dir_pos-973 sysfs_dirent use after free:
> tun(tun)-uevent, 2-1472641949
Thanks again for your test.
Looks it is caused by another bug in
On 03/18/2013 02:32 PM, Matthew Garrett wrote:
> IO port access would permit users to gain access to PCI configuration
> registers, which in turn (on a lot of hardware) give access to MMIO register
> space. This would potentially permit root to trigger arbitrary DMA, so lock
> it down by default.
>
On 2013/3/20 6:02, Tejun Heo wrote:
> It doesn't make sense to nest cgroup_mutex inside threadgroup_lock
> when it should be outer to most all locks used by all cgroup
> controllers. It was nested inside threadgroup_lock only because some
> controllers were abusing cgroup_mutex inside controllers
On Tue, 19 Mar 2013 16:04:03 +0100, Peter Zijlstra wrote:
> On Tue, 2013-03-19 at 10:59 -0400, Steven Rostedt wrote:
>> On Tue, 2013-03-19 at 15:49 +0100, Peter Zijlstra wrote:
>> > On Tue, 2013-03-19 at 10:35 -0400, Steven Rostedt wrote:
>> > > What about:
>> > > int err = 0;
>> > >
>> >
Hi Simon,
On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote:
> The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
> used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
> connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interru
Hi Steve,
On Tue, 19 Mar 2013 09:54:21 -0400, Steven Rostedt wrote:
> On Tue, 2013-03-19 at 17:53 +0900, Namhyung Kim wrote:
>> From: Namhyung Kim
>>
>> So that it can be used by other places.
>>
>> Cc: Steven Rostedt
>> Cc: Frederic Weisbecker
>> Signed-off-by: Namhyung Kim
>> ---
>> tools
On Tue, Mar 19, 2013 at 09:46:43PM +, Simon J. Rowe wrote:
> On 19/03/13 00:27, Guenter Roeck wrote:
> >Couple of problems I noticed when browsing through the code.
> >
> >- Some functions return errors with return code 0.
> >
> > if (ret <= 0)
> > goto out;
> > ...
> >out:
On Tue, Mar 19, 2013 at 8:32 PM, Andy Lutomirski wrote:
> On Tue, Mar 19, 2013 at 8:26 PM, Lucas De Marchi
> wrote:
>> Hi Rusty,
>>
>> On Mon, Mar 18, 2013 at 11:32 PM, Rusty Russell
>> wrote:
>>> Andy Lutomirski writes:
On Sun, Mar 17, 2013 at 7:24 PM, Rusty Russell
wrote:
> A
At Mon, 18 Mar 2013 13:10:29 +1030,
Rusty Russell wrote:
>
> Ben Hutchings writes:
> > On Fri, 2013-03-15 at 15:35 +1030, Rusty Russell wrote:
> >> Satoru Takeuchi writes:
> >> > At Thu, 14 Mar 2013 17:11:21 +1030,
> >> > Rusty Russell wrote:
> >> >>
> >> >> Satoru Takeuchi writes:
> >> >> > H
On Tue, Mar 19, 2013 at 8:26 PM, Lucas De Marchi
wrote:
> Hi Rusty,
>
> On Mon, Mar 18, 2013 at 11:32 PM, Rusty Russell wrote:
>> Andy Lutomirski writes:
>>> On Sun, Mar 17, 2013 at 7:24 PM, Rusty Russell
>>> wrote:
Andy Lutomirski writes:
> On Thu, Mar 14, 2013 at 10:03 PM, Rusty Ru
Hi Naoya,
On 03/19/2013 08:07 AM, Naoya Horiguchi wrote:
> On Mon, Mar 18, 2013 at 04:40:57PM +0100, Michal Hocko wrote:
>> On Thu 21-02-13 14:41:44, Naoya Horiguchi wrote:
>>> This patch extends check_range() to handle vma with VM_HUGETLB set.
>>> With this changes, we can migrate hugepage with mi
Serge Hallyn writes:
> Hi,
>
> Benoit was kind enough to follow up on some scalability issues with
> larger (but not huge imo) numbers of containers. Running a script
> to simply time the creation of veth pairs on a rather large (iiuc)
> machine, he got the following numbers (time is for creatio
1 - 100 of 716 matches
Mail list logo
