Re: [PATCH] KVM: x86: Check for nested events if there is an injectable interrupt
On 2014-07-08 07:50, Paolo Bonzini wrote:
> Il 08/07/2014 06:30, Bandan Das ha scritto:
>>
>> With commit b6b8a1451fc40412c57d1 that introduced
>> vmx_check_nested_events, checks for injectable interrupts happen
>> at different points in time for L1 and L2 that could potentially
>> cause a race. The regression occurs because KVM_REQ_EVENT is always
>> set when nested_run_pending is set even if there's no pending interrupt.
>> Consequently, there could be a small window when check_nested_events
>> returns without exiting to L1, but an interrupt comes through soon
>> after and it incorrectly, gets injected to L2 by inject_pending_event
>> Fix this by adding a call to check for nested events too when a check
>> for injectable interrupt returns true
>>
>> Signed-off-by: Bandan Das
>> ---
>> arch/x86/kvm/x86.c | 13 +
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 73537ec..56327a6 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -5907,6 +5907,19 @@ static int inject_pending_event(struct kvm_vcpu
>> *vcpu, bool req_int_win)
>> kvm_x86_ops->set_nmi(vcpu);
>> }
>> } else if (kvm_cpu_has_injectable_intr(vcpu)) {
>> +/*
>> + * TODO/FIXME: We are calling check_nested_events again
>> + * here to avoid a race condition. We should really be
>> + * setting KVM_REQ_EVENT only on certain events
>> + * and not unconditionally.
>> + * See https://lkml.org/lkml/2014/7/2/60 for discussion
>> + * about this proposal and current concerns
>> + */
>> +if (is_guest_mode(vcpu) && kvm_x86_ops->check_nested_events) {
>> +r = kvm_x86_ops->check_nested_events(vcpu, req_int_win);
>> +if (r != 0)
>> +return r;
>> +}
>> if (kvm_x86_ops->interrupt_allowed(vcpu)) {
>> kvm_queue_interrupt(vcpu, kvm_cpu_get_interrupt(vcpu),
>> false);
>>
>
> I think this should be done for NMI as well.
I don't think arch.nmi_pending can flip asynchronously, only in the
context of the VCPU thread - in contrast to pending IRQ states.
>
> Jan, what do you think? Can you run Jailhouse through this patch?
Jailhouse seems fine with it, and it resolves the lockup of nested KVM
here as well.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net] r8152: wake up the device before dumping the hw counter
The device should be waked up from runtime suspend before dumping the hw counter. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 2543196..a795ecf 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -3204,8 +3204,13 @@ static void rtl8152_get_ethtool_stats(struct net_device *dev, struct r8152 *tp = netdev_priv(dev); struct tally_counter tally; + if (usb_autopm_get_interface(tp->intf) < 0) + return; + generic_ocp_read(tp, PLA_TALLYCNT, sizeof(tally), &tally, MCU_TYPE_PLA); + usb_autopm_put_interface(tp->intf); + data[0] = le64_to_cpu(tally.tx_packets); data[1] = le64_to_cpu(tally.rx_packets); data[2] = le64_to_cpu(tally.tx_errors); -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 4/4] kvm, mem-hotplug: Update apic access page when it is migrated.
Tang, I am sorry if I caused any confusion. Following Gleb response, there is no apparent need for dealing with the scenario I mentioned (relocating the APIC base), so you don't need to do any changes to your patch, and I will post another patch later to warn if the guest relocates its APIC (from the default address to another guest physical address). My answers to your questions are below. On 7/8/14, 4:44 AM, Tang Chen wrote: Hi Nadav, Thanks for the reply, please see below. On 07/07/2014 08:10 PM, Nadav Amit wrote: On 7/7/14, 2:54 PM, Gleb Natapov wrote: On Mon, Jul 07, 2014 at 02:42:27PM +0300, Nadav Amit wrote: Tang, Running some (unrelated) tests I see that KVM does not handle APIC base relocation correctly. When the base is changed, kvm_lapic_set_base just changes lapic->base_address without taking further action (i.e., modifying the VMCS apic address in VMX). This patch follows KVM bad behavior by using the constant VMX_APIC_ACCESS_PAGE_ADDR instead of lapic->base_address. There is no OS out there that relocates APIC base (in fact it was not always relocatable on real HW), so there is not point in complicating the code to support it. In fact current APIC_ACCESS_ADDR handling relies on the fact that all vcpus has apic mapped at the same address. Anyhow, I didn't see anything that would make my life (in fixing the lapic base issue) too difficult. Yet, feel free in making it more "fix-friendly". Why would you want to fix it? If there is no general need, I will not send a fix. However, I think the very least a warning message should be appear if the guest relocates the APIC base. Maybe I didn't understand you question correctly. If I'm wrong, please tell me. This patch does not relocate APIC base in guest, but in host. Host migrates the apic page to somewhere else, and KVM updates ept pagetable to track it. In guest, apic base address (gpa) doesn't change. The last claim is true in practice, according to Gleb, but it is not necessarily so according to the specifications. Pentium 4, Intel Xeon and P6 family processors support APIC base relocation. See the Intel SDM section 10.4.5. Anyhow, Gleb claims it is not used by any OS. Is this lapic->base_address a hpa ? No, it is guest physical address. Is there anywhere I need to update in my patch ? No. I'll send another patch on top of yours that prints a warning if the APIC base is relocated (i.e., the guest physical address of the APIC base is changed). Such relocation is done explicitly by the guest, not by your patch. Nadav -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] alarmtimer: Fix bug where relative alarm timers were treated as absolute
On Mon, Jul 07, 2014 at 02:06:11PM -0700, John Stultz wrote:
> @@ -597,8 +602,16 @@ static int alarm_timer_set(struct k_itimer *timr, int
> flags,
>
> /* start the timer */
> timr->it.alarm.interval = timespec_to_ktime(new_setting->it_interval);
> - alarm_start(&timr->it.alarm.alarmtimer,
> - timespec_to_ktime(new_setting->it_value));
> + exp = timespec_to_ktime(new_setting->it_value);
> + /* Convert (if necessary) to absolute time */
> + if (flags != TIMER_ABSTIME) {
> + ktime_t now;
> +
> + now = alarm_bases[timr->it.alarm.alarmtimer.type].gettime();
> + exp = ktime_add(now, exp);
> + }
> +
> + alarm_start(&timr->it.alarm.alarmtimer, exp);
Nothing protects 'exp' from becoming invalid before queuing the alarm,
if the time base is reset on another cpu. Or would that be harmless
here?
> return 0;
> }
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [f2fs-dev] [PATCH] f2fs: do checkpoint for the renamed inode
On Mon, Jul 07, 2014 at 11:17:35AM +0800, Chao Yu wrote:
> Hi Jaegeuk,
>
> > -Original Message-
> > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > Sent: Wednesday, July 02, 2014 6:35 PM
> > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> > linux-f2fs-de...@lists.sourceforge.net
> > Cc: Jaegeuk Kim
> > Subject: [f2fs-dev] [PATCH] f2fs: do checkpoint for the renamed inode
> >
> > If an inode is renamed, it should be registered as file_lost_pino to conduct
> > checkpoint at f2fs_sync_file.
> > Otherwise, the inode cannot be recovered due to no dent_mark in the
> > following
> > scenario.
> >
> > Note that, this scenario is from xfstests/322.
> >
> > 1. create "a"
> > 2. fsync "a"
> > 3. rename "a" to "b"
> > 4. fsync "b"
> > 5. Sudden power-cut
> >
> > After recovery is done, "b" should be seen.
> > However, the result shows "a", since the recovery procedure does not enter
> > recover_dentry due to no dent_mark.
>
> As we know CP is expensive, how about modifying checkpointed value directly
> in nat cache at step #3? So "b" could be fsynced with dent_mark at step #4.
Yes, I also thought about that.
But, when handling the nat cache, one of my concerns was the lock granularity.
Basically each nat cache entry should be covered by its node page lock, so it
is a little bit complicate to do something easily in f2fs_rename.
So, this patch was to fix the bug with a naive approach.
And we can write additional patch to enhance this too.
Thanks,
>
> >
> > The reason is like below.
> > - The nid of "a" is checkpointed during #2, f2fs_sync_file.
> > - The inode page for "b" produced by #3 is written without dent_mark by
> > sync_node_pages.
> >
> > So, this patch fixes this bug by assinging file_lost_pino to the "a"'s
> > inode.
> > If the pino is lost, f2fs_sync_file conducts checkpoint, and then recovers
> > the latest pino and its dentry information for further recovery.
> >
> > Signed-off-by: Jaegeuk Kim
> > ---
> > fs/f2fs/namei.c | 10 --
> > 1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
> > index 96f1dd1..1b3cae0 100644
> > --- a/fs/f2fs/namei.c
> > +++ b/fs/f2fs/namei.c
> > @@ -411,9 +411,6 @@ static int f2fs_rename(struct inode *old_dir, struct
> > dentry *old_dentry,
> > }
> >
> > f2fs_set_link(new_dir, new_entry, new_page, old_inode);
> > - down_write(&F2FS_I(old_inode)->i_sem);
> > - F2FS_I(old_inode)->i_pino = new_dir->i_ino;
> > - up_write(&F2FS_I(old_inode)->i_sem);
> >
> > new_inode->i_ctime = CURRENT_TIME;
> > down_write(&F2FS_I(new_inode)->i_sem);
> > @@ -446,6 +443,10 @@ static int f2fs_rename(struct inode *old_dir, struct
> > dentry *old_dentry,
> > }
> > }
> >
> > + down_write(&F2FS_I(old_inode)->i_sem);
> > + file_lost_pino(old_inode);
> > + up_write(&F2FS_I(old_inode)->i_sem);
> > +
> > old_inode->i_ctime = CURRENT_TIME;
> > mark_inode_dirty(old_inode);
> >
> > @@ -455,9 +456,6 @@ static int f2fs_rename(struct inode *old_dir, struct
> > dentry *old_dentry,
> > if (old_dir != new_dir) {
> > f2fs_set_link(old_inode, old_dir_entry,
> > old_dir_page, new_dir);
> > - down_write(&F2FS_I(old_inode)->i_sem);
> > - F2FS_I(old_inode)->i_pino = new_dir->i_ino;
> > - up_write(&F2FS_I(old_inode)->i_sem);
> > update_inode_page(old_inode);
> > } else {
> > kunmap(old_dir_page);
> > --
> > 1.8.5.2 (Apple Git-48)
> >
> >
> > --
> > Open source business process management suite built on Java and Eclipse
> > Turn processes into business applications with Bonita BPM Community Edition
> > Quickly connect people, data, and systems into organized workflows
> > Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > http://p.sf.net/sfu/Bonitasoft
> > ___
> > Linux-f2fs-devel mailing list
> > linux-f2fs-de...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
Jaegeuk Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Allow increasing the buffer-head per-CPU LRU size
Can anyone demonstrate why we shouldn't just do I was assuming due to memory usage: with 4K blocks 32K->64K Moreover, performance gain was not that satisfactory on ext4 when increasing BH_LRU_SIZE to 16. Here are the performances I got with: (a) mdtest on ramdisk device, single shared dir, with large ACL and SELinux (b) mdtest on ramdisk device, single shared dir, with large ACL but NO SELinux (results show performance gain in percentage when increasing BH_LRU_SIZE to 16) (a) files tasks dir size Creation Stat Removal 100 10 -8,7-2,7 -0,5 100 1 10 -5,2-0,5 -1,1 100 1 50 -5,1-3,7 -1,5 100 1 200 -5,1-4,0 -8,5 100 1 500 -4,2-5,3 -10,2 100 1 1000 -3,5-8,0 -10,9 100 80 -0,3-3,8 -1,2 100 8 10 -1,2-3,7 -1,5 100 8 50 0,5-3,2 -5,3 100 8 200 -1,7-6,1 -8,7 100 8 500 -5,9-7,7 -11,9 100 8 1000 -4,1-8,8 -13,6 (b) files tasks dir size Creation Stat Removal 100 1 00,0-0,9 -1,1 100 1 101,0-3,0 -3,5 100 1 503,7-3,0 -2,4 100 1 2001,1 3,6 -0,2 100 1 5003,5 0,1 5,9 100 110009,0 3,8 6,4 100 8 02,4-1,2 -4,3 100 8 10 -0,2-1,8 -2,4 100 8 501,1-0,3 2,0 100 8 200 -0,3-2,8 -3,3 100 8 5000,3-3,1 -1,3 100 810001,5 0,0 0,7 To compare with the performances I got on Lustre with: (c) mds-survey on ramdisk device, quota enabled, shared directory (d) mds-survey on ramdisk device, quota enabled, directory per process (c) fi dir threads create lookup destroy 100 11 11,3 1,2 7,2 100 12 6,4 2,3 6,9 100 14 1,9 3,0 1,3 100 18 -0,6 4,3 0,7 100 1 16 0,5 4,4 0,6 (d) files dir threads create lookup destroy 100 4 43,2 28,5 5,3 100 8 81,2 33,9 2,0 10016 160,6 7,9 -0,2 Sebastien. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v11 2/7] x86: add pmd_[dirty|mkclean] for THP
On 07/08/2014 02:03 PM, Minchan Kim wrote:
> MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent
> overwrite of the contents since MADV_FREE syscall is called for
> THP page.
>
> This patch adds pmd_dirty and pmd_mkclean for THP page MADV_FREE
> support.
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> Acked-by: Kirill A. Shutemov
> Signed-off-by: Minchan Kim
Acked-by: Zhang Yanfei
> ---
> arch/x86/include/asm/pgtable.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
> index 0ec056012618..329865799653 100644
> --- a/arch/x86/include/asm/pgtable.h
> +++ b/arch/x86/include/asm/pgtable.h
> @@ -104,6 +104,11 @@ static inline int pmd_young(pmd_t pmd)
> return pmd_flags(pmd) & _PAGE_ACCESSED;
> }
>
> +static inline int pmd_dirty(pmd_t pmd)
> +{
> + return pmd_flags(pmd) & _PAGE_DIRTY;
> +}
> +
> static inline int pte_write(pte_t pte)
> {
> return pte_flags(pte) & _PAGE_RW;
> @@ -267,6 +272,11 @@ static inline pmd_t pmd_mkold(pmd_t pmd)
> return pmd_clear_flags(pmd, _PAGE_ACCESSED);
> }
>
> +static inline pmd_t pmd_mkclean(pmd_t pmd)
> +{
> + return pmd_clear_flags(pmd, _PAGE_DIRTY);
> +}
> +
> static inline pmd_t pmd_wrprotect(pmd_t pmd)
> {
> return pmd_clear_flags(pmd, _PAGE_RW);
>
--
Thanks.
Zhang Yanfei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v11 1/7] mm: support madvise(MADV_FREE)
On 07/08/2014 02:03 PM, Minchan Kim wrote:
> Linux doesn't have an ability to free pages lazy while other OS
> already have been supported that named by madvise(MADV_FREE).
>
> The gain is clear that kernel can discard freed pages rather than
> swapping out or OOM if memory pressure happens.
>
> Without memory pressure, freed pages would be reused by userspace
> without another additional overhead(ex, page fault + allocation
> + zeroing).
>
> How to work is following as.
>
> When madvise syscall is called, VM clears dirty bit of ptes of
> the range. If memory pressure happens, VM checks dirty bit of
> page table and if it found still "clean", it means it's a
> "lazyfree pages" so VM could discard the page instead of swapping out.
> Once there was store operation for the page before VM peek a page
> to reclaim, dirty bit is set so VM can swap out the page instead of
> discarding.
>
> Firstly, heavy users would be general allocators(ex, jemalloc,
> tcmalloc and hope glibc supports it) and jemalloc/tcmalloc already
> have supported the feature for other OS(ex, FreeBSD)
>
> barrios@blaptop:~/benchmark/ebizzy$ lscpu
> Architecture: x86_64
> CPU op-mode(s):32-bit, 64-bit
> Byte Order:Little Endian
> CPU(s):4
> On-line CPU(s) list: 0-3
> Thread(s) per core:2
> Core(s) per socket:2
> Socket(s): 1
> NUMA node(s): 1
> Vendor ID: GenuineIntel
> CPU family:6
> Model: 42
> Stepping: 7
> CPU MHz: 2801.000
> BogoMIPS: 5581.64
> Virtualization:VT-x
> L1d cache: 32K
> L1i cache: 32K
> L2 cache: 256K
> L3 cache: 4096K
> NUMA node0 CPU(s): 0-3
>
> ebizzy benchmark(./ebizzy -S 10 -n 512)
>
> vanilla-jemalloc MADV_free-jemalloc
>
> 1 thread
> records: 10 records: 10
> avg: 7682.10 avg: 15306.10
> std: 62.35(0.81%)std: 347.99(2.27%)
> max: 7770.00 max: 15622.00
> min: 7598.00 min: 14772.00
>
> 2 thread
> records: 10 records: 10
> avg: 12747.50avg: 24171.00
> std: 792.06(6.21%) std: 895.18(3.70%)
> max: 13337.00max: 26023.00
> min: 10535.00min: 23152.00
>
> 4 thread
> records: 10 records: 10
> avg: 16474.60avg: 33717.90
> std: 1496.45(9.08%) std: 2008.97(5.96%)
> max: 17877.00max: 35958.00
> min: 12224.00min: 29565.00
>
> 8 thread
> records: 10 records: 10
> avg: 16778.50avg: 33308.10
> std: 825.53(4.92%) std: 1668.30(5.01%)
> max: 17543.00max: 36010.00
> min: 14576.00min: 29577.00
>
> 16 thread
> records: 10 records: 10
> avg: 20614.40avg: 35516.30
> std: 602.95(2.92%) std: 1283.65(3.61%)
> max: 21753.00max: 37178.00
> min: 19605.00min: 33217.00
>
> 32 thread
> records: 10 records: 10
> avg: 22771.70avg: 36018.50
> std: 598.94(2.63%) std: 1046.76(2.91%)
> max: 24035.00max: 37266.00
> min: 22108.00min: 34149.00
>
> In summary, MADV_FREE is about 2 time faster than MADV_DONTNEED.
>
> Cc: Michael Kerrisk
> Cc: Linux API
> Cc: Hugh Dickins
> Cc: Johannes Weiner
> Cc: KOSAKI Motohiro
> Cc: Mel Gorman
> Cc: Jason Evans
> Cc: Zhang Yanfei
> Acked-by: Rik van Riel
> Signed-off-by: Minchan Kim
A quick respin, looks good to me now for this !THP part. And
looks neat with the Pagewalker.
Acked-by: Zhang Yanfei
> ---
> include/linux/rmap.h | 9 ++-
> include/linux/vm_event_item.h | 1 +
> include/uapi/asm-generic/mman-common.h | 1 +
> mm/madvise.c | 135
> +
> mm/rmap.c | 42 +-
> mm/vmscan.c| 40 --
> mm/vmstat.c| 1 +
> 7 files changed, 217 insertions(+), 12 deletions(-)
>
> diff --git a/include/linux/rmap.h b/include/linux/rmap.h
> index be574506e6a9..0ba377b97a38 100644
> --- a/include/linux/rmap.h
> +++ b/include/linux/rmap.h
> @@ -75,6 +75,7 @@ enum ttu_flags {
> TTU_UNMAP = 1, /* unmap mode */
> TTU_MIGRATION = 2, /* migration mode */
> TTU_MUNLOCK = 4,/* munlock mode */
> + TTU_FREE = 8, /* free mode */
>
> TTU_IGNORE_MLOCK = (1 << 8),/* ignore mlock */
> TTU_IGNORE_ACCESS = (1 << 9), /* don't age */
> @@ -181,7 +182,8 @@ static inline void page_dup_rmap(struct page *page)
> * Called from mm/vmscan.c to handle paging out
> */
> int page_referenced(struct page *, int is_locked,
> -
Re: [PATCH v2 2/4] Staging: rts5208: Replace custom macro with print_hex_dump_bytes
>
> Hi,
> here exist some checkpatch errors.
>
> Best Regards.
> micky.
Yes, you'are right, I'm gonna fix it, thanks.
On Tue, Jul 8, 2014 at 4:12 AM, micky wrote:
> On 07/07/2014 03:10 PM, Fabio Falzoi wrote:
>>
>> Use print_hex_dump_bytes to have memory properly dumped only when
>> DEBUG is defined.
>>
>> Signed-off-by: Fabio Falzoi
>> ---
>> drivers/staging/rts5208/ms.c| 4 ++--
>> drivers/staging/rts5208/rtsx_chip.c | 4 ++--
>> drivers/staging/rts5208/rtsx_scsi.c | 9 -
>> drivers/staging/rts5208/sd.c| 6 +++---
>> drivers/staging/rts5208/trace.h | 10 +-
>> 5 files changed, 16 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/staging/rts5208/ms.c b/drivers/staging/rts5208/ms.c
>> index 2476d22..0a33043 100644
>> --- a/drivers/staging/rts5208/ms.c
>> +++ b/drivers/staging/rts5208/ms.c
>> @@ -307,7 +307,7 @@ static int ms_read_bytes(struct rtsx_chip *chip,
>> if ((tpc == PRO_READ_SHORT_DATA) && (data_len == 8)) {
>> pr_debug("Read format progress:\n");
>> - RTSX_DUMP(ptr, cnt);
>> + rtsx_hex_dump(ptr, cnt);
>> }
>> return STATUS_SUCCESS;
>> @@ -1910,7 +1910,7 @@ RE_SEARCH:
>> ptr = rtsx_get_cmd_data(chip);
>> pr_debug("Boot block data:\n");
>> - RTSX_DUMP(ptr, 16);
>> + rtsx_hex_dump(ptr, 16);
>> /* Block ID error
>> * HEADER_ID0, HEADER_ID1
>> diff --git a/drivers/staging/rts5208/rtsx_chip.c
>> b/drivers/staging/rts5208/rtsx_chip.c
>> index 8f447ef..761e83c 100644
>> --- a/drivers/staging/rts5208/rtsx_chip.c
>> +++ b/drivers/staging/rts5208/rtsx_chip.c
>> @@ -1299,8 +1299,8 @@ int rtsx_write_cfg_seq(struct rtsx_chip *chip, u8
>> func, u16 addr, u8 *buf,
>> }
>> }
>> - RTSX_DUMP(mask, dw_len * 4);
>> - RTSX_DUMP(data, dw_len * 4);
>> + rtsx_hex_dump(mask, dw_len * 4);
>> + rtsx_hex_dump(data, dw_len * 4);
>> for (i = 0; i < dw_len; i++) {
>> retval = rtsx_write_cfg_dw(chip, func, aligned_addr + i *
>> 4,
>> diff --git a/drivers/staging/rts5208/rtsx_scsi.c
>> b/drivers/staging/rts5208/rtsx_scsi.c
>> index fd3c2e7..8269a02 100644
>> --- a/drivers/staging/rts5208/rtsx_scsi.c
>> +++ b/drivers/staging/rts5208/rtsx_scsi.c
>> @@ -40,7 +40,8 @@
>> void scsi_show_command(struct scsi_cmnd *srb)
>> {
>> char *what = NULL;
>> - int i, unknown_cmd = 0;
>> + int unknown_cmd = 0;
>> + size_t len;
>> switch (srb->cmnd[0]) {
>> case TEST_UNIT_READY:
>> @@ -319,10 +320,8 @@ void scsi_show_command(struct scsi_cmnd *srb)
>> pr_debug("Command %s (%d bytes)\n", what, srb->cmd_len);
>> if (unknown_cmd) {
>> - pr_debug("");
>> - for (i = 0; i < srb->cmd_len && i < 16; i++)
>> - pr_debug(" %02x", srb->cmnd[i]);
>> - pr_debug("\n");
>> + len = min_t(size_t, srb->cmd_len, 16);
>> + rtsx_hex_dump(srb->cmnd, len);
>> }
>> }
>> diff --git a/drivers/staging/rts5208/sd.c b/drivers/staging/rts5208/sd.c
>> index 96acd39..2f50f9c 100644
>> --- a/drivers/staging/rts5208/sd.c
>> +++ b/drivers/staging/rts5208/sd.c
>> @@ -426,7 +426,7 @@ static int sd_check_csd(struct rtsx_chip *chip, char
>> check_wp)
>> memcpy(sd_card->raw_csd, rsp + 1, 15);
>> pr_debug("CSD Response:\n");
>> - RTSX_DUMP(sd_card->raw_csd, 16);
>> + rtsx_hex_dump(sd_card->raw_csd, 16);
>> csd_ver = (rsp[1] & 0xc0) >> 6;
>> pr_debug("csd_ver = %d\n", csd_ver);
>> @@ -1059,7 +1059,7 @@ static int sd_check_switch_mode(struct rtsx_chip
>> *chip, u8 mode,
>> TRACE_RET(chip, STATUS_FAIL);
>> }
>> - RTSX_DUMP(buf, 64);
>> + rtsx_hex_dump(buf, 64);
>> if (func_group == NO_ARGUMENT) {
>> sd_card->func_group1_mask = buf[0x0D];
>> @@ -2107,7 +2107,7 @@ static int sd_check_wp_state(struct rtsx_chip *chip)
>> }
>> pr_debug("ACMD13:\n");
>> - RTSX_DUMP(buf, 64);
>> + rtsx_hex_dump(buf, 64);
>> sd_card_type = ((u16)buf[2] << 8) | buf[3];
>> pr_debug("sd_card_type = 0x%04x\n", sd_card_type);
>> diff --git a/drivers/staging/rts5208/trace.h
>> b/drivers/staging/rts5208/trace.h
>> index 7fcb459..8386a20 100644
>> --- a/drivers/staging/rts5208/trace.h
>> +++ b/drivers/staging/rts5208/trace.h
>> @@ -82,12 +82,12 @@ static inline char *filename(char *path)
>> #define TRACE_GOTO(chip, label) goto label
>> #endif
>> -#ifdef CONFIG_RTS5208_DEBUG
>> -#define RTSX_DUMP(buf, buf_len)\
>> - print_hex_dump(KERN_DEBUG, KBUILD_MODNAME ": ", \
>> - DUMP_PREFIX_NONE, 16, 1, (buf), (buf_len), false)
>> +#ifdef DEBUG
>> +#define rtsx_hex_dump(buf, len)\
>> + print_hex_dump_bytes(KBUILD_MODNAME ": ", DUMP_PREFIX_NONE, buf,
>> len)
>> #else
>> -#d
Re: [PATCH v2 4/4] Staging: rts5208: Fix a format specifier for dev_err
Hi Micky,
in the latest linux-tree sources, lun field in struct scsi_device from
include/scsi/scsi_device.h is a u64:
unsigned int id, channel;
u64 lun;
unsigned int manufacturer;
so we get a compiler warning if we keep the %u specifier.
Regards,
Fabio
On Tue, Jul 8, 2014 at 4:13 AM, micky wrote:
> On 07/07/2014 03:10 PM, Fabio Falzoi wrote:
>>
>> Fix an incorrect use of the %d format specifier in dev_err that caused a
>> warning.
>>
>> Signed-off-by: Fabio Falzoi
>> ---
>> drivers/staging/rts5208/rtsx.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/rts5208/rtsx.c
>> b/drivers/staging/rts5208/rtsx.c
>> index 4f5f7a3..9aae7ac 100644
>> --- a/drivers/staging/rts5208/rtsx.c
>> +++ b/drivers/staging/rts5208/rtsx.c
>> @@ -463,14 +463,14 @@ static int rtsx_control_thread(void *__dev)
>> * the maximum known LUN
>> */
>> else if (chip->srb->device->id) {
>> - dev_err(&dev->pci->dev, "Bad target number
>> (%d:%d)\n",
>> + dev_err(&dev->pci->dev, "Bad target number
>> (%d:%llu)\n",
>
> here exist some compile warning.
> drivers/staging/rts5208/rtsx.c:468:5: warning: format ‘%llu’ expects
> argument of type ‘long long unsigned int’, but argument 4 has type ‘unsigned
> int’ [-Wformat]
>
>
>> chip->srb->device->id,
>> chip->srb->device->lun);
>> chip->srb->result = DID_BAD_TARGET << 16;
>> }
>> else if (chip->srb->device->lun > chip->max_lun) {
>> - dev_err(&dev->pci->dev, "Bad LUN (%d:%d)\n",
>> + dev_err(&dev->pci->dev, "Bad LUN (%d:%llu)\n",
>> chip->srb->device->id,
>> chip->srb->device->lun);
>> chip->srb->result = DID_BAD_TARGET << 16;
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv2 17/32] ARM: at91/dt: ge863-pro3: define crystals frequencies
Hi,
the slow crystal is not on the module "ge863-pro3", but it's usually on application board. So I think this clock should
be in board dts.
Dne 7.7.2014 22:23, Alexandre Belloni napsal(a):
Define Telit GE863-PRO3, AK signal CDU and Telit EVK-PRO3 main and slow
crystals frequencies.
Signed-off-by: Alexandre Belloni
Cc: Fabio Porcedda
Cc: Jiri Prchal
---
arch/arm/boot/dts/ge863-pro3.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/ge863-pro3.dtsi
b/arch/arm/boot/dts/ge863-pro3.dtsi
index 230099bb31c8..a32fdbefbbd9 100644
--- a/arch/arm/boot/dts/ge863-pro3.dtsi
+++ b/arch/arm/boot/dts/ge863-pro3.dtsi
@@ -19,6 +19,14 @@
compatible = "atmel,osc", "fixed-clock";
clock-frequency = <600>;
};
+
+ slow_xtal {
+ clock-frequency = <32768>;
+ };
+
+ main_xtal {
+ clock-frequency = <600>;
+ };
};
ahb {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/1] ARM: imx: use PTR_ERR_OR_ZERO
On Tue, Jul 8, 2014 at 10:49 AM, Shawn Guo wrote: > On Tue, Jul 08, 2014 at 09:18:56AM +0530, Sachin Kamat wrote: >> Hi Shawn, >> >> On Mon, Jul 7, 2014 at 11:25 AM, Shawn Guo wrote: >> > On Fri, Jul 04, 2014 at 09:03:10PM +0200, Fabian Frederick wrote: >> >> replace IS_ERR/PTR_ERR >> >> >> >> Cc: Shawn Guo >> >> Cc: Sascha Hauer >> >> Cc: linux-arm-ker...@lists.infradead.org >> >> Signed-off-by: Fabian Frederick >> > >> > Applied, thanks. >> >> >> I had sent a similar series [1] in May which you rejected. Just >> curious if something >> changed between then and now? > > The main difference is this is the second attempt from a different > person to "clean up" the code. I'm still not fond of the change, but > I'm getting tied to tell people about that, so just applied the change, > since after all it at least gives some good diffstat. > > I would prefer Fabian's patch over yours because it's really good > enough to have one patch than 5 patches in a series to do the change for > IMX platform. Doesn't really matter whose patches are in. I was just curious to know the change in logic at this point of time. Thanks for clarification. -- Regards, Sachin. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/8] phy: core: Support regulator supply for PHY power
Hi Greg, On Tuesday 08 July 2014 07:15 AM, Greg KH wrote: > On Mon, Jul 07, 2014 at 12:18:23PM +0530, Kishon Vijay Abraham I wrote: >> From: Roger Quadros >> >> Some PHYs can be powered by an external power regulator. >> e.g. USB_HS PHY on DRA7 SoC. Make the PHY core support a >> power regulator. >> >> Signed-off-by: Roger Quadros >> Signed-off-by: Kishon Vijay Abraham I >> --- >> drivers/phy/phy-core.c | 26 ++ >> include/linux/phy/phy.h |2 ++ >> 2 files changed, 28 insertions(+) > > This looks like a new feature :( > > again, I can't take that for 3.16-final, you know better... In the outset it looks like a new feature (which actually is) but it actually is needed to get USB and SATA working in DRA7xx. It was working before since these regulators were *always on* before. But now the the users of these regulators should explicitly enable it. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/8] phy: core: Fix error path in phy_create()
Hi, On Tuesday 08 July 2014 07:15 AM, Greg KH wrote: > On Mon, Jul 07, 2014 at 12:18:22PM +0530, Kishon Vijay Abraham I wrote: >> From: Roger Quadros >> >> Prevent resources from being freed twice in case device_add() call >> fails within phy_create(). Also use ida_simple_remove() instead of >> ida_remove() as we had used ida_simple_get() to allocate the ida. >> >> Signed-off-by: Roger Quadros >> Signed-off-by: Kishon Vijay Abraham I >> --- >> drivers/phy/phy-core.c |7 --- >> 1 file changed, 4 insertions(+), 3 deletions(-) > > Is this a problem in older kernels as well? yeah. Will send it for stable kernel. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] appletalk: Fix socket referencing in skb
On Mon, 2014-07-07 at 23:22 +0300, Andrey Utkin wrote: > Setting just skb->sk without taking its reference and setting a > destructor is invalid. However, in the places where this was done, skb > is used in a way not requiring skb->sk setting. So dropping the setting > of skb->sk. > Thanks to Eric Dumazet for correct solution. > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79441 > Reported-by: Ed Martin > Signed-off-by: Andrey Utkin > --- Thanks ! Signed-off-by: Eric Dumazet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/8] phy: phy-samsung-usb2: Change phy power on/power off sequence
Hi Greg, On Tuesday 08 July 2014 07:14 AM, Greg KH wrote: > On Mon, Jul 07, 2014 at 12:18:20PM +0530, Kishon Vijay Abraham I wrote: >> From: Kamil Debski >> >> The Exynos4412 USB 2.0 PHY hardware differs from the description provided >> in the documentation. Some register bits have different function. This >> patch fixes the defines of register bits and changes the way how phys are >> powered on and off. >> >> Signed-off-by: Kamil Debski >> Tested-by: Marek Szyprowski >> Tested-by: Daniel Drake >> Signed-off-by: Kishon Vijay Abraham I >> --- >> drivers/phy/phy-exynos4x12-usb2.c | 112 >> + >> drivers/phy/phy-exynos5250-usb2.c |2 - >> drivers/phy/phy-samsung-usb2.h|3 +- >> 3 files changed, 77 insertions(+), 40 deletions(-) >> > > This doesn't look like a regression fix for 3.16-final, it looks like a > "new feature" to me :( This patch was primarily due to the incorrectly documented register bits in the manual. So thought this would qualify as fix and should be in 3.16. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v10 7/7] mm: Don't split THP page when syscall is called
On Tue, Jul 08, 2014 at 10:30:38AM +0900, Minchan Kim wrote:
> On Mon, Jul 07, 2014 at 02:13:03PM +0300, Kirill A. Shutemov wrote:
> > On Mon, Jul 07, 2014 at 09:53:58AM +0900, Minchan Kim wrote:
> > > We don't need to split THP page when MADV_FREE syscall is
> > > called. It could be done when VM decide really frees it so
> > > we could reduce the number of THP split.
> > >
> > > Signed-off-by: Minchan Kim
> > > ---
> > > include/linux/huge_mm.h | 3 +++
> > > mm/huge_memory.c| 25 +
> > > mm/madvise.c| 19 +--
> > > mm/rmap.c | 4
> > > mm/vmscan.c | 24
> > > 5 files changed, 65 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> > > index 63579cb8d3dc..f0d37238cf8f 100644
> > > --- a/include/linux/huge_mm.h
> > > +++ b/include/linux/huge_mm.h
> > > @@ -19,6 +19,9 @@ extern struct page *follow_trans_huge_pmd(struct
> > > vm_area_struct *vma,
> > > unsigned long addr,
> > > pmd_t *pmd,
> > > unsigned int flags);
> > > +extern int madvise_free_pmd(struct mmu_gather *tlb,
> > > + struct vm_area_struct *vma,
> > > + pmd_t *pmd, unsigned long addr);
> > > extern int zap_huge_pmd(struct mmu_gather *tlb,
> > > struct vm_area_struct *vma,
> > > pmd_t *pmd, unsigned long addr);
> > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > > index 5d562a9fe931..2a70069dcfc0 100644
> > > --- a/mm/huge_memory.c
> > > +++ b/mm/huge_memory.c
> > > @@ -1384,6 +1384,31 @@ out:
> > > return 0;
> > > }
> > >
> > > +int madvise_free_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
> > > + pmd_t *pmd, unsigned long addr)
> > > +{
> > > + spinlock_t *ptl;
> > > + int ret = 0;
> > > +
> > > + if (__pmd_trans_huge_lock(pmd, vma, &ptl) == 1) {
> > > + pmd_t orig_pmd;
> > > + struct mm_struct *mm = vma->vm_mm;
> > > +
> > > + /* No hugepage in swapcache */
> > > + VM_BUG_ON(PageSwapCache(pmd_page(orig_pmd)));
> >
> > VM_BUG_ON_PAGE() ?
>
> NP.
>
> >
> > > +
> > > + orig_pmd = pmdp_get_and_clear(tlb->mm, addr, pmd);
> > > + orig_pmd = pmd_mkold(orig_pmd);
> > > + orig_pmd = pmd_mkclean(orig_pmd);
> > > +
> > > + set_pmd_at(mm, addr, pmd, orig_pmd);
> > > + tlb_remove_pmd_tlb_entry(tlb, pmd, addr);
> > > + spin_unlock(ptl);
> > > + ret = 1;
> > > + }
> > > + return ret;
> > > +}
> > > +
> > > int zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
> > >pmd_t *pmd, unsigned long addr)
> > > {
> > > diff --git a/mm/madvise.c b/mm/madvise.c
> > > index 372a25a8ea82..3c99919ee094 100644
> > > --- a/mm/madvise.c
> > > +++ b/mm/madvise.c
> > > @@ -320,8 +320,23 @@ static inline unsigned long
> > > madvise_free_pmd_range(struct mmu_gather *tlb,
> > >* if the range covers.
> > >*/
> > > next = pmd_addr_end(addr, end);
> > > - if (pmd_trans_huge(*pmd))
> > > - split_huge_page_pmd(vma, addr, pmd);
> > > + if (pmd_trans_huge(*pmd)) {
> > > + if (next - addr != HPAGE_PMD_SIZE) {
> > > +#ifdef CONFIG_DEBUG_VM
> > > + if (!rwsem_is_locked(&tlb->mm->mmap_sem)) {
> > > + pr_err("%s: mmap_sem is unlocked!
> > > addr=0x%lx end=0x%lx vma->vm_start=0x%lx vma->vm_end=0x%lx\n",
> > > + __func__, addr, end,
> > > + vma->vm_start,
> > > + vma->vm_end);
> > > + BUG();
> > > + }
> > > +#endif
> > > + split_huge_page_pmd(vma, addr, pmd);
> > > + } else if (madvise_free_pmd(tlb, vma, pmd, addr))
> > > + goto next;
> > > + /* fall through */
> > > + }
> > > +
> > > /*
> > >* Here there can be other concurrent MADV_DONTNEED or
> > >* trans huge page faults running, and if the pmd is
> > > diff --git a/mm/rmap.c b/mm/rmap.c
> > > index ee495d84c8b3..3c415eb8b6f0 100644
> > > --- a/mm/rmap.c
> > > +++ b/mm/rmap.c
> > > @@ -702,6 +702,10 @@ static int page_referenced_one(struct page *page,
> > > struct vm_area_struct *vma,
> > > /* go ahead even if the pmd is pmd_trans_splitting() */
> > > if (pmdp_clear_flush_young_notify(vma, address, pmd))
> > > referenced++;
> > > +
> > > + if (pmd_dirty(*pmd))
> > > + dirty++;
> > > +
> > > spin_unlock(ptl);
> > > } else {
> > > pte_t *pte;
> > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > index f7a45600846f..4e15babf4414 1006
RE: [PATCH 3/4] power_supply: Introduce PSE compliant algorithm
> > +static int get_tempzone(struct psy_pse_chrg_prof *pse_mod_bprof,
> > + int temp)
> > +{
> > + int i = 0;
> > + int temp_range_cnt;
> > +
> > + temp_range_cnt = min_t(u16, pse_mod_bprof->temp_mon_ranges,
> > + BATT_TEMP_NR_RNG);
> > + if ((temp < pse_mod_bprof->temp_low_lim) ||
> > + (temp > pse_mod_bprof->temp_mon_range[0].temp_up_lim))
> > + return -EINVAL;
> > +
> > + for (i = 0; i < temp_range_cnt; ++i)
> > + if (temp > pse_mod_bprof->temp_mon_range[i].temp_up_lim)
> > + break;
> > + return i-1;
> > +}
>
> pse_mod_bprof->temp_mon_ranges > BATT_TEMP_NR_RNG is not allowed, so I
> suggest to print an error and return some error code.
>
min_t takes care of the upper bound. The algorithm process BATT_TEMP_NR_RNG
even if the actual number of zones are greater than this.
Agree to other comments
-Jenny
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v11 4/7] powerpc: add pmd_[dirty|mkclean] for THP
MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent overwrite of the contents since MADV_FREE syscall is called for THP page. This patch adds pmd_dirty and pmd_mkclean for THP page MADV_FREE support. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: "Aneesh Kumar K.V" Cc: linuxppc-...@lists.ozlabs.org Signed-off-by: Minchan Kim --- arch/powerpc/include/asm/pgtable-ppc64.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h index eb9261024f51..c9a4bbe8e179 100644 --- a/arch/powerpc/include/asm/pgtable-ppc64.h +++ b/arch/powerpc/include/asm/pgtable-ppc64.h @@ -468,9 +468,11 @@ static inline pte_t *pmdp_ptep(pmd_t *pmd) #define pmd_pfn(pmd) pte_pfn(pmd_pte(pmd)) #define pmd_young(pmd) pte_young(pmd_pte(pmd)) +#define pmd_dirty(pmd) pte_dirty(pmd_pte(pmd)) #define pmd_mkold(pmd) pte_pmd(pte_mkold(pmd_pte(pmd))) #define pmd_wrprotect(pmd) pte_pmd(pte_wrprotect(pmd_pte(pmd))) #define pmd_mkdirty(pmd) pte_pmd(pte_mkdirty(pmd_pte(pmd))) +#define pmd_mkclean(pmd) pte_pmd(pte_mkclean(pmd_pte(pmd))) #define pmd_mkyoung(pmd) pte_pmd(pte_mkyoung(pmd_pte(pmd))) #define pmd_mkwrite(pmd) pte_pmd(pte_mkwrite(pmd_pte(pmd))) -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v11 2/7] x86: add pmd_[dirty|mkclean] for THP
MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent
overwrite of the contents since MADV_FREE syscall is called for
THP page.
This patch adds pmd_dirty and pmd_mkclean for THP page MADV_FREE
support.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Acked-by: Kirill A. Shutemov
Signed-off-by: Minchan Kim
---
arch/x86/include/asm/pgtable.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 0ec056012618..329865799653 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -104,6 +104,11 @@ static inline int pmd_young(pmd_t pmd)
return pmd_flags(pmd) & _PAGE_ACCESSED;
}
+static inline int pmd_dirty(pmd_t pmd)
+{
+ return pmd_flags(pmd) & _PAGE_DIRTY;
+}
+
static inline int pte_write(pte_t pte)
{
return pte_flags(pte) & _PAGE_RW;
@@ -267,6 +272,11 @@ static inline pmd_t pmd_mkold(pmd_t pmd)
return pmd_clear_flags(pmd, _PAGE_ACCESSED);
}
+static inline pmd_t pmd_mkclean(pmd_t pmd)
+{
+ return pmd_clear_flags(pmd, _PAGE_DIRTY);
+}
+
static inline pmd_t pmd_wrprotect(pmd_t pmd)
{
return pmd_clear_flags(pmd, _PAGE_RW);
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v11 5/7] s390: add pmd_[dirty|mkclean] for THP
MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent
overwrite of the contents since MADV_FREE syscall is called for
THP page but for s390 pmds only referenced bit is available
because there is no free bit left in the pmd entry for the
software dirty bit so this patch adds dumb pmd_dirty which
returns always true by suggesting by Martin.
They finally find a solution in future.
http://marc.info/?l=linux-api&m=140440328820808&w=2
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: Dominik Dingel
Cc: Christian Borntraeger
Cc: linux-s...@vger.kernel.org
Acked-by: Gerald Schaefer
Signed-off-by: Minchan Kim
---
arch/s390/include/asm/pgtable.h | 12
1 file changed, 12 insertions(+)
diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index fcba5e03839f..9862fcb0592b 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -1586,6 +1586,18 @@ static inline pmd_t pmd_mkdirty(pmd_t pmd)
return pmd;
}
+static inline int pmd_dirty(pmd_t pmd)
+{
+ /* No dirty bit in the segment table entry */
+ return 1;
+}
+
+static inline pmd_t pmd_mkclean(pmd_t pmd)
+{
+ /* No dirty bit in the segment table entry */
+ return pmd;
+}
+
#define __HAVE_ARCH_PMDP_TEST_AND_CLEAR_YOUNG
static inline int pmdp_test_and_clear_young(struct vm_area_struct *vma,
unsigned long address, pmd_t *pmdp)
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v11 6/7] ARM: add pmd_[dirty|mkclean] for THP
MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent
overwrite of the contents since MADV_FREE syscall is called for
THP page.
This patch adds pmd_dirty and pmd_mkclean for THP page MADV_FREE
support.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Steve Capper
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Minchan Kim
---
arch/arm/include/asm/pgtable-3level.h | 3 +++
arch/arm64/include/asm/pgtable.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/arch/arm/include/asm/pgtable-3level.h
b/arch/arm/include/asm/pgtable-3level.h
index 85c60adc8b60..3a7bb8dc7d05 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -220,6 +220,8 @@ static inline pmd_t *pmd_offset(pud_t *pud, unsigned long
addr)
#define pmd_trans_splitting(pmd) (pmd_val(pmd) & PMD_SECT_SPLITTING)
#endif
+#define pmd_dirty (pmd_val(pmd) & PMD_SECT_DIRTY)
+
#define PMD_BIT_FUNC(fn,op) \
static inline pmd_t pmd_##fn(pmd_t pmd) { pmd_val(pmd) op; return pmd; }
@@ -228,6 +230,7 @@ PMD_BIT_FUNC(mkold, &= ~PMD_SECT_AF);
PMD_BIT_FUNC(mksplitting, |= PMD_SECT_SPLITTING);
PMD_BIT_FUNC(mkwrite, &= ~PMD_SECT_RDONLY);
PMD_BIT_FUNC(mkdirty, |= PMD_SECT_DIRTY);
+PMD_BIT_FUNC(mkclean, &= ~PMD_SECT_DIRTY);
PMD_BIT_FUNC(mkyoung, |= PMD_SECT_AF);
#define pmd_mkhuge(pmd)(__pmd(pmd_val(pmd) & ~PMD_TABLE_BIT))
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 579702086488..f3ec01cef04f 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -240,10 +240,12 @@ static inline pmd_t pte_pmd(pte_t pte)
#endif
#define pmd_young(pmd) pte_young(pmd_pte(pmd))
+#define pmd_dirty(pmd) pte_dirty(pmd_pte(pmd))
#define pmd_wrprotect(pmd) pte_pmd(pte_wrprotect(pmd_pte(pmd)))
#define pmd_mksplitting(pmd) pte_pmd(pte_mkspecial(pmd_pte(pmd)))
#define pmd_mkold(pmd) pte_pmd(pte_mkold(pmd_pte(pmd)))
#define pmd_mkwrite(pmd) pte_pmd(pte_mkwrite(pmd_pte(pmd)))
+#define pmd_mkclean(pmd) pte_pmd(pte_mkclean(pmd_pte(pmd)))
#define pmd_mkdirty(pmd) pte_pmd(pte_mkdirty(pmd_pte(pmd)))
#define pmd_mkyoung(pmd) pte_pmd(pte_mkyoung(pmd_pte(pmd)))
#define pmd_mknotpresent(pmd) (__pmd(pmd_val(pmd) & ~PMD_TYPE_MASK))
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v11 7/7] mm: Don't split THP page when syscall is called
We don't need to split THP page when MADV_FREE syscall is
called. It could be done when VM decide really frees it so
we could avoid unnecessary THP split.
Signed-off-by: Minchan Kim
---
mm/madvise.c | 20 +++-
mm/rmap.c| 7 +++
mm/vmscan.c | 28 ++--
3 files changed, 40 insertions(+), 15 deletions(-)
diff --git a/mm/madvise.c b/mm/madvise.c
index a6aa7d4c4e02..77f13a99584c 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -272,7 +272,25 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned
long addr,
pte_t *pte, ptent;
struct page *page;
- split_huge_page_pmd(vma, addr, pmd);
+ if (pmd_trans_huge_lock(pmd, vma, &ptl) == 1) {
+ struct page *page;
+ pmd_t orig_pmd;
+
+ orig_pmd = pmdp_get_and_clear(mm, addr, pmd);
+
+ /* No hugepage in swapcache */
+ page = pmd_page(orig_pmd);
+ VM_BUG_ON_PAGE(PageSwapCache(page), page);
+
+ orig_pmd = pmd_mkold(orig_pmd);
+ orig_pmd = pmd_mkclean(orig_pmd);
+
+ set_pmd_at(mm, addr, pmd, orig_pmd);
+ tlb_remove_pmd_tlb_entry(tlb, pmd, addr);
+ spin_unlock(ptl);
+ return 0;
+ }
+
if (pmd_trans_unstable(pmd))
return 0;
diff --git a/mm/rmap.c b/mm/rmap.c
index a8e34596dc97..67e1c1859c1d 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -703,10 +703,9 @@ static int page_referenced_one(struct page *page, struct
vm_area_struct *vma,
if (pmdp_clear_flush_young_notify(vma, address, pmd))
referenced++;
- /*
-* In this implmentation, MADV_FREE doesn't support THP free
-*/
- dirty++;
+ if (pmd_dirty(*pmd))
+ dirty++;
+
spin_unlock(ptl);
} else {
pte_t *pte;
diff --git a/mm/vmscan.c b/mm/vmscan.c
index d88413ccadcc..6557f0b36321 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -971,17 +971,25 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
* Anonymous process memory has backing store?
* Try to allocate it some swap space here.
*/
- if (PageAnon(page) && !PageSwapCache(page) && !freeable) {
- if (!(sc->gfp_mask & __GFP_IO))
- goto keep_locked;
- if (!add_to_swap(page, page_list))
- goto activate_locked;
- may_enter_fs = 1;
-
- /* Adding to swap updated mapping */
- mapping = page_mapping(page);
+ if (PageAnon(page) && !PageSwapCache(page)) {
+ if (!freeable) {
+ if (!(sc->gfp_mask & __GFP_IO))
+ goto keep_locked;
+ if (!add_to_swap(page, page_list))
+ goto activate_locked;
+ may_enter_fs = 1;
+ /* Adding to swap updated mapping */
+ mapping = page_mapping(page);
+ } else {
+ if (likely(!PageTransHuge(page)))
+ goto unmap;
+ /* try_to_unmap isn't aware of THP page */
+ if (unlikely(split_huge_page_to_list(page,
+ page_list)))
+ goto keep_locked;
+ }
}
-
+unmap:
/*
* The page is mapped into the page tables of one or more
* processes. Try to unmap it here.
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] power_supply: Introduce PSE compliant algorithm
As per Product Safety Engineering (PSE) specification for battery charging, the
battery characteristics and thereby the charging rates can vary on different
temperature zones. This patch introduces a PSE compliant charging algorithm with
maintenance charging support. The algorithm can be selected by the power supply
charging driver based on the type of the battery charging profile.
Signed-off-by: Jenny TC
---
drivers/power/Kconfig | 15 ++
drivers/power/Makefile |1 +
drivers/power/charging_algo_pse.c | 203
include/linux/power/power_supply_charger.h | 66 +
4 files changed, 285 insertions(+)
create mode 100644 drivers/power/charging_algo_pse.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index f679f82..54a0321 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -22,6 +22,21 @@ config POWER_SUPPLY_CHARGER
drivers to keep the charging logic outside and the charger driver
just need to abstract the charger hardware.
+config POWER_SUPPLY_CHARGING_ALGO_PSE
+ bool "PSE compliant charging algorithm"
+ depends on POWER_SUPPLY_CHARGER
+ help
+ Say Y here to select Product Safety Engineering (PSE) compliant
+ charging algorithm. As per PSE standard the battery characteristics
+ and thereby the charging rates can vary on different temperature
+ zones. Select this if your charging algorithm need to change the
+ charging parameters based on the battery temperature and the battery
+ charging profile follows the struct psy_pse_chrg_prof definition.
+ This config will enable PSE compliant charging algorithm with
+ maintenance charging support. At runtime the algorithm will be
+ selected by the psy charger driver based on the type of the battery
+ charging profile.
+
config PDA_POWER
tristate "Generic PDA/phone power driver"
depends on !S390
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 405f0f4..77535fd 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_POWER_SUPPLY) += power_supply.o
obj-$(CONFIG_GENERIC_ADC_BATTERY) += generic-adc-battery.o
obj-$(CONFIG_POWER_SUPPLY_CHARGER) += power_supply_charger.o
+obj-$(CONFIG_POWER_SUPPLY_CHARGING_ALGO_PSE) += charging_algo_pse.o
obj-$(CONFIG_PDA_POWER)+= pda_power.o
obj-$(CONFIG_APM_POWER)+= apm_power.o
obj-$(CONFIG_MAX8925_POWER)+= max8925_power.o
diff --git a/drivers/power/charging_algo_pse.c
b/drivers/power/charging_algo_pse.c
new file mode 100644
index 000..fbc9ea6
--- /dev/null
+++ b/drivers/power/charging_algo_pse.c
@@ -0,0 +1,203 @@
+/*
+ * Copyright (C) 2012 Intel Corporation
+ *
+ * ~~
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the GNU
+ * General Public License for more details.
+ *
+ * ~~
+ * Author: Jenny TC
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "power_supply.h"
+#include "power_supply_charger.h"
+
+/* 98% of CV is considered as voltage to detect Full */
+#define FULL_CV_MIN 98
+
+/*
+ * Offset to exit from maintenance charging. In maintenance charging
+ * if the volatge is less than the (maintenance_lower_threshold -
+ * MAINT_EXIT_OFFSET) then system can switch to normal charging
+ */
+
+#define MAINT_EXIT_OFFSET 50 /* mV */
+
+static int get_tempzone(struct psy_pse_chrg_prof *pse_mod_bprof,
+ int temp)
+{
+ int i = 0;
+ int temp_range_cnt;
+
+ temp_range_cnt = min_t(u16, pse_mod_bprof->temp_mon_ranges,
+ BATT_TEMP_NR_RNG);
+ if ((temp < pse_mod_bprof->temp_min) ||
+ (temp > pse_mod_bprof->temp_mon_range[0].temp_max))
+ return -EINVAL;
+
+ for (i = 0; i < temp_range_cnt; ++i)
+ if (temp > pse_mod_bprof->temp_mon_range[i].temp_max)
+ break;
+ return i-1;
+}
+
+static inline bool is_charge_terminated(long volt, long cur,
+ long iterm, unsigned long cv)
+{
+ return (cur > 0) && (cur <= iterm) &&
+ ((volt * 100) >= (FULL_CV_MIN * cv));
+}
+
+static inline bool is_battery_full(struct psy_batt_context *batt_cxt,
+ struct psy_pse_chrg_prof *pse_mod_bprof, unsigned long cv)
+{
+ int
[PATCH 1/4] power_supply: Add inlmt,iterm, min/max temp props
Add new power supply properties for input current, charge termination
current, min and max temperature
POWER_SUPPLY_PROP_TEMP_MIN - minimum operatable temperature
POWER_SUPPLY_PROP_TEMP_MAX - maximum operatable temperature
POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT - input current limit programmed
by charger. Indicates the input current for a charging source.
POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT - Charge termination current used
to detect the end of charge condition
Signed-off-by: Jenny TC
---
Documentation/power/power_supply_class.txt |6 ++
drivers/power/power_supply_sysfs.c |4
include/linux/power_supply.h |4
3 files changed, 14 insertions(+)
diff --git a/Documentation/power/power_supply_class.txt
b/Documentation/power/power_supply_class.txt
index 89a8816..48cff88 100644
--- a/Documentation/power/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.txt
@@ -118,6 +118,10 @@ relative, time-based measurements.
CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger.
CONSTANT_CHARGE_CURRENT_MAX - maximum charge current supported by the
power supply object.
+INPUT_CURRENT_LIMIT - input current limit programmed by charger. Indicates
+the current drawn from a charging source.
+CHARGE_TERM_CURRENT - Charge termination current used to detect the end of
charge
+condition.
CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger.
CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by the
@@ -140,6 +144,8 @@ TEMP_ALERT_MAX - maximum battery temperature alert.
TEMP_AMBIENT - ambient temperature.
TEMP_AMBIENT_ALERT_MIN - minimum ambient temperature alert.
TEMP_AMBIENT_ALERT_MAX - maximum ambient temperature alert.
+TEMP_MIN - minimum operatable temperature
+TEMP_MAX - maximum operatable temperature
TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e.
while battery powers a load)
diff --git a/drivers/power/power_supply_sysfs.c
b/drivers/power/power_supply_sysfs.c
index 44420d1..750a202 100644
--- a/drivers/power/power_supply_sysfs.c
+++ b/drivers/power/power_supply_sysfs.c
@@ -167,6 +167,7 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(constant_charge_voltage_max),
POWER_SUPPLY_ATTR(charge_control_limit),
POWER_SUPPLY_ATTR(charge_control_limit_max),
+ POWER_SUPPLY_ATTR(input_current_limit),
POWER_SUPPLY_ATTR(energy_full_design),
POWER_SUPPLY_ATTR(energy_empty_design),
POWER_SUPPLY_ATTR(energy_full),
@@ -178,6 +179,8 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(capacity_alert_max),
POWER_SUPPLY_ATTR(capacity_level),
POWER_SUPPLY_ATTR(temp),
+ POWER_SUPPLY_ATTR(temp_max),
+ POWER_SUPPLY_ATTR(temp_min),
POWER_SUPPLY_ATTR(temp_alert_min),
POWER_SUPPLY_ATTR(temp_alert_max),
POWER_SUPPLY_ATTR(temp_ambient),
@@ -189,6 +192,7 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(time_to_full_avg),
POWER_SUPPLY_ATTR(type),
POWER_SUPPLY_ATTR(scope),
+ POWER_SUPPLY_ATTR(charge_term_current),
/* Properties of type `const char *' */
POWER_SUPPLY_ATTR(model_name),
POWER_SUPPLY_ATTR(manufacturer),
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index c9dc4e0..0278600 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -120,6 +120,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX,
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT,
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX,
+ POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN,
POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN,
POWER_SUPPLY_PROP_ENERGY_FULL,
@@ -131,6 +132,8 @@ enum power_supply_property {
POWER_SUPPLY_PROP_CAPACITY_ALERT_MAX, /* in percents! */
POWER_SUPPLY_PROP_CAPACITY_LEVEL,
POWER_SUPPLY_PROP_TEMP,
+ POWER_SUPPLY_PROP_TEMP_MAX,
+ POWER_SUPPLY_PROP_TEMP_MIN,
POWER_SUPPLY_PROP_TEMP_ALERT_MIN,
POWER_SUPPLY_PROP_TEMP_ALERT_MAX,
POWER_SUPPLY_PROP_TEMP_AMBIENT,
@@ -142,6 +145,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_TIME_TO_FULL_AVG,
POWER_SUPPLY_PROP_TYPE, /* use power_supply.type instead */
POWER_SUPPLY_PROP_SCOPE,
+ POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT,
/* Properties of type `const char *' */
POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_MANUFACTURER,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv11 0/4] power_supply: Introduce power supply charging driver
v1: introduced feature as a framework within power supply class driver with separate files for battid framework and charging framework v2: fixed review comments, moved macros and inline functions to power_supply.h v3: moved the feature as a separate driver, combined battid framework and charging framework inside the power supply charging driver. Moved charger specific properties to power_supply_charger.h and plugged the driver with power supply subsystem using power_supply_notifier introduced in my previous patch. Also a sample charger chip driver (bq24261) patch added to give more idea on the psy charging driver usage v4: Fixed review comments, no major design changes. v5: Fixed makefile inconsistencies, removed unused pdata callbacks v6: Fixed nested loops, commenting style v7: added kerneldocs for structs and minor fixes v8: used msecs_to_jiffies instead of HZ directly, modified Kconfig help text for POWER_SUPPLY_CHARGING_ALGO_PSE v9: Removed string lookups, static cable initialization v10: Fixed bug in algorithm lookup v11: Few variable name changes for better readability Jenny TC (4): power_supply: Add inlmt,iterm, min/max temp props power_supply: Introduce generic psy charging driver power_supply: Introduce PSE compliant algorithm power_supply: bq24261 charger driver Documentation/power/power_supply_charger.txt | 350 +++ Documentation/power/power_supply_class.txt |6 + drivers/power/Kconfig| 33 + drivers/power/Makefile |3 + drivers/power/bq24261_charger.c | 1348 ++ drivers/power/charging_algo_pse.c| 202 drivers/power/power_supply_charger.c | 1016 +++ drivers/power/power_supply_charger.h | 226 + drivers/power/power_supply_core.c|3 + drivers/power/power_supply_sysfs.c |4 + include/linux/power/bq24261-charger.h| 25 + include/linux/power/power_supply_charger.h | 372 +++ include/linux/power_supply.h | 165 13 files changed, 3753 insertions(+) create mode 100644 Documentation/power/power_supply_charger.txt create mode 100644 drivers/power/bq24261_charger.c create mode 100644 drivers/power/charging_algo_pse.c create mode 100644 drivers/power/power_supply_charger.c create mode 100644 drivers/power/power_supply_charger.h create mode 100644 include/linux/power/bq24261-charger.h create mode 100644 include/linux/power/power_supply_charger.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: powerpc allyesconfig fix
Hi Nicholas, On Tue, 8 Jul 2014 01:04:09 -0400 Nicholas Krause wrote: > > powerpc:allmodconfig has been failing for some time with the following > error. This patch has already bee submitted directly by Guenter, however for future reference: when you submit someone else's patch, you should include a From line as the first line of the email body containing their email address and you should include a Signed-off-by line from yourself. -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
[PATCH 4/4] power_supply: bq24261 charger driver
This patch introduces BQ24261 charger driver. The driver makes use of power supply charging driver to setup charging. So the driver does hardware abstraction and handles h/w specific corner cases. The charging logic resides with power supply charging driver Signed-off-by: Jenny TC --- drivers/power/Kconfig | 10 + drivers/power/Makefile|1 + drivers/power/bq24261_charger.c | 1348 + include/linux/power/bq24261-charger.h | 25 + 4 files changed, 1384 insertions(+) create mode 100644 drivers/power/bq24261_charger.c create mode 100644 include/linux/power/bq24261-charger.h diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 54a0321..4ff080c 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -411,6 +411,16 @@ config BATTERY_GOLDFISH Say Y to enable support for the battery and AC power in the Goldfish emulator. +config CHARGER_BQ24261 + tristate "BQ24261 charger driver" + select POWER_SUPPLY_CHARGER + depends on I2C + help + Say Y to include support for BQ24261 Charger driver. This driver + makes use of power supply charging driver. So the driver gives + the charger hardware abstraction only. Charging logic is abstracted + in the power supply charging driver. + source "drivers/power/reset/Kconfig" endif # POWER_SUPPLY diff --git a/drivers/power/Makefile b/drivers/power/Makefile index 77535fd..a6e9897 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -59,4 +59,5 @@ obj-$(CONFIG_CHARGER_BQ24735) += bq24735-charger.o obj-$(CONFIG_POWER_AVS)+= avs/ obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o +obj-$(CONFIG_CHARGER_BQ24261) += bq24261_charger.o obj-$(CONFIG_POWER_RESET) += reset/ diff --git a/drivers/power/bq24261_charger.c b/drivers/power/bq24261_charger.c new file mode 100644 index 000..4de73e1 --- /dev/null +++ b/drivers/power/bq24261_charger.c @@ -0,0 +1,1348 @@ +/* + * bq24261-charger.c - BQ24261 Charger I2C client driver + * + * Copyright (C) 2011 Intel Corporation + * + * ~~ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the GNU + * General Public License for more details. + * + * ~~ + * Author: Jenny TC + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +#define DEV_NAME "bq24261_charger" +#define MODEL_NAME_SIZE 8 + +#define EXCEPTION_MONITOR_DELAY (60 * HZ) +#define WDT_RESET_DELAY (15 * HZ) + +/* BQ24261 registers */ +#define BQ24261_STAT_CTRL0_ADDR0x00 +#define BQ24261_CTRL_ADDR 0x01 +#define BQ24261_BATT_VOL_CTRL_ADDR 0x02 +#define BQ24261_VENDOR_REV_ADDR0x03 +#define BQ24261_TERM_FCC_ADDR 0x04 +#define BQ24261_VINDPM_STAT_ADDR 0x05 +#define BQ24261_ST_NTC_MON_ADDR0x06 + +#define BQ24261_RESET_MASK (0x01 << 7) +#define BQ24261_RESET_ENABLE (0x01 << 7) + +#define BQ24261_FAULT_MASK 0x07 +#define BQ24261_STAT_MASK (0x03 << 4) +#define BQ24261_BOOST_MASK (0x01 << 6) +#define BQ24261_TMR_RST_MASK (0x01 << 7) +#define BQ24261_TMR_RST(0x01 << 7) + +#define BQ24261_ENABLE_BOOST (0x01 << 6) + +#define BQ24261_VOVP 0x01 +#define BQ24261_LOW_SUPPLY 0x02 +#define BQ24261_THERMAL_SHUTDOWN 0x03 +#define BQ24261_BATT_TEMP_FAULT0x04 +#define BQ24261_TIMER_FAULT0x05 +#define BQ24261_BATT_OVP 0x06 +#define BQ24261_NO_BATTERY 0x07 +#define BQ24261_STAT_READY 0x00 + +#define BQ24261_STAT_CHRG_PRGRSS (0x01 << 4) +#define BQ24261_STAT_CHRG_DONE (0x02 << 4) +#define BQ24261_STAT_FAULT (0x03 << 4) + +#define BQ24261_CE_MASK(0x01 << 1) +#define BQ24261_CE_DISABLE (0x01 << 1) + +#define BQ24261_HZ_MASK(0x01) +#define BQ24261_HZ_ENABLE (0x01) + +#define BQ24261_ICHRG_MASK (0x1F << 3) +#define BQ24261_MIN_CC 500 /* 500mA */ +#define BQ24261_MAX_CC 3000 /* 3A */ + +#define BQ24261_ITERM_MASK (0x03) +#define BQ24261_MIN_ITERM 50 /* 50 mA */ +#define BQ24261_MAX_ITERM 300 /* 300
[PATCH v11 3/7] sparc: add pmd_[dirty|mkclean] for THP
MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent
overwrite of the contents since MADV_FREE syscall is called for
THP page.
This patch adds pmd_dirty and pmd_mkclean for THP page MADV_FREE
support.
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
Signed-off-by: Minchan Kim
---
arch/sparc/include/asm/pgtable_64.h | 16
1 file changed, 16 insertions(+)
diff --git a/arch/sparc/include/asm/pgtable_64.h
b/arch/sparc/include/asm/pgtable_64.h
index 3770bf5c6e1b..0a3e5fdfead2 100644
--- a/arch/sparc/include/asm/pgtable_64.h
+++ b/arch/sparc/include/asm/pgtable_64.h
@@ -666,6 +666,13 @@ static inline unsigned long pmd_young(pmd_t pmd)
return pte_young(pte);
}
+static inline int pmd_dirty(pmd_t pmd)
+{
+ pte_t pte = __pte(pmd_val(pmd));
+
+ return pte_dirty(pte);
+}
+
static inline unsigned long pmd_write(pmd_t pmd)
{
pte_t pte = __pte(pmd_val(pmd));
@@ -723,6 +730,15 @@ static inline pmd_t pmd_mkdirty(pmd_t pmd)
return __pmd(pte_val(pte));
}
+static inline pmd_mkclean(pmd_t pmd)
+{
+ pte_t pte = __pte(pmd_val(pmd));
+
+ pte = pte_mkclean(pte);
+
+ return __pmd(pte_val(pte));
+}
+
static inline pmd_t pmd_mkyoung(pmd_t pmd)
{
pte_t pte = __pte(pmd_val(pmd));
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v11 1/7] mm: support madvise(MADV_FREE)
Linux doesn't have an ability to free pages lazy while other OS
already have been supported that named by madvise(MADV_FREE).
The gain is clear that kernel can discard freed pages rather than
swapping out or OOM if memory pressure happens.
Without memory pressure, freed pages would be reused by userspace
without another additional overhead(ex, page fault + allocation
+ zeroing).
How to work is following as.
When madvise syscall is called, VM clears dirty bit of ptes of
the range. If memory pressure happens, VM checks dirty bit of
page table and if it found still "clean", it means it's a
"lazyfree pages" so VM could discard the page instead of swapping out.
Once there was store operation for the page before VM peek a page
to reclaim, dirty bit is set so VM can swap out the page instead of
discarding.
Firstly, heavy users would be general allocators(ex, jemalloc,
tcmalloc and hope glibc supports it) and jemalloc/tcmalloc already
have supported the feature for other OS(ex, FreeBSD)
barrios@blaptop:~/benchmark/ebizzy$ lscpu
Architecture: x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):4
On-line CPU(s) list: 0-3
Thread(s) per core:2
Core(s) per socket:2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family:6
Model: 42
Stepping: 7
CPU MHz: 2801.000
BogoMIPS: 5581.64
Virtualization:VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 4096K
NUMA node0 CPU(s): 0-3
ebizzy benchmark(./ebizzy -S 10 -n 512)
vanilla-jemalloc MADV_free-jemalloc
1 thread
records: 10 records: 10
avg: 7682.10 avg: 15306.10
std: 62.35(0.81%)std: 347.99(2.27%)
max: 7770.00 max: 15622.00
min: 7598.00 min: 14772.00
2 thread
records: 10 records: 10
avg: 12747.50avg: 24171.00
std: 792.06(6.21%) std: 895.18(3.70%)
max: 13337.00max: 26023.00
min: 10535.00min: 23152.00
4 thread
records: 10 records: 10
avg: 16474.60avg: 33717.90
std: 1496.45(9.08%) std: 2008.97(5.96%)
max: 17877.00max: 35958.00
min: 12224.00min: 29565.00
8 thread
records: 10 records: 10
avg: 16778.50avg: 33308.10
std: 825.53(4.92%) std: 1668.30(5.01%)
max: 17543.00max: 36010.00
min: 14576.00min: 29577.00
16 thread
records: 10 records: 10
avg: 20614.40avg: 35516.30
std: 602.95(2.92%) std: 1283.65(3.61%)
max: 21753.00max: 37178.00
min: 19605.00min: 33217.00
32 thread
records: 10 records: 10
avg: 22771.70avg: 36018.50
std: 598.94(2.63%) std: 1046.76(2.91%)
max: 24035.00max: 37266.00
min: 22108.00min: 34149.00
In summary, MADV_FREE is about 2 time faster than MADV_DONTNEED.
Cc: Michael Kerrisk
Cc: Linux API
Cc: Hugh Dickins
Cc: Johannes Weiner
Cc: KOSAKI Motohiro
Cc: Mel Gorman
Cc: Jason Evans
Cc: Zhang Yanfei
Acked-by: Rik van Riel
Signed-off-by: Minchan Kim
---
include/linux/rmap.h | 9 ++-
include/linux/vm_event_item.h | 1 +
include/uapi/asm-generic/mman-common.h | 1 +
mm/madvise.c | 135 +
mm/rmap.c | 42 +-
mm/vmscan.c| 40 --
mm/vmstat.c| 1 +
7 files changed, 217 insertions(+), 12 deletions(-)
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index be574506e6a9..0ba377b97a38 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -75,6 +75,7 @@ enum ttu_flags {
TTU_UNMAP = 1, /* unmap mode */
TTU_MIGRATION = 2, /* migration mode */
TTU_MUNLOCK = 4,/* munlock mode */
+ TTU_FREE = 8, /* free mode */
TTU_IGNORE_MLOCK = (1 << 8),/* ignore mlock */
TTU_IGNORE_ACCESS = (1 << 9), /* don't age */
@@ -181,7 +182,8 @@ static inline void page_dup_rmap(struct page *page)
* Called from mm/vmscan.c to handle paging out
*/
int page_referenced(struct page *, int is_locked,
- struct mem_cgroup *memcg, unsigned long *vm_flags);
+ struct mem_cgroup *memcg, unsigned long *vm_flags,
+ int *is_dirty);
#define TTU_ACTION(x) ((x) & TTU_ACTION_MASK)
@@ -260,9 +262,12 @@ int rmap_walk(struct page *page, struct rmap_walk_control
*rwc);
static inline int page_referenced(struct page *page, int is_locked,
[PATCH v11 0/7] MADV_FREE support
This patch enable MADV_FREE hint for madvise syscall, which have been supported by other OSes. [PATCH 1] includes the details. [1] support MADVISE_FREE for !THP page so if VM encounter THP page in syscall context, it splits THP page. [2-6] is to preparing to call madvise syscall without THP plitting [7] enable THP page support for MADV_FREE. * From v10 * Add Acked-by from arch stuff(x86, s390) * Pagewalker based pagetable working - Kirill * Fix try_to_unmap_one broken with hwpoison - Kirill * Use VM_BUG_ON_PAGE in madvise_free_pmd - Kirill * Fix pgtable-3level.h for arm - Steve * From v9 * Add Acked-by - Rik * Add THP page support - Kirill * Rebased-on v3.16-rc3-mmotm-2014-07-02-15-07 * From v8 * Rebased-on v3.16-rc2-mmotm-2014-06-25-16-44 * From v7 * Rebased-on next-20140613 * From v6 * Remove page from swapcache in syscal time * Move utility functions from memory.c to madvise.c - Johannes * Rename untilify functtions - Johannes * Remove unnecessary checks from vmscan.c - Johannes * Rebased-on v3.15-rc5-mmotm-2014-05-16-16-56 * Drop Reviewe-by because there was some changes since then. * From v5 * Fix PPC problem which don't flush TLB - Rik * Remove unnecessary lazyfree_range stub function - Rik * Rebased on v3.15-rc5 * From v4 * Add Reviewed-by: Zhang Yanfei * Rebase on v3.15-rc1-mmotm-2014-04-15-16-14 * From v3 * Add "how to work part" in description - Zhang * Add page_discardable utility function - Zhang * Clean up * From v2 * Remove forceful dirty marking of swap-readed page - Johannes * Remove deactivation logic of lazyfreed page * Rebased on 3.14 * Remove RFC tag * From v1 * Use custom page table walker for madvise_free - Johannes * Remove PG_lazypage flag - Johannes * Do madvise_dontneed instead of madvise_freein swapless system Minchan Kim (7): [1] mm: support madvise(MADV_FREE) [2] x86: add pmd_[dirty|mkclean] for THP [3] sparc: add pmd_[dirty|mkclean] for THP [4] powerpc: add pmd_[dirty|mkclean] for THP [5] s390: add pmd_[dirty|mkclean] for THP [6] ARM: add pmd_[dirty|mkclean] for THP [7] mm: Don't split THP page when syscall is called arch/arm/include/asm/pgtable-3level.h| 3 + arch/arm64/include/asm/pgtable.h | 2 + arch/powerpc/include/asm/pgtable-ppc64.h | 2 + arch/s390/include/asm/pgtable.h | 12 +++ arch/sparc/include/asm/pgtable_64.h | 16 arch/x86/include/asm/pgtable.h | 10 ++ include/linux/rmap.h | 9 +- include/linux/vm_event_item.h| 1 + include/uapi/asm-generic/mman-common.h | 1 + mm/madvise.c | 153 +++ mm/rmap.c| 41 - mm/vmscan.c | 64 + mm/vmstat.c | 1 + 13 files changed, 295 insertions(+), 20 deletions(-) -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arch/score/include/asm/Kbuild: Add generic "serial.h"
The related error (with allmodconfig under score): CC [M] drivers/staging/speakup/speakup_acntpc.o In file included from drivers/staging/speakup/speakup_acntpc.c:33:0: drivers/staging/speakup/serialio.h:7:24: fatal error: asm/serial.h: No such file or directory #include ^ compilation terminated. make[3]: *** [drivers/staging/speakup/speakup_acntpc.o] Error 1 make[2]: *** [drivers/staging/speakup] Error 2 make[1]: *** [drivers/staging] Error 2 make: *** [drivers] Error 2 Signed-off-by: Chen Gang --- arch/score/include/asm/Kbuild | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/score/include/asm/Kbuild b/arch/score/include/asm/Kbuild index bfb31569..108a225 100644 --- a/arch/score/include/asm/Kbuild +++ b/arch/score/include/asm/Kbuild @@ -10,5 +10,6 @@ generic-y += mcs_spinlock.h generic-y += pci.h generic-y += preempt.h generic-y += scatterlist.h +generic-y += serial.h generic-y += trace_clock.h generic-y += xor.h -- 1.9.2.459.g68773ac -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v2] video: fbdev: sis: init.c: Cleaning up variable that is never used
On Mon, Jul 07, 2014 at 10:23:47PM +0200, Rickard Strandqvist wrote: > Variable ar assigned a value that is never used. > I have also removed all the code that thereby serves no purpose. > > This was found using a static code analysis program called cppcheck > > Signed-off-by: Rickard Strandqvist Thanks. Reviewed-by: Dan Carpenter regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [f2fs-dev][PATCH 1/2] f2fs: check name_len of dir entry to prevent from deadloop
On Mon, Jul 07, 2014 at 09:24:05AM +0800, Chao Yu wrote:
> Hi Jaegeuk,
>
> > -Original Message-
> > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > Sent: Saturday, July 05, 2014 2:43 PM
> > To: Chao Yu
> > Cc: Changman Lee; linux-f2fs-de...@lists.sourceforge.net;
> > linux-fsde...@vger.kernel.org;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [f2fs-dev][PATCH 1/2] f2fs: check name_len of dir entry to
> > prevent from deadloop
> >
> > Hi Chao,
> >
> > On Wed, Jul 02, 2014 at 01:23:47PM +0800, Chao Yu wrote:
> > > We assume that modification of some special application could result in
> > > zeroed
> > > name_len, or it is consciously made by somebody. We will deadloop in
> > > find_in_block when name_len of dir entry is zero.
> >
> > Could you explain this a little bit more?
> > I'm not sure how it can happen.
>
> IMO,
> On one hand, programs like mkfs/fsck/img2simg and f2fs could directly operate
> the raw device, so bugs of these software may be triggered to generate the
> corrupt data such as zeroed name_len.
Well...
If such the programs try to corrupt the f2fs image crucially, the bug should be
fixed inside the programs, not from the workaround through f2fs.
As I mentioned, even though f2fs avoids such the dead loop whatever at that
moment, it will be operating with inconsistent file system status, resulting
in system crash in the near furture finally.
Why should we avoid this specific case only?
It seems that it is a kinda intentional user-made case.
Is it really normal?
> On the other hand, it' could be treated as a potential security problem,
> because
> user could crafted such a malicious image include zeroed name_len for hacking
> purpose.
If user can try to do something like that, why do they write zeroed name_len
only?
To crash the system, they can do everything.
Thanks,
> Once such special image is being mounted, deadloop could be triggered,
> finally will
> result in effecting on linux system's running.
>
> Thanks,
> Yu
>
> > I think the zeroed name_len would cause some problems in f2fs_add_link.
> >
> > Thanks,
> >
> > >
> > > This patch is added for preventing deadloop in above scenario.
> > >
> > > Signed-off-by: Chao Yu
> > > ---
> > > fs/f2fs/dir.c | 10 ++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
> > > index be8c7af..4316ec5 100644
> > > --- a/fs/f2fs/dir.c
> > > +++ b/fs/f2fs/dir.c
> > > @@ -121,6 +121,16 @@ static struct f2fs_dir_entry *find_in_block(struct
> > > page *dentry_page,
> > > }
> > > }
> > >
> > > + /* check name_len to prevent from deadloop here */
> > > + if (unlikely(de->name_len == 0)) {
> > > + struct inode *inode = dentry_page->mapping->host;
> > > +
> > > + f2fs_msg(inode->i_sb, KERN_ERR,
> > > + "zero-length dir entry, ino = %lu, name = %s",
> > > + (unsigned long)inode->i_ino, name->name);
> > > + break;
> > > + }
> > > +
> > > bit_start = bit_pos
> > > + GET_DENTRY_SLOTS(le16_to_cpu(de->name_len));
> > > }
> > > --
> > > 1.7.9.5
> >
> > --
> > Jaegeuk Kim
--
Jaegeuk Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: rtl8192u: fix checkpatch error/warning in r819xU_phy.c
From: sanjeevs1
This is a patch to the r819xU_phy.c file that fixes up all the Error/Warning
found by the checkpatch.pl tool
Signed-off-by: Sanjeev Sharma
---
drivers/staging/rtl8192u/r819xU_phy.c | 76 +--
1 file changed, 36 insertions(+), 40 deletions(-)
diff --git a/drivers/staging/rtl8192u/r819xU_phy.c
b/drivers/staging/rtl8192u/r819xU_phy.c
index 02554c9..1dd1c1e 100644
--- a/drivers/staging/rtl8192u/r819xU_phy.c
+++ b/drivers/staging/rtl8192u/r819xU_phy.c
@@ -101,16 +101,15 @@ void rtl8192_setBBreg(struct net_device *dev, u32
reg_addr, u32 bitmask,
} else {
write_nic_dword(dev, reg_addr, data);
}
- return;
}
/**
* function: This function reads specific bits from BB register
* input: net_device *dev
- *u32 reg_addr //target addr to be readback
- *u32 bitmask//taget bit pos to be readback
- * output:none
- * return:u32 data //the readback register value
+ * u32 reg_addr //target addr to be readback
+ * u32 bitmask//taget bit pos to be readback
+ * output: none
+ * return: u32 data //the readback register value
* notice:
**/
u32 rtl8192_QueryBBReg(struct net_device *dev, u32 reg_addr, u32 bitmask)
@@ -192,7 +191,7 @@ static u32 rtl8192_phy_RFSerialRead(struct net_device *dev,
/* TODO: we should not delay such a long time. Ask for help from SD3 */
- usleep_range(1000, 1000);
+ usleep_range(1000, 2000);
ret = rtl8192_QueryBBReg(dev, pPhyReg->rfLSSIReadBack,
bLSSIReadBackData);
@@ -281,7 +280,6 @@ static void rtl8192_phy_RFSerialWrite(struct net_device
*dev,
priv->RfReg0Value[eRFPath] << 16);
}
}
- return;
}
/**
@@ -332,7 +330,6 @@ void rtl8192_phy_SetRFReg(struct net_device *dev,
RF90_RADIO_PATH_E eRFPath,
rtl8192_phy_RFSerialWrite(dev, eRFPath, reg_addr, data);
}
}
- return;
}
/**
@@ -481,9 +478,9 @@ static void phy_FwRFSerialWrite(struct net_device *dev,
/**
* function: This function reads BB parameters from header file we generate,
*and do register read/write
- * input: net_device *dev
- * output:none
- * return:none
+ * input: net_device *dev
+ * output: none
+ * return: none
* notice:BB parameters may change all the time, so please make
*sure it has been synced with the newest.
*/
@@ -513,7 +510,6 @@ void rtl8192_phy_configmac(struct net_device *dev)
rtl8192_setBBreg(dev, pdwArray[i], pdwArray[i+1],
pdwArray[i+2]);
}
- return;
}
/**
@@ -559,7 +555,6 @@ void rtl8192_phyConfigBB(struct net_device *dev, u8
ConfigType)
rtl819XAGCTAB_Array[i+1]);
}
}
- return;
}
/**
@@ -746,11 +741,11 @@ u8 rtl8192_phy_checkBBAndRF(struct net_device *dev,
HW90_BLOCK_E CheckBlock,
bMask12Bits, WriteData[i]);
/* TODO: we should not delay for such a long time.
Ask SD3 */
- usleep_range(1000, 1000);
+ usleep_range(1000, 2000);
reg = rtl8192_phy_QueryRFReg(dev, eRFPath,
WriteAddr[HW90_BLOCK_RF],
bMask12Bits);
- usleep_range(1000, 1000);
+ usleep_range(1000, 2000);
break;
default:
@@ -846,7 +841,6 @@ static void rtl8192_BB_Config_ParaFile(struct net_device
*dev)
priv->bCckHighPower = (u8)rtl8192_QueryBBReg(dev,
rFPGA0_XA_HSSIParameter2,
0x200);
- return;
}
/**
@@ -864,7 +858,6 @@ void rtl8192_BBConfig(struct net_device *dev)
* implemented, so use file first.
* FIXME: should implement it for hardcode? */
rtl8192_BB_Config_Pa
Re: [PATCH] KVM: x86: Check for nested events if there is an injectable interrupt
Il 08/07/2014 06:30, Bandan Das ha scritto:
With commit b6b8a1451fc40412c57d1 that introduced
vmx_check_nested_events, checks for injectable interrupts happen
at different points in time for L1 and L2 that could potentially
cause a race. The regression occurs because KVM_REQ_EVENT is always
set when nested_run_pending is set even if there's no pending interrupt.
Consequently, there could be a small window when check_nested_events
returns without exiting to L1, but an interrupt comes through soon
after and it incorrectly, gets injected to L2 by inject_pending_event
Fix this by adding a call to check for nested events too when a check
for injectable interrupt returns true
Signed-off-by: Bandan Das
---
arch/x86/kvm/x86.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 73537ec..56327a6 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5907,6 +5907,19 @@ static int inject_pending_event(struct kvm_vcpu *vcpu,
bool req_int_win)
kvm_x86_ops->set_nmi(vcpu);
}
} else if (kvm_cpu_has_injectable_intr(vcpu)) {
+ /*
+* TODO/FIXME: We are calling check_nested_events again
+* here to avoid a race condition. We should really be
+* setting KVM_REQ_EVENT only on certain events
+* and not unconditionally.
+* See https://lkml.org/lkml/2014/7/2/60 for discussion
+* about this proposal and current concerns
+*/
+ if (is_guest_mode(vcpu) && kvm_x86_ops->check_nested_events) {
+ r = kvm_x86_ops->check_nested_events(vcpu, req_int_win);
+ if (r != 0)
+ return r;
+ }
if (kvm_x86_ops->interrupt_allowed(vcpu)) {
kvm_queue_interrupt(vcpu, kvm_cpu_get_interrupt(vcpu),
false);
I think this should be done for NMI as well.
Jan, what do you think? Can you run Jailhouse through this patch?
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sparse: Add CLOG option for saving warning
On Mon, Jul 7, 2014 at 4:22 AM, Sam Ravnborg wrote:
>> > Typical usage:
>> >
>> > make -j8 C=2 CLOG=
>>
> We do not need this kind of special handling of outputs from gcc.
> For sparse you just do a run with C=2 then you have it.
>
> In other words - this looks like overkill for somethign thas is achievable
> with simpler means.
I am aware of the C=2 flag. However, it does not provide consistent result
with "make -jn" flag.
Please consider that the gcc case is different. The kernel source is usually
clean of gcc warnings. If there is an error with gcc, the build process
stops. It is different with sparse. The primary goal of running sparse in
kernel build is to see those warning. Also sparse is a lot noisier than gcc
in the kernel build, so there is a need with logging which is not present
with gcc.
With this patch, here is a normal test procedure for me to see the impact of a
sparse change on kernel build:
$ make -j8 C=2 CLOG=std
# apply sparse change and make sparse
$ make -j8 C=2 CLOG=std-exp
$ find -name ".*.std.sparse" | while read -r file; do diff -du $file
${file/std.sparse/std-exp.
sparse} ; done > /tmp/sparse-diff
Without the CLOG= option, the only way to get similar diff
result is disable "-jn" option. Which make the test process painfully
slow.
I agree if I don't use "make -jn" flags, using C=2 is good enough.
However, what is your suggestion if I do want to use "make -jn" for
sparse checking in the previous mentioned usage case?
Thanks
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] KVM: nVMX: Fix IRQs inject to L2 which belong to L1 since race
Il 08/07/2014 01:38, Wanpeng Li ha scritto: On Mon, Jul 07, 2014 at 03:03:13PM +0200, Paolo Bonzini wrote: Il 07/07/2014 10:46, Wanpeng Li ha scritto: Hi Paolo, Is it ok for you to apply this patch and then more effort should be taken to figure out the other bug which don't have any relationship with the race that this patch fixed? Which patch? Yours or Bandan's? Please wait, a patch which fix the hang will be submitted soon. This is a regression, so I think the right thing to do is to apply Bandan's patch to 3.16 and yours to 3.17. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] checkstack: use $UTS_MACHINE as target architecture
On Tue, Jul 8, 2014 at 2:05 AM, Andrew Morton wrote:
> On Sat, 05 Jul 2014 15:22:38 +0400 Konstantin Khlebnikov
> wrote:
>
>> This fixes command # make checkstack for i386/x86_64.
>> Looks like $UTS_MACHINE is exactly what scripts/checkstack.pl needs.
>>
>> By default $UTS_MACHINE is equal to $ARCH, but some arch/${ARCH}/Makefile
>> overrides it. This patch updates it also in arch/x86/Makefile.um
>>
>> broken in ffee0de ("x86: Default to ARCH=x86 to avoid overriding
>> CONFIG_64BIT")
>
> The changelog doesn't describe the bug which is being fixed. It should
> do so please. If there are any compiler/make error messages then those
> should be included.
>
Oh, ok. checkstalk.pl needs either i386 or x86_64, x86 isn't enough.
$ make checkstack
objdump -d vmlinux $(find . -name '*.ko') | \
perl /home/blind/src/linux-stable/scripts/checkstack.pl x86
wrong or unknown architecture "x86"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Fwd: Fwd: Fwd: shx3_defconfig Fails
From: Guenter Roeck wrote on Tue, Jul 8, 2014 at 1:18 AM Subject: Re: Fwd: Fwd: shx3_defconfig Fails To: Nick Krause , Greg KH Cc: jsl...@suse.cz, "linux-kernel@vger.kernel.org" On 07/07/2014 10:13 PM, Nick Krause wrote: > > -- Forwarded message -- > From: Nick Krause > Date: Tue, Jul 8, 2014 at 1:11 AM > Subject: Fwd: Fwd: shx3_defconfig Fails > To: li...@roeck-us.net, gre...@linuxfoundation.org > Cc: sl...@suse.cz > > > -- Forwarded message -- > From: Nick Krause > Date: Tue, Jul 8, 2014 at 1:07 AM > Subject: Fwd: Fwd: shx3_defconfig Fails > To: li...@roeck-us.ne, Greg KH > Cc: sl...@suse.cz, "sl...@suse.cz" > > > From: Guenter Roeck work Tue, Jul 8, 2014 at 12:50 AM > Subject: Re: Fwd: shx3_defconfig Fails > To: Nick Krause , Greg KH > Cc: jsl...@suse.cz, "linux-kernel@vger.kernel.org" > > > > On 07/07/2014 09:29 PM, Nick Krause wrote: >> >> >> Guenter Roeck work on Tue, Jul 8, 2014 at 12:00 AM >> Subject: Re: shx3_defconfig Fails >> >> On 07/07/2014 08:32 PM, Greg KH wrote: >>> >>> >>> >>> On Mon, Jul 07, 2014 at 11:04:23PM -0400, Nick Krause wrote: Hey Greg and others, The build, shx3_defconfig seems to be failing. >>> >>> >>> >>> >>> In what kernel version? >>> >>> Has it ever worked? >>> >>> Why not ask the maintainer of that arch about it? I doubt many people >>> ever use defconfig files anymore... >>> >> >> Works in mainline for me. And, for the record, I use lots of defconfig files >> (144 or so of them) for my build tests, so there is at least one user :-) >> >> Cheers, >> Guenter >> >> Still fails in the the same way. I am using the latest git tree. >> Cheers Nick >> > >> From your other errors I start wondering if you use dash or some other >> non-bash > > shell and some dash-incompatibility creeped into the kernel build (again). > > Guenter > > Hey Guenter, > I seem to be using bash. Weird , maybe this is just my machine ,perhaps. Sure, but what does /bin/sh point to ? Default on Ubuntu would be dash. Guenter It does point to dash , therefore I should load bash on opening a shell , I guess. This is probably my issue. Thanks Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 V8 0/9] PCI: Add SPEAr13xx PCie support
On Tue, Jul 8, 2014 at 10:54 AM, Mohit KUMAR DCG wrote: > Pls find attached patches to push through your repo. These are rebased over > the top > of 3.16-rc3. git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git spear/pcie-support-v8 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Fwd: Fwd: shx3_defconfig Fails
On 07/07/2014 10:13 PM, Nick Krause wrote: -- Forwarded message -- From: Nick Krause Date: Tue, Jul 8, 2014 at 1:11 AM Subject: Fwd: Fwd: shx3_defconfig Fails To: li...@roeck-us.net, gre...@linuxfoundation.org Cc: sl...@suse.cz -- Forwarded message -- From: Nick Krause Date: Tue, Jul 8, 2014 at 1:07 AM Subject: Fwd: Fwd: shx3_defconfig Fails To: li...@roeck-us.ne, Greg KH Cc: sl...@suse.cz, "sl...@suse.cz" From: Guenter Roeck work Tue, Jul 8, 2014 at 12:50 AM Subject: Re: Fwd: shx3_defconfig Fails To: Nick Krause , Greg KH Cc: jsl...@suse.cz, "linux-kernel@vger.kernel.org" On 07/07/2014 09:29 PM, Nick Krause wrote: Guenter Roeck work on Tue, Jul 8, 2014 at 12:00 AM Subject: Re: shx3_defconfig Fails On 07/07/2014 08:32 PM, Greg KH wrote: On Mon, Jul 07, 2014 at 11:04:23PM -0400, Nick Krause wrote: Hey Greg and others, The build, shx3_defconfig seems to be failing. In what kernel version? Has it ever worked? Why not ask the maintainer of that arch about it? I doubt many people ever use defconfig files anymore... Works in mainline for me. And, for the record, I use lots of defconfig files (144 or so of them) for my build tests, so there is at least one user :-) Cheers, Guenter Still fails in the the same way. I am using the latest git tree. Cheers Nick From your other errors I start wondering if you use dash or some other non-bash shell and some dash-incompatibility creeped into the kernel build (again). Guenter Hey Guenter, I seem to be using bash. Weird , maybe this is just my machine ,perhaps. Sure, but what does /bin/sh point to ? Default on Ubuntu would be dash. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/1] ARM: imx: use PTR_ERR_OR_ZERO
On Tue, Jul 08, 2014 at 09:18:56AM +0530, Sachin Kamat wrote: > Hi Shawn, > > On Mon, Jul 7, 2014 at 11:25 AM, Shawn Guo wrote: > > On Fri, Jul 04, 2014 at 09:03:10PM +0200, Fabian Frederick wrote: > >> replace IS_ERR/PTR_ERR > >> > >> Cc: Shawn Guo > >> Cc: Sascha Hauer > >> Cc: linux-arm-ker...@lists.infradead.org > >> Signed-off-by: Fabian Frederick > > > > Applied, thanks. > > > I had sent a similar series [1] in May which you rejected. Just > curious if something > changed between then and now? The main difference is this is the second attempt from a different person to "clean up" the code. I'm still not fond of the change, but I'm getting tied to tell people about that, so just applied the change, since after all it at least gives some good diffstat. I would prefer Fabian's patch over yours because it's really good enough to have one patch than 5 patches in a series to do the change for IMX platform. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Can I use DEVICE_INT_ATTR() so that probing and removing sysfs enteries happens automatically?
What is the proper way to use the 'DEVICE_(INT|ULONG|BOOL)_ATTR()'
macros with a platform driver? Or, am I best using per attribute pairs
of show/store functions?
If I code my own 'show()' and 'store()' functions and use the
'DEVICE_ATTR()' macros things work happily with an assignment of
'struct attribute_group * attr_groups[];' to the 'struct
device_driver' 'groups' field. i.e.
static struct platform_driver platform = { /* ... */ .driver = {
.groups = attr_groups, /* ... */ }, };
If I use the 'DEVICE_INT_ATTR()' macro (for
'device_(show|store)_int()' utility) the attribute appears in sysfs,
but accesses cause an OOPs: 'device_show_int()' is called via
'drv_attr_show()' with an inappropriate signature.
Whats a correct/corrected approach?
- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Fwd: Fwd: shx3_defconfig Fails
-- Forwarded message -- From: Nick Krause Date: Tue, Jul 8, 2014 at 1:11 AM Subject: Fwd: Fwd: shx3_defconfig Fails To: li...@roeck-us.net, gre...@linuxfoundation.org Cc: sl...@suse.cz -- Forwarded message -- From: Nick Krause Date: Tue, Jul 8, 2014 at 1:07 AM Subject: Fwd: Fwd: shx3_defconfig Fails To: li...@roeck-us.ne, Greg KH Cc: sl...@suse.cz, "sl...@suse.cz" From: Guenter Roeck work Tue, Jul 8, 2014 at 12:50 AM Subject: Re: Fwd: shx3_defconfig Fails To: Nick Krause , Greg KH Cc: jsl...@suse.cz, "linux-kernel@vger.kernel.org" On 07/07/2014 09:29 PM, Nick Krause wrote: > > Guenter Roeck work on Tue, Jul 8, 2014 at 12:00 AM > Subject: Re: shx3_defconfig Fails > > On 07/07/2014 08:32 PM, Greg KH wrote: >> >> >> On Mon, Jul 07, 2014 at 11:04:23PM -0400, Nick Krause wrote: >>> >>> >>> Hey Greg and others, >>> The build, shx3_defconfig seems to be failing. >> >> >> >> In what kernel version? >> >> Has it ever worked? >> >> Why not ask the maintainer of that arch about it? I doubt many people >> ever use defconfig files anymore... >> > > Works in mainline for me. And, for the record, I use lots of defconfig files > (144 or so of them) for my build tests, so there is at least one user :-) > > Cheers, > Guenter > > Still fails in the the same way. I am using the latest git tree. > Cheers Nick > >From your other errors I start wondering if you use dash or some other non-bash shell and some dash-incompatibility creeped into the kernel build (again). Guenter Hey Guenter, I seem to be using bash. Weird , maybe this is just my machine ,perhaps. Cheers Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fwd: Fwd: shx3_defconfig Fails
From: Guenter Roeck work Tue, Jul 8, 2014 at 12:50 AM Subject: Re: Fwd: shx3_defconfig Fails To: Nick Krause , Greg KH Cc: jsl...@suse.cz, "linux-kernel@vger.kernel.org" On 07/07/2014 09:29 PM, Nick Krause wrote: > > Guenter Roeck work on Tue, Jul 8, 2014 at 12:00 AM > Subject: Re: shx3_defconfig Fails > > On 07/07/2014 08:32 PM, Greg KH wrote: >> >> >> On Mon, Jul 07, 2014 at 11:04:23PM -0400, Nick Krause wrote: >>> >>> >>> Hey Greg and others, >>> The build, shx3_defconfig seems to be failing. >> >> >> >> In what kernel version? >> >> Has it ever worked? >> >> Why not ask the maintainer of that arch about it? I doubt many people >> ever use defconfig files anymore... >> > > Works in mainline for me. And, for the record, I use lots of defconfig files > (144 or so of them) for my build tests, so there is at least one user :-) > > Cheers, > Guenter > > Still fails in the the same way. I am using the latest git tree. > Cheers Nick > >From your other errors I start wondering if you use dash or some other non-bash shell and some dash-incompatibility creeped into the kernel build (again). Guenter Hey Guenter, I seem to be using bash. Weird , maybe this is just my machine ,perhaps. Cheers Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/1] ARM: imx: use PTR_ERR_OR_ZERO
On Tue, 8 Jul 2014 09:18:56 +0530 Sachin Kamat wrote: > Hi Shawn, > > On Mon, Jul 7, 2014 at 11:25 AM, Shawn Guo wrote: > > On Fri, Jul 04, 2014 at 09:03:10PM +0200, Fabian Frederick wrote: > >> replace IS_ERR/PTR_ERR > >> > >> Cc: Shawn Guo > >> Cc: Sascha Hauer > >> Cc: linux-arm-ker...@lists.infradead.org > >> Signed-off-by: Fabian Frederick > > > > Applied, thanks. > > > I had sent a similar series [1] in May which you rejected. Just > curious if something > changed between then and now? Hi Sachin, I still don't see anything from you for those files in linux-next lately. If it was already in some other tree, you can remove my patch or update signed-off-by as it seems you made it before me :) Regards, Fabian > > [1] http://patchwork.ozlabs.org/patch/353653/ > > -- > Regards, > Sachin. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
powerpc allyesconfig fix
powerpc:allmodconfig has been failing for some time with the following error. arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org backwards make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 A number of attempts to fix the problem by moving around code have been unsuccessful and resulted in failed builds for some configurations and the discovery of toolchain bugs. Fix the problem by disabling RELOCATABLE for COMPILE_TEST builds instead. While this is less than perfect, it avoids substantial code changes which would otherwise be necessary just to make COMPILE_TEST builds happy and might have undesired side effects. Signed-off-by: Guenter Roeck --- arch/powerpc/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index bd6dd6e..fefe7c8 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -414,7 +414,7 @@ config KEXEC config CRASH_DUMP bool "Build a kdump crash kernel" depends on PPC64 || 6xx || FSL_BOOKE || (44x && !SMP) - select RELOCATABLE if PPC64 || 44x || FSL_BOOKE + select RELOCATABLE if (PPC64 && !COMPILE_TEST) || 44x || FSL_BOOKE help Build a kernel suitable for use as a kdump capture kernel. The same kernel binary can be used as production kernel and dump @@ -1017,6 +1017,7 @@ endmenu if PPC64 config RELOCATABLE bool "Build a relocatable kernel" + depends on !COMPILE_TEST select NONSTATIC_KERNEL help This builds a kernel image that is capable of running anywhere -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fwd: Fwd: Allyesconfig for powerpc still Failing
From: Guenter Roeck on Mon, Jul 7, 2014 at 11:57 PM wrote Subject: Re: Fwd: Allyesconfig for powerpc still Failing To: Nick Krause , "linux-kernel@vger.kernel.org" , "linuxppc-...@lists.ozlabs.org" On 07/07/2014 08:38 PM, Nick Krause wrote: > > On 07/07/2014 07:45 PM, Nick Krause wrote: >> >> >> Today I tested the allyesconfig for powerpc and it seems to be still >> failing according to my tests. >> Below are the error messages I get before the jobs finish and exit >> failing the build. >> Cheers Nick >> arch/powerpc/kernel/exceptions-64s.S: Assembler messages: >> arch/powerpc/kernel/exceptions-64s.S:1331: Error: attempt to move .org >> backwards >> make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 >> make: *** [arch/powerpc/kernel] Error 2 >> make: *** Waiting for unfinished jobs > > > Guenter Roeck wrote on Mon, Jul 7, 2014 at 11:07 PM > I submitted a patch to work around this problem a couple of weeks ago [1]. > Unfortunately, with this patch applied, allyesconfig still fails with > relocation errors, but at least the above message is gone, and > allmodconfig passes. > > Maybe we can convince Ben to accept the patch ... > > Thanks, > Guenter > > --- > [1] https://lkml.org/lkml/2014/6/30/607 > > Hey Guenter, > Would you mind sending me the patch that fixes these errors. > I would like to test it before sending in to Ben. > Cheers Nick > Hi Nick, Just follow the link above, select 'forward', and follow the directions. You'll get the patch per e-mail. Alternative: wget "http://download.gmane.org/gmane.linux.kernel/1736036/1736037"; The patch will be in a file named '1736037'. I copied the list for others, in case the 'how to download a patch' question comes up again. Guenter Guenter, Your patch works for me in building the powerpc allyesconfig. This is one news, I am going to send this patch to Ben. Cheers Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Fwd: shx3_defconfig Fails
On 07/07/2014 09:29 PM, Nick Krause wrote: Guenter Roeck work on Tue, Jul 8, 2014 at 12:00 AM Subject: Re: shx3_defconfig Fails On 07/07/2014 08:32 PM, Greg KH wrote: On Mon, Jul 07, 2014 at 11:04:23PM -0400, Nick Krause wrote: Hey Greg and others, The build, shx3_defconfig seems to be failing. In what kernel version? Has it ever worked? Why not ask the maintainer of that arch about it? I doubt many people ever use defconfig files anymore... Works in mainline for me. And, for the record, I use lots of defconfig files (144 or so of them) for my build tests, so there is at least one user :-) Cheers, Guenter Still fails in the the same way. I am using the latest git tree. Cheers Nick From your other errors I start wondering if you use dash or some other non-bash shell and some dash-incompatibility creeped into the kernel build (again). Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 4 July 2014 09:51, Viresh Kumar wrote: > Yeah, having something like what you suggested from DT is the perfect > solution to get over this. The only reason why I am not touching that here > is to not delay other patches just because of that. > > There are separate threads going on for that and probably somebody > else was trying to push for that. > > That's it, nothing more. I would definitely like to use those bindings instead > of the crazy routines we are trying here, once that is finalized :) Do we have some kind of agreement for this temporary solution? Anyways I will kick the other thread again to resolve the bindings soon. @Stephen: Do you still want find_rate_changer() stuff in this series only and or this can go into 3.17 without anymore changes and lets finalize the bindings Mike suggested and then update this code? -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] [RFC] CMA: clear buffer-head lru before page migration
On Tue, 08 Jul 2014 13:44:04 +0900 Gioh Kim wrote: > 2014-07-08 __ 7:52, Andrew Morton ___ ___: > > On Fri, 04 Jul 2014 17:25:09 +0900 Gioh Kim wrote: > > > >> From: Gioh Kim > >> Date: Fri, 4 Jul 2014 16:53:22 +0900 > >> Subject: [PATCH] [RFC] CMA: clear buffer-head lru before page migration > >> > >> When CMA try to migrate page, some buffer-heads can exist on lru. > >> The bh on lru has non-zero count value so that it cannot be dropped > >> even-if it is not used. We can drop only buffers related to the > >> migrated page, but it can take long time more than dropping all > >> because of searching list. There all buffers in lru are dropped. > >> > >> Signed-off-by: Laura Abbott > >> Signed-off-by: Gioh Kim > >> --- > >> fs/buffer.c | 13 + > >> 1 file changed, 13 insertions(+) > >> > >> diff --git a/fs/buffer.c b/fs/buffer.c > >> index eba6e4f..4f11b7a 100644 > >> --- a/fs/buffer.c > >> +++ b/fs/buffer.c > >> @@ -3233,6 +3233,19 @@ int try_to_free_buffers(struct page *page) > >> if (PageWriteback(page)) > >> return 0; > >> > >> +#ifdef CONFIG_CMA > >> + /* > >> +* When CMA try to migrate page, some buffer-heads can exist on > >> lru. > >> +* The bh on lru has non-zero count value so that it cannot > >> +* be dropped even-if it is not used. > >> +* We can drop only buffers related to the migrated page, > >> +* but it can take long time more than dropping all > >> +* because of searching list. > >> +* There all buffers in lru are dropped first. > >> +*/ > >> + invalidate_bh_lrus(); > >> +#endif > > > > No, this will be tremendously expensive. > > > > What I proposed is that CMA call invalidate_bh_lrus() right at the > > outset. Something along the lines of Please do not top-post your email replies - it makes it very hard to conduct a coherent discussion. > It's my fault. > I'm going to send another patch ASAP. No, not "ASAP". Such a patch will require careful testing on numerous system configurations and workloads. Take however much time it needs to get it right. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Fwd: shx3_defconfig Fails
On 07/07/2014 09:29 PM, Nick Krause wrote: Guenter Roeck work on Tue, Jul 8, 2014 at 12:00 AM Subject: Re: shx3_defconfig Fails On 07/07/2014 08:32 PM, Greg KH wrote: On Mon, Jul 07, 2014 at 11:04:23PM -0400, Nick Krause wrote: Hey Greg and others, The build, shx3_defconfig seems to be failing. In what kernel version? Has it ever worked? Why not ask the maintainer of that arch about it? I doubt many people ever use defconfig files anymore... Works in mainline for me. And, for the record, I use lots of defconfig files (144 or so of them) for my build tests, so there is at least one user :-) Cheers, Guenter Still fails in the the same way. I am using the latest git tree. What exactly is failing for you ? The log you provided shows a bunch of warnings and a final error, but I don't see the actual error in the log. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v10 1/7] mm: support madvise(MADV_FREE)
Hello Zhang, On Tue, Jul 08, 2014 at 11:54:12AM +0800, Zhang Yanfei wrote: > Hi Minchan, > > On 07/07/2014 08:53 AM, Minchan Kim wrote: > > Linux doesn't have an ability to free pages lazy while other OS > > already have been supported that named by madvise(MADV_FREE). > > > > The gain is clear that kernel can discard freed pages rather than > > swapping out or OOM if memory pressure happens. > > > > Without memory pressure, freed pages would be reused by userspace > > without another additional overhead(ex, page fault + allocation > > + zeroing). > > > > How to work is following as. > > > > When madvise syscall is called, VM clears dirty bit of ptes of > > the range. > > This should be updated because the implementation has been changed. > It also remove the page from the swapcache if it is. You're right in current implementation but it's rather one of implementation technique(ie, it could be changed later) but still main main logic from MADV_FREE is tightly coupled with pte dirty bit so I don't feel I added it in description but it would be better to add it as comment. Thanks for the review! > > Thank you for your effort! > > -- > Thanks. > Zhang Yanfei > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org";> em...@kvack.org -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] [RFC] CMA: clear buffer-head lru before page migration
It's my fault.
I'm going to send another patch ASAP.
2014-07-08 오전 7:52, Andrew Morton 쓴 글:
On Fri, 04 Jul 2014 17:25:09 +0900 Gioh Kim wrote:
From: Gioh Kim
Date: Fri, 4 Jul 2014 16:53:22 +0900
Subject: [PATCH] [RFC] CMA: clear buffer-head lru before page migration
When CMA try to migrate page, some buffer-heads can exist on lru.
The bh on lru has non-zero count value so that it cannot be dropped
even-if it is not used. We can drop only buffers related to the
migrated page, but it can take long time more than dropping all
because of searching list. There all buffers in lru are dropped.
Signed-off-by: Laura Abbott
Signed-off-by: Gioh Kim
---
fs/buffer.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/fs/buffer.c b/fs/buffer.c
index eba6e4f..4f11b7a 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -3233,6 +3233,19 @@ int try_to_free_buffers(struct page *page)
if (PageWriteback(page))
return 0;
+#ifdef CONFIG_CMA
+ /*
+* When CMA try to migrate page, some buffer-heads can exist on lru.
+* The bh on lru has non-zero count value so that it cannot
+* be dropped even-if it is not used.
+* We can drop only buffers related to the migrated page,
+* but it can take long time more than dropping all
+* because of searching list.
+* There all buffers in lru are dropped first.
+*/
+ invalidate_bh_lrus();
+#endif
No, this will be tremendously expensive.
What I proposed is that CMA call invalidate_bh_lrus() right at the
outset. Something along the lines of
--- a/mm/page_alloc.c~a
+++ a/mm/page_alloc.c
@@ -6329,6 +6329,14 @@ int alloc_contig_range(unsigned long sta
};
INIT_LIST_HEAD(&cc.migratepages);
+#ifdef CONFIG_CMA
+ /*
+* Comment goes here
+*/
+ if (migratetype == MIGRATE_CMA)
+ invalidate_bh_lrus();
+#endif
+
/*
* What we do here is we mark all pageblocks in range as
* MIGRATE_ISOLATE. Because pageblock and max order pages may
- I'd have thought that it would make sense to do this for huge pages
as well (MIGRATE_MOVABLE) but nobody really seems to know.
- There's a patch floating around ("Allow increasing the buffer-head
per-CPU LRU size") which will double the size of the bh lrus, so this
all becomes more important.
- alloc_contig_range() does lru_add_drain_all() and drain_all_pages()
*after* performing the allocation. I can't work out why this is the
case and of course it is undocumented. If this is indeed not a bug
then probably the invalidate_bh_lrus() should happen in the same
place.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] KVM: nVMX: Fix IRQs inject to L2 which belong to L1 since race
Wanpeng Li writes: ... > > As Jan metioned in http://www.spinics.net/lists/kvm/msg105238.html, "In any > case, > unconditionally setting KVM_REQ_EVENT seems strange and should be changed." > Your > trick still keep the unconditionally setting KVM_REQ_EVENT which is the root > cause > of the race there, anyway, I focus on fix the hang currently and a patch will > be > submitted soon. Right, that's the plan. Once you submit an updated fix, we can always revert this change :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: arcnet: Remove "#define bool int"
From: Rasmus Villemoes Date: Wed, 2 Jul 2014 14:12:01 +0200 > The header file include/linux/arcdevice.h #defines bool to int, if > bool is not already #defined. However, the files which use that header > file seem to rely on that #define (unconditionally) being in effect: > the prototypes for the functions arcrimi_reset, com20020_reset, > com90io_reset, com90xx_reset (whose addresses are assigned to the > hw.reset member of struct arcnet_local) use int explicitly. > > Moreover, that #define is an accident waiting to happen (scenario: > inclusion of arcdevice.h followed by inclusion of some header which > declares function prototypes using bool). Also, #include > must appear before #include (the > compiler wouldn't like "typedef _Bool int"). > > Since none of the files using arcdevice.h declare variables of type > "bool", the patch is actually quite simple, unlike the commit message. > > Signed-off-by: Rasmus Villemoes Applied to net-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] KVM: x86: Check for nested events if there is an injectable interrupt
With commit b6b8a1451fc40412c57d1 that introduced
vmx_check_nested_events, checks for injectable interrupts happen
at different points in time for L1 and L2 that could potentially
cause a race. The regression occurs because KVM_REQ_EVENT is always
set when nested_run_pending is set even if there's no pending interrupt.
Consequently, there could be a small window when check_nested_events
returns without exiting to L1, but an interrupt comes through soon
after and it incorrectly, gets injected to L2 by inject_pending_event
Fix this by adding a call to check for nested events too when a check
for injectable interrupt returns true
Signed-off-by: Bandan Das
---
arch/x86/kvm/x86.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 73537ec..56327a6 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5907,6 +5907,19 @@ static int inject_pending_event(struct kvm_vcpu *vcpu,
bool req_int_win)
kvm_x86_ops->set_nmi(vcpu);
}
} else if (kvm_cpu_has_injectable_intr(vcpu)) {
+ /*
+* TODO/FIXME: We are calling check_nested_events again
+* here to avoid a race condition. We should really be
+* setting KVM_REQ_EVENT only on certain events
+* and not unconditionally.
+* See https://lkml.org/lkml/2014/7/2/60 for discussion
+* about this proposal and current concerns
+*/
+ if (is_guest_mode(vcpu) && kvm_x86_ops->check_nested_events) {
+ r = kvm_x86_ops->check_nested_events(vcpu, req_int_win);
+ if (r != 0)
+ return r;
+ }
if (kvm_x86_ops->interrupt_allowed(vcpu)) {
kvm_queue_interrupt(vcpu, kvm_cpu_get_interrupt(vcpu),
false);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Fwd: shx3_defconfig Fails
Guenter Roeck work on Tue, Jul 8, 2014 at 12:00 AM Subject: Re: shx3_defconfig Fails On 07/07/2014 08:32 PM, Greg KH wrote: > > On Mon, Jul 07, 2014 at 11:04:23PM -0400, Nick Krause wrote: >> >> Hey Greg and others, >> The build, shx3_defconfig seems to be failing. > > > In what kernel version? > > Has it ever worked? > > Why not ask the maintainer of that arch about it? I doubt many people > ever use defconfig files anymore... > Works in mainline for me. And, for the record, I use lots of defconfig files (144 or so of them) for my build tests, so there is at least one user :-) Cheers, Guenter Still fails in the the same way. I am using the latest git tree. Cheers Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 V8 0/9] PCI: Add SPEAr13xx PCie support
On Tue, Jul 8, 2014 at 9:21 AM, Mohit KUMAR DCG wrote: > - These patches are rebased over 3-16-rc3 to go through arm-soc tree. > Somehow we are having 'sync' issue in providing web link for spear public > repository with these patches. > > It will be resolve soon, and I will provide the link. I can push these to some Linaro repo of mine if you want. And you can send a pull request from there then. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 NETDEV_CHANGE notifier usage causing spurious arp flush
From: Loic Prylli
Date: Tue, 1 Jul 2014 21:39:43 -0700
> A bug was introduced in NETDEV_CHANGE notifier sequence causing the
> arp table to be sometimes spuriously cleared (including manual arp
> entries marked permanent), upon network link carrier changes.
>
> The changed argument for the notifier was applied only to a single
> caller of NETDEV_CHANGE, missing among others netdev_state_change().
> So upon net_carrier events induced by the network, which are
> triggering a call to netdev_state_change(), arp_netdev_event() would
> decide whether to clear or not arp cache based on random/junk stack
> values (a kind of read buffer overflow).
>
> Fixes: be9efd365328 ("net: pass changed flags along with NETDEV_CHANGE event")
> Fixes: 6c8b4e3ff81b ("arp: flush arp cache on IFF_NOARP change")
> Signed-off-by: Loic Prylli
Applied, thanks.
We should probably make plain call_netdevice_notifiers() BUG if it is
invoked for NETDEV_CHANGE.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/2] phy: Kconfig: Re-organize Exynos USB 2.0 PHY configs
On Mon, Jun 30, 2014 at 2:26 PM, Sachin Kamat wrote: > Since the USB 2.0 PHYs are required only with EHCI/OHCI USB drivers, > make it depend on them and default to ARCH_EXYNOS as they are meant > for Exynos platforms. Also, make the sub-drivers silent options enabling > them based on the SoC platforms that they are meant to work with. This > will make life easier for end users who do not have any way knowing the > dependencies. > > Signed-off-by: Sachin Kamat > --- > drivers/phy/Kconfig | 35 +++ > 1 file changed, 11 insertions(+), 24 deletions(-) > > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig > index 16a2f067c242..9aab5dfb0adf 100644 > --- a/drivers/phy/Kconfig > +++ b/drivers/phy/Kconfig > @@ -122,43 +122,30 @@ config PHY_SUN4I_USB > > config PHY_SAMSUNG_USB2 > tristate "Samsung USB 2.0 PHY driver" > + depends on USB_EHCI_EXYNOS || USB_OHCI_EXYNOS > select GENERIC_PHY > select MFD_SYSCON > + default ARCH_EXYNOS > help > Enable this to support the Samsung USB 2.0 PHY driver for Samsung > - SoCs. This driver provides the interface for USB 2.0 PHY. Support > for > - particular SoCs has to be enabled in addition to this driver. Number > - and type of supported phys depends on the SoC. > + SoCs. This driver provides the interface for USB 2.0 PHY. Support > + for particular PHYs will be enabled based on the SoC type in > addition > + to this driver. > > config PHY_EXYNOS4210_USB2 > - bool "Support for Exynos 4210" > + bool > depends on PHY_SAMSUNG_USB2 > - depends on CPU_EXYNOS4210 > - help > - Enable USB PHY support for Exynos 4210. This option requires that > - Samsung USB 2.0 PHY driver is enabled and means that support for > this > - particular SoC is compiled in the driver. In case of Exynos 4210 > four > - phys are available - device, host, HSIC0 and HSIC1. > + default CPU_EXYNOS4210 > > config PHY_EXYNOS4X12_USB2 > - bool "Support for Exynos 4x12" > + bool > depends on PHY_SAMSUNG_USB2 > - depends on (SOC_EXYNOS4212 || SOC_EXYNOS4412) > - help > - Enable USB PHY support for Exynos 4x12. This option requires that > - Samsung USB 2.0 PHY driver is enabled and means that support for > this > - particular SoC is compiled in the driver. In case of Exynos 4x12 > four > - phys are available - device, host, HSIC0 and HSIC1. > + default SOC_EXYNOS4212 || SOC_EXYNOS4412 > > config PHY_EXYNOS5250_USB2 > - bool "Support for Exynos 5250" > + bool > depends on PHY_SAMSUNG_USB2 > - depends on SOC_EXYNOS5250 > - help > - Enable USB PHY support for Exynos 5250. This option requires that > - Samsung USB 2.0 PHY driver is enabled and means that support for > this > - particular SoC is compiled in the driver. In case of Exynos 5250 > four > - phys are available - device, host, HSIC0 and HSIC. > + default SOC_EXYNOS5250 || SOC_EXYNOS5420 > > config PHY_EXYNOS5_USBDRD > tristate "Exynos5 SoC series USB DRD PHY driver" > -- > 1.7.9.5 Kishon, Any comments on these patches? -- Regards, Sachin. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fwd: Compile issues with se7206_defconfig
Guenter Roeck work on Tue, Jul 8, 2014 at 12:03 AM Subject: Re: Compile issues with se7206_defconfig To: Nick Krause , "linux-kernel@vger.kernel.org" On 07/07/2014 07:56 PM, Nick Krause wrote: > > There seems to me a build issue with this config. I will paste my logs > for this build below this message. > Cheers Nick > scripts/mod/empty.c:1:0: error: cannot use atomic model soft-imask in user > mode > /* empty file to figure out endianness / word size */ > ^ > make[2]: *** [scripts/mod/empty.o] Error 1 > make[2]: *** Waiting for unfinished jobs > make[1]: *** [scripts/mod] Error 2 > make[1]: *** Waiting for unfinished jobs >CHK include/generated/utsrelease.h >UPD include/generated/utsrelease.h >Generating include/generated/machtypes.h >CC kernel/bounds.s > kernel/bounds.c:1:0: error: cannot use atomic model soft-imask in user mode > /* > ^ > make[1]: *** [kernel/bounds.s] Error 1 > make: *** [prepare0] Error 2 > make: *** Waiting for unfinished jobs > make: *** [scripts] Error 2 What kernel version ? I see a build failure in mainline, but it is different. net/built-in.o: In function `__sk_run_filter': filter.c:(.text+0x3156c): undefined reference to `__fpscr_values' filter.c:(.text+0x31760): undefined reference to `__fpscr_values' filter.c:(.text+0x31c8c): undefined reference to `__fpscr_values' filter.c:(.text+0x31f00): undefined reference to `__fpscr_values' filter.c:(.text+0x323b0): undefined reference to `__fpscr_values' Guenter I am running mainline too. I will retest and see if I get the same results as you. Cheers Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: linux-next: build failure after merge of the iommu tree
On Tue, 2014-07-08 at 14:02 +1000, Stephen Rothwell wrote:
> Hi Joerg,
>
> After merging the iommu tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> arch/powerpc/platforms/built-in.o:(.opd+0x29e8): multiple definition of
> `iommu_device_destroy'
> arch/powerpc/kernel/built-in.o:(.opd+0x5628): first defined here
> arch/powerpc/platforms/built-in.o: In function `.iommu_device_unlink':
> (.text+0x13240): multiple definition of `.iommu_device_unlink'
> arch/powerpc/kernel/built-in.o:(.text+0x2b240): first defined here
> arch/powerpc/platforms/built-in.o: In function `.iommu_device_create':
> (.text+0x13210): multiple definition of `.iommu_device_create'
> arch/powerpc/kernel/built-in.o:(.text+0x2b210): first defined here
> arch/powerpc/platforms/built-in.o: In function `.iommu_device_destroy':
> (.text+0x13220): multiple definition of `.iommu_device_destroy'
> arch/powerpc/kernel/built-in.o:(.text+0x2b220): first defined here
> arch/powerpc/platforms/built-in.o: In function `.iommu_device_link':
> (.text+0x13230): multiple definition of `.iommu_device_link'
> arch/powerpc/kernel/built-in.o:(.text+0x2b230): first defined here
> arch/powerpc/platforms/built-in.o:(.opd+0x2a00): multiple definition of
> `iommu_device_link'
> arch/powerpc/kernel/built-in.o:(.opd+0x5640): first defined here
> arch/powerpc/platforms/built-in.o:(.opd+0x2a18): multiple definition of
> `iommu_device_unlink'
> arch/powerpc/kernel/built-in.o:(.opd+0x5658): first defined here
> arch/powerpc/platforms/built-in.o:(.opd+0x29d0): multiple definition of
> `iommu_device_create'
> arch/powerpc/kernel/built-in.o:(.opd+0x5610): first defined here
>
> Caused by commit c61959ecbbc6 ("iommu: Add sysfs support for IOMMUs").
> CONFIG_IOMMU_API is not set for this build. Forgotten "static
> inline"s :-(
Yep, I already posted a patch for this:
http://lists.linuxfoundation.org/pipermail/iommu/2014-July/009123.html
Sorry for the trouble. Thanks,
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/2] sched: Rewrite per entity runnable load average tracking
Thanks, Peter. On Mon, Jul 07, 2014 at 12:46:46PM +0200, Peter Zijlstra wrote: > > That tg->load_avg cacheline is already red hot glowing, and you've just > increased the amount of updates to it.. That's not going to be pleasant. > Logically, this rewrite updates tg->load_avg as soon as it is changed. But technically, this is not necessary, as it is only needed to be updated when it is used before update_cfs_shares() and update_cfs_rq_h_load(). Yes, I can optimize it. > So here you add the task to the cfs_rq avg when its got migrate in, > however: > > > @@ -4552,17 +4326,9 @@ migrate_task_rq_fair(struct task_struct *p, int > > next_cpu) > > struct sched_entity *se = &p->se; > > struct cfs_rq *cfs_rq = cfs_rq_of(se); > > > > + /* Update task on old CPU, then ready to go (entity must be off the > > queue) */ > > + __update_load_avg(cfs_rq_clock_task(cfs_rq), &se->avg, 0); > > + se->avg.last_update_time = 0; > > > > /* We have migrated, no longer consider this task hot */ > > se->exec_start = 0; > > there you don't remove it first.. > Yes, I missed it. I wonder what I was thinking. Migration is the only reason to track task load average... Yuyang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the iommu tree
Hi Joerg,
After merging the iommu tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/platforms/built-in.o:(.opd+0x29e8): multiple definition of
`iommu_device_destroy'
arch/powerpc/kernel/built-in.o:(.opd+0x5628): first defined here
arch/powerpc/platforms/built-in.o: In function `.iommu_device_unlink':
(.text+0x13240): multiple definition of `.iommu_device_unlink'
arch/powerpc/kernel/built-in.o:(.text+0x2b240): first defined here
arch/powerpc/platforms/built-in.o: In function `.iommu_device_create':
(.text+0x13210): multiple definition of `.iommu_device_create'
arch/powerpc/kernel/built-in.o:(.text+0x2b210): first defined here
arch/powerpc/platforms/built-in.o: In function `.iommu_device_destroy':
(.text+0x13220): multiple definition of `.iommu_device_destroy'
arch/powerpc/kernel/built-in.o:(.text+0x2b220): first defined here
arch/powerpc/platforms/built-in.o: In function `.iommu_device_link':
(.text+0x13230): multiple definition of `.iommu_device_link'
arch/powerpc/kernel/built-in.o:(.text+0x2b230): first defined here
arch/powerpc/platforms/built-in.o:(.opd+0x2a00): multiple definition of
`iommu_device_link'
arch/powerpc/kernel/built-in.o:(.opd+0x5640): first defined here
arch/powerpc/platforms/built-in.o:(.opd+0x2a18): multiple definition of
`iommu_device_unlink'
arch/powerpc/kernel/built-in.o:(.opd+0x5658): first defined here
arch/powerpc/platforms/built-in.o:(.opd+0x29d0): multiple definition of
`iommu_device_create'
arch/powerpc/kernel/built-in.o:(.opd+0x5610): first defined here
Caused by commit c61959ecbbc6 ("iommu: Add sysfs support for IOMMUs").
CONFIG_IOMMU_API is not set for this build. Forgotten "static
inline"s :-(
I have used the iommu tree from next-20140707 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: Compile issues with se7206_defconfig
On 07/07/2014 07:56 PM, Nick Krause wrote: There seems to me a build issue with this config. I will paste my logs for this build below this message. Cheers Nick scripts/mod/empty.c:1:0: error: cannot use atomic model soft-imask in user mode /* empty file to figure out endianness / word size */ ^ make[2]: *** [scripts/mod/empty.o] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [scripts/mod] Error 2 make[1]: *** Waiting for unfinished jobs CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h Generating include/generated/machtypes.h CC kernel/bounds.s kernel/bounds.c:1:0: error: cannot use atomic model soft-imask in user mode /* ^ make[1]: *** [kernel/bounds.s] Error 1 make: *** [prepare0] Error 2 make: *** Waiting for unfinished jobs make: *** [scripts] Error 2 What kernel version ? I see a build failure in mainline, but it is different. net/built-in.o: In function `__sk_run_filter': filter.c:(.text+0x3156c): undefined reference to `__fpscr_values' filter.c:(.text+0x31760): undefined reference to `__fpscr_values' filter.c:(.text+0x31c8c): undefined reference to `__fpscr_values' filter.c:(.text+0x31f00): undefined reference to `__fpscr_values' filter.c:(.text+0x323b0): undefined reference to `__fpscr_values' Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/3] PCI/MSI: Add pci_enable_msi_partial()
On Wed, 2014-07-02 at 14:22 -0600, Bjorn Helgaas wrote: > On Tue, Jun 10, 2014 at 03:10:30PM +0200, Alexander Gordeev wrote: > > There are PCI devices that require a particular value written > > to the Multiple Message Enable (MME) register while aligned on > > power of 2 boundary value of actually used MSI vectors 'nvec' > > is a lesser of that MME value: > > > > roundup_pow_of_two(nvec) < 'Multiple Message Enable' > > > > However the existing pci_enable_msi_block() interface is not > > able to configure such devices, since the value written to the > > MME register is calculated from the number of requested MSIs > > 'nvec': > > > > 'Multiple Message Enable' = roundup_pow_of_two(nvec) > > For MSI, software learns how many vectors a device requests by reading > the Multiple Message Capable (MMC) field. This field is encoded, so a > device can only request 1, 2, 4, 8, etc., vectors. It's impossible > for a device to request 3 vectors; it would have to round up that up > to a power of two and request 4 vectors. > > Software writes similarly encoded values to MME to tell the device how > many vectors have been allocated for its use. For example, it's > impossible to tell the device that it can use 3 vectors; the OS has to > round that up and tell the device it can use 4 vectors. > > So if I understand correctly, the point of this series is to take > advantage of device-specific knowledge, e.g., the device requests 4 > vectors via MMC, but we "know" the device is only capable of using 3. > Moreover, we tell the device via MME that 4 vectors are available, but > we've only actually set up 3 of them. > > This makes me uneasy because we're lying to the device, and the device > is perfectly within spec to use all 4 of those vectors. If anything > changes the number of vectors the device uses (new device revision, > firmware upgrade, etc.), this is liable to break. It also adds more complexity into the already complex MSI API, across all architectures, all so a single Intel chipset can save a couple of MSIs. That seems like the wrong trade off to me. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: shx3_defconfig Fails
On 07/07/2014 08:32 PM, Greg KH wrote: On Mon, Jul 07, 2014 at 11:04:23PM -0400, Nick Krause wrote: Hey Greg and others, The build, shx3_defconfig seems to be failing. In what kernel version? Has it ever worked? Why not ask the maintainer of that arch about it? I doubt many people ever use defconfig files anymore... Works in mainline for me. And, for the record, I use lots of defconfig files (144 or so of them) for my build tests, so there is at least one user :-) Cheers, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Fwd: Allyesconfig for powerpc still Failing
On 07/07/2014 08:38 PM, Nick Krause wrote: On 07/07/2014 07:45 PM, Nick Krause wrote: Today I tested the allyesconfig for powerpc and it seems to be still failing according to my tests. Below are the error messages I get before the jobs finish and exit failing the build. Cheers Nick arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1331: Error: attempt to move .org backwards make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 make: *** Waiting for unfinished jobs Guenter Roeck wrote on Mon, Jul 7, 2014 at 11:07 PM I submitted a patch to work around this problem a couple of weeks ago [1]. Unfortunately, with this patch applied, allyesconfig still fails with relocation errors, but at least the above message is gone, and allmodconfig passes. Maybe we can convince Ben to accept the patch ... Thanks, Guenter --- [1] https://lkml.org/lkml/2014/6/30/607 Hey Guenter, Would you mind sending me the patch that fixes these errors. I would like to test it before sending in to Ben. Cheers Nick Hi Nick, Just follow the link above, select 'forward', and follow the directions. You'll get the patch per e-mail. Alternative: wget "http://download.gmane.org/gmane.linux.kernel/1736036/1736037"; The patch will be in a file named '1736037'. I copied the list for others, in case the 'how to download a patch' question comes up again. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v10 1/7] mm: support madvise(MADV_FREE)
Hi Minchan, On 07/07/2014 08:53 AM, Minchan Kim wrote: > Linux doesn't have an ability to free pages lazy while other OS > already have been supported that named by madvise(MADV_FREE). > > The gain is clear that kernel can discard freed pages rather than > swapping out or OOM if memory pressure happens. > > Without memory pressure, freed pages would be reused by userspace > without another additional overhead(ex, page fault + allocation > + zeroing). > > How to work is following as. > > When madvise syscall is called, VM clears dirty bit of ptes of > the range. This should be updated because the implementation has been changed. It also remove the page from the swapcache if it is. Thank you for your effort! -- Thanks. Zhang Yanfei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: qmi_wwan: Add ID for Telewell TW-LTE 4G v2
From: Bernd Wachter Date: Tue, 01 Jul 2014 22:01:09 +0300 > There's a new version of the Telewell 4G modem working with, but not > recognized by this driver. > > Signed-off-by: Bernd Wachter Applied and queued up for -stable, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 V8 0/9] PCI: Add SPEAr13xx PCie support
Hello Bartlomiej, > -Original Message- > From: Bartlomiej Zolnierkiewicz [mailto:b.zolnier...@samsung.com] > Sent: Monday, July 07, 2014 9:01 PM > To: Pratyush ANAND > Cc: Arnd Bergmann (a...@arndb.de); 'Bjorn Helgaas' > (bhelg...@google.com); Mohit KUMAR DCG; spear-devel; linux- > ker...@vger.kernel.org; devicet...@vger.kernel.org; linux- > p...@vger.kernel.org; Mark Nicholson > Subject: Re: [PATCH V8 0/9] PCI: Add SPEAr13xx PCie support > > > Hi Arnd, > > Any update on status of this patchset? Is it OK for it to go through arm-soc > tree or should it be splitted into separate parts which would go through > pci/phy/arm-soc trees? - These patches are rebased over 3-16-rc3 to go through arm-soc tree. Somehow we are having 'sync' issue in providing web link for spear public repository with these patches. It will be resolve soon, and I will provide the link. > > [ The patchset applies fine to next-20140707 after fixing trivial > reject in drivers/pci/host/Makefile in patch #8. To make it build > the following line from patch #8 needs to be dropped: > > + spin_lock_init(&pp->conf_lock); - yes, I have already considered this while rebasing. Thanks Mohit > ] > > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R&D Institute Poland > Samsung Electronics > > On Thursday, May 22, 2014 05:01:19 PM Pratyush Anand wrote: > > Hi Arnd/Bjorn, > > > > On Mon, May 19, 2014 at 07:55:12PM +0800, Mohit KUMAR wrote: > > > Hello Arnd, > > > > > > > -Original Message- > > > > From: Mohit KUMAR DCG > > > > Sent: Tuesday, April 15, 2014 5:20 PM > > > > To: spear-devel; linux-kernel@vger.kernel.org; > > > > devicet...@vger.kernel.org; linux-...@vger.kernel.org; > > > > linux-arm-ker...@lists.infradead.org > > > > Cc: Mohit KUMAR DCG > > > > Subject: [PATCH V8 0/9] PCI: Add SPEAr13xx PCie support > > > > > > > > Patch# 1 and 2: Improvement and fixes for SPEAr13xx support. > > > > Patch# 3,4 and 6: Add DT bindings for spear1310/40-miphy, misc and > > > > pcie node Patch# 5: Add spear1310/40-miphy driver and support for > > > > spear1310/40 miphy wrapper. > > > > Patch# 7-9: Add SPEAr13xx PCIe driver and dt support. > > > > > > > > These pathes are tested with linux-3.15 tag of arm-soc tree. > > > > Tested with SPEAr1310 evaluation board with: > > > > - INTEL PRO 100/100 EP card > > > > - USB xhci gen2 card > > > > - Above cards connected through LeCROY PTC switch > > > > > > > > Modifications for SATA are tested with SPEAr1340-evb board > > > > > > > > > > I think 3.16 windows is about to close, are you planning to merge this > series? > > > Pls let me know if something pending on our part. > > > > If you could let us know the status of this patch series inclusion. > > > > Regards > > Pratyush > > > > > > > > Regards > > > Mohit > > > > > > > Changes since v7: > > > > - Rebase over for-linus-3.15 tag of arm-soc tree so that complete > > > > patch series can be applied cleanly. > > > > - Incorporated few comments on comment style and superfluous > > > > comments Changes since v6: > > > > - Split miphy driver for SPEAr1310 and SPEAr1340 > > > > - Some cleanup and incorporated other minor comments Changes since > v5: > > > > - Split DT bindings for misc, miphy-40lp and pcie node into > > > > sepearte patches > > > > - Merge config options PCIE_SPEAR13XX and PCI_MSI into defconfig > > > > patch > > > > - Incorporated other minor comments Changes since v4: > > > > - Uses per device function pointers passed from .data field to > > > > the of_device_id instead of of_device_is_compatible. > > > > - Incorporated other minor comments from v4 > > > > > > > > Changes since v3: > > > > - Phy driver renamed to phy-miphy40lp > > > > - ahci phy hook patch used as suggested by Arnd > > > > - Incorporated other minor comments from v3 > > > > > > > > Changes since v2: > > > > - Incorporated comments to move SPEAr13xx PCIe and SATA phy > > > > specific routines to > > > > the phy framework > > > > - Modify ahci driver to include phy hooks > > > > - phy-core driver modifications for subsys_initcall() > > >
Re: [PATCH 1/1] ARM: imx: use PTR_ERR_OR_ZERO
Hi Shawn, On Mon, Jul 7, 2014 at 11:25 AM, Shawn Guo wrote: > On Fri, Jul 04, 2014 at 09:03:10PM +0200, Fabian Frederick wrote: >> replace IS_ERR/PTR_ERR >> >> Cc: Shawn Guo >> Cc: Sascha Hauer >> Cc: linux-arm-ker...@lists.infradead.org >> Signed-off-by: Fabian Frederick > > Applied, thanks. I had sent a similar series [1] in May which you rejected. Just curious if something changed between then and now? [1] http://patchwork.ozlabs.org/patch/353653/ -- Regards, Sachin. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/3] dra7: Add PCIe support
On Sat, Jul 5, 2014 at 11:02 PM, Bjorn Helgaas wrote: > On Wed, Jun 25, 2014 at 11:26:44PM +0530, Kishon Vijay Abraham I wrote: >> [1] is split into separate series in order for individual subsystem >> Maintainers to pick up the patches. This series handles the PCIe >> support for DRA7. >> >> Rebased to 3.16-rc2. >> >> [1] -> https://lkml.org/lkml/2014/5/29/258 >> >> Kishon Vijay Abraham I (3): >> PCI: designware: Configuration space should be specified in 'reg' >> PCI: designware: use untranslated address while programming ATU >> PCI: host: pcie-dra7xx: add support for pcie-dra7xx controller > > Mohit, I see your ack for [1/3], but not for [2/3]; are you OK with that, > too? > > Pratyush, you had some questions about [2/3]; are you happy with that one? OK for me. ~Pratyush -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: shx3_defconfig Fails
On Mon, Jul 07, 2014 at 11:04:23PM -0400, Nick Krause wrote: > Hey Greg and others, > The build, shx3_defconfig seems to be failing. In what kernel version? Has it ever worked? Why not ask the maintainer of that arch about it? I doubt many people ever use defconfig files anymore... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sh -allyesconfig Fails
Hey guys, shallyesconfig seems to still be failing. Below this message are the logs for this failing build. Cheers Nick scripts/kconfig/conf --silentoldconfig Kconfig CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h :1:0: error: cannot use atomic model soft-imask in user mode :1:0: error: cannot use atomic model soft-imask in user mode ./scripts/gcc-version.sh: line 31: printf: #: invalid number ./scripts/gcc-version.sh: line 31: printf: #: invalid number :1:0: error: cannot use atomic model soft-imask in user mode :1:0: error: cannot use atomic model soft-imask in user mode ./scripts/gcc-version.sh: line 31: printf: #: invalid number ./scripts/gcc-version.sh: line 31: printf: #: invalid number /bin/sh: 1: [: 0001: unexpected operator :1:0: error: cannot use atomic model soft-imask in user mode :1:0: error: cannot use atomic model soft-imask in user mode ./scripts/gcc-version.sh: line 31: printf: #: invalid number ./scripts/gcc-version.sh: line 31: printf: #: invalid number /bin/sh: 1: [: 0001: unexpected operator CHK include/generated/utsrelease.h CC scripts/mod/empty.o scripts/mod/empty.c:1:0: error: cannot use atomic model soft-imask in user mode /* empty file to figure out endianness / word size */ ^ make[2]: *** [scripts/mod/empty.o] Error 1 make[1]: *** [scripts/mod] Error 2 make: *** [scripts] Error 2 make: *** Waiting for unfinished jobs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] powerpc: Disable RELOCATABLE for COMPILE_TEST with PPC64
On Mon, 2014-07-07 at 20:03 -0700, Guenter Roeck wrote: > ping ... > > Ben, I know this is not perfect, but on the other side it is simple > and would be easy to backport. With this in place, a complete/clean > fix would not be as urgent. Any chance to get it applied ? Yes, that definitely helps, I'll include it as a band aid. Cheers, Ben. > Nick, this doesn't fix the allyesconfig build - it still fails with > relocation errors. But it does fix the allmodconfig build. > > Thanks, > Guenter > > On 06/30/2014 11:45 AM, Guenter Roeck wrote: > > powerpc:allmodconfig has been failing for some time with the following > > error. > > > > arch/powerpc/kernel/exceptions-64s.S: Assembler messages: > > arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org > > backwards > > make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 > > > > A number of attempts to fix the problem by moving around code have been > > unsuccessful and resulted in failed builds for some configurations and > > the discovery of toolchain bugs. > > > > Fix the problem by disabling RELOCATABLE for COMPILE_TEST builds instead. > > While this is less than perfect, it avoids substantial code changes > > which would otherwise be necessary just to make COMPILE_TEST builds > > happy and might have undesired side effects. > > > > Signed-off-by: Guenter Roeck > > --- > > arch/powerpc/Kconfig | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > > index bd6dd6e..fefe7c8 100644 > > --- a/arch/powerpc/Kconfig > > +++ b/arch/powerpc/Kconfig > > @@ -414,7 +414,7 @@ config KEXEC > > config CRASH_DUMP > > bool "Build a kdump crash kernel" > > depends on PPC64 || 6xx || FSL_BOOKE || (44x && !SMP) > > - select RELOCATABLE if PPC64 || 44x || FSL_BOOKE > > + select RELOCATABLE if (PPC64 && !COMPILE_TEST) || 44x || FSL_BOOKE > > help > > Build a kernel suitable for use as a kdump capture kernel. > > The same kernel binary can be used as production kernel and dump > > @@ -1017,6 +1017,7 @@ endmenu > > if PPC64 > > config RELOCATABLE > > bool "Build a relocatable kernel" > > + depends on !COMPILE_TEST > > select NONSTATIC_KERNEL > > help > > This builds a kernel image that is capable of running anywhere > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sh allmodconfig Fails
Hey Kirill and other maintainers , When building sh allmodconfig I hit errors in a file you guys maintain. I will paste below this log the issues with the build and their respective errors. Cheers Nick :) :1:0: error: cannot use atomic model soft-imask in user mode :1:0: error: cannot use atomic model soft-imask in user mode ./scripts/gcc-version.sh: line 31: printf: #: invalid number ./scripts/gcc-version.sh: line 31: printf: #: invalid number :1:0: error: cannot use atomic model soft-imask in user mode :1:0: error: cannot use atomic model soft-imask in user mode ./scripts/gcc-version.sh: line 31: printf: #: invalid number ./scripts/gcc-version.sh: line 31: printf: #: invalid number /bin/sh: 1: [: 0001: unexpected operator CHK include/generated/utsrelease.h HOSTCC scripts/genksyms/genksyms.o CC scripts/mod/empty.o scripts/mod/empty.c:1:0: error: cannot use atomic model soft-imask in user mode /* empty file to figure out endianness / word size */ ^ make[2]: *** [scripts/mod/empty.o] Error 1 make[1]: *** [scripts/mod] Error 2 make[1]: *** Waiting for unfinished jobs HOSTCC scripts/genksyms/lex.lex.o HOSTCC scripts/genksyms/parse.tab.o make[1]: `include/generated/machtypes.h' is up to date. HOSTLD scripts/genksyms/genksyms CC kernel/bounds.s kernel/bounds.c:1:0: error: cannot use atomic model soft-imask in user mode /* ^ make[1]: *** [kernel/bounds.s] Error 1 make: *** [prepare0] Error 2 make: *** Waiting for unfinished jobs make: *** [scripts] Error 2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 01/12] sched: fix imbalance flag reset
On 06/30/2014 09:35 PM, Vincent Guittot wrote:
> The imbalance flag can stay set whereas there is no imbalance.
>
> Let assume that we have 3 tasks that run on a dual cores /dual cluster system.
> We will have some idle load balance which are triggered during tick.
> Unfortunately, the tick is also used to queue background work so we can reach
> the situation where short work has been queued on a CPU which already runs a
> task. The load balance will detect this imbalance (2 tasks on 1 CPU and an
> idle
> CPU) and will try to pull the waiting task on the idle CPU. The waiting task
> is
> a worker thread that is pinned on a CPU so an imbalance due to pinned task is
> detected and the imbalance flag is set.
> Then, we will not be able to clear the flag because we have at most 1 task on
> each CPU but the imbalance flag will trig to useless active load balance
> between the idle CPU and the busy CPU.
>
> We need to reset of the imbalance flag as soon as we have reached a balanced
> state.
>
> Signed-off-by: Vincent Guittot
> ---
> kernel/sched/fair.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index d3c73122..0c48dff 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -6615,10 +6615,8 @@ more_balance:
> if (sd_parent) {
> int *group_imbalance =
> &sd_parent->groups->sgc->imbalance;
>
> - if ((env.flags & LBF_SOME_PINNED) && env.imbalance > 0)
> {
> + if ((env.flags & LBF_SOME_PINNED) && env.imbalance > 0)
> *group_imbalance = 1;
> - } else if (*group_imbalance)
> - *group_imbalance = 0;
> }
>
> /* All tasks on this runqueue were pinned by CPU affinity */
> @@ -6703,6 +6701,16 @@ more_balance:
> goto out;
>
> out_balanced:
> + /*
> + * We reach balance although we may have faced some affinity
> + * constraints. Clear the imbalance flag if it was set.
> + */
> + if (sd_parent) {
> + int *group_imbalance = &sd_parent->groups->sgc->imbalance;
> + if (*group_imbalance)
> + *group_imbalance = 0;
> + }
> +
> schedstat_inc(sd, lb_balanced[idle]);
>
> sd->nr_balance_failed = 0;
>
I am not convinced that we can clear the imbalance flag here. Lets take
a simple example. Assume at a particular level of sched_domain, there
are two sched_groups with one cpu each. There are 2 tasks on the source
cpu, one of which is running(t1) and the other thread(t2) does not have
the dst_cpu in the tsk_allowed_mask. Now no task can be migrated to the
dst_cpu due to affinity constraints. Note that t2 is *not pinned, it
just cannot run on the dst_cpu*. In this scenario also we reach the
out_balanced tag right? If we set the group_imbalance flag to 0, we are
ruling out the possibility of migrating t2 to any other cpu in a higher
level sched_domain by saying that all is well, there is no imbalance.
This is wrong, isn't it?
My point is that by clearing the imbalance flag in the out_balanced
case, you might be overlooking the fact that the tsk_cpus_allowed mask
of the tasks on the src_cpu may not be able to run on the dst_cpu in
*this* level of sched_domain, but can potentially run on a cpu at any
higher level of sched_domain. By clearing the flag, we are not
encouraging load balance at that level for t2.
Am I missing something?
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Fwd: Allyesconfig for powerpc still Failing
On Mon, Jul 7, 2014 at 11:03 PM wrote Benjamin Herrenschmidt On Mon, 2014-07-07 at 22:45 -0400, Nick Krause wrote: > Today I tested the allyesconfig for powerpc and it seems to be still > failing according to my tests. > Below are the error messages I get before the jobs finish and exit > failing the build. > Cheers Nick > arch/powerpc/kernel/exceptions-64s.S: Assembler messages: > arch/powerpc/kernel/exceptions-64s.S:1331: Error: attempt to move .org > backwards > make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 > make: *** [arch/powerpc/kernel] Error 2 > make: *** Waiting for unfinished jobs Yes, it's a trainwreck and I don't know how to fix it yet ... I tried various more or less invasive approaches and none of them worked properly so far. I need to spend more time on this. Cheers, Ben. If you need any help with these issues please let me known. Cheers Nick :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the regulator tree
Hi all,
After merging the regulator tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/regulator/act8865-regulator.c: In function 'act8865_pmic_probe':
drivers/regulator/act8865-regulator.c:291:13: error: 'act8846_matches'
undeclared (first use in this function)
matches = act8846_matches;
^
drivers/regulator/act8865-regulator.c:291:13: note: each undeclared identifier
is reported only once for each function it appears in
drivers/regulator/act8865-regulator.c:296:13: error: 'act8865_matches'
undeclared (first use in this function)
matches = act8865_matches;
^
drivers/regulator/act8865-regulator.c:311:9: error: too many arguments to
function 'act8865_pdata_from_dt'
ret = act8865_pdata_from_dt(dev, of_node, &pdata_of, matches,
^
drivers/regulator/act8865-regulator.c:239:19: note: declared here
static inline int act8865_pdata_from_dt(struct device *dev,
^
Caused by commit 7160912a8c55 ("regulator: act8865: add support for
act8846").
I have used the regulator tree from next-20140707 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: Allyesconfig for powerpc still Failing
Just hoped this log may help you in your issues with the train wreck. If you need any help with the issues here please let me know. Cheers Nick :) On Mon, Jul 7, 2014 at 11:03 PM, Benjamin Herrenschmidt wrote: > On Mon, 2014-07-07 at 22:45 -0400, Nick Krause wrote: >> Today I tested the allyesconfig for powerpc and it seems to be still >> failing according to my tests. >> Below are the error messages I get before the jobs finish and exit >> failing the build. >> Cheers Nick >> arch/powerpc/kernel/exceptions-64s.S: Assembler messages: >> arch/powerpc/kernel/exceptions-64s.S:1331: Error: attempt to move .org >> backwards >> make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 >> make: *** [arch/powerpc/kernel] Error 2 >> make: *** Waiting for unfinished jobs > > Yes, it's a trainwreck and I don't know how to fix it yet ... I tried > various more or less invasive approaches and none of them worked > properly so far. I need to spend more time on this. > > Cheers, > Ben. > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Allyesconfig for powerpc still Failing
On 07/07/2014 07:45 PM, Nick Krause wrote: Today I tested the allyesconfig for powerpc and it seems to be still failing according to my tests. Below are the error messages I get before the jobs finish and exit failing the build. Cheers Nick arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1331: Error: attempt to move .org backwards make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 make: *** Waiting for unfinished jobs I submitted a patch to work around this problem a couple of weeks ago [1]. Unfortunately, with this patch applied, allyesconfig still fails with relocation errors, but at least the above message is gone, and allmodconfig passes. Maybe we can convince Ben to accept the patch ... Thanks, Guenter --- [1] https://lkml.org/lkml/2014/6/30/607 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Allyesconfig for powerpc still Failing
On Mon, 2014-07-07 at 22:45 -0400, Nick Krause wrote: > Today I tested the allyesconfig for powerpc and it seems to be still > failing according to my tests. > Below are the error messages I get before the jobs finish and exit > failing the build. > Cheers Nick > arch/powerpc/kernel/exceptions-64s.S: Assembler messages: > arch/powerpc/kernel/exceptions-64s.S:1331: Error: attempt to move .org > backwards > make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 > make: *** [arch/powerpc/kernel] Error 2 > make: *** Waiting for unfinished jobs Yes, it's a trainwreck and I don't know how to fix it yet ... I tried various more or less invasive approaches and none of them worked properly so far. I need to spend more time on this. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
shx3_defconfig Fails
Hey Greg and others, The build, shx3_defconfig seems to be failing. Below this message are the logs. Please note they are pretty long as the errors were not in the same subsystems from what I get from reading the trace. Cheers Nick net/ipv4/ping.c: In function ‘ping_err’: net/ipv4/ping.c:547:37: warning: ‘code’ may be used uninitialized in this function [-Wmaybe-uninitialized] harderr = icmp_err_convert[code].fatal; ^ net/ipv4/ping.c:559:11: warning: ‘type’ may be used uninitialized in this function [-Wmaybe-uninitialized] harderr = pingv6_ops.icmpv6_err_convert(type, code, &err); ^ net/ipv4/ping.c:501:48: warning: ‘icmph’ may be used uninitialized in this function [-Wmaybe-uninitialized] if (!ping_supported(family, icmph->type, icmph->code)) ^ CC drivers/scsi/scsi_trace.o CC net/ipv4/gre_offload.o net/ipv4/ping.c: In function ‘ping_common_sendmsg’: net/ipv4/ping.c:464:63: warning: ‘code’ may be used uninitialized in this function [-Wmaybe-uninitialized] return (family == AF_INET && type == ICMP_ECHO && code == 0) || ^ net/ipv4/ping.c:646:11: note: ‘code’ was declared here u8 type, code; ^ net/ipv4/ping.c:678:21: warning: ‘type’ may be used uninitialized in this function [-Wmaybe-uninitialized] if (!ping_supported(family, type, code)) ^ CC net/ipv4/sysctl_net_ipv4.o CC drivers/scsi/sd.o CC net/ipv4/proc.o CC net/ipv4/xfrm4_mode_beet.o CC net/ipv4/xfrm4_mode_transport.o CC net/ipv4/xfrm4_mode_tunnel.o CC net/ipv4/ipconfig.o CC net/ipv4/inet_diag.o CC net/ipv4/tcp_diag.o CC net/ipv4/tcp_cubic.o CC net/ipv4/xfrm4_policy.o CC net/ipv4/xfrm4_state.o LD drivers/scsi/scsi_mod.o LD drivers/scsi/sd_mod.o LD drivers/scsi/built-in.o CC drivers/sh/clk/core.o CC net/ipv4/xfrm4_input.o CC net/ipv4/xfrm4_output.o CC net/ipv4/xfrm4_protocol.o CC drivers/sh/clk/cpg.o drivers/sh/clk/cpg.c: In function ‘r8’: drivers/sh/clk/cpg.c:41:2: warning: passing argument 1 of ‘ioread8’ discards ‘const’ qualifier from pointer target type [enabled by default] return ioread8(addr); ^ In file included from ./arch/sh/include/asm/io.h:20:0, from include/linux/io.h:22, from drivers/sh/clk/cpg.c:14: include/asm-generic/iomap.h:28:21: note: expected ‘void *’ but argument is of type ‘const void *’ extern unsigned int ioread8(void __iomem *); ^ drivers/sh/clk/cpg.c: In function ‘r16’: drivers/sh/clk/cpg.c:46:2: warning: passing argument 1 of ‘ioread16’ discards ‘const’ qualifier from pointer target type [enabled by default] return ioread16(addr); ^ In file included from ./arch/sh/include/asm/io.h:20:0, from include/linux/io.h:22, from drivers/sh/clk/cpg.c:14: include/asm-generic/iomap.h:29:21: note: expected ‘void *’ but argument is of type ‘const void *’ extern unsigned int ioread16(void __iomem *); ^ drivers/sh/clk/cpg.c: In function ‘r32’: drivers/sh/clk/cpg.c:51:2: warning: passing argument 1 of ‘ioread32’ discards ‘const’ qualifier from pointer target type [enabled by default] return ioread32(addr); ^ In file included from ./arch/sh/include/asm/io.h:20:0, from include/linux/io.h:22, from drivers/sh/clk/cpg.c:14: include/asm-generic/iomap.h:31:21: note: expected ‘void *’ but argument is of type ‘const void *’ extern unsigned int ioread32(void __iomem *); ^ CC drivers/sh/intc/access.o LD drivers/soc/built-in.o CC drivers/sh/intc/chip.o LD drivers/sh/clk/built-in.o CC drivers/sh/intc/core.o CC [M] net/ipv4/ip_tunnel.o CC drivers/spi/spi.o CC drivers/sh/intc/handle.o CC drivers/sh/intc/irqdomain.o CC drivers/sh/intc/virq.o CC [M] net/ipv4/tunnel4.o LD drivers/sh/intc/built-in.o CC drivers/sh/pm_runtime.o LD drivers/sh/built-in.o CC drivers/tty/tty_io.o LD net/ipv4/built-in.o CC drivers/tty/n_tty.o make: *** [net] Error 2 make: *** Waiting for unfinished jobs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] powerpc: Disable RELOCATABLE for COMPILE_TEST with PPC64
ping ... Ben, I know this is not perfect, but on the other side it is simple and would be easy to backport. With this in place, a complete/clean fix would not be as urgent. Any chance to get it applied ? Nick, this doesn't fix the allyesconfig build - it still fails with relocation errors. But it does fix the allmodconfig build. Thanks, Guenter On 06/30/2014 11:45 AM, Guenter Roeck wrote: powerpc:allmodconfig has been failing for some time with the following error. arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org backwards make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 A number of attempts to fix the problem by moving around code have been unsuccessful and resulted in failed builds for some configurations and the discovery of toolchain bugs. Fix the problem by disabling RELOCATABLE for COMPILE_TEST builds instead. While this is less than perfect, it avoids substantial code changes which would otherwise be necessary just to make COMPILE_TEST builds happy and might have undesired side effects. Signed-off-by: Guenter Roeck --- arch/powerpc/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index bd6dd6e..fefe7c8 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -414,7 +414,7 @@ config KEXEC config CRASH_DUMP bool "Build a kdump crash kernel" depends on PPC64 || 6xx || FSL_BOOKE || (44x && !SMP) - select RELOCATABLE if PPC64 || 44x || FSL_BOOKE + select RELOCATABLE if (PPC64 && !COMPILE_TEST) || 44x || FSL_BOOKE help Build a kernel suitable for use as a kdump capture kernel. The same kernel binary can be used as production kernel and dump @@ -1017,6 +1017,7 @@ endmenu if PPC64 config RELOCATABLE bool "Build a relocatable kernel" + depends on !COMPILE_TEST select NONSTATIC_KERNEL help This builds a kernel image that is capable of running anywhere -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420
On 07/08/2014 05:04 AM, Kukjin Kim wrote: > On 07/01/14 20:59, Tushar Behera wrote: >> On 06/27/2014 08:18 PM, Kevin Hilman wrote: >>> On Fri, Jun 27, 2014 at 7:18 AM, Kevin Hilman >>> wrote: On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera wrote: > Would you please provide me the environment setting of your u-boot? > U-boot environment on my board has been over-written, I would like to > set it same as yours and try to reproduce the issue at my end. With > only > 'sound init', I don't seem to hit this issue anymore. Attached is a full boot log using v3.16-rc2 with my patch adding CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch. In the boot log, you'll see the output of 'printenv' inside u-boot where the environment is dumped. >>> >>> Oops, I sent you a boot log for the octa board. Here's the one for >>> peach-pi with the same kernel (built with upstream exynos_defconfig) >>> >>> Kevin >>> >> >> The u-boot version is a little different on my Peach-Pi as compared to >> the market release version. Not sure if that is making any difference. >> >> Peach # version >> >> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach >> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66) >> 4.8.x-google 20130905 (prerelease) >> GNU ld (binutils-2.22_cos_gg_2) 2.22 >> > > Note that I've applied this only from this series so I'm not sure how > much the problem can be solved...any updates for 1/3 and 3/3? > > - Kukjin Thanks for applying 2/3. I am working on 1/3 to see if we are following the right approach to fix Kevin's issue (unfortunately, I am not hitting the bug on my board ATM). 3/3 has already been merged through a different patchset. -- Tushar Behera -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Compile issues with se7206_defconfig
There seems to me a build issue with this config. I will paste my logs for this build below this message. Cheers Nick scripts/mod/empty.c:1:0: error: cannot use atomic model soft-imask in user mode /* empty file to figure out endianness / word size */ ^ make[2]: *** [scripts/mod/empty.o] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [scripts/mod] Error 2 make[1]: *** Waiting for unfinished jobs CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h Generating include/generated/machtypes.h CC kernel/bounds.s kernel/bounds.c:1:0: error: cannot use atomic model soft-imask in user mode /* ^ make[1]: *** [kernel/bounds.s] Error 1 make: *** [prepare0] Error 2 make: *** Waiting for unfinished jobs make: *** [scripts] Error 2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: linux-next: build failure after merge of the net tree
From: Stephen Rothwell
Date: Fri, 4 Jul 2014 11:39:07 +1000
> After merging the net tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: "phy_resume" [drivers/net/ethernet/stmicro/stmmac/stmmac.ko] undefined!
>
> Caused by commit 0acf16768740 ("net: stmmac: add platform init/exit for
> Altera's ARM socfpga").
>
> I reverted that commit for today.
Vince you haven't made any effort to fix this build failure, so I am reverting
your changes.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console
Hi Daniel,
The patch below also works. You can use my Tested By for it.
Thanks
Ed Tomlinson
PS. I _really_ need to get a serial console working on my i7 box.
On Monday 07 July 2014 14:26:54 Daniel Vetter wrote:
> On Mon, Jul 07, 2014 at 06:45:49AM -0400, Ed Tomlinson wrote:
> > Daniel,
> >
> > I am not quite sure I understand what you want me to test?
> > Do you want me to try it without:
> >
> > > > + if (ret == 0) {
> > > > + ret = do_unregister_con_driver(&vga_con);
>
> Below the diff of what I mean.
> -Daniel
>
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 5e583a1838f8..bd8517151479 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1466,12 +1466,13 @@ static int i915_kick_out_vgacon(struct
> drm_i915_private *dev_priv)
> #else
> static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> {
> - int ret;
> + int ret = 0;
>
> DRM_INFO("Replacing VGA console driver\n");
>
> console_lock();
> - ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
> + if (con_is_bound(&vga_con))
> + ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1,
> 1);
> if (ret == 0) {
> ret = do_unregister_con_driver(&vga_con);
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] modules: Fix build error in moduleloader.h
(2014/07/08 8:40), Rusty Russell wrote:
> Steven Rostedt writes:
>> Fengguang Wu's build bot detected that if moduleloader.h is included in
>> a C file (used by ftrace and kprobes to access module_alloc() when
>> available), that it can fail to build if CONFIG_MODULES and
>> CONFIG_MODULES_USE_ELF_REL is not defined.
>>
>> This is because there's a printk() that dereferences struct module to
>> print the name of the module. But as struct module does not exist when
>> CONFIG_MODULES is not defined we get this error:
>
> First, we have module_name() for exactly this.
>
> Second, there are two places like this: you hit
> CONFIG_MODULES_USE_ELF_REL and not CONFIG_MODULES_USE_ELF_RELA.
>
> (We could uninline them, and put them in module.c, but I think having
> them in the header is nice and self-documenting.)
>
> So does this work for you?
>
> Thanks,
> Rusty.
> PS. Masami Hiramatsu, your review should have caught the second case,
> at least :(
Oops, sorry, I missed the second one ... and this version seems good to me.
Thank you,
>
> Subject: modules: Fix build error in moduleloader.h
>
> Fengguang Wu's build bot detected that if moduleloader.h is included in
> a C file (used by ftrace and kprobes to access module_alloc() when
> available), that it can fail to build if CONFIG_MODULES and
> CONFIG_MODULES_USE_ELF_REL is not defined.
>
> This is because there's a printk() that dereferences struct module to
> print the name of the module. But as struct module does not exist when
> CONFIG_MODULES is not defined we get this error:
>
>include/linux/moduleloader.h: In function 'apply_relocate':
>>> include/linux/moduleloader.h:48:63: error: dereferencing pointer to
>>> incomplete type
> printk(KERN_ERR "module %s: REL relocation unsupported\n", me->name);
> ^
> Reported-by: kbuild test robot
> Based-on-the-true-story-by: Steven Rostedt
> Signed-off-by: Rusty Russell
>
> diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h
> index 560ca53a75fa..7eeb9bbfb816 100644
> --- a/include/linux/moduleloader.h
> +++ b/include/linux/moduleloader.h
> @@ -45,7 +45,8 @@ static inline int apply_relocate(Elf_Shdr *sechdrs,
>unsigned int relsec,
>struct module *me)
> {
> - printk(KERN_ERR "module %s: REL relocation unsupported\n", me->name);
> + printk(KERN_ERR "module %s: REL relocation unsupported\n",
> +module_name(me));
> return -ENOEXEC;
> }
> #endif
> @@ -67,7 +68,8 @@ static inline int apply_relocate_add(Elf_Shdr *sechdrs,
>unsigned int relsec,
>struct module *me)
> {
> - printk(KERN_ERR "module %s: REL relocation unsupported\n", me->name);
> + printk(KERN_ERR "module %s: REL relocation unsupported\n",
> +module_name(me));
> return -ENOEXEC;
> }
> #endif
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sched/rt: overrun could happen in start_hrtick_dl
On 2014/7/8 10:40, Li Zefan wrote: On 2014/7/8 9:10, xiaofeng.yan wrote: On 2014/7/7 16:41, Peter Zijlstra wrote: On Fri, Jul 04, 2014 at 12:02:21PM +, xiaofeng.yan wrote: It could be wrong for the precision of runtime and deadline when the precision is within microsecond level. For example: Task runtime deadline period P1 200us 500us 500us This case need enbale HRTICK feature by the next command PC#echo "HRTICK" > /sys/kernel/debug/sched_features PC#./schedtool -E -t 20:50 -e ./test& PC#trace-cmd record -e sched_switch Are you actually using HRTICK ? yes, If HRTICK is close , then all of runtime and deadline will be wrong. I think what peter meant is, do you use HRTICK in products or just use it for testing/experiment? Thanks for your timely comments. In fact, We use HRTICK feature in product. We need microsecond level precision. Thanks Yan . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fwd: Compiler Tests
-- Forwarded message -- From: Nick Krause Date: Mon, Jul 7, 2014 at 10:13 PM Subject: Fwd: Compiler Tests To: Levente Kurusa Cc: "linux-kernel@vger.kernel.org" -- Forwarded message -- From: Nick Krause Date: Mon, Jul 7, 2014 at 6:45 PM Subject: Fwd: Compiler Tests To: lkur...@redhat.com Cc: "linux-kernel@vger.kernel.org" On Mon, Jul 7, 2014 at 4:31 PM Levente Kurusa wrote Subject: Re: Compiler Tests To: Nick Krause Hi, 2014-07-07 22:05 GMT+02:00 Nick Krause : > [...] > um-i386: No compiler UML should be able to be built without anything specific. Try this: $ make mrproper $ make ARCH=um mrproper $ make ARCH=um defconfig $ make ARCH=um ... and then it should be built. (Also, seeing from your other posts on the list, please avoid topposting...) Thanks, Levente Kurusa Hey Levente, Thanks for the information on um i386 build. I will build it later today to see if it now builds. Cheers Nick Hey Levente, um-i386 seems to build now. Overall excluding rand configs we now have as of updating my branch , 9 tests fail as I am excluding xtensa due to issues with my binutils perhaps. Cheers Nick Sorry again about another message but s390-allnoconfig seems to build now which is great news. :) Cheers Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] SCHED: allow wait_on_bit_action functions to support a timeout.
It is currently not possible for various wait_on_bit functions to
implement a timeout.
While the "action" function that is called to do the waiting could
certainly use schedule_timeout(), there is no way to carry forward the
remaining timeout after a false wake-up.
As false-wakeups a clearly possible at least due to possible
hash collisions in bit_waitqueue(), this is a real problem.
The 'action' function is currently passed a pointer to the word
containing the bit being waited on. No current action functions use
this pointer. So changing it to something else will be a little noisy
but will have no immediate effect.
This patch changes the 'action' function to take a pointer to the
"struct wait_bit_key", which contains a pointer to the word
containing the bit so nothing is really lost.
It also adds a 'private' field to "struct wait_bit_key", which is
initialized to zero.
An action function can now implement a timeout with something like
static int timed_out_waiter(struct wait_bit_key *key)
{
unsigned long waited;
if (key->private == 0) {
key->private = jiffies;
if (key->private == 0)
key->private -= 1;
}
waited = jiffies - key->private;
if (waited > 10 * HZ)
return -EAGAIN;
schedule_timeout(waited - 10 * HZ);
return 0;
}
If any other need for context in a waiter were found it would be easy
to use ->private for some other purpose, or even extend "struct
wait_bit_key".
My particular need is to support timeouts in nfs_release_page() to
avoid deadlocks with loopback mounted NFS.
While wait_on_bit_timeout() would be a cleaner interface, it will not
meet my need. I need the timeout to be sensitive to the state of
the connection with the server, which could change. So I need to
use an 'action' interface.
Signed-off-by: NeilBrown
---
fs/cifs/inode.c |2 +-
fs/nfs/inode.c |2 +-
fs/nfs/internal.h|2 +-
fs/nfs/pagelist.c|2 +-
include/linux/sunrpc/sched.h |2 +-
include/linux/wait.h | 18 ++
kernel/sched/wait.c | 16
net/sunrpc/sched.c |4 ++--
8 files changed, 25 insertions(+), 23 deletions(-)
diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index 213c4580b4e3..41de3935caa0 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -1780,7 +1780,7 @@ cifs_invalidate_mapping(struct inode *inode)
* @word: long word containing the bit lock
*/
static int
-cifs_wait_bit_killable(void *word)
+cifs_wait_bit_killable(struct wait_bit_key *key)
{
if (fatal_signal_pending(current))
return -ERESTARTSYS;
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index b7b710e7d08e..abd37a380535 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -75,7 +75,7 @@ nfs_fattr_to_ino_t(struct nfs_fattr *fattr)
* nfs_wait_bit_killable - helper for functions that are sleeping on bit locks
* @word: long word containing the bit lock
*/
-int nfs_wait_bit_killable(void *word)
+int nfs_wait_bit_killable(struct wait_bit_key *key)
{
if (fatal_signal_pending(current))
return -ERESTARTSYS;
diff --git a/fs/nfs/internal.h b/fs/nfs/internal.h
index 82ddbf46660e..e0193d63630c 100644
--- a/fs/nfs/internal.h
+++ b/fs/nfs/internal.h
@@ -347,7 +347,7 @@ extern int nfs_drop_inode(struct inode *);
extern void nfs_clear_inode(struct inode *);
extern void nfs_evict_inode(struct inode *);
void nfs_zap_acl_cache(struct inode *inode);
-extern int nfs_wait_bit_killable(void *word);
+extern int nfs_wait_bit_killable(struct wait_bit_key *key);
/* super.c */
extern const struct super_operations nfs_sops;
diff --git a/fs/nfs/pagelist.c b/fs/nfs/pagelist.c
index 6104d3500b49..745a612dbe22 100644
--- a/fs/nfs/pagelist.c
+++ b/fs/nfs/pagelist.c
@@ -117,7 +117,7 @@ __nfs_iocounter_wait(struct nfs_io_counter *c)
set_bit(NFS_IO_INPROGRESS, &c->flags);
if (atomic_read(&c->io_count) == 0)
break;
- ret = nfs_wait_bit_killable(&c->flags);
+ ret = nfs_wait_bit_killable(&q.key);
} while (atomic_read(&c->io_count) != 0);
finish_wait(wq, &q.wait);
return ret;
diff --git a/include/linux/sunrpc/sched.h b/include/linux/sunrpc/sched.h
index ad7dbe2cfecd..1a8959944c5f 100644
--- a/include/linux/sunrpc/sched.h
+++ b/include/linux/sunrpc/sched.h
@@ -236,7 +236,7 @@ void * rpc_malloc(struct rpc_task *, size_t);
void rpc_free(void *);
intrpciod_up(void);
void rpciod_down(void);
-int__rpc_wait_for_completion_task(struct rpc_task *task, int
(*)(void *));
+int__rpc_wait_for_completion_task(struct rpc_task *task,
wait_bit_action_f *);
#ifdef RPC_DEBUG
struct net;
void rpc_show_tasks(struct net *);
diff --git a/include/linux/wait.h b/include/linux/wait.h
index 73960ff09e56..6fb1
[PATCH 1/2] SCHED: remove proliferation of wait_on_bit action functions.
The current "wait_on_bit" interface requires an 'action' function
to be provided which does the actual waiting.
There are over 20 such functions, many of them identical.
Most cases can be satisfied by one of just two functions, one
which uses io_schedule() and one which just uses schedule().
So:
Rename wait_on_bit andwait_on_bit_lock to
wait_on_bit_action and wait_on_bit_lock_action
to make it explicit that they need an action function.
Introduce new wait_on_bit{,_lock} and wait_on_bit{,_lock}_io
which are *not* given an action function but implicitly use
a standard one.
The decision to error-out if a signal is pending is now made
based on the 'mode' argument rather than being encoded in the action
function.
All instances of the old wait_on_bit and wait_on_bit_lock which
can use the new version have been changed accordingly and their
action functions have been discarded.
wait_on_bit{_lock} does not return any specific error code in the
event of a signal so the caller must check for non-zero and
interpolate their own error code as appropriate.
The wait_on_bit() call in __fscache_wait_on_invalidate() was ambiguous
as it specified TASK_UNINTERRUPTIBLE but used
fscache_wait_bit_interruptible as an action function.
David Howells confirms this should be uniformly "uninterruptible"
The main remaining user of wait_on_bit{,_lock}_action is NFS which
needs to use a freezer-aware schedule() call.
A comment in fs/gfs2/glock.c notes that having multiple 'action'
functions is useful as they display differently in the 'wchan' field
of 'ps'. (and /proc/$PID/wchan).
As the new bit_wait{,_io} functions are tagged "__sched", they will
not show up at all, but something higher in the stack. So the
distinction will still be visible, only with different function names
(gds2_glock_wait versus gfs2_glock_dq_wait in the gfs2/glock.c case).
Since first version of this patch (against 3.15) two new action
functions appeared, on in NFS and one in CIFS. CIFS also now uses
an action function that makes the same freezer aware schedule call
as NFS.
Signed-off-by: NeilBrown
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Acked-by: David Howells (fscache, keys)
Acked-by: Steven Whitehouse (gfs2)
---
Documentation/filesystems/caching/operations.txt |2
drivers/md/dm-bufio.c| 41 +++-
drivers/md/dm-snap.c | 10 --
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 12 --
fs/btrfs/extent_io.c | 10 --
fs/buffer.c | 11 --
fs/cifs/connect.c| 10 --
fs/cifs/file.c |9 --
fs/cifs/inode.c |4 -
fs/cifs/misc.c |2
fs/fs-writeback.c|3 -
fs/fscache/cookie.c |7 +
fs/fscache/internal.h|2
fs/fscache/main.c| 18 ---
fs/fscache/page.c|4 -
fs/gfs2/glock.c | 25 -
fs/gfs2/lock_dlm.c |8 --
fs/gfs2/ops_fstype.c | 11 --
fs/gfs2/recovery.c |8 --
fs/gfs2/super.c |8 --
fs/inode.c |7 -
fs/jbd2/transaction.c| 10 --
fs/nfs/file.c|4 -
fs/nfs/filelayout/filelayoutdev.c|4 -
fs/nfs/inode.c |4 -
fs/nfs/nfs4state.c |4 -
fs/nfs/pagelist.c| 12 --
fs/nfs/pnfs.c|2
fs/nfs/write.c |4 -
include/linux/wait.h | 115 +-
include/linux/writeback.h|3 -
kernel/ptrace.c |8 --
kernel/sched/wait.c | 18 +++
mm/filemap.c | 20 +---
mm/ksm.c |8 --
net/bluetooth/hci_core.c |8 --
security/keys/gc.c | 11 --
security/keys/request_key.c | 23
38 files changed, 195 insertions(+), 275 deletions(-)
diff --git a/Documentation/filesystems/caching/operations.txt
b/Documentation/filesystems/caching/operations.txt
index bee2a5f93d60..a1c052cbba35 100644
--- a/Documentation/filesystems/caching/operations.txt
+++ b/Documentation/filesystems/caching/operations.txt
@@ -90,7 +90,7 @@ operations:
to be cleared before proceeding:
wait_on_bit(&op->flags, FSCACHE_OP_WAITING,
-
[PATCH 0/2] Improve wait_on_bit interface.
Hi Linus (hoping to get through your spam filter :-) I wonder if you would consider applying these patches directly? I originally sent them to Peter Zijlstra who was happy with them and they went into "tip" for a while http://lkml.iu.edu/hypermail/linux/kernel/1405.2/01678.html however other code (nfs and cifs) added new users of the old wait_on_bit interface causing conflicts, so Ingo had to remove them. At that time I suggested: > How about you drop my patch for now, we wait for -rc1 to come out, then I > submit a new version against -rc1 and we get that into -rc2. > That should minimise such conflicts. > > Does that work for you? and Ingo replied > Sure, that sounds like a good approach, if Linus doesn't object. > which I took to mean that I could forward revised patches though the 'tip' tree at that time. I did resend after rc2 (missed rc1 - on leave) and have heard nothing from Ingo since despite a ping. So maybe he meant I should submit them directly to you. I would really like at least the first of these to go in before 3.16 else other people could add calls using the old interface and cause the same problems again. Having both of them go in would make me very happy as I could then submit the change to NFS which needs the new wait_on_bit() functionality to device loop-back NFS deadlocks. Thanks a lot, NeilBrown --- NeilBrown (2): SCHED: remove proliferation of wait_on_bit action functions. SCHED: allow wait_on_bit_action functions to support a timeout. Documentation/filesystems/caching/operations.txt |2 drivers/md/dm-bufio.c| 41 ++- drivers/md/dm-snap.c | 10 -- drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 12 -- fs/btrfs/extent_io.c | 10 -- fs/buffer.c | 11 -- fs/cifs/connect.c| 10 -- fs/cifs/file.c |9 -- fs/cifs/inode.c |6 + fs/cifs/misc.c |2 fs/fs-writeback.c|3 - fs/fscache/cookie.c |7 + fs/fscache/internal.h|2 fs/fscache/main.c| 18 --- fs/fscache/page.c|4 - fs/gfs2/glock.c | 25 fs/gfs2/lock_dlm.c |8 - fs/gfs2/ops_fstype.c | 11 -- fs/gfs2/recovery.c |8 - fs/gfs2/super.c |8 - fs/inode.c |7 - fs/jbd2/transaction.c| 10 -- fs/nfs/file.c|4 - fs/nfs/filelayout/filelayoutdev.c|4 - fs/nfs/inode.c |6 + fs/nfs/internal.h|2 fs/nfs/nfs4state.c |4 - fs/nfs/pagelist.c| 14 +- fs/nfs/pnfs.c|2 fs/nfs/write.c |4 - include/linux/sunrpc/sched.h |2 include/linux/wait.h | 125 +- include/linux/writeback.h|3 - kernel/ptrace.c |8 - kernel/sched/wait.c | 30 - mm/filemap.c | 20 +--- mm/ksm.c |8 - net/bluetooth/hci_core.c |8 - net/sunrpc/sched.c |4 - security/keys/gc.c | 11 -- security/keys/request_key.c | 23 41 files changed, 214 insertions(+), 292 deletions(-) -- Signature -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Allyesconfig for powerpc still Failing
Today I tested the allyesconfig for powerpc and it seems to be still failing according to my tests. Below are the error messages I get before the jobs finish and exit failing the build. Cheers Nick arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1331: Error: attempt to move .org backwards make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 make: *** Waiting for unfinished jobs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sched/rt: overrun could happen in start_hrtick_dl
On 2014/7/8 9:10, xiaofeng.yan wrote: > On 2014/7/7 16:41, Peter Zijlstra wrote: >> On Fri, Jul 04, 2014 at 12:02:21PM +, xiaofeng.yan wrote: >>> It could be wrong for the precision of runtime and deadline >>> when the precision is within microsecond level. For example: >>> Task runtime deadline period >>> P1 200us 500us 500us >>> >>> This case need enbale HRTICK feature by the next command >>> PC#echo "HRTICK" > /sys/kernel/debug/sched_features >>> PC#./schedtool -E -t 20:50 -e ./test& >>> PC#trace-cmd record -e sched_switch >> Are you actually using HRTICK ? > yes, If HRTICK is close , then all of runtime and deadline will be wrong. I think what peter meant is, do you use HRTICK in products or just use it for testing/experiment? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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-next v1 2/2] netpoll: avoid reference leaks
From: David Decotigny Date: Mon, 30 Jun 2014 16:50:10 -0700 > This ensures that the ndo_netpoll_cleanup callback is called for every > device that provides one. Otherwise there is a risk of reference leak > with bonding for example, which depends on this callback to cleanup > the slaves' references to netpoll info. > > Tested: > see patch "netpoll: fix use after free" > > Signed-off-by: David Decotigny I definitely don't understand this. Why would we call the cleanup function of an object before it's reference count hits zero? It is exactly the act of reaching a zero refcount which should trigger invoking the cleanup callback. If a refcount is being released in another location without checking if it hits zero and invoking the cleanup if so, _THAT_ is the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
