Quantcast
Channel: Serverphorums.com
Viewing all 23908 articles
Browse latest View live

Re: [PATCH] regmap: Fix possible shift overflow in regmap_field_init()

$
0
0
On Tue, Jun 16, 2015 at 01:53:19PM +0200, Maxime Coquelin wrote:
> The way the mask is generated in regmap_field_init() is wrong.
> Indeed, a field initialized with msb = 31 and lsb = 0 provokes a shift
> overflow while calculating the mask field.

Applied, thanks.

[PATCH v2] drivers/staging/comedi/drivers/pcl816.c: style fix

$
0
0
Removed some spaces before a tab character.

Signed-off-by: Guillermo O. Freschi <kedrot@gmail.com>
---
drivers/staging/comedi/drivers/pcl816.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/pcl816.c b/drivers/staging/comedi/drivers/pcl816.c
index 1ccb2f1..781b321 100644
--- a/drivers/staging/comedi/drivers/pcl816.c
+++ b/drivers/staging/comedi/drivers/pcl816.c
@@ -323,7 +323,7 @@ static int check_channel_list(struct comedi_device *dev,

/* check whole chanlist */
for (i = 0, segpos = 0; i < chanlen; i++) {
- if (chanlist != chansegment[i % seglen]) {
+ if (chanlist != chansegment[i % seglen]) {
dev_dbg(dev->class_dev,
"bad channel or range number! chanlist[%i]=%d,%d,%d and not %d,%d,%d!\n",
i, CR_CHAN(chansegment),
--
2.1.4

--
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/

Re: X86 GIT GCC 5 compilation warning

$
0
0
Hello,

On Mon, 15 Jun 2015, Borislav Petkov wrote:

> Hmm, so I did start my oS13.2 i386 guest:
>
> $ as --version
> GNU assembler (GNU Binutils; openSUSE 13.2) 2.24.0.20140403-6.1

That won't show the issue. Our binutils are compiled with support for
multiple targets, among them 64bit ones, and as I said, that makes the
internal value types be 64bit as well, and hence masks the warning.

You could compile binutils yourself in that i386 guest, without enabling
other than the host target to see the problem, but why would you want
that?

> $ gcc --version

Again, gcc doesn't enter the picture here, it's gas itself that warns if
it was compiled with the right (or wrong) options.

> $ cat t.s
> .text
> LOWMEM_PAGES = (((1<<32) - 0xc0000000) >> 12)
>
> mov LOWMEM_PAGES, %eax
>
> $ as t.s
> $

My self-compiled gas warns here.

> Do we have some bleeding edge gcc5 rpms somewhere I could try?

devel:gcc, but gcc is not the cause here.


Ciao,
Michael.
--
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/

Re: [PHP-DEV] PHP7 releases vs Windows Sources?

$
0
0
On Tue, 2015-06-16 at 02:02 +0200, Christoph Becker wrote:
> Johannes Schlüter wrote:
>
> > On Tue, 2015-06-16 at 00:02 +0200, Christoph Becker wrote:
> >
> >> Why should these downloads be disabled? They contain exactly what could
> >> be checked out from the respective tag.
> >
> > It is not including the generated parsers. This means the user might use
> > a different version, which might cause a bug which might be hard to
> > debug as usage of provided files is assumed.
>
> Fair enough. However, the Windows sources neither contain the generated
> parser files, because they would break linking on Windows, see
> http://news.php.net/php.internals/86685.

This is a bug and has to be addressed.

johannes



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PATCH 3/3] x86, perf, uncore: Don't make MSR uncore depend on PCI uncore

$
0
0
On Sun, 14 Jun 2015, Andi Kleen wrote:
> @@ -1287,27 +1289,17 @@ static void __init uncore_cpumask_init(void)
>
> static int __init intel_uncore_init(void)
> {
> - int ret;
> -
> if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
> return -ENODEV;
>
> if (cpu_has_hypervisor)
> return -ENODEV;
>
> - ret = uncore_pci_init();
> - if (ret)
> - goto fail;
> - ret = uncore_cpu_init();
> - if (ret) {
> - uncore_pci_exit();
> - goto fail;
> - }
> + uncore_pci_init();
> + uncore_cpu_init();
> uncore_cpumask_init();

So, even if the cpu does not support that, we install a completely
useless cpu notifier and invoke equally pointless init code on all
cores.

Sigh,


tglx
--
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/

Re: [PATCH v3] selinux: reduce locking overhead in inode_free_security()

$
0
0
On 06/15/2015 01:13 PM, Waiman Long wrote:
> The inode_free_security() function just took the superblock's isec_lock
> before checking and trying to remove the inode security struct from the
> linked list. In many cases, the list was empty and so the lock taking
> is wasteful as no useful work is done. On multi-socket systems with
> a large number of CPUs, there can also be a fair amount of spinlock
> contention on the isec_lock if many tasks are exiting at the same time.
>
> This patch changes the code to check the state of the list first before
> taking the lock and attempting to dequeue it. The list_del_init()
> can be called more than once on the same list with no harm as long
> as they are properly serialized. It should not be possible to have
> inode_free_security() called concurrently with list_add(). For better
> safety, however, we use list_empty_careful() here even though it is
> still not completely safe in case that happens.
>
> Signed-off-by: Waiman Long <Waiman.Long@hp.com>

Acked-by: Stephen Smalley <sds@tycho.nsa.gov>

> ---
> security/selinux/hooks.c | 17 ++++++++++++++---
> 1 files changed, 14 insertions(+), 3 deletions(-)
>
> v1->v2:
> - Take out the second list_empty() test inside the lock.
>
> v2->v3:
> - Fix incorrent comment and commit log message.
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 7dade28..2a99804 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -254,10 +254,21 @@ static void inode_free_security(struct inode *inode)
> struct inode_security_struct *isec = inode->i_security;
> struct superblock_security_struct *sbsec = inode->i_sb->s_security;
>
> - spin_lock(&sbsec->isec_lock);
> - if (!list_empty(&isec->list))
> + /*
> + * As not all inode security structures are in a list, we check for
> + * empty list outside of the lock to make sure that we won't waste
> + * time taking a lock doing nothing.
> + *
> + * The list_del_init() function can be safely called more than once.
> + * It should not be possible for this function to be called with
> + * concurrent list_add(), but for better safety against future changes
> + * in the code, we use list_empty_careful() here.
> + */
> + if (!list_empty_careful(&isec->list)) {
> + spin_lock(&sbsec->isec_lock);
> list_del_init(&isec->list);
> - spin_unlock(&sbsec->isec_lock);
> + spin_unlock(&sbsec->isec_lock);
> + }
>
> /*
> * The inode may still be referenced in a path walk and
>

--
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/

Re: [PATCH 3/6] mm, compaction: encapsulate resetting cached scanner positions

$
0
0
On 06/16/2015 07:41 AM, Joonsoo Kim wrote:
> On Wed, Jun 10, 2015 at 11:32:31AM +0200, Vlastimil Babka wrote:
>> Resetting the cached compaction scanner positions is now done implicitly in
>> __reset_isolation_suitable() and compact_finished(). Encapsulate the
>> functionality in a new function reset_cached_positions() and call it explicitly
>> where needed.
>>
>> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
>> Cc: Minchan Kim <minchan@kernel.org>
>> Cc: Mel Gorman <mgorman@suse.de>
>> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>> Cc: Michal Nazarewicz <mina86@mina86.com>
>> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>> Cc: Christoph Lameter <cl@linux.com>
>> Cc: Rik van Riel <riel@redhat.com>
>> Cc: David Rientjes <rientjes@google.com>
>> ---
>> mm/compaction.c | 22 ++++++++++++++--------
>> 1 file changed, 14 insertions(+), 8 deletions(-)
>>
>> diff --git a/mm/compaction.c b/mm/compaction.c
>> index 7e0a814..d334bb3 100644
>> --- a/mm/compaction.c
>> +++ b/mm/compaction.c
>> @@ -207,6 +207,13 @@ static inline bool isolation_suitable(struct compact_control *cc,
>> return !get_pageblock_skip(page);
>> }
>>
>> +static void reset_cached_positions(struct zone *zone)
>> +{
>> + zone->compact_cached_migrate_pfn[0] = zone->zone_start_pfn;
>> + zone->compact_cached_migrate_pfn[1] = zone->zone_start_pfn;
>> + zone->compact_cached_free_pfn = zone_end_pfn(zone);
>> +}
>> +
>> /*
>> * This function is called to clear all cached information on pageblocks that
>> * should be skipped for page isolation when the migrate and free page scanner
>> @@ -218,9 +225,6 @@ static void __reset_isolation_suitable(struct zone *zone)
>> unsigned long end_pfn = zone_end_pfn(zone);
>> unsigned long pfn;
>>
>> - zone->compact_cached_migrate_pfn[0] = start_pfn;
>> - zone->compact_cached_migrate_pfn[1] = start_pfn;
>> - zone->compact_cached_free_pfn = end_pfn;
>> zone->compact_blockskip_flush = false;
>
> Is there a valid reason not to call reset_cached_positions() in
> __reset_isolation_suitable?

Hm maybe not, except being somewhat implicit again. It might had a stronger
reason in the previous patchset.

> You missed one callsite in
> __compact_pgdat().
>
> if (cc->order == -1)
> __reset_isolation_suitable(zone);
>
> This also needs reset_cached_positions().

Ah, good catch. Thanks.

>
> Thanks.
>

--
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/

Re: [PATCH] net: fix search limit handling in skb_find_text()

$
0
0
В письме от 16 июня 2015 12:48:41 пользователь Pablo Neira Ayuso написал:
> On Mon, Jun 15, 2015 at 10:37:31PM +0300, Roman Khimov wrote:
> > В письме от 15 июня 2015 19:06:39 пользователь Pablo Neira Ayuso написал:
> > > On Mon, Jun 15, 2015 at 12:11:58PM +0300, Roman I Khimov wrote:
> > > > Suppose that we're trying to use an xt_string netfilter module to
> > > > match a
> > > > string in a specially crafted packet that has "a nice string" starting
> > > > at
> > > > offset 28.
> > > >
> > > > It could be done in iptables like this:
> > > >
> > > > -A some_chain -m string --string "a nice string" --algo bm --from 28
> > > > --to
> > > > 38 -j DROP
> > > >
> > > > And it would work as expected. Now changing that to
> > > >
> > > > -A some_chain -m string --string "a nice string" --algo bm --from 29
> > > > --to
> > > > 38 -j DROP
> > > >
> > > > breaks the match, as expected. But, if we try to make
> > > >
> > > > -A some_chain -m string --string "a nice string" --algo bm --from 20
> > > > --to
> > > > 28 -j DROP
> > > >
> > > > then it suddenly works again! So the 'to' parameter seems to be
> > > > inclusive,
> > > > not working as an offset after which no search should be done. OK, now
> > > > if
> > > > we try:
> > > >
> > > > -A some_chain -m string --string "a nice string" --algo bm --from 28
> > > > --to
> > > > 28 -j DROP
> > >
> > > Can you reproduce the same behaviour with the km algo?
> >
> > Will try tomorrow MSK time.
>
> Thanks, wait for your feedback on this.

Same behaviour with kmp.

> > > That will break existing setups for people that are
> > > relying on this behaviour. This has been exposed in this way for long
> > > time, so we should avoid that breakage.
> >
> > Yes, that could be an issue, but there are other skb_find_text() usages
> > and to me they suggest that the intended behaviour is to stop search at
> > 'to' offset.>
> > In nf_conntrack_amanda.c, for example:
> > start = skb_find_text(skb, dataoff, skb->len,
> >
> > search[SEARCH_CONNECT].ts);
> >
> > ...
> >
> > stop = skb_find_text(skb, start, skb->len,
> >
> > search[SEARCH_NEWLINE].ts);
> >
> > ...
> >
> > stop += start;
> >
> > ...
> >
> > off = skb_find_text(skb, start, stop, search.ts);
> >
> > First of all, nothing can ever match at skb->len, and second, it looks
> > like
> > the third usage is also expecting to search from offset 'start' to offset
> > 'stop', not to 'stop + 1'.
>
> Then, please fix the Amanda helper.
>
> Look, Amanda is an in-tree client of this textsearch infrastructure,
> so it's not exposed to userspace, we can fix it.
>
> But if we change the existing behaviour, users may be relying on it
> and we'll get things broken for them. Someone else will come later one
> with another patch to say: "hey, --to used to be inclusive but this is
> not the case anymore and it's breaking my setup".

I do understand your concerns, but fixing it this way would require changing
skb_seq_read() and basicaly would propagate "'to' offset included" semantics
(which seems a bit strange for programmers, IMO) further. And initially I
thought that changing skb_seq_read() would be more intrusive, although looking
at all this now it looks like the only real user of upper_offset field in
ts_config struct is skb_find_text(), because other invocations of
skb_seq_read() from drivers/scsi/libiscsi_tcp.c and net/batman-adv/main..c use
skb->len as an upper limit.

> > em_text_match() in net/sched/em_text.c is also suspicious.
>
> Please, elaborate.

The way it constructs 'to' offset, I think it doesn't expect something to
match at 'to'. Although I might be wrong here.

Re: [PATCH 4/6] mm, compaction: always skip compound pages by order in migrate scanner

$
0
0
On 06/16/2015 07:44 AM, Joonsoo Kim wrote:
> On Wed, Jun 10, 2015 at 11:32:32AM +0200, Vlastimil Babka wrote:

[...]

>> @@ -723,39 +725,35 @@ isolate_migratepages_block(struct compact_control *cc, unsigned long low_pfn,
>> * It's possible to migrate LRU pages and balloon pages
>> * Skip any other type of page
>> */
>> - if (!PageLRU(page)) {
>> + is_lru = PageLRU(page);
>> + if (!is_lru) {
>> if (unlikely(balloon_page_movable(page))) {
>> if (balloon_page_isolate(page)) {
>> /* Successfully isolated */
>> goto isolate_success;
>> }
>> }
>> - continue;
>> }
>>
>> /*
>> - * PageLRU is set. lru_lock normally excludes isolation
>> - * splitting and collapsing (collapsing has already happened
>> - * if PageLRU is set) but the lock is not necessarily taken
>> - * here and it is wasteful to take it just to check transhuge.
>> - * Check PageCompound without lock and skip the whole pageblock
>> - * if it's a transhuge page, as calling compound_order()
>> - * without preventing THP from splitting the page underneath us
>> - * may return surprising results.
>> - * If we happen to check a THP tail page, compound_order()
>> - * returns 0. It should be rare enough to not bother with
>> - * using compound_head() in that case.
>> + * Regardless of being on LRU, compound pages such as THP and
>> + * hugetlbfs are not to be compacted. We can potentially save
>> + * a lot of iterations if we skip them at once. The check is
>> + * racy, but we can consider only valid values and the only
>> + * danger is skipping too much.
>> */
>> if (PageCompound(page)) {
>> - int nr;
>> - if (locked)
>> - nr = 1 << compound_order(page);
>> - else
>> - nr = pageblock_nr_pages;
>> - low_pfn += nr - 1;
>> + unsigned int comp_order = compound_order(page);
>> +
>> + if (comp_order > 0 && comp_order < MAX_ORDER)
>> + low_pfn += (1UL << comp_order) - 1;
>> +
>> continue;
>> }
>
> How about moving this PageCompound() check up to the PageLRU check?
> Is there any relationship between balloon page and PageCompound()?

I didn't want to assume if there's a relationship or not, as per the changelog:

>> After this patch, all pages are tested for PageCompound() and we skip them by
>> compound_order(). The test is done after the test for balloon_page_movable()
>> as we don't want to assume if balloon pages (or other pages with own isolation
>> and migration implementation if a generic API gets implemented) are compound
>> or not.

> It will remove is_lru and code would be more understandable.

Right, it just felt safer and more future-proof this way.

> Otherwise,
>
> Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>
> Thanks.
>

--
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/

Re: [PATCH v3 1/2] locking/qrwlock: Better optimization for interrupt context readers

$
0
0
Hi Waiman,

On Mon, Jun 15, 2015 at 11:24:02PM +0100, Waiman Long wrote:
> The qrwlock is fair in the process context, but becoming unfair when
> in the interrupt context to support use cases like the tasklist_lock.
>
> The current code isn't that well-documented on what happens when
> in the interrupt context. The rspin_until_writer_unlock() will only
> spin if the writer has gotten the lock. If the writer is still in the
> waiting state, the increment in the reader count will cause the writer
> to remain in the waiting state and the new interrupt context reader
> will get the lock and return immediately. The current code, however,
> do an additional read of the lock value which is not necessary as the
> information have already been there in the fast path. This may sometime
> cause an additional cacheline load when the lock is highly contended.
>
> This patch passes the lock value information gotten in the fast path
> to the slow path to eliminate the additional read. It also clarify the
> action for the interrupt context readers more explicitly.
>
> Signed-off-by: Waiman Long <Waiman.Long@hp.com>
> ---
> include/asm-generic/qrwlock.h | 4 ++--
> kernel/locking/qrwlock.c | 14 ++++++++------
> 2 files changed, 10 insertions(+), 8 deletions(-)

[...]

> diff --git a/kernel/locking/qrwlock.c b/kernel/locking/qrwlock.c
> index 00c12bb..d7d7557 100644
> --- a/kernel/locking/qrwlock.c
> +++ b/kernel/locking/qrwlock.c
> @@ -43,22 +43,24 @@ rspin_until_writer_unlock(struct qrwlock *lock, u32 cnts)
> * queue_read_lock_slowpath - acquire read lock of a queue rwlock
> * @lock: Pointer to queue rwlock structure
> */
> -void queue_read_lock_slowpath(struct qrwlock *lock)
> +void queue_read_lock_slowpath(struct qrwlock *lock, u32 cnts)
> {
> - u32 cnts;
> -
> /*
> * Readers come here when they cannot get the lock without waiting
> */
> if (unlikely(in_interrupt())) {
> /*
> - * Readers in interrupt context will spin until the lock is
> - * available without waiting in the queue.
> + * Readers in interrupt context will get the lock immediately
> + * if the writer is just waiting (not holding the lock yet)
> + * or they will spin until the lock is available without
> + * waiting in the queue.
> */
> - cnts = smp_load_acquire((u32 *)&lock->cnts);
> + if ((cnts & _QW_WMASK) != _QW_LOCKED)
> + return;

I really doubt the check here is gaining you any performance, given
rspin_until_write_unlock does the same check immediately and should be
inlined. Just dropping the acquire and passing cnts through should be
sufficient.

Will
--
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/

Re: [PATCH 5/7] userfaultfd: switch to exclusive wakeup for blocking reads

$
0
0
On Mon, Jun 15, 2015 at 08:41:24PM -1000, Linus Torvalds wrote:
> On Mon, Jun 15, 2015 at 12:19 PM, Andrea Arcangeli <aarcange@redhat.com> wrote:
> >
> > Yes, it would leave the other blocked, how is it different from having
> > just 1 reader and it gets killed?
>
> Either is completely wrong. But the read() code can at least see that
> "I'm returning early due to a signal, so I'll wake up any other
> waiters".
>
> Poll simply *cannot* do that. Because by definition poll always
> returns without actually clearing the thing that caused the wakeup.
>
> So for "poll()", using exclusive waits is wrong very much by
> definition. For read(), you *can* use exclusive waits correctly, it
> just requires you to wake up others if you don't read all the data
> (either due to being killed by a signal, or because the read was
> incomplete).

There's no interface to do wakeone with poll so I haven't thought much
about it frankly but intuitively it didn't look radically different as
long as poll checks every fd revent it gets. If I was to patch it to
introduce wakeone in poll I'd think more about it of course. Perhaps
I've been overoptimistic here.

> What does qemu have to do with anything?
>
> We don't implement kernel interfaces that are broken, and that can
> leave processes blocked when they shouldn't be blocked. We also don't
> implement kernel interfaces that only work with one program and then
> say "if that program is broken, it's not our problem".

I'm testing with the stresstest application not with qemu, qemu cannot
take advantage of this anyway because it uses a single thread so far
and it uses poll not blocking reads. The stresstest suite listens to
events with one thread per CPU and it interleaves poll usage with
blocking reads at every bounce, and it's working correctly so far.

> > I'm not saying doing wakeone is easy [...]
>
> Bullshit, Andrea.
>
> That's *exactly* what you said in the commit message for the broken
> patch that I complained about. And I quote:

Please don't quote me out of context, and quote me in full if you
quote me:

"I'm not saying doing wakeone is easy and it's enough to flip a switch
everywhere to get it everywhere"

In the above paragraph (that you quoted in a truncated version of it)
I was talking in general, not specific to userfaultfd. I meant in
general wakeone is not easy.

> patch that I complained about. And I quote:
>
> "Blocking reads can easily use exclusive wakeups. Poll in theory
> could too but there's no poll_wait_exclusive in common code yet"

With "I'm not saying doing wakeone is easy and it's enough to flip a
switch everywhere to get it everywhere" I intended exactly to clarify
that "Blocking reads can easily use exclusive wakeups" was in the
context of userfaultfd only.

With regard to the patch you still haven't told what exactly what
runtime breakage I shall expect from my simple change. The case you
mentioned about a thread that gets killed is irrelevant because an
userfault would get missed anyway, if a task listening to userfaultfd
get killed after it received any uffd_msg structure. Wakeone or
wakeall won't move the needle for that case. There's no broadcast of
userfaults to all readers, even with wakeall, only the first reader
that wakes up, gets the messages, the others returns to sleep
immediately.
--
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/

Re: [alsa-devel][PATCH v2] ASoC: wm8960: add dapm kcontrols to select left/right ADC input source

$
0
0
On Tue, Jun 16, 2015 at 02:23:19PM +0800, Zidan Wang wrote:
> Add dapm kcontrols to select left/right ADC input source, one to select
> the left ADC input source and one for the right ADC input source.
>
> In default, the left ADC will select the left input, and the right ADC will
> select the right input. When the left(right) ADC select the right(left) input,
> the left(right) input path will be powered down.
>
> Signed-off-by: Zidan Wang <zidan.wang@freescale.com>
> ---
> sound/soc/codecs/wm8960.c | 24 ++++++++++++++++++++++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/codecs/wm8960.c b/sound/soc/codecs/wm8960.c
> index 023e898..3ea12b7 100644
> --- a/sound/soc/codecs/wm8960.c
> +++ b/sound/soc/codecs/wm8960.c
> @@ -141,6 +141,8 @@ static const char *wm8960_3d_upper_cutoff[] = {"High", "Low"};
> static const char *wm8960_3d_lower_cutoff[] = {"Low", "High"};
> static const char *wm8960_alcfunc[] = {"Off", "Right", "Left", "Stereo"};
> static const char *wm8960_alcmode[] = {"ALC", "Limiter"};
> +static const char *wm8960_adcl_src_text[] = {"Left", "Right"};
> +static const char *wm8960_adcr_src_text[] = {"Right", "Left"};
>
> static const struct soc_enum wm8960_enum[] = {
> SOC_ENUM_SINGLE(WM8960_DACCTL1, 5, 4, wm8960_polarity),
> @@ -150,6 +152,10 @@ static const struct soc_enum wm8960_enum[] = {
> SOC_ENUM_SINGLE(WM8960_ALC1, 7, 4, wm8960_alcfunc),
> SOC_ENUM_SINGLE(WM8960_ALC3, 8, 2, wm8960_alcmode),
> };
> +static SOC_ENUM_SINGLE_DECL(wm8960_adcl_src_enum,
> + WM8960_ADDCTL1, 3, wm8960_adcl_src_text);
> +static SOC_ENUM_SINGLE_DECL(wm8960_adcr_src_enum,
> + WM8960_ADDCTL1, 2, wm8960_adcr_src_text);
>
> static const int deemph_settings[] = { 0, 32000, 44100, 48000 };
>
> @@ -281,6 +287,11 @@ SOC_SINGLE_TLV("Right Output Mixer RINPUT3 Volume",
> WM8960_ROUTMIX, 4, 7, 1, bypass_tlv),
> };
>
> +static const struct snd_kcontrol_new wm8960_adcl_mux =
> + SOC_DAPM_ENUM("ADCL Source", wm8960_adcl_src_enum);
> +static const struct snd_kcontrol_new wm8960_adcr_mux =
> + SOC_DAPM_ENUM("ADCR Source", wm8960_adcr_src_enum);
> +
> static const struct snd_kcontrol_new wm8960_lin_boost[] = {
> SOC_DAPM_SINGLE("LINPUT2 Switch", WM8960_LINPATH, 6, 1, 0),
> SOC_DAPM_SINGLE("LINPUT3 Switch", WM8960_LINPATH, 7, 1, 0),
> @@ -344,6 +355,9 @@ SND_SOC_DAPM_ADC("Right ADC", "Capture", WM8960_POWER1, 2, 0),
> SND_SOC_DAPM_DAC("Left DAC", "Playback", WM8960_POWER2, 8, 0),
> SND_SOC_DAPM_DAC("Right DAC", "Playback", WM8960_POWER2, 7, 0),
>
> +SND_SOC_DAPM_MUX("ADCL Source", SND_SOC_NOPM, 0, 0, &wm8960_adcl_mux),
> +SND_SOC_DAPM_MUX("ADCR Source", SND_SOC_NOPM, 0, 0, &wm8960_adcr_mux),
> +
> SND_SOC_DAPM_MIXER("Left Output Mixer", WM8960_POWER3, 3, 0,
> &wm8960_loutput_mixer[0],
> ARRAY_SIZE(wm8960_loutput_mixer)),
> @@ -399,8 +413,14 @@ static const struct snd_soc_dapm_route audio_paths[] = {
> { "Right Input Mixer", NULL, "RINPUT2" },
> { "Right Input Mixer", NULL, "RINPUT3" },
>
> - { "Left ADC", NULL, "Left Input Mixer" },
> - { "Right ADC", NULL, "Right Input Mixer" },
> + { "ADCL Source", "Left", "Left Input Mixer" },
> + { "ADCL Source", "Right", "Right Input Mixer" },
> +
> + { "ADCR Source", "Left", "Left Input Mixer" },
> + { "ADCR Source", "Right", "Right Input Mixer" },
> +
> + { "Left ADC", NULL, "ADCL Source" },
> + { "Right ADC", NULL, "ADCR Source" },

Are you sure this is correct? My reading is that those bits don't
affect routing at all, they mearly determine how the channel is
sent out on the AIF.

Thanks,
Charles
--
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/

RE: HAProxy Redirect Domain While Retaining Original Domain Name In URL

$
0
0
Hi Brian,


> Thanks for your suggestion. Unfortunately it's not clear how I would
> use this command and format it when doing a redirect. I read the
> HAProxy 1.5 documentation, but it wasn't detailed enough.

You don't want a redirect, you explicitly asked for a rewrite:
"retaining original domain name in URL".

This is a rewrite, not a redirect.

With my suggestion you are replacing the Host header.

Is that not what you want? What do you want?



Please "Replay to All" including the mailing list, thank you.


Lukas

Re: [PATCH v6 4/7] arm64: dts: mediatek: Add MT8173 MMC dts

$
0
0
On Tue, Jun 16, 2015 at 7:39 PM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> Hi Chaotian,
>
> On Mon, Jun 15, 2015 at 7:20 PM, Chaotian Jing
> <chaotian.jing@mediatek.com> wrote:
>> From: Eddie Huang <eddie.huang@mediatek.com>
>>
>> Add node mmc0 ~ mmc3 for mt8173.dtsi
>> Add node mmc0, mmc1 for mt8173-evb.dts
>>
>> Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
>> Signed-off-by: Eddie Huang <eddie.huang@mediatek.com>
>> ---
>> arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 126 ++++++++++++++++++++++++++++
>> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 45 +++++++++-
>> 2 files changed, 170 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> index b1560c9..762ec61 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> @@ -33,6 +33,132 @@
>> chosen { };
>> };
>>
>> +&mmc0 {
>> + pinctrl-names = "default", "state_uhs";
>> + pinctrl-0 = <&mmc0_pins_default>;
>> + pinctrl-1 = <&mmc0_pins_uhs>;
>> + status = "okay";
>> + bus-width = <8>;
>> + max-frequency = <50000000>;
>> + cap-mmc-highspeed;
>> + vmmc-supply = <&mt6397_vemc_3v3_reg>;
>> + vqmmc-supply = <&mt6397_vio18_reg>;

I also can't find phandles for these regulators.

>> + non-removable;
>> +};
>> +
>> +&mmc1 {
>> + pinctrl-names = "default", "state_uhs";
>> + pinctrl-0 = <&mmc1_pins_default>;
>> + pinctrl-1 = <&mmc1_pins_uhs>;
>> + status = "okay";
>> + bus-width = <4>;
>> + max-frequency = <50000000>;
>> + cap-sd-highspeed;
>> + sd-uhs-sdr25;
>> + cd-gpios = <&pio 132 0>;
>> + vmmc-supply = <&mt6397_vmch_reg>;
>> + vqmmc-supply = <&mt6397_vmc_reg>;

nor these regulators.

Which kernel branch are you basing your patch set on?

Thanks,
-Dan


>> +};
>> +
>> +&pio {
>> + mmc0_pins_default: mmc0default {
>> + pins_cmd_dat {
>> + pinmux = <MT8173_PIN_57_MSDC0_DAT0__FUNC_MSDC0_DAT0>,
>> + <MT8173_PIN_58_MSDC0_DAT1__FUNC_MSDC0_DAT1>,
>> + <MT8173_PIN_59_MSDC0_DAT2__FUNC_MSDC0_DAT2>,
>> + <MT8173_PIN_60_MSDC0_DAT3__FUNC_MSDC0_DAT3>,
>> + <MT8173_PIN_61_MSDC0_DAT4__FUNC_MSDC0_DAT4>,
>> + <MT8173_PIN_62_MSDC0_DAT5__FUNC_MSDC0_DAT5>,
>> + <MT8173_PIN_63_MSDC0_DAT6__FUNC_MSDC0_DAT6>,
>> + <MT8173_PIN_64_MSDC0_DAT7__FUNC_MSDC0_DAT7>,
>> + <MT8173_PIN_66_MSDC0_CMD__FUNC_MSDC0_CMD>;
>> + input-enable;
>> + bias-pull-up;
>> + };
>> +
>> + pins_clk {
>> + pinmux = <MT8173_PIN_65_MSDC0_CLK__FUNC_MSDC0_CLK>;
>> + bias-pull-down;
>> + };
>> +
>> + pins_rst {
>> + pinmux = <MT8173_PIN_68_MSDC0_RST___FUNC_MSDC0_RSTB>;
>> + bias-pull-up;
>> + };
>> + };
>> +
>> + mmc1_pins_default: mmc1default {
>> + pins_cmd_dat {
>> + pinmux = <MT8173_PIN_73_MSDC1_DAT0__FUNC_MSDC1_DAT0>,
>> + <MT8173_PIN_74_MSDC1_DAT1__FUNC_MSDC1_DAT1>,
>> + <MT8173_PIN_75_MSDC1_DAT2__FUNC_MSDC1_DAT2>,
>> + <MT8173_PIN_76_MSDC1_DAT3__FUNC_MSDC1_DAT3>,
>> + <MT8173_PIN_78_MSDC1_CMD__FUNC_MSDC1_CMD>;
>> + input-enable;
>> + drive-strength = <MTK_DRIVE_4mA>;
>> + bias-pull-up = <MTK_PUPD_SET_R1R0_10>;
>> + };
>> +
>> + pins_clk {
>> + pinmux = <MT8173_PIN_77_MSDC1_CLK__FUNC_MSDC1_CLK>;
>> + bias-pull-down;
>> + drive-strength = <MTK_DRIVE_4mA>;
>> + };
>> +
>> + pins_insert {
>> + pinmux = <MT8173_PIN_132_I2S0_DATA1__FUNC_GPIO132>;
>> + bias-pull-up;
>> + };
>> + };
>> +
>> + mmc0_pins_uhs: mmc0@0{
>> + pins_cmd_dat {
>> + pinmux = <MT8173_PIN_57_MSDC0_DAT0__FUNC_MSDC0_DAT0>,
>> + <MT8173_PIN_58_MSDC0_DAT1__FUNC_MSDC0_DAT1>,
>> + <MT8173_PIN_59_MSDC0_DAT2__FUNC_MSDC0_DAT2>,
>> + <MT8173_PIN_60_MSDC0_DAT3__FUNC_MSDC0_DAT3>,
>> + <MT8173_PIN_61_MSDC0_DAT4__FUNC_MSDC0_DAT4>,
>> + <MT8173_PIN_62_MSDC0_DAT5__FUNC_MSDC0_DAT5>,
>> + <MT8173_PIN_63_MSDC0_DAT6__FUNC_MSDC0_DAT6>,
>> + <MT8173_PIN_64_MSDC0_DAT7__FUNC_MSDC0_DAT7>,
>> + <MT8173_PIN_66_MSDC0_CMD__FUNC_MSDC0_CMD>;
>> + input-enable;
>> + drive-strength = <MTK_DRIVE_2mA>;
>> + bias-pull-up = <MTK_PUPD_SET_R1R0_01>;
>> + };
>> +
>> + pins_clk {
>> + pinmux = <MT8173_PIN_65_MSDC0_CLK__FUNC_MSDC0_CLK>;
>> + drive-strength = <MTK_DRIVE_2mA>;
>> + bias-pull-down = <MTK_PUPD_SET_R1R0_01>;
>> + };
>> +
>> + pins_rst {
>> + pinmux = <MT8173_PIN_68_MSDC0_RST___FUNC_MSDC0_RSTB>;
>> + bias-pull-up;
>> + };
>> + };
>> +
>> + mmc1_pins_uhs: mmc1@0 {
>> + pins_cmd_dat {
>> + pinmux = <MT8173_PIN_73_MSDC1_DAT0__FUNC_MSDC1_DAT0>,
>> + <MT8173_PIN_74_MSDC1_DAT1__FUNC_MSDC1_DAT1>,
>> + <MT8173_PIN_75_MSDC1_DAT2__FUNC_MSDC1_DAT2>,
>> + <MT8173_PIN_76_MSDC1_DAT3__FUNC_MSDC1_DAT3>,
>> + <MT8173_PIN_78_MSDC1_CMD__FUNC_MSDC1_CMD>;
>> + input-enable;
>> + drive-strength = <MTK_DRIVE_4mA>;
>> + bias-pull-up = <MTK_PUPD_SET_R1R0_10>;
>> + };
>> +
>> + pins_clk {
>> + pinmux = <MT8173_PIN_77_MSDC1_CLK__FUNC_MSDC1_CLK>;
>> + drive-strength = <MTK_DRIVE_4mA>;
>> + bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
>> + };
>> + };
>> +};
>> +
>> &pwrap {
>> pmic: mt6397 {
>> compatible = "mediatek,mt6397";
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> index 512e4eb..56ea429 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> @@ -288,7 +288,50 @@
>> reg = <0 0x19000000 0 0x1000>;
>> #clock-cells = <1>;
>> };
>> - };
>>
>> + mmc0: mmc@11230000 {
>> + compatible = "mediatek,mt8173-mmc",
>> + "mediatek,mt8135-mmc";
>> + reg = <0 0x11230000 0 0x1000>;
>> + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_LOW>;
>> + clocks = <&pericfg CLK_PERI_MSDC30_0>,
>> + <&topckgen CLK_TOP_MSDC50_0_H_SEL>;
>> + clock-names = "source", "hclk";
>> + status = "disabled";
>> + };
>> +
>> + mmc1: mmc@11240000 {
>> + compatible = "mediatek,mt8173-mmc",
>> + "mediatek,mt8135-mmc";
>> + reg = <0 0x11240000 0 0x1000>;
>> + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_LOW>;
>> + clocks = <&pericfg CLK_PERI_MSDC30_1>,
>> + <&clk_null>;
>
> This requires a "clk_null" phandle, but I have not seen a patch adding
> that on the public list.
> Did I miss a patch?
>
> -Dan
>
>> + clock-names = "source", "hclk";
>> + status = "disabled";
>> + };
>> +
>> + mmc2: mmc@11250000 {
>> + compatible = "mediatek,mt8173-mmc",
>> + "mediatek,mt8135-mmc";
>> + reg = <0 0x11250000 0 0x1000>;
>> + interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_LOW>;
>> + clocks = <&pericfg CLK_PERI_MSDC30_2>,
>> + <&clk_null>;
>> + clock-names = "source", "hclk";
>> + status = "disabled";
>> + };
>> +
>> + mmc3: mmc@11260000 {
>> + compatible = "mediatek,mt8173-mmc",
>> + "mediatek,mt8135-mmc";
>> + reg = <0 0x11260000 0 0x1000>;
>> + interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_LOW>;
>> + clocks = <&pericfg CLK_PERI_MSDC30_3>,
>> + <&topckgen CLK_TOP_MSDC50_2_H_SEL>;
>> + clock-names = "source", "hclk";
>> + status = "disabled";
>> + };
>> + };
>> };
>>
>> --
>> 1.8.1.1.dirty
>>
>>
>> _______________________________________________
>> Linux-mediatek mailing list
>> Linux-mediatek@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
--
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/

Re: [PATCH] Staging: wilc1000: Boolean tests don't need comparisons

$
0
0
On Tuesday 16 June 2015 04:41 PM, Sudip Mukherjee wrote:
> On Tue, Jun 16, 2015 at 08:55:13AM +0000, Abdul, Hussain (H.) wrote:
>> On Tuesday 16 June 2015 01:40 PM, Sudip Mukherjee wrote:
>>> On Tue, Jun 16, 2015 at 07:33:42AM +0000, Abdul, Hussain (H.) wrote:
>>>> From: Abdul Hussain <habdul@visteon.com>
>>> regards
>>> sudip
>>>
>> Sudip,
>>
>> Yes that is an assignment to the boolean variable. Do i need to modify the commit message or to send separate patch?
> if that assignment is related to the change in boolean test then it should
> be in the same patch. But in any case commit message should mention that
> change and the reason.
>
> regards
> sudip
>
>
I have sent separate patch for this change.

Thanks,
Abdul
--
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/

Re: call_rcu from trace_preempt

$
0
0
On Mon, Jun 15, 2015 at 10:45:05PM -0700, Alexei Starovoitov wrote:
> On 6/15/15 7:14 PM, Paul E. McKenney wrote:
> >
> >Why do you believe that it is better to fix it within call_rcu()?
>
> found it:
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 8cf7304b2867..a3be09d482ae 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -935,9 +935,9 @@ bool notrace rcu_is_watching(void)
> {
> bool ret;
>
> - preempt_disable();
> + preempt_disable_notrace();
> ret = __rcu_is_watching();
> - preempt_enable();
> + preempt_enable_notrace();
> return ret;
> }
>
> the rcu_is_watching() and __rcu_is_watching() are already marked
> notrace, so imo it's a good 'fix'.
> What was happening is that the above preempt_enable was triggering
> recursive call_rcu that was indeed messing 'rdp' that was
> prepared by __call_rcu and before __call_rcu_core could use that.

> btw, also noticed that local_irq_save done by note_gp_changes
> is partially redundant. In __call_rcu_core path the irqs are
> already disabled.

But you said earlier that nothing happened when interrupts were
disabled. And interrupts are disabled across the call to
rcu_is_watching() in __call_rcu_core(). So why did those calls
to preempt_disable() and preempt_enable() cause trouble?

That said, the patch looks inoffensive to me, adding Steven for his
trace expertise.

Still, I do need to understand what was really happening. Did interrupts
get enabled somehow? Or is your code that ignores calls when interrupts
are disabled incomplete in some way? Something else?

> >Perhaps you are self-deadlocking within __call_rcu_core(). If you have
> >not already done so, please try running with CONFIG_PROVE_LOCKING=y.
>
> yes, I had CONFIG_PROVE_LOCKING on.

Good! ;-)

> >I suspect that your problem may range quite a bit further than just
> >call_rcu(). For example, in your stack trace, you have a recursive
> >call to debug_object_activate(), which might not be such good thing.
>
> nope :) recursive debug_object_activate() is fine.
> with the above 'fix' the trace.patch is now passing.
>
> Why I'm digging into all of these? Well, to find out when
> it's safe to finally do call_rcu. If I will use deferred kfree
> approach in bpf maps, I need to know when it's safe to finally
> call_rcu and it's not an easy answer.

Given that reentrant calls to call_rcu() and/or kfree_rcu() were not
in any way considered during design and implementation, it is not a
surprise that the answer is not easy. The reason I need to understand
what your code does in interrupt-disabled situations is to work out
whether or not it makes sense to agree to support reentrancy in call_rcu()
and kfree_rcu().

> kprobes potentially can be placed in any part of call_rcu stack,
> so things can go messy quickly. So it helps to understand the call_rcu
> logic well enough to come up with good solution.

Indeed, I do have some concerns about that sort of thing, as it is not
at all clear that designing call_rcu() and kfree_rcu() for unrestricted
reentrancy is a win.

Thanx, Paul

--
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/

[PHP-DEV] Re: [PHP-CVS] com php-src: Make CALL VM with FP and IP in global registers not to return anything from opcode handlers. Set OPLINE to NULL to terminate VM loop instead. This saves 1 CPU instruction for each opcode handler.: Zend/zend_vm_execute.

$
0
0
Hi Dmitry,

----- Original Message -----
From: "Dmitry Stogov"
Sent: Tuesday, June 16, 2015

Commit: 48ed660cdf6fe94ac2cd8eac217ea97340766e75
Author: Dmitry Stogov <dmitry@zend.com> Tue, 16 Jun 2015 14:11:16
+0300
Parents: 3180b8e100285e5bd9088e9981608dfd14f6ff27
Branches: master

Link:
http://git.php.net/?p=php-src.git;a=commitdiff;h=48ed660cdf6fe94ac2cd8eac217ea97340766e75

Log:
Make CALL VM with FP and IP in global registers not to return anything from
opcode handlers.
Set OPLINE to NULL to terminate VM loop instead.
This saves 1 CPU instruction for each opcode handler.

Changed paths:
M Zend/zend_vm_execute.h
M Zend/zend_vm_gen.php


In zend_vm_gen.php, it seems lines 1073-1075 can be removed, since they have
identical #define's. So, pseudo-diff:

-out($f,"#if defined(ZEND_VM_FP_GLOBAL_REG) &&
defined(ZEND_VM_IP_GLOBAL_REG)\n");
-out($f,"# define ZEND_VM_ENTER() ...");
-out($f,"# define ZEND_VM_LEAVE() ZEND_VM_CONTINUE()\n");
-out($f,"#elif defined(ZEND_VM_FP_GLOBAL_REG)\n");
+out($f,"#if defined(ZEND_VM_FP_GLOBAL_REG)\n");

Just FYI. Unless you purposely kept it like that for semantics or will be
adding something else distinct soon/later. :-)

But always neat to see extra optimization tricks (thanks!), even when they
don't apply for Windows builds. :-(

- Matt


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PATCH v2 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend

$
0
0
2015-06-16 0:00 GMT+09:00 Javier Martinez Canillas
<javier.martinez@collabora.co.uk>:
> Hello Sudeep,
>
> On 06/15/2015 11:01 AM, Sudeep Holla wrote:
>>
>>
>> On 15/06/15 08:46, Javier Martinez Canillas wrote:
>> [...]
>>
>>>
>>> Sudeep, so we may need something like $subject after all from Doug's
>>> explanations since the combiner chip state is lost during a S2R. I know
>>> that it adds more duplicated code (others irqchip drivers do the same)
>>> and it may not scale well if a chip has many registers but is the best
>>> solution I could came with.
>>>
>>
>> OK
>>
>>> If you have a suggestion for a better alternative, I can give a try and
>>> write the patch. But I think $subject could also land to fix this issue
>>> since is a very non intrusive change and later can be changed once the
>>> irqchip core supports this use case.
>>>
>>
>> Agreed. But I would suggest also to add MASK_ON_SUSPEND and set_irq_wake
>> also and then you can restore iff it's non-zero as irq core will take
>> care of most of the non-wakeup sources. Because I am planning to push
>
> I've looking at this and a problem I found is that IIUC the set_irq_wake
> is not propagated from the the Exynos pinctrl / GPIO driver which is the
> combiner's external interrupt source so the callback is never called.
> Which means that right now only the state of the wakeup source IRQs can't
> be saved since that information is not present.
>
> The drivers/pinctrl/samsung/pinctrl-exynos.c driver enables and disables
> the combiner interrupts but its .irq_set_wake handler only updates the
> wakeup source mask for the external interrupts but does not call the
> combiner .set_irq_wake so that should be changed as well.
>

As far as I'm aware of, wake-up events from pin controllers don't go
through GIC, but rather directly to PMU, which is a dedicated unit
responsible for power management and not a standalone interrupt
controller (well actually I saw a series making it a cascaded
controller some time ago, but I'm not sure if that went in). Based on
this, I don't think we have to call set_irq_wake on GIC. Correct me if
I'm wrong, though.

Best regards,
Tomasz
--
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/

Re: [PATCH 6/6] mm, compaction: decouple updating pageblock_skip and cached pfn

$
0
0
On 06/16/2015 08:10 AM, Joonsoo Kim wrote:
> On Wed, Jun 10, 2015 at 11:32:34AM +0200, Vlastimil Babka wrote:
>> The pageblock_skip bitmap and cached scanner pfn's are two mechanisms in
>> compaction to prevent rescanning pages where isolation has recently failed
>> or they were scanned during the previous compaction attempt.
>>
>> Currently, both kinds of information are updated via update_pageblock_skip(),
>> which is suboptimal for the cached scanner pfn's:
>>
>> - The condition "isolation has failed in the pageblock" checked by
>> update_pageblock_skip() may be valid for the pageblock_skip bitmap, but makes
>> less sense for cached pfn's. There's little point for the next compaction
>> attempt to scan again a pageblock where all pages that could be isolated were
>> already processed.
>
> In async compaction, compaction could be stopped due to cc->contended
> in freepage scanner so sometimes isolated pages were not migrated. Your
> change makes next async compaction skip these pages. This possibly causes
> compaction complete prematurely by async compaction.

Hm, I see, thanks. That could be fixed when returning the non-migrated pages,
just like we do for the unused freepages and cached free scanner position.

> And, rescan previous attempted range could solve some race problem.
> If allocated page waits to set PageLRU in pagevec, compaction will
> pass it. If we try rescan after short time, page will have PageLRU and
> compaction can isolate and migrate it and make high order freepage. This
> requires some rescanning overhead but migration overhead which is more bigger
> than scanning overhead is just a little. If compaction pass it like as
> this change, pages on this area would be allocated for other requestor, and,
> when compaction revisit, there would be more page to migrate.

The same "race problem" (and many others) can happen when we don't abort and
later restart from cached pfn's, but just continue on to later pageblocks within
single compaction run. Still I would expect that it's statistically higher
chance to succeed in the next pageblock than rescanning pageblock(s) that we
just scanned.

> I basically agree with this change because it is more intuitive. But,
> I'd like to see some improvement result or test this patch myself before merging
> it.

Sure, please test. I don't expect much difference, the primary motivation was
really that the recorded pfn's by tracepoints looked much saner.

Thanks for the review!
--
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/

Re: call_rcu from trace_preempt

$
0
0
On 06/16/2015 02:27 PM, Paul E. McKenney wrote:
> On Mon, Jun 15, 2015 at 10:45:05PM -0700, Alexei Starovoitov wrote:
>> On 6/15/15 7:14 PM, Paul E. McKenney wrote:
>>>
>>> Why do you believe that it is better to fix it within call_rcu()?
>>
>> found it:
>> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
>> index 8cf7304b2867..a3be09d482ae 100644
>> --- a/kernel/rcu/tree.c
>> +++ b/kernel/rcu/tree.c
>> @@ -935,9 +935,9 @@ bool notrace rcu_is_watching(void)
>> {
>> bool ret;
>>
>> - preempt_disable();
>> + preempt_disable_notrace();
>> ret = __rcu_is_watching();
>> - preempt_enable();
>> + preempt_enable_notrace();
>> return ret;
>> }
>>
>> the rcu_is_watching() and __rcu_is_watching() are already marked
>> notrace, so imo it's a good 'fix'.
>> What was happening is that the above preempt_enable was triggering
>> recursive call_rcu that was indeed messing 'rdp' that was
>> prepared by __call_rcu and before __call_rcu_core could use that.
>
>> btw, also noticed that local_irq_save done by note_gp_changes
>> is partially redundant. In __call_rcu_core path the irqs are
>> already disabled.
>
> But you said earlier that nothing happened when interrupts were
> disabled. And interrupts are disabled across the call to
> rcu_is_watching() in __call_rcu_core(). So why did those calls
> to preempt_disable() and preempt_enable() cause trouble?

Just for the record: Using a thread for freeing the memory is curing the
problem without the need to modify rcu_is_watching.

Here is the hack:

diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index 83c209d..8d73be3 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -13,6 +13,8 @@
#include <linux/jhash.h>
#include <linux/filter.h>
#include <linux/vmalloc.h>
+#include <linux/kthread.h>
+#include <linux/spinlock.h>

struct bpf_htab {
struct bpf_map map;
@@ -27,10 +29,14 @@ struct bpf_htab {
struct htab_elem {
struct hlist_node hash_node;
struct rcu_head rcu;
+ struct list_head list;
u32 hash;
char key[0] __aligned(8);
};

+static LIST_HEAD(elem_freelist);
+static DEFINE_SPINLOCK(elem_freelist_lock);
+
/* Called from syscall */
static struct bpf_map *htab_map_alloc(union bpf_attr *attr)
{
@@ -228,6 +234,7 @@ static int htab_map_update_elem(struct bpf_map *map,
void *key, void *value,
memcpy(l_new->key + round_up(key_size, 8), value, map->value_size);

l_new->hash = htab_map_hash(l_new->key, key_size);
+ INIT_LIST_HEAD(&l_new->list);

/* bpf_map_update_elem() can be called in_irq() */
spin_lock_irqsave(&htab->lock, flags);
@@ -300,11 +307,17 @@ static int htab_map_delete_elem(struct bpf_map
*map, void *key)
if (l) {
hlist_del_rcu(&l->hash_node);
htab->count--;
- kfree_rcu(l, rcu);
+ /* kfree_rcu(l, rcu); */
ret = 0;
}

spin_unlock_irqrestore(&htab->lock, flags);
+
+ if (l) {
+ spin_lock_irqsave(&elem_freelist_lock, flags);
+ list_add(&l->list, &elem_freelist);
+ spin_unlock_irqrestore(&elem_freelist_lock, flags);
+ }
return ret;
}

@@ -359,9 +372,31 @@ static struct bpf_map_type_list htab_type
__read_mostly = {
.type = BPF_MAP_TYPE_HASH,
};

+static int free_thread(void *arg)
+{
+ unsigned long flags;
+ struct htab_elem *l;
+
+ while (!kthread_should_stop()) {
+ spin_lock_irqsave(&elem_freelist_lock, flags);
+ while (!list_empty(&elem_freelist)) {
+ l = list_entry(elem_freelist.next,
+ struct htab_elem, list);
+ list_del(&l->list);
+ kfree(l);
+ }
+ spin_unlock_irqrestore(&elem_freelist_lock, flags);
+ }
+
+ return 0;
+}
+
static int __init register_htab_map(void)
{
bpf_register_map_type(&htab_type);
+
+ kthread_run(free_thread, NULL, "free_thread");
+
return 0;
}
late_initcall(register_htab_map);
--
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/
Viewing all 23908 articles
Browse latest View live




Latest Images