* RE: [PATCH] SCSI: aacraid: potential integer overflow in aac_get_containers()
From: Achim Leubner @ 2011-12-01 10:07 UTC (permalink / raw)
To: Haogang Chen, aacraid; +Cc: JBottomley, linux-scsi, linux-kernel
In-Reply-To: <1322706601-26181-1-git-send-email-haogangchen@gmail.com>
Acked-by: Achim Leubner <Achim_Leubner@pmc-sierra.com>
-----Original Message-----
From: linux-scsi-owner@vger.kernel.org
[mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of Haogang Chen
Sent: Donnerstag, 1. Dezember 2011 03:30
To: aacraid@adaptec.com
Cc: JBottomley@parallels.com; linux-scsi@vger.kernel.org;
linux-kernel@vger.kernel.org; haogangchen@gmail.com
Subject: [PATCH] SCSI: aacraid: potential integer overflow in
aac_get_containers()
There is a potential integer overflow in aac_get_containers(). When
maximum_num_containers is large, the subsequent call to kzalloc() will
allocate a buffer smaller than expected, which leads to memory
corruption in the for loop.
The patch replaces kzalloc with kcalloc.
Signed-off-by: Haogang Chen <haogangchen@gmail.com>
---
drivers/scsi/aacraid/aachba.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/aacraid/aachba.c
b/drivers/scsi/aacraid/aachba.c
index 409f580..440b84d 100644
--- a/drivers/scsi/aacraid/aachba.c
+++ b/drivers/scsi/aacraid/aachba.c
@@ -381,7 +381,7 @@ int aac_get_containers(struct aac_dev *dev)
if (maximum_num_containers < MAXIMUM_NUM_CONTAINERS)
maximum_num_containers = MAXIMUM_NUM_CONTAINERS;
- fsa_dev_ptr = kzalloc(sizeof(*fsa_dev_ptr) *
maximum_num_containers,
+ fsa_dev_ptr = kcalloc(maximum_num_containers,
sizeof(*fsa_dev_ptr),
GFP_KERNEL);
if (!fsa_dev_ptr)
return -ENOMEM;
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2] ramoops: use pstore interface
From: Marco Stornelli @ 2011-12-01 10:31 UTC (permalink / raw)
To: Kees Cook
Cc: Chen Gong, linux-kernel, Tony Luck, Randy Dunlap, Arnd Bergmann,
Greg Kroah-Hartman, Andrew Morton
In-Reply-To: <CAGXu5j+kzXpAhCYELDBBeMDPg2XMHt8jWRjZf2xiPVSMfUhjzA@mail.gmail.com>
Il 29/11/2011 18:24, Kees Cook ha scritto:
> On Mon, Nov 28, 2011 at 8:50 PM, Chen Gong<gong.chen@linux.intel.com> wrote:
>> 于 2011/11/29 4:09, Kees Cook 写道:
>>>
>>> Instead of using /dev/mem directly, use the common pstore infrastructure
>>> to handle Oops gathering and extraction.
>>>
>>> Signed-off-by: Kees Cook<keescook@chromium.org>
>>> ---
>>> This depends on the pstore changes waiting for -next in:
>>>
>>> http://git.kernel.org/?p=linux/kernel/git/aegl/linux.git;a=shortlog;h=refs/heads/next
>>> ---
>>> Documentation/ramoops.txt | 8 +-
>>> drivers/char/Kconfig | 1 +
>>> drivers/char/ramoops.c | 206
>>> ++++++++++++++++++++++++++++++++++-----------
>>> 3 files changed, 160 insertions(+), 55 deletions(-)
>>>
>>> diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt
>>> index 8fb1ba7..a0b9d8e 100644
>>> --- a/Documentation/ramoops.txt
>>> +++ b/Documentation/ramoops.txt
>>> @@ -3,7 +3,7 @@ Ramoops oops/panic logger
>>>
>>> Sergiu Iordache<sergiu@chromium.org>
>>>
>>> -Updated: 8 August 2011
>>> +Updated: 17 November 2011
>>>
>>> 0. Introduction
>>>
>>> @@ -71,6 +71,6 @@ timestamp and a new line. The dump then continues with
>>> the actual data.
>>>
>>> 4. Reading the data
>>>
>>> -The dump data can be read from memory (through /dev/mem or other means).
>>> -Getting the module parameters, which are needed in order to parse the
>>> data, can
>>> -be done through /sys/module/ramoops/parameters/* .
>>> +The dump data can be read from the pstore filesystem. The format for
>>> these
>>> +files is "dmesg-ramoops-N", where N is the record number in memory. To
>>> delete
>>> +a stored record from RAM, simply unlink the respective pstore file.
>>
>> I think the definition of "mem_address" in the doc is not very clear. It is
>> not a normal memory instead of a persistent RAM. I suggest adding more
>> descriptions.
>> It's better if there is a real example.
>
> Okay. I'm not sure it's in the scope of this patch, but I can try.
>
> Marco, do you have suggestions for how this could be enhanced?
>
I don't know actually. It's not mandatory use a persistent memory. A
simple piece of reserved RAM is ok. Obviously it will work only over
reboot and not over power down. I define mem_address as a generic piece
of reserved memory.
Marco
^ permalink raw reply
* Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions
From: Ian Campbell @ 2011-12-01 10:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
Pawel Moll, kvm@vger.kernel.org, Stefano Stabellini,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
android-virt@lists.cs.columbia.edu,
embeddedxen-devel@lists.sourceforge.net,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <201111301815.01297.arnd@arndb.de>
On Wed, 2011-11-30 at 18:15 +0000, Arnd Bergmann wrote:
> On Wednesday 30 November 2011, Ian Campbell wrote:
> > On Wed, 2011-11-30 at 14:32 +0000, Arnd Bergmann wrote:
> > > On Wednesday 30 November 2011, Ian Campbell wrote:
> > > What I suggested to the KVM developers is to start out with the
> > > vexpress platform, but then generalize it to the point where it fits
> > > your needs. All hardware that one expects a guest to have (GIC, timer,
> > > ...) will still show up in the same location as on a real vexpress,
> > > while anything that makes no sense or is better paravirtualized (LCD,
> > > storage, ...) just becomes optional and has to be described in the
> > > device tree if it's actually there.
> >
> > That's along the lines of what I was thinking as well.
> >
> > The DT contains the address of GIC, timer etc as well right? So at least
> > in principal we needn't provide e.g. the GIC at the same address as any
> > real platform but in practice I expect we will.
>
> Yes.
>
> > In principal we could also offer the user options as to which particular
> > platform a guest looks like.
>
> At least when using a qemu based simulation. Most platforms have some
> characteristics that are not meaningful in a classic virtualization
> scenario, but it would certainly be helpful to use the virtualization
> extensions to run a kernel that was built for a particular platform
> faster than with pure qemu, when you want to test that kernel image.
>
> It has been suggested in the past that it would be nice to run the
> guest kernel built for the same platform as the host kernel by
> default, but I think it would be much better to have just one
> platform that we end up using for guests on any host platform,
> unless there is a strong reason to do otherwise.
Yes, I agree, certainly that is what we were planning to target in the
first instance. Doing this means that we can get away with minimal
emulation of actual hardware, relying instead on PV drivers or hardware
virtualisation features.
Supporting specific board platforms as guests would be nice to have
eventually. We would need to do more emulation (e.g. running qemu as a
device model) for that case.
> There is also ongoing restructuring in the ARM Linux kernel to
> allow running the same kernel binary on multiple platforms. While
> there is still a lot of work to be done, you should assume that
> we will finish it before you see lots of users in production, there
> is no need to plan for the current one-kernel-per-board case.
We were absolutely banking on targeting the results of this work, so
that's good ;-)
Ian.
^ permalink raw reply
* Busy looping iwl3945 driver
From: Zdenek Kabelac @ 2011-12-01 10:33 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: linux-wireless
Hi
Today I've noticed 100% CPU occupied by kworker thread - which
appeared to be the result of some iwl3945 driver interaction.
Here are some trace of some tasks from that moment.
It looked like when I've then even tried to run 'mc' of 'ifconfig' -
they could not start since some device lock was kept busy.
The problem was most probably caused by doing suspend when attached to
the wireless network and resuming in wired docking station,
without having the previous wireless AP available.
My hw - T61, 4G, C2D, iwl3945 wifi, X86_64 kernel 3.2.0-rc3
Only reboot fixed this problem.
NetworkManager D 0000000000000000 0 648 1 0x00000004
ffff8801301157e8 0000000000000046 ffffffff814d9fe4 0000000000000000
ffff8801301157f8 ffff88012c968000 0000000000000000 ffff880130115fd8
ffff880130115fd8 ffff880130115fd8 ffffffff81a0d020 ffff88012c968000
Call Trace:
[<ffffffff814d9fe4>] ? __schedule+0x994/0xb50
[<ffffffff814da23f>] schedule+0x3f/0x60
[<ffffffff814db1c2>] mutex_lock_nested+0x1b2/0x3f0
[<ffffffffa033984f>] ? ieee80211_ifa_changed+0x9f/0x150 [mac80211]
[<ffffffffa033984f>] ? ieee80211_ifa_changed+0x9f/0x150 [mac80211]
[<ffffffffa033984f>] ieee80211_ifa_changed+0x9f/0x150 [mac80211]
[<ffffffff814e17e3>] notifier_call_chain+0x93/0x100
[<ffffffff81082cf8>] __blocking_notifier_call_chain+0x78/0xb0
[<ffffffff81082d46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff814856b6>] __inet_del_ifa+0xb6/0x290
[<ffffffff8148633e>] inet_rtm_deladdr+0x10e/0x160
[<ffffffff81436544>] rtnetlink_rcv_msg+0x124/0x2e0
[<ffffffff81436420>] ? __rtnl_unlock+0x20/0x20
[<ffffffff81446c49>] netlink_rcv_skb+0xa9/0xd0
[<ffffffff81434465>] rtnetlink_rcv+0x25/0x40
[<ffffffff81446580>] netlink_unicast+0x2c0/0x310
[<ffffffff81446886>] netlink_sendmsg+0x2b6/0x310
[<ffffffff81410458>] ? sock_update_classid+0xb8/0x1f0
[<ffffffff81409cee>] sock_sendmsg+0x10e/0x1e0
[<ffffffff8140babd>] ? sock_recvmsg+0x18d/0x210
[<ffffffff8112dce3>] ? might_fault+0x53/0xb0
[<ffffffff8112dd2c>] ? might_fault+0x9c/0xb0
[<ffffffff8112dce3>] ? might_fault+0x53/0xb0
[<ffffffff814191c6>] ? verify_iovec+0x56/0xd0
[<ffffffff8140c116>] __sys_sendmsg+0x376/0x380
[<ffffffff81161458>] ? fget_light+0x48/0x3b0
[<ffffffff811614f1>] ? fget_light+0xe1/0x3b0
[<ffffffff81161458>] ? fget_light+0x48/0x3b0
[<ffffffff8118149f>] ? mntput+0x1f/0x30
[<ffffffff8140db19>] sys_sendmsg+0x49/0x90
[<ffffffff814e562b>] system_call_fastpath+0x16/0x1b
avahi-daemon D 0000000000000246 0 667 1 0x00000000
ffff880127df5ba8 0000000000000046 0000000000000000 0000000000000000
ffff880127df5bb8 ffff880128be4600 0000000000000000 ffff880127df5fd8
ffff880127df5fd8 ffff880127df5fd8 ffff88012ca72300 ffff880128be4600
Call Trace:
[<ffffffff814da23f>] schedule+0x3f/0x60
[<ffffffff814db1c2>] mutex_lock_nested+0x1b2/0x3f0
[<ffffffff81434437>] ? rtnl_lock+0x17/0x20
[<ffffffff81434437>] ? rtnl_lock+0x17/0x20
[<ffffffff81434437>] rtnl_lock+0x17/0x20
[<ffffffff8148ff6f>] ip_mc_leave_group+0x2f/0x180
[<ffffffff8145b2f4>] do_ip_setsockopt+0x6d4/0xdb0
[<ffffffff81409cee>] ? sock_sendmsg+0x10e/0x1e0
[<ffffffff8116a1fc>] ? pipe_write+0x2ec/0x5b0
[<ffffffff811a1b43>] ? fsnotify+0x93/0x600
[<ffffffff8140d6f1>] ? sys_sendto+0x101/0x130
[<ffffffff8145bad6>] ip_setsockopt+0x36/0xb0
[<ffffffff8147dcab>] udp_setsockopt+0x1b/0x40
[<ffffffff8140e574>] sock_common_setsockopt+0x14/0x20
[<ffffffff8140d8ff>] sys_setsockopt+0x7f/0xe0
[<ffffffff814e562b>] system_call_fastpath+0x16/0x1b
wpa_supplicant D 0000000000000246 0 770 1 0x00000000
ffff880127c17908 0000000000000046 0000000000000000 0000000000000000
ffff880127c17918 ffff880127e02300 0000000000000000 ffff880127c17fd8
ffff880127c17fd8 ffff880127c17fd8 ffff88012ca72300 ffff880127e02300
Call Trace:
[<ffffffff814da23f>] schedule+0x3f/0x60
[<ffffffff814db1c2>] mutex_lock_nested+0x1b2/0x3f0
[<ffffffff81434437>] ? rtnl_lock+0x17/0x20
[<ffffffff81434437>] ? rtnl_lock+0x17/0x20
[<ffffffff81434437>] rtnl_lock+0x17/0x20
[<ffffffffa02ec1d5>] nl80211_pre_doit+0xf5/0x190 [cfg80211]
[<ffffffff81447263>] genl_rcv_msg+0x1c3/0x250
[<ffffffff814470a0>] ? genl_rcv+0x40/0x40
[<ffffffff81446c49>] netlink_rcv_skb+0xa9/0xd0
[<ffffffff81447085>] genl_rcv+0x25/0x40
[<ffffffff81446580>] netlink_unicast+0x2c0/0x310
[<ffffffff81446886>] netlink_sendmsg+0x2b6/0x310
[<ffffffff81410458>] ? sock_update_classid+0xb8/0x1f0
[<ffffffff81409cee>] sock_sendmsg+0x10e/0x1e0
[<ffffffff8140babd>] ? sock_recvmsg+0x18d/0x210
[<ffffffff8112dce3>] ? might_fault+0x53/0xb0
[<ffffffff8112dd2c>] ? might_fault+0x9c/0xb0
[<ffffffff8112dce3>] ? might_fault+0x53/0xb0
[<ffffffff814191c6>] ? verify_iovec+0x56/0xd0
[<ffffffff8140c116>] __sys_sendmsg+0x376/0x380
[<ffffffff8106a904>] ? set_current_blocked+0x34/0x60
[<ffffffff8100bee1>] ? fpu_finit+0x21/0x40
[<ffffffff8100bf4a>] ? init_fpu+0x4a/0x180
[<ffffffff8100d198>] ? restore_i387_xstate+0xc8/0x1d0
[<ffffffff811615bf>] ? fget_light+0x1af/0x3b0
[<ffffffff814ddedb>] ? _raw_spin_unlock_irq+0x3b/0x60
[<ffffffff8140db19>] sys_sendmsg+0x49/0x90
[<ffffffff814e562b>] system_call_fastpath+0x16/0x1b
ntpd D 0000000000000246 0 21324 1 0x00000000
ffff880127adfca8 0000000000000046 0000000000000000 0000000000000000
ffff880127adfcb8 ffff880127f5c600 0000000000000000 ffff880127adffd8
ffff880127adffd8 ffff880127adffd8 ffff8800379e4600 ffff880127f5c600
Call Trace:
[<ffffffff814da23f>] schedule+0x3f/0x60
[<ffffffff814db1c2>] mutex_lock_nested+0x1b2/0x3f0
[<ffffffff81434437>] ? rtnl_lock+0x17/0x20
[<ffffffff81434437>] ? rtnl_lock+0x17/0x20
[<ffffffff81434437>] rtnl_lock+0x17/0x20
[<ffffffff81428165>] dev_ioctl+0x3c5/0x660
[<ffffffff81090b80>] ? lockdep_init_map+0xf0/0x590
[<ffffffff814092ad>] sock_do_ioctl+0x5d/0x70
[<ffffffff81409339>] sock_ioctl+0x79/0x2f0
[<ffffffff811736f8>] do_vfs_ioctl+0x98/0x570
[<ffffffff814dddf5>] ? _raw_spin_unlock+0x35/0x60
[<ffffffff8115d7cd>] ? fd_install+0x7d/0x100
[<ffffffff811615bf>] ? fget_light+0x1af/0x3b0
[<ffffffff81173c61>] sys_ioctl+0x91/0xa0
[<ffffffff814e562b>] system_call_fastpath+0x16/0x1b
Here I've tried 'mc' and rmmod of iwl3945 (which had in fact open count == 0)
mc D 0000000000000000 0 12325 12174 0x00000000
ffff880007a77ca8 0000000000000046 ffffffff814d9fe4 0000000000000000
ffff880007a77cb8 ffff880037918000 0000000000000000 ffff880007a77fd8
ffff880007a77fd8 ffff880007a77fd8 ffffffff81a0d020 ffff880037918000
Call Trace:
[<ffffffff814d9fe4>] ? __schedule+0x994/0xb50
[<ffffffff814da23f>] schedule+0x3f/0x60
[<ffffffff814db1c2>] mutex_lock_nested+0x1b2/0x3f0
[<ffffffff81434437>] ? rtnl_lock+0x17/0x20
[<ffffffff81434437>] ? rtnl_lock+0x17/0x20
[<ffffffff81434437>] rtnl_lock+0x17/0x20
[<ffffffff81428165>] dev_ioctl+0x3c5/0x660
[<ffffffff81090b80>] ? lockdep_init_map+0xf0/0x590
[<ffffffff814092ad>] sock_do_ioctl+0x5d/0x70
[<ffffffff81409339>] sock_ioctl+0x79/0x2f0
[<ffffffff811736f8>] do_vfs_ioctl+0x98/0x570
[<ffffffff814dddf5>] ? _raw_spin_unlock+0x35/0x60
[<ffffffff8115d7cd>] ? fd_install+0x7d/0x100
[<ffffffff811615bf>] ? fget_light+0x1af/0x3b0
[<ffffffff81173c61>] sys_ioctl+0x91/0xa0
[<ffffffff814e562b>] system_call_fastpath+0x16/0x1b
rmmod D 0000000000000000 0 12340 22112 0x00000000
ffff880051811bf8 0000000000000046 ffffffff814d9fe4 ffffffff814d5fd1
0000000000000001 ffff8800b0cd8000 0000000000000046 ffff880051811fd8
ffff880051811fd8 ffff880051811fd8 ffff880136d44600 ffff8800b0cd8000
Call Trace:
[<ffffffff814d9fe4>] ? __schedule+0x994/0xb50
[<ffffffff814d5fd1>] ? __slab_free+0x233/0x3aa
[<ffffffff814da23f>] schedule+0x3f/0x60
[<ffffffff814dd265>] rwsem_down_failed_common+0xc5/0x160
[<ffffffff814dd313>] rwsem_down_write_failed+0x13/0x20
[<ffffffff812d2733>] call_rwsem_down_write_failed+0x13/0x20
[<ffffffff81082a07>] ? blocking_notifier_chain_unregister+0x27/0xe0
[<ffffffff814dc629>] ? down_write+0x89/0xb0
[<ffffffff81082a07>] ? blocking_notifier_chain_unregister+0x27/0xe0
[<ffffffff81082a07>] blocking_notifier_chain_unregister+0x27/0xe0
[<ffffffff81485cd8>] unregister_inetaddr_notifier+0x18/0x20
[<ffffffffa03380b6>] ieee80211_unregister_hw+0x46/0x120 [mac80211]
[<ffffffffa03b4779>] iwl3945_pci_remove+0x57/0x300 [iwl3945]
[<ffffffff814dde62>] ? _raw_spin_unlock_irqrestore+0x42/0x80
[<ffffffff812ee156>] pci_device_remove+0x46/0x110
[<ffffffff813926bc>] __device_release_driver+0x7c/0xe0
[<ffffffff81392fc8>] driver_detach+0xd8/0xe0
[<ffffffff813924f1>] bus_remove_driver+0x91/0x110
[<ffffffff813937b2>] driver_unregister+0x62/0xa0
[<ffffffff812ecf94>] pci_unregister_driver+0x44/0xc0
[<ffffffffa03b4a32>] iwl3945_exit+0x10/0x17 [iwl3945]
[<ffffffff810a169e>] sys_delete_module+0x16e/0x250
[<ffffffff8109647f>] ? trace_hardirqs_on_caller+0x1f/0x1b0
[<ffffffff814e562b>] system_call_fastpath+0x16/0x1b
Here is 'pert record -a -g'
# Overhead Command Shared Object
Symbol
# ........ ............... ..........................
...........................................
#
97.57% kworker/u:3 [kernel.kallsyms] [k] lock_timer_base
|
--- lock_timer_base
try_to_del_timer_sync
del_timer_sync
iwl3945_send_tx_power
ieee80211_bss_info_change_notify
ieee80211_sta_eosp_irqsafe
ieee80211_sta_eosp_irqsafe
ieee80211_stop_tx_ba_cb
ieee80211_stop_tx_ba_cb
ieee80211_stop_tx_ba_cb
ieee80211_stop_tx_ba_cb
process_one_work
worker_thread
kthread
kernel_thread_helper
0.38% kworker/u:3 [kernel.kallsyms] [k] ioread32
|
--- ioread32
|
|--37.76%-- iwl_legacy_send_bt_config
| iwl3945_rx_queue_restock
| iwl3945_irq_tasklet
| tasklet_action
| __do_softirq
| call_softirq
| do_softirq
| irq_exit
| __irqentry_text_start
| ret_from_intr
| try_to_del_timer_sync
| del_timer_sync
| iwl3945_send_tx_power
| ieee80211_bss_info_change_notify
| ieee80211_sta_eosp_irqsafe
| ieee80211_sta_eosp_irqsafe
| ieee80211_stop_tx_ba_cb
| ieee80211_stop_tx_ba_cb
| ieee80211_stop_tx_ba_cb
| ieee80211_stop_tx_ba_cb
| process_one_work
| worker_thread
| kthread
| kernel_thread_helper
|
|--31.13%-- iwl3945_irq_tasklet
| tasklet_action
| __do_softirq
| call_softirq
| do_softirq
| irq_exit
| |
| |--92.86%-- __irqentry_text_start
| | ret_from_intr
| | try_to_del_timer_sync
| | del_timer_sync
| | iwl3945_send_tx_power
| | ieee80211_bss_info_change_notify
| | ieee80211_sta_eosp_irqsafe
| | ieee80211_sta_eosp_irqsafe
| | ieee80211_stop_tx_ba_cb
| | ieee80211_stop_tx_ba_cb
| | ieee80211_stop_tx_ba_cb
| | ieee80211_stop_tx_ba_cb
| | process_one_work
| | worker_thread
| | kthread
| | kernel_thread_helper
| |
| --7.14%-- smp_apic_timer_interrupt
| apic_timer_interrupt
| try_to_del_timer_sync
| del_timer_sync
| iwl3945_send_tx_power
| ieee80211_bss_info_change_notify
| ieee80211_sta_eosp_irqsafe
| ieee80211_sta_eosp_irqsafe
| ieee80211_stop_tx_ba_cb
| ieee80211_stop_tx_ba_cb
| ieee80211_stop_tx_ba_cb
| ieee80211_stop_tx_ba_cb
| process_one_work
| worker_thread
| kthread
| kernel_thread_helper
|
--31.12%-- iwl_legacy_add_beacon_time
handle_irq_event_percpu
handle_irq_event
handle_edge_irq
handle_irq
__irqentry_text_start
ret_from_intr
try_to_del_timer_sync
del_timer_sync
iwl3945_send_tx_power
ieee80211_bss_info_change_notify
ieee80211_sta_eosp_irqsafe
ieee80211_sta_eosp_irqsafe
ieee80211_stop_tx_ba_cb
ieee80211_stop_tx_ba_cb
ieee80211_stop_tx_ba_cb
ieee80211_stop_tx_ba_cb
process_one_work
worker_thread
kthread
kernel_thread_helper
0.27% kworker/u:3 [kernel.kallsyms] [k] read_hpet
....
Zdenek
^ permalink raw reply
* Re: [PATCH 1/4] iommu: Add iommu_device_group callback and iommu_group sysfs entry
From: David Woodhouse @ 2011-12-01 10:33 UTC (permalink / raw)
To: Alex Williamson
Cc: David Gibson, Benjamin Herrenschmidt, joerg.roedel, iommu,
linux-kernel, chrisw, agraf, scottwood, B08248
In-Reply-To: <1322722110.26545.68.camel@bling.home>
On Wed, 2011-11-30 at 23:48 -0700, Alex Williamson wrote:
> I'm not sure if we're getting into VM usage with "assigning" terminology
> above. You're free to architect qemu however you want on POWER to make
> groups be the assignable unit to a guest. On x86, an individual device
> is the assignable unit for a guest. Unassigned group devices will still
> be required to be held by vfio, they'll just be unused. Thanks,
I'm not sure I understand this.
BY DEFINITION, the smallest assignable unit is the group, surely? Isn't
that the *point* of the groups? That the IOMMU cannot tell the
difference between the devices in the group?
So in *practice*, surely you cannot assign just *one* device from a
group? You can assign the while group, or nothing.
You might *pretend* to assign single devices, and we might try to cope
with the weirdness that happens when you want *one* device of a group to
be owned by one VM, another device in the same group to be owned by a
second VM, and a third device from the same group to be driven by a
native driver in the host. But why not just assign groups as a whole?
Surely that makes most sense?
Btw, did we get a quirk for the Ricoh multi-function devices which all
need to be in the same group because they do all their DMA from function
zero? I think we need another similar quirk for a Marvell SATA
controller which seems to do its AHCI DMA from its IDE function; see
https://bugzilla.redhat.com/757166
--
dwmw2
^ permalink raw reply
* [PATCH] mm: Ensure that pfn_valid is called once per pageblock when reserving pageblocks
From: Michal Hocko @ 2011-12-01 10:29 UTC (permalink / raw)
To: Andrew Morton
Cc: Mel Gorman, KAMEZAWA Hiroyuki, Andrea Arcangeli, David Rientjes,
Dang Bo, Arve Hjønnevåg, KOSAKI Motohiro, John Stultz,
Dave Hansen, linux-mm, linux-kernel
Hi,
the patch bellow fixes a crash during boot (when we set up reserved
page blocks) if zone start_pfn is not block aligned. The issue has
been introduced in 3.0-rc1 by 6d3163ce: mm: check if any page in a
pageblock is reserved before marking it MIGRATE_RESERVE.
I think this is 3.2 and stable material.
---
>From f4da723adb36b247b80283ae520e33726caf485f Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.cz>
Date: Tue, 29 Nov 2011 16:58:38 +0100
Subject: [PATCH] mm: Ensure that pfn_valid is called once per pageblock when
reserving pageblocks
setup_zone_migrate_reserve expects that zone->start_pfn starts
at pageblock_nr_pages aligned pfn otherwise we could access
beyond an existing memblock resulting in the following panic if
CONFIG_HOLES_IN_ZONE is not configured and we do not check pfn_valid:
IP: [<c02d331d>] setup_zone_migrate_reserve+0xcd/0x180
*pdpt = 0000000000000000 *pde = f000ff53f000ff53
Oops: 0000 [#1] SMP
Modules linked in:
Supported: Yes
Pid: 1, comm: swapper Not tainted 3.0.7-0.7-pae #1 VMware, Inc.
VMware Virtual Platform/440BX Desktop Reference Platform
EIP: 0060:[<c02d331d>] EFLAGS: 00010006 CPU: 0
EIP is at setup_zone_migrate_reserve+0xcd/0x180
EAX: 000c0000 EBX: f5801fc0 ECX: 000c0000 EDX: 00000000
ESI: 000c01fe EDI: 000c01fe EBP: 00140000 ESP: f2475f58
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process swapper (pid: 1, ti=f2474000 task=f2472cd0 task.ti=f2474000)
Stack:
f4000800 00000000 f4000800 000006b8 00000000 000c6cd5 c02d389c 000003b2
00036aa9 00000292 f4000830 c08cfe78 00000000 00000000 c08a76f5 c02d3a1f
c08a771c c08cfe78 c020111b 35310001 00000000 00000000 00000100 f24730c4
Call Trace:
[<c02d389c>] __setup_per_zone_wmarks+0xec/0x160
[<c02d3a1f>] setup_per_zone_wmarks+0xf/0x20
[<c08a771c>] init_per_zone_wmark_min+0x27/0x86
[<c020111b>] do_one_initcall+0x2b/0x160
[<c086639d>] kernel_init+0xbe/0x157
[<c05cae26>] kernel_thread_helper+0x6/0xd
Code: a5 39 f5 89 f7 0f 46 fd 39 cf 76 40 8b 03 f6 c4 08 74 32 eb 91 90 89 c8 c1 e8 0e 0f be 80 80 2f 86 c0 8b 14 85 60 2f 86 c0 89 c8 <2b> 82 b4 12 00 00 c1 e0 05 03 82 ac 12 00 00 8b 00 f6 c4 08 0f
EIP: [<c02d331d>] setup_zone_migrate_reserve+0xcd/0x180 SS:ESP 0068:f2475f58
CR2: 00000000000012b4
---[ end trace 93d72a36b9146f22 ]---
We crashed in pageblock_is_reserved() when accessing pfn 0xc0000 because
highstart_pfn = 0x36ffe.
Make sure that start_pfn is always aligned to pageblock_nr_pages to
ensure that pfn_valid s always called at the start of each pageblock.
Architectures with holes in pageblocks will be correctly handled by
pfn_valid_within in pageblock_is_reserved.
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Tested-by: Dang Bo <bdang@vmware.com>
---
mm/page_alloc.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 9dd443d..94ff20d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3377,9 +3377,15 @@ static void setup_zone_migrate_reserve(struct zone *zone)
unsigned long block_migratetype;
int reserve;
- /* Get the start pfn, end pfn and the number of blocks to reserve */
+ /*
+ * Get the start pfn, end pfn and the number of blocks to reserve
+ * We have to be careful to be aligned to pageblock_nr_pages to
+ * make sure that we always check pfn_valid for the first page in
+ * the block.
+ */
start_pfn = zone->zone_start_pfn;
end_pfn = start_pfn + zone->spanned_pages;
+ start_pfn = roundup(start_pfn, pageblock_nr_pages);
reserve = roundup(min_wmark_pages(zone), pageblock_nr_pages) >>
pageblock_order;
--
1.7.7.3
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
^ permalink raw reply related
* Re: [PATCH 2/5] KVM: MMU: audit: replace mmu audit tracepoint with jump-lable
From: Avi Kivity @ 2011-12-01 10:28 UTC (permalink / raw)
To: Xiao Guangrong; +Cc: Jason Baron, Marcelo Tosatti, LKML, KVM
In-Reply-To: <4ED5FABC.1080705@linux.vnet.ibm.com>
On 11/30/2011 11:43 AM, Xiao Guangrong wrote:
> Subject: [PATCH] KVM: MMU: audit: inline audit function
>
> inline audit function and little cleanup
>
>
Thanks, applied.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* [PATCH] fs: Make write(2) interruptible by a fatal signal
From: Jan Kara @ 2011-12-01 10:27 UTC (permalink / raw)
To: LKML; +Cc: linux-fsdevel, Andrew Morton, Linus Torvalds, Wu Fengguang,
Jan Kara
Currently write(2) to a file is not interruptible by any signal. Sometimes this
is desirable (e.g. when you want to quickly kill a process hogging your disk or
when some process gets blocked in balance_dirty_pages() indefinitely due to a
filesystem being in an error condition). This patch makes write interruptible
by SIGKILL. We do not allow write to be interruptible by any other signal
because that has larger potential of screwing some badly written applications.
Reported-by: Kazuya Mio <k-mio@sx.jp.nec.com>
Tested-by: Kazuya Mio <k-mio@sx.jp.nec.com>
Signed-off-by: Jan Kara <jack@suse.cz>
---
mm/filemap.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
Resending this patch to allow people outside linux-fsdevel to take part
in the discussion...
diff --git a/mm/filemap.c b/mm/filemap.c
index c0018f2..c106d3b 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2407,7 +2407,6 @@ static ssize_t generic_perform_write(struct file *file,
iov_iter_count(i));
again:
-
/*
* Bring in the user page that we will copy from _first_.
* Otherwise there's a nasty deadlock on copying from the
@@ -2463,7 +2462,10 @@ again:
written += copied;
balance_dirty_pages_ratelimited(mapping);
-
+ if (fatal_signal_pending(current)) {
+ status = -EINTR;
+ break;
+ }
} while (iov_iter_count(i));
return written ? written : status;
--
1.7.1
^ permalink raw reply related
* Re: [Embeddedxen-devel] [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions
From: Ian Campbell @ 2011-12-01 10:26 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Arnd Bergmann, xen-devel@lists.xensource.com,
linaro-dev@lists.linaro.org, Pawel Moll, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
android-virt@lists.cs.columbia.edu,
embeddedxen-devel@lists.sourceforge.net,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <alpine.DEB.2.00.1111301820290.31179@kaball-desktop>
On Wed, 2011-11-30 at 18:32 +0000, Stefano Stabellini wrote:
> On Wed, 30 Nov 2011, Arnd Bergmann wrote:
>
> > KVM and Xen at least both fall into the single-return-value category,
> > so we should be able to agree on a calling conventions. KVM does not
> > have an hcall API on ARM yet, and I see no reason not to use the
> > same implementation that you have in the Xen guest.
> >
> > Stefano, can you split out the generic parts of your asm/xen/hypercall.h
> > file into a common asm/hypercall.h and submit it for review to the
> > arm kernel list?
>
> Sure, I can do that.
> Usually the hypercall calling convention is very hypervisor specific,
> but if it turns out that we have the same requirements I happy to design
> a common interface.
I expect the only real decision to be made is hypercall page vs. raw hvc
instruction.
The page was useful on x86 where there is a variety of instructions
which could be used (at least for PV there was systenter/syscall/int, I
think vmcall instruction differs between AMD and Intel also) and gives
some additional flexibility. It's hard to predict but I don't think I'd
expect that to be necessary on ARM.
Another reason for having a hypercall page instead of a raw instruction
might be wanting to support 32 bit guests (from ~today) on a 64 bit
hypervisor in the future and perhaps needing to do some shimming/arg
translation. It would be better to aim for having the interface just be
32/64 agnostic but mistakes do happen.
Ian.
^ permalink raw reply
* Re: [bug?] r8169: hangs under heavy load
From: Francois Romieu @ 2011-12-01 10:20 UTC (permalink / raw)
To: booster
Cc: hayeswang, 'Jonathan Nieder', 'Eric Dumazet',
netdev, 'nic_swsd', linux-kernel, 'Armin Kazmi'
In-Reply-To: <4ED538EC.4010509@wolke7.net>
booster@wolke7.net <booster@wolke7.net> :
[...]
> Any more ideas ?
Give me a brain.
Fixed patch below.
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 6f06aa1..e776bf2 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4885,8 +4894,7 @@ static void rtl_hw_start_8168(struct net_device *dev)
RTL_W16(IntrMitigate, 0x5151);
/* Work around for RxFIFO overflow. */
- if (tp->mac_version == RTL_GIGA_MAC_VER_11 ||
- tp->mac_version == RTL_GIGA_MAC_VER_22) {
+ if (tp->mac_version == RTL_GIGA_MAC_VER_11) {
tp->intr_event |= RxFIFOOver | PCSTimeout;
tp->intr_event &= ~RxOverflow;
}
@@ -5804,6 +5812,10 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
*/
status = RTL_R16(IntrStatus);
while (status && status != 0xffff) {
+ status &= tp->intr_event;
+ if (!status)
+ break;
+
handled = 1;
/* Handle all of the error cases first. These will reset
@@ -5818,7 +5830,6 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
switch (tp->mac_version) {
/* Work around for rx fifo overflow */
case RTL_GIGA_MAC_VER_11:
- case RTL_GIGA_MAC_VER_22:
case RTL_GIGA_MAC_VER_26:
netif_stop_queue(dev);
rtl8169_tx_timeout(dev);
@@ -5828,6 +5839,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
case RTL_GIGA_MAC_VER_19:
case RTL_GIGA_MAC_VER_20:
case RTL_GIGA_MAC_VER_21:
+ case RTL_GIGA_MAC_VER_22:
case RTL_GIGA_MAC_VER_23:
case RTL_GIGA_MAC_VER_24:
case RTL_GIGA_MAC_VER_27:
^ permalink raw reply related
* Re: [PATCH] virtio-ring: Use threshold for switching to indirect descriptors
From: Michael S. Tsirkin @ 2011-12-01 10:26 UTC (permalink / raw)
To: Sasha Levin
Cc: Rusty Russell, Avi Kivity, linux-kernel, virtualization, kvm,
markmc
In-Reply-To: <1322726977.3259.3.camel@lappy>
On Thu, Dec 01, 2011 at 10:09:37AM +0200, Sasha Levin wrote:
> On Thu, 2011-12-01 at 09:58 +0200, Michael S. Tsirkin wrote:
> > On Thu, Dec 01, 2011 at 01:12:25PM +1030, Rusty Russell wrote:
> > > On Wed, 30 Nov 2011 18:11:51 +0200, Sasha Levin <levinsasha928@gmail.com> wrote:
> > > > On Tue, 2011-11-29 at 16:58 +0200, Avi Kivity wrote:
> > > > > On 11/29/2011 04:54 PM, Michael S. Tsirkin wrote:
> > > > > > >
> > > > > > > Which is actually strange, weren't indirect buffers introduced to make
> > > > > > > the performance *better*? From what I see it's pretty much the
> > > > > > > same/worse for virtio-blk.
> > > > > >
> > > > > > I know they were introduced to allow adding very large bufs.
> > > > > > See 9fa29b9df32ba4db055f3977933cd0c1b8fe67cd
> > > > > > Mark, you wrote the patch, could you tell us which workloads
> > > > > > benefit the most from indirect bufs?
> > > > > >
> > > > >
> > > > > Indirects are really for block devices with many spindles, since there
> > > > > the limiting factor is the number of requests in flight. Network
> > > > > interfaces are limited by bandwidth, it's better to increase the ring
> > > > > size and use direct buffers there (so the ring size more or less
> > > > > corresponds to the buffer size).
> > > > >
> > > >
> > > > I did some testing of indirect descriptors under different workloads.
> > >
> > > MST and I discussed getting clever with dynamic limits ages ago, but it
> > > was down low on the TODO list. Thanks for diving into this...
> > >
> > > AFAICT, if the ring never fills, direct is optimal. When the ring
> > > fills, indirect is optimal (we're better to queue now than later).
> > >
> > > Why not something simple, like a threshold which drops every time we
> > > fill the ring?
> > >
> > > struct vring_virtqueue
> > > {
> > > ...
> > > int indirect_thresh;
> > > ...
> > > }
> > >
> > > virtqueue_add_buf_gfp()
> > > {
> > > ...
> > >
> > > if (vq->indirect &&
> > > (vq->vring.num - vq->num_free) + out + in > vq->indirect_thresh)
> > > return indirect()
> > > ...
> > >
> > > if (vq->num_free < out + in) {
> > > if (vq->indirect && vq->indirect_thresh > 0)
> > > vq->indirect_thresh--;
> > >
> > > ...
> > > }
> > >
> > > Too dumb?
> > >
> > > Cheers,
> > > Rusty.
> >
> > We'll presumably need some logic to increment is back,
> > to account for random workload changes.
> > Something like slow start?
>
> We can increment it each time the queue was less than 10% full, it
> should act like slow start, no?
No, we really shouldn't get an empty ring as long as things behave
well. What I meant is something like:
#define VIRTIO_DECREMENT 2
#define VIRTIO_INCREMENT 1
if (vq->num_free < out + in) {
if (vq->indirect && vq->indirect_thresh > VIRTIO_DECREMENT)
vq->indirect_thresh /= VIRTIO_DECREMENT;
} else {
if (vq->indirect_thresh < vq->num)
vq->indirect_thresh += VIRTIO_INCREMENT;
}
So we try to avoid indirect but the moment there's no space, we decrease
the threshold drastically. If you make the increment/decrement module
parameters it's easy to try different values.
> --
>
> Sasha.
^ permalink raw reply
* Re: [PATCH 2a/5] Remove unsafe clock values from omap1_defconfig
From: Janusz Krzysztofik @ 2011-12-01 10:21 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Paul Walmsley, linux-omap, linux-arm-kernel, linux-kernel
In-Reply-To: <201112011054.09878.jkrzyszt@tis.icnet.pl>
On Thursday 01 of December 2011 at 10:54:09, Janusz Krzysztofik wrote:
>
> Anyway, did you mean resending those 2/5 and 5/5 without any changes,
> only renumbered as 1/2 and 2/2?
This was not a very clever question, sorry. Answering myself: 2/5 must
be refreshed if not on top of 1/5.
Thanks,
Janusz
^ permalink raw reply
* Re: Which one corresponds to ioctl in the file_operations struct in linux/fs.h?
From: Tvrtko Ursulin @ 2011-12-01 10:22 UTC (permalink / raw)
To: Peng Yu; +Cc: linux-kernel
In-Reply-To: <CABrM6wnDgRd0N5eSGffj51KR6-axAoFMNRWMZs2pFQ8dN94t0A@mail.gmail.com>
On Thursday 01 Dec 2011 07:40:49 Peng Yu wrote:
> Hi,
>
> I have some driver code for older version of kernel. It refers to
> ioctl in the file_operations struct. But this field is change in
> kernel 3.0.0-13
>
> I find the following in linux/fs.h
>
> 1566 long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
> 1567 long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
>
> Does anybody know which one I should use in order to migrate the
> driver code to the newer version of kernel? Thanks!
>From Documentation/filesystems/vfs.txt:
unlocked_ioctl: called by the ioctl(2) system call.
compat_ioctl: called by the ioctl(2) system call when 32 bit system calls
are used on 64 bit kernels.
You don't need compat_ioctl if your ioctl arguments are 32/64-bit safe.
For both your code needs to be re-entrant or take appropriate locks
internally.
Hope this helps,
Tvrtko
^ permalink raw reply
* Re: KSM: numa awareness sysfs knob
From: Petr Holasek @ 2011-12-01 10:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Hugh Dickins, Andrea Arcangeli, linux-kernel, linux-mm,
Anton Arapov
In-Reply-To: <20111130154719.57154fdd.akpm@linux-foundation.org>
On Wed, 30 Nov 2011, Andrew Morton wrote:
> Date: Wed, 30 Nov 2011 15:47:19 -0800
> From: Andrew Morton <akpm@linux-foundation.org>
> To: Petr Holasek <pholasek@redhat.com>
> Cc: Hugh Dickins <hughd@google.com>, Andrea Arcangeli
> <aarcange@redhat.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
> Anton Arapov <anton@redhat.com>
> Subject: Re: [PATCH] [RFC] KSM: numa awareness sysfs knob
>
> On Wed, 30 Nov 2011 11:37:26 +0100
> Petr Holasek <pholasek@redhat.com> wrote:
>
> > Introduce a new sysfs knob /sys/kernel/mm/ksm/max_node_dist, whose
> > value will be used as the limitation for node distance of merged pages.
> >
>
> The changelog doesn't really describe why you think Linux needs this
> feature? What's the reasoning? Use cases? What value does it provide?
Typical use-case could be a lot of KVM guests on NUMA machine and cpus from
more distant nodes would have significant increase of access latency to the
merged ksm page. I chose sysfs knob for higher scalability.
>
> > index b392e49..b882140 100644
> > --- a/Documentation/vm/ksm.txt
> > +++ b/Documentation/vm/ksm.txt
> > @@ -58,6 +58,10 @@ sleep_millisecs - how many milliseconds ksmd should sleep before next scan
> > e.g. "echo 20 > /sys/kernel/mm/ksm/sleep_millisecs"
> > Default: 20 (chosen for demonstration purposes)
> >
> > +max_node_dist - maximum node distance between two pages which could be
> > + merged.
> > + Default: 255 (without any limitations)
>
> And this doesn't explain to our users why they might want to alter it,
> and what effects they would see from doing so. Maybe that's obvious to
> them...
Now I can't figure out more extensive description of this feature, but we
could explain it deeply, of course.
>
> > run - set 0 to stop ksmd from running but keep merged pages,
> > set 1 to run ksmd e.g. "echo 1 > /sys/kernel/mm/ksm/run",
> > set 2 to stop ksmd and unmerge all pages currently merged,
> >
> > ...
> >
> > +#ifdef CONFIG_NUMA
> > +static inline int node_dist(int from, int to)
> > +{
> > + int dist = node_distance(from, to);
> > +
> > + return dist == -1 ? 0 : dist;
> > +}
>
> So I spent some time grubbing around trying to work out what a return
> value of -1 from node_distance() means, and wasn't successful. Perhaps
> an explanatory comment here would have helped.
Yes, apologize, my mistake. I've overlooked that it should never return value
lower than LOCAL_DISTANCE even with CONFIG_NUMA unset. So those wrappers are
pointless and I'll remove them.
>
> > +#else
> > +static inline int node_dist(int from, int to)
> > +{
> > + return 0;
> > +}
> > +#endif
> >
> > ...
> >
> > +static ssize_t max_node_dist_store(struct kobject *kobj,
> > + struct kobj_attribute *attr,
> > + const char *buf, size_t count)
> > +{
> > + int err;
> > + unsigned long node_dist;
> > +
> > + err = kstrtoul(buf, 10, &node_dist);
> > + if (err || node_dist > 255)
> > + return -EINVAL;
>
> If kstrtoul() returned an errno we should propagate that back rather than
> overwriting it with -EINVAL.
Ok, I'll fix it.
>
> > + ksm_node_distance = node_dist;
> > +
> > + return count;
> > +}
> >
> > ...
> >
>
^ permalink raw reply
* [PATCH] irqdomain: export irq_domain_simple_ops for !CONFIG_OF
From: Jamie Iles @ 2011-12-01 10:15 UTC (permalink / raw)
To: linux-kernel; +Cc: Jamie Iles, Thomas Gleixner, Rob Herring, Grant Likely
irqdomain support is used in interrupt controller drivers that may not
have device tree support but only need the basic HW->Linux irq
translation. Rather than having each of these implement their own IRQ
domain, allow them to use the simple ops.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Rob Herring <robherring2@gmail.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
---
include/linux/irqdomain.h | 3 ++-
kernel/irq/irqdomain.c | 12 +++++++-----
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 99834e58..bd4272b 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -91,10 +91,11 @@ static inline unsigned int irq_domain_to_irq(struct irq_domain *d,
extern void irq_domain_add(struct irq_domain *domain);
extern void irq_domain_del(struct irq_domain *domain);
+
+extern struct irq_domain_ops irq_domain_simple_ops;
#endif /* CONFIG_IRQ_DOMAIN */
#if defined(CONFIG_IRQ_DOMAIN) && defined(CONFIG_OF_IRQ)
-extern struct irq_domain_ops irq_domain_simple_ops;
extern void irq_domain_add_simple(struct device_node *controller, int irq_base);
extern void irq_domain_generate_simple(const struct of_device_id *match,
u64 phys_base, unsigned int irq_start);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 200ce83..7ca523b 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -143,11 +143,6 @@ int irq_domain_simple_dt_translate(struct irq_domain *d,
return 0;
}
-struct irq_domain_ops irq_domain_simple_ops = {
- .dt_translate = irq_domain_simple_dt_translate,
-};
-EXPORT_SYMBOL_GPL(irq_domain_simple_ops);
-
/**
* irq_domain_create_simple() - Set up a 'simple' translation range
*/
@@ -182,3 +177,10 @@ void irq_domain_generate_simple(const struct of_device_id *match,
}
EXPORT_SYMBOL_GPL(irq_domain_generate_simple);
#endif /* CONFIG_OF_IRQ */
+
+struct irq_domain_ops irq_domain_simple_ops = {
+#ifdef CONFIG_OF_IRQ
+ .dt_translate = irq_domain_simple_dt_translate,
+#endif /* CONFIG_OF_IRQ */
+};
+EXPORT_SYMBOL_GPL(irq_domain_simple_ops);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 19/25] pnp: if CONFIG_DYNAMIC_DEBUG, use pnp.ddebug instead of pnp.debug
From: Thomas Renninger @ 2011-12-01 11:15 UTC (permalink / raw)
To: jim.cromie; +Cc: jbaron, greg, joe, bart.vanassche, linux-kernel, bhelgaas
In-Reply-To: <1322683014-13285-20-git-send-email-jim.cromie@gmail.com>
On Wednesday 30 November 2011 20:56:48 jim.cromie@gmail.com wrote:
> From: Jim Cromie <jim.cromie@gmail.com>
>
> resubmit of https://lkml.org/lkml/2010/9/15/398
>
> This allows usage of generic pnp.ddebug debug parameter instead of
> pnp.debug PNP specific parameter.
It depends on what you compile in which pnp debug parameter one has to use
and both are doing more or less the same?
We could add two pnp parameters in !defined(CONFIG_DYNAMIC_DEBUG) case:
- deprecate pnp.debug by a message:
"pnp.debug deprecated, use pnp.ddebug" instead
- pnp.ddebug doing what pnp.debug is doing currently
The only misleading would be that pnp.ddebug has nothing to do with
dynamic debug if not compiled in, but user would have one parameter
to rely on.
In Documentation/kernel-parameters:
pnp.debug [PNP]
Enable PNP debug messages. This depends on the
CONFIG_PNP_DEBUG_MESSAGES option.
Would be wrong in defined(CONFIG_DYNAMIC_DEBUG) case with your patch,
but would always work with:
pnp.ddebug
with my above suggestions.
It's not a big deal and not a perfect solution, just looks a bit confusing
to have 2 different parameters for the same thing.
Bjorn should have a look and acknowledge or sign the pnp parts off.
Thomas
> I wonder whether CONFIG_PNP_DEBUG_MESSAGES can vanish totally with
> this or at some time. Only advantage having it is: If you are
> restricted and your kernel must not exceed X bytes, you cannot compile
> in PNP debug messages only, but you have to compile in all debug
> messages.
>
> Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
> CC: Thomas Renninger <trenn@suse.de>
> ---
> drivers/pnp/base.h | 8 ++++++--
> drivers/pnp/core.c | 13 +++++++++++++
> 2 files changed, 19 insertions(+), 2 deletions(-)
>
...
> +#if defined(CONFIG_DYNAMIC_DEBUG)
> +static int __init pnp_debug_setup(char *__unused)
> +{
> + printk(KERN_INFO "DYNAMIC_DEBUG enabled use pnp.ddebug instead of "
> + "pnp.debug boot param\n");
> + return 1;
> +}
> +__setup("pnp.debug", pnp_debug_setup);
> +
> +#else
> +
> #if defined(CONFIG_PNP_DEBUG_MESSAGES)
> module_param_named(debug, pnp_debug, int, 0644);
> #endif
> +
> +#endif
> --
> 1.7.7.3
>
>
^ permalink raw reply
* RE: linux-next: manual merge of the staging tree with the hid tree
From: KY Srinivasan @ 2011-12-01 10:12 UTC (permalink / raw)
To: Greg KH, Stephen Rothwell
Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Thomas Meyer, Jiri Kosina
In-Reply-To: <20111201035113.GA7647@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Wednesday, November 30, 2011 10:51 PM
> To: Stephen Rothwell
> Cc: linux-next@vger.kernel.org; linux-kernel@vger.kernel.org; KY Srinivasan;
> Thomas Meyer; Jiri Kosina
> Subject: Re: linux-next: manual merge of the staging tree with the hid tree
>
> On Thu, Dec 01, 2011 at 02:39:52PM +1100, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > Today's linux-next merge of the staging tree got a conflict in
> > drivers/hid/hid-hyperv.c between commit b95f5bcb811e ("HID: Move the
> > hid-hyperv driver out of staging") from the hid tree and various commits
> > from the staging tree (this was drivers/staging/hv/hv_mouse.c).
> >
> > The commit message says that all the changes that happened when this file
> > moved from staging have also been applied to the staging file, so I just
> > used the version from the hid tree.
>
> Ok, that's fine, Jiri, want me to just delete the driver from my tree
> now to remove any of these conflicts?
Jiri,
Yesterday (Nov 30th, 2011) I had sent a patch for the mouse driver to fix a bug
that got introduced during the recent cleanup to exit staging. This patch was against
the staging tree that Greg is planning to delete. It is a trivial patch; can you pick this up
for the hid tree. If you prefer, I could rebase the patch against your tree. Let me know.
Regards,
K. Y
^ permalink raw reply
* RE: [PATCH] watchdog: fix initialisation printout in s3c2410_wdt
From: Kukjin Kim @ 2011-12-01 10:12 UTC (permalink / raw)
To: 'Wim Van Sebroeck'
Cc: 'Thomas Abraham', 'Dmitry Artamonow',
linux-kernel, linux-arm-kernel, 'Ben Dooks',
linux-watchdog
In-Reply-To: <20111201090934.GO23376@infomag.iguana.be>
Wim Van Sebroeck wrote:
>
> Hi Kim,
>
> > Thomas Abraham wrote:
> > >
> > > On 16 November 2011 14:16, Dmitry Artamonow <mad_soft@inbox.ru> wrote:
> > > > Looks like a typo creeped in, and driver prints
> > > > s3c2410-wdt s3c2410-wdt: watchdog active, reset abled, irq abled
> > > >
> > > > instead of
> > > > s3c2410-wdt s3c2410-wdt: watchdog active, reset enabled, irq enabled
> > > >
> > > > Also it may completely disinform about irq status, as it prints
> > > > "irq enabled" when S3C2410_WTCON_INTEN is in fact 0.
> > > >
> > > > Fix it.
> > > >
> > > > Signed-off-by: Dmitry Artamonow <mad_soft@inbox.ru>
> > > > ---
> > > >
> > > > It seems to be here for a long time, but I don't think it's
> > > > important enough for cc-ing stable.
> > > >
> > > > Also I haven't tested it, as I don't have a hardware, but it's
> > > > rather trivial (and yes, I checked with datasheet that 1 in
> > > > S3C2410_WTCON_*EN bits really means 'enabled')
> > > >
> > >
> > > Tested on Exynos4210 based Origen board. This patch fixed in incorrect
> > > "irq enabled" message at bootup. Thanks for this fix.
> > >
> > > Tested-by: Thomas Abraham <thomas.abraham@linaro.org>
> > >
> >
> > Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> >
> > Hi Wim,
> > Please pick this up in your tree and if any problem, let me know.
>
> See commit 20403e845f9988446c5b48024ff4d0c3a5929f7d in the linux git tree.
>
OK :)
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* Re: [PATCH 2/2 v4] pinctrl: introduce generic pin config
From: Linus Walleij @ 2011-12-01 10:11 UTC (permalink / raw)
To: Stephen Warren
Cc: Linus Walleij, linux-kernel@vger.kernel.org, Grant Likely,
Barry Song, Shawn Guo, Thomas Abraham, Dong Aisheng,
Rajendra Nayak
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF174FDAFF30@HQMAIL01.nvidia.com>
On Wed, Nov 30, 2011 at 8:45 PM, Stephen Warren <swarren@nvidia.com> wrote:
> Linus Walleij wrote at Thursday, November 24, 2011 11:46 AM:
>> +void pinconf_generic_dump_pin(struct pinctrl_dev *pctldev,
> ...
>> + for(i = 0; i < ARRAY_SIZE(conf_items); i++) {
> ...
>> + /* We want to check out this parameter */
>> + config = (unsigned long) conf_items[i].param;
>
> Don't you need to use to_config_packed() here?
Yep! Fixed it.
>> + ret = pin_config_get(pctldev, pin, &config);
>> + /* These are legal errors */
>> + if (ret == -EINVAL || ret == -ENOTSUPP)
>> + continue;
>
> Ah, I guess I see why you consider -ENOTSUPP an error that you don't want
> to print to syslog. Maybe you should call _pin_config_get() here which
> doesn't spew messages on -ENOTSUPP, but have the public pin_config_get()
> function spew errors.
I just deleted the error check for now since it's not necessary.
Better keep the code compact and simple.
>> + if (ret) {
>> + seq_printf(s, "ERROR READING CONFIG SETTING %d ", i);
>> + continue;
>> + }
>> + /* Space between multiple configs */
>> + seq_puts(s, " ");
>> + seq_puts(s, conf_items[i].display);
>> + /* Print unit if available */
>> + if (conf_items[i].format && config != 0)
>> + seq_printf(s, " (%lu %s)", config,
>> + conf_items[i].format);
>
> Don't you need to use to_config_argument() here?
Yes. I'm too sloppy :-(
>> @@ -169,6 +169,8 @@ static void pinconf_dump_pin(struct pinctrl_dev *pctldev,
>> {
>> const struct pinconf_ops *ops = pctldev->desc->confops;
>>
>> + /* no-op when not using generic pin config */
>> + pinconf_generic_dump_pin(pctldev, s, pin);
>> if (ops && ops->pin_config_dbg_show)
>> ops->pin_config_dbg_show(pctldev, s, pin);
>> }
>
> This is really a comment on the previous patch, but what about config
> params that only apply to groups?
Oh! I need to create a separate debugfs file for that.
Thanks for this nice catch!
>> diff --git a/include/linux/pinctrl/pinconf-generic.h b/include/linux/pinctrl/pinconf-generic.h
>
>> +/*
>> + * You shouldn't even be able to compile with these enums etc unless you're
>> + * using generic pin config. That is why this is defined out.
>> + */
>> +#ifdef CONFIG_GENERIC_PINCONF
>
> Hmm. I'd prefer to have drivers able to use both generic values and
> extend them with custom values. Can't we just use the top bit of the
> param value to indicate 0:standard (from the enum below) 1:custom
> (something meaningful to only the individual pinctrl driver). This
> could then trigger calling pinconf_generic_dump_pin() or not for
> example.
Hm...
That will get messy when if I refactor this stuff, add new enums
and whatever.
>> +#ifdef CONFIG_GENERIC_PINCONF
>> + bool is_generic;
>> +#endif
>
> ... and get rid of that flag.
This is for the case wher you have both generic and non-generic
config controllers onboard a system.
Like in the generic debugfs dump function:
if (!ops->is_generic)
return;
If I take this out, the generic debugfs code will be used for
everything.
And then the generic sematics which you didn't like in the
previous patch:
if (ret == -EINVAL || ret == -ENOTSUPP)
Need to go back in, else the generic debugfs stuff won't
work.
I'm really not sure about that kind of extension, it feels to
me like a hard-to grasp unstable middleground between two
clean-cut solutions "all custom" or "all generic".
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2a/5 v2] ARM: OMAP1: select clock rate by CPU type
From: Janusz Krzysztofik @ 2011-12-01 10:10 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Paul Walmsley, linux-omap, linux-arm-kernel, linux-kernel
In-Reply-To: <20111130222837.GR31337@atomide.com>
On Wednesday 30 of November 2011 at 23:28:38, Tony Lindgren wrote:
>
> We should also now be able to remove all the CONFIG_OMAP_ARM_XXXMHZ options
> too, right?
Right, but then, perhaps the initial version of patch 2a/5, which
already started removing them, from omap1_defconfig for now, then going
into the right direction while unblocking another regression fix (3/5),
_is_ a good candidate for an rc fix?
Thanks,
Janusz
^ permalink raw reply
* Re: [PATCH 1/2 v4] pinctrl: add a pin config interface
From: Linus Walleij @ 2011-12-01 9:59 UTC (permalink / raw)
To: Stephen Warren
Cc: Linus Walleij, linux-kernel@vger.kernel.org, Grant Likely,
Barry Song, Shawn Guo, Thomas Abraham, Dong Aisheng,
Rajendra Nayak
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF174FDAFF07@HQMAIL01.nvidia.com>
On Wed, Nov 30, 2011 at 8:19 PM, Stephen Warren <swarren@nvidia.com> wrote:
> Linus Walleij wrote at Thursday, November 24, 2011 11:46 AM:
>> @@ -315,6 +317,7 @@ int pinctrl_get_group_selector(struct pinctrl_dev *pctldev,
>> return -EINVAL;
>> }
>>
>> +
>
> That's probably an accident?
Yes, fixed it.
>> +/**
>> + * pin_config_get() - get the configuration of a single pin parameter
>> + * @pctldev: pin controller device for this pin
>> + * @pin: pin to get the config for
>> + * @config: this config tuple will be filled in with the setting for
>> + * the requested parameter, so the .param part of this setting must
>> + * me set when calling the function
>
> I don't like muxing the param and value together in a single parameter;
> it requires a bunch of bit-shifting to create them, modify the value
> here, and extract values. Why not just have "param" and "value" function
> parameters like the old patches?
Because since we move to the concept of the core not knowing what
it is passing around, it is better to just have an unsigned long and let
the driver and its board file/device tree decide what to do with it.
Since I don't have any enum for the param anymore, it would
just be another unsigned long, so what's the point?
Either the core knows the params (as was proposed earlier and
is now optional) or it knows nothing, in which case an opaque
unsigned long should fit the bill. Passing two unsigned longs
with undefined semantics is just sort of half-guessing what drivers
need I don't like the looks of that.
The opaque unsigned long passed here can be cast to anything,
just like we do with interrupts. Could be void * but that is more a
matter of taste. unsigned long is nice for implementations that
just want to cast that to some enum (like the patch to the
in-tree driver).
In the driver for the situation you want:
<mach/my-config.h>:
struct my_config {
enum my_param;
unsigned long my_value;
};
pinctrl/my-driver.c:
#include <mach/my-config.h>
int foo_pin_config_get(struct pinctrl_dev *pctldev,
unsigned pin,
unsigned long *config)
{
struct my_config *conf = (struct my_config *) *config;
...
}
int foo_pin_config_set(struct pinctrl_dev *pctldev,
unsigned pin,
unsigned long config)
{
struct my_config *conf = (struct my_config *) config;
...
}
In the U300 pinmux driver the split between parameter and
argument is unnecessary so it just casts (assigns really) the
unsigned long config to it's enum, and pass it along. Thus it
gets really slim without needing to pass around an ununsed
unsigned long to all functions.
Driver that want complex arguments can still pass them around
per above.
Will this work for you?
> In the description of @config, there is no ".param part of this setting"
> since this isn't a struct in this version of the patch.
Thanks, taking it out.
>> +int pin_config_get(struct pinctrl_dev *pctldev, int pin,
>> + unsigned long *config)
> ...
>> + ret = ops->pin_config_get(pctldev, pin, config);
>> + /*
>> + * -EINVAL is OK, it means the setting is not active right now
>
> That doesn't really make sense; given it's a param/value thing, a
> particular param can't be "not active"; it has a particular value or
> not.
Yeah that's generic pin config semantics, I'll take it out, remove the
debug print and put it in the generic config documentation.
> There's no pin_config_group_get()?
I've added it for symmetry, but will that work in practice?
Say you pin_config_group_get() and pins have wildly different
settings, what do you return?
Since it's now up to the driver I've added it, I just want to
make sure there is a solid use case for it.
>> + * -ENOTSUPP just means that setting is not available and is also OK
>> + */
>> + if (ret == -EINVAL || ret == -ENOTSUPP)
>> + return ret;
>> + if (ret) {
>> + dev_err(&pctldev->dev,
>> + "unable to get pin configuration on pin %d\n", pin);
>
> This is always true; why make the dev_err() conditional at all? Especially
> attempts to retrieve unsupported parameters should be logged.
This hunk is taken out per above.
>> +int pin_config_group(struct pinctrl_dev *pctldev, const char *pin_group,
>> + unsigned long config)
> ...
>> + /*
>> + * If the controller cannot handle entire groups, we configure each pin
>> + * individually.
>> + */
>
> I don't really like the automatic fallback; a particular param is either
> valid for a group or a pin, and the user really should be setting it on
> the appropriate one. Still, for drivers where the fallback never makes
> sense, we can just never return -EAGAIN, so can disable this if we want,
> so I guess it's fine.
Yep, the fallback is not automatic as you say, drivers have to request
the fallback by returning -EAGAIN, which they are unlikely to do
by chance.
>> +int pinconf_check_ops(const struct pinconf_ops *ops)
>> +{
>> + /* We must be able to read out pin status */
>> + if (!ops->pin_config_get)
>> + return -EINVAL;
>
> What if there are no per-pin configuration parameters?
Yes and another case for adding ops->pin_config_group_get()
so now it looks like this:
if (!ops->pin_config_get && !ops->pin_config_group_get)
return -EINVAL;
> ... [debugfs code]
>> +#else
>> +
>> +#endif
>
> Should there be something inside the #else? If not, perhaps just write
> #endif without #else?
True! The stuf in pin pinconf.h.
>> diff --git a/include/linux/pinctrl/pinconf.h b/include/linux/pinctrl/pinconf.h
>
>> +extern int pin_config_get(struct pinctrl_dev *pctldev, int pin,
>> + unsigned long *config);
>> +extern int pin_config_set(struct pinctrl_dev *pctldev, int pin,
>> + unsigned long config);
>> +extern int pin_config_group(struct pinctrl_dev *pctldev, const char *pin_group,
>> + unsigned long config);
>
> I don't really like exposing these as public APIs; I don't see any need
> for drivers to be explicitly configuring pins, just like they don't
> explicitly request a particular mux option, but rather there's a mapping
> table which determines the configuration the device needs. I think pin
> config options should be included in the mapping table, or a parallel
> pin config table.
I know this, but we need this as a foundation for the driver interface.
Without something like this we cannot test the patch set in isolation
and develop in steps.
> Still, this patch will give me what I need to implement the pin config
> part of the Tegra pinctrl driver, so I won't push back too hard on this
> for now, but I think eventually these APIs will just go away.
If there are no in-kernel users at some point later down the road
they can be deleted.
If there are in-kernel users ... they may be useful.
>> +static inline int pin_config_get(struct pinctrl_dev *pctldev, int pin,
>> + unsigned long *config)
>> +{
>> + return 0;
>> +}
>
> Shouldn't at least pin_config_get() return an error. It seems like both
> pin_config_set() and pin_config_group() don't do what they're asked, so
> they should also return an error. gpiolib takes that approach; e.g.
> gpio_direction_input() fails in the dummy case.
We already allow say pinmux_enable() to succeed if pinmux
is compiled out.
My idea was that it would be good for debugging to say disable
the pinctrl altogether, then leave pins in their power-on state
and no calls into the framework will even touch them, so you
can see what happens. (This I think is partly the intention of the
clk and regulator stubs.)
Having this return errors will make such binaries with pinconf
compiled-out just not boot if the error codes are handled
correctly, which is not very helpful.
Maybe I'm getting this all wrong?
I'll send a v5 patchset as soon as I've reviewed the comments
on the other patch.
Thanks!
Linus Walleij
^ permalink raw reply
* Different behaviour when using "nosmp" parameter on SMP and UP
From: Jean-Michel Hautbois @ 2011-12-01 9:57 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev
Hi,
I have a P2020 CPU (powerpc) and I compiled it with two different defconfigs.
The first one is a SMP, 2 cores, launched with the "nosmp" kernel
parameter, the other one is an UP kernel.
My driver behaviour is not the same whether launching one or the
other. It is hard to explain more precisely, as it deals only with
ioctl which only does ioread32/iowrite32 on a PCIe device.
But I can tell that it never works the same way when UP (not working
correctly), or SMP "nosmp" (working) or even SMP (not working).
AFAIK, the "nosmp" parameter should tell the kernel to act the same is
if it is an UP kernel, and it disables IO APIC, which is not an issue
in my case.
Can you think about anything that would explain it, or would help me
debugging it ?
Thanks in advance for your help.
Regards,
JM
^ permalink raw reply
* Re: [PATCH] mm: incorrect overflow check in shrink_slab()
From: Xi Wang @ 2011-12-01 9:57 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Andrew Morton, Mel Gorman, Minchan Kim, Johannes Weiner, linux-mm,
linux-kernel
In-Reply-To: <20111201183202.2e5bd872.kamezawa.hiroyu@jp.fujitsu.com>
On Dec 1, 2011, at 4:32 AM, KAMEZAWA Hiroyuki wrote:
> Nice catch but.... the 'total_scan" shouldn't be long ?
> Rather than type casting ?
Could be.. I am just trying to avoid signed integer overflow like
"total_scan += delta" in that case, which is undefined, even though
the kernel is compiled with -fno-strict-overflow.
- xi
^ permalink raw reply
* Re: [PATCH 2a/5] Remove unsafe clock values from omap1_defconfig
From: Janusz Krzysztofik @ 2011-12-01 9:54 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Paul Walmsley, linux-omap, linux-arm-kernel, linux-kernel
In-Reply-To: <20111201022750.GY13928@atomide.com>
I've unintentionally answered off-line, sorry, re-adding all Cc:'s.
On Thursday 01 of December 2011 at 03:27:51, Tony Lindgren wrote:
> * Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [111130 17:40]:
> > On Wednesday 30 of November 2011 at 23:32:42, Tony Lindgren wrote:
> > >
> > > Can you please split your series into two: Fix(es) for the -rc cycle,
> > > then patches that can be left for the next merge window.
> >
> > From my point of view, all 5 are important fixes. Please decide
> > yourself, having the following information provided:
> >
> > 1/5: inspired by in-line comments about running from sram requirement
> > (works without this one for me),
> >
> > 2/5: without this one, system clock runs way too fast if dpll1 is
> > reprogrammed to default rate,
> >
> > 3/5: without this one, all boards with bootloaders not setting rate
> > correctly, like Amstrad Delta, will run at default rate, despite
> > any .config selections, no matter if omap1_defconfig or custom,
> >
> > 2a/5: required by 3/5,
> >
> > 5/5: without this one, BogoMIPS is not updated after dpll1 reprogramme,
> > breaking omap_keypad at least.
> >
> > and please let me know which I should resend as fixes and which not.
>
> How about 2 and 5 as fixes during the -rc, then the rest for the
> merge window? That is assuming that those are enough for you to have
> things mostly working.
If you still ask me for my opinion: with patch 3/5 omitted, then not
being able to run at any other frequency than 60 MHz instead of usual
150 since the board support was introduced first, isn't this a
regression? Having a choice of upgrading to 3.2 and running my
application on not very powerfull board at 60 MHz, or keep running 3.1
at 150, guess what I chose? If I were a distro kernel package
maintainer, guess what I would chose?
> It seems that we've had the issue of not actually changing the rate
> for a while, right?
This was not an issue before dpll1 reprogramming has been moved out from
omap1_clk_init(), as an rc fix to another bug introduced in 3.2. Perhaps
we should rather think of reverting a few commits which caused all these
problems if fixing them all during rc cycle seems not possible? I
haven't bisected them yet, rather concentrated on providing fixes, but I
can still try to do it, starting back from the original issue
(http://www.spinics.net/lists/linux-omap/msg60052.html), if so decided.
> If that's the case, I'd rather not start messing
> with that during the -rc cycle.
>
> Regards,
>
> Tony
I don't feel like a person who makes the final decision.
Anyway, did you mean resending those 2/5 and 5/5 without any changes,
only renumbered as 1/2 and 2/2?
Thanks,
Janusz
^ permalink raw reply
* Build warnings - v3.2-rc3-187-g11d814a
From: Dave Haywood @ 2011-12-01 9:40 UTC (permalink / raw)
To: Linux Kernel
Hi,
Noticed the build warnings below from v3.2-rc3-187-g11d814a.
$ gcc --version
gcc (Gentoo Hardened 4.6.2 p1.0, pie-0.4.5) 4.6.2
$ uname -a
Linux s1 3.2.0-rc3 #97 SMP Fri Nov 25 10:17:10 GMT 2011 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux
...
CC fs/binfmt_misc.o
In file included from ~/git/linux/arch/x86/include/asm/uaccess.h:573:0,
from include/linux/uaccess.h:5,
from include/linux/highmem.h:7,
from include/linux/pagemap.h:10,
from fs/binfmt_misc.c:26:
~/git/linux/arch/x86/include/asm/uaccess_32.h: In function 'parse_command.part.2':
~/git/linux/arch/x86/include/asm/uaccess_32.h:211:26: warning: call to 'copy_from_user_overflow' declared with attribute warning: copy_from_user() buffer size is not provably correct [enabled by default]
...
CC drivers/md/dm-table.o
drivers/md/dm-table.c: In function 'dm_table_set_integrity':
drivers/md/dm-table.c:1285:3: warning: statement with no effect [-Wunused-value]
...
CC drivers/usb/host/ohci-hcd.o
In file included from drivers/usb/host/ohci-hcd.c:101:0:
drivers/usb/host/ohci-dbg.c: In function 'fill_registers_buffer':
drivers/usb/host/ohci-dbg.c:642:2: warning: the comparison will always evaluate as 'true' for the address of 'next' will never be NULL [-Waddress]
drivers/usb/host/ohci-dbg.c:661:3: warning: the comparison will always evaluate as 'true' for the address of 'next' will never be NULL [-Waddress]
...
HOSTCC arch/x86/boot/compressed/relocs
arch/x86/boot/compressed/relocs.c: In function 'print_absolute_symbols':
arch/x86/boot/compressed/relocs.c:405:14: warning: variable 'sh_symtab' set but not used [-Wunused-but-set-variable]
arch/x86/boot/compressed/relocs.c: In function 'emit_relocs':
arch/x86/boot/compressed/relocs.c:605:9: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result [-Wunused-result]
arch/x86/boot/compressed/relocs.c:612:10: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result [-Wunused-result]
Regards,
Dave.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox