twitter: linux.kernel - 26 new messages in 21 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* Loan Offer - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8de9d77f99f99e86?hl=en
* tracing/kprobes: Make Kconfig dependencies generic - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/f25a85a28b5e0740?hl=en
* tracking memory usage/leak in "inactive" field in /proc/meminfo? -- solved -
1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/59f0d2bf0a30f6a8?hl=en
* Stage: hv: Rename struct device_context and re-arrange the fields inside (re-
formatted) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/79777a8cc1e179ec?hl=en
* NO_HZ migration of TCP ack timers - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e86dd5c1a70294be?hl=en
* V4L/DVB: tm6000: fix mutex lock unbalance - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/922699b93398ea85?hl=en
* V4L/DVB: media/video/tlg2300: fix build when CONFIG_PM=n - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/585b67046deaf85d?hl=en
* V4L/DVB: timberdale: fix mfd build - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ade61eb98e995ca7?hl=en
* V4L/DVB: tm6000: only register after initialized - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8542034d825d2a03?hl=en
* V4L/DVB: Kbuild addition for TVP7002 driver - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/82c14ed323b0c0bb?hl=en
* V4L/DVB: TVP7002 driver for DM365 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b54a765ded4d3576?hl=en
* Staging:rtl8192e: fix comments style issue in r8180_93cx6.c This is a patch
to the r8180_93cx6.c file that fixes up the comments styling issues found by
the checkpatch.pl tool Signed-off-by: Tim Schofield <tim@weberpafrica.com> - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/4992bccfa92a2498?hl=en
* Staging: r8187se: Remove two private variables that have a fixed value - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/0ddd76ba030293c8?hl=en
* add_timer_on: in-kernel users _all_ buggy ? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/10ba4cd052c77aef?hl=en
* Staging: r8187se: Remove dead code from r8185b_init.c - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8fc6a7665bad31d8?hl=en
* Performance regression in scsi sequential throughput (iozone) due to "e084b -
page-allocator: preserve PFN ordering when __GFP_COLD is set" - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/0f198fe3053e9f98?hl=en
* KVM: SVM: Don't use kmap_atomic in nested_svm_map - 4 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b608877f8fa7c926?hl=en
* staging: r8187se: Miscellaneous cleanups - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ff63660903c66f17?hl=en
* powerpc: implement arch_scale_smt_power for Power7 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/891f3a14ac88e3fb?hl=en
* MM: Pass a PTE pointer to update_mmu_cache() rather than the PTE itself - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/d51f38966592b1f7?hl=en
* Weird deadlock when shutting down - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/9c698ef90b575d61?hl=en

==============================================================================
TOPIC: Loan Offer
http://groups.google.com/group/linux.kernel/t/8de9d77f99f99e86?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 7:40 am
From: Cesar Augusto

I am Cesar Augusto of Cesar Augusto® Corporation.
We give out loans to business people and individuals for just 3% interest
rate.We give out local and international loan via account transfer to
qualified
borrowers.

If you are interested in getting loan from our company,contact us with the
following details to help us send you our loan terms and repayment Plan.

===========================
FIRST NAME:...........
LAST NAME:.......
ADDRESS:................
COUNTRY:..............
PHONE NUMBER:.........
FAX NUMBER: ...........
OCCUPATION:...........
MONTHLY INCOME...........
AGE:...............
LOAN AMOUNT NEEDED:.......
LOAN DURATION:........
=============================
Mode of Payment:
* Payment by bank to bank transfer
=============================

Regards,
Cesar Augusto.
Email: cesaraugusto@qatar.io

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: tracing/kprobes: Make Kconfig dependencies generic
http://groups.google.com/group/linux.kernel/t/f25a85a28b5e0740?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Feb 18 2010 7:50 am
From: Frederic Weisbecker

