Re: [PATCH v3 1/2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend
On 17 July 2014 01:26, Saravana Kannan wrote: > No it's not. All the cpu*/ directories for all possible CPUs will be there > whether a CPU is online/offline. Which is why I also weed out impossible > CPUs, but you said the driver shouldn't be passing impossible CPUs anyway. > I'm just picking one directory to put the real cpufreq directory under. So, > the code as-is is definitely not broken. I may be wrong, and that's why I checked it with Srivatsa. He is quite familiar with hotplug code. Let me show the example again, its a bit tricky. I agree with you that sysfs nodes for CPUs stay as is with offline events, but we aren't talking about that here. On boot when we are trying to bring CPUs online, some of them may fail to come. And in that case, as confirmed by Srivatsa, there are no sysfs directories. This doesn't happen normally and is a very corner case. Still think we are wrong? > Sure, I can pick the first cpu that comes online to decide where to put the > real sysfs cpufreq directory, but then I have to keep track of that in a > separate field when it's time to remove it when the cpufreq driver is > unregistered. It works this way right now and I don't think we maintain any separate field here. Subsys-interface takes care of the order in which CPUs are added/ removed. And we don't have to handle that here. Just fix policy->cpu at first cpufreq_add_dev(). > And no, we > shouldn't be moving sysfs directory to stay with only an online directory. > That's the thing this patch is trying to simplify. Ahh, I really missed it in reviews. So, that's why you are looking at first cpu of related_cpus.. Hmm, so it is quite possible that we would end up in a case where policy->cpu wouldn't have sysfs directory created for it. Not sure if that might cause some hickups. @Srivatsa: ?? > So, I think using the first cpu in related CPUs will always work. If there's > any disagreement, I think it's purely a personal preference over adding > another field vs calling cpumask_first() That's what the problem with this patch was, just too big to miss important things :) I now understood why you had these extra cpumask_first() calls. But having said that, I still don't see a need to change the current behavior. The important point is kobject and links are added just once, no movement. And so, I would still like to add it to policy->cpu, i.e. the cpu which comes first. And this happens only once while we register a driver, so no side effects probably. Not every platform is going through hotplug/suspend/resume and keeping policy->cpu and sysfs node aligned atleast for them might not be that bad. Though it will work for any cpu. -- 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 1/2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend
On 17 July 2014 01:26, Saravana Kannan wrote: > On 07/16/2014 04:16 AM, Srivatsa S. Bhat wrote: >> That is, we wanted >> to do the kobject cleanup after releasing the hotplug lock, and POST_DEAD >> stage was well-suited for that. I think, this has changed in Saravana's patch, we do it in the PREPARE stage now. >> Commit 1aee40ac9c8 (cpufreq: Invoke __cpufreq_remove_dev_finish() after >> releasing cpu_hotplug.lock) explains this in detail. Saravana, please take >> a >> look at that reasoning and ensure that your patch doesn't re-introduce >> those >> deadlock possibilities! > > > But all of that was needed _because_ we were creating and destroying > policies and kobjs all the time. We don't do that anymore. So, I don't think > any of that applies. We only destroy when the cpufreq driver is > unregistered. That's kinda of the point of this patchset. > > Thoughts? See above. -- 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: char interface to sdio, chdio.c
On Wed, Jul 16, 2014 at 04:08:11PM -0700, Stephen Boyd wrote: > On 07/16/14 12:38, Stephen Boyd wrote: > > On 07/16/14 11:44, Greg KH wrote: > >> My specific question is why 2 different interfaces? > > Ok. It definitely looks odd to support set/get of the VDD with sysfs and > > ioctl interfaces. I'm just guessing, but I suspect it's a permissions > > thing given that the patch that introduces the VDD stuff also updates > > the permissions of the device node. Of course, the commit text only > > mentions an ioctl, nothing about sysfs. The only other sysfs stuff seems > > to be module parameters to change the vendor ids. > > > > I'll have to go repo diving to figure out if the sysfs interface was > > ever used. Maybe Alex or Konstantin can respond before I have to do that. > > > > > > I couldn't find any usage of the sysfs interface. The only thing I see > used is the host_name field when the module is inserted, if that even > happens at all (I'm not sure because it's behind some ifdef that may or > may not be defined). Sorry this doesn't explain why there are two > different interfaces for the VDD stuff. Hopefully Alex or Konstantin can > help. The duplication of the vdd interface is odd, I'll just go delete it. In looking further at the code, it only supports 1 single device, set at build time, or module load time. That's not good, or generic. Any objection to me making it so it can support any sdio device in the system, and multiple devices as well, and actually work on a 64bit kernel, with multiple cores? Oh, and this obviously didn't run on a phone that had a kernel log enabled, as it logs every single little thing that happens to the device, just short of a raw byte stream. I'll fix that up, and I got it building on a 3.16-rc kernel. Patch that builds is below if anyone is curious. Oh, and checkout the code that goes and modifies the permissions of the device node in /dev/ from the kernel itself. The hoops Android developers have to go through because they were not using a udev-like programs is crazy. Hopefully devtmpfs is being used these days... thanks, greg k-h -- mmc: Char SDIO Device Driver Squashed commit of the following: commit c3fb53893cbc4b5e217ef176010d1b88982a9454 Author: Alexander Kolesnikov Date: Wed Sep 15 17:16:52 2010 +0200 csdio: Set/get vdd ioctl support Implement power up/down sequence for internal UBM chip. This commit includes generic, platform independent part. CRs-Fixed: 255849 Change-Id: I526c78765ba32b310463a231c5cf578cb37c6deb Signed-off-by: Alexander Kolesnikov commit e1ba27311fcf3de2a5ca9a3fc1303328720dd120 Author: Nela Gurevich Date: Thu Aug 19 14:00:09 2010 +0300 csdio: Move csdio.h to kernel/include Change-Id: Idf8df750e9f3bcc014d1afa673c9c27c97253195 Signed-off-by: Nela Gurevich commit 31d1b09c677c26efb71fa36ff6fe1e7f2d83abbc Author: Alexander Kolesnikov Date: Tue Aug 10 13:26:20 2010 +0300 mmc: Char SDIO Device Driver The Char SDIO Device Driver is an interface which exposes an SDIO card/function from kernel space as a char device in user space. Change-Id: If298cdd6d4426b700e69affa5a3602cd221ad89c Signed-off-by: Alexander Kolesnikov Signed-off-by: Stephen Boyd --- Documentation/csdio.txt | 189 drivers/char/Kconfig | 23 drivers/char/Makefile |1 drivers/char/csdio.c | 1070 ++ include/linux/csdio.h | 37 + include/uapi/linux/Kbuild |1 6 files changed, 1321 insertions(+) --- /dev/null +++ b/Documentation/csdio.txt @@ -0,0 +1,189 @@ +Introduction + +The Char SDIO Device Driver is an interface which exposes an SDIO +card/function from kernel space as a char device in user space. + +The driver doesn't interact with any HW directly. It relies on SDIO +card/function interface provided as a part of Linux kernel. + +Hardware description + +Each SDIO device/card contains an SDIO client HW block. +The host interacts with the device by sending byte sequences called +command (CMD). Some commands can be followed by data blocks. The +device sends back a byte sequence called response (R) and a data +block if required. CMD3, CMD5 and CMD7 are used to initialize the +device. CMD52 and CMD53 are used to access the device. Command +format and properties are defined by SDIO Specification document +published by SD Association: +http://www.sdcard.org/developers/tech/sdio/. + +CMD52 and CMD53 can access up to 8 address spaces called Functions. +Function 0 contains system information predefined by SD/SDIO +standard and Functions 1-7 are defined by the SDIO device +manufacturer. + +An SDIO device/card can send an interrupt to SDIO host. This +interrupt is intercepted and handled by SDIO host. + +Software description + +Linux provides a framework for handling SDIO devices. It implements +kind of plug-and-play model in which the Linux
Re: [PATCH RFC tip/core/rcu 1/2] rcu: Rationalize kthread spawning
On Wed, Jul 16, 2014 at 10:57:39PM -0400, Sasha Levin wrote: > On 07/14/2014 06:06 AM, Paul E. McKenney wrote: > > From: "Paul E. McKenney" > > > > Currently, RCU spawns kthreads from several different early_initcall() > > functions. Although this has served RCU well for quite some time, > > as more kthreads are added a more deterministic approach is required. > > This commit therefore causes all of RCU's early-boot kthreads to be > > spawned from a single early_initcall() function. > > > > Signed-off-by: Paul E. McKenney > > Hey Paul, > > I've updated to today's -next and my VM started hanging on boot. Bisect > pointed out this patch. > > I don't have any further info right now, but can provide whatever you'll > find useful. Could you please add initcall_debug to qemu's -append list? If sysrq-T works that early, its output would be helpful as well. Your .config would also be helpful. Thanx, Paul -- 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] PM / OPP: cpufreq: Avoid sleeping while atomic
On 17 July 2014 05:05, Stephen Boyd wrote:
> We allocate the cpufreq table after calling rcu_read_lock(),
> which disables preemption. This causes scheduling while atomic
> warnings. Use GFP_ATOMIC instead of GFP_KERNEL and update for
> kcalloc while we're here.
I am surprised to see that this isn't reported by anybody since the time
it came into existence? Some special config option required to observe
this?
> BUG: sleeping function called from invalid context at mm/slub.c:1246
> in_atomic(): 0, irqs_disabled(): 0, pid: 80, name: modprobe
> 5 locks held by modprobe/80:
> #0: (>mutex){..}, at: [] __driver_attach+0x48/0x98
> #1: (>mutex){..}, at: [] __driver_attach+0x58/0x98
> #2: (subsys mutex#5){+.+.+.}, at: []
> subsys_interface_register+0x38/0xc8
> #3: (cpufreq_rwsem){.+.+.+}, at: []
> __cpufreq_add_dev.isra.22+0x84/0x92c
> #4: (rcu_read_lock){..}, at: []
> dev_pm_opp_init_cpufreq_table+0x18/0x10c
> Preemption disabled at:[< (null)>] (null)
>
> CPU: 2 PID: 80 Comm: modprobe Not tainted
> 3.16.0-rc3-next-20140701-00035-g286857f216aa-dirty #217
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x70/0xbc)
> [] (dump_stack) from [] (__kmalloc+0x124/0x250)
> [] (__kmalloc) from []
> (dev_pm_opp_init_cpufreq_table+0x3c/0x10c)
> [] (dev_pm_opp_init_cpufreq_table) from []
> (cpufreq_init+0x48/0x378 [cpufreq_generic])
> [] (cpufreq_init [cpufreq_generic]) from []
> (__cpufreq_add_dev.isra.22+0x200/0x92c)
> [] (__cpufreq_add_dev.isra.22) from []
> (subsys_interface_register+0x84/0xc8)
> [] (subsys_interface_register) from []
> (cpufreq_register_driver+0x108/0x2d8)
> [] (cpufreq_register_driver) from []
> (generic_cpufreq_probe+0x50/0x74 [cpufreq_generic])
> [] (generic_cpufreq_probe [cpufreq_generic]) from []
> (platform_drv_probe+0x18/0x48)
> [] (platform_drv_probe) from []
> (driver_probe_device+0x128/0x370)
> [] (driver_probe_device) from []
> (__driver_attach+0x94/0x98)
> [] (__driver_attach) from [] (bus_for_each_dev+0x54/0x88)
> [] (bus_for_each_dev) from [] (bus_add_driver+0xe8/0x204)
> [] (bus_add_driver) from [] (driver_register+0x78/0xf4)
> [] (driver_register) from [] (do_one_initcall+0xac/0x1d8)
> [] (do_one_initcall) from [] (load_module+0x190c/0x21e8)
> [] (load_module) from [] (SyS_init_module+0xa4/0x110)
> [] (SyS_init_module) from [] (ret_fast_syscall+0x0/0x48)
>
> Fixes: a0dd7b79657b "PM / OPP: Move cpufreq specific OPP functions out of
> generic OPP library"
That looks to be wrong. This commit just moved things around and I can still
see rcu_read_lock() before this commit.
> Cc: Kevin Hilman
> Cc: Nishanth Menon
> Signed-off-by: Stephen Boyd
> ---
>
> It would be nice to not do atomic allocations, but I guess the table could
> change size?
Yep. Number of OPPs can vary over time on a running machine.
> drivers/cpufreq/cpufreq_opp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/cpufreq_opp.c b/drivers/cpufreq/cpufreq_opp.c
> index c0c6f4a4eccf..f7a32d2326c6 100644
> --- a/drivers/cpufreq/cpufreq_opp.c
> +++ b/drivers/cpufreq/cpufreq_opp.c
> @@ -60,7 +60,7 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
> goto out;
> }
>
> - freq_table = kzalloc(sizeof(*freq_table) * (max_opps + 1),
> GFP_KERNEL);
> + freq_table = kcalloc(sizeof(*freq_table), (max_opps + 1), GFP_ATOMIC);
I am not really sure if there would be any consequences of this, but overall it
looks fine.
Acked-by: Viresh Kumar
--
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] r8169: Enable RX_MULTI_EN for RTL_GIGA_MAC_VER_40
From: Michel Dänzer
Date: Thu, 17 Jul 2014 12:55:40 +0900
> The ethernet port on my ASUS A88X Pro mainboard stopped working
> several times a day, with messages like these in dmesg:
>
> AMD-Vi: Event logged [IO_PAGE_FAULT device=05:00.0 domain=0x001e
> address=0x3000 flags=0x0050]
>
> Searching the web for these messages led me to similar reports about
> different hardware supported by r8169, and eventually to commits
> 3ced8c955e74d319f3e3997f7169c79d524dfd06 ('r8169: enforce RX_MULTI_EN
> for the 8168f.') and eb2dc35d99028b698cdedba4f5522bc43e576bd2 ('r8169:
> RxConfig hack for the 8168evl'). So I tried this change, and it fixes
> the problem for me.
>
> Signed-off-by: Michel Dänzer
> ---
>
> v2: Updated commit log, how about this?
Works for me, applied, 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 2/2 v3] sched: Rewrite per entity runnable load average tracking
On Wed, Jul 16, 2014 at 11:53:23AM -0700, bseg...@google.com wrote:
> Morten Rasmussen writes:
>
> > On Wed, Jul 16, 2014 at 02:50:47AM +0100, Yuyang Du wrote:
> >
> > [...]
> >
> >> +/*
> >> + * Update load_avg of the cfs_rq along with its own se. They should get
> >> + * synchronized: group se's load_avg is used for task_h_load calc, and
> >> + * group cfs_rq's load_avg is used for task_h_load (and update_cfs_share
> >> + * calc).
> >> + */
> >> +static inline int update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
> >> {
> >> - long old_contrib = se->avg.load_avg_contrib;
> >> + int decayed;
> >>
> >> - if (entity_is_task(se)) {
> >> - __update_task_entity_contrib(se);
> >> - } else {
> >> - __update_tg_runnable_avg(>avg, group_cfs_rq(se));
> >> - __update_group_entity_contrib(se);
> >> + if (atomic_long_read(_rq->removed_load_avg)) {
> >> + long r = atomic_long_xchg(_rq->removed_load_avg, 0);
> >> + cfs_rq->avg.load_avg =
> >> subtract_until_zero(cfs_rq->avg.load_avg, r);
> >> + r *= LOAD_AVG_MAX;
> >> + cfs_rq->avg.load_sum =
> >> subtract_until_zero(cfs_rq->avg.load_sum, r);
> >> }
> >>
> >> - return se->avg.load_avg_contrib - old_contrib;
> >> -}
> >> + decayed = __update_load_avg(now, _rq->avg,
> >> cfs_rq->load.weight);
> >> +#ifndef CONFIG_64BIT
> >> + if (cfs_rq->avg.last_update_time !=
> >> cfs_rq->load_last_update_time_copy)
> >> + sa_q->last_update_time_copy = sa_q->last_update_time;
> >
> > to make it build. But I'm not convinced that this synchronization is
> > right.
> >
> > First let me say that I'm not an expert on synchronization. It seems to
> > me that there is nothing preventing reordering of the writes in
> > __update_load_avg() which sets cfs_rq->avg.last_update_time and the
> > update of cfs_rq->avg.load_last_update_time_copy.
>
> You're correct, this needs to be if(...) { smp_wmb(); copy = time; },
> the same as update_min_vruntime.
Ok, I will get the barrier back. Thanks, Morten and Ben.
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/
RE: [PATCH 2/3] KVM: nVMX: Fix fail to get nested ack intr's vector during nested vmexit
Wanpeng Li wrote on 2014-07-17:
> WARNING: CPU: 9 PID: 7251 at arch/x86/kvm/vmx.c:8719
> nested_vmx_vmexit+0xa4/0x233 [kvm_intel]() Modules linked in: tun
> nfsv3 nfs_acl auth_rpcgss oid_registry nfsv4 dns_resolver nfs fscache
> lockd sunrpc pci_stub netconsole kvm_intel kvm bridge stp llc autofs4
> 8021q ipv6 uinput joydev microcode pcspkr igb i2c_algo_bit ehci_pci
> ehci_hcd e1000e ixgbe ptp pps_core hwmon mdio i2c_i801 i2c_core
> tpm_tis tpm ipmi_si ipmi_msghandler isci libsas scsi_transport_sas
> button dm_mirror dm_region_hash dm_log dm_mod
> CPU: 9 PID: 7251 Comm: qemu-system-x86 Tainted: GW
> 3.16.0-rc1 #2
> Hardware name: Intel Corporation S2600CP/S2600CP, BIOS
> RMLSDP.86I.00.29.D696.131329 11/11/2013 220f
> 880ffd107bf8 81493563 220f
> 880ffd107c38 8103f0eb 880ffd107c48
> a059709a 881ffc9e0040 8800b74b8000
> Call Trace: [] dump_stack+0x49/0x5e
> []
> warn_slowpath_common+0x7c/0x96 [] ?
> nested_vmx_vmexit+0xa4/0x233 [kvm_intel] []
> warn_slowpath_null+0x15/0x17 []
> nested_vmx_vmexit+0xa4/0x233 [kvm_intel] [] ?
> nested_vmx_exit_handled+0x6a/0x39e [kvm_intel] [] ?
> kvm_apic_has_interrupt+0x80/0xd5 [kvm] []
> vmx_check_nested_events+0xc3/0xd3 [kvm_intel] []
> inject_pending_event+0xd0/0x16e [kvm] []
> vcpu_enter_guest+0x319/0x704 [kvm]
>
> After commit 77b0f5d (KVM: nVMX: Ack and write vector info to
> intr_info if L1 asks us to), "Acknowledge interrupt on exit" behavior
> can be emulated. Current logic will ask for intr vector if it is
> nested vmexit and VM_EXIT_ACK_INTR_ON_EXIT is set by L1. However, intr
> vector for posted intr can't be got by generic read pending interrupt
> vector and intack routine, there is a requirement to sync from pir to
> irr. This patch fix it by ask the intr vector after sync pir to irr.
>
> Signed-off-by: Wanpeng Li
Reviewed-by: Yang Zhang
> ---
> arch/x86/kvm/lapic.c | 1 +
> arch/x86/kvm/vmx.c | 3 +++
> 2 files changed, 4 insertions(+)
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index
> 0069118..b7d45dc 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -1637,6 +1637,7 @@ int kvm_get_apic_interrupt(struct kvm_vcpu *vcpu)
> apic_clear_irr(vector, apic);
> return vector;
> }
> +EXPORT_SYMBOL_GPL(kvm_get_apic_interrupt);
>
> void kvm_apic_post_state_restore(struct kvm_vcpu *vcpu,
> struct kvm_lapic_state *s)
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index
> 4ae5ad8..31f1479 100644 --- a/arch/x86/kvm/vmx.c +++
> b/arch/x86/kvm/vmx.c @@ -8697,6 +8697,9 @@ static void
> nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 exit_reason,
> if ((exit_reason == EXIT_REASON_EXTERNAL_INTERRUPT)
> && nested_exit_intr_ack_set(vcpu)) {
> int irq = kvm_cpu_get_interrupt(vcpu);
> +
> + if (irq < 0 && kvm_apic_vid_enabled(vcpu->kvm))
> + irq = kvm_get_apic_interrupt(vcpu);
> WARN_ON(irq < 0);
> vmcs12->vm_exit_intr_info = irq |
> INTR_INFO_VALID_MASK | INTR_TYPE_EXT_INTR;
Best regards,
Yang
--
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/6] autofs4: allow RCU-walk to walk through autofs4.
On Wed, 2014-07-16 at 14:56 +0800, Ian Kent wrote: > > That looks a bit messy ... I wonder if we could have a new "ino" flag which > > says "This dentry is mounted-on if it needs to be. Gets set by ->lookup > > and cleared by ->d_automount or when ->d_manage returns -EISDIR. > > At one point DCACHE_NEED_AUTOMOUNT and DCACHE_MANAGE_TRANSIT were > handled separately and DCACHE_NEED_AUTOMOUNT was cleared for rootless > multi-mount dentrys following a mount and set again at expire. Not > having to worry about managing that flag was also part of the > optimization. > > We could go back to managing DCACHE_NEED_AUTOMOUNT or add a new flag. > I'm not fussy how it's done as long as it works. IIRC there was one > quite convoluted if check (in the expire code) that was removed due to > the optimization. Umm ... using DCACHE_NEED_AUTOMOUNT rather than a new flag means using an additional lock so perhaps a new flag would be preferred since reducing lock overhead was the point of this. Just a thought Ian -- 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 v12 0/8] MADV_FREE support
Kirill, Do you have any comment? On Wed, Jul 09, 2014 at 03:22:21PM +0900, Minchan Kim wrote: > 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-7] is to preparing to call madvise syscall without THP plitting > [8] enable THP page support for MADV_FREE. > > > * From v11 > * Fix arm build - Steve > * Separate patch for arm and arm64 - Steve > * Remove unnecessary check - Kirill > * Skip non-vm_normal page - Kirill > * Add Acked-by - Zhang > * Sparc64 build fix > * Pagetable walker THP handling fix > > * 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 > > * 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 (8): > [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] arm64: add pmd_[dirty|mkclean] for THP > [8] 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/huge_mm.h | 4 + > include/linux/rmap.h | 9 +- > include/linux/vm_event_item.h| 1 + > include/uapi/asm-generic/mman-common.h | 1 + > mm/huge_memory.c | 35 +++ > mm/madvise.c | 155 > +++ > mm/rmap.c| 46 - > mm/vmscan.c | 64 + > mm/vmstat.c | 1 + > 15 files changed, 341 insertions(+), 20 deletions(-) > > -- > 2.0.0 > > -- > 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/
[PATCH 3/3] KVM: nVMX: Fix vmptrld fail and vmwrite error when L1 goes down
This bug can be trigger by L1 goes down directly w/ enable_shadow_vmcs.
[ 6413.158950] kvm: vmptrld (null)/7800 failed
[ 6413.158954] vmwrite error: reg 401e value 4 (err 1)
[ 6413.158957] CPU: 0 PID: 4840 Comm: qemu-system-x86 Tainted: G OE
3.16.0kvm+ #2
[ 6413.158958] Hardware name: Dell Inc. OptiPlex 9020/0DNKMN, BIOS A05
12/05/2013
[ 6413.158959] 0003 880210c9fb58 81741de9
8800d7433f80
[ 6413.158960] 880210c9fb68 a059fa08 880210c9fb78
a05938bf
[ 6413.158962] 880210c9fba8 a059a97f 8800d7433f80
0003
[ 6413.158963] Call Trace:
[ 6413.158968] [] dump_stack+0x45/0x56
[ 6413.158972] [] vmwrite_error+0x2c/0x2e [kvm_intel]
[ 6413.158974] [] vmcs_writel+0x1f/0x30 [kvm_intel]
[ 6413.158976] [] free_nested.part.73+0x5f/0x170 [kvm_intel]
[ 6413.158978] [] vmx_free_vcpu+0x33/0x70 [kvm_intel]
[ 6413.158991] [] kvm_arch_vcpu_free+0x44/0x50 [kvm]
[ 6413.158998] [] kvm_arch_destroy_vm+0xf2/0x1f0 [kvm]
Commit 26a865 (KVM: VMX: fix use after free of vmx->loaded_vmcs) fix the use
after free bug by move free_loaded_vmcs() before free_nested(), however, this
lead to free loaded_vmcs->vmcs premature and vmptrld load a NULL pointer during
sync shadow vmcs to vmcs12. In addition, vmwrite which used to disable shadow
vmcs and reset VMCS_LINK_POINTER failed since there is no valid current-VMCS.
This patch fix it by skipping sync shadow vmcs and reset vmcs field for L1
destroy since they will be reinitialized after L1 recreate.
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/vmx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index fbce89e..2b28da7 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -6113,9 +6113,9 @@ static void free_nested(struct vcpu_vmx *vmx)
return;
vmx->nested.vmxon = false;
if (vmx->nested.current_vmptr != -1ull) {
- nested_release_vmcs12(vmx);
vmx->nested.current_vmptr = -1ull;
vmx->nested.current_vmcs12 = NULL;
+ nested_release_vmcs12(vmx);
}
if (enable_shadow_vmcs)
free_vmcs(vmx->nested.current_shadow_vmcs);
--
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/
[PATCH 1/3] KVM: nVMX: Fix virtual interrupt delivery injection
This patch fix bug reported in
https://bugzilla.kernel.org/show_bug.cgi?id=73331,
after the patch http://www.spinics.net/lists/kvm/msg105230.html applied, there
is
some progress and the L2 can boot up, however, slowly. The original idea of
this
fix vid injection patch is from "Zhang, Yang Z" .
Interrupt which delivered by vid should be injected to L1 by L0 if current is
in
L1, or should be injected to L2 by L0 through the old injection way if L1
doesn't
have set VM_EXIT_ACK_INTR_ON_EXIT. The current logic doen't consider these
cases.
This patch fix it by vid intr to L1 if current is L1 or L2 through old
injection
way if L1 doen't have VM_EXIT_ACK_INTR_ON_EXIT set.
Signed-off-by: Wanpeng Li
Signed-off-by: "Zhang, Yang Z"
---
arch/x86/kvm/vmx.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 021d84a..ad36646 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -7112,8 +7112,22 @@ static void vmx_hwapic_irr_update(struct kvm_vcpu *vcpu,
int max_irr)
{
if (max_irr == -1)
return;
-
- vmx_set_rvi(max_irr);
+ if (!is_guest_mode(vcpu)) {
+ vmx_set_rvi(max_irr);
+ } else if (is_guest_mode(vcpu) && !nested_exit_on_intr(vcpu)) {
+ /*
+* Fall back to old way to inject the interrupt since there
+* is no vAPIC-v for L2.
+*/
+ if (vcpu->arch.exception.pending ||
+ vcpu->arch.nmi_injected ||
+ vcpu->arch.interrupt.pending)
+ return;
+ else if (vmx_interrupt_allowed(vcpu)) {
+ kvm_queue_interrupt(vcpu, max_irr, false);
+ vmx_inject_irq(vcpu);
+ }
+ }
}
static void vmx_load_eoi_exitmap(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap)
--
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/
[PATCH 2/3] KVM: nVMX: Fix fail to get nested ack intr's vector during nested vmexit
WARNING: CPU: 9 PID: 7251 at arch/x86/kvm/vmx.c:8719
nested_vmx_vmexit+0xa4/0x233 [kvm_intel]()
Modules linked in: tun nfsv3 nfs_acl auth_rpcgss oid_registry nfsv4
dns_resolver nfs fscache lockd
sunrpc pci_stub netconsole kvm_intel kvm bridge stp llc autofs4 8021q ipv6
uinput joydev microcode
pcspkr igb i2c_algo_bit ehci_pci ehci_hcd e1000e ixgbe ptp pps_core hwmon mdio
i2c_i801 i2c_core
tpm_tis tpm ipmi_si ipmi_msghandler isci libsas scsi_transport_sas button
dm_mirror dm_region_hash
dm_log dm_mod
CPU: 9 PID: 7251 Comm: qemu-system-x86 Tainted: GW 3.16.0-rc1 #2
Hardware name: Intel Corporation S2600CP/S2600CP, BIOS
RMLSDP.86I.00.29.D696.131329 11/11/2013
220f 880ffd107bf8 81493563 220f
880ffd107c38 8103f0eb 880ffd107c48
a059709a 881ffc9e0040 8800b74b8000
Call Trace:
[] dump_stack+0x49/0x5e
[] warn_slowpath_common+0x7c/0x96
[] ? nested_vmx_vmexit+0xa4/0x233 [kvm_intel]
[] warn_slowpath_null+0x15/0x17
[] nested_vmx_vmexit+0xa4/0x233 [kvm_intel]
[] ? nested_vmx_exit_handled+0x6a/0x39e [kvm_intel]
[] ? kvm_apic_has_interrupt+0x80/0xd5 [kvm]
[] vmx_check_nested_events+0xc3/0xd3 [kvm_intel]
[] inject_pending_event+0xd0/0x16e [kvm]
[] vcpu_enter_guest+0x319/0x704 [kvm]
After commit 77b0f5d (KVM: nVMX: Ack and write vector info to intr_info if L1
asks us to), "Acknowledge interrupt on exit" behavior can be emulated. Current
logic will ask for intr vector if it is nested vmexit and
VM_EXIT_ACK_INTR_ON_EXIT
is set by L1. However, intr vector for posted intr can't be got by generic read
pending interrupt vector and intack routine, there is a requirement to sync
from
pir to irr. This patch fix it by ask the intr vector after sync pir to irr.
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/lapic.c | 1 +
arch/x86/kvm/vmx.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 0069118..b7d45dc 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1637,6 +1637,7 @@ int kvm_get_apic_interrupt(struct kvm_vcpu *vcpu)
apic_clear_irr(vector, apic);
return vector;
}
+EXPORT_SYMBOL_GPL(kvm_get_apic_interrupt);
void kvm_apic_post_state_restore(struct kvm_vcpu *vcpu,
struct kvm_lapic_state *s)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4ae5ad8..31f1479 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -8697,6 +8697,9 @@ static void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32
exit_reason,
if ((exit_reason == EXIT_REASON_EXTERNAL_INTERRUPT)
&& nested_exit_intr_ack_set(vcpu)) {
int irq = kvm_cpu_get_interrupt(vcpu);
+
+ if (irq < 0 && kvm_apic_vid_enabled(vcpu->kvm))
+ irq = kvm_get_apic_interrupt(vcpu);
WARN_ON(irq < 0);
vmcs12->vm_exit_intr_info = irq |
INTR_INFO_VALID_MASK | INTR_TYPE_EXT_INTR;
--
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/
Re: [PATCH net-next] virtio-net: rx busy polling support
Jason Wang writes:
> Add basic support for rx busy polling.
>
> 1 byte netperf tcp_rr on mlx4 shows 116% improvement: the transaction
> rate was increased from 9151.94 to 19787.37.
>
> Cc: Rusty Russell
> Cc: Michael S. Tsirkin
> Cc: Vlad Yasevich
> Signed-off-by: Jason Wang
Nice! But I'm deeply unqualified to review it :(
Thanks,
Rusty.
> ---
> drivers/net/virtio_net.c | 241
> +++
> 1 file changed, 225 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 7d9f84a..a5ce604 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
>
> static int napi_weight = NAPI_POLL_WEIGHT;
> module_param(napi_weight, int, 0444);
> @@ -94,8 +95,144 @@ struct receive_queue {
>
> /* Name of this receive queue: input.$index */
> char name[40];
> +
> +#ifdef CONFIG_NET_RX_BUSY_POLL
> + unsigned int state;
> +#define VIRTNET_RQ_STATE_IDLE0
> +#define VIRTNET_RQ_STATE_NAPI 1/* NAPI or refill owns this
> RQ */
> +#define VIRTNET_RQ_STATE_POLL 2/* poll owns this RQ */
> +#define VIRTNET_RQ_STATE_DISABLED4/* RQ is disabled */
> +#define VIRTNET_RQ_OWNED (VIRTNET_RQ_STATE_NAPI | VIRTNET_RQ_STATE_POLL)
> +#define VIRTNET_RQ_LOCKED (VIRTNET_RQ_OWNED | VIRTNET_RQ_STATE_DISABLED)
> +#define VIRTNET_RQ_STATE_NAPI_YIELD 8/* NAPI or refill yielded this RQ
> */
> +#define VIRTNET_RQ_STATE_POLL_YIELD 16 /* poll yielded this RQ */
> +#define VIRTNET_RQ_YIELD (VIRTNET_RQ_STATE_NAPI_YIELD |
> VIRTNET_RQ_STATE_POLL_YIELD)
> + spinlock_t lock;
> +#endif /* CONFIG_NET_RX_BUSY_POLL */
> };
>
> +#ifdef CONFIG_NET_RX_BUSY_POLL
> +static inline void virtnet_rq_init_lock(struct receive_queue *rq)
> +{
> +
> + spin_lock_init(>lock);
> + rq->state = VIRTNET_RQ_STATE_IDLE;
> +}
> +
> +/* called from the device poll routine or refill routine to get ownership of
> a
> + * receive queue.
> + */
> +static inline bool virtnet_rq_lock_napi_refill(struct receive_queue *rq)
> +{
> + int rc = true;
> +
> + spin_lock(>lock);
> + if (rq->state & VIRTNET_RQ_LOCKED) {
> + WARN_ON(rq->state & VIRTNET_RQ_STATE_NAPI);
> + rq->state |= VIRTNET_RQ_STATE_NAPI_YIELD;
> + rc = false;
> + } else
> + /* we don't care if someone yielded */
> + rq->state = VIRTNET_RQ_STATE_NAPI;
> + spin_unlock(>lock);
> + return rc;
> +}
> +
> +/* returns true is someone tried to get the rq while napi or refill had it */
> +static inline bool virtnet_rq_unlock_napi_refill(struct receive_queue *rq)
> +{
> + int rc = false;
> +
> + spin_lock(>lock);
> + WARN_ON(rq->state & (VIRTNET_RQ_STATE_POLL |
> + VIRTNET_RQ_STATE_NAPI_YIELD));
> +
> + if (rq->state & VIRTNET_RQ_STATE_POLL_YIELD)
> + rc = true;
> + /* will reset state to idle, unless RQ is disabled */
> + rq->state &= VIRTNET_RQ_STATE_DISABLED;
> + spin_unlock(>lock);
> + return rc;
> +}
> +
> +/* called from virtnet_low_latency_recv() */
> +static inline bool virtnet_rq_lock_poll(struct receive_queue *rq)
> +{
> + int rc = true;
> +
> + spin_lock_bh(>lock);
> + if ((rq->state & VIRTNET_RQ_LOCKED)) {
> + rq->state |= VIRTNET_RQ_STATE_POLL_YIELD;
> + rc = false;
> + } else
> + /* preserve yield marks */
> + rq->state |= VIRTNET_RQ_STATE_POLL;
> + spin_unlock_bh(>lock);
> + return rc;
> +}
> +
> +/* returns true if someone tried to get the receive queue while it was
> locked */
> +static inline bool virtnet_rq_unlock_poll(struct receive_queue *rq)
> +{
> + int rc = false;
> +
> + spin_lock_bh(>lock);
> + WARN_ON(rq->state & (VIRTNET_RQ_STATE_NAPI));
> +
> + if (rq->state & VIRTNET_RQ_STATE_POLL_YIELD)
> + rc = true;
> + /* will reset state to idle, unless RQ is disabled */
> + rq->state &= VIRTNET_RQ_STATE_DISABLED;
> + spin_unlock_bh(>lock);
> + return rc;
> +}
> +
> +/* return false if RQ is currently owned */
> +static inline bool virtnet_rq_disable(struct receive_queue *rq)
> +{
> + int rc = true;
> +
> + spin_lock_bh(>lock);
> + if (rq->state & VIRTNET_RQ_OWNED)
> + rc = false;
> + rq->state |= VIRTNET_RQ_STATE_DISABLED;
> + spin_unlock_bh(>lock);
> +
> + return rc;
> +}
> +
> +#else /* CONFIG_NET_RX_BUSY_POLL */
> +static inline void virtnet_rq_init_lock(struct receive_queue *rq)
> +{
> +}
> +
> +static inline bool virtnet_rq_lock_napi_refill(struct receive_queue *rq)
> +{
> + return true;
> +}
> +
> +static inline bool virtnet_rq_unlock_napi_refill(struct receive_queue *rq)
> +{
> + return false;
> +}
> +
> +static inline bool virtnet_rq_lock_poll(struct receive_queue *rq)
> +{
> + return false;
> +}
> +
> +static inline bool
Re: [PATCH v3 2/5] random,x86: Add arch_get_slow_rng_u64
On 07/16/2014 05:03 PM, Andy Lutomirski wrote: >> >> prandom is exactly the opposite; it is designed for when we need >> possibly low quality random numbers very quickly. RDRAND is actually >> too slow. > > I meant that prandom isn't using rdrand for early seeding. > We should probably fix that. -hpa -- 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] NoMoreModuleVmalloc - Try alloc_pages_exact before vmalloc, if fails do vmalloc
Lucas Tanure writes: > Hi Russell, > > I found that project > http://kernelnewbies.org/KernelProjects/NoMoreModuleVmalloc. > So I thought that doing first a alloc_pages_exact would be the goal. > The kernel/module.c doesn't need this task any more, or I just did in > the wrong way ? Hmm, that's hardly a newbie project! arch/x86/kernel/module.c contains the module_alloc() code for x86. You'd need to repalce that, and set module_free() too. And it's not entirely clear that replacing it with kmalloc is actually useful, since it will break CONFIG_DEBUG_SET_MODULE_RONX=y. Cheers, Rusty. -- 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] percpu: add data dependency barrier in percpu accessors and operations
"Paul E. McKenney" writes: > On Wed, Jul 09, 2014 at 10:25:44AM +0930, Rusty Russell wrote: >> Tejun Heo writes: >> > Hello, Paul. >> >> Rusty wakes up... > > ;-) > >> >> Good point. How about per-CPU variables that are introduced by >> >> loadable modules? (I would guess that there are plenty of memory >> >> barriers in the load process, given that text and data also needs >> >> to be visible to other CPUs.) >> > >> > (cc'ing Rusty, hi!) >> > >> > Percpu initialization happens in post_relocation() before >> > module_finalize(). There seem to be enough operations which can act >> > as write barrier afterwards but nothing seems explicit. >> > >> > I have no idea how we're guaranteeing that .data is visible to all >> > cpus without barrier from reader side. Maybe we don't allow something >> > like the following? >> > >> > module init built-in code >> > >> > static int mod_static_var = X; if (builtin_ptr) >> > builtin_ptr = _static_var; WARN_ON(*builtin_ptr != X); >> > >> > Rusty, can you please enlighten me? >> >> Subtle, but I think in theory (though not in practice) this can happen. >> >> Making this this assigner's responsibility is nasty, since we reasonably >> assume that .data is consistent across CPUs once code is executing >> (similarly on boot). >> >> >> Again, it won't help for the allocator to strongly order the >> >> initialization to zero if there are additional initializations of some >> >> fields to non-zero values. And again, it should be a lot easier to >> >> require the smp_store_release() or whatever uniformly than only in cases >> >> where additional initialization occurred. >> > >> > This one is less murky as we can say that the cpu which allocated owns >> > the zeroing; however, it still deviates from requiring the one which >> > makes changes to take care of barriering for those changes, which is >> > what makes me feel a bit uneasy. IOW, it's the allocator which >> > cleared the memory, why should its users worry about in-flight >> > operations from it? That said, this poses a lot less issues compared >> > to percpu ones as passing normal pointers to other cpus w/o going >> > through proper set of barriers is a special thing to do anyway. >> >> I think that the implicit per-cpu allocations done by modules need to >> be consistent once the module is running. >> >> I'm deeply reluctant to advocate it in the other per-cpu cases though. >> Once we add a barrier, it's impossible to remove: callers may subtly >> rely on the behavior. >> >> "Magic barrier sprinkles" is a bad path to start down, IMHO. > > Here is the sort of thing that I would be concerned about: > > p = alloc_percpu(struct foo); > for_each_possible_cpu(cpu) > initialize(per_cpu_ptr(p, cpu); > gp = p; > > We clearly need a memory barrier in there somewhere, and it cannot > be buried in alloc_percpu(). Some cases avoid trouble due to locking, > for example, initialize() might acquire a per-CPU lock and later uses > might acquire that same lock. Clearly, use of a global lock would not > be helpful from a scalability viewpoint. I agree with Christoph: there's no per-cpu-unique peculiarity here. Anyone who exposes a pointer needs a barrier first. And the per-cpu allocation for modules is under a mutex, so that case is already covered. Cheers, Rusty. -- 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 V2 3/3] virtio-net: rx busy polling support
On Thursday 17 July 2014 10:13 AM, Jason Wang wrote:
On 07/17/2014 11:27 AM, Varka Bhadram wrote:
On Thursday 17 July 2014 08:25 AM, Jason Wang wrote:
On 07/16/2014 04:38 PM, Varka Bhadram wrote:
On 07/16/2014 11:51 AM, Jason Wang wrote:
Add basic support for rx busy polling.
Test was done between a kvm guest and an external host. Two hosts were
connected through 40gb mlx4 cards. With both busy_poll and busy_read
are set to 50 in guest, 1 byte netperf tcp_rr shows 116% improvement:
transaction rate was increased from 9151.94 to 19787.37.
Cc: Rusty Russell
Cc: Michael S. Tsirkin
Cc: Vlad Yasevich
Cc: Eric Dumazet
Signed-off-by: Jason Wang
---
drivers/net/virtio_net.c | 190
++-
1 file changed, 187 insertions(+), 3 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index e417d93..4830713 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
static int napi_weight = NAPI_POLL_WEIGHT;
module_param(napi_weight, int, 0444);
@@ -94,8 +95,143 @@ struct receive_queue {
/* Name of this receive queue: input.$index */
char name[40];
+
+#ifdef CONFIG_NET_RX_BUSY_POLL
+unsigned int state;
+#define VIRTNET_RQ_STATE_IDLE0
+#define VIRTNET_RQ_STATE_NAPI 1/* NAPI or refill owns
this RQ */
+#define VIRTNET_RQ_STATE_POLL 2/* poll owns this RQ */
+#define VIRTNET_RQ_STATE_DISABLED4/* RQ is disabled */
+#define VIRTNET_RQ_OWNED (VIRTNET_RQ_STATE_NAPI |
VIRTNET_RQ_STATE_POLL)
+#define VIRTNET_RQ_LOCKED (VIRTNET_RQ_OWNED |
VIRTNET_RQ_STATE_DISABLED)
+#define VIRTNET_RQ_STATE_NAPI_YIELD 8/* NAPI or refill yielded
this RQ */
+#define VIRTNET_RQ_STATE_POLL_YIELD 16 /* poll yielded this RQ */
+spinlock_t lock;
+#endif /* CONFIG_NET_RX_BUSY_POLL */
};
+#ifdef CONFIG_NET_RX_BUSY_POLL
+static inline void virtnet_rq_init_lock(struct receive_queue *rq)
+{
+
+spin_lock_init(>lock);
+rq->state = VIRTNET_RQ_STATE_IDLE;
+}
+
+/* called from the device poll routine or refill routine to get
ownership of a
+ * receive queue.
+ */
+static inline bool virtnet_rq_lock_napi_refill(struct receive_queue
*rq)
+{
+int rc = true;
+
bool instead of int...?
Yes, it was better.
+spin_lock(>lock);
+if (rq->state & VIRTNET_RQ_LOCKED) {
+WARN_ON(rq->state & VIRTNET_RQ_STATE_NAPI);
+rq->state |= VIRTNET_RQ_STATE_NAPI_YIELD;
+rc = false;
+} else
+/* we don't care if someone yielded */
+rq->state = VIRTNET_RQ_STATE_NAPI;
+spin_unlock(>lock);
Lock for rq->state ...?
If yes:
spin_lock(>lock);
if (rq->state & VIRTNET_RQ_LOCKED) {
rq->state |= VIRTNET_RQ_STATE_NAPI_YIELD;
spin_unlock(>lock);
WARN_ON(rq->state & VIRTNET_RQ_STATE_NAPI);
rc = false;
} else {
/* we don't care if someone yielded */
rq->state = VIRTNET_RQ_STATE_NAPI;
spin_unlock(>lock);
}
I didn't see any differences. Is this used to catch the bug of driver
earlier? btw, several other rx busy polling capable driver does the same
thing.
We need not to include WARN_ON() & rc=false under critical section.
Ok. but unless there's a bug in the driver itself, WARN_ON() should be
just a condition check for a branch, so there should not be noticeable
differences.
Also we should not check rq->state outside the protection of lock.
Ok. I will agree with you. But 'rc' can be outside the protection of lock
--
Regards,
Varka Bhadram
--
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 V2 3/3] virtio-net: rx busy polling support
On 07/17/2014 11:27 AM, Varka Bhadram wrote:
>
> On Thursday 17 July 2014 08:25 AM, Jason Wang wrote:
>> On 07/16/2014 04:38 PM, Varka Bhadram wrote:
>>> On 07/16/2014 11:51 AM, Jason Wang wrote:
Add basic support for rx busy polling.
Test was done between a kvm guest and an external host. Two hosts were
connected through 40gb mlx4 cards. With both busy_poll and busy_read
are set to 50 in guest, 1 byte netperf tcp_rr shows 116% improvement:
transaction rate was increased from 9151.94 to 19787.37.
Cc: Rusty Russell
Cc: Michael S. Tsirkin
Cc: Vlad Yasevich
Cc: Eric Dumazet
Signed-off-by: Jason Wang
---
drivers/net/virtio_net.c | 190
++-
1 file changed, 187 insertions(+), 3 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index e417d93..4830713 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
static int napi_weight = NAPI_POLL_WEIGHT;
module_param(napi_weight, int, 0444);
@@ -94,8 +95,143 @@ struct receive_queue {
/* Name of this receive queue: input.$index */
char name[40];
+
+#ifdef CONFIG_NET_RX_BUSY_POLL
+unsigned int state;
+#define VIRTNET_RQ_STATE_IDLE0
+#define VIRTNET_RQ_STATE_NAPI 1/* NAPI or refill owns
this RQ */
+#define VIRTNET_RQ_STATE_POLL 2/* poll owns this RQ */
+#define VIRTNET_RQ_STATE_DISABLED4/* RQ is disabled */
+#define VIRTNET_RQ_OWNED (VIRTNET_RQ_STATE_NAPI |
VIRTNET_RQ_STATE_POLL)
+#define VIRTNET_RQ_LOCKED (VIRTNET_RQ_OWNED |
VIRTNET_RQ_STATE_DISABLED)
+#define VIRTNET_RQ_STATE_NAPI_YIELD 8/* NAPI or refill yielded
this RQ */
+#define VIRTNET_RQ_STATE_POLL_YIELD 16 /* poll yielded this RQ */
+spinlock_t lock;
+#endif /* CONFIG_NET_RX_BUSY_POLL */
};
+#ifdef CONFIG_NET_RX_BUSY_POLL
+static inline void virtnet_rq_init_lock(struct receive_queue *rq)
+{
+
+spin_lock_init(>lock);
+rq->state = VIRTNET_RQ_STATE_IDLE;
+}
+
+/* called from the device poll routine or refill routine to get
ownership of a
+ * receive queue.
+ */
+static inline bool virtnet_rq_lock_napi_refill(struct receive_queue
*rq)
+{
+int rc = true;
+
>>> bool instead of int...?
>> Yes, it was better.
+spin_lock(>lock);
+if (rq->state & VIRTNET_RQ_LOCKED) {
+WARN_ON(rq->state & VIRTNET_RQ_STATE_NAPI);
+rq->state |= VIRTNET_RQ_STATE_NAPI_YIELD;
+rc = false;
+} else
+/* we don't care if someone yielded */
+rq->state = VIRTNET_RQ_STATE_NAPI;
+spin_unlock(>lock);
>>> Lock for rq->state ...?
>>>
>>> If yes:
>>> spin_lock(>lock);
>>> if (rq->state & VIRTNET_RQ_LOCKED) {
>>> rq->state |= VIRTNET_RQ_STATE_NAPI_YIELD;
>>> spin_unlock(>lock);
>>> WARN_ON(rq->state & VIRTNET_RQ_STATE_NAPI);
>>> rc = false;
>>> } else {
>>> /* we don't care if someone yielded */
>>> rq->state = VIRTNET_RQ_STATE_NAPI;
>>> spin_unlock(>lock);
>>> }
>> I didn't see any differences. Is this used to catch the bug of driver
>> earlier? btw, several other rx busy polling capable driver does the same
>> thing.
>
> We need not to include WARN_ON() & rc=false under critical section.
>
Ok. but unless there's a bug in the driver itself, WARN_ON() should be
just a condition check for a branch, so there should not be noticeable
differences.
Also we should not check rq->state outside the protection of lock.
--
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/6 v2] autofs4: factor should_expire() out of autofs4_expire_indirect.
On Wed, 16 Jul 2014 15:50:17 +0800 Ian Kent wrote:
> > + if (simple_empty(dentry))
> > + return NULL;
> > +
> > + /* Case 2: tree mount, expire iff entire tree is not busy */
> > + if (!exp_leaves) {
> > + /* Path walk currently on this dentry? */
> > + ino_count = atomic_read(>count) + 1;
> > + if (d_count(dentry) > ino_count)
> > + return NULL;
> > +
> > + if (!autofs4_tree_busy(mnt, dentry, timeout, do_now))
> > + return dentry;
> > + /*
> > +* Case 3: pseudo direct mount, expire individual leaves
> > +* (autofs-4.1).
> > +*/
>
> I recommend removing one of the tab stops on this since it relates to
> the else case but feels like it's "attached" to the code above the else.
The auto-reindent feature of emacs put it there and I didn't double check.
I've fix it.
>
> > + } else {
> > + /* Path walk currently on this dentry? */
> > + struct dentry *expired;
> > + ino_count = atomic_read(>count) + 1;
> > + if (d_count(dentry) > ino_count)
> > + return NULL;
> > +
> > + expired = autofs4_check_leaves(mnt, dentry, timeout, do_now);
> > + if (expired) {
> > + if (expired == dentry)
> > + dput(dentry);
> > + return dentry;
>
> Umm .. I think this should be "return expired".
Yes, of course it should. Fixed.
>
> Otherwise this looks like a straight refactor.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c
On Wed, Jul 16, 2014 at 21:17:32 +0200, Dietmar Eggemann wrote: Could you please share: cat /proc/cpuinfo and cat /proc/schedstat (kernel config w/ CONFIG_SCHEDSTATS=y) /proc/schedstat output is attached. version 15 timestamp 4294858660 cpu0 12 0 85767 30027 61826 37767 15709950719 5620241067 53904 domain0 0005 5408 5285 91 16777 39 2 1 5284 107 88 9 3926 11 0 0 88 23792 23076 349 87051 391 19 11 23065 3 0 3 0 0 0 0 0 0 18607 338 0 domain1 000f 4365 3913 399 64817 59 0 486 3427 59 50 3 1948 6 0 3 47 23422 21879 1368 206776 197 1 11697 10182 0 0 0 0 0 0 0 0 0 5434 164 0 cpu1 0 0 56596 21903 29921 13292 19364110947 8836735986 34640 domain0 000a 3239 3163 56 24775 27 6 0 3163 181 166 6 4460 9 1 0 166 20452 19845 272 90788 374 8 17 19828 4 0 4 0 0 0 0 0 0 10132 501 0 domain1 000f 2540 2279 207 69991 57 2 258 2021 99 90 2 2757 7 0 13 77 20103 19160 744 193572 228 4 5770 13390 1 1 0 0 0 0 0 0 0 6497 141 0 cpu2 120 0 58755 24874 18071 6797 16937128548 3947587861 33681 domain0 0005 2940 2811 105 39819 35 13 0 2811 158 141 4 8878 13 0 0 141 18795 18156 336 189651 339 7 10 18146 8 0 8 0 0 0 0 0 0 5062 206 0 domain1 000f 2376 1903 437 82849 40 1 216 1687 35 32 1 6881 2 0 6 26 18491 17419 885 260774 216 6 2076 15343 0 0 0 0 0 0 0 0 0 6212 130 0 cpu3 0 0 54095 22291 28164 13979 19759585558 3515338364 31766 domain0 000a 4642 4135 495 61645 15 4 0 4135 157 147 7 1546 3 0 0 147 20473 19444 670 114383 394 7 15 19429 3 0 3 0 0 0 0 0 0 9962 468 0 domain1 000f 3104 2629 431 71143 49 2 326 2303 82 76 4 495 2 0 9 67 20105 18739 1168 207093 223 4 5545 13194 0 0 0 0 0 0 0 0 0 4223 157 0
Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c
Could you also put the two BUG_ON lines into build_sched_groups() [kernel/sched/core.c] wo/ the cpumask_clear() and setting sg->sgc->capacity to 0 and share the possible crash output as well? I can try a new build with this. I can probably get results back tomorrow before I leave for work. The crashes happen too early in the boot process for me to easily capture output as text. I can slow things down to take pictures though. That would be helpful. Thanks. I saw that you have CONFIG_SCHED_DEBUG enabled. Well that didn't help much. It still crashed. Taking pictures didn't get a good capture. I wasn't able to use boot_delay to slow things down, as even a small value resulted in me only seeing one line of output before giving up after a minute or two. I used a serial console to slow things down, but it isn't enough to make it easy to take pictures with the camera I had. The crash was someplace inside the scheduler, but I don't know if there were messages from the BUG_ON lines. -- 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/
Issues with test builds
I am having issues with build tests. Seems arch/x86/Makefile:136: CONFIG_X86_X32 enabled but no binutils support is the culprit. I am new so how do I fix this. 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 v5 3/5] PCI: designware: enhance dw_pcie_host_init() to support v3.65 DW hardware
> -Original Message-
> From: Pratyush ANAND
> Sent: Thursday, July 17, 2014 9:07 AM
> To: Murali Karicheri
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; Santosh Shilimkar; Russell King; Grant Likely; Rob
> Herring; Mohit KUMAR DCG; Jingoo Han; Bjorn Helgaas; Richard Zhu; Kishon
> Vijay Abraham I; Marek Vasut; Arnd Bergmann; Pawel Moll; Mark Rutland;
> Ian Campbell; Kumar Gala; Randy Dunlap
> Subject: Re: [PATCH v5 3/5] PCI: designware: enhance dw_pcie_host_init()
> to support v3.65 DW hardware
>
> On Thu, Jul 17, 2014 at 12:38:04AM +0800, Murali Karicheri wrote:
> > keystone PCI controller is based on v3.65 designware hardware. This
> > version differs from newer versions of the hardware in few functional
> > areas discussed below that makes it necessary to change
> > dw_pcie_host_init() to support v3.65 based PCI controller.
> >
> > 1. No support for ATU port. So any ATU specific resource handling code
> > is to be bypassed for v3.65 h/w.
> > 2. MSI controller uses Application space to implement MSI and 32 MSI
> > interrupts are multiplexed over 8 IRQs to the host. Hence the code
> > to process MSI IRQ needs to be different. This patch allows platform
> > driver to provide its own irq_domain_ops ptr to irq_domain_add_linear()
> > through an API callback from the designware core driver.
> > 3. MSI interrupt generation requires EP to write to the RC's application
> > register. So enhance the driver to allow setup of inbound access to
> > MSI irq register as a post scan bus API callback.
> >
> > Signed-off-by: Murali Karicheri
>
> Looks almost ok to me.
>
> Reviewed-by: Pratyush Anand
>
- Now looks fine to me.
Acked-by: Mohit KUMAR
Jingoo,
After Murali's patches, dw code can be used by older Synopsys controller
based driver too.
Pls have a look at the series if you have any further comment.
Thanks
Mohit
> > int __init dw_pcie_host_init(struct pcie_port *pp) {
> > struct device_node *np = pp->dev->of_node;
> > - struct of_pci_range range;
> > struct of_pci_range_parser parser;
> > + struct of_pci_range range;
>
> You may avoid moving the above line.
>
> ~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: [PATCH 0/6] LLVMLinux: Patches to enable the kernel to be compiled with clang/LLVM
On 07/13/14 02:10, Nicolas Pitre wrote: On Tue, 8 Jul 2014, beh...@converseincode.com wrote: From: Behan Webster The LLVMLinux project aims to fully build the Linux kernel using both gcc and clang (the C front end for the LLVM compiler infrastructure project). Clang only supports global named registers for non-allocatable registers like the stack pointer. By centralizing the definition of current_stack_pointer, the use of named registers for ARM remains largely unchanged while working for both gcc and clang. You verified that the compiled code is identical on gcc? Yes. Identical. If so: Acked-by: Nicolas Pitre Thanks, Behan -- Behan Webster beh...@converseincode.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/
[PATCH] Staging: gdm724x: gdm_tty.c: fix missing blank line after variable declaration
Checkpatch fix - Add missing blank line after variable declaration
Signed-off-by: Kiran Padwal
---
drivers/staging/gdm724x/gdm_tty.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/staging/gdm724x/gdm_tty.c
b/drivers/staging/gdm724x/gdm_tty.c
index fe47cd3..001348c 100644
--- a/drivers/staging/gdm724x/gdm_tty.c
+++ b/drivers/staging/gdm724x/gdm_tty.c
@@ -111,24 +111,28 @@ static int gdm_tty_install(struct tty_driver *driver,
struct tty_struct *tty)
static int gdm_tty_open(struct tty_struct *tty, struct file *filp)
{
struct gdm *gdm = tty->driver_data;
+
return tty_port_open(>port, tty, filp);
}
static void gdm_tty_cleanup(struct tty_struct *tty)
{
struct gdm *gdm = tty->driver_data;
+
tty_port_put(>port);
}
static void gdm_tty_hangup(struct tty_struct *tty)
{
struct gdm *gdm = tty->driver_data;
+
tty_port_hangup(>port);
}
static void gdm_tty_close(struct tty_struct *tty, struct file *filp)
{
struct gdm *gdm = tty->driver_data;
+
tty_port_close(>port, tty, filp);
}
@@ -139,6 +143,7 @@ static int gdm_tty_recv_complete(void *data,
int complete)
{
struct gdm *gdm = tty_dev->gdm[index];
+
if (!GDM_TTY_READY(gdm)) {
if (complete == RECV_PACKET_PROCESS_COMPLETE)
gdm_tty_recv(gdm, gdm_tty_recv_complete);
--
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/
[PATCH] Staging: gdm724x: gdm_lte.c: fix missing blank line after variable declaration
Checkpatch fix - Add missing blank line after variable declaration
Signed-off-by: Kiran Padwal
---
drivers/staging/gdm724x/gdm_lte.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/gdm724x/gdm_lte.c
b/drivers/staging/gdm724x/gdm_lte.c
index 64c55b9..bc6d574 100644
--- a/drivers/staging/gdm724x/gdm_lte.c
+++ b/drivers/staging/gdm724x/gdm_lte.c
@@ -447,6 +447,7 @@ static int gdm_lte_tx(struct sk_buff *skb, struct
net_device *dev)
*/
if (nic_type & NIC_TYPE_F_VLAN) {
struct vlan_ethhdr *vlan_eth = (struct vlan_ethhdr *)skb->data;
+
nic->vlan_id = ntohs(vlan_eth->h_vlan_TCI) & VLAN_VID_MASK;
data_buf = skb->data + (VLAN_ETH_HLEN - ETH_HLEN);
data_len = skb->len - (VLAN_ETH_HLEN - ETH_HLEN);
@@ -505,6 +506,7 @@ static int gdm_lte_tx(struct sk_buff *skb, struct
net_device *dev)
static struct net_device_stats *gdm_lte_stats(struct net_device *dev)
{
struct nic *nic = netdev_priv(dev);
+
return >stats;
}
--
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: [PATCH RFC tip/core/rcu 1/2] rcu: Rationalize kthread spawning
On 07/16/2014 10:57 PM, Sasha Levin wrote: > On 07/14/2014 06:06 AM, Paul E. McKenney wrote: >> From: "Paul E. McKenney" >> >> Currently, RCU spawns kthreads from several different early_initcall() >> functions. Although this has served RCU well for quite some time, >> as more kthreads are added a more deterministic approach is required. >> This commit therefore causes all of RCU's early-boot kthreads to be >> spawned from a single early_initcall() function. >> >> Signed-off-by: Paul E. McKenney > > Hey Paul, > > I've updated to today's -next and my VM started hanging on boot. Bisect > pointed out this patch. > > I don't have any further info right now, but can provide whatever you'll > find useful. Hi Sasha, Could you attach the config file which is failing for a start? Thanks, -- Pranith > > > Thanks, > Sasha > -- 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] mm, writeback: prevent race when calculating dirty limits
On Wed, Jul 16, 2014 at 05:36:49PM -0700, David Rientjes wrote: > Setting vm_dirty_bytes and dirty_background_bytes is not protected by any > serialization. > > Therefore, it's possible for either variable to change value after the > test in global_dirty_limits() to determine whether available_memory needs > to be initialized or not. > > Always ensure that available_memory is properly initialized. > > Cc: sta...@vger.kernel.org > Signed-off-by: David Rientjes Any such race should be barely noticable to the user, so I assume you realized this while looking at the code? The patch looks good, but I don't see that it's stable material. Acked-by: Johannes Weiner -- 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 v2] r8169: Enable RX_MULTI_EN for RTL_GIGA_MAC_VER_40
The ethernet port on my ASUS A88X Pro mainboard stopped working
several times a day, with messages like these in dmesg:
AMD-Vi: Event logged [IO_PAGE_FAULT device=05:00.0 domain=0x001e
address=0x3000 flags=0x0050]
Searching the web for these messages led me to similar reports about
different hardware supported by r8169, and eventually to commits
3ced8c955e74d319f3e3997f7169c79d524dfd06 ('r8169: enforce RX_MULTI_EN
for the 8168f.') and eb2dc35d99028b698cdedba4f5522bc43e576bd2 ('r8169:
RxConfig hack for the 8168evl'). So I tried this change, and it fixes
the problem for me.
Signed-off-by: Michel Dänzer
---
v2: Updated commit log, how about this?
drivers/net/ethernet/realtek/r8169.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index 06bdc31..61623e9 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4240,6 +4240,8 @@ static void rtl_init_rxcfg(struct rtl8169_private *tp)
RTL_W32(RxConfig, RX128_INT_EN | RX_MULTI_EN | RX_DMA_BURST);
break;
case RTL_GIGA_MAC_VER_40:
+ RTL_W32(RxConfig, RX128_INT_EN | RX_MULTI_EN | RX_DMA_BURST |
RX_EARLY_OFF);
+ break;
case RTL_GIGA_MAC_VER_41:
case RTL_GIGA_MAC_VER_42:
case RTL_GIGA_MAC_VER_43:
--
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/
Re: [PATCH 3/6] samples: use uapiprogs support for seccomp
On Wed, 16 Jul 2014 12:31:21 +0200 Sam Ravnborg wrote: > > How can I build hostprogs for the same host as the kernel? > > (I mean, how can I override $(HOSTCC) for cross-compiling ?) > > One way to do this: > > make ARCH=sparc CROSS_COMPILE=sparc-leon-linux-gnu- > HOSTCC=sparc-leon-linux-gnu-gcc > > Notice that I override HOSTCC as part of the make comand line. > This allows me to override the "=" assignment in the top-level Makefile. > > But then my build breaks as fixdep do not run on my host. > > If you in general want to build a binary for the target then uapiprogs come > in handy. > Only caveat here is that you will be using the exported kernel headers. > Thanks for explaining this. It is clearer to me now. At first I thought this patch was a clean-up, but it is indeed a big improvement. Thanks! Best Regards Masahiro Yamada -- 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] Staging: gdm724x: fix missing blank line after variable declaration
Hi, On Thu, Jul 17, 2014 at 2:00 AM, Greg KH wrote: > On Wed, Jul 16, 2014 at 04:55:23PM +0530, Kiran Padwal wrote: >> From: Kiran Padwal >> >> Checkpatch fix - Add missing blank line after variable declaration >> >> Signed-off-by:Kiran Padwal > > Minor nit, you need a ' ' after the ':'. > > Also, you sent me two different patches, with the same Subject: line. > So I can't apply either of them, sorry. Please resend both of them with > better subject lines (hint, put the filename in the subject: that would > fix this...) Thanks, I will resend it. > > 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/
Re: linux-next: Tree for Jul 16
On Wed, Jul 16, 2014 at 11:14 PM, Stephen Rothwell wrote: > Hi Nick, > > On Wed, 16 Jul 2014 22:01:35 -0400 Nick Krause wrote: >> >> Absolutely , I am using the latest kernel rc from git. I am using gcc >> 4.8.3 and binutils 2.83.91. > > Then that has nothing to do with me ... I am the linux-next > maintainer. I just happen to use the same build test system as is also > used to test Linus' tree (kisskb). I hope you are looking at the right > result pages for what you are testing. The URL I gave you was for the > linux-next builds, not Linus' tree. > >> In addition I am using the default configurations as you are in less >> I am doing it differently. >> By the way xtensa-defconfig seems to fail because of binutils as I >> discussed this with >> the maintainers and they seemed to have tested it with a newer upstream >> binutils >> then I am using and it succeeded it the linking failures I am seeing with it. > > Maybe we need per architecture minimum tools versions (instead of > current global one). > > -- > Cheers, > Stephen Rothwells...@canb.auug.org.au That seems like a good idea. I am also curious if when there is a build failure in the mainline kernel if we can mail the logs to the maintainers of that arch as if we do it seems to get resolved much faster, usually in a day or two, 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 v5 3/5] PCI: designware: enhance dw_pcie_host_init() to support v3.65 DW hardware
On Thu, Jul 17, 2014 at 12:38:04AM +0800, Murali Karicheri wrote:
> keystone PCI controller is based on v3.65 designware hardware. This
> version differs from newer versions of the hardware in few functional
> areas discussed below that makes it necessary to change dw_pcie_host_init()
> to support v3.65 based PCI controller.
>
> 1. No support for ATU port. So any ATU specific resource handling code
> is to be bypassed for v3.65 h/w.
> 2. MSI controller uses Application space to implement MSI and 32 MSI
> interrupts are multiplexed over 8 IRQs to the host. Hence the code
> to process MSI IRQ needs to be different. This patch allows platform
> driver to provide its own irq_domain_ops ptr to irq_domain_add_linear()
> through an API callback from the designware core driver.
> 3. MSI interrupt generation requires EP to write to the RC's application
> register. So enhance the driver to allow setup of inbound access to
> MSI irq register as a post scan bus API callback.
>
> Signed-off-by: Murali Karicheri
Looks almost ok to me.
Reviewed-by: Pratyush Anand
> int __init dw_pcie_host_init(struct pcie_port *pp)
> {
> struct device_node *np = pp->dev->of_node;
> - struct of_pci_range range;
> struct of_pci_range_parser parser;
> + struct of_pci_range range;
You may avoid moving the above line.
~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: [PATCH v5 2/5] PCI: designware: refactor MSI code to work with v3.65 dw hardware
On Thu, Jul 17, 2014 at 12:38:03AM +0800, Murali Karicheri wrote: > Keystone PCI controller is based on v3.65 version of the DW > PCI h/w that implements MSI controller registers in application > space compared to the newer version. This requires updates to > the DW core API to support the PCI controller driver based on > this old DW hardware. Add msi_irq_set()/clear() API functions to > allow Set/Clear MSI IRQ enable bit in the application register. > Also the old h/w uses MSI_IRQ register in application register > space to raise MSI IRQ to the RC from EP. Current code uses the > standard mechanism as per PCI spec. So add another API get_msi_data() > to get the address of this register so that common code can be > re-used on old h/w. > > Signed-off-by: Murali Karicheri > Acked-by: Mohit Kumar > Acked-by: Jingoo Han > Acked-by: Santosh Shilimkar > Reviewed-by: Pratyush Anand -- 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 v5 1/5] PCI: designware: add rd[wr]_other_conf API
On Thu, Jul 17, 2014 at 12:38:02AM +0800, Murali Karicheri wrote: > v3.65 version of the designware h/w, requires application space > registers to be configured to access the remote EP config space. > To support this, add rd[wr]_other_conf API in the pcie_host_opts > > Signed-off-by: Murali Karicheri > Acked-by: Mohit Kumar > Acked-by: Jingoo Han > Acked-by: Santosh Shilimkar > Reviewed-by: Pratyush Anand -- 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] r8169: Enable RX_MULTI_EN for RTL_GIGA_MAC_VER_40
From: Michel Dänzer Date: Thu, 17 Jul 2014 09:55:59 +0900 > On 17.07.2014 07:25, David Miller wrote: >> From: Francois Romieu >> Date: Tue, 15 Jul 2014 23:54:12 +0200 >> >>> Hayes Wang : Michel D?nzer [mailto:mic...@daenzer.net] >>> [...] > Without this, the ethernet port on my ASUS A88X Pro mainboard stops > working sometimes, with messages like these in dmesg: > > AMD-Vi: Event logged [IO_PAGE_FAULT device=05:00.0 > domain=0x001e address=0x3000 flags=0x0050] I search the information about your issue. It seems to be relative to the IOMMU. I don't sure if your patch is the root cause or a workaround. >>> >>> Btw, a few extra identifiers in rtl_init_rxcfg may improve consistency: >>> >>>missing | included >>> ---+--- >>> RTL_GIGA_MAC_VER_36 (8168f)| RTL_GIGA_MAC_VER_35 (8168f) >>> RTL_GIGA_MAC_VER_38 (RTL8411) | RTL_GIGA_MAC_VER_44 (RTL8411) >>> RTL_GIGA_MAC_VER_39 (RTL8106e) | RTL_GIGA_MAC_VER_43 (RTL8106e) >>> RTL_GIGA_MAC_VER_37 (RTL8402) | >> >> Michel please take Francois's feedback here into consideration and also >> provide a more detailed commit message so other people reading the commit >> can understand your reasoning for making this change, not just what the >> result might be for making it. > > I'm afraid I can't do that. I don't really understand any of this stuff, > I just googled the IOMMU event message, found similar patches for other > chipsets, and adapted them for my mainboard until the problem stopped. And if so, that's exactly what I want you to say in the commit message. -- 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 V2 3/3] virtio-net: rx busy polling support
On Thursday 17 July 2014 08:25 AM, Jason Wang wrote:
On 07/16/2014 04:38 PM, Varka Bhadram wrote:
On 07/16/2014 11:51 AM, Jason Wang wrote:
Add basic support for rx busy polling.
Test was done between a kvm guest and an external host. Two hosts were
connected through 40gb mlx4 cards. With both busy_poll and busy_read
are set to 50 in guest, 1 byte netperf tcp_rr shows 116% improvement:
transaction rate was increased from 9151.94 to 19787.37.
Cc: Rusty Russell
Cc: Michael S. Tsirkin
Cc: Vlad Yasevich
Cc: Eric Dumazet
Signed-off-by: Jason Wang
---
drivers/net/virtio_net.c | 190
++-
1 file changed, 187 insertions(+), 3 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index e417d93..4830713 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
static int napi_weight = NAPI_POLL_WEIGHT;
module_param(napi_weight, int, 0444);
@@ -94,8 +95,143 @@ struct receive_queue {
/* Name of this receive queue: input.$index */
char name[40];
+
+#ifdef CONFIG_NET_RX_BUSY_POLL
+unsigned int state;
+#define VIRTNET_RQ_STATE_IDLE0
+#define VIRTNET_RQ_STATE_NAPI 1/* NAPI or refill owns
this RQ */
+#define VIRTNET_RQ_STATE_POLL 2/* poll owns this RQ */
+#define VIRTNET_RQ_STATE_DISABLED4/* RQ is disabled */
+#define VIRTNET_RQ_OWNED (VIRTNET_RQ_STATE_NAPI |
VIRTNET_RQ_STATE_POLL)
+#define VIRTNET_RQ_LOCKED (VIRTNET_RQ_OWNED |
VIRTNET_RQ_STATE_DISABLED)
+#define VIRTNET_RQ_STATE_NAPI_YIELD 8/* NAPI or refill yielded
this RQ */
+#define VIRTNET_RQ_STATE_POLL_YIELD 16 /* poll yielded this RQ */
+spinlock_t lock;
+#endif /* CONFIG_NET_RX_BUSY_POLL */
};
+#ifdef CONFIG_NET_RX_BUSY_POLL
+static inline void virtnet_rq_init_lock(struct receive_queue *rq)
+{
+
+spin_lock_init(>lock);
+rq->state = VIRTNET_RQ_STATE_IDLE;
+}
+
+/* called from the device poll routine or refill routine to get
ownership of a
+ * receive queue.
+ */
+static inline bool virtnet_rq_lock_napi_refill(struct receive_queue
*rq)
+{
+int rc = true;
+
bool instead of int...?
Yes, it was better.
+spin_lock(>lock);
+if (rq->state & VIRTNET_RQ_LOCKED) {
+WARN_ON(rq->state & VIRTNET_RQ_STATE_NAPI);
+rq->state |= VIRTNET_RQ_STATE_NAPI_YIELD;
+rc = false;
+} else
+/* we don't care if someone yielded */
+rq->state = VIRTNET_RQ_STATE_NAPI;
+spin_unlock(>lock);
Lock for rq->state ...?
If yes:
spin_lock(>lock);
if (rq->state & VIRTNET_RQ_LOCKED) {
rq->state |= VIRTNET_RQ_STATE_NAPI_YIELD;
spin_unlock(>lock);
WARN_ON(rq->state & VIRTNET_RQ_STATE_NAPI);
rc = false;
} else {
/* we don't care if someone yielded */
rq->state = VIRTNET_RQ_STATE_NAPI;
spin_unlock(>lock);
}
I didn't see any differences. Is this used to catch the bug of driver
earlier? btw, several other rx busy polling capable driver does the same
thing.
We need not to include WARN_ON() & rc=false under critical section.
--
Regards,
Varka Bhadram
--
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/
Are You Looking For Financial Assistant
-- We give out all kinds of loans,If interested do contact us through email morganchris.multifina...@gmail.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 v2 1/3] ACPI: ARM64 does not have a BIOS add config for BIOS table scan.
On 2014-7-17 7:49, H. Peter Anvin wrote: > On 07/16/2014 04:46 PM, Luck, Tony wrote: >>> + select ACPI_LEGACY_TABLES_LOOKUP if ACPI >> >>> This shouldn't actually be set on IA64, should it? IA64 doesn't have >>> BIOS, either, it has EFI/UEFI, like ARM64... Yes, I agree with you, thanks for pointing this out. if I remember correctly, the EFI standard was introduced when IA64 came out. >> >> Which ACPI tables are in the "LEGACY" category affected by this option? >> > > That's not what this is about... it is about how you find the root pointer. > > On a BIOS system it is found by scanning low memory. On an EFI system > it is found by querying EFI for a specific UUID. Thanks for the explanation. Tony, if it is ok with you, I will modify the patch and will not select ACPI_LEGACY_TABLES_LOOKUP on IA64, I'm waiting for your final confirmation. Thanks Hanjun -- 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: Tree for Jul 16
Hi Nick, On Wed, 16 Jul 2014 22:01:35 -0400 Nick Krause wrote: > > Absolutely , I am using the latest kernel rc from git. I am using gcc > 4.8.3 and binutils 2.83.91. Then that has nothing to do with me ... I am the linux-next maintainer. I just happen to use the same build test system as is also used to test Linus' tree (kisskb). I hope you are looking at the right result pages for what you are testing. The URL I gave you was for the linux-next builds, not Linus' tree. > In addition I am using the default configurations as you are in less > I am doing it differently. > By the way xtensa-defconfig seems to fail because of binutils as I > discussed this with > the maintainers and they seemed to have tested it with a newer upstream > binutils > then I am using and it succeeded it the linking failures I am seeing with it. Maybe we need per architecture minimum tools versions (instead of current global one). -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c
On Thu, Jul 17, 2014 at 01:18:36 +0200, Dietmar Eggemann wrote: So the output of $ cat /proc/sys/kernel/sched_domain/cpu*/domain*/* would be handy too. Attached and added to the bug. Just to make sure, you do have 'CONFIG_X86_32=y' and '# CONFIG_NUMA is not set' in your build? Yes. I probably won't be able to get /proc/schedstat on my next test since the system will probably crash right away. However, I probably will have a much faster rebuild and might still be able to get the info for you before I leave tomorrow. 32 0 0 687 0 0 110 4 28353 2 SMT 0 0 32 2 1 4143 0 1 125 8 15370 4 DIE 0 0 32 0 0 687 0 0 110 4 21753 2 SMT 0 0 32 2 1 4143 0 1 125 8 12715 4 DIE 0 0 32 0 0 687 0 0 110 4 25097 2 SMT 0 0 32 2 1 4143 0 1 125 8 21624 4 DIE 0 0 32 0 0 687 0 0 110 4 23714 2 SMT 0 0 32 2 1 4143 0 1 125 8 14920 4 DIE 0 0
Re: [GIT] Networking
On Wed, Jul 16, 2014 at 4:18 PM, Kalle Valo wrote:
>
> Just out of curiosity, what is the best way to send a proposal how to
> fix a merge conflict? For example, if I send a pull request to John
> which I know will issue a conflict it would be nice to include
> instructions (or some sort of patch) how I think it should be resolved.
So from personal experience seeing lots of different explanations, my
preferred one is not so much a patch, as explaining *why* something
generates a merge conflict.
Optimally for each conflict, say what happened ("X changed Y, A
changed B close by") and then describe the result in those terms (eg
"pick the code from my branch, but then do the rename of xyz to abc
that caused the conflict", or "pick your side, it obsoletes the fix
from me that causes the conflict" or whatever).
And if you have a *lot* of conflicts, explain why that happaned too,
and think very hard about whether what you do is perhaps screwed up
(or complain about the other entity that did annoying whitespace
changes for no good reason or whatever). Maybe it's just that the
source code is badly organized, but more likely it's because somebody
is just doing something stupid, and people are stepping on each others
toes. If the explanation is "this is a one-time issue brought on by
xyz", then that's fine - sh*t happens. If it's something else, at
least mention it. And if it keeps happening, something needs to be
done.
And in the end, I personally tend to always resolve the conflicts
*without* really looking at the explanation, by just trying to figure
it out on my own. I've had people send me incorrect resolution
suggestions, and I've also occasionally just screwed up my own
resolution. Having somebody elses explanations of what they did is a
good sanity check that things went right (when their explanation
matches mine), and is a good red flag about "maybe this is more
complicated than I thought" when the explanations and results don't
match up.
Linus
--
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 0/4] dra7: Add PCIe support
On Monday, July 14, 2014 11:55 PM, Kishon Vijay Abraham I wrote: > > Changes from v1: > * fixed dw_pcie_prog_viewport_io_outbound() to use untranslated address > * split dra7xx patch into driver part and documentation part > > [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 pci -next. > > [1] -> https://lkml.org/lkml/2014/5/29/258 > > Kishon Vijay Abraham I (4): > PCI: designware: Configuration space should be specified in 'reg' > PCI: designware: use untranslated address while programming ATU > Documentation: pci: ti: Add dt binding documentation for PCIe in > DRA7xx > PCI: host: pcie-dra7xx: add support for pcie-dra7xx controller Kishon, Actually, I have no objections to these patches. Then, how about adding maintainer entry for pci-dra7xx.c to MAINTAINERS file? It would be good. :-) Best regards, Jingoo Han > > .../devicetree/bindings/pci/designware-pcie.txt|4 + > Documentation/devicetree/bindings/pci/ti-pci.txt | 59 +++ > drivers/pci/host/Kconfig | 10 + > drivers/pci/host/Makefile |1 + > drivers/pci/host/pci-dra7xx.c | 458 > > drivers/pci/host/pcie-designware.c | 72 ++- > drivers/pci/host/pcie-designware.h |4 + > 7 files changed, 592 insertions(+), 16 deletions(-) > create mode 100644 Documentation/devicetree/bindings/pci/ti-pci.txt > create mode 100644 drivers/pci/host/pci-dra7xx.c > > -- > 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: [PATCH RFC tip/core/rcu 1/2] rcu: Rationalize kthread spawning
On 07/14/2014 06:06 AM, Paul E. McKenney wrote: > From: "Paul E. McKenney" > > Currently, RCU spawns kthreads from several different early_initcall() > functions. Although this has served RCU well for quite some time, > as more kthreads are added a more deterministic approach is required. > This commit therefore causes all of RCU's early-boot kthreads to be > spawned from a single early_initcall() function. > > Signed-off-by: Paul E. McKenney Hey Paul, I've updated to today's -next and my VM started hanging on boot. Bisect pointed out this patch. I don't have any further info right now, but can provide whatever you'll find useful. Thanks, Sasha -- 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 V2 3/3] virtio-net: rx busy polling support
On 07/16/2014 04:38 PM, Varka Bhadram wrote:
> On 07/16/2014 11:51 AM, Jason Wang wrote:
>> Add basic support for rx busy polling.
>>
>> Test was done between a kvm guest and an external host. Two hosts were
>> connected through 40gb mlx4 cards. With both busy_poll and busy_read
>> are set to 50 in guest, 1 byte netperf tcp_rr shows 116% improvement:
>> transaction rate was increased from 9151.94 to 19787.37.
>>
>> Cc: Rusty Russell
>> Cc: Michael S. Tsirkin
>> Cc: Vlad Yasevich
>> Cc: Eric Dumazet
>> Signed-off-by: Jason Wang
>> ---
>> drivers/net/virtio_net.c | 190
>> ++-
>> 1 file changed, 187 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index e417d93..4830713 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -27,6 +27,7 @@
>> #include
>> #include
>> #include
>> +#include
>> static int napi_weight = NAPI_POLL_WEIGHT;
>> module_param(napi_weight, int, 0444);
>> @@ -94,8 +95,143 @@ struct receive_queue {
>> /* Name of this receive queue: input.$index */
>> char name[40];
>> +
>> +#ifdef CONFIG_NET_RX_BUSY_POLL
>> +unsigned int state;
>> +#define VIRTNET_RQ_STATE_IDLE0
>> +#define VIRTNET_RQ_STATE_NAPI 1/* NAPI or refill owns
>> this RQ */
>> +#define VIRTNET_RQ_STATE_POLL 2/* poll owns this RQ */
>> +#define VIRTNET_RQ_STATE_DISABLED4/* RQ is disabled */
>> +#define VIRTNET_RQ_OWNED (VIRTNET_RQ_STATE_NAPI |
>> VIRTNET_RQ_STATE_POLL)
>> +#define VIRTNET_RQ_LOCKED (VIRTNET_RQ_OWNED |
>> VIRTNET_RQ_STATE_DISABLED)
>> +#define VIRTNET_RQ_STATE_NAPI_YIELD 8/* NAPI or refill yielded
>> this RQ */
>> +#define VIRTNET_RQ_STATE_POLL_YIELD 16 /* poll yielded this RQ */
>> +spinlock_t lock;
>> +#endif /* CONFIG_NET_RX_BUSY_POLL */
>> };
>> +#ifdef CONFIG_NET_RX_BUSY_POLL
>> +static inline void virtnet_rq_init_lock(struct receive_queue *rq)
>> +{
>> +
>> +spin_lock_init(>lock);
>> +rq->state = VIRTNET_RQ_STATE_IDLE;
>> +}
>> +
>> +/* called from the device poll routine or refill routine to get
>> ownership of a
>> + * receive queue.
>> + */
>> +static inline bool virtnet_rq_lock_napi_refill(struct receive_queue
>> *rq)
>> +{
>> +int rc = true;
>> +
>
> bool instead of int...?
Yes, it was better.
>
>> +spin_lock(>lock);
>> +if (rq->state & VIRTNET_RQ_LOCKED) {
>> +WARN_ON(rq->state & VIRTNET_RQ_STATE_NAPI);
>> +rq->state |= VIRTNET_RQ_STATE_NAPI_YIELD;
>> +rc = false;
>> +} else
>> +/* we don't care if someone yielded */
>> +rq->state = VIRTNET_RQ_STATE_NAPI;
>> +spin_unlock(>lock);
>
> Lock for rq->state ...?
>
> If yes:
> spin_lock(>lock);
> if (rq->state & VIRTNET_RQ_LOCKED) {
> rq->state |= VIRTNET_RQ_STATE_NAPI_YIELD;
> spin_unlock(>lock);
> WARN_ON(rq->state & VIRTNET_RQ_STATE_NAPI);
> rc = false;
> } else {
> /* we don't care if someone yielded */
> rq->state = VIRTNET_RQ_STATE_NAPI;
> spin_unlock(>lock);
> }
I didn't see any differences. Is this used to catch the bug of driver
earlier? btw, several other rx busy polling capable driver does the same
thing.
--
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: Checkpatch Feature Idea: Search directory for files with errors and warnings with -d argument
On 07/16/2014 12:59 AM, Nick Krause wrote:
> On Wed, Jul 16, 2014 at 12:39 AM, Joe Perches wrote:
>> > On Wed, 2014-07-16 at 00:28 -0400, Nick Krause wrote:
>>> >> I am cleaning up the kernel as it needs a lot of cleanup.
>> >
>> > Needs are curious things.
>> >
>> > Consistency is a nicety not really a need.
>> >
>> > Bugs need fixing. Defects need eliminating.
>> > Enhancements are appreciated. Inconsistent
>> > code style is a minor annoyance.
>> >
>> > I suggest you focus on the bugs, defects or
>> > enhancements in performance or testing.
>> >
>> > Are you really cross-compiling the patches you
>> > submit here or do you have an alpha on your desk?
>> >
>> >
> I am cross compiling then. I don't have the hardware :(.
Are you sure you're actually cross compiling them? From your
recent patchset it doesn't seem you even bother to do that:
diff --git a/arch/alpha/boot/misc.c b/arch/alpha/boot/misc.c
index 174b7c6..886e469 100644
--- a/arch/alpha/boot/misc.c
+++ b/arch/alpha/boot/misc.c
@@ -23,7 +23,7 @@
#include
-#define memzero (s, n) memset((s), 0 , (n))
+#define memzero { (s, n) memset((s), 0 , (n)) }
#define puts srm_printk
extern long srm_printk(const char *, ...)
__attribute__ ((format (printf, 1, 2)));
@@ -61,8 +61,8 @@ static unsigned outcnt; /* bytes in output
buffer */
/* Diagnostic functions */
#ifdef DEBUG
-# define Assert (cond, msg) {if (!(cond)) error(msg) ; }
-# define Trace(x) fprintf x
+# define Assert { (cond, msg) {if (!(cond)) error(msg) ; } }
+# define Trace { (x) fprintf x }
# define Tracev(x) {if (verbose) fprintf x ; }
# define Tracevv(x) {if (verbose > 1) fprintf x ; }
# define Tracec(c, x) {if (verbose && (c)) fprintf x ; }
Or:
diff --git a/arch/alpha/boot/misc.c b/arch/alpha/boot/misc.c
index 886e469..56c3325 100644
--- a/arch/alpha/boot/misc.c
+++ b/arch/alpha/boot/misc.c
@@ -144,7 +144,7 @@ static void error(char *x)
puts(x);
puts("\n\n -- System halted");
- while (1);
+ while{ (1); }
/* Halt */
}
Thanks,
Sasha
--
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] arch/score/include/uapi/asm/ptrace.h: Remove the macros which not be used currently
Yes, you might miss something. Some patches were merged once I acknowledged them,and some were missed. So I am not sure the rule, if someone will merge these patches once them are acknowledged, it is redundant that I issue a PULL request again. 2014-07-17 10:30 GMT+08:00 Guenter Roeck : > On 07/16/2014 07:14 PM, Lennox Wu wrote: >> >> Actually, I don't know the rule for merging patches. Some patches will >> be merge,and some will be miss. If the patch is missed, we will merge >> it into our git. >> > Unless I am missing something, this patch is in arch/score, so the > expectation would be for you to pick it up and send it to Linus. > > Guenter > > >> Best, >> Lennox >> >> 2014-07-17 9:49 GMT+08:00 David Rientjes : >>> >>> On Thu, 26 Jun 2014, David Rientjes wrote: >>> On Thu, 26 Jun 2014, Chen Gang wrote: > 'COUNTER' and other same kind macros are too common to use, and easy to > get conflict with other modules. > > At present, they are not used, so it is OK to simply remove them. And > the > related warning (allmodconfig with score): > > CC [M] drivers/md/raid1.o >In file included from drivers/md/raid1.c:42:0: >drivers/md/bitmap.h:93:0: warning: "COUNTER" redefined > #define COUNTER(x) (((bitmap_counter_t) x) & COUNTER_MAX) > ^ >In file included from ./arch/score/include/asm/ptrace.h:4:0, > from include/linux/sched.h:31, > from include/linux/blkdev.h:4, > from drivers/md/raid1.c:36: >./arch/score/include/uapi/asm/ptrace.h:13:0: note: this is the > location of the previous definition > #define COUNTER 38 > > > Signed-off-by: Chen Gang Acked-by: David Rientjes >>> >>> Lennox or Liqin, could you please queue this patch for 3.17? >> >> >> > -- 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 4/4] PCI: host: pcie-dra7xx: add support for pcie-dra7xx controller
On Monday, July 14, 2014 11:55 PM, Kishon Vijay Abraham I wrote:
>
> Added support for pcie controller in dra7xx. This driver re-uses
> the designware core code that is already present in kernel.
>
> Cc: Jason Gunthorpe
> Cc: Bjorn Helgaas
> Cc: Mohit Kumar
> Cc: Jingoo Han
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> Cc: Marek Vasut
> Cc: Arnd Bergmann
> Signed-off-by: Kishon Vijay Abraham I
> ---
> drivers/pci/host/Kconfig | 10 +
> drivers/pci/host/Makefile |1 +
> drivers/pci/host/pci-dra7xx.c | 458
> +
> 3 files changed, 469 insertions(+)
> create mode 100644 drivers/pci/host/pci-dra7xx.c
>
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 21df477..22117b0 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -1,6 +1,16 @@
> menu "PCI host controller drivers"
> depends on PCI
>
> +config PCI_DRA7XX
> + bool "TI DRA7xx PCIe controller"
> + select PCIE_DW
> + depends on OF && HAS_IOMEM && TI_PIPE3
> + help
> + Enables support for the PCIE controller present in DRA7xx SoC. There
> + are two instances of PCIE controller in DRA7xx. This controller can
> + act both as EP and RC. This reuses the same Designware core as used
> + by other SoCs.
> +
> config PCI_MVEBU
> bool "Marvell EBU PCIe controller"
> depends on ARCH_MVEBU || ARCH_DOVE || ARCH_KIRKWOOD
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 611ba4b..c42844d 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -1,4 +1,5 @@
> obj-$(CONFIG_PCIE_DW) += pcie-designware.o
> +obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
> obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
> obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
> obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> new file mode 100644
> index 000..52b34fe
> --- /dev/null
> +++ b/drivers/pci/host/pci-dra7xx.c
> @@ -0,0 +1,458 @@
> +/*
> + * pcie-dra7xx - PCIe controller driver for TI DRA7xx SoCs
> + *
> + * Copyright (C) 2013-2014 Texas Instruments Incorporated - http://www.ti.com
> + *
> + * Authors: Kishon Vijay Abraham I
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "pcie-designware.h"
> +
> +/* PCIe controller wrapper DRA7XX configuration registers */
> +
> +#define PCIECTRL_DRA7XX_CONF_IRQSTATUS_MAIN 0x0024
> +#define PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MAIN 0x0028
> +#define ERR_SYS BIT(0)
> +#define ERR_FATAL BIT(1)
> +#define ERR_NONFATALBIT(2)
> +#define ERR_COR BIT(3)
> +#define ERR_AXI BIT(4)
> +#define ERR_ECRCBIT(5)
> +#define PME_TURN_OFFBIT(8)
> +#define PME_TO_ACK BIT(9)
> +#define PM_PME BIT(10)
> +#define LINK_REQ_RSTBIT(11)
> +#define LINK_UP_EVT BIT(12)
> +#define CFG_BME_EVT BIT(13)
> +#define CFG_MSE_EVT BIT(14)
> +#define INTERRUPTS (ERR_SYS | ERR_FATAL | ERR_NONFATAL | ERR_COR |
> ERR_AXI | \
> + ERR_ECRC | PME_TURN_OFF | PME_TO_ACK | PM_PME | \
> + LINK_REQ_RST | LINK_UP_EVT | CFG_BME_EVT | CFG_MSE_EVT)
> +
> +#define PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI 0x0034
> +#define PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MSI 0x0038
> +#define INTABIT(0)
> +#define INTBBIT(1)
> +#define INTCBIT(2)
> +#define INTDBIT(3)
> +#define MSI BIT(4)
> +#define LEG_EP_INTERRUPTS (INTA | INTB | INTC | INTD)
> +
> +#define PCIECTRL_DRA7XX_CONF_DEVICE_CMD 0x0104
> +#define LTSSM_EN0x1
> +
> +#define PCIECTRL_DRA7XX_CONF_PHY_CS 0x010C
> +#define LINK_UP BIT(16)
> +
> +struct dra7xx_pcie {
> + void __iomem*base;
> + struct
Re: [PATCH 2/2] staging: comedi: addi_apci_1564: use addi_watchdog module to init watchdog subdevice
On Tue, Jul 15, 2014 at 5:14 AM, Ian Abbott wrote: > On 2014-07-15 05:00, Chase Southwood wrote: >> >> On Mon, Jul 14, 2014 at 4:22 AM, Ian Abbott wrote: >>> >>> On 2014-07-12 23:44, Chase Southwood wrote: Use the addi_watchdog module to provide support for the watchdog subdevice. Also, rearrange the subdevice init blocks so that the order makes sense. Digital input/output subdevices and subdevices for DI/DO interrupt support, followed by timer/counter/watchdog subdevices is the new order. Signed-off-by: Chase Southwood Cc: Ian Abbott Cc: H Hartley Sweeten --- drivers/staging/comedi/drivers/addi_apci_1564.c | 34 +++-- 1 file changed, 20 insertions(+), 14 deletions(-) >>> >>> >>> >>> I don't think the subdevice order matters that much, and I prefer to keep >>> them stable, but since this driver is in such a state of flux, it doesn't >>> really matter. >>> >> >> Hi Ian! >> Quick question here about this. First off, duly noted that grouping >> subdevices by function isn't necessary and I won't shuffle them around >> like this in the future. Second, the reason I stuck the watchdog at >> the end is because it causes an early return if addi_watchdog_init() >> returns an error and it seemed appropriate at the end so it doesn't >> prevent the initialization of any other subdevices if that call should >> fail. Now I realize that it is very unlikely that that call fails, >> but in any case should I put future subdevice inits above the watchdog >> for the same reason (so they aren't at risk of not getting >> initialized), or does that count for subdevice order not being stable >> and you would prefer them all to go at the end? > > > Since you return an error from the auto_attach handler > apci1564_auto_attach() when addi_watchdog_init() fails, it makes little > difference what order the subdevices are initialized in. The error from > auto_attach handler causes the comedi core to call the detach handler > apci1564_detach() and tear everything down. Ultimately, > comedi_pci_auto_attach() will return an error back to the PCI probe function > apci1564_pci_probe(), which will propagate it to the PCI subsystem. > > In general, if adding a new subdevice, either add it to the end or replace > an "unused" subdevice. > Oh excellent. Perfect, that makes sense. Thanks for taking the time to explain, I'll make sure everything goes at the end from now on. Thanks, Chase > > -- > -=( Ian Abbott @ MEV Ltd.E-mail: )=- > -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- -- 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] arch/score/include/uapi/asm/ptrace.h: Remove the macros which not be used currently
On 07/16/2014 07:14 PM, Lennox Wu wrote: Actually, I don't know the rule for merging patches. Some patches will be merge,and some will be miss. If the patch is missed, we will merge it into our git. Unless I am missing something, this patch is in arch/score, so the expectation would be for you to pick it up and send it to Linus. Guenter Best, Lennox 2014-07-17 9:49 GMT+08:00 David Rientjes : On Thu, 26 Jun 2014, David Rientjes wrote: On Thu, 26 Jun 2014, Chen Gang wrote: 'COUNTER' and other same kind macros are too common to use, and easy to get conflict with other modules. At present, they are not used, so it is OK to simply remove them. And the related warning (allmodconfig with score): CC [M] drivers/md/raid1.o In file included from drivers/md/raid1.c:42:0: drivers/md/bitmap.h:93:0: warning: "COUNTER" redefined #define COUNTER(x) (((bitmap_counter_t) x) & COUNTER_MAX) ^ In file included from ./arch/score/include/asm/ptrace.h:4:0, from include/linux/sched.h:31, from include/linux/blkdev.h:4, from drivers/md/raid1.c:36: ./arch/score/include/uapi/asm/ptrace.h:13:0: note: this is the location of the previous definition #define COUNTER 38 Signed-off-by: Chen Gang Acked-by: David Rientjes Lennox or Liqin, could you please queue this patch for 3.17? -- 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/
Sparc: Fix Mes in highmem.c
I am hitting three Fix mes in this file and am wondering as the maintainer how you would like to clean them up. 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] arch: score: Export necessary symbols in related files
Acked-by: Lennox Wu 2014-07-09 16:48 GMT+08:00 Chen Gang : > 'csum_partial_copy_from_user' and 'flush_dcache_page' are also needed by > outside modules, so need export them in the related files. > > The related error (with allmodconfig under score): > > MODPOST 1365 modules > ERROR: "csum_partial_copy_from_user" [net/rxrpc/af-rxrpc.ko] undefined! > ERROR: "flush_dcache_page" [net/sunrpc/sunrpc.ko] undefined! > > > Signed-off-by: Chen Gang > --- > arch/score/lib/checksum_copy.c | 1 + > arch/score/mm/cache.c | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/arch/score/lib/checksum_copy.c b/arch/score/lib/checksum_copy.c > index 04565dd..9b770b3 100644 > --- a/arch/score/lib/checksum_copy.c > +++ b/arch/score/lib/checksum_copy.c > @@ -50,3 +50,4 @@ unsigned int csum_partial_copy_from_user(const char *src, > char *dst, > > return csum_partial(dst, len, sum); > } > +EXPORT_SYMBOL(csum_partial_copy_from_user); > diff --git a/arch/score/mm/cache.c b/arch/score/mm/cache.c > index f85ec1a..be91041 100644 > --- a/arch/score/mm/cache.c > +++ b/arch/score/mm/cache.c > @@ -72,6 +72,7 @@ void flush_dcache_page(struct page *page) > addr = (unsigned long) page_address(page); > flush_data_cache_page(addr); > } > +EXPORT_SYMBOL(flush_dcache_page); > > /* called by update_mmu_cache. */ > void __update_cache(struct vm_area_struct *vma, unsigned long address, > -- > 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 2/3] rcu: Remove stale comment in tree.c
On 07/16/2014 10:14 PM, Josh Triplett wrote:
> On Wed, Jul 16, 2014 at 09:01:52PM -0400, Pranith Kumar wrote:
>> Sure, please find an updated patch with Josh Triplett's sign-off added:
>
> It appears to have a reviewed-by from someone named "Joe Tripplett"
> instead. ;)
>
I apologize for fat-fingering this.
Since I've sent one too many emails in this thread already, I suppose on more
can not do much harm :)
This time with Reviewed-by Lai Jiangshan added and Reviewed-by Josh Triplett
corrected.
From: Pranith Kumar
Date: Mon, 14 Jul 2014 16:01:05 -0400
Subject: [PATCH 2/3] rcu: Remove stale comment in tree.c
This commit removes a stale comment in rcu/tree.c which was left out when some
code was moved around previously in the commit
2036d94a7b61 ("rcu: Rework detection of use of RCU by offline CPUs")
For reference, the following updated comment exists a few lines below this which
means the same.
/* Remove the outgoing CPU from the masks in the rcu_node hierarchy. */
Signed-off-by: Pranith Kumar
Reviewed-by: Josh Triplett
Reviewed-by: Lai Jiangshan
---
kernel/rcu/tree.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index a1abaa8..e67246e 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2211,8 +2211,6 @@ static void rcu_cleanup_dead_cpu(int cpu, struct
rcu_state *rsp)
/* Adjust any no-longer-needed kthreads. */
rcu_boost_kthread_setaffinity(rnp, -1);
- /* Remove the dead CPU from the bitmasks in the rcu_node hierarchy. */
-
/* Exclude any attempts to start a new grace period. */
mutex_lock(>onoff_mutex);
raw_spin_lock_irqsave(>orphan_lock, flags);
--
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/
Re: [GIT] Networking
"John W. Linville" writes: > On Tue, Jul 15, 2014 at 11:46:14AM -0700, David Miller wrote: >> From: Linus Torvalds >> Date: Tue, 15 Jul 2014 08:52:33 -0700 >> >> > And if David actually asks for these, my apologies.. >> >> I didn't ask for these :-) > > Just trying to be helpful, for those times when there are non-trivial > merge conflicts. I can stop. Just out of curiosity, what is the best way to send a proposal how to fix a merge conflict? For example, if I send a pull request to John which I know will issue a conflict it would be nice to include instructions (or some sort of patch) how I think it should be resolved. -- Kalle Valo -- 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] arch/score/include/uapi/asm/ptrace.h: Remove the macros which not be used currently
Actually, I don't know the rule for merging patches. Some patches will be merge,and some will be miss. If the patch is missed, we will merge it into our git. Best, Lennox 2014-07-17 9:49 GMT+08:00 David Rientjes : > On Thu, 26 Jun 2014, David Rientjes wrote: > >> On Thu, 26 Jun 2014, Chen Gang wrote: >> >> > 'COUNTER' and other same kind macros are too common to use, and easy to >> > get conflict with other modules. >> > >> > At present, they are not used, so it is OK to simply remove them. And the >> > related warning (allmodconfig with score): >> > >> > CC [M] drivers/md/raid1.o >> > In file included from drivers/md/raid1.c:42:0: >> > drivers/md/bitmap.h:93:0: warning: "COUNTER" redefined >> >#define COUNTER(x) (((bitmap_counter_t) x) & COUNTER_MAX) >> >^ >> > In file included from ./arch/score/include/asm/ptrace.h:4:0, >> >from include/linux/sched.h:31, >> >from include/linux/blkdev.h:4, >> >from drivers/md/raid1.c:36: >> > ./arch/score/include/uapi/asm/ptrace.h:13:0: note: this is the location >> > of the previous definition >> >#define COUNTER 38 >> > >> > >> > Signed-off-by: Chen Gang >> >> Acked-by: David Rientjes >> > > Lennox or Liqin, could you please queue this patch for 3.17? -- 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] rcu: Remove stale comment in tree.c
On Wed, Jul 16, 2014 at 09:01:52PM -0400, Pranith Kumar wrote: > Sure, please find an updated patch with Josh Triplett's sign-off added: It appears to have a reviewed-by from someone named "Joe Tripplett" instead. ;) > From: Pranith Kumar > Date: Mon, 14 Jul 2014 16:01:05 -0400 > Subject: [PATCH 2/3] rcu: Remove stale comment in tree.c > > > This commit removes a stale comment in rcu/tree.c which was left out in > commit 2036d94a7b61ca5032ce (rcu: Rework detection of use of RCU by offline > CPUs) > > For reference, the following updated comment exists a few lines below this > which > means the same. > > /* Remove the outgoing CPU from the masks in the rcu_node hierarchy. */ > > Signed-off-by: Pranith Kumar > Reviewed-by: Joe Tripplett > --- > kernel/rcu/tree.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > index a1abaa8..e67246e 100644 > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -2211,8 +2211,6 @@ static void rcu_cleanup_dead_cpu(int cpu, struct > rcu_state *rsp) > /* Adjust any no-longer-needed kthreads. */ > rcu_boost_kthread_setaffinity(rnp, -1); > > - /* Remove the dead CPU from the bitmasks in the rcu_node hierarchy. */ > - > /* Exclude any attempts to start a new grace period. */ > mutex_lock(>onoff_mutex); > raw_spin_lock_irqsave(>orphan_lock, flags); > -- > 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/
[PATCH] m68k: Remove unneeded FIXME message in sun3_pgalloc.h
This removes a FIX ME message due to this file not compiling. Now that this message is no longer needed I am removing it from sun3_pgalloc.h. Signed-off-by: Nicholas Krause --- arch/m68k/include/asm/sun3_pgalloc.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/m68k/include/asm/sun3_pgalloc.h b/arch/m68k/include/asm/sun3_pgalloc.h index f868506..66644f3 100644 --- a/arch/m68k/include/asm/sun3_pgalloc.h +++ b/arch/m68k/include/asm/sun3_pgalloc.h @@ -12,8 +12,6 @@ #include -/* FIXME - when we get this compiling */ -/* erm, now that it's compiling, what do we do with it? */ #define _KERNPG_TABLE 0 extern const char bad_pmd_string[]; -- 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/
linux-next: manual merge of the samsung tree with the arm-soc tree
Hi Kukjin,
Today's linux-next merge of the samsung tree got conflicts in
arch/arm/mach-s5pv210/dev-audio.c,
arch/arm/mach-s5pv210/include/mach/gpio-samsung.h,
arch/arm/mach-s5pv210/mach-aquila.c, arch/arm/mach-s5pv210/mach-goni.c,
arch/arm/mach-s5pv210/mach-smdkv210.c,
arch/arm/mach-s5pv210/setup-fb-24bpp.c,
arch/arm/mach-s5pv210/setup-fimc.c, arch/arm/mach-s5pv210/setup-i2c0.c,
arch/arm/mach-s5pv210/setup-i2c1.c, arch/arm/mach-s5pv210/setup-i2c2.c,
arch/arm/mach-s5pv210/setup-ide.c,
arch/arm/mach-s5pv210/setup-keypad.c,
arch/arm/mach-s5pv210/setup-sdhci-gpio.c,
arch/arm/mach-s5pv210/setup-spi.c and
arch/arm/plat-samsung/s5p-irq-eint.c between commit 2fd48f94426d ("ARM:
mach-s5p: get rid of all headers") from the arm-soc tree
and commits 36278bb98dc7 ("ARM: S5PV210: Remove support for board
files") and 2722091e711f ("ARM: SAMSUNG: Remove remaining legacy code")
from the samsung tree.
I fixed it up (I just removed the files removed by the latter commits)
and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
linux-next: manual merge of the samsung tree with the arm-soc tree
Hi Kukjin,
Today's linux-next merge of the samsung tree got a conflict in
arch/arm/plat-samsung/Kconfig between commit ab275b132a79 ("ARM: s5p:
cut the custom ARCH_NR_GPIOS definition") from the arm-soc tree and
commit 2722091e711f ("ARM: SAMSUNG: Remove remaining legacy code") from
the samsung tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/plat-samsung/Kconfig
index 6910c8669742,1091b0a3729a..
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@@ -65,48 -51,22 +51,6 @@@ config SAMSUNG_ATAG
if SAMSUNG_ATAGS
- # clock options
-
- config SAMSUNG_CLOCK
- bool
- default y if !COMMON_CLK
-
- config SAMSUNG_CLKSRC
- bool
- help
- Select the clock code for the clksrc implementation
- used by newer systems such as the S3C64XX.
-
- config S5P_CLOCK
- def_bool ARCH_S5PV210
- help
- Support common clock part for ARCH_S5P and ARCH_EXYNOS SoCs
-
- # options for IRQ support
-
- config S5P_IRQ
- def_bool ARCH_S5PV210
- help
- Support common interrupt part for ARCH_S5P SoCs
-
- config S5P_EXT_INT
- bool
-config SAMSUNG_GPIO_EXTRA
- int "Number of additional GPIO pins"
- default 128 if SAMSUNG_GPIO_EXTRA128
- default 64 if SAMSUNG_GPIO_EXTRA64
- default 0
-- help
- Use the external interrupts (other than GPIO interrupts.)
-Use additional GPIO space in addition to the GPIO's the SOC
-provides. This allows expanding the GPIO space for use with
-GPIO expanders.
--
- config S5P_GPIO_INT
-config SAMSUNG_GPIO_EXTRA64
-- bool
- help
- Common code for the GPIO interrupts (other than external interrupts.)
-
- # options for gpio configuration support
--
- config S5P_GPIO_DRVSTR
-config SAMSUNG_GPIO_EXTRA128
-- bool
- help
- Internal configuration to get and set correct GPIO driver strength
- helper
--
config S3C_GPIO_SPACE
int "Space between gpio banks"
default 0
signature.asc
Description: PGP signature
Re: linux-next: Tree for Jul 16
On Wed, Jul 16, 2014 at 9:47 PM, Stephen Rothwell wrote: > Hi Nick, > > On Wed, 16 Jul 2014 21:16:16 -0400 Nick Krause wrote: >> >> > On Wed, 16 Jul 2014 20:45:25 -0400 Nick Krause wrote: >> >> >> >> On Wed, Jul 16, 2014 at 4:45 AM, Stephen Rothwell >> >> wrote: >> >> > >> >> > Status of my local build tests will be at >> >> > http://kisskb.ellerman.id.au/linux-next . >> > >> >> I am trying to get the maintainers to clean up still failing builds. >> >> When you get time I wondering >> >> if you can send me a list of still failing builds and warnings of >> >> interest in the kernel that is' >> >> up to date for me to help clean up these outstanding issues with the >> >> maintainers support as needed. >> > >> > See above ... >> >> There seems to be a few that are still succeeding for me that aren't for. >> Would you mind testing some of them again to see if they are succeeding >> with a gcc compiler that is newer then version 4.7. > > Please tell us exactly what you are testing: what kernel version, what > compiler/binutils version. The kernel is meant to be able to be built > with gcc 4.7 (and some earlier) - barring compiler bugs, of course. > > -- > Cheers, > Stephen Rothwells...@canb.auug.org.au Absolutely , I am using the latest kernel rc from git. I am using gcc 4.8.3 and binutils 2.83.91. In addition I am using the default configurations as you are in less I am doing it differently. By the way xtensa-defconfig seems to fail because of binutils as I discussed this with the maintainers and they seemed to have tested it with a newer upstream binutils then I am using and it succeeded it the linking failures I am seeing with it. 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] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'
On 07/16/2014 06:27 PM, Chen Gang wrote:
On 07/15/2014 10:38 PM, Chen Gang wrote:
On 07/15/2014 09:11 AM, Chen Gang wrote:
On 07/15/2014 08:53 AM, Guenter Roeck wrote:
On 07/14/2014 05:34 PM, Chen Gang wrote:
On 07/14/2014 05:22 PM, Chen Gang wrote:
在 2014年7月14日，下午4:57，Richard Weinberger 写道：
Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:
On 07/14/2014 10:31 AM, Richard Weinberger wrote:
Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:
On Sun, Jul 13, 2014 at 09:33:38PM +0200, Richard Weinberger wrote:
Maybe we could add COMPILE_TEST to the version string too?
Just to detect such kernels fast in user bug reports...
What kind of bug report are you going to get?
User manages to enable CONFIG_FOO by selecting COMPILE_TEST and
complains that it does not work. :)
These drivers are typically drivers for some SoC peripheral and the
device will simply physically not exist on a platform that does not
provide HAS_IOMEM. This is not really any
different from making the driver selectable via COMPILE_TEST for
any other platform. To hit the issue you'd have to instantiate a
device driver instance for a device that
physically does not exist. This will always result in a failure.
Okay, you have convinced me. :)
After search the history patches, I found one related patch which made
by myself (when I am in Asianux):
"https://lkml.org/lkml/2013/7/1/641;
For me, it is a long discussion, and forced many members have to join
in. Please help check again.
One thing you could try would be to return NULL (or where appropriate
an error) in the #else case of CONFIG_HAS_IOMEM and CONFIG_HAS_IOPORT,
ie dont take COMPILE_TEST into account at all. Obviously that means
you won't be able to dump a warning message in the COMPILE_TEST
case, but at least the code would compile. The rejection of above patch
would make a good case for this approach.
For me, only let 'devm_io*map*' support COMPILE_TEST is OK, that can fix
all related issues:
[PATCH] lib: devres: Add dumy functions to support COMPILE_TEST when no IOMEM
For some architectures which no IOMEM, 'devres' will be skipped. But
many drivers may still want COMPILE_TEST, so let 'devres' support it.
The related error (with allmodconfig under score):
MODPOST 1365 modules
ERROR: "devm_ioremap_resource" [drivers/watchdog/tegra_wdt.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/watchdog/of_xilinx_wdt.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/staging/iio/adc/mxs-lradc.ko]
undefined!
ERROR: "devm_ioremap_resource" [drivers/pwm/pwm-clps711x.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/input/serio/olpc_apsp.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/input/serio/arc_ps2.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-xgene.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-stk17ta8.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1742.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1553.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1511.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1286.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-rp5c01.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-msm6242.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-m48t59.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-m48t35.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-bq4802.ko] undefined!
Signed-off-by: Chen Gang
---
include/linux/device.h | 9 +
include/linux/io.h | 30 +-
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index c2421e0..a7500c3 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -630,7 +630,16 @@ extern unsigned long devm_get_free_pages(struct device
*dev,
gfp_t gfp_mask, unsigned int order);
extern void devm_free_pages(struct device *dev, unsigned long addr);
+#ifdef CONFIG_HAS_IOMEM
void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
+#elif defined(CONFIG_COMPILE_TEST)
I would make it #else
+static inline void __iomem *devm_ioremap_resource(struct device *dev,
+ struct resource *res)
+{
+ pr_warn("no hardware io memory, only for COMPILE_TEST\n");
dev_warn
+ return (__force void __iomem *)ERR_PTR(-ENXIO);
+}
+#endif /* CONFIG_HAS_IOMEM || CONFIG_COMPILE_TEST */
/* allows to add/remove a custom action to devres stack */
int devm_add_action(struct device *dev, void (*action)(void *), void *data);
diff --git a/include/linux/io.h b/include/linux/io.h
index b76e6e5..59128aa 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -58,14 +58,42 @@ static inline void devm_ioport_unmap(struct device *dev,
void __iomem *addr)
}
#endif
+#ifdef CONFIG_HAS_IOMEM
+
linux-next: manual merge of the samsung tree with the arm-soc tree
Hi Kukjin,
Today's linux-next merge of the samsung tree got a conflict in
arch/arm/Kconfig between commit 2fd48f94426d ("ARM: mach-s5p: get rid
of all headers") from the arm-soc tree and commit
72dc5e8f84b0 ("ARM: S5PV210: Enable multi-platform build support") from
the samsung tree.
I fixed it up (the latter is a superset of the former) and can carry
the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH 3.15 00/84] 3.15.6-stable review
On Wed, Jul 16, 2014 at 07:53:41PM +0900, Satoru Takeuchi wrote: > At Tue, 15 Jul 2014 21:28:16 -0700, > Guenter Roeck wrote: > > > > On 07/15/2014 04:16 PM, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 3.15.6 release. > > > There are 84 patches in this series, all will be posted as a response > > > to this one. If anyone has any issues with these being applied, please > > > let me know. > > > > > > Responses should be made by Thu Jul 17 23:17:00 UTC 2014. > > > Anything received after that time might be too late. > > > > > > > Build results: > > total: 139 pass: 139 fail: 0 > > > > Qemu tests all passed. > > > > Another set of perfect results. > > > > Details are available at http://server.roeck-us.net:8010/builders. > > All 3.15.6-rc1, 3.14.13-rc1, 3.10.49-rc1, and 3.4.99-rc1 passed my test. > > - Test Cases: >- Build this kernel. >- Boot this kernel. >- Build the latest mainline kernel with this kernel. > ># "selftests" is not added to this list yet. > > - Test Tool: >https://github.com/satoru-takeuchi/test-linux-stable > > - Test Result (kernel .config, ktest config and test log): >http://satoru-takeuchi.org/test-linux-stable/results/- datetime>.tar.xz > > - Build Environment: >- OS: Debian Jessy x86_64 >- CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 >- memory: 8GB > > - Test Target Environment: >- Debian Jessy x86_64 (KVM guest on the Build Environment) >- # of vCPU: 2 >- memory: 2GB Thanks for testing these and letting me know. 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/
Re: [PATCH 3.15 00/84] 3.15.6-stable review
On Wed, Jul 16, 2014 at 05:12:28PM -0700, Guenter Roeck wrote: > On 07/16/2014 04:09 PM, Greg Kroah-Hartman wrote: > >On Tue, Jul 15, 2014 at 04:16:57PM -0700, Greg Kroah-Hartman wrote: > >>This is the start of the stable review cycle for the 3.15.6 release. > >>There are 84 patches in this series, all will be posted as a response > >>to this one. If anyone has any issues with these being applied, please > >>let me know. > >> > >>Responses should be made by Thu Jul 17 23:17:00 UTC 2014. > >>Anything received after that time might be too late. > >> > >>The whole patch series can be found in one patch at: > >>kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.6-rc1.gz > >>and the diffstat can be found below. > > > >Due to some problems with Xen, I've removed a bunch of patches from this > >series (and the 3.4, 3.10, and 3.14 series) and done a -rc2 release with > >the updated set: > > > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.6-rc2.gz > > > > Build and qemu test for all releases is still fine. Great, thanks for letting me know. 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/
Re: [RFC PATCH 1/1] rcu: use atomic_read(v) instead of atomic_add_return(0, v)
On 07/16/2014 09:14 AM, Paul E. McKenney wrote: > On Mon, Jul 14, 2014 at 09:27:00AM -0400, Pranith Kumar wrote: >> On Sat, Jul 12, 2014 at 8:08 AM, Paul E. McKenney wrote: >>> >>> They ensure that any RCU read-side critical sections that took place before >>> the current (or previous) idle/userspace period on the remote CPU in >>> question are seen as having completed before the completion of the current >>> grace period. It also ensures that any RCU read-side critical sections >>> that extend beyond the end of the current grace period (thus starting >>> after the current (or previous) idle/userspace period) see any updates >>> that were carried out before the beginning of the current grace period. >>> >>> Of course, that is also the purpose of many of RCU's memory barriers, >>> so this probably doesn't help much. An alternative explanation is that >>> it ensures a coherent view of the ->dynticks counter, but I am quite >>> sure that this helps even less. >>> >>> So here is the problem we are having: >>> >>> The dyntick_save_progress_counter() and rcu_implicit_dynticks_qs() >>> functions are really bad places to start reading the RCU code. I would >>> say that starting there is like learning to swim by diving into the deep >>> end of a swimming pool, but that doesn't really capture it. Instead, >>> it is more like learning to swim by diving from the top of this waterfall: >>> >>> http://blog.pacificnorthwestphotography.com/wp-content/uploads/2011/03/54.jpg >>> >>> To understand these functions, you will first need to understand how >>> the rest of RCU works. These functions are tiny cogs in RCU's energy >>> efficiency optimization mechanism, which fits into the larger grace-period >>> detection mechanism. The purpose of the two atomic operations is to >>> preserve the memory-ordering guarantees called out in the docbook header >>> comments for call_rcu() and synchronize_rcu(), and I must confess that >>> it is not clear to me that you actually read these header comments. >>> Even so, these two functions interact with lots of other accesses to >>> implement these guarantees -- so again, it is really really difficult >>> to understand these two functions in isolation. >>> >>> Please see the end of this message for my suggested order of learning >>> the RCU code. A study plan, if you will. >> >> This guide helps a lot, thank you for the detailed study plan. I will >> make sure to go slow and steady. :) > > Best of everything with it! > Thanks a lot, Paul, for taking the time to help me understand. Hopefully one of these days, after reading the study list, I actually will :) -- Pranith. -- 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] arch/score/include/uapi/asm/ptrace.h: Remove the macros which not be used currently
On Thu, 26 Jun 2014, David Rientjes wrote: > On Thu, 26 Jun 2014, Chen Gang wrote: > > > 'COUNTER' and other same kind macros are too common to use, and easy to > > get conflict with other modules. > > > > At present, they are not used, so it is OK to simply remove them. And the > > related warning (allmodconfig with score): > > > > CC [M] drivers/md/raid1.o > > In file included from drivers/md/raid1.c:42:0: > > drivers/md/bitmap.h:93:0: warning: "COUNTER" redefined > >#define COUNTER(x) (((bitmap_counter_t) x) & COUNTER_MAX) > >^ > > In file included from ./arch/score/include/asm/ptrace.h:4:0, > >from include/linux/sched.h:31, > >from include/linux/blkdev.h:4, > >from drivers/md/raid1.c:36: > > ./arch/score/include/uapi/asm/ptrace.h:13:0: note: this is the location > > of the previous definition > >#define COUNTER 38 > > > > > > Signed-off-by: Chen Gang > > Acked-by: David Rientjes > Lennox or Liqin, could you please queue this patch for 3.17? -- 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/
2014 FINANCIAL AID
Are you in need of A personal loan? or are you in need of a business loan? we offer loan to individual and co-operate bodies in need of financial assistance, Application are available for applicant over 18 years only. contact us by email if interested in a fast and easy loan at a low and affordable interest rate of 3%. Interested applicant are require to fill this form below and send it back to us: Full Name:.. Amount Required:. Loan Terms/Duration:... Country: State: Occupation:.. Sex: Address:. Tel Number: We do hope to hear from you soonest so that we can send you the loan Terms, Conditions and Repayment Schedule. Be assured that the possibility of getting a Loan from our firm is extremely Guaranteed. Regards Jazmin Fox Fin Aid jazminfoxfin...@gmail.com +16464195728 -- 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: Tree for Jul 16
Hi Nick, On Wed, 16 Jul 2014 21:16:16 -0400 Nick Krause wrote: > > > On Wed, 16 Jul 2014 20:45:25 -0400 Nick Krause wrote: > >> > >> On Wed, Jul 16, 2014 at 4:45 AM, Stephen Rothwell > >> wrote: > >> > > >> > Status of my local build tests will be at > >> > http://kisskb.ellerman.id.au/linux-next . > > > >> I am trying to get the maintainers to clean up still failing builds. > >> When you get time I wondering > >> if you can send me a list of still failing builds and warnings of > >> interest in the kernel that is' > >> up to date for me to help clean up these outstanding issues with the > >> maintainers support as needed. > > > > See above ... > > There seems to be a few that are still succeeding for me that aren't for. > Would you mind testing some of them again to see if they are succeeding > with a gcc compiler that is newer then version 4.7. Please tell us exactly what you are testing: what kernel version, what compiler/binutils version. The kernel is meant to be able to be built with gcc 4.7 (and some earlier) - barring compiler bugs, of course. -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
linux-next: manual merge of the mvebu tree with Linus' tree
Hi all,
Today's linux-next merge of the mvebu tree got a conflict in
drivers/cpuidle/cpuidle-armada-370-xp.c between commit dc559aabe2d4
("cpuidle: mvebu: Fix the name of the states") from Linus' tree and
commit 742450174037 ("cpuidle: mvebu: rename the driver from
armada-370-xp to mvebu-v7") from the mvebu tree.
The former patch appears to have been applied to the
renamed file, so there was nothing to do (except remove the git created
version of the old file).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Fix ME in pm-pxa910.c
When learning for Fix Mes I am hitting one in this file. The line number is 105 and I am new so what error code should I return. 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: manual merge of the mvebu tree with the arm tree
Hi all,
Today's linux-next merge of the mvebu tree got a conflict in
arch/arm/mach-mvebu/headsmp-a9.S between commit e77a0969a99e ("ARM:
convert all "mov.* pc, reg" to "bx reg" for ARMv6+") from the arm tree
and commit 435b4642e49f ("ARM: mvebu: use the common function for
Armada 375 SMP workaround") from the mvebu tree.
I fixed it up (the latter removed the code modified by the former) and
can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
[PATCH] staging: dgap: introduce dgap_cleanup_nodes()
When a configration file is parsed with dgap_parsefile(),
makes nodes for saving configrations for board.
Making a node will allocate node memory and strings for saving
configrations with kstrdup().
So these are freed when dgap is unloaded or failed to initialize.
Signed-off-by: Daeseok Youn
---
Mark, please review this patch.
Thanks.
drivers/staging/dgap/dgap.c | 47 +++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 06c55cb..e9df2ea 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -201,6 +201,7 @@ static int dgap_test_fep(struct board_t *brd);
static int dgap_tty_register_ports(struct board_t *brd);
static int dgap_firmware_load(struct pci_dev *pdev, int card_type,
struct board_t *brd);
+static void dgap_cleanup_nodes(void);
static void dgap_cleanup_module(void);
@@ -619,6 +620,7 @@ unregister_tty:
free_flipbuf:
dgap_free_flipbuf(brd);
cleanup_brd:
+ dgap_cleanup_nodes();
dgap_release_remap(brd);
kfree(brd);
@@ -659,6 +661,8 @@ static void dgap_cleanup_module(void)
dgap_cleanup_board(dgap_board[i]);
}
+ dgap_cleanup_nodes();
+
if (dgap_numboards)
pci_unregister_driver(_driver);
}
@@ -6323,6 +6327,49 @@ static void dgap_remove_tty_sysfs(struct device *c)
sysfs_remove_group(>kobj, _tty_attribute_group);
}
+static void dgap_cleanup_nodes(void)
+{
+ struct cnode *p;
+
+ p = _head;
+
+ while (p) {
+ struct cnode *tmp = p->next;
+
+ switch (p->type) {
+ case BNODE:
+ kfree(p->u.board.portstr);
+ kfree(p->u.board.addrstr);
+ kfree(p->u.board.pcibusstr);
+ kfree(p->u.board.pcislotstr);
+ kfree(p->u.board.method);
+ break;
+ case CNODE:
+ kfree(p->u.conc.id);
+ kfree(p->u.conc.connect);
+ break;
+ case MNODE:
+ kfree(p->u.module.id);
+ break;
+ case TNODE:
+ kfree(p->u.ttyname);
+ break;
+ case CUNODE:
+ kfree(p->u.cuname);
+ break;
+ case LNODE:
+ kfree(p->u.line.cable);
+ break;
+ case PNODE:
+ kfree(p->u.printname);
+ break;
+ }
+
+ kfree(p->u.board.status);
+ kfree(p);
+ p = tmp;
+ }
+}
/*
* Parse a configuration file read into memory as a string.
*/
--
1.7.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/
RE: [PATCH v3 7/7] ACPI: Cleanup useless ACPI inclusion.
Hi, > From: Mark Brown [mailto:broo...@kernel.org] > Sent: Thursday, July 17, 2014 5:35 AM > > On Wed, Jul 16, 2014 at 11:46:14PM +0200, Rafael J. Wysocki wrote: > > On Wednesday, July 16, 2014 01:07:50 PM Mark Brown wrote: > > > On Wed, Jul 16, 2014 at 04:59:02PM +0800, Lv Zheng wrote: > > > > > The sst-haswell-dsp.c is an ACPI independent file, this patch removes > > > > ACPI header files for it. > > > > Applied, thanks. Please use subject lines matching the style for the > > > subsystem and send at least the cover letter for the series to everyone > > > so that they know what's going on with dependencies and so on. > > > Lv thought that this would go through the ACPI tree I suppose. > > Even so the subject line should still line up (it's part of how some of > us pick out which mail to read). I just didn't notice this. :-) I'll take care next time. Thanks and best regards -Lv -- 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] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'
On 07/15/2014 10:38 PM, Chen Gang wrote:
> On 07/15/2014 09:11 AM, Chen Gang wrote:
>>
>>
>> On 07/15/2014 08:53 AM, Guenter Roeck wrote:
>>> On 07/14/2014 05:34 PM, Chen Gang wrote:
On 07/14/2014 05:22 PM, Chen Gang wrote:
>
> 在 2014年7月14日，下午4:57，Richard Weinberger 写道：
>
>> Am 14.07.2014 10:48, schrieb Lars-Peter Clausen:
>>> On 07/14/2014 10:31 AM, Richard Weinberger wrote:
Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman:
> On Sun, Jul 13, 2014 at 09:33:38PM +0200, Richard Weinberger wrote:
>> Maybe we could add COMPILE_TEST to the version string too?
>> Just to detect such kernels fast in user bug reports...
>
> What kind of bug report are you going to get?
User manages to enable CONFIG_FOO by selecting COMPILE_TEST and
complains that it does not work. :)
>>>
>>> These drivers are typically drivers for some SoC peripheral and the
>>> device will simply physically not exist on a platform that does not
>>> provide HAS_IOMEM. This is not really any
>>> different from making the driver selectable via COMPILE_TEST for
>>> any other platform. To hit the issue you'd have to instantiate a
>>> device driver instance for a device that
>>> physically does not exist. This will always result in a failure.
>>
>> Okay, you have convinced me. :)
>>
After search the history patches, I found one related patch which made
by myself (when I am in Asianux):
"https://lkml.org/lkml/2013/7/1/641;
For me, it is a long discussion, and forced many members have to join
in. Please help check again.
>>>
>>> One thing you could try would be to return NULL (or where appropriate
>>> an error) in the #else case of CONFIG_HAS_IOMEM and CONFIG_HAS_IOPORT,
>>> ie dont take COMPILE_TEST into account at all. Obviously that means
>>> you won't be able to dump a warning message in the COMPILE_TEST
>>> case, but at least the code would compile. The rejection of above patch
>>> would make a good case for this approach.
>>>
For me, only let 'devm_io*map*' support COMPILE_TEST is OK, that can fix
all related issues:
[PATCH] lib: devres: Add dumy functions to support COMPILE_TEST when no IOMEM
For some architectures which no IOMEM, 'devres' will be skipped. But
many drivers may still want COMPILE_TEST, so let 'devres' support it.
The related error (with allmodconfig under score):
MODPOST 1365 modules
ERROR: "devm_ioremap_resource" [drivers/watchdog/tegra_wdt.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/watchdog/of_xilinx_wdt.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/staging/iio/adc/mxs-lradc.ko]
undefined!
ERROR: "devm_ioremap_resource" [drivers/pwm/pwm-clps711x.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/input/serio/olpc_apsp.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/input/serio/arc_ps2.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-xgene.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-stk17ta8.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1742.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1553.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1511.ko] undefined!
ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1286.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-rp5c01.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-msm6242.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-m48t59.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-m48t35.ko] undefined!
ERROR: "devm_ioremap" [drivers/rtc/rtc-bq4802.ko] undefined!
Signed-off-by: Chen Gang
---
include/linux/device.h | 9 +
include/linux/io.h | 30 +-
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index c2421e0..a7500c3 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -630,7 +630,16 @@ extern unsigned long devm_get_free_pages(struct device
*dev,
gfp_t gfp_mask, unsigned int order);
extern void devm_free_pages(struct device *dev, unsigned long addr);
+#ifdef CONFIG_HAS_IOMEM
void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
+#elif defined(CONFIG_COMPILE_TEST)
+static inline void __iomem *devm_ioremap_resource(struct device *dev,
+ struct resource *res)
+{
+ pr_warn("no hardware io memory, only for COMPILE_TEST\n");
+ return (__force void __iomem *)ERR_PTR(-ENXIO);
+}
+#endif /* CONFIG_HAS_IOMEM || CONFIG_COMPILE_TEST */
/* allows to add/remove a custom action to devres stack */
int devm_add_action(struct device *dev, void (*action)(void *), void *data);
diff --git a/include/linux/io.h b/include/linux/io.h
index b76e6e5..59128aa 100644
---
Re: [PATCH 2/3] rcu: Remove stale comment in tree.c
On 07/16/2014 09:25 PM, Lai Jiangshan wrote:
> On 07/17/2014 09:01 AM, Pranith Kumar wrote:
>> On 07/16/2014 08:55 PM, Lai Jiangshan wrote:
>>> On 07/16/2014 09:29 PM, Pranith Kumar wrote:
On 07/16/2014 08:47 AM, Paul E. McKenney wrote:
> On Tue, Jul 15, 2014 at 06:57:59PM -0400, Pranith Kumar wrote:
>>
>> On 07/15/2014 06:53 PM, j...@joshtriplett.org wrote:
>>> On Tue, Jul 15, 2014 at 06:31:48PM -0400, Pranith Kumar wrote:
This commit removes a stale comment in rcu/tree.c.
FYI, an updated comment exists a few lines below this.
Signed-off-by: Pranith Kumar
>>> In general, when removing a stale comment, I'd suggest explaining why
>>> the comment is stale. Was code removed without removing the
>>> corresponding comment, or was code changed such that the comment no
>>> longer applies, or...?
>>
>> I guess it was left out when code was moved around previously. And I did
>> mention that an updated comment is there a few lines below.
>>
>> For reference this is the new comment which is below the old comment,
>> they mean the same :)
>>
>> /* Remove the outgoing CPU from the masks in the rcu_node hierarchy.
>> */
>
> Indeed that is the case.
>
> Please update the commit log with this explanation and resend.
>
> Thanx, Paul
>
Please find the updated patch below.
--
Pranith
From: Pranith Kumar
Date: Mon, 14 Jul 2014 16:01:05 -0400
Subject: [PATCH 2/3] rcu: Remove stale comment in tree.c
This commit removes a stale comment in rcu/tree.c which was left out when
some
code was moved around previously.
>>>
>>> Which commit caused this leftover comment? Could you mention that commit in
>>> your changlog?
>>>
>>> 12BitsCmmtID ("commit title...")
>>>
>>
>> Sure, please find an updated patch with Josh Triplett's sign-off added:
>>
>> From: Pranith Kumar
>> Date: Mon, 14 Jul 2014 16:01:05 -0400
>> Subject: [PATCH 2/3] rcu: Remove stale comment in tree.c
>>
>>
>> This commit removes a stale comment in rcu/tree.c which was left out in
>> commit 2036d94a7b61ca5032ce (rcu: Rework detection of use of RCU by offline
>> CPUs)
>
> I suggest you use the following syntax in future.
>
> 2036d94a7b61 ("rcu: Rework detection of use of RCU by offline CPUs")
>
OK. I will do that from now on. Thanks! :)
--
Pranith
>>
>> For reference, the following updated comment exists a few lines below this
>> which
>> means the same.
>>
>> /* Remove the outgoing CPU from the masks in the rcu_node hierarchy. */
>>
>> Signed-off-by: Pranith Kumar
>> Reviewed-by: Joe Tripplett
>
> Reviewed-by: Lai Jiangshan
>
>> ---
>> kernel/rcu/tree.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
>> index a1abaa8..e67246e 100644
>> --- a/kernel/rcu/tree.c
>> +++ b/kernel/rcu/tree.c
>> @@ -2211,8 +2211,6 @@ static void rcu_cleanup_dead_cpu(int cpu, struct
>> rcu_state *rsp)
>> /* Adjust any no-longer-needed kthreads. */
>> rcu_boost_kthread_setaffinity(rnp, -1);
>>
>> -/* Remove the dead CPU from the bitmasks in the rcu_node hierarchy. */
>> -
>> /* Exclude any attempts to start a new grace period. */
>> mutex_lock(>onoff_mutex);
>> raw_spin_lock_irqsave(>orphan_lock, flags);
>
--
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] rcu: Remove stale comment in tree.c
On 07/17/2014 09:01 AM, Pranith Kumar wrote:
> On 07/16/2014 08:55 PM, Lai Jiangshan wrote:
>> On 07/16/2014 09:29 PM, Pranith Kumar wrote:
>>> On 07/16/2014 08:47 AM, Paul E. McKenney wrote:
On Tue, Jul 15, 2014 at 06:57:59PM -0400, Pranith Kumar wrote:
>
> On 07/15/2014 06:53 PM, j...@joshtriplett.org wrote:
>> On Tue, Jul 15, 2014 at 06:31:48PM -0400, Pranith Kumar wrote:
>>> This commit removes a stale comment in rcu/tree.c.
>>> FYI, an updated comment exists a few lines below this.
>>>
>>> Signed-off-by: Pranith Kumar
>> In general, when removing a stale comment, I'd suggest explaining why
>> the comment is stale. Was code removed without removing the
>> corresponding comment, or was code changed such that the comment no
>> longer applies, or...?
>
> I guess it was left out when code was moved around previously. And I did
> mention that an updated comment is there a few lines below.
>
> For reference this is the new comment which is below the old comment,
> they mean the same :)
>
> /* Remove the outgoing CPU from the masks in the rcu_node hierarchy.
> */
Indeed that is the case.
Please update the commit log with this explanation and resend.
Thanx, Paul
>>>
>>> Please find the updated patch below.
>>>
>>> --
>>> Pranith
>>>
>>> From: Pranith Kumar
>>> Date: Mon, 14 Jul 2014 16:01:05 -0400
>>> Subject: [PATCH 2/3] rcu: Remove stale comment in tree.c
>>>
>>> This commit removes a stale comment in rcu/tree.c which was left out when
>>> some
>>> code was moved around previously.
>>
>> Which commit caused this leftover comment? Could you mention that commit in
>> your changlog?
>>
>> 12BitsCmmtID ("commit title...")
>>
>
> Sure, please find an updated patch with Josh Triplett's sign-off added:
>
> From: Pranith Kumar
> Date: Mon, 14 Jul 2014 16:01:05 -0400
> Subject: [PATCH 2/3] rcu: Remove stale comment in tree.c
>
>
> This commit removes a stale comment in rcu/tree.c which was left out in
> commit 2036d94a7b61ca5032ce (rcu: Rework detection of use of RCU by offline
> CPUs)
I suggest you use the following syntax in future.
2036d94a7b61 ("rcu: Rework detection of use of RCU by offline CPUs")
>
> For reference, the following updated comment exists a few lines below this
> which
> means the same.
>
> /* Remove the outgoing CPU from the masks in the rcu_node hierarchy. */
>
> Signed-off-by: Pranith Kumar
> Reviewed-by: Joe Tripplett
Reviewed-by: Lai Jiangshan
> ---
> kernel/rcu/tree.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index a1abaa8..e67246e 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -2211,8 +2211,6 @@ static void rcu_cleanup_dead_cpu(int cpu, struct
> rcu_state *rsp)
> /* Adjust any no-longer-needed kthreads. */
> rcu_boost_kthread_setaffinity(rnp, -1);
>
> - /* Remove the dead CPU from the bitmasks in the rcu_node hierarchy. */
> -
> /* Exclude any attempts to start a new grace period. */
> mutex_lock(>onoff_mutex);
> raw_spin_lock_irqsave(>orphan_lock, flags);
--
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 07/12] usb: chipidea: add a usb2 driver for ci13xxx
> > > > > > > > Some people wanted the possibility to set the DMA mask as this > > > > USB2 CI driver does not do specific Berlin operation and can be > reused later. > > > > I don't particularly need to call dma_coerce_mask_and_coherent() > > > > in my case, as far as I know. > > > > > > Ok, just remove the call then and rely on the default mask. > > > > > > > They can maybe give the restrictions they might want to put on the > > > > DMA mask. > > > > > > If the restriction is from the bus, it should get handled > > > automatically by the device probe as long as the correct dma-ranges > > > property is there (though we have a small bug there at the moment). > > > If there is a variation of ci13xxx that can't do 32-bit DMA, that > > > should use a different compatible string and pass a fixed mask into > > > dma_set_mask_and_coherent() based on the device. > > > > > > > Correct me if my below understanding is wrong please. > > > > For three chipidea users: > > user_a: don't need dma mask > > user_b: dma mask value is dma_mask_b > > user_c: dma mask value is dma_mask_c > > > > We don't need to call dma_coerce_mask_and_coherent() at generic > > chipidea glue driver, and set dma-ranges as dma_mask_b at user_b's > > dts, and set dma-ranges as dma_mask_c at user_c's dts. > > The dma-ranges property doesn't just encode a dma-mask for a device, but > rather how the children of a bus see the memory address space of the > parent. > > For traditional reasons we default to assuming that a 32-bit dma_mask is > correct, but there may be multiple reasons why this is not true: > > - you have a device connected to a bus that is smaller than 32-bit wide > (and that would have a dma-ranges property describing that) > - you have a device that has fewer than 32 address lines but is connected > to a 32-bit upstream bus (hence the dma-ranges describe all 32 bit, > but the driver must set a smaller mask) > - you have a 64-bit capable device connected to a 32-bit bus: the driver > will ask for a 64-bit mask, but the dma_set_mask() call refuses this > because of the bus capabilities. > - you have a 64-bit capable device on a 64-bit capable bus, and the > dma_set_mask call should succeed. > > The mask is definitely never "user" specific, but is a combination of the > device you have and the bus it is connected to. > Thanks, arnd. For chipidea generic glue layer case, if there are three devices who use this driver, and all devices have 32-bit bus, some devices have less 32 address lines. For example: - the device_a doesn't need to use dma_mask - the device_b needs dma_mask as 0xf - the device_c needs dma_mask as 0xfff0, assume it has only 28 address lines My questions are: - Can we not set dma_mask at driver, and only set dma-ranges at dts for device_b and device_c as a solution to cover this different dma mask use case? - If we can't use this solution, would you suggest one? - If we can use this solution, for device_b and device_c, how can we write dma-ranges? I can't find any arm platforms use it, only some powerpc platform use it. According to the definition from Power_ePAPR_APPROVED_v1.1.pdf, it is dma-ranges = but I find the powerpc has different way for using dma-ranges. Peter -- 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 v6] mtd:nor:timeout:fix do_write_buffer() timeout error
On Thu, Jul 17, 2014 at 12:54:17AM +, Bean Huo wrote: > > I have just fixed up your patch myself, to use max() and to improve some > > of the language. Let me know if the below works for you. > > hi,Brian > Thanks once again.I test and it works Ok.It can be accepted now? > Yes. Pushed to l2-mtd.git. Please be more diligent next time to follow CodingStyle and email submission practices next time. Even if your company email gives trouble, I'm sure you can find some way to send patches properly. For instance, a quick search shows me that your outlook.com email supports sending email via SMTP: http://windows.microsoft.com/en-us/windows/outlook/send-receive-from-app That means you can, for instance, use git-send-email to send patches. Brian -- 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: Tree for Jul 16
> > On Wed, 16 Jul 2014 20:45:25 -0400 Nick Krause wrote: >> >> On Wed, Jul 16, 2014 at 4:45 AM, Stephen Rothwell >> wrote: >> > >> > Status of my local build tests will be at >> > http://kisskb.ellerman.id.au/linux-next . > >> I am trying to get the maintainers to clean up still failing builds. >> When you get time I wondering >> if you can send me a list of still failing builds and warnings of >> interest in the kernel that is' >> up to date for me to help clean up these outstanding issues with the >> maintainers support as needed. > > See above ... > > -- > Cheers, > Stephen Rothwells...@canb.auug.org.au There seems to be a few that are still succeeding for me that aren't for. Would you mind testing some of them again to see if they are succeeding with a gcc compiler that is newer then version 4.7. 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] mach-s3c64xx: Remove all defintions not related to regs-clocks
On Mon, Jul 14, 2014 at 5:43 PM, wrote: > On Mon, 14 Jul 2014 14:14:24 -0400, Nicholas Krause said: >> This patch addresses the fix me message in this file that states to >> remove all definitions not related to reg-clocks in this header >> file. >> >> Signed-off-by: Nicholas Krause >> --- >> arch/arm/mach-s3c64xx/include/mach/regs-clock.h | 22 +- >> 1 file changed, 1 insertion(+), 21 deletions(-) > >> -#endif /* _PLAT_REGS_CLOCK_H */ >> +/#endif /* _PLAT_REGS_CLOCK_H */ > > You're kidding us, right? Given that this was obviously *not* compile > tested at all, why should we believe that in fact all those #defines > are in fact no longer used? > > Hint: There's a very high chance that somebody stuck that FIXME in there > rather > than just cleaning it up themselves precisely *because* it was still in use in > an inconvenient to fix place in the tree.. > I build the arch/arm directory I seem to me hitting a error. arch/arm/xen/enlighten.c:17:29: fatal error: asm/system_misc.h: No such file or directory #include I am also looking into fixing this issue. 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 2/3] rcu: Remove stale comment in tree.c
On 07/16/2014 08:55 PM, Lai Jiangshan wrote:
> On 07/16/2014 09:29 PM, Pranith Kumar wrote:
>> On 07/16/2014 08:47 AM, Paul E. McKenney wrote:
>>> On Tue, Jul 15, 2014 at 06:57:59PM -0400, Pranith Kumar wrote:
On 07/15/2014 06:53 PM, j...@joshtriplett.org wrote:
> On Tue, Jul 15, 2014 at 06:31:48PM -0400, Pranith Kumar wrote:
>> This commit removes a stale comment in rcu/tree.c.
>> FYI, an updated comment exists a few lines below this.
>>
>> Signed-off-by: Pranith Kumar
> In general, when removing a stale comment, I'd suggest explaining why
> the comment is stale. Was code removed without removing the
> corresponding comment, or was code changed such that the comment no
> longer applies, or...?
I guess it was left out when code was moved around previously. And I did
mention that an updated comment is there a few lines below.
For reference this is the new comment which is below the old comment, they
mean the same :)
/* Remove the outgoing CPU from the masks in the rcu_node hierarchy. */
>>>
>>> Indeed that is the case.
>>>
>>> Please update the commit log with this explanation and resend.
>>>
>>> Thanx, Paul
>>>
>>
>> Please find the updated patch below.
>>
>> --
>> Pranith
>>
>> From: Pranith Kumar
>> Date: Mon, 14 Jul 2014 16:01:05 -0400
>> Subject: [PATCH 2/3] rcu: Remove stale comment in tree.c
>>
>> This commit removes a stale comment in rcu/tree.c which was left out when
>> some
>> code was moved around previously.
>
> Which commit caused this leftover comment? Could you mention that commit in
> your changlog?
>
> 12BitsCmmtID ("commit title...")
>
Sure, please find an updated patch with Josh Triplett's sign-off added:
From: Pranith Kumar
Date: Mon, 14 Jul 2014 16:01:05 -0400
Subject: [PATCH 2/3] rcu: Remove stale comment in tree.c
This commit removes a stale comment in rcu/tree.c which was left out in
commit 2036d94a7b61ca5032ce (rcu: Rework detection of use of RCU by offline
CPUs)
For reference, the following updated comment exists a few lines below this which
means the same.
/* Remove the outgoing CPU from the masks in the rcu_node hierarchy. */
Signed-off-by: Pranith Kumar
Reviewed-by: Joe Tripplett
---
kernel/rcu/tree.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index a1abaa8..e67246e 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2211,8 +2211,6 @@ static void rcu_cleanup_dead_cpu(int cpu, struct
rcu_state *rsp)
/* Adjust any no-longer-needed kthreads. */
rcu_boost_kthread_setaffinity(rnp, -1);
- /* Remove the dead CPU from the bitmasks in the rcu_node hierarchy. */
-
/* Exclude any attempts to start a new grace period. */
mutex_lock(>onoff_mutex);
raw_spin_lock_irqsave(>orphan_lock, flags);
--
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/
[patch v3] mm, thp: only collapse hugepages to nodes with affinity for zone_reclaim_mode
Commit 9f1b868a13ac ("mm: thp: khugepaged: add policy for finding target
node") improved the previous khugepaged logic which allocated a
transparent hugepages from the node of the first page being collapsed.
However, it is still possible to collapse pages to remote memory which may
suffer from additional access latency. With the current policy, it is
possible that 255 pages (with PAGE_SHIFT == 12) will be collapsed remotely
if the majority are allocated from that node.
When zone_reclaim_mode is enabled, it means the VM should make every attempt
to allocate locally to prevent NUMA performance degradation. In this case,
we do not want to collapse hugepages to remote nodes that would suffer from
increased access latency. Thus, when zone_reclaim_mode is enabled, only
allow collapsing to nodes with RECLAIM_DISTANCE or less.
There is no functional change for systems that disable zone_reclaim_mode.
Signed-off-by: David Rientjes
---
v2: only change behavior for zone_reclaim_mode per Dave Hansen
v3: optimization based on previous node counts per Vlastimil Babka
mm/huge_memory.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2234,6 +2234,30 @@ static void khugepaged_alloc_sleep(void)
static int khugepaged_node_load[MAX_NUMNODES];
#ifdef CONFIG_NUMA
+static bool khugepaged_scan_abort(int nid)
+{
+ int i;
+
+ /*
+* If zone_reclaim_mode is disabled, then no extra effort is made to
+* allocate memory locally.
+*/
+ if (!zone_reclaim_mode)
+ return false;
+
+ /* If there is a count for this node already, it must be acceptable */
+ if (khugepaged_node_load[nid])
+ return false;
+
+ for (i = 0; i < MAX_NUMNODES; i++) {
+ if (!khugepaged_node_load[i])
+ continue;
+ if (node_distance(nid, i) > RECLAIM_DISTANCE)
+ return true;
+ }
+ return false;
+}
+
static int khugepaged_find_target_node(void)
{
static int last_khugepaged_target_node = NUMA_NO_NODE;
@@ -2309,6 +2333,11 @@ static struct page
return *hpage;
}
#else
+static bool khugepaged_scan_abort(int nid)
+{
+ return false;
+}
+
static int khugepaged_find_target_node(void)
{
return 0;
@@ -2545,6 +2574,8 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,
* hit record.
*/
node = page_to_nid(page);
+ if (khugepaged_scan_abort(node))
+ goto out_unmap;
khugepaged_node_load[node]++;
VM_BUG_ON_PAGE(PageCompound(page), page);
if (!PageLRU(page) || PageLocked(page) || !PageAnon(page))
--
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] r8169: Enable RX_MULTI_EN for RTL_GIGA_MAC_VER_40
On 17.07.2014 07:25, David Miller wrote: > From: Francois Romieu > Date: Tue, 15 Jul 2014 23:54:12 +0200 > >> Hayes Wang : >>> Michel D?nzer [mailto:mic...@daenzer.net] >> [...] Without this, the ethernet port on my ASUS A88X Pro mainboard stops working sometimes, with messages like these in dmesg: AMD-Vi: Event logged [IO_PAGE_FAULT device=05:00.0 domain=0x001e address=0x3000 flags=0x0050] >>> >>> I search the information about your issue. It seems to be >>> relative to the IOMMU. I don't sure if your patch is the root >>> cause or a workaround. >> >> Btw, a few extra identifiers in rtl_init_rxcfg may improve consistency: >> >>missing | included >> ---+--- >> RTL_GIGA_MAC_VER_36 (8168f)| RTL_GIGA_MAC_VER_35 (8168f) >> RTL_GIGA_MAC_VER_38 (RTL8411) | RTL_GIGA_MAC_VER_44 (RTL8411) >> RTL_GIGA_MAC_VER_39 (RTL8106e) | RTL_GIGA_MAC_VER_43 (RTL8106e) >> RTL_GIGA_MAC_VER_37 (RTL8402) | > > Michel please take Francois's feedback here into consideration and also > provide a more detailed commit message so other people reading the commit > can understand your reasoning for making this change, not just what the > result might be for making it. I'm afraid I can't do that. I don't really understand any of this stuff, I just googled the IOMMU event message, found similar patches for other chipsets, and adapted them for my mainboard until the problem stopped. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer -- 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] mm, tmp: only collapse hugepages to nodes with affinity for zone_reclaim_mode
On Wed, 16 Jul 2014, Vlastimil Babka wrote: > I wonder if you could do this here? > > if (khugepaged_node_load[nid]) > return false; > > If the condition is true, it means you already checked the 'nid' node against > all other nodes present in the pmd in a previous khugepaged_scan_pmd > iteration. > And if it passed then, it would also pass now. If meanwhile a new node was > found > and recorded, it was also checked against everything present at that point, > including 'nid'. So it should be safe? > > The worst case (perfect interleaving page per page, so that "node != > last_node" > is true in each iteration) complexity then reduces from O(HPAGE_PMD_NR * > MAX_NUMNODES) to O(HPAGE_PMD_NR + MAX_NUMNODES) iterations. > Excellent suggestion, thanks Vlastimil! -- 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] rcu: Remove stale comment in tree.c
On 07/16/2014 09:29 PM, Pranith Kumar wrote:
> On 07/16/2014 08:47 AM, Paul E. McKenney wrote:
>> On Tue, Jul 15, 2014 at 06:57:59PM -0400, Pranith Kumar wrote:
>>>
>>> On 07/15/2014 06:53 PM, j...@joshtriplett.org wrote:
On Tue, Jul 15, 2014 at 06:31:48PM -0400, Pranith Kumar wrote:
> This commit removes a stale comment in rcu/tree.c.
> FYI, an updated comment exists a few lines below this.
>
> Signed-off-by: Pranith Kumar
In general, when removing a stale comment, I'd suggest explaining why
the comment is stale. Was code removed without removing the
corresponding comment, or was code changed such that the comment no
longer applies, or...?
>>>
>>> I guess it was left out when code was moved around previously. And I did
>>> mention that an updated comment is there a few lines below.
>>>
>>> For reference this is the new comment which is below the old comment, they
>>> mean the same :)
>>>
>>> /* Remove the outgoing CPU from the masks in the rcu_node hierarchy. */
>>
>> Indeed that is the case.
>>
>> Please update the commit log with this explanation and resend.
>>
>> Thanx, Paul
>>
>
> Please find the updated patch below.
>
> --
> Pranith
>
> From: Pranith Kumar
> Date: Mon, 14 Jul 2014 16:01:05 -0400
> Subject: [PATCH 2/3] rcu: Remove stale comment in tree.c
>
> This commit removes a stale comment in rcu/tree.c which was left out when some
> code was moved around previously.
Which commit caused this leftover comment? Could you mention that commit in
your changlog?
12BitsCmmtID ("commit title...")
>
> For reference, the following updated comment exists a few lines below this
> which
> means the same.
>
> /* Remove the outgoing CPU from the masks in the rcu_node hierarchy. */
>
> Signed-off-by: Pranith Kumar
> ---
> kernel/rcu/tree.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index a1abaa8..e67246e 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -2211,8 +2211,6 @@ static void rcu_cleanup_dead_cpu(int cpu, struct
> rcu_state *rsp)
> /* Adjust any no-longer-needed kthreads. */
> rcu_boost_kthread_setaffinity(rnp, -1);
>
> - /* Remove the dead CPU from the bitmasks in the rcu_node hierarchy. */
> -
> /* Exclude any attempts to start a new grace period. */
> mutex_lock(>onoff_mutex);
> raw_spin_lock_irqsave(>orphan_lock, flags);
--
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 v6] mtd:nor:timeout:fix do_write_buffer() timeout error
> Hi Bean, >> + cfi->chips[i].buffer_write_time_max = >> + ((cfi->chips[i].buffer_write_time_max>= 2000) >> + ? cfi->chips[i].buffer_write_time_max : 2000); > > This should just use the 'max()' macro, from . > I have just fixed up your patch myself, to use max() and to improve some > of the language. Let me know if the below works for you. hi,Brian Thanks once again.I test and it works Ok.It can be accepted now? -- 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: Tree for Jul 16
Hi Nick, [Please trim your replies to just the bit (if any) that you are referring to] On Wed, 16 Jul 2014 20:45:25 -0400 Nick Krause wrote: > > On Wed, Jul 16, 2014 at 4:45 AM, Stephen Rothwell > wrote: > > > > Status of my local build tests will be at > > http://kisskb.ellerman.id.au/linux-next . > I am trying to get the maintainers to clean up still failing builds. > When you get time I wondering > if you can send me a list of still failing builds and warnings of > interest in the kernel that is' > up to date for me to help clean up these outstanding issues with the > maintainers support as needed. See above ... -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: [PATCH v3] PM / devfreq: Add possible_frequencies device attribute
On Wed, Jul 16, 2014 at 12:01 PM, Saravana Kannan
wrote:
> Some devices use freq_table instead of OPP. For those devices, the
> available_frequencies sysfs file shows up empty. So, add a
> possible_frequencies attribute/syfs file that list all the possible
> frequencies.
>
> For devices that use OPP, the output of this file will match
> available_frequencies. It may change in the future to show all OPP
> frequencies -- even the disabled ones.
>
> Signed-off-by: Saravana Kannan
Hi,
Please add a documentation entry for this new ABI having a little justification
and usage included.
Plus, I am considering to move trans_stat along with this entry to somewhere
such as .../stat/*
(you don't need to take care of this.)
Besides, as OPP seems becoming the standard as imagined when devfreq
development started,
soon, devfreq may require OPP unless the devfreq device has continuous
frequencies.
Cheers,
MyungJoo
> ---
> drivers/devfreq/devfreq.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 9f90369..65eed38 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -994,6 +994,31 @@ static ssize_t available_frequencies_show(struct device
> *d,
> }
> static DEVICE_ATTR_RO(available_frequencies);
>
> +static ssize_t possible_frequencies_show(struct device *d,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct devfreq *df = to_devfreq(d);
> + unsigned int i = 0;
> + ssize_t count = 0;
> +
> + if (!df->profile->freq_table)
> + return available_frequencies_show(d, attr, buf);
> +
> + for (i = 0; i < df->profile->max_state; i++)
> + count += scnprintf([count], (PAGE_SIZE - count - 2),
> + "%u ", df->profile->freq_table[i]);
> +
> + /* Truncate the trailing space */
> + if (count)
> + count--;
> +
> + count += sprintf([count], "\n");
> +
> + return count;
> +}
> +static DEVICE_ATTR_RO(possible_frequencies);
> +
> static ssize_t trans_stat_show(struct device *dev,
>struct device_attribute *attr, char *buf)
> {
> @@ -1041,6 +1066,7 @@ static struct attribute *devfreq_attrs[] = {
> _attr_available_governors.attr,
> _attr_cur_freq.attr,
> _attr_available_frequencies.attr,
> + _attr_possible_frequencies.attr,
> _attr_target_freq.attr,
> _attr_polling_interval.attr,
> _attr_min_freq.attr,
> --
> 1.8.2.1
>
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
Re: [PATCH] title: no lookup_page for if statement
On Mon, Jul 14, 2014 at 3:35 PM, Chris Metcalf wrote:
> On 7/14/2014 2:59 PM, Paul Bolle wrote:
>>
>> On Mon, 2014-07-14 at 14:49 -0400, Nicholas Krause wrote:
>>>
>>> >This patch removes the if define statement for page_lookup in order
>>> >to remove a fix me of this not being defined as of yet.
>>> >
>>> >Signed-off-by: Nicholas Krause
>
>
> Nicholas, you can't just enable this code; it will break the
> build, since there is no lookup_address() symbol on tile.
>
> I'd like to encourage you to look for more substantive kinds of
> changes to submit to LKML. This one and the last one (adding some
> underscores to some obsolete symbols) both have ended up costing me
> some time to look at and figure out what's actually going on, but
> for no real value. I suspect there may be "janitor" tasks that
> are more useful if you are looking for small starting points
> (Google for "linux kernel janitors").
>
> That said I'm going to go ahead and check in the following change
> which actually does work, now that my attention has been drawn here.
>
> diff --git a/arch/tile/mm/fault.c b/arch/tile/mm/fault.c
> index 6c0571216a9d..7e884001ca6a 100644
> --- a/arch/tile/mm/fault.c
> +++ b/arch/tile/mm/fault.c
> @@ -513,17 +513,14 @@ no_context:
>
> bust_spinlocks(1);
>
> - /* FIXME: no lookup_address() yet */
> -#ifdef SUPPORT_LOOKUP_ADDRESS
> - if (fault_num == INT_ITLB_MISS) {
> - pte_t *pte = lookup_address(address);
> + if (fault_num == INT_ITLB_MISS && address >= PAGE_OFFSET) {
> + pte_t *pte = virt_to_kpte(address);
>
> - if (pte && pte_present(*pte) && !pte_exec_kernel(*pte))
> - pr_crit("kernel tried to execute"
> - " non-executable page - exploit attempt?"
> - " (uid: %d)\n", current->uid);
> + if (pte && pte_present(*pte) && !pte_exec(*pte))
> + pr_crit("kernel tried to execute non-executable
> page"
> + " - exploit attempt? (uid: %d)\n",
> + from_kuid(_user_ns, current_uid()));
> }
> -#endif
> if (address < PAGE_SIZE)
> pr_alert("Unable to handle kernel NULL pointer
> dereference\n");
> else
>
> --
> Chris Metcalf, Tilera Corp.
> http://www.tilera.com
>
Chris,
Understood I screwed up here. I am doing other changes with build and
warning errors. Plus some
fix me issues that are simple. I will double check my patches and the
code they are relating to more
carefully. I should have asked you before writing this patch:(.
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 v2] mm, tmp: only collapse hugepages to nodes with affinity for zone_reclaim_mode
On Wed, 16 Jul 2014, Vlastimil Babka wrote:
> >> @@ -2545,6 +2571,11 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,
> >> * hit record.
> >> */
> >>node = page_to_nid(page);
> >> + if (node != last_node) {
> >> + if (khugepaged_scan_abort(node))
> >> + goto out_unmap;
> >
> > Nitpick: How about not break the loop but only reset the related
> > khugepaged_node_load[] to zero. E.g. modify khugepaged_scan_abort() like
> > this:
> > if (node_distance(nid, i) > RECLAIM_DISTANCE)
> >khugepaged_node_load[i] = 0;
> >
> > By this way, we may have a chance to find a more suitable node.
>
> Hm theoretically there might be a suitable node, but this approach wouldn't
> work. By resetting it to zero you forget that there ever was node 'i'. If
> there
> is no more base page from node 'i', the load remains zero and the next call
> with
> 'nid' will think that 'nid' is OK.
>
Right, the suggestion is wrong because we do not want to ever collapse to
a node when the distance from the source page is > RECLAIM_DISTANCE,
that's the entire point of the patch.
--
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: [RFC PATCH 1/1] rcu: Allow user to ovveride RCU_NOCB_CPU_ALL at boot time
On 07/16/2014 08:26 PM, Paul E. McKenney wrote: > On Wed, Jul 16, 2014 at 06:38:08PM -0400, Pranith Kumar wrote: >> A kernel built with RCU_NOCB_CPU_ALL build time option will offload callbacks >> from all CPUs. The user cannot override this behavior without recompiling the >> kernel with the RCU_NOCB_CPU_ALL option turned off. >> >> This commit allows the user to override the build-time option by using the >> rcu_nocbs= boot time option without needing to recompile the kernel. >> >> Please note that this is how NO_HZ_FULL_ALL build time option works and this >> commit makes it work similar to that. >> >> Signed-off-by: Pranith Kumar Hi Paul, > I cannot accept this patch. For one thing, tick_nohz_init_all() looks > a bit on the unconditional side when CONFIG_NO_HZ_FULL_ALL=y. For > another thing, we really do not want to be handing the user a tool that > allows CPUs that are nohz_full to not be no-CBs CPUs. For another thing, I thought the latest patch does not allow that by ORing the nohz_full and rcu_nocbs mask. Doesn't it? All nohz_full CPUs will be nocb CPUS. We can mention this explicitly in the kernel-parameters.txt file. > if we add this and it turns out to be a bad idea, it will be difficult > to take it back -- someone somewhere will no doubt have scripted the > boot parameter. This option already exists in the kernel when RCU_NOCB_CPU_ALL is not set. The user can pass in rcu_nocbs= at boot time. I am not sure we are adding anything new with this patch. Most of the distro kernels set RCU_NOCB_CPU_ALL and rightly so, as it is the suggested and most appropriate option. This patch will make it easier for users who want to specify nocb CPUs for their needs, without having to recompile the kernel. > > Thanx, Paul > > -- Pranith -- 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: Tree for Jul 16
On Wed, Jul 16, 2014 at 4:45 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20140715: > > The v4l-dvb tree lost its build failure. > > The wireless-next tree gained a build failure so I used the version > from next-20140715. > > The infiniband tree gained a conflict against the net-next tree. > > The staging tree gained conflict against the net-next and v4l-dvb trees. > > The akpm tree gained a build failure due to an interaction with the > cgroup tree for which I applied a fix patch. > > Non-merge commits (relative to Linus' tree): 5966 > 5609 files changed, 220568 insertions(+), 280729 deletions(-) > > > > I have created today's linux-next tree at > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you > are tracking the linux-next tree using git, you should not use "git pull" > to do so as that will try to merge the new linux-next release with the > old one. You should use "git fetch" and checkout or reset to the new > master. > > You can see which trees have been included by looking in the Next/Trees > file in the source. There are also quilt-import.log and merge.log files > in the Next directory. Between each merge, the tree was built with > a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a > multi_v7_defconfig for arm. After the final fixups (if any), it is also > built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and > allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm > defconfig. > > Below is a summary of the state of the merge. > > I am currently merging 222 trees (counting Linus' and 30 trees of patches > pending for Linus' tree). > > Stats about the size of the tree over time can be seen at > http://neuling.org/linux-next-size.html . > > Status of my local build tests will be at > http://kisskb.ellerman.id.au/linux-next . If maintainers want to give > advice about cross compilers/configs that work, we are always open to add > more builds. > > Thanks to Randy Dunlap for doing many randconfig builds. And to Paul > Gortmaker for triage and bug fixes. > > -- > Cheers, > Stephen Rothwells...@canb.auug.org.au > Hey Stephen, I am trying to get the maintainers to clean up still failing builds. When you get time I wondering if you can send me a list of still failing builds and warnings of interest in the kernel that is' up to date for me to help clean up these outstanding issues with the maintainers support as needed. 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 6/8 V2] staging: dgap: remove unneeded dgap_err()
2014-07-17 3:47 GMT+09:00 Greg KH :
> On Wed, Jul 16, 2014 at 06:26:17PM +0900, DaeSeok Youn wrote:
>> 2014-07-16 8:50 GMT+09:00 Greg KH :
>> > On Wed, Jul 16, 2014 at 08:21:30AM +0900, DaeSeok Youn wrote:
>> >> Hi,
>> >>
>> >> 2014-07-16 0:29 GMT+09:00 Greg KH :
>> >> > On Tue, Jul 15, 2014 at 06:11:44PM +0900, Daeseok Youn wrote:
>> >> >> The dgap_err() is printing a message with pr_err(),
>> >> >> so all those are replaced.
>> >> >>
>> >> >> Use definition "pr_fmt" and then all of "dgap:" in
>> >> >> the beginning of print messages are removed.
>> >> >>
>> >> >> And also removed "out of memory" message because
>> >> >> the kernel has own message for that.
>> >> >>
>> >> >> Signed-off-by: Daeseok Youn
>> >> >> ---
>> >> >> V2: use pr_fmt "dgap:" prefix on print message on dgap.
>> >> >> remove "out of memory" message.
>> >> >>
>> >> >> Adds Mark to TO list and CC list for checking send
>> >> >> this email properly to him.
>> >> >>
>> >> >> drivers/staging/dgap/dgap.c | 306
>> >> >> +++
>> >> >> 1 files changed, 133 insertions(+), 173 deletions(-)
>> >> >>
>> >> >> diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
>> >> >> index 06c55cb..9e750fb 100644
>> >> >> --- a/drivers/staging/dgap/dgap.c
>> >> >> +++ b/drivers/staging/dgap/dgap.c
>> >> >> @@ -41,6 +41,8 @@
>> >> >> */
>> >> >> #undef DIGI_CONCENTRATORS_SUPPORTED
>> >> >>
>> >> >> +#define pr_fmt(fmt) "dgap: " fmt
>> >> >> +
>> >> >> #include
>> >> >> #include
>> >> >> #include
>> >> >> @@ -153,7 +155,6 @@ static void dgap_firmware_reset_port(struct
>> >> >> channel_t *ch);
>> >> >> static int dgap_gettok(char **in);
>> >> >> static char *dgap_getword(char **in);
>> >> >> static int dgap_checknode(struct cnode *p);
>> >> >> -static void dgap_err(char *s);
>> >> >>
>> >> >> /*
>> >> >> * Function prototypes from dgap_sysfs.h
>> >> >> @@ -815,7 +816,7 @@ static struct board_t *dgap_found_board(struct
>> >> >> pci_dev *pdev, int id,
>> >> >> if (ret)
>> >> >> goto free_brd;
>> >> >>
>> >> >> - pr_info("dgap: board %d: %s (rev %d), irq %ld\n",
>> >> >> + pr_info("board %d: %s (rev %d), irq %ld\n",
>> >> >> boardnum, brd->name, brd->rev, brd->irq);
>> >> >
>> >> > Almost all of the pr_*() calls in this driver should be converted over
>> >> > to use dev_*() calls instead. And some of them, like this one, should
>> >> > be removed entirely (no need for a driver to be "noisy" when a device
>> >> > for it is found, it should be quiet if at all possible, unless something
>> >> > went wrong.)
>> >> >
>> >> > So can you do that here instead? I've applied the earlier patches in
>> >> > this series, and stopped here.
>> >> OK. I can. pr_*() calls are replaced with dev_*() calls.
>> >> And also removes some of print message which are useless like "out
>> >> of memory"
>> >
>> > Yes, please do that, that would be great.
>> I have been working to change pr_*() to dev_*(), but dgap_parse() has no
>> "struct device" for using dev_*(). If dgap_parse still need for this driver,
>> it need to take a parameter for using dev_*(), it may be "pdev" but
>> configuration
>> file doesn't need to parse in kernel at all, dgap_parse() will be removed.
>
> For now keep the parsing code, and find a device to use, there should be
> one somewhere, as it is a driver :)
OK. find a device to use for dev_*() and makes a patch for this.
thanks.
regards,
Daeseok Youn.
>
> 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/
Re: [PATCH 6/8 V2] staging: dgap: remove unneeded dgap_err()
2014-07-16 23:17 GMT+09:00 Mark Hounschell :
> On 07/16/2014 05:26 AM, DaeSeok Youn wrote:
>>
>> 2014-07-16 8:50 GMT+09:00 Greg KH :
>>
>>> On Wed, Jul 16, 2014 at 08:21:30AM +0900, DaeSeok Youn wrote:
Hi,
2014-07-16 0:29 GMT+09:00 Greg KH :
>
> On Tue, Jul 15, 2014 at 06:11:44PM +0900, Daeseok Youn wrote:
>>
>> The dgap_err() is printing a message with pr_err(),
>> so all those are replaced.
>>
>> Use definition "pr_fmt" and then all of "dgap:" in
>> the beginning of print messages are removed.
>>
>> And also removed "out of memory" message because
>> the kernel has own message for that.
>>
>> Signed-off-by: Daeseok Youn
>> ---
>> V2: use pr_fmt "dgap:" prefix on print message on dgap.
>> remove "out of memory" message.
>>
>> Adds Mark to TO list and CC list for checking send
>> this email properly to him.
>>
>> drivers/staging/dgap/dgap.c | 306
>> +++
>> 1 files changed, 133 insertions(+), 173 deletions(-)
>>
>> diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
>> index 06c55cb..9e750fb 100644
>> --- a/drivers/staging/dgap/dgap.c
>> +++ b/drivers/staging/dgap/dgap.c
>> @@ -41,6 +41,8 @@
>>*/
>> #undef DIGI_CONCENTRATORS_SUPPORTED
>>
>> +#define pr_fmt(fmt) "dgap: " fmt
>> +
>> #include
>> #include
>> #include
>> @@ -153,7 +155,6 @@ static void dgap_firmware_reset_port(struct
>> channel_t *ch);
>> static int dgap_gettok(char **in);
>> static char *dgap_getword(char **in);
>> static int dgap_checknode(struct cnode *p);
>> -static void dgap_err(char *s);
>>
>> /*
>>* Function prototypes from dgap_sysfs.h
>> @@ -815,7 +816,7 @@ static struct board_t *dgap_found_board(struct
>> pci_dev *pdev, int id,
>>if (ret)
>>goto free_brd;
>>
>> - pr_info("dgap: board %d: %s (rev %d), irq %ld\n",
>> + pr_info("board %d: %s (rev %d), irq %ld\n",
>>boardnum, brd->name, brd->rev, brd->irq);
>
>
> Almost all of the pr_*() calls in this driver should be converted over
> to use dev_*() calls instead. And some of them, like this one, should
> be removed entirely (no need for a driver to be "noisy" when a device
> for it is found, it should be quiet if at all possible, unless
> something
> went wrong.)
>
> So can you do that here instead? I've applied the earlier patches in
> this series, and stopped here.
OK. I can. pr_*() calls are replaced with dev_*() calls.
And also removes some of print message which are useless like "out
of memory"
>>>
>>>
>>> Yes, please do that, that would be great.
>>
>> I have been working to change pr_*() to dev_*(), but dgap_parse() has no
>>
>> "struct device" for using dev_*(). If dgap_parse still need for this
>> driver,
>> it need to take a parameter for using dev_*(), it may be "pdev" but
>> configuration
>> file doesn't need to parse in kernel at all, dgap_parse() will be removed.
>>
>> So I will wait to verify by Mark about parsing configuration file.
>>
>> Thanks.
>>
>> regards,
>> Daeseok Youn.
>>
>
> Hi Daeseok,
>
> I would wait on that one for now. I know that code has to be removed
> eventually. I'm just not sure if we are quite ready. That is actually a LOT
> of lines of code also. I think a couple of things need done first.
>
> Here is a sample config file created by one of DIGI's user land applications
> (mpi). These entries are only for 2 different cards. There are others cards
> that may have other things to consider. I only have these 2 cards types now.
> I had a third type which is just a 2 port but that one is gone now.
>
> config_begin
> board Digi_AccelePort_8r_920_PCI
> io 0x000
> mem 0x00
> start 1
> nports 8
> ttyname ttya
> altpin 0
> useintr 0
> board Digi_AccelePort_4r_920_PCI
> io 0x000
> mem 0x00
> start 1
> nports 4
> ttyname ttyb
> altpin 0
> useintr 0
> board Digi_AccelePort_8r_920_PCI
> io 0x000
> mem 0x00
> start 1
> nports 8
> ttyname ttyc
> altpin 0
> useintr 0
> config_end
oh.. I couldn't find a sample of config file for dgap module in web. Thanks.
>
> The altpin and useintr parameters need to be converted to module parameters.
> I found references in the code somewhere that the nports may not be reliably
> known using the device id for at least one card type. All the other stuff in
> this particular config file is pretty much useless. Well, sort of. The
> ttyname parameter is used by the driver to populate a "sys" file with a
> custom device name that is then used by a userland script and udev to allow
> a user to define his own device names. Custom links are created.
Re: Blackfin Build fixs
On Wed, Jul 16, 2014 at 3:12 AM, Steven Miao wrote: > Hi Nick, > > On Sun, Jul 13, 2014 at 6:18 AM, Nick Krause wrote: >> On Fri, Jul 11, 2014 at 12:18 PM, Nick Krause wrote: >>> Hey Steven, >>> I having been testing what builds are still failing from Steven >>> Rothwell's tests and there seem to be two failing >>> still for blackfin. I am tracing the issues to make it easier for you >>> as a maintainer. BF561-ACVILON_defconfig >>> is failing in acvlion.c due to BFIN_NAND_PLAT_READY not being defined >>> when calling gpio request in >>> bfin_plat_nand_init. I would recommend defining it to the correct >>> value to initialize nand on this board. >>> There also seems to be some undefined syscalls for this board I would >>> can either remove them or you can >>> tell me how to clean them up. >>> >>> I also am hitting a build failure still for blackstamp defconfig. The >>> issue seems to be that when calling functions >>> that need GPIO_PF0 that it's undefined as it fails whenc calling >>> gpio_request that needs it be defined on line 318 >>> of file , arch/blackfin/mach-bf533/boards/blackstamp.c on line 480 and >>> again on line 481 when calling gpio_free. >>> Like the other build there seems to be undefined syscalls and they >>> need to be either removed or cleaned up. I >>> would like recommendations or how you want to clean up these system calls. >>> >>> I am also attaching the log files for these failing builds. > I have fixed BF561-ACVILON, BF533-BLACKSTAMP and some other board > build for missing . Thanks for you build test. > This build fix patch has applied to the next blackfin git tree, and > will send for next rc. > http://git.kernel.org/pub/scm/linux/kernel/git/realmz6/blackfin-linux.git > for-linux > >>> >>> Cheers Nick >> Sorry about my grammar. I attached the same file twice. I will attach >> my build log for Blackstamp >> defconfig. >> Cheers Nick > > -steven Steven , They seem to still be open as of July 16. I have tried using this link http://kisskb.ellerman.id.au/kisskb/branch/9/ to track failing builds. Perhaps it's outdated. Thanks for your help through :). 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] mm, writeback: prevent race when calculating dirty limits
Setting vm_dirty_bytes and dirty_background_bytes is not protected by any
serialization.
Therefore, it's possible for either variable to change value after the
test in global_dirty_limits() to determine whether available_memory needs
to be initialized or not.
Always ensure that available_memory is properly initialized.
Cc: sta...@vger.kernel.org
Signed-off-by: David Rientjes
---
mm/page-writeback.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -261,14 +261,11 @@ static unsigned long global_dirtyable_memory(void)
*/
void global_dirty_limits(unsigned long *pbackground, unsigned long *pdirty)
{
+ const unsigned long available_memory = global_dirtyable_memory();
unsigned long background;
unsigned long dirty;
- unsigned long uninitialized_var(available_memory);
struct task_struct *tsk;
- if (!vm_dirty_bytes || !dirty_background_bytes)
- available_memory = global_dirtyable_memory();
-
if (vm_dirty_bytes)
dirty = DIV_ROUND_UP(vm_dirty_bytes, PAGE_SIZE);
else
--
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 17 July 2014 02:48, Rafael J. Wysocki wrote: > I don't like that idea, but I wonder what other people think. Hmm, the other thread around looking at the bindings is really slow. One common thing around the platforms which want to use cpufreq-cpu0 is they have different clocks for ALL CPUs. I was wondering if instead of a clock-matching routine, we can provide some temporary relief to them via some other means. I meant we can allow cpufreq-cpu0/generic to either set policy->cpus to ALL CPUs or just 1. So that existing and these new platforms can atleast get going.. But don't know how should we do that. Not a binding ofcourse, a Kconfig option could work but multiplatform stuff would break. What else? Maybe platform data as we are handling cpufreq-cpu0 with a platform device? -- 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 v2 00/12] usb: dwc2/gadget: fix series
> From: Robert Baldyga [mailto:r.bald...@samsung.com] > Sent: Wednesday, July 16, 2014 3:22 AM > > This patchset contains fixes for dwc2 gadget driver. It touches PHY, > FIFO configuration, initialization sequence and adds many other small fixes. > > Best regards > Robert Baldyga > Samsung R Institute Poland > > Changelog: > v2: > - add patch usb: dwc2/gadget: avoid disabling ep0 > - fix FIFO flushing when it's assigned to endpoint dynamically > - write to proper FIFO in s3c_hsotg_write_fifo() function > - use real FIFO size in kill_all_requests > - fix comment in s3c_hsotg_init_fifo() function > > v1: https://lkml.org/lkml/2014/6/23/67 Hi Robert, For v1, I gave my Ack for the entire series, but I don't see my Ack on any of these. Any reason for that? -- Paul -- 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: [RFC PATCH 1/1] rcu: Allow user to ovveride RCU_NOCB_CPU_ALL at boot time
On Wed, Jul 16, 2014 at 06:38:08PM -0400, Pranith Kumar wrote:
> A kernel built with RCU_NOCB_CPU_ALL build time option will offload callbacks
> from all CPUs. The user cannot override this behavior without recompiling the
> kernel with the RCU_NOCB_CPU_ALL option turned off.
>
> This commit allows the user to override the build-time option by using the
> rcu_nocbs= boot time option without needing to recompile the kernel.
>
> Please note that this is how NO_HZ_FULL_ALL build time option works and this
> commit makes it work similar to that.
>
> Signed-off-by: Pranith Kumar
I cannot accept this patch. For one thing, tick_nohz_init_all() looks
a bit on the unconditional side when CONFIG_NO_HZ_FULL_ALL=y. For
another thing, we really do not want to be handing the user a tool that
allows CPUs that are nohz_full to not be no-CBs CPUs. For another thing,
if we add this and it turns out to be a bad idea, it will be difficult
to take it back -- someone somewhere will no doubt have scripted the
boot parameter.
Thanx, Paul
> ---
> init/Kconfig | 14 +++---
> kernel/rcu/tree_plugin.h | 8
> 2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index 41066e4..7d363a4 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -768,13 +768,13 @@ config RCU_NOCB_CPU_ALL
> bool "All CPUs are build_forced no-CBs CPUs"
> depends on RCU_NOCB_CPU
> help
> - This option forces all CPUs to be no-CBs CPUs. The rcu_nocbs=
> - boot parameter will be ignored. All CPUs' RCU callbacks will
> - be executed in the context of per-CPU rcuo kthreads created for
> - this purpose. Assuming that the kthreads whose names start with
> - "rcuo" are bound to "housekeeping" CPUs, this reduces OS jitter
> - on the remaining CPUs, but might decrease memory locality during
> - RCU-callback invocation, thus potentially degrading throughput.
> + If the user doesn't pass the rcu_nocbs= boot option, force all CPUs
> + to be no-CBs CPUs. All CPUs' RCU callbacks will be executed in the
> + context of per-CPU rcuo kthreads created for this purpose. Assuming
> + that the kthreads whose names start with "rcuo" are bound to
> + "housekeeping" CPUs, this reduces OS jitter on the remaining CPUs, but
> + might decrease memory locality during RCU-callback invocation, thus
> + potentially degrading throughput.
>
> Select this if all CPUs need to be no-CBs CPUs for real-time
> or energy-efficiency reasons.
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index a2113f6..b97a939 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -92,15 +92,15 @@ static void __init rcu_bootup_announce_oddness(void)
> if (!have_rcu_nocb_mask) {
> zalloc_cpumask_var(_nocb_mask, GFP_KERNEL);
> have_rcu_nocb_mask = true;
> +#ifdef CONFIG_RCU_NOCB_CPU_ALL
> + pr_info("\tOffload RCU callbacks from all CPUs\n");
> + cpumask_copy(rcu_nocb_mask, cpu_possible_mask);
> +#endif /* #ifdef CONFIG_RCU_NOCB_CPU_ALL */
> }
> #ifdef CONFIG_RCU_NOCB_CPU_ZERO
> pr_info("\tOffload RCU callbacks from CPU 0\n");
> cpumask_set_cpu(0, rcu_nocb_mask);
> #endif /* #ifdef CONFIG_RCU_NOCB_CPU_ZERO */
> -#ifdef CONFIG_RCU_NOCB_CPU_ALL
> - pr_info("\tOffload RCU callbacks from all CPUs\n");
> - cpumask_copy(rcu_nocb_mask, cpu_possible_mask);
> -#endif /* #ifdef CONFIG_RCU_NOCB_CPU_ALL */
> #endif /* #ifndef CONFIG_RCU_NOCB_CPU_NONE */
> if (have_rcu_nocb_mask) {
> if (!cpumask_subset(rcu_nocb_mask, cpu_possible_mask)) {
> --
> 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/
