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
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
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
>
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:
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:
>>
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
> >
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:
>>
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:
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
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
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
>
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
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
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
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
> > > >
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
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
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
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
> >> >
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
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
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:
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,
ivate' 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 from next-20130319 for today.
--
Cheers,
Stephen Rothwells...@c
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
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?
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
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
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"
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
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
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
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
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
>>>
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.
>
>
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;
> >> -
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:
>>
>>>
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
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
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
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.
--
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
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
>>
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);
>>
>> -
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
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
>
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.
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
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
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
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
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
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
>> ---
>>
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:
>
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:
> >> >> >
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
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
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
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, yes. Don't remove module parameters,
2013/3/19 Andrew Morton :
> On Fri, 15 Mar 2013 17:53:59 +0100 Frederic Weisbecker
> wrote:
>
>> The posix cpu timer expiry time is stored in a union of
>> two types: a 64 bits field if we rely on scheduler precise
>> accounting, or a cputime_t if we rely on jiffies.
>>
>> This result in quite
On 03/19/2013 05:20 PM, William Hubbs wrote:
>
> I'm not following what you mean.
>
> The problem is that "/dev/root" should not be in /proc/mounts,
> since there is always another entry that points to the root file
> system.
>
You are getting the name from the root= command line option.
The
On Tue, Mar 19, 2013 at 04:17:11PM -0700, H. Peter Anvin wrote:
> On 03/19/2013 03:28 PM, William Hubbs wrote:
> > The issue is that /dev/root appears in /proc/mounts if you do not
> > boot with an initramfs, but /dev/root is not a device node. In the
> > past, udev created a symbolic link from
Particularly in oom conditions, it's troublesome that hugetlb memory is
not displayed. All other meminfo that is emitted will not add up to what
is expected, and there is no artifact left in the kernel log to show that
a potentially significant amount of memory is actually allocated as
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 more question before I apply it.
> >> >
> >> > Is there
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 Warren because I only found his report after I bisected
it
On 03/19/2013 04:48 PM, Yinghai Lu wrote:
>
> So do you mean we have to change all __pa_symbol before
> setup.c::setup_arch/find_low_pfn_range ?
> because only at that time max_low_pfn get setup.
>
No, I suspect the problem is that the debugging code fails to notice
that max_low_pfn isn't set
Currently workqueue->name[] is of flexible length. We want to use the
flexible field for something more useful and there isn't much benefit
in allowing arbitrary name length anyway. Make it fixed len capping
at 24 bytes.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c | 19 ---
Currently, when exposing attrs of an unbound workqueue via sysfs, the
workqueue_attrs of first_pwq() is used as that should equal the
current state of the workqueue.
The planned NUMA affinity support will make unbound workqueues make
use of multiple pool_workqueues for different NUMA nodes and
Hello,
There are two types of workqueues - per-cpu and unbound. The former
is bound to each CPU and the latter isn't not bound to any by default.
While the recently added attrs support allows unbound workqueues to be
confined to subset of CPUs, it still is quite cumbersome for
applications where
Unbound workqueues are going to be NUMA-affine. Add wq_numa_tbl_len
and wq_numa_possible_cpumask[] in preparation. The former is the
highest NUMA node ID + 1 and the latter is masks of possibles CPUs for
each NUMA node.
This patch only introduces these. Future patches will make use of
them.
Unbound workqueues are now NUMA aware. Let's add some control knobs
and update sysfs interface accordingly.
* Add kernel param workqueue.numa_disable which disables NUMA affinity
globally.
* Replace sysfs file "pool_id" with "pool_ids" which contain
node:pool_id pairs. This change is
Currently, an unbound workqueue has single current, or first, pwq
(pool_workqueue) to which all new work items are queued. This often
isn't optimal on NUMA machines as workers may jump around across node
boundaries and work items get assigned to workers without any regard
to NUMA affinity.
This
Currently, an unbound workqueue has only one "current" pool_workqueue
associated with it. It may have multple pool_workqueues but only the
first pool_workqueue servies new work items. For NUMA affinity, we
want to change this so that there are multiple current pool_workqueues
serving different
1 - 100 of 1444 matches
Mail list logo