On Thu, Feb 18, 2010 at 10:02:52AM -0500, Mike Frysinger wrote:
> On Thu, Feb 18, 2010 at 09:50, Frederic Weisbecker wrote:
> > On Thu, Feb 18, 2010 at 09:01:12AM -0500, Mike Frysinger wrote:
> >> > --- a/arch/Kconfig
> >> > +++ b/arch/Kconfig
> >> > @@ -123,6 +123,10 @@ config USE_GENERIC_SMP_HELPERS
> >> >
> >> > �config HAVE_REGS_AND_STACK_ACCESS_API
> >> > � � � �bool
> >> > + � � � help
> >> > + � � � � This symbol should be selected by an architecure if it supports
> >> > + � � � � the API needed to access registers and stack entries from pt_regs.
> >> > + � � � � For example the kprobes-based event tracer needs this API.
> >>
> >> a bit vague ... arent there headers/functions people could look at ?
> >> perhaps you're talking about the regset functions (which is an API to
> >> access registers in pt_regs) ? �or you're talking about asm/syscall.h
> >> (which is an API to access registers in pt_regs) ?
> >>
> >> i'm not asking to be a pain, i'm asking because i really havent a
> >> clue. �if i wanted to add support for this stuff to the Blackfin arch,
> >> i wouldnt know where to start. �even after reading this help i'd fall
> >> back to grepping arch/x86/ and trying to divine a starting point from
> >> there.
> >
> > If an arch support kprobes, it just needs to select
> > HAVE_REGS_AND_STACK_ACCESS_API to figure out quickly what is missing,
> > as gcc will barf every missing clues you need.
>
> so should this new Kconfig option have an appropriate depends on
> KPROBES or something ?

No, kprobes events need KPROBES and the above one, but KPROBES
alone can perfectely work without HAVE_REGS_AND_STACK_ACCESS_API.

> > For now it is stored is asm/ptrace.h, but that might be split in
> > the future, especially as ptrace has initially nothing related to
> > that. A documentation that deals with filenames or API enumerations
> > tend to be incidentally async with API evolutions.
>
> i dont expect there to be per-function documentation here ... such
> things below in the header files themselves (linux/regset.h is an
> example of how to approach this). but having a tip of reading a file
> or two (like HAVE_ARCH_TRACEHOOK) doesnt bit rot nearly as often. if
> the common API expected of headers hasnt yet been split, then i guess
> not much left to be done here.

Yeah. Once it's split up from ptrace, we can think about a more dedicated
header file and then it can be reasonable to put the header filename in the
documentation. But not for now IMHO.

== 2 of 3 ==
Date: Thurs, Feb 18 2010 8:10 am
From: Masami Hiramatsu

Mike Frysinger wrote:
>>
>> config HAVE_REGS_AND_STACK_ACCESS_API
>> bool
>> + help
>> + This symbol should be selected by an architecure if it supports
>> + the API needed to access registers and stack entries from pt_regs.
>> + For example the kprobes-based event tracer needs this API.
>
> a bit vague ... arent there headers/functions people could look at ?
> perhaps you're talking about the regset functions (which is an API to
> access registers in pt_regs) ? or you're talking about asm/syscall.h
> (which is an API to access registers in pt_regs) ?

We're talking about new API which was introduced by b1cf540f
(regs_get_argument_nth has been dropped on -tip tree anyway)

> i'm not asking to be a pain, i'm asking because i really havent a
> clue. if i wanted to add support for this stuff to the Blackfin arch,
> i wouldnt know where to start. even after reading this help i'd fall
> back to grepping arch/x86/ and trying to divine a starting point from
> there.

yeah, I think the comment might be better to refer that APIs are
in arch/*/include/asm/ptrace.h :)

Thank you,

--
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com

== 3 of 3 ==
Date: Thurs, Feb 18 2010 8:30 am
From: Masami Hiramatsu

Frederic Weisbecker wrote:
> On Thu, Feb 18, 2010 at 09:01:12AM -0500, Mike Frysinger wrote:
>>> --- a/arch/Kconfig
>>> +++ b/arch/Kconfig
>>> @@ -123,6 +123,10 @@ config USE_GENERIC_SMP_HELPERS
>>>
>>> config HAVE_REGS_AND_STACK_ACCESS_API
>>> bool
>>> + help
>>> + This symbol should be selected by an architecure if it supports
>>> + the API needed to access registers and stack entries from pt_regs.
>>> + For example the kprobes-based event tracer needs this API.
>>
>> a bit vague ... arent there headers/functions people could look at ?
>> perhaps you're talking about the regset functions (which is an API to
>> access registers in pt_regs) ? or you're talking about asm/syscall.h
>> (which is an API to access registers in pt_regs) ?
>>
>> i'm not asking to be a pain, i'm asking because i really havent a
>> clue. if i wanted to add support for this stuff to the Blackfin arch,
>> i wouldnt know where to start. even after reading this help i'd fall
>> back to grepping arch/x86/ and trying to divine a starting point from
>> there.
>
>
> If an arch support kprobes, it just needs to select
> HAVE_REGS_AND_STACK_ACCESS_API to figure out quickly what is missing,
> as gcc will barf every missing clues you need.

These APIs are needed for kprobe-tracer on ftrace(kernel/trace/trace_kprobe.c),
which is just a consumer of kprobes (so depends on CONFIG_KPROBES).

I mean, if you wanna figure out that, you have to select CONFIG_KPROBE_EVENT too :)
And then, gcc tries to compile trace_kprobe.c and quickly dumps error messages
what APIs are not found :)

> For now it is stored is asm/ptrace.h, but that might be split in
> the future, especially as ptrace has initially nothing related to
> that. A documentation that deals with filenames or API enumerations
> tend to be incidentally async with API evolutions.

yeah, now those APIs depend on pt_regs, so I put it in ptrace.h.

Thank you,

--
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com

==============================================================================
TOPIC: tracking memory usage/leak in "inactive" field in /proc/meminfo? --
solved
http://groups.google.com/group/linux.kernel/t/59f0d2bf0a30f6a8?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 7:50 am
From: "Chris Friesen"

On 02/16/2010 04:22 PM, Rik van Riel wrote:
> On 02/16/2010 04:26 PM, Chris Friesen wrote:
>
>> For the backtrace scenario I posted it seems like it might actually be
>> release_pages(). There seems to be a plausible call chain:
>>
>> __ClearPageLRU
>> release_pages
>> free_pages_and_swap_cache
>> tlb_flush_mmu
>> tlb_remove_page
>> zap_pte_range
>>
>> Does that seem right? In this case, tlb_remove_page() is called right
>> after page_remove_rmap() which ultimately results in clearing the
>> PageAnon bit.
>
> That is right - and pinpoints the fault for the memory leak
> on some third party code that fails to release a refcount on
> memory pages.

I think I've tracked down the source of the problem. Turns out one of
our vendors had misapplied a patch which ended up bumping the page count
an extra time.

Thanks to everyone that helped out.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Stage: hv: Rename struct device_context and re-arrange the fields
inside (re-formatted)
http://groups.google.com/group/linux.kernel/t/79777a8cc1e179ec?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 8:00 am
From: Haiyang Zhang

>
> Ok, I fixed the patch up, but it looks like you did not make this
> against the linux-next tree, but against Linus's tree, right? The code
> has changed since Linus's tree a bit in places (dead code was removed),
> and it conflicted with this patch.
>
> Next time please be more careful.

Thanks for fixing the patch!
And, I will ensure I use linux-next tree for future patches.

- Haiyang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: NO_HZ migration of TCP ack timers
http://groups.google.com/group/linux.kernel/t/e86dd5c1a70294be?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 8:10 am
From: Andi Kleen

> > > What should we do? Should we use mod_timer_pinned here? Or is this an issue
> >
> > Sounds like something that should be controlled by the cpufreq governour's
> > idle predictor? Only migrate if predicted idle time is long enough.
> > It's essentially the same problem as deciding how deeply idle to put
> > a CPU. Heavy measures only pay off if the expected time is long enough.
> >
>
> cpuidle infrastructure hs statistics about the idle times for
> all the cpus. Maybe we can look to use this infrastructure to decide
> whether to migrate timers or not?

Yes sorry I reallhy meant cpuidle when I wrote cpufreq.
That's what I suggested too.

But if the problem is lock contention on the target CPU that would
still not completely solve it, just make it less frequent depending
on the idle pattern.

-Andi

--
ak@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: V4L/DVB: tm6000: fix mutex lock unbalance
http://groups.google.com/group/linux.kernel/t/922699b93398ea85?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 8:10 am
From: Patch from Mauro Carvalho Chehab

From: Mauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

drivers/staging/tm6000/tm6000-cards.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

---

http://git.linuxtv.org/v4l-dvb.git?a=commit;h=955ac2240299dca3b878a4a19e72cd7463f996b0

diff --git a/drivers/staging/tm6000/tm6000-cards.c b/drivers/staging/tm6000/tm6000-cards.c
index 8297801..c0159a1 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -496,6 +496,7 @@ static int tm6000_init_dev(struct tm6000_core *dev)
}

twitter

Thursday, February 18, 2010

linux.kernel - 26 new messages in 21 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts