Re: [PATCH] KVM: mmu: allow page tables to be in read-only slots
On Mon, Sep 02, 2013 at 06:05:10PM +0800, Xiao Guangrong wrote:
On 09/02/2013 05:49 PM, Gleb Natapov wrote:
On Mon, Sep 02, 2013 at 05:42:25PM +0800, Xiao Guangrong wrote:
On 09/01/2013 05:17 PM, Gleb Natapov wrote:
On Fri, Aug 30, 2013 at 02:41:37PM +0200, Paolo Bonzini wrote:
Page tables in a read-only memory slot will currently cause a triple
fault because the page walker uses gfn_to_hva and it fails on such a
slot.
OVMF uses such a page table; however, real hardware seems to be fine with
that as long as the accessed/dirty bits are set. Save whether the slot
is readonly, and later check it when updating the accessed and dirty
bits.
The fix looks OK to me, but some comment below.
Cc: sta...@vger.kernel.org
Cc: g...@redhat.com
Cc: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
CCing to stable@ since the regression was introduced with
support for readonly memory slots.
arch/x86/kvm/paging_tmpl.h | 7 ++-
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c| 14 +-
3 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 0433301..dadc5c0 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -99,6 +99,7 @@ struct guest_walker {
pt_element_t prefetch_ptes[PTE_PREFETCH_NUM];
gpa_t pte_gpa[PT_MAX_FULL_LEVELS];
pt_element_t __user *ptep_user[PT_MAX_FULL_LEVELS];
+bool pte_writable[PT_MAX_FULL_LEVELS];
unsigned pt_access;
unsigned pte_access;
gfn_t gfn;
@@ -235,6 +236,9 @@ static int FNAME(update_accessed_dirty_bits)(struct
kvm_vcpu *vcpu,
if (pte == orig_pte)
continue;
+if (unlikely(!walker-pte_writable[level - 1]))
+return -EACCES;
+
ret = FNAME(cmpxchg_gpte)(vcpu, mmu, ptep_user, index,
orig_pte, pte);
if (ret)
return ret;
@@ -309,7 +313,8 @@ retry_walk:
goto error;
real_gfn = gpa_to_gfn(real_gfn);
-host_addr = gfn_to_hva(vcpu-kvm, real_gfn);
+host_addr = gfn_to_hva_read(vcpu-kvm, real_gfn,
+
walker-pte_writable[walker-level - 1]);
The use of gfn_to_hva_read is misleading. The code can still write into
gfn. Lets rename gfn_to_hva_read to gfn_to_hva_prot() and gfn_to_hva()
to gfn_to_hva_write().
Yes. I agreed.
This makes me think are there other places where gfn_to_hva() was
used, but gfn_to_hva_prot() should have been?
- kvm_host_page_size() looks incorrect. We never use huge page to map
read only memory slots currently.
It only checks whether gfn have been mapped, I think we can use
gfn_to_hva_read() instead, the real permission will be checked when we
translate
the gfn to pfn.
Yes, all the cases I listed should be changed to use function that looks
at both regular and RO slots.
- kvm_handle_bad_page() also looks incorrect and may cause incorrect
address to be reported to userspace.
I have no idea on this point. kvm_handle_bad_page() is called when it
failed to
translate the target gfn to pfn, then the emulator can detect the error on
target gfn
properly. no? Or i misunderstood your meaning?
I am talking about the following code:
if (pfn == KVM_PFN_ERR_HWPOISON) {
kvm_send_hwpoison_signal(gfn_to_hva(vcpu-kvm, gfn),
current);
return 0;
}
pfn will be KVM_PFN_ERR_HWPOISON gfn is backed by faulty memory, we need
to report the liner address of the faulty memory to a userspace here,
but if gfn is in a RO slot gfn_to_hva() will not return correct address
here.
Got it, thanks for your explanation.
BTW, if you and Paolo are busy on other things, i am happy to fix these
issues. :)
I am busy with reviews mostly :). If you are not to busy with lockless
write protection then fine with me. Lest wait for Paolo's input on
proposed API though.
--
Gleb.
--
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/
[char-misc-next 0/3] mei: few more reset recursion fixes
*** BLURB HERE *** Alexander Usyskin (1): mei: cancel stall timers in mei_reset Tomas Winkler (2): mei: make me client counters less error prone mei: bus: stop wait for read during cl state transition drivers/misc/mei/amthif.c | 1 + drivers/misc/mei/bus.c | 5 - drivers/misc/mei/client.h | 6 ++ drivers/misc/mei/hbm.c | 10 ++ drivers/misc/mei/init.c| 3 +++ drivers/misc/mei/main.c| 11 --- drivers/misc/mei/mei_dev.h | 6 +++--- 7 files changed, 27 insertions(+), 15 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[char-misc-next 3/3] mei: cancel stall timers in mei_reset
From: Alexander Usyskin alexander.usys...@intel.com Unset init_clients_timer and amthif_stall_timers in mei_reset in order to cancel timer ticking and hence avoid recursive reset calls. Cc: sta...@vger.kernel.org # 3.9+ Signed-off-by: Alexander Usyskin alexander.usys...@intel.com Signed-off-by: Tomas Winkler tomas.wink...@intel.com --- drivers/misc/mei/amthif.c | 1 + drivers/misc/mei/init.c | 3 +++ 2 files changed, 4 insertions(+) diff --git a/drivers/misc/mei/amthif.c b/drivers/misc/mei/amthif.c index d0fdc13..f6ff711 100644 --- a/drivers/misc/mei/amthif.c +++ b/drivers/misc/mei/amthif.c @@ -57,6 +57,7 @@ void mei_amthif_reset_params(struct mei_device *dev) dev-iamthif_ioctl = false; dev-iamthif_state = MEI_IAMTHIF_IDLE; dev-iamthif_timer = 0; + dev-iamthif_stall_timer = 0; } /** diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c index 92c7311..6197018 100644 --- a/drivers/misc/mei/init.c +++ b/drivers/misc/mei/init.c @@ -175,6 +175,9 @@ void mei_reset(struct mei_device *dev, int interrupts_enabled) memset(dev-wr_ext_msg, 0, sizeof(dev-wr_ext_msg)); } + /* we're already in reset, cancel the init timer */ + dev-init_clients_timer = 0; + dev-me_clients_num = 0; dev-rd_msg_hdr = 0; dev-wd_pending = false; -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[char-misc-next 1/3] mei: make me client counters less error prone
1. u8 counters are prone to hard to detect overflow:
make them unsigned long to match bit_ functions argument type
2. don't check me_clients_num for negativity, it is unsigned.
3. init all the me client counters from one place
Cc: sta...@vger.kernel.org # 3.9+
Signed-off-by: Tomas Winkler tomas.wink...@intel.com
---
drivers/misc/mei/hbm.c | 10 ++
drivers/misc/mei/mei_dev.h | 6 +++---
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c
index f706fe8..52afe1e 100644
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -35,11 +35,15 @@ static void mei_hbm_me_cl_allocate(struct mei_device *dev)
struct mei_me_client *clients;
int b;
+ dev-me_clients_num = 0;
+ dev-me_client_presentation_num = 0;
+ dev-me_client_index = 0;
+
/* count how many ME clients we have */
for_each_set_bit(b, dev-me_clients_map, MEI_CLIENTS_MAX)
dev-me_clients_num++;
- if (dev-me_clients_num = 0)
+ if (dev-me_clients_num == 0)
return;
kfree(dev-me_clients);
@@ -221,7 +225,7 @@ static int mei_hbm_prop_req(struct mei_device *dev)
struct hbm_props_request *prop_req;
const size_t len = sizeof(struct hbm_props_request);
unsigned long next_client_index;
- u8 client_num;
+ unsigned long client_num;
client_num = dev-me_client_presentation_num;
@@ -680,8 +684,6 @@ void mei_hbm_dispatch(struct mei_device *dev, struct
mei_msg_hdr *hdr)
if (dev-dev_state == MEI_DEV_INIT_CLIENTS
dev-hbm_state == MEI_HBM_ENUM_CLIENTS) {
dev-init_clients_timer = 0;
- dev-me_client_presentation_num = 0;
- dev-me_client_index = 0;
mei_hbm_me_cl_allocate(dev);
dev-hbm_state = MEI_HBM_CLIENT_PROPERTIES;
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index 7b918b2..456b322 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -396,9 +396,9 @@ struct mei_device {
struct mei_me_client *me_clients; /* Note: memory has to be allocated */
DECLARE_BITMAP(me_clients_map, MEI_CLIENTS_MAX);
DECLARE_BITMAP(host_clients_map, MEI_CLIENTS_MAX);
- u8 me_clients_num;
- u8 me_client_presentation_num;
- u8 me_client_index;
+ unsigned long me_clients_num;
+ unsigned long me_client_presentation_num;
+ unsigned long me_client_index;
struct mei_cl wd_cl;
enum mei_wd_states wd_state;
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount
On Sun, Sep 1, 2013 at 5:55 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Sun, Sep 1, 2013 at 8:45 AM, Sedat Dilek sedat.di...@gmail.com wrote: Samples: 160K of event 'cycles:pp', Event count (approx.): 77003901089 + 12,46% t_lockref_from- [kernel.kallsyms] [k] irq_return + 4,86% t_lockref_from- [kernel.kallsyms] [k] lockref_get_or_lock + 4,42% t_lockref_from- [kernel.kallsyms] [k] __ticket_spin_lock + 4,28% t_lockref_from- [kernel.kallsyms] [k] __acct_update_integrals You need to go into __ticket_spin_lock to see who the callers are. Just go down to it and press enter to expand it (and then you need to go and expand that entry too to get the callers) I am new to perf usage. 4,60% t_lockref_from- [kernel.kallsyms] [k] __ticket_spin_lock Which entry to select? Annotate __ticket_spin_lock Zoom into t_lockref_from-(3962) thread Zoom into the Kernel DSO Browse map details Run scripts for samples of thread [t_lockref_from-] Run scripts for samples of symbol [__ticket_spin_lock] Run scripts for all samples Switch to another data file in PWD Exit I still don't know how you get to irq_return. It should use sysret. Odd. - Sedat - -- 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/
[char-misc-next 2/3] mei: bus: stop wait for read during cl state transition
Bus layer omitted check for client state transition while waiting
for read completion
The client state transition may occur for example as result
of firmware initiated reset
Add mei_cl_is_transitioning wrapper to reduce the code
repetition.:
Cc: sta...@vger.kernel.org # 3.9+
Signed-off-by: Tomas Winkler tomas.wink...@intel.com
---
drivers/misc/mei/bus.c| 5 -
drivers/misc/mei/client.h | 6 ++
drivers/misc/mei/main.c | 11 ---
3 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index a150a42..f5dabb3 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -295,10 +295,13 @@ int __mei_cl_recv(struct mei_cl *cl, u8 *buf, size_t
length)
if (cl-reading_state != MEI_READ_COMPLETE
!waitqueue_active(cl-rx_wait)) {
+
mutex_unlock(dev-device_lock);
if (wait_event_interruptible(cl-rx_wait,
- (MEI_READ_COMPLETE == cl-reading_state))) {
+ cl-reading_state == MEI_READ_COMPLETE ||
+ mei_cl_is_transitioning(cl))) {
+
if (signal_pending(current))
return -EINTR;
return -ERESTARTSYS;
diff --git a/drivers/misc/mei/client.h b/drivers/misc/mei/client.h
index 9eb031e..892cc42 100644
--- a/drivers/misc/mei/client.h
+++ b/drivers/misc/mei/client.h
@@ -90,6 +90,12 @@ static inline bool mei_cl_is_connected(struct mei_cl *cl)
cl-dev-dev_state == MEI_DEV_ENABLED
cl-state == MEI_FILE_CONNECTED);
}
+static inline bool mei_cl_is_transitioning(struct mei_cl *cl)
+{
+ return (MEI_FILE_INITIALIZING == cl-state ||
+ MEI_FILE_DISCONNECTED == cl-state ||
+ MEI_FILE_DISCONNECTING == cl-state);
+}
bool mei_cl_is_other_connecting(struct mei_cl *cl);
int mei_cl_disconnect(struct mei_cl *cl);
diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c
index 7404584..b8f8604 100644
--- a/drivers/misc/mei/main.c
+++ b/drivers/misc/mei/main.c
@@ -255,19 +255,16 @@ static ssize_t mei_read(struct file *file, char __user
*ubuf,
mutex_unlock(dev-device_lock);
if (wait_event_interruptible(cl-rx_wait,
- (MEI_READ_COMPLETE == cl-reading_state ||
-MEI_FILE_INITIALIZING == cl-state ||
-MEI_FILE_DISCONNECTED == cl-state ||
-MEI_FILE_DISCONNECTING == cl-state))) {
+ MEI_READ_COMPLETE == cl-reading_state ||
+ mei_cl_is_transitioning(cl))) {
+
if (signal_pending(current))
return -EINTR;
return -ERESTARTSYS;
}
mutex_lock(dev-device_lock);
- if (MEI_FILE_INITIALIZING == cl-state ||
- MEI_FILE_DISCONNECTED == cl-state ||
- MEI_FILE_DISCONNECTING == cl-state) {
+ if (mei_cl_is_transitioning(cl)) {
rets = -EBUSY;
goto out;
}
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ACPI / LPSS: don't crash if a device has no MMIO resources
Intel LPSS devices that are enumerated from ACPI have both MMIO and IRQ
resources returned in their _CRS method. However, Apple Macbook Air with
Haswell has LPSS devices enumerated from PCI bus instead and _CRS method
returns only an interrupt number (but the device has _HID set that causes
the scan handler to match it).
The current ACPI / LPSS code sets pdata-dev_desc only when MMIO resource
is found for the device and in case of Macbook Air it is never found. That
leads to a NULL pointer dereference in register_device_clock().
Correct this by always setting the pdata-dev_desc.
Reported-and-tested-by: Imre Kaloz ka...@openwrt.org
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
Cc: sta...@vger.kernel.org # 3.10+
---
drivers/acpi/acpi_lpss.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 6a38218..fb78bb9 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -257,12 +257,13 @@ static int acpi_lpss_create_device(struct acpi_device
*adev,
pdata-mmio_size = resource_size(rentry-res);
pdata-mmio_base = ioremap(rentry-res.start,
pdata-mmio_size);
- pdata-dev_desc = dev_desc;
break;
}
acpi_dev_free_resource_list(resource_list);
+ pdata-dev_desc = dev_desc;
+
if (dev_desc-clk_required) {
ret = register_device_clock(adev, pdata);
if (ret) {
--
1.8.4.rc3
--
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 RESEND 2/3] x86, mm: Update min_pfn_mapped in add_pfn_range_mapped().
In current kernel, we update min_pfn_mapped and max_pfn_mapped like this:
init_mem_mapping()
{
while ( a loop iterates all memory ranges ) {
init_range_memory_mapping();
|-init_memory_mapping()
|-kernel_physical_mapping_init()
|-add_pfn_range_mapped()
|- update max_pfn_mapped;
update min_pfn_mapped;
}
}
max_pfn_mapped is updated in add_pfn_range_mapped() when a range of memory
is mapped. But min_pfn_mapped is updated in init_mem_mapping(). We can also
update min_pfn_mapped in add_pfn_range_mapped().
Signed-off-by: Tang Chen tangc...@cn.fujitsu.com
---
arch/x86/mm/init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 5b2eaca..a97749f 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -313,6 +313,7 @@ static void add_pfn_range_mapped(unsigned long start_pfn,
unsigned long end_pfn)
nr_pfn_mapped = clean_sort_range(pfn_mapped, E820_X_MAX);
max_pfn_mapped = max(max_pfn_mapped, end_pfn);
+ min_pfn_mapped = min(min_pfn_mapped, start_pfn);
}
bool pfn_range_is_mapped(unsigned long start_pfn, unsigned long end_pfn)
@@ -442,7 +443,6 @@ void __init init_mem_mapping(void)
new_mapped_ram_size = init_range_memory_mapping(start,
last_start);
last_start = start;
- min_pfn_mapped = last_start PAGE_SHIFT;
/* only increase step_size after big range get mapped */
if (new_mapped_ram_size mapped_ram_size)
step_size = STEP_SIZE_SHIFT;
--
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 RFC 00/16] EFI stub for ARM
On Tue, 13 Aug, at 10:58:16AM, Roy Franz wrote: Hi Matt, Do you have any more feedback on the X86 and common code (patches 1-13) that needs to be addressed? Mark Salter has a working ARM64 EFI stub implemented based on these patches, so the common code has now been tested with another architecture, and he has acked these patches. If the current patches are OK, can this be queued for 3.12? (and into linux-next, if appropriate) The ARM portion may take a little longer based on the EFI runtime services patch dependencies, but getting the common code merged would allow the ARM64 EFI stub work to go forward independently. I can resend patches 1-13 as a new series of x86/common only changes if you would like. I think resending the common patches as a new series, including Acked-by and Reviewed-by tags, and after addressing Grant's comments is the best idea. We've missed the v3.12 merge window now, but we can certainly get these into linux-next for some testing. -- Matt Fleming, Intel Open Source Technology Center -- 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 RESEND 0/3] x86, ACPI, mm: Cleanup for {max|low|max_low}_pfn_mapped.
This patch-set does the following: 1. Kill max_low_pfn_mapped as it is useless. This patch is from Yinghai. 2. Update min_pfn_mapped and max_pfn_mapped together in add_pfn_range_mapped(). 3. Move definition of max_pfn_mapped tp init.c together with min_pfn_mapped. Tang Chen (2): x86, mm: Update min_pfn_mapped in add_pfn_range_mapped(). x86, mm: Move max_pfn_mapped definition to init.c. Yinghai Lu (1): x86, ACPI, mm: Kill max_low_pfn_mapped. arch/x86/include/asm/page_types.h |1 - arch/x86/kernel/setup.c | 10 -- arch/x86/mm/init.c| 15 ++- drivers/acpi/osl.c|6 +++--- 4 files changed, 13 insertions(+), 19 deletions(-) -- 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 RESEND 3/3] x86, mm: Move max_pfn_mapped definition to init.c.
min_pfn_mapped is defined in init.c, we can also define max_pfn_mapped here. Signed-off-by: Tang Chen tangc...@cn.fujitsu.com --- arch/x86/kernel/setup.c |8 arch/x86/mm/init.c |9 + 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 7fa1ec3..698b9c6 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -111,14 +111,6 @@ #include asm/alternative.h #include asm/prom.h -/* - * max_pfn_mapped: highest direct mapped pfn - * - * The direct mapping only covers E820_RAM regions, so the ranges and gaps are - * represented by pfn_mapped - */ -unsigned long max_pfn_mapped; - #ifdef CONFIG_DMI RESERVE_BRK(dmi_alloc, 65536); #endif diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c index a97749f..793204b 100644 --- a/arch/x86/mm/init.c +++ b/arch/x86/mm/init.c @@ -24,6 +24,15 @@ static unsigned long __initdata pgt_buf_start; static unsigned long __initdata pgt_buf_end; static unsigned long __initdata pgt_buf_top; +/* + * max_pfn_mapped: highest direct mapped pfn + * min_pfn_mapped: lowest direct mapped pfn + * + * The direct mapping only covers E820_RAM regions, so the ranges and gaps are + * represented by pfn_mapped + */ + +unsigned long max_pfn_mapped; static unsigned long min_pfn_mapped; static bool __initdata can_use_brk_pgt = true; -- 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/
[PATCH RESEND 1/3] x86, ACPI, mm: Kill max_low_pfn_mapped.
From: Yinghai Lu ying...@kernel.org
Now we have pfn_mapped[] in , and max_low_pfn_mapped should not be used anymore.
User should use pfn_mapped[] or just 1UL(32-PAGE_SHIFT) instead.
Only user is ACPI_INITRD_TABLE_OVERRIDE, and it should not use that,
as later accessing is using early_ioremap(). We could change to use
1U(32_PAGE_SHIFT) with it, aka under 4G.
-v2: Leave alone max_low_pfn_mapped in i915 code according to tj.
Suggested-by: H. Peter Anvin h...@zytor.com
Signed-off-by: Yinghai Lu ying...@kernel.org
Signed-off-by: Tang Chen tangc...@cn.fujitsu.com
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Jacob Shin jacob.s...@amd.com
Cc: Pekka Enberg penb...@kernel.org
Cc: linux-a...@vger.kernel.org
Tested-by: Thomas Renninger tr...@suse.de
Reviewed-by: Tang Chen tangc...@cn.fujitsu.com
Tested-by: Tang Chen tangc...@cn.fujitsu.com
---
arch/x86/include/asm/page_types.h |1 -
arch/x86/kernel/setup.c |4 +---
arch/x86/mm/init.c|4
drivers/acpi/osl.c|6 +++---
4 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/arch/x86/include/asm/page_types.h
b/arch/x86/include/asm/page_types.h
index 54c9787..b012b82 100644
--- a/arch/x86/include/asm/page_types.h
+++ b/arch/x86/include/asm/page_types.h
@@ -43,7 +43,6 @@
extern int devmem_is_allowed(unsigned long pagenr);
-extern unsigned long max_low_pfn_mapped;
extern unsigned long max_pfn_mapped;
static inline phys_addr_t get_max_mapped(void)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index f8ec578..7fa1ec3 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -112,13 +112,11 @@
#include asm/prom.h
/*
- * max_low_pfn_mapped: highest direct mapped pfn under 4GB
- * max_pfn_mapped: highest direct mapped pfn over 4GB
+ * max_pfn_mapped: highest direct mapped pfn
*
* The direct mapping only covers E820_RAM regions, so the ranges and gaps are
* represented by pfn_mapped
*/
-unsigned long max_low_pfn_mapped;
unsigned long max_pfn_mapped;
#ifdef CONFIG_DMI
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 2ec29ac..5b2eaca 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -313,10 +313,6 @@ static void add_pfn_range_mapped(unsigned long start_pfn,
unsigned long end_pfn)
nr_pfn_mapped = clean_sort_range(pfn_mapped, E820_X_MAX);
max_pfn_mapped = max(max_pfn_mapped, end_pfn);
-
- if (start_pfn (1UL(32-PAGE_SHIFT)))
- max_low_pfn_mapped = max(max_low_pfn_mapped,
-min(end_pfn, 1UL(32-PAGE_SHIFT)));
}
bool pfn_range_is_mapped(unsigned long start_pfn, unsigned long end_pfn)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 6ab2c35..378de0d 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -624,9 +624,9 @@ void __init acpi_initrd_override(void *data, size_t size)
if (table_nr == 0)
return;
- acpi_tables_addr =
- memblock_find_in_range(0, max_low_pfn_mapped PAGE_SHIFT,
- all_tables_size, PAGE_SIZE);
+ /* under 4G at first, then above 4G */
+ acpi_tables_addr = memblock_find_in_range(0, (1ULL32) - 1,
+ all_tables_size, PAGE_SIZE);
if (!acpi_tables_addr) {
WARN_ON(1);
return;
--
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 0/8] partitions/efi: detect hybrid mbrs
On Thu, Aug 15, 2013 at 06:37:19PM -0700, Davidlohr Bueso wrote: On Thu, 2013-08-15 at 12:29 -0700, Andrew Morton wrote: On Thu, 15 Aug 2013 09:59:42 -0700 Davidlohr Bueso davidl...@hp.com wrote: On Tue, 2013-08-06 at 14:16 -0700, Andrew Morton wrote: On Mon, 5 Aug 2013 22:21:08 -0700 Davidlohr Bueso davidl...@hp.com wrote: This patchset teaches the kernel about hybrid master boot records (MBRs), one of the most common issues with GUID partition tables, as a workaround to layout disk partitions to be compatible with both EFI and legacy MBR based systems. Except for adding more pmbr checks, to better comply with the UEFI/GPT specs, the functionality is left unchanged - we only inform (through debug) the user about the used MBR scheme. While it is true that these restrictions can be bypassed when forcing gpt, this is not the correct or default way of doing things, complicating users furthermore. More details are in the individual patches. Patches look nice, although I'll cheerily admit to not having a clue what they do. What is a hybrid MBR anyway? Someone's editor seems to replace tabs with spaces so the patches generate quite a checkpatch storm. Please use checkpatch. Andrew, any chance of getting this in for 3.12? gee, I didn't review the patches because I simply have no useful knowledge in the area. I can check the whitespace and code comments, but that has the downside of creating the false impression that someone actually reviewed the code :( I'm struggling to think who might be better situated. Matt Fleming or Matt Domsch, maybe? Cc'ing Matt Fleming. Karel, I believe you took a look at these, any thoughts? Reviewed-by: Karel Zak k...@redhat.com Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.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] Fix bitoperation for compilation with clang
On Thu, Aug 29, 2013 at 08:09:24PM +0200, dl...@gmx.de wrote: From: Jan-Simon Möller dl...@gmx.de v2: Fix bug in statement as pointed out by Herbert Xu. Kudos to pipacs. Author: PaX Team pageexec at freemail.hu ML-Post: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120507/142707.html URL: http://llvm.linuxfoundation.org Merge: Jan-Simon Möller dl9pf at gmx.de Description: Fix for warning: linux/crypto/fcrypt.c:143:47: warning: signed shift result (0x59800) requires 36 bits to represent, but 'int' only has 32 bits [-Wshift-overflow] Z(0xef), Z(0x70), Z(0xcf), Z(0xc2), Z(0x2a), Z(0xb3), Z(0x61), Z(0xad), ^~~ linux/crypto/fcrypt.c:113:29: note: expanded from macro 'Z' ^ ~~ linux/include/uapi/linux/byteorder/little_endian.h:38:53: note: expanded from macro '__cpu_to_be32' ^ linux/include/uapi/linux/swab.h:116:21: note: expanded from macro '__swab32' ___constant_swab32(x) : \ ^ linux/include/uapi/linux/swab.h:18:12: note: expanded from macro '___constant_swab32' (((__u32)(x) (__u32)0xff00UL) 8) |\ ^ Solution - make sure we don't exceed the 32 bit range. #define Z(x) cpu_to_be32(((x 0x1f) 27) | (x 5)) Signed-off-by: Jan-Simon Möller dl...@gmx.de Patch applied. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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/10] Series of fixes for NX driver
On Thu, Aug 29, 2013 at 11:36:30AM -0300, Marcelo Cerri wrote: This series of patches contains fixes in several algorithms implemented by the NX driver. The patches can be separated in three different categories: - Changes to split the data in several hyper calls to respect the limits of data that the co-processador can handle. This affects all AES modes. - Fixes in how the driver handle zero length messages. This affects XCBC and GCM. - Fixes for SHA-2 when chunks bigger than the block size are provided. v2: - Fixed conflict. All applied. Thanks! -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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] hwrng: via-rng: Add MODULE_DEVICE_TABLE
On Sun, Sep 01, 2013 at 11:53:57PM +0100, Ben Hutchings wrote: via-rng currently isn't auto-loaded if built as a module. Signed-off-by: Ben Hutchings b...@decadent.org.uk Patch applied. Thanks. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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: [alsa-devel] [PATCH] ASoC: codecs: da9055: Update driver name to fix breakage due to pmic driver with same name
On Mon, Sep 02, 2013 at 09:49:20AM +, Opensource [Adam Thomson] wrote: Please fix your mailer to wrap within 80 columns, it makes your mails very hard to read if you don't do this. At present I believe your suggestion is to instantiate the codec regmap in the MFD core for the PMIC, and then pass this in as part initialisation of the codec driver, from the PMIC. Please correct me if I'm wrong. That's correct. If I'm correct then to me this doesn't make sense. The devices are separate, and have completely independent register maps. As such I believe the instantiation They are not separate, they are soldered to the board as part of the same package - quite a few other devices use a similar scheme and are also handled in this fashion (the TI TWL devices are one example). 2) Including the above change, add some optional code to the PMIC MFD core which uses 'i2c_new_device()' to instantiate the codec, if it's required (I guess indicated by platform data to the PMIC). Means the Codec can still be used as is, but the PMIC core code can, if required, instantiate the codec. This is roughly what ends up happening, you do need to instantiate another I2C client no matter what. The important thing here is that the CODEC does not need to be separately registered by the user, if it really is only the I2C client that needs creating that's probably OK so long as the user doesn't need to worry about that implementation detail. I personally believe option 2 seems unnecessary and it would be simple enough just to instantiate the codec driver from machine code, as is done for many standalone codecs. Am interested though in understanding the reasoning behind your suggestion, for devices like this which are completely independent but can share the same HW package. I currently don't see a good reason to make PMIC MFD core instantiate the codec, for this type of scenario, but maybe you see something I don't? The reasoning is simply that if the chip design solders a single device to the board then the software system integration should register a single device with the system. signature.asc Description: Digital signature
Re: [patch 0/7] improve memcg oom killer robustness v2
Hi azur, here is the x86-only rollup of the series for 3.2. Thanks! Johannes --- Johannes, unfortunately, one problem arises: I have (again) cgroup which cannot be deleted :( it's a user who had very high memory usage and was reaching his limit very often. Do you need any info which i can gather now? azur Now i can definitely confirm that problem is NOT fixed :( it happened again but i don't have any data because i already disabled all debug output. azur -- 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/2] i2c: prepare runtime PM support for I2C client devices
On Wed, Aug 28, 2013 at 11:38:58AM +0200, Wolfram Sang wrote: On Tue, Aug 20, 2013 at 05:03:35PM +0300, Mika Westerberg wrote: From: Aaron Lu aaron...@intel.com This patch adds runtime PM support for the I2C bus in a similar way that has been done for PCI bus already. This means that the I2C bus core prepares runtime PM for a client device just before a driver is about to be bound to it. Devices that are not bound to any driver are not prepared for runtime PM. In order to take advantage of this runtime PM support, the client device driver needs drop the device runtime PM reference count by calling pm_runtime_put() in its -probe() callback and possibly implement rest of the runtime PM callbacks. However, this does not yet make runtime PM happen for the device, it has to be explicitly allowed from userspace per each I2C client device. The reason for this is that things like HID over I2C might not work as smoothly when runtime PM is active. So we leave it to the user to balance between performance and power efficiency. User can allow runtime PM for the client device by running: # echo auto /sys/bus/i2c/devices/device/power/control and it can be forbidden again by: # echo on /sys/bus/i2c/devices/device/power/control Status of the device can be monitored by reading files under the device power directory. If the driver doesn't support runtime PM (like most of the existing I2C client drivers), the device in question is regarded as being runtime PM active and powered on. The patch adds also runtime PM support for the adapter device because it is needed to be able to runtime power manage the I2C controller device. The adapter device is handled along with the I2C controller device (it uses pm_runtime_no_callbacks()). Signed-off-by: Aaron Lu aaron...@intel.com Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com CCing ALKML. Would appreciate comments/tags from the runtime-PM users of the ARM world. Any comments on this? I can resend the whole series with ALKML included if that helps. -- 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] thp: support split page table lock
Naoya Horiguchi wrote: Thp related code also uses per process mm-page_table_lock now. So making it fine-grained can provide better performance. This patch makes thp support split page table lock which makes us use page-ptl of the pages storing pmd_trans_huge pmds. Hm. So, you use page-ptl only when you deal with thp pages, otherwise mm-page_table_lock, right? It looks inconsistent to me. Does it mean we have to take both locks on split and collapse paths? I'm not sure if it's safe to take only page-ptl for alloc path. Probably not. Why not to use new locking for pmd everywhere? -- Kirill A. Shutemov -- 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] dma: add driver for R-Car HPB-DMAC
On Sun, Aug 25, 2013 at 12:33:24AM +0400, Sergei Shtylyov wrote: From: Max Filippov max.filip...@cogentembedded.com Add support for HPB-DMAC found in Renesas R-Car SoCs, using 'shdma-base' DMA driver framework. Based on the original patch by Phil Edworthy phil.edwor...@renesas.com. Signed-off-by: Max Filippov max.filip...@cogentembedded.com [Sergei: removed useless #include, sorted #include's, fixed HPB_DMA_TCR_MAX, fixed formats and removed line breaks in the dev_dbg() calls, rephrased and added IRQ # to the shdma_request_irq() failure message, added MODULE_AUTHOR(), removed '__init'/'__exit' annotations from the probe()/remove() methods, removed '__initdata' annotation from 'hpb_dmae_driver', fixed guard macro name in the header file, fixed #define ASYNCRSTR_ASRST20, added #define ASYNCRSTR_ASRST24, added the necessary runtime PM calls to the probe() and remove() methods, handled errors returned by dma_async_device_register(), beautified comments and #define's.] Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com Applied, thanks ~Vinod -- 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: Clock framework deadlock with external SPI clockchip
On Fri, Aug 30, 2013 at 03:24:45PM +0200, Lars-Peter Clausen wrote: Hi, I'm currently facing a deadlock in the common clock framework that unfortunately is not addressed by the reentrancy patches. I have a external clock chip that is controlled via SPI. So for example to configure the rate of the clock chip you need to send a SPI message. Naturally the clock framework will hold the prepare lock while configuring the rate. Communication in the SPI framework happens asynchronously, spi_sync() will enqueue a message in the SPI masters queue and then wait using wait_for_completion(). The master will call complete() once the transfer has been finished. The SPI master runs in it's own thread in which it processes the messages. In this thread it also calls clk_set_rate() to configure the SPI transfer clock rate based on what the message says. Now the deadlock happens as we try to take the prepare_lock again and since the clock chip and the SPI master run in different threads the reentrancy code does not kick in. The basic sequence is like this: === Clock chip driver ====== SPI master driver === clk_prepare_lock() spi_sync() wait_for_completion(X) clk_get_rate() clk_prepare_lock() --- DEADLOCK clk_prepare_unlock() ... complete(X) ... clk_prepare_unlock() I'm wondering if you have any idea how this can be fixed. In my opinion we'd need a per clock mutex to address this properly. One workaround is to leave the SPI masters clock always prepared. A similar problem can occur with I2C and DVFS using notifiers. Cheers, 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/
[PATCH 1/5] xhci: fix usb3 streams
xhci maintains a radix tree for each stream endpoint because it must
be able to map a trb address to the stream ring. Each ring segment
must be added to the ring for this to work. Currently xhci sticks
only the first segment of each stream ring into the radix tree.
Result is that things work initially, but as soon as the first segment
is full xhci can't map the trb address from the completion event to the
stream ring any more - BOOM. You'll find this message in the logs:
ERROR Transfer event for disabled endpoint or incorrect stream ring
This patch adds a helper function to update the radix tree. It can
both insert and remove ring segments. It loops over the segment list
and handles all segments instead of just the first. It is called
whenever an update is needed: When allocating a ring, when expanding
a ring and when releasing a ring.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
drivers/usb/host/xhci-mem.c | 51 +
drivers/usb/host/xhci.h | 2 ++
2 files changed, 40 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 6f8c2fd..c7fd88f 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -154,8 +154,11 @@ void xhci_ring_free(struct xhci_hcd *xhci, struct
xhci_ring *ring)
if (!ring)
return;
- if (ring-first_seg)
+ if (ring-first_seg) {
+ if (ring-type == TYPE_STREAM)
+ xhci_update_stream_ring(ring, false);
xhci_free_segments_for_ring(xhci, ring-first_seg);
+ }
kfree(ring);
}
@@ -351,6 +354,11 @@ int xhci_ring_expansion(struct xhci_hcd *xhci, struct
xhci_ring *ring,
xhci_dbg(xhci, ring expansion succeed, now has %d segments\n,
ring-num_segs);
+ if (ring-type == TYPE_STREAM) {
+ ret = xhci_update_stream_ring(ring, true);
+ WARN_ON(ret); /* FIXME */
+ }
+
return 0;
}
@@ -601,6 +609,33 @@ static int xhci_test_radix_tree(struct xhci_hcd *xhci,
* extended systems (where the DMA address can be bigger than 32-bits),
* if we allow the PCI dma mask to be bigger than 32-bits. So don't do that.
*/
+
+int xhci_update_stream_ring(struct xhci_ring *ring, bool insert)
+{
+ struct xhci_segment *seg;
+ unsigned long key;
+ bool present;
+ int ret;
+
+ BUG_ON(ring-trb_address_map == NULL);
+ seg = ring-first_seg;
+ do {
+ key = (unsigned long)(seg-dma TRB_SEGMENT_SHIFT);
+ present = radix_tree_lookup(ring-trb_address_map, key) != NULL;
+ if (!present insert) {
+ ret = radix_tree_insert(ring-trb_address_map, key,
ring);
+ if (ret)
+ return ret;
+ }
+ if (present !insert) {
+ radix_tree_delete(ring-trb_address_map, key);
+ }
+ seg = seg-next;
+ } while (seg != ring-first_seg);
+
+ return 0;
+}
+
struct xhci_stream_info *xhci_alloc_stream_info(struct xhci_hcd *xhci,
unsigned int num_stream_ctxs,
unsigned int num_streams, gfp_t mem_flags)
@@ -608,7 +643,6 @@ struct xhci_stream_info *xhci_alloc_stream_info(struct
xhci_hcd *xhci,
struct xhci_stream_info *stream_info;
u32 cur_stream;
struct xhci_ring *cur_ring;
- unsigned long key;
u64 addr;
int ret;
@@ -663,6 +697,7 @@ struct xhci_stream_info *xhci_alloc_stream_info(struct
xhci_hcd *xhci,
if (!cur_ring)
goto cleanup_rings;
cur_ring-stream_id = cur_stream;
+ cur_ring-trb_address_map = stream_info-trb_address_map;
/* Set deq ptr, cycle bit, and stream context type */
addr = cur_ring-first_seg-dma |
SCT_FOR_CTX(SCT_PRI_TR) |
@@ -672,10 +707,7 @@ struct xhci_stream_info *xhci_alloc_stream_info(struct
xhci_hcd *xhci,
xhci_dbg(xhci, Setting stream %d ring ptr to 0x%08llx\n,
cur_stream, (unsigned long long) addr);
- key = (unsigned long)
- (cur_ring-first_seg-dma TRB_SEGMENT_SHIFT);
- ret = radix_tree_insert(stream_info-trb_address_map,
- key, cur_ring);
+ ret = xhci_update_stream_ring(cur_ring, true);
if (ret) {
xhci_ring_free(xhci, cur_ring);
stream_info-stream_rings[cur_stream] = NULL;
@@ -702,9 +734,6 @@ cleanup_rings:
for (cur_stream = 1; cur_stream num_streams; cur_stream++) {
cur_ring = stream_info-stream_rings[cur_stream];
if (cur_ring) {
- addr = cur_ring-first_seg-dma;
-
[PATCH 5/5] uas: remove BROKEN
xhci streams support is fixed, unblock usb attached scsi. Signed-off-by: Gerd Hoffmann kra...@redhat.com --- drivers/usb/storage/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/storage/Kconfig b/drivers/usb/storage/Kconfig index 8470e1b..4761a28 100644 --- a/drivers/usb/storage/Kconfig +++ b/drivers/usb/storage/Kconfig @@ -202,7 +202,7 @@ config USB_STORAGE_ENE_UB6250 config USB_UAS tristate USB Attached SCSI - depends on SCSI BROKEN + depends on SCSI help The USB Attached SCSI protocol is supported by some USB storage devices. It permits higher performance by supporting -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] uas: properly reinitialize in uas_eh_bus_reset_handler
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
drivers/usb/storage/uas.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index d966b59..f89202f 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -85,6 +85,8 @@ static int uas_submit_urbs(struct scsi_cmnd *cmnd,
struct uas_dev_info *devinfo, gfp_t gfp);
static void uas_do_work(struct work_struct *work);
static int uas_try_complete(struct scsi_cmnd *cmnd, const char *caller);
+static void uas_configure_endpoints(struct uas_dev_info *devinfo);
+static void uas_free_streams(struct uas_dev_info *devinfo);
static DECLARE_WORK(uas_work, uas_do_work);
static DEFINE_SPINLOCK(uas_work_lock);
@@ -800,7 +802,11 @@ static int uas_eh_bus_reset_handler(struct scsi_cmnd *cmnd)
usb_kill_anchored_urbs(devinfo-cmd_urbs);
usb_kill_anchored_urbs(devinfo-sense_urbs);
usb_kill_anchored_urbs(devinfo-data_urbs);
+ uas_free_streams(devinfo);
err = usb_reset_device(udev);
+ if (!err) {
+ uas_configure_endpoints(devinfo);
+ }
devinfo-resetting = 0;
if (err) {
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] uas: add dead request list
This patch adds a new list where all requests which are canceled are
added to, so we don't loose them. Then, after killing all inflight
urbs on bus reset (and disconnect) we'll walk over the list and clean
them up.
Without this we can end up with aborted requests lingering around in
case of status pipe transfer errors.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
drivers/usb/storage/uas.c | 69 +--
1 file changed, 61 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index a63972a..9dfb8f9 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -78,6 +78,7 @@ struct uas_cmd_info {
struct urb *data_in_urb;
struct urb *data_out_urb;
struct list_head work;
+ struct list_head dead;
};
/* I hate forward declarations, but I actually have a loop */
@@ -87,10 +88,12 @@ static void uas_do_work(struct work_struct *work);
static int uas_try_complete(struct scsi_cmnd *cmnd, const char *caller);
static void uas_configure_endpoints(struct uas_dev_info *devinfo);
static void uas_free_streams(struct uas_dev_info *devinfo);
+static void uas_log_cmd_state(struct scsi_cmnd *cmnd, const char *caller);
static DECLARE_WORK(uas_work, uas_do_work);
static DEFINE_SPINLOCK(uas_lists_lock);
static LIST_HEAD(uas_work_list);
+static LIST_HEAD(uas_dead_list);
static void uas_unlink_data_urbs(struct uas_dev_info *devinfo,
struct uas_cmd_info *cmdinfo)
@@ -167,15 +170,13 @@ static void uas_abort_work(struct uas_dev_info *devinfo)
struct uas_dev_info *di = (void *)cmnd-device-hostdata;
if (di == devinfo) {
+ uas_log_cmd_state(cmnd, __func__);
+ BUG_ON(cmdinfo-state COMMAND_ABORTED);
cmdinfo-state |= COMMAND_ABORTED;
+ spin_lock_irq(uas_lists_lock);
+ list_add_tail(cmdinfo-dead, uas_dead_list);
+ spin_unlock_irq(uas_lists_lock);
cmdinfo-state = ~IS_IN_WORK_LIST;
- if (devinfo-resetting) {
- /* uas_stat_cmplt() will not do that
-* when a device reset is in
-* progress */
- cmdinfo-state = ~COMMAND_INFLIGHT;
- }
- uas_try_complete(cmnd, __func__);
} else {
/* not our uas device, relink into list */
list_del(cmdinfo-work);
@@ -187,6 +188,43 @@ static void uas_abort_work(struct uas_dev_info *devinfo)
spin_unlock_irqrestore(devinfo-lock, flags);
}
+static void uas_zap_dead(struct uas_dev_info *devinfo)
+{
+ struct uas_cmd_info *cmdinfo;
+ struct uas_cmd_info *temp;
+ struct list_head list;
+ unsigned long flags;
+
+ spin_lock_irq(uas_lists_lock);
+ list_replace_init(uas_dead_list, list);
+ spin_unlock_irq(uas_lists_lock);
+
+ spin_lock_irqsave(devinfo-lock, flags);
+ list_for_each_entry_safe(cmdinfo, temp, list, dead) {
+ struct scsi_pointer *scp = (void *)cmdinfo;
+ struct scsi_cmnd *cmnd = container_of(scp,
+ struct scsi_cmnd, SCp);
+ struct uas_dev_info *di = (void *)cmnd-device-hostdata;
+
+ if (di == devinfo) {
+ uas_log_cmd_state(cmnd, __func__);
+ BUG_ON(!(cmdinfo-state COMMAND_ABORTED));
+ /* all urbs are killed, clear inflight bits */
+ cmdinfo-state = ~(COMMAND_INFLIGHT |
+ DATA_IN_URB_INFLIGHT |
+ DATA_OUT_URB_INFLIGHT);
+ uas_try_complete(cmnd, __func__);
+ } else {
+ /* not our uas device, relink into list */
+ list_del(cmdinfo-dead);
+ spin_lock_irq(uas_lists_lock);
+ list_add_tail(cmdinfo-dead, uas_dead_list);
+ spin_unlock_irq(uas_lists_lock);
+ }
+ }
+ spin_unlock_irqrestore(devinfo-lock, flags);
+}
+
static void uas_sense(struct urb *urb, struct scsi_cmnd *cmnd)
{
struct sense_iu *sense_iu = urb-transfer_buffer;
@@ -274,6 +312,9 @@ static int uas_try_complete(struct scsi_cmnd *cmnd, const
char *caller)
if (cmdinfo-state COMMAND_ABORTED) {
scmd_printk(KERN_INFO, cmnd, abort completed\n);
cmnd-result = DID_ABORT 16;
+ spin_lock_irq(uas_lists_lock);
+ list_del(cmdinfo-dead);
+ spin_unlock_irq(uas_lists_lock);
}
cmnd-scsi_done(cmnd);
return 0;
@@ -307,7 +348,12 @@ static
[PATCH 3/5] uas: rename work list lock + list field
This patch prepares for the addition of another list and renames the
work list lock and the list_head field in struct uas_cmd_info.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
drivers/usb/storage/uas.c | 50 +++
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index f89202f..a63972a 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -77,7 +77,7 @@ struct uas_cmd_info {
struct urb *cmd_urb;
struct urb *data_in_urb;
struct urb *data_out_urb;
- struct list_head list;
+ struct list_head work;
};
/* I hate forward declarations, but I actually have a loop */
@@ -89,7 +89,7 @@ static void uas_configure_endpoints(struct uas_dev_info
*devinfo);
static void uas_free_streams(struct uas_dev_info *devinfo);
static DECLARE_WORK(uas_work, uas_do_work);
-static DEFINE_SPINLOCK(uas_work_lock);
+static DEFINE_SPINLOCK(uas_lists_lock);
static LIST_HEAD(uas_work_list);
static void uas_unlink_data_urbs(struct uas_dev_info *devinfo,
@@ -124,11 +124,11 @@ static void uas_do_work(struct work_struct *work)
unsigned long flags;
int err;
- spin_lock_irq(uas_work_lock);
+ spin_lock_irq(uas_lists_lock);
list_replace_init(uas_work_list, list);
- spin_unlock_irq(uas_work_lock);
+ spin_unlock_irq(uas_lists_lock);
- list_for_each_entry_safe(cmdinfo, temp, list, list) {
+ list_for_each_entry_safe(cmdinfo, temp, list, work) {
struct scsi_pointer *scp = (void *)cmdinfo;
struct scsi_cmnd *cmnd = container_of(scp,
struct scsi_cmnd, SCp);
@@ -139,10 +139,10 @@ static void uas_do_work(struct work_struct *work)
cmdinfo-state = ~IS_IN_WORK_LIST;
spin_unlock_irqrestore(devinfo-lock, flags);
if (err) {
- list_del(cmdinfo-list);
- spin_lock_irq(uas_work_lock);
- list_add_tail(cmdinfo-list, uas_work_list);
- spin_unlock_irq(uas_work_lock);
+ list_del(cmdinfo-work);
+ spin_lock_irq(uas_lists_lock);
+ list_add_tail(cmdinfo-work, uas_work_list);
+ spin_unlock_irq(uas_lists_lock);
schedule_work(uas_work);
}
}
@@ -155,12 +155,12 @@ static void uas_abort_work(struct uas_dev_info *devinfo)
struct list_head list;
unsigned long flags;
- spin_lock_irq(uas_work_lock);
+ spin_lock_irq(uas_lists_lock);
list_replace_init(uas_work_list, list);
- spin_unlock_irq(uas_work_lock);
+ spin_unlock_irq(uas_lists_lock);
spin_lock_irqsave(devinfo-lock, flags);
- list_for_each_entry_safe(cmdinfo, temp, list, list) {
+ list_for_each_entry_safe(cmdinfo, temp, list, work) {
struct scsi_pointer *scp = (void *)cmdinfo;
struct scsi_cmnd *cmnd = container_of(scp,
struct scsi_cmnd, SCp);
@@ -178,10 +178,10 @@ static void uas_abort_work(struct uas_dev_info *devinfo)
uas_try_complete(cmnd, __func__);
} else {
/* not our uas device, relink into list */
- list_del(cmdinfo-list);
- spin_lock_irq(uas_work_lock);
- list_add_tail(cmdinfo-list, uas_work_list);
- spin_unlock_irq(uas_work_lock);
+ list_del(cmdinfo-work);
+ spin_lock_irq(uas_lists_lock);
+ list_add_tail(cmdinfo-work, uas_work_list);
+ spin_unlock_irq(uas_lists_lock);
}
}
spin_unlock_irqrestore(devinfo-lock, flags);
@@ -288,10 +288,10 @@ static void uas_xfer_data(struct urb *urb, struct
scsi_cmnd *cmnd,
cmdinfo-state |= direction | SUBMIT_STATUS_URB;
err = uas_submit_urbs(cmnd, cmnd-device-hostdata, GFP_ATOMIC);
if (err) {
- spin_lock(uas_work_lock);
- list_add_tail(cmdinfo-list, uas_work_list);
+ spin_lock(uas_lists_lock);
+ list_add_tail(cmdinfo-work, uas_work_list);
cmdinfo-state |= IS_IN_WORK_LIST;
- spin_unlock(uas_work_lock);
+ spin_unlock(uas_lists_lock);
schedule_work(uas_work);
}
}
@@ -694,10 +694,10 @@ static int uas_queuecommand_lck(struct scsi_cmnd *cmnd,
spin_unlock_irqrestore(devinfo-lock, flags);
return SCSI_MLQUEUE_DEVICE_BUSY;
}
- spin_lock(uas_work_lock);
- list_add_tail(cmdinfo-list, uas_work_list);
+
[PATCH 2/4] ab8500-charger: Remove redundant break
Each of the if-else blocks has a break statement. Remove the additional one which is unreachable. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/power/ab8500_charger.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/power/ab8500_charger.c b/drivers/power/ab8500_charger.c index fec0546..608b63e 100644 --- a/drivers/power/ab8500_charger.c +++ b/drivers/power/ab8500_charger.c @@ -766,7 +766,6 @@ static int ab8500_charger_max_usb_curr(struct ab8500_charger *di, ret = -ENXIO; break; } - break; case USB_STAT_CARKIT_1: case USB_STAT_CARKIT_2: case USB_STAT_ACA_DOCK_CHARGER: -- 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 1/4] ab8500-charger: Check return value of regulator_enable
Check the return value of regulator_enable to silence the following
type of warnings:
drivers/power/ab8500_charger.c:1390:20: warning: ignoring return value
of ‘regulator_enable’, declared with attribute warn_unused_result
[-Wunused-result]
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Lee Jones lee.jo...@linaro.org
---
drivers/power/ab8500_charger.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/power/ab8500_charger.c b/drivers/power/ab8500_charger.c
index a4c4a10..fec0546 100644
--- a/drivers/power/ab8500_charger.c
+++ b/drivers/power/ab8500_charger.c
@@ -1387,7 +1387,12 @@ static int ab8500_charger_ac_en(struct ux500_charger
*charger,
* the GPADC module independant of the AB8500 chargers
*/
if (!di-vddadc_en_ac) {
- regulator_enable(di-regu);
+ ret = regulator_enable(di-regu);
+ if (ret) {
+ dev_err(di-dev,
+ Failed to enable regulator\n);
+ return ret;
+ }
di-vddadc_en_ac = true;
}
@@ -1556,7 +1561,12 @@ static int ab8500_charger_usb_en(struct ux500_charger
*charger,
* the GPADC module independant of the AB8500 chargers
*/
if (!di-vddadc_en_usb) {
- regulator_enable(di-regu);
+ ret = regulator_enable(di-regu);
+ if (ret) {
+ dev_err(di-dev,
+ Failed to enable regulator\n);
+ return ret;
+ }
di-vddadc_en_usb = true;
}
--
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 3/4] pm2301-charger: Check return value of regulator_enable
Check the return value of regulator_enable to silence the following
warning:
drivers/power/pm2301_charger.c:725:20: warning:
ignoring return value of ‘regulator_enable’, declared with
attribute warn_unused_result [-Wunused-result]
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Lee Jones lee.jo...@linaro.org
---
drivers/power/pm2301_charger.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/power/pm2301_charger.c b/drivers/power/pm2301_charger.c
index ffa10ed..ab87d1a 100644
--- a/drivers/power/pm2301_charger.c
+++ b/drivers/power/pm2301_charger.c
@@ -722,7 +722,12 @@ static int pm2xxx_charger_ac_en(struct ux500_charger
*charger,
dev_dbg(pm2-dev, Enable AC: %dmV %dmA\n, vset, iset);
if (!pm2-vddadc_en_ac) {
- regulator_enable(pm2-regu);
+ ret = regulator_enable(pm2-regu);
+ if (ret) {
+ dev_err(pm2-dev,
+ Failed to enable regulator\n);
+ goto error_occured;
+ }
pm2-vddadc_en_ac = true;
}
--
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 4/4] pm2301-charger: Staticize pm2xxx_charger_die_therm_mngt
pm2xxx_charger_die_therm_mngt is used only in this file.
Make it static.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Lee Jones lee.jo...@linaro.org
---
drivers/power/pm2301_charger.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/pm2301_charger.c b/drivers/power/pm2301_charger.c
index ab87d1a..b9e1ef7 100644
--- a/drivers/power/pm2301_charger.c
+++ b/drivers/power/pm2301_charger.c
@@ -205,7 +205,7 @@ static int pm2xxx_charger_batt_therm_mngt(struct
pm2xxx_charger *pm2, int val)
}
-int pm2xxx_charger_die_therm_mngt(struct pm2xxx_charger *pm2, int val)
+static int pm2xxx_charger_die_therm_mngt(struct pm2xxx_charger *pm2, int val)
{
queue_work(pm2-charger_wq, pm2-check_main_thermal_prot_work);
--
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] HID: Correct the USB IDs for the new Macbook Air 6
On Sun, 1 Sep 2013, Henrik Rydberg wrote: A recent patch (9d9a04ee) added support for the new machine, but got the sequence of USB ids wrong. Reports from both Ian and Linus T show that the 0x0291 id is for ISO, not ANSI, which should have the missing number 0x0290. This patchs moves the three numbers accordingly, fixing the problem. Cc: Dmitry Torokhov dmitry.torok...@gmail.com Reported-and-tested-by: Ian Munsie darkstarsw...@gmail.com Tested-by: Linus G Thiel li...@hanssonlarsson.se Signed-off-by: Henrik Rydberg rydb...@euromail.se --- Hi Jiri, Dmitry, it looks like this change has been sufficiently tested now, in addition to making perfect sense. Jiri, would you mind taking it, if Dmitry approves? Absolutely ... waiting for Dmitry's Ack. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] dma: imx-dma: Remove redundant NULL check
On Mon, Sep 02, 2013 at 01:21:18PM +0530, Sachin Kamat wrote: kfree on a NULL pointer is a no-op. Null pointer check is not necessary. Applied, thanks ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] dma: ste_dma40: Remove duplicate const
On Mon, Sep 02, 2013 at 01:44:58PM +0530, Sachin Kamat wrote: 'const' was added twice. Applied, both thanks ~Vinod -- 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] HID: usbhid: quirk for N-Trig DuoSense Touch Screen
On Fri, 30 Aug 2013, Vasily Titskiy wrote:
The DuoSense touchscreen device causes a 10 second timeout. This fix
removes the delay.
Signed-off-by: Vasily Titskiy qeh...@gmail.com
---
drivers/hid/hid-ids.h |1 +
drivers/hid/usbhid/hid-quirks.c |1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 2168885..376170e 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -646,6 +646,7 @@
#define USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_16 0x0012
#define USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_17 0x0013
#define USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_18 0x0014
+#define USB_DEVICE_ID_NTRIG_DUOSENSE 0x1500
#define USB_VENDOR_ID_ONTRAK 0x0a07
#define USB_DEVICE_ID_ONTRAK_ADU100 0x0064
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 19b8360..1671b47 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -109,6 +109,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_SIGMA_MICRO, USB_DEVICE_ID_SIGMA_MICRO_KEYBOARD,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_MOUSEPEN_I608X,
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_EASYPEN_M610X, HID_QUIRK_MULTI_INPUT
},
+ { USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_DUOSENSE,
HID_QUIRK_NO_INIT_REPORTS },
{ 0, 0 }
};
Vasily,
your mail client is line-wrapping text, which causes corrupted patches.
I have fixed it up and applied, but please keep that in mind for your
future submissions.
Thanks,
--
Jiri Kosina
SUSE Labs
--
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 05/23] thp: represent file thp pages in meminfo and friends
Ning Qu wrote: Hi, Kirill I believe there is a typo in your previous commit, but you didn't include it in this series of patch set. Below is the link for the commit. I think you are trying to decrease the value NR_ANON_PAGES in page_remove_rmap, but it is currently adding the value instead when using __mod_zone_page_state.Let me know if you would like to fix it in your commit or you want another patch from me. Thanks! The patch is already in Andrew's tree. I'll send a fix for that. Thanks. -- Kirill A. Shutemov -- 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] HID: roccat: Added support for KonePureOptical v2
On Fri, 30 Aug 2013, Stefan Achatz wrote: KonePureOptical is a KonePure with different sensor. Signed-off-by: Stefan Achatz erazor...@users.sourceforge.net Applied, thanks. -- Jiri Kosina SUSE Labs -- 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] Kconfig.debug: Add FRAME_POINTER anti-dependency for ARC
Hi Gilad, On 09/02/2013 02:33 PM, Gilad Ben-Yossef wrote: Hi, On Tue, Aug 27, 2013 at 11:31 AM, Vineet Gupta vineet.gup...@synopsys.com wrote: Frame pointer on ARC doesn't serve the conventional purpose of stack unwinding due to the typical way ABI designates it's usage. More out of curiosity to understand the platform better than actual review - can you explain a little what you meant by this statement? Is this statement because of the use of write back mode with ld/st to or not related? No - this is not related to to any LD/ST addressing/wb modes. ARCompact ISA has 2 stack related registers, SP (top) and FP (Base) A typical frame pointer-ish ABI would do sometime like this 1. push BLINK (return address) 2. push FP 3. FP = SP 4. push callee-regs 5. allocate stack for local vars etc ... Note that beyond #3, FP remains constant while this function is in scope. Thus from anywhere inside the function, [FP, 4] always has caller's PC and [FP, 0] always has caller's FP. This makes it possible to retract back to caller and from there to it's caller and so on. However the ARC gcc ABI - set in stone many years ago doesn't do this. It does 1, 4, 2, 3... With FP no longer having base address of current call, it can't be used to get FP/BLINK of prev frame so from stack unwinding perspective, there's no point in using FP for stack frames. More importantly, FP usage bloats function prologue/epilogue - adds extra stack ops, hence it's usage in general is discouraged. gcc though is free to summon it's usage for typical stack frames (var sized arrays etc). Hence the reason we don't ever build ARC with FP and need for this patch. HTH, -Vineet -- 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: fix accounting on page_remove_rmap()
There's typo in page_remove_rmap(): we increase NR_ANON_PAGES counter
instead of decreasing it. Let's fix this.
Signed-off-by: Kirill A. Shutemov kirill.shute...@linux.intel.com
Reported-by: Ning Qu qun...@google.com
---
mm/rmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/rmap.c b/mm/rmap.c
index 52cc59a..6219f07 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1156,7 +1156,7 @@ void page_remove_rmap(struct page *page)
__dec_zone_page_state(page,
NR_ANON_TRANSPARENT_HUGEPAGES);
__mod_zone_page_state(page_zone(page), NR_ANON_PAGES,
- hpage_nr_pages(page));
+ -hpage_nr_pages(page));
} else {
__dec_zone_page_state(page, NR_FILE_MAPPED);
mem_cgroup_dec_page_stat(page, MEM_CGROUP_STAT_FILE_MAPPED);
--
1.8.4.rc3
--
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: Memory synchronization vs. interrupt handlers
On 26 August 2013 16:49, Alan Stern st...@rowland.harvard.edu wrote: Here's a question that doesn't seem to be answered in Documentation/memory-barriers.txt. Are memory accesses within an interrupt handler synchronized with respect to interrupts? In more detail, suppose we have an interrupt handler that uses a memory variable A. The device attached to the IRQ line sends two interrupt requests, and we get: CPU 0 CPU 1 - - Receive IRQ Call the interrupt handler Write A Finish IRQ processing Receive IRQ Call the interrupt handler Read A Finish IRQ processing Is CPU 0's write to A guaranteed to be visible on CPU 1? Given that interrupts on an IRQ line are serialized, and that IRQ processing must involve some amount of memory barriers, I would expect the answer to be Yes. On arm (or arm64), this is not guaranteed. Finishing the IRQ processing usually involves a device write but there is no ordering required with other write accesses. It could easily be fixed in the IRQ controller code (drivers/irqchip/irq-gic.c for newer ARM processors). We have a barrier for SMP cross-calls for the same ordering reason, so I guess we need one for EOI as well. In practice I would think it's nearly impossible to hit this issue, given the time to save the state when taking the interrupt plus some spinlocks, the write from CPU0 would become visible. Also, if the data is accessed by the same driver with the same IRQ, most likely the interrupt goes to the same CPU (unless you had some rebalancing, but this being rarer it makes it less likely). If the data is being accessed between two separate IRQ handlers, a spinlock must be used anyway. -- Catalin -- 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 v4 3/3] dma: Add Freescale eDMA engine driver support
On Mon, Sep 02, 2013 at 07:32:53AM +, Lu Jingchang-B35083 wrote:
+ chan-private = fn_param;
why do you need to use chan-private?
[Lu Jingchang]
The private used here is to store the slot_id information, which
must
be used
by the DMAMUX in alloc_chan_resources function. Thanks.
Why dont you pass this in struct dma_slave_config memeber slave_id
for
this.
[Lu Jingchang-b35083]
I will drop this private and setup the slave_id directly in the filter
function.
why in filter? before calling prepare function you can set the slave
config
How about change the filter_fn to follow:
static bool fsl_edma_filter_fn(struct dma_chan *chan, void *fn_param)
{
struct fsl_edma_filter_param *fparam = fn_param;
struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(chan);
unsigned char val;
if (fsl_chan-edmamux-mux_id != fparam-mux_id)
return false;
val = EDMAMUX_CHCFG_ENBL | EDMAMUX_CHCFG_SOURCE(fparam-slot_id);
fsl_edmamux_config_chan(fsl_chan, val);
return true;
}
In fact the slot_id isn't need elsewhere, and if the filter return true,
This channel should be to this request. So no need to save the slave id,
Right?
something like
static bool fsl_edma_filter_fn(struct dma_chan *chan, void *fn_param)
{
struct fsl_edma_filter_param *fparam = fn_param;
struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(chan);
if (fsl_chan-edmamux-mux_id != fparam-mux_id)
return false;
return true;
}
in thedriver which calls this:
before prep:
config-slave_id = val;
dma_set_slave_config(chan, slave);
~Vinod
--
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/6] Remove the duplicated _MAT evaluation and simplify _acpi_map_lsapic()
On Monday, September 02, 2013 11:57:33 AM Hanjun Guo wrote: v1-v2: Return specific error value instead of just return -1, and correct some grammar mistake in changelog. For cpu hot add, evaluate _MAT or parse MADT will did twice to get APIC id: acpi_processor_add() acpi_processor_get_info() acpi_get_cpuid() will evaluate _MAT or parse MADT; acpi_processor_hotadd_init() acpi_map_lsapic() will evaluate _MAT again; This patch set introduces apic_id in struct processor to save parsed APIC id, and use it to remove the duplicated _MAT evaluation. Further more, the new logical cpu number will be generated in acpi_register_lapic(), this can be returned to remove the cpumask allocation and operation to simplify _acpi_map_lsapic(). There are also some cleanups for the ACPI processor dirver code. I like the series, so I've queued it up for 3.13. Thanks, Rafael Hanjun Guo (2): ACPI / processor: remove unnecessary if (!pr) check ACPI / processor: Remove outdated comments Jiang Liu (4): ACPI / processor: Introduce apic_id in struct processor to save parsed APIC id ACPI / processor: use apic_id and remove duplicated _MAT evaluation x86 / ACPI: simplify _acpi_map_lsapic() ACPI / processor: remove some dead code in acpi_processor_get_info() arch/ia64/kernel/acpi.c | 38 ++ arch/x86/include/asm/mpspec.h |2 +- arch/x86/kernel/acpi/boot.c | 88 + arch/x86/kernel/apic/apic.c |8 ++-- drivers/acpi/acpi_processor.c | 22 +++ drivers/acpi/processor_core.c | 26 +--- include/acpi/processor.h |3 ++ include/linux/acpi.h |2 +- 8 files changed, 60 insertions(+), 129 deletions(-) -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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: 3.11-rc7:BUG: soft lockup
On 09/02/2013 05:04 PM, Ding Tianhong wrote:
On 2013/9/2 16:24, Baoquan He wrote:
Hi Tianhong,
I applied your patch and execute below cmd.
Then keyboard inputting problems happened,
I can't enter user/password correctly, then reboot again, it's OK now.
Thanks for your work, I don't understand that the keyboard problem is the
patch fault or your system problem,
if it is not happen again, I think the problem is fixed.
Yeah, I will wait and see if it will happen again. Up to now, it's OK.
Thank you all for help.
Baoquan
Thanks
The original bug still can't be reproduced.
make SUBDIRS=net/bridge/netfilter/
cp /net/bridge/netfilter/ebtables.ko
/lib/modules/3.11.0-rc7+/kernel/net/bridge/netfilter/ebtables.ko
depmod
modprobe ebtables.ko
reboot
Baoquan
Thanks
please try this patch and give me the result, thanks.
Return the correct value if mutex_lock_interruptible() failed, avoid
confusion with that the modules is not exist, and deal with the return
value in right way.
if mutex_lock_interrupt() failed, sh
Signed-off-by: root r...@linux-yocto.site
---
net/bridge/netfilter/ebtables.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/net/bridge/netfilter/ebtables.c
b/net/bridge/netfilter/ebtables.c
index ac78024..e7fe9f8 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -322,17 +322,14 @@ static inline void *
find_inlist_lock_noload(struct list_head *head, const char *name, int
*error,
struct mutex *mutex)
{
- struct {
- struct list_head list;
- char name[EBT_FUNCTION_MAXNAMELEN];
- } *e;
+ struct ebt_table *e;
*error = mutex_lock_interruptible(mutex);
if (*error != 0)
- return NULL;
+ return ERR_PTR(-EINTR);
list_for_each_entry(e, head, list) {
- if (strcmp(e-name, name) == 0)
+if (strcmp(e-name, name) == 0 try_module_get(e-me))
return e;
}
*error = -ENOENT;
@@ -1005,7 +1002,7 @@ static int do_replace_finish(struct net *net, struct
ebt_replace *repl,
goto free_counterstmp;
t = find_table_lock(net, repl-name, ret, ebt_mutex);
- if (!t) {
+ if (IS_ERR_OR_NULL(t)) {
ret = -ENOENT;
goto free_iterate;
}
@@ -1284,7 +1281,7 @@ static int do_update_counters(struct net *net, const
char *name,
return -ENOMEM;
t = find_table_lock(net, name, ret, ebt_mutex);
- if (!t)
+ if (IS_ERR_OR_NULL(t))
goto free_tmp;
if (num_counters != t-private-nentries) {
@@ -1504,7 +1501,7 @@ static int do_ebt_get_ctl(struct sock *sk, int cmd,
void __user *user, int *len)
return -EFAULT;
t = find_table_lock(net, tmp.name, ret, ebt_mutex);
- if (!t)
+ if (IS_ERR_OR_NULL(t))
return ret;
switch(cmd) {
@@ -2319,7 +2316,7 @@ static int compat_do_ebt_get_ctl(struct sock *sk, int
cmd,
return -EFAULT;
t = find_table_lock(net, tmp.name, ret, ebt_mutex);
- if (!t)
+ if (IS_ERR_OR_NULL(t))
return ret;
xt_compat_lock(NFPROTO_BRIDGE);
.
--
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] ACPI / LPSS: don't crash if a device has no MMIO resources
On Monday, September 02, 2013 01:30:25 PM Mika Westerberg wrote:
Intel LPSS devices that are enumerated from ACPI have both MMIO and IRQ
resources returned in their _CRS method. However, Apple Macbook Air with
Haswell has LPSS devices enumerated from PCI bus instead and _CRS method
returns only an interrupt number (but the device has _HID set that causes
the scan handler to match it).
The current ACPI / LPSS code sets pdata-dev_desc only when MMIO resource
is found for the device and in case of Macbook Air it is never found. That
leads to a NULL pointer dereference in register_device_clock().
Correct this by always setting the pdata-dev_desc.
Reported-and-tested-by: Imre Kaloz ka...@openwrt.org
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
Cc: sta...@vger.kernel.org # 3.10+
Queued up for 3.12, thanks for taking care of this Mika!
---
drivers/acpi/acpi_lpss.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 6a38218..fb78bb9 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -257,12 +257,13 @@ static int acpi_lpss_create_device(struct acpi_device
*adev,
pdata-mmio_size = resource_size(rentry-res);
pdata-mmio_base = ioremap(rentry-res.start,
pdata-mmio_size);
- pdata-dev_desc = dev_desc;
break;
}
acpi_dev_free_resource_list(resource_list);
+ pdata-dev_desc = dev_desc;
+
if (dev_desc-clk_required) {
ret = register_device_clock(adev, pdata);
if (ret) {
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
can not debug using gdbserver
hi, i am tring debug a application on an arm based device using gdbserver, in code i am trying to add `set_debug_traps' and `breakpoint' functions but its giving me compilation error something like undefined reference to `set_debug_traps' multisoc.c:594: undefined reference to `breakpoint' i am also tring to debug my code with using these function, after successfull burn and listen from remote connection, i am trying to add break point from main() but it tries to make breakpoint in shared liberaies and do not stop at that point. anybody have idea what i am missing, how i can successfull use up gdbserver 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: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat
On (08/31/13 01:04), Frederic Weisbecker wrote:
in cputime_adjust() `stime' is greater than `rtime', so `utime = rtime -
stime'
sets wrong value.
But stime should always be below rtime due to the calculation done by
scale_stime()
which roughly sums up to:
stime = (stime / stime + utime) * rtime
So this shouldn't happen.
I couldn't manage to reproduce it though. Can you still trigger it with
latest -next?
Hope this may help.
I've added a silly check to make sure that `stime rtime'
@@ -579,6 +582,10 @@ static void cputime_adjust(struct task_cputime *curr,
if (total) {
stime = scale_stime((__force u64)stime,
(__force u64)rtime, (__force u64)total);
+ if (stime rtime) {
+ printk(KERN_ERR Ooops: stime:%llu rtime:%llu\n,
stime, rtime);
+ WARN_ON(1);
+ }
utime = rtime - stime;
} else {
stime = rtime;
and got the following results:
[ 1295.311056] Ooops: stime:4622750929 rtime:4622750928
[ 1295.311063] [ cut here ]
[ 1295.311072] WARNING: CPU: 1 PID: 2167 at kernel/sched/cputime.c:584
cputime_adjust+0x132/0x140()
[ 1295.311123] CPU: 1 PID: 2167 Comm: top Tainted: G C
3.11.0-rc7-next-20130902-dbg-dirty #2
[ 1295.311126] Hardware name: Acer Aspire 5741G/Aspire 5741G
, BIOS V1.20 02/08/2011
[ 1295.311128] 0009 880099937c50 8162fc85
[ 1295.311134] 880099937c88 8104ee2d 8801530bb158
880099937df0
[ 1295.311139] 0001138994d0 0001138994d1 880153118ff0
880099937c98
[ 1295.311145] Call Trace:
[ 1295.311155] [8162fc85] dump_stack+0x4e/0x82
[ 1295.311162] [8104ee2d] warn_slowpath_common+0x7d/0xa0
[ 1295.311166] [8104ef0a] warn_slowpath_null+0x1a/0x20
[ 1295.311170] [8108db72] cputime_adjust+0x132/0x140
[ 1295.311175] [8108e941] thread_group_cputime_adjusted+0x41/0x50
[ 1295.311182] [811f3ac4] do_task_stat+0x9c4/0xb50
[ 1295.311188] [811f4904] proc_tgid_stat+0x14/0x20
[ 1295.311192] [811edac4] proc_single_show+0x54/0xa0
[ 1295.311198] [811a6d24] seq_read+0x164/0x3d0
[ 1295.311204] [811805e1] vfs_read+0xa1/0x180
[ 1295.311208] [8118119c] SyS_read+0x4c/0xa0
[ 1295.311213] [8163ad06] tracesys+0xd4/0xd9
[ 1295.311216] ---[ end trace bab1e899ff45eea2 ]---
[ 1301.384396] Ooops: stime:4654072951 rtime:4654072950
[ 1301.384401] [ cut here ]
[ 1301.384409] WARNING: CPU: 0 PID: 2167 at kernel/sched/cputime.c:584
cputime_adjust+0x132/0x140()
[ 1301.384450] CPU: 0 PID: 2167 Comm: top Tainted: GWC
3.11.0-rc7-next-20130902-dbg-dirty #2
[ 1301.384452] Hardware name: Acer Aspire 5741G/Aspire 5741G
, BIOS V1.20 02/08/2011
[ 1301.384454] 0009 880099937c50 8162fc85
[ 1301.384458] 880099937c88 8104ee2d 8801530bb158
880099937df0
[ 1301.384462] 000115678476 000115678477 880153118ff0
880099937c98
[ 1301.384466] Call Trace:
[ 1301.384475] [8162fc85] dump_stack+0x4e/0x82
[ 1301.384481] [8104ee2d] warn_slowpath_common+0x7d/0xa0
[ 1301.384484] [8104ef0a] warn_slowpath_null+0x1a/0x20
[ 1301.384487] [8108db72] cputime_adjust+0x132/0x140
[ 1301.384491] [8108e941] thread_group_cputime_adjusted+0x41/0x50
[ 1301.384497] [811f3ac4] do_task_stat+0x9c4/0xb50
[ 1301.384501] [811f4904] proc_tgid_stat+0x14/0x20
[ 1301.384504] [811edac4] proc_single_show+0x54/0xa0
[ 1301.384509] [811a6d24] seq_read+0x164/0x3d0
[ 1301.384514] [811805e1] vfs_read+0xa1/0x180
[ 1301.384517] [8118119c] SyS_read+0x4c/0xa0
[ 1301.384521] [8163ad06] tracesys+0xd4/0xd9
[ 1301.384523] ---[ end trace bab1e899ff45eea3 ]---
and so on.
$ dmesg | grep Ooops
[ 1295.311056] Ooops: stime:4622750929 rtime:4622750928
[ 1301.384396] Ooops: stime:4654072951 rtime:4654072950
[ 1307.438935] Ooops: stime:4687858107 rtime:4687858106
[ 1313.493462] Ooops: stime:4724166945 rtime:4724166944
[ 1316.521740] Ooops: stime:4741142233 rtime:4741142232
[ 1325.605625] Ooops: stime:4793906690 rtime:4793906688
[ 1331.648611] Ooops: stime:4308413629 rtime:4308413628
[ 1337.708468] Ooops: stime:4510156747 rtime:4510156746
[ 1340.744586] Ooops: stime:4880584390 rtime:4880584389
[ 1343.773111] Ooops: stime:4442005879 rtime:4442005878
[ 1343.773362] Ooops: stime:4558310943 rtime:4558310942
[ 1349.815797] Ooops: stime:4927379646 rtime:4927379645
[ 1352.836936] Ooops: stime:4942782836 rtime:4942782834
[ 1358.885232] Ooops: stime:4979031940 rtime:4979031938
[ 1364.977902] Ooops: stime:5019633914 rtime:5019633912
[ 1364.978283] Ooops: stime:4601969101 rtime:4601969100
[ 1364.978623] Ooops: stime:4826393815 rtime:4826393814
Re: [PATCH 2/2] cpufreq: serialize calls to __cpufreq_governor()
On Sunday, September 01, 2013 09:30:49 PM Viresh Kumar wrote: On 1 September 2013 18:58, Rafael J. Wysocki r...@sisk.pl wrote: On Sunday, September 01, 2013 10:56:02 AM Viresh Kumar wrote: We can't take a big lock around __cpufreq_governor() as this causes recursive locking for some cases. But calls to this routine must be serialized for every policy. Care to explain here why it must be serialized? Yes, added that to the attached patches (Added reported-by too): OK, the attached patches queued up for 3.12. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] mm/hwpoison: fix false report 2nd try page recovery
If the page is poisoned by software inject w/ MF_COUNT_INCREASED flag, there
is a false report 2nd try page recovery which is not truth, this patch fix it
by report first try free buddy page recovery if MF_COUNT_INCREASED is set.
Before patch:
[ 346.332041] Injecting memory failure at pfn 200010
[ 346.332189] MCE 0x200010: free buddy, 2nd try page recovery: Delayed
After patch:
[ 297.742600] Injecting memory failure at pfn 200010
[ 297.742941] MCE 0x200010: free buddy page recovery: Delayed
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
mm/memory-failure.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index b114570..6293164 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1114,8 +1114,10 @@ int memory_failure(unsigned long pfn, int trapno, int
flags)
* shake_page could have turned it free.
*/
if (is_free_buddy_page(p)) {
- action_result(pfn, free buddy, 2nd try,
- DELAYED);
+ if (flags MF_COUNT_INCREASED)
+ action_result(pfn, free buddy,
DELAYED);
+ else
+ action_result(pfn, free buddy, 2nd
try, DELAYED);
return 0;
}
action_result(pfn, non LRU, IGNORED);
--
1.7.5.4
--
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 4/4] mm/hwpoison: fix the lack of one reference count against poisoned page
The lack of one reference count against poisoned page for hwpoison_inject w/o hwpoison_filter enabled result in hwpoison detect -1 users still referenced the page, however, the number should be 0 except the poison handler held one after successfully unmap. This patch fix it by hold one referenced count against poisoned page for hwpoison_inject w/ and w/o hwpoison_filter enabled. Before patch: [ 71.902112] Injecting memory failure at pfn 224706 [ 71.902137] MCE 0x224706: dirty LRU page recovery: Failed [ 71.902138] MCE 0x224706: dirty LRU page still referenced by -1 users After patch: [ 94.710860] Injecting memory failure at pfn 215b68 [ 94.710885] MCE 0x215b68: dirty LRU page recovery: Recovered Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com --- mm/hwpoison-inject.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/mm/hwpoison-inject.c b/mm/hwpoison-inject.c index afc2daa..4c84678 100644 --- a/mm/hwpoison-inject.c +++ b/mm/hwpoison-inject.c @@ -20,8 +20,6 @@ static int hwpoison_inject(void *data, u64 val) if (!capable(CAP_SYS_ADMIN)) return -EPERM; - if (!hwpoison_filter_enable) - goto inject; if (!pfn_valid(pfn)) return -ENXIO; @@ -33,6 +31,9 @@ static int hwpoison_inject(void *data, u64 val) if (!get_page_unless_zero(hpage)) return 0; + if (!hwpoison_filter_enable) + goto inject; + if (!PageLRU(p) !PageHuge(p)) shake_page(p, 0); /* -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] mm/hwpoison: fix miss catch transparent huge page
PageTransHuge() can't guarantee the page is transparent huge page since it
return true for both transparent huge and hugetlbfs pages. This patch fix
it by check the page is also !hugetlbfs page.
Before patch:
[ 121.571128] Injecting memory failure at pfn 23a200
[ 121.571141] MCE 0x23a200: huge page recovery: Delayed
[ 140.355100] MCE: Memory failure is now running on 0x23a200
After patch:
[ 94.290793] Injecting memory failure at pfn 23a000
[ 94.290800] MCE 0x23a000: huge page recovery: Delayed
[ 105.722303] MCE: Software-unpoisoned page 0x23a000
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
mm/memory-failure.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index e28ee77..b114570 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
* worked by memory_failure() and the page lock is not held yet.
* In such case, we yield to memory_failure() and make unpoison fail.
*/
- if (PageTransHuge(page)) {
+ if (PageTransHuge(page) !PageHuge(page)) {
pr_info(MCE: Memory failure is now running on %#lx\n, pfn);
return 0;
}
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] mm/hwpoison: fix traverse hugetlbfs page to avoid printk flood
madvise_hwpoison won't check if the page is small page or huge page and
traverse
in small page granularity against the range unconditional, which result in a
printk
flood MCE xxx: already hardware poisoned if the page is huge page. This patch
fix
it by increase compound_order(compound_head(page)) for huge page iterator.
Testcase:
#define _GNU_SOURCE
#include stdlib.h
#include stdio.h
#include sys/mman.h
#include unistd.h
#include fcntl.h
#include sys/types.h
#include errno.h
#define PAGES_TO_TEST 3
#define PAGE_SIZE 4096 * 512
int main(void)
{
char *mem;
int i;
mem = mmap(NULL, PAGES_TO_TEST * PAGE_SIZE,
PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS |
MAP_HUGETLB, 0, 0);
if (madvise(mem, PAGES_TO_TEST * PAGE_SIZE, MADV_HWPOISON) == -1)
return -1;
munmap(mem, PAGES_TO_TEST * PAGE_SIZE);
return 0;
}
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
mm/madvise.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/madvise.c b/mm/madvise.c
index 6975bc8..539eeb9 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -343,10 +343,11 @@ static long madvise_remove(struct vm_area_struct *vma,
*/
static int madvise_hwpoison(int bhv, unsigned long start, unsigned long end)
{
+ struct page *p;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
- for (; start end; start += PAGE_SIZE) {
- struct page *p;
+ for (; start end; start += PAGE_SIZE
+ compound_order(compound_head(p))) {
int ret;
ret = get_user_pages_fast(start, 1, 0, p);
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] mm/vmalloc: move VM_UNINITIALIZED just before show_numa_info
The VM_UNINITIALIZED/VM_UNLIST flag introduced by commit f5252e00(mm: avoid null pointer access in vm_struct via /proc/vmallocinfo) is used to avoid accessing the pages field with unallocated page when show_numa_info() is called. This patch move the check just before show_numa_info in order that some messages still can be dumped via /proc/vmallocinfo. Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com --- mm/vmalloc.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index e3ec8b4..c4720cd 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2590,11 +2590,6 @@ static int s_show(struct seq_file *m, void *p) v = va-vm; - /* Pair with smp_wmb() in clear_vm_uninitialized_flag() */ - smp_rmb(); - if (v-flags VM_UNINITIALIZED) - return 0; - seq_printf(m, 0x%pK-0x%pK %7ld, v-addr, v-addr + v-size, v-size); @@ -2622,6 +2617,11 @@ static int s_show(struct seq_file *m, void *p) if (v-flags VM_VPAGES) seq_printf(m, vpages); + /* Pair with smp_wmb() in clear_vm_uninitialized_flag() */ + smp_rmb(); + if (v-flags VM_UNINITIALIZED) + return; + show_numa_info(m, v); seq_putc(m, '\n'); return 0; -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] mm/vmalloc: don't set area-caller twice
The caller address has already been set in set_vmalloc_vm(), there's no need
to set it again in __vmalloc_area_node.
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
mm/vmalloc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 1074543..d78d117 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1566,7 +1566,6 @@ static void *__vmalloc_area_node(struct vm_struct *area,
gfp_t gfp_mask,
pages = kmalloc_node(array_size, nested_gfp, node);
}
area-pages = pages;
- area-caller = caller;
if (!area-pages) {
remove_vm_area(area-addr);
kfree(area);
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] mm/vmalloc: don't warning vmalloc allocation failure twice
Don't warning twice in __vmalloc_area_node and __vmalloc_node_range if __vmalloc_area_node allocation failure. Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com --- mm/vmalloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index ee41cc6..e324d38 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -1635,7 +1635,7 @@ void *__vmalloc_node_range(unsigned long size, unsigned long align, addr = __vmalloc_area_node(area, gfp_mask, prot, node, caller); if (!addr) - goto fail; + return NULL; /* * In this function, newly allocated vm_struct has VM_UNINITIALIZED -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] dmaengine: add driver for Samsung s3c24xx SoCs
On Wed, Aug 28, 2013 at 12:13:51AM +0200, Heiko Stübner wrote:
This adds a new driver to support the s3c24xx dma using the dmaengine
and makes the old one in mach-s3c24xx obsolete in the long run.
Conceptually the s3c24xx-dma feels like a distant relative of the pl08x
with numerous virtual channels being mapped to a lot less physical ones.
The driver therefore borrows a lot from the amba-pl08x driver in this
regard. Functionality-wise the driver gains a memcpy ability in addition
to the slave_sg one.
The driver supports both the method for requesting the peripheral used
by SoCs before the S3C2443 and the different method for S3C2443 and later.
On earlier SoCs the hardware channels usable for specific peripherals is
constrainted while on later SoCs all channels can be used for any peripheral.
Tested on a s3c2416-based board, memcpy using the dmatest module and
slave_sg partially using the spi-s3c64xx driver.
+static int s3c24xx_dma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
+ unsigned long arg)
+{
+ struct s3c24xx_dma_chan *s3cchan = to_s3c24xx_dma_chan(chan);
+ struct s3c24xx_dma_engine *s3cdma = s3cchan-host;
+ unsigned long flags;
+ int ret = 0;
+
+ /* Controls applicable to inactive channels */
+ if (cmd == DMA_SLAVE_CONFIG)
+ return s3c24xx_dma_set_runtime_config(s3cchan,
+ (struct dma_slave_config *)arg);
+
+ /*
+ * Anything succeeds on channels with no physical allocation and
+ * no queued transfers.
+ */
+ spin_lock_irqsave(s3cchan-vc.lock, flags);
+ if (!s3cchan-phy !s3cchan-at) {
+ spin_unlock_irqrestore(s3cchan-vc.lock, flags);
+ return 0;
this can be bad cmd or terminating already closed channel, return 0 doesnt make
sense
+ }
+
+ switch (cmd) {
+ case DMA_TERMINATE_ALL:
why not DMA_SLAVE_CONFIG in this switch to make it look simpler...
+static enum dma_status s3c24xx_dma_tx_status(struct dma_chan *chan,
+ dma_cookie_t cookie, struct dma_tx_state *txstate)
+{
+ struct s3c24xx_dma_chan *s3cchan = to_s3c24xx_dma_chan(chan);
+ struct virt_dma_desc *vd;
+ unsigned long flags;
+ enum dma_status ret;
+ size_t bytes = 0;
+
+ ret = dma_cookie_status(chan, cookie, txstate);
+ if (ret == DMA_SUCCESS)
+ return ret;
+
+ /*
+ * There's no point calculating the residue if there's
+ * no txstate to store the value.
+ */
+ if (!txstate)
+ return ret;
+
+ spin_lock_irqsave(s3cchan-vc.lock, flags);
+ ret = dma_cookie_status(chan, cookie, txstate);
you are checking the cookie status twice, if you check txstate (which should be
valid anyways), then you avoid the duplication
+ if (ret != DMA_SUCCESS) {
+ struct s3c24xx_txd *txd;
+ struct s3c24xx_sg *dsg;
+
+ vd = vchan_find_desc(s3cchan-vc, cookie);
+ if (vd) {
+ /* On the issued list, so hasn't been processed yet */
+ txd = to_s3c24xx_txd(vd-tx);
+
+ list_for_each_entry(dsg, txd-dsg_list, node)
+ bytes += dsg-len;
+ } else {
+ /*
+ * Currently running, so sum over the pending sg's and
+ * the currently active one.
+ */
+ txd = s3cchan-at;
+
+ dsg = list_entry(txd-at, struct s3c24xx_sg, node);
+ list_for_each_entry_from(dsg, txd-dsg_list, node);
+ bytes += dsg-len;
+
+ bytes += s3c24xx_dma_getbytes_chan(s3cchan);
+ }
+ }
+ spin_unlock_irqrestore(s3cchan-vc.lock, flags);
+
+ /*
+ * This cookie not complete yet
+ * Get number of bytes left in the active transactions and queue
+ */
+ dma_set_residue(txstate, bytes);
+
+ /* Whether waiting or running, we're in progress */
+ return ret;
+}
+
+/*
+ * Initialize a descriptor to be used by memcpy submit
+ */
+static struct dma_async_tx_descriptor *s3c24xx_dma_prep_memcpy(
+ struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
+ size_t len, unsigned long flags)
+{
+ struct s3c24xx_dma_chan *s3cchan = to_s3c24xx_dma_chan(chan);
+ struct s3c24xx_dma_engine *s3cdma = s3cchan-host;
+ struct s3c24xx_txd *txd;
+ struct s3c24xx_sg *dsg;
+
+ dev_dbg(s3cdma-pdev-dev, prepare memcpy of %d bytes from %s\n,
+ len, s3cchan-name);
+
+ if ((len S3C24XX_DCON_TC_MASK) != len) {
+ dev_err(s3cdma-pdev-dev, memcpy size %d to large\n, len);
+ return NULL;
+ }
+
+ txd = s3c24xx_dma_get_txd();
+ if (!txd)
+ return NULL;
+
+ dsg =
tsc2007 driver, read data abort after i2c timeout
Hello!
In the last few weeks I worked on a problem I had with I2C errors and the
effect they had on the touchscreen performance with a TI TSC2007 IC.
For I'm stuck with an old kernel (2.6.28) i used the tsc2003 driver, but the
code seems to be close to the tsc2007.c .
I came across the funktion tsc2003_read_values where 5 I2C transfers are
executed after a PenIRQ event (read x,y,z1,z2 and power down).
In this function the return values of the tsc2007_xfer function are ignored. So
there will always be 5 tries to access the bus.
In the I2C driver there is a timeout for failed transfers of 5 second. This
leads to an overall time for the above function of 25s in case of an error on
the i2c bus.
In my case it helped a lot to abort the read_values function after an error
return value from the _xfer function.
I obviously don't know all the details of the tsc code. To this day I don't
understand how the transfer recovers and reacts to the next penirq when the
first transfer is interrupted and so the tsc-chip is never returned to the
power down and listen to the penirq state. Maybe there are good reasons not
to interrupt the function.
Can you comment on this change? Is it a grave mistake or could this work. It
does right now but not understanding all implications means it probably bites
me in the ass at one point.
Attached you'll find a patch for the tsc2003.c file.
Best regards
Sebastian
diff --git a/drivers/input/touchscreen/tsc2003.c
b/drivers/input/touchscreen/tsc2003.c
index 4f3a2c9..7ad62f2 100644
--- a/drivers/input/touchscreen/tsc2003.c
+++ b/drivers/input/touchscreen/tsc2003.c
@@ -115,15 +115,31 @@ static inline int tsc2003_xfer(struct tsc2003 *tsc, u8
cmd)
static void tsc2003_read_values(struct tsc2003 *tsc, struct ts_event *tc)
{
+ s32 temp;
+
+ tc-y = 0;
+ tc-x = 0;
+ tc-z1 = 0;
+ tc-z2 = 0;
+
/* y- still on; turn on only y+ (and ADC) */
- tc-y = tsc2003_xfer(tsc, READ_Y);
+ temp = tsc2003_xfer(tsc, READ_Y);
+ if (temp 0) tc-y = temp;
+ else return;
/* turn y- off, x+ on, then leave in lowpower */
- tc-x = tsc2003_xfer(tsc, READ_X);
+ temp = tsc2003_xfer(tsc, READ_X);
+ if (temp 0) tc-x = temp;
+ else return;
/* turn y+ off, x- on; we'll use formula #1 */
- tc-z1 = tsc2003_xfer(tsc, READ_Z1);
- tc-z2 = tsc2003_xfer(tsc, READ_Z2);
+ temp = tsc2003_xfer(tsc, READ_Z1);
+ if (temp 0) tc-z1 = temp;
+ else return;
+
+ temp = tsc2003_xfer(tsc, READ_Z2);
+ if (temp 0) tc-z2 = temp;
+ else return;
/* Prepare for next touch reading - power down ADC, enable PENIRQ */
tsc2003_xfer(tsc, PWRDOWN);
--
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 v4 0/6] dma: edma: Support scatter-lists of any length
On Thu, 2013-08-29 at 18:05 -0500, Joel Fernandes wrote: The following series adds support to EDMA driver to enable DMA of scatter-gather lists of arbitrary length, but still make use of only a certain MAX number of slots at a time for a given channel. Thus free-ing up the rest of the slots to other slaves/channels. With this there is no need for slave drivers to query the EDMA driver about how much is the MAX it can send at a time as done in [1]. Drivers can send SG lists of any number of entries to DMA. Reference discussion at [2]. With this, all the patches for MMC and EDMA related to sg limits can be dropped. Tested omap-aes and omap_hsmmc drivers with different MAX number of slots, even just 1. In the case where it is 1, only 1-slot is used to DMA an entire scatter list of arbitrary length. Since this series touches EDMA private API code also shared with davinci-pcm, playback of a 16-bit 44.1KHz audio file with davinci-pcm has been tested. Sample test run with 1 vs 16 (MAX number of slots/SG) in omap-aes driver: MAX slots = 1: (128 bit key, 8192 byte blocks): 1266 operations in 1 seconds (10371072 bytes) MAX slots = 16: (128 bit key, 8192 byte blocks): 1601 operations in 1 seconds (13115392 bytes) Note: For the above test, 8K buffer is mapped into SG list of size 2 so only 2 slots are required. So beyond size 2, there will not be any noticeable performance improvement. But above experiment just shows as proof of concept that even using 1 slot is managed by just DMA'ing 1 SG entry at a time. much better series, thanks I think i am okay with this, if anyone has objections pls speak up. Also I need ack on the ARM patch 3/6 before I can carry this. -- Vinod Koul Intel Corp. -- 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/7] dma: replace devm_request_and_ioremap by devm_ioremap_resource
On Mon, Aug 19, 2013 at 01:20:38PM +0200, Julia Lawall wrote: From: Julia Lawall julia.law...@lip6.fr Use devm_ioremap_resource instead of devm_request_and_ioremap. This was done using the semantic patch scripts/coccinelle/api/devm_ioremap_resource.cocci The relevant call to platform_get_resource was manually moved down to the call to devm_ioremap_resource. Applied, thanks ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] dma: sh: use devm_ioremap_resource() instead of devm_request_and_ioremap()
On Mon, Sep 02, 2013 at 12:04:29PM +0530, Vinod Koul wrote: On Mon, Sep 02, 2013 at 10:23:15AM +0900, Jingoo Han wrote: Use devm_ioremap_resource() because devm_request_and_ioremap() is obsoleted by devm_ioremap_resource(). Applied both, Thanks I have removed this one and reapplied patch 2. This was duplicate of Julia's patch which was sent earlier, so I have applied that one ~Vinod -- -- 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: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat
On Mon, Sep 02, 2013 at 03:28:45PM +0300, Sergey Senozhatsky wrote:
On (08/31/13 01:04), Frederic Weisbecker wrote:
in cputime_adjust() `stime' is greater than `rtime', so `utime = rtime -
stime'
sets wrong value.
But stime should always be below rtime due to the calculation done by
scale_stime()
which roughly sums up to:
stime = (stime / stime + utime) * rtime
So this shouldn't happen.
I couldn't manage to reproduce it though. Can you still trigger it with
latest -next?
Hope this may help.
I've added a silly check to make sure that `stime rtime'
@@ -579,6 +582,10 @@ static void cputime_adjust(struct task_cputime *curr,
if (total) {
stime = scale_stime((__force u64)stime,
(__force u64)rtime, (__force u64)total);
+ if (stime rtime) {
+ printk(KERN_ERR Ooops: stime:%llu rtime:%llu\n,
stime, rtime);
+ WARN_ON(1);
+ }
utime = rtime - stime;
} else {
stime = rtime;
and got the following results:
[ 1295.311056] Ooops: stime:4622750929 rtime:4622750928
[ 1295.311063] [ cut here ]
[ 1295.311072] WARNING: CPU: 1 PID: 2167 at kernel/sched/cputime.c:584
cputime_adjust+0x132/0x140()
[ 1295.311123] CPU: 1 PID: 2167 Comm: top Tainted: G C
3.11.0-rc7-next-20130902-dbg-dirty #2
[ 1295.311126] Hardware name: Acer Aspire 5741G/Aspire 5741G
, BIOS V1.20 02/08/2011
[ 1295.311128] 0009 880099937c50 8162fc85
[ 1295.311134] 880099937c88 8104ee2d 8801530bb158
880099937df0
[ 1295.311139] 0001138994d0 0001138994d1 880153118ff0
880099937c98
[ 1295.311145] Call Trace:
[ 1295.311155] [8162fc85] dump_stack+0x4e/0x82
[ 1295.311162] [8104ee2d] warn_slowpath_common+0x7d/0xa0
[ 1295.311166] [8104ef0a] warn_slowpath_null+0x1a/0x20
[ 1295.311170] [8108db72] cputime_adjust+0x132/0x140
[ 1295.311175] [8108e941] thread_group_cputime_adjusted+0x41/0x50
[ 1295.311182] [811f3ac4] do_task_stat+0x9c4/0xb50
[ 1295.311188] [811f4904] proc_tgid_stat+0x14/0x20
[ 1295.311192] [811edac4] proc_single_show+0x54/0xa0
[ 1295.311198] [811a6d24] seq_read+0x164/0x3d0
[ 1295.311204] [811805e1] vfs_read+0xa1/0x180
[ 1295.311208] [8118119c] SyS_read+0x4c/0xa0
[ 1295.311213] [8163ad06] tracesys+0xd4/0xd9
[ 1295.311216] ---[ end trace bab1e899ff45eea2 ]---
[ 1301.384396] Ooops: stime:4654072951 rtime:4654072950
[ 1301.384401] [ cut here ]
[ 1301.384409] WARNING: CPU: 0 PID: 2167 at kernel/sched/cputime.c:584
cputime_adjust+0x132/0x140()
[ 1301.384450] CPU: 0 PID: 2167 Comm: top Tainted: GWC
3.11.0-rc7-next-20130902-dbg-dirty #2
[ 1301.384452] Hardware name: Acer Aspire 5741G/Aspire 5741G
, BIOS V1.20 02/08/2011
[ 1301.384454] 0009 880099937c50 8162fc85
[ 1301.384458] 880099937c88 8104ee2d 8801530bb158
880099937df0
[ 1301.384462] 000115678476 000115678477 880153118ff0
880099937c98
[ 1301.384466] Call Trace:
[ 1301.384475] [8162fc85] dump_stack+0x4e/0x82
[ 1301.384481] [8104ee2d] warn_slowpath_common+0x7d/0xa0
[ 1301.384484] [8104ef0a] warn_slowpath_null+0x1a/0x20
[ 1301.384487] [8108db72] cputime_adjust+0x132/0x140
[ 1301.384491] [8108e941] thread_group_cputime_adjusted+0x41/0x50
[ 1301.384497] [811f3ac4] do_task_stat+0x9c4/0xb50
[ 1301.384501] [811f4904] proc_tgid_stat+0x14/0x20
[ 1301.384504] [811edac4] proc_single_show+0x54/0xa0
[ 1301.384509] [811a6d24] seq_read+0x164/0x3d0
[ 1301.384514] [811805e1] vfs_read+0xa1/0x180
[ 1301.384517] [8118119c] SyS_read+0x4c/0xa0
[ 1301.384521] [8163ad06] tracesys+0xd4/0xd9
[ 1301.384523] ---[ end trace bab1e899ff45eea3 ]---
and so on.
$ dmesg | grep Ooops
[ 1295.311056] Ooops: stime:4622750929 rtime:4622750928
[ 1301.384396] Ooops: stime:4654072951 rtime:4654072950
[ 1307.438935] Ooops: stime:4687858107 rtime:4687858106
[ 1313.493462] Ooops: stime:4724166945 rtime:4724166944
[ 1316.521740] Ooops: stime:4741142233 rtime:4741142232
[ 1325.605625] Ooops: stime:4793906690 rtime:4793906688
[ 1331.648611] Ooops: stime:4308413629 rtime:4308413628
[ 1337.708468] Ooops: stime:4510156747 rtime:4510156746
[ 1340.744586] Ooops: stime:4880584390 rtime:4880584389
[ 1343.773111] Ooops: stime:4442005879 rtime:4442005878
[ 1343.773362] Ooops: stime:4558310943 rtime:4558310942
[ 1349.815797] Ooops: stime:4927379646 rtime:4927379645
[ 1352.836936] Ooops: stime:4942782836 rtime:4942782834
[ 1358.885232] Ooops: stime:4979031940 rtime
[PATCH] dmaengine: dma_slave_caps: remove sg entries
As pointed by Russell in [1], the sg properties are already availble in struct
device,
so no need to duplicate here.
[1]: http://marc.info/?l=linux-omapm=137416733628831
Signed-off-by: Vinod Koul vinod.k...@intel.com
---
include/linux/dmaengine.h |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 5692bc3..4310b89 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -380,11 +380,6 @@ struct dma_slave_config {
* should be checked by controller as well
* @cmd_pause: true, if pause and thereby resume is supported
* @cmd_terminate: true, if terminate cmd is supported
- *
- * @max_sg_nr: maximum number of SG segments supported
- * 0 for no maximum
- * @max_sg_len: maximum length of a SG segment supported
- * 0 for no maximum
*/
struct dma_slave_caps {
u32 src_addr_widths;
@@ -392,9 +387,6 @@ struct dma_slave_caps {
u32 directions;
bool cmd_pause;
bool cmd_terminate;
-
- u32 max_sg_nr;
- u32 max_sg_len;
};
static inline const char *dma_chan_name(struct dma_chan *chan)
--
1.7.0.4
--
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: perf_event: rdpmc self-monitoring overhead issue
On Mon, 2 Sep 2013, Stephane Eranian wrote: On Mon, Sep 2, 2013 at 4:50 AM, Andi Kleen a...@firstfloor.org wrote: Stephane Eranian eran...@googlemail.com writes: I don't see a flag in mmap() to fault it in immediately. MAP_PRESENT I could not find this constant defined anywhere in the kernel source tree nor in /usr/include. Are you sure of the name? I assume he means MAP_POPULATE which does improve things, from ~3000 cycles to ~219 cycles but that's still more overhead than the ~130 or so you get by manually touching the page first. Vince -- 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: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat
On (09/02/13 15:07), Frederic Weisbecker wrote: $ dmesg | grep Ooops [ 1295.311056] Ooops: stime:4622750929 rtime:4622750928 [ 1301.384396] Ooops: stime:4654072951 rtime:4654072950 [ 1307.438935] Ooops: stime:4687858107 rtime:4687858106 [ 1313.493462] Ooops: stime:4724166945 rtime:4724166944 [ 1316.521740] Ooops: stime:4741142233 rtime:4741142232 [ 1325.605625] Ooops: stime:4793906690 rtime:4793906688 [ 1331.648611] Ooops: stime:4308413629 rtime:4308413628 [ 1337.708468] Ooops: stime:4510156747 rtime:4510156746 [ 1340.744586] Ooops: stime:4880584390 rtime:4880584389 [ 1343.773111] Ooops: stime:4442005879 rtime:4442005878 [ 1343.773362] Ooops: stime:4558310943 rtime:4558310942 [ 1349.815797] Ooops: stime:4927379646 rtime:4927379645 [ 1352.836936] Ooops: stime:4942782836 rtime:4942782834 [ 1358.885232] Ooops: stime:4979031940 rtime:4979031938 [ 1364.977902] Ooops: stime:5019633914 rtime:5019633912 [ 1364.978283] Ooops: stime:4601969101 rtime:4601969100 [ 1364.978623] Ooops: stime:4826393815 rtime:4826393814 [ 1371.034265] Ooops: stime:4894272175 rtime:4894272174 [ 1374.077150] Ooops: stime:4688831829 rtime:4688831828 [ 1374.077519] Ooops: stime:4916319315 rtime:4916319314 [ 1377.110416] Ooops: stime:5084174048 rtime:5084174047 [ 1377.111043] Ooops: stime:4949250198 rtime:4949250196 [ 1380.137382] Ooops: stime:5096963048 rtime:5096963046 [ 1380.137739] Ooops: stime:4975014880 rtime:4975014879 [ 1383.161441] Ooops: stime:5002466396 rtime:5002466394 [ 1389.212166] Ooops: stime:5140400038 rtime:5140400036 [ 1392.239303] Ooops: stime:5082051028 rtime:5082051027 [ 1395.270391] Ooops: stime:5170118636 rtime:5170118634 [ 1398.303593] Ooops: stime:5184355318 rtime:5184355316 Thanks a lot Sergey for testing this further! Interesting results, so rtime is always one or two units off stime after scaling. Stanislaw made the scaling code with Linus and he has a better idea on the math guts here. Stanislaw, any idea? sure. sorry, it took so long to get back to this. actual scale_stime() input that triggers overflow: [ 1291.409566] stime:3790580815 rtime:4344293130 total:3790580815 [ 1300.484675] stime:3966526699 rtime:4316110636 total:3966526699 [ 1309.548850] stime:4016453845 rtime:4369061182 total:4016453845 [ 1315.597880] stime:4055256777 rtime:4409603756 total:4055256777 [ 1315.598340] stime:4004230541 rtime:4571167362 total:4004230541 [ 1318.623774] stime:4072651687 rtime:4427641260 total:4072651687 [ 1318.624194] stime:3307672697 rtime:4359433252 total:3307672697 [ 1321.661950] stime:4073588267 rtime:4644946914 total:4073588267 [ 1324.691457] stime:4105876887 rtime:4462631018 total:4105876887 [ 1327.722074] stime:3375231967 rtime:4439900096 total:3375231967 [ 1333.757482] stime:4156087279 rtime:4514990216 total:4156087279 [ 1333.757755] stime:3427423145 rtime:4504337498 total:3427423145 [ 1333.758080] stime:4180115893 rtime:4758073724 total:4180115893 [ 1339.813117] stime:3465843945 rtime:4554325330 total:3465843945 [ 1342.845746] stime:4204665773 rtime:4565346324 total:4204665773 [ 1345.888570] stime:3497346343 rtime:4592210094 total:3497346343 [ 1348.922371] stime:4348957782 rtime:4935439460 total:4348957782 [ 1351.950096] stime:4362056506 rtime:4949617939 total:4362056506 [ 1361.021453] stime:4295785738 rtime:4661661137 total:4295785738 [ 1361.022000] stime:4458897246 rtime:5051395981 total:4458897246 [ 1364.050371] stime:4311972683 rtime:4678581654 total:4311972683 [ 1364.050765] stime:4479087426 rtime:5072949454 total:4479087426 [ 1367.076973] stime:4499465526 rtime:5094687861 total:4499465526 [ 1370.099987] stime:4343775870 rtime:4712036053 total:4343775870 [ 1373.125650] stime:4359154163 rtime:4727095545 total:4359154163 [ 1373.126009] stime:4552630150 rtime:5150626456 total:4552630150 [ 1376.148541] stime:4374640011 rtime:4743265121 total:4374640011 [ 1379.177031] stime:3732027459 rtime:4887067184 total:3732027459 [ 1382.220666] stime:4404735122 rtime:4774829507 total:4404735122 [ 1385.246696] stime:4420289930 rtime:4790957716 total:4420289930 [ 1385.247197] stime:4649961982 rtime:5253432805 total:4649961982 [ 1388.269661] stime:4433706951 rtime:4804365472 total:4433706951 [ 1388.270078] stime:3783514895 rtime:4952742424 total:3783514895 [ 1391.299533] stime:4449952651 rtime:4821791998 total:4449952651 [ 1394.329016] stime:4463714342 rtime:4836891922 total:4463714342 -ss -- 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: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat
On Mon, Sep 02, 2013 at 03:07:45PM +0200, Frederic Weisbecker wrote:
Hope this may help.
I've added a silly check to make sure that `stime rtime'
@@ -579,6 +582,10 @@ static void cputime_adjust(struct task_cputime *curr,
if (total) {
stime = scale_stime((__force u64)stime,
(__force u64)rtime, (__force u64)total);
+ if (stime rtime) {
+ printk(KERN_ERR Ooops: stime:%llu rtime:%llu\n,
stime, rtime);
+ WARN_ON(1);
+ }
utime = rtime - stime;
} else {
stime = rtime;
[snip]
Thanks a lot Sergey for testing this further!
Interesting results, so rtime is always one or two units off stime after
scaling.
Stanislaw made the scaling code with Linus and he has a better idea on the
math guts
here.
I don't think this is scale issue, but rather at scale_stime() input
stime is already bigger then rtime. Sergey, could you verify that
by adding check before scale_stime() ?
Stanislaw
--
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/
Please discard checkpatch: warn when using extern with function prototypes in .h files
I noticed that a patch got committed to checkpatch to complain about function prototypes prefixed by extern. Please discard/revert this patch: commit 7cd0f806622836e386ef18ad1950a9a729803019 Author: Joe Perches j...@perches.com Date: Wed Aug 28 10:16:00 2013 +1000 checkpatch: warn when using extern with function prototypes in .h files Using the extern keyword on function prototypes is superfluous visual noise so suggest removing it. This is inaccurate. It's actually a useful visual cue - so if anything, please make checkpatch indicate that it be added to all future function prototypes. David -- 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/
Fix style in s3c-hsotg.c
Hi!
checkpatch.pl has some valid complaints about style in s3c-hsotg.c :
macro with if should be really enclosed in do {} while, and puts is
going to be slightly faster.
Here's suggested patch. I don't have the hardware, so it is completely
untested.
Signed-off-by: Pavel Machek, pa...@denx.de
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index af22f24..f8e762a 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -2091,12 +2091,14 @@ static void kill_all_requests(struct s3c_hsotg *hsotg,
}
#define call_gadget(_hs, _entry) \
+do { \
if ((_hs)-gadget.speed != USB_SPEED_UNKNOWN \
(_hs)-driver (_hs)-driver-_entry) { \
spin_unlock(_hs-lock); \
(_hs)-driver-_entry((_hs)-gadget); \
spin_lock(_hs-lock); \
}
+} while (0)
/**
* s3c_hsotg_disconnect - disconnect service
@@ -3204,7 +3206,7 @@ static int state_show(struct seq_file *seq, void *v)
readl(regs + GNPTXSTS),
readl(regs + GRXSTSR));
- seq_printf(seq, \nEndpoint status:\n);
+ seq_puts(seq, \nEndpoint status:\n);
for (idx = 0; idx 15; idx++) {
u32 in, out;
@@ -3221,7 +3223,7 @@ static int state_show(struct seq_file *seq, void *v)
seq_printf(seq, , DIEPTSIZ=0x%08x, DOEPTSIZ=0x%08x,
in, out);
- seq_printf(seq, \n);
+ seq_puts(seq, \n);
}
return 0;
@@ -3255,7 +3257,7 @@ static int fifo_show(struct seq_file *seq, void *v)
u32 val;
int idx;
- seq_printf(seq, Non-periodic FIFOs:\n);
+ seq_puts(seq, Non-periodic FIFOs:\n);
seq_printf(seq, RXFIFO: Size %d\n, readl(regs + GRXFSIZ));
val = readl(regs + GNPTXFSIZ);
@@ -3263,7 +3265,7 @@ static int fifo_show(struct seq_file *seq, void *v)
val GNPTXFSIZ_NPTxFDep_SHIFT,
val GNPTXFSIZ_NPTxFStAddr_MASK);
- seq_printf(seq, \nPeriodic TXFIFOs:\n);
+ seq_puts(seq, \nPeriodic TXFIFOs:\n);
for (idx = 1; idx = 15; idx++) {
val = readl(regs + DPTXFSIZn(idx));
@@ -3334,7 +3336,7 @@ static int ep_show(struct seq_file *seq, void *v)
readl(regs + DIEPTSIZ(index)),
readl(regs + DOEPTSIZ(index)));
- seq_printf(seq, \n);
+ seq_puts(seq, \n);
seq_printf(seq, mps %d\n, ep-ep.maxpacket);
seq_printf(seq, total_data=%ld\n, ep-total_data);
@@ -3345,7 +3347,7 @@ static int ep_show(struct seq_file *seq, void *v)
list_for_each_entry(req, ep-queue, queue) {
if (--show_limit 0) {
- seq_printf(seq, not showing more requests...\n);
+ seq_puts(seq, not showing more requests...\n);
break;
}
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat
On (09/02/13 15:50), Stanislaw Gruszka wrote:
Date: Mon, 2 Sep 2013 15:50:34 +0200
From: Stanislaw Gruszka sgrus...@redhat.com
To: Frederic Weisbecker fweis...@gmail.com
Cc: Sergey Senozhatsky sergey.senozhat...@gmail.com, Ingo Molnar
mi...@redhat.com, Peter Zijlstra pet...@infradead.org, Paul E.
McKenney paul...@linux.vnet.ibm.com, Borislav Petkov b...@alien8.de,
linux-kernel@vger.kernel.org
Subject: Re: [sched next] overflowed cpu time for kernel threads in
/proc/PID/stat
User-Agent: Mutt/1.5.21 (2010-09-15)
On Mon, Sep 02, 2013 at 03:07:45PM +0200, Frederic Weisbecker wrote:
Hope this may help.
I've added a silly check to make sure that `stime rtime'
@@ -579,6 +582,10 @@ static void cputime_adjust(struct task_cputime *curr,
if (total) {
stime = scale_stime((__force u64)stime,
(__force u64)rtime, (__force
u64)total);
+ if (stime rtime) {
+ printk(KERN_ERR Ooops: stime:%llu rtime:%llu\n,
stime, rtime);
+ WARN_ON(1);
+ }
utime = rtime - stime;
} else {
stime = rtime;
[snip]
Thanks a lot Sergey for testing this further!
Interesting results, so rtime is always one or two units off stime after
scaling.
Stanislaw made the scaling code with Linus and he has a better idea on the
math guts
here.
I don't think this is scale issue, but rather at scale_stime() input
stime is already bigger then rtime. Sergey, could you verify that
by adding check before scale_stime() ?
usually stime rtime.
this is what scale_stime() gets as input:
[ 1291.409566] stime:3790580815 rtime:4344293130 total:3790580815
[ 1300.484675] stime:3966526699 rtime:4316110636 total:3966526699
[ 1309.548850] stime:4016453845 rtime:4369061182 total:4016453845
[ 1315.597880] stime:4055256777 rtime:4409603756 total:4055256777
[ 1315.598340] stime:4004230541 rtime:4571167362 total:4004230541
[ 1318.623774] stime:4072651687 rtime:4427641260 total:4072651687
[ 1318.624194] stime:3307672697 rtime:4359433252 total:3307672697
[ 1321.661950] stime:4073588267 rtime:4644946914 total:4073588267
[ 1324.691457] stime:4105876887 rtime:4462631018 total:4105876887
[ 1327.722074] stime:3375231967 rtime:4439900096 total:3375231967
[ 1333.757482] stime:4156087279 rtime:4514990216 total:4156087279
[ 1333.757755] stime:3427423145 rtime:4504337498 total:3427423145
[ 1333.758080] stime:4180115893 rtime:4758073724 total:4180115893
[ 1339.813117] stime:3465843945 rtime:4554325330 total:3465843945
[ 1342.845746] stime:4204665773 rtime:4565346324 total:4204665773
[ 1345.888570] stime:3497346343 rtime:4592210094 total:3497346343
[ 1348.922371] stime:4348957782 rtime:4935439460 total:4348957782
[ 1351.950096] stime:4362056506 rtime:4949617939 total:4362056506
[ 1361.021453] stime:4295785738 rtime:4661661137 total:4295785738
[ 1361.022000] stime:4458897246 rtime:5051395981 total:4458897246
[ 1364.050371] stime:4311972683 rtime:4678581654 total:4311972683
[ 1364.050765] stime:4479087426 rtime:5072949454 total:4479087426
[ 1367.076973] stime:4499465526 rtime:5094687861 total:4499465526
[ 1370.099987] stime:4343775870 rtime:4712036053 total:4343775870
[ 1373.125650] stime:4359154163 rtime:4727095545 total:4359154163
[ 1373.126009] stime:4552630150 rtime:5150626456 total:4552630150
[ 1376.148541] stime:4374640011 rtime:4743265121 total:4374640011
[ 1379.177031] stime:3732027459 rtime:4887067184 total:3732027459
[ 1382.220666] stime:4404735122 rtime:4774829507 total:4404735122
[ 1385.246696] stime:4420289930 rtime:4790957716 total:4420289930
[ 1385.247197] stime:4649961982 rtime:5253432805 total:4649961982
[ 1388.269661] stime:4433706951 rtime:4804365472 total:4433706951
[ 1388.270078] stime:3783514895 rtime:4952742424 total:3783514895
[ 1391.299533] stime:4449952651 rtime:4821791998 total:4449952651
[ 1394.329016] stime:4463714342 rtime:4836891922 total:4463714342
-ss
--
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 v4 3/6] ARM: edma: Add function to manually trigger an EDMA channel
On 8/30/2013 4:35 AM, Joel Fernandes wrote: Manual trigger for events missed as a result of splitting a scatter gather list and DMA'ing it in batches. Add a helper function to trigger a channel incase any such events are missed. Signed-off-by: Joel Fernandes jo...@ti.com Acked-by: Sekhar Nori nsek...@ti.com Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 3/5] drivers: thermal: make usage of CONFIG_THERMAL_HWMON optional
Hi,
On 29-08-2013 16:12, Eduardo Valentin wrote:
When registering a new thermal_device, the thermal framework
will always add a hwmon sysfs interface.
This patch adds a flag to make this behavior optional. Now
when registering a new thermal device, the caller can
optionally inform if hwmon interface is desirable. This can
be done by means of passing a thermal_zone_params.no_hwmon == true.
In order to keep same behavior as of today, all current
calls will by default create the hwmon interface.
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: Zhang Rui rui.zh...@intel.com
Suggested-by: Wei Ni w...@nvidia.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
Documentation/thermal/sysfs-api.txt | 5 +
drivers/thermal/thermal_core.c | 8 +---
include/linux/thermal.h | 8
3 files changed, 18 insertions(+), 3 deletions(-)
---
Hello all,
So, here is then a different way of implementing same feature.
As requested by Rui, now the flag goes via thermal_zone_params,
because this seams to be the preferred way, at least in near future.
Using this method the amount of subsystems involved is reduced to 1:
thermal, as requested by Raphael. I just made is a negative flag
in order to keep the same behavior of the existing drivers, without
changing them. The flag is documented though.
Objections on this way of adding this flag?
Rui,
If you are OK, I can add this series to my tree too.
All best,
diff --git a/Documentation/thermal/sysfs-api.txt
b/Documentation/thermal/sysfs-api.txt
index a71bd5b..37c5486 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -142,6 +142,11 @@ temperature) and throttle appropriate devices.
This is an optional feature where some platforms can choose not to
provide this data.
.governor_name: Name of the thermal governor used for this zone
+.no_hwmon: a boolean to indicate if the thermal to hwmon sysfs interface
+ is required. when no_hwmon == false, a hwmon sysfs interface
+ will be created. when no_hwmon == true, nothing will be done.
+ In case the thermal_zone_params is NULL, the hwmon interface
+ will be created (for backward compatibility).
.num_tbps: Number of thermal_bind_params entries for this zone
.tbp: thermal_bind_params entries
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 247528b..51648bf 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1462,9 +1462,11 @@ struct thermal_zone_device
*thermal_zone_device_register(const char *type,
mutex_unlock(thermal_governor_lock);
- result = thermal_add_hwmon_sysfs(tz);
- if (result)
- goto unregister;
+ if (!tz-tzp || !tz-tzp-no_hwmon) {
+ result = thermal_add_hwmon_sysfs(tz);
+ if (result)
+ goto unregister;
+ }
mutex_lock(thermal_list_lock);
list_add_tail(tz-node, thermal_tz_list);
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index a386a1c..b4a975f 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -214,6 +214,14 @@ struct thermal_bind_params {
/* Structure to define Thermal Zone parameters */
struct thermal_zone_params {
char governor_name[THERMAL_NAME_LENGTH];
+
+ /*
+ * a boolean to indicate if the thermal to hwmon sysfs interface
+ * is required. when no_hwmon == false, a hwmon sysfs interface
+ * will be created. when no_hwmon == true, nothing will be done
+ */
+ bool no_hwmon;
+
int num_tbps; /* Number of tbp entries */
struct thermal_bind_params *tbp;
};
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
[PATCH RFC 0/6] ARM: OMAP2+: AM43x/AM335x prcm reset driver
Hi,
This is an attempt to achieve reset on AM43x/AM335x based SoC's with
reset driver making use of the reset framework.
prcm node is added in device tree, which would hold reset bindings.
Initially node was made as a one that represents reset functionality
of SoC. but ended up with node for prcm (which is felt to be natural
choice) instead. I am a bit doubtful whether placement of prcm node in
root node as in this series is the right thing.
Reset driver gets probed for specific prcm node, the same defines
register details to be used for a particular SoC (using .data field
associated with .compatible in driver match table).
Another option to handle different SoC's would be to add register
details to DT and let the driver extract it from DT. I vaguely
remember seeing a thread mentioning that putting register details in
DT is not preferred. But open to putting register level details
instead in DT if that is being generally preferred. This would have
advantage that adding reset support for a new SoC would be easier, but
would have to put more thought before doing so as DT bindings should
not change.
With the approach taken here, for supporting a new SoC with new prcm
register details, driver would have to be updated much like the way a
pci based ethernet driver would have to be updated to handle a new IP
version that is not register level compatible with the existing ones.
In this series out of the three IP's (gfx, m3, pruss) that would need
reset support, here as a proof of concept only gfx is taken care.
Other's can be easily supported by adding new register data array
entries.
Two new reset API's are provided to check whether reset is ready and
to clear reset. This would be required in case IP needs to mix reset
handling procedure with power/clock managment procedure to achieve
proper reset and these procedures are sometimes IP specific that would
make it difficult to handle reset fully in pm_runtime platform support.
*--*
client IP handling s/w (DT based) should do as follows:
1. Specify reset handle in the relevant DT node, for eg.
myip@deadbeef {
:
:
/* here prcm is the handle to reset binding node */
resets = prcm 0;
};
2. In driver, that require reset to be deasserted,
(this is the sequence required for gfx on AM43x/AM335x, this would
depend on requirements of the IP)
mydriver_probe(struct platform device *pdev)
{
:
:
reset_control_get(pdev-dev, NULL);
reset_control_clear_reset();
reset_control_deassert();
pm_runtime_get_sync();
if (reset_control_is_reset() != true)
goto err;
reset_control_put();
:
:
}
*--*
May be removing reset handling in hwmod can be considered by making
use of reset driver.
Or as another extreme, perhaps, other logic's in the prcm can be
handled by a new prcm driver and then this reset driver can be a child
of it.
Regards
Afzal
Afzal Mohammed (6):
reset: is_reset and clear_reset api's
doc: dt: binding: omap: am43x/am335x prcm reset
reset: am43x/am335x support
ARM: OMAP2+: AM43x/AM335x: have reset controller
ARM: dts: AM335x: prcm node (for reset)
ARM: dts: AM4372: prcm node (for reset)
.../devicetree/bindings/arm/omap/prcm.txt | 13 ++
arch/arm/boot/dts/am33xx.dtsi | 6 +
arch/arm/boot/dts/am4372.dtsi | 6 +
arch/arm/mach-omap2/Kconfig| 2 +
drivers/reset/Kconfig | 14 ++
drivers/reset/Makefile | 1 +
drivers/reset/amx3_reset.c | 157 +
drivers/reset/core.c | 32 +
include/linux/reset-controller.h | 2 +
include/linux/reset.h | 2 +
10 files changed, 235 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/prcm.txt
create mode 100644 drivers/reset/amx3_reset.c
--
1.8.3.4
--
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: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat
On Mon, Sep 02, 2013 at 03:50:34PM +0200, Stanislaw Gruszka wrote:
On Mon, Sep 02, 2013 at 03:07:45PM +0200, Frederic Weisbecker wrote:
Hope this may help.
I've added a silly check to make sure that `stime rtime'
@@ -579,6 +582,10 @@ static void cputime_adjust(struct task_cputime *curr,
if (total) {
stime = scale_stime((__force u64)stime,
(__force u64)rtime, (__force
u64)total);
+ if (stime rtime) {
+ printk(KERN_ERR Ooops: stime:%llu rtime:%llu\n,
stime, rtime);
+ WARN_ON(1);
+ }
utime = rtime - stime;
} else {
stime = rtime;
[snip]
Thanks a lot Sergey for testing this further!
Interesting results, so rtime is always one or two units off stime after
scaling.
Stanislaw made the scaling code with Linus and he has a better idea on the
math guts
here.
I don't think this is scale issue, but rather at scale_stime() input
stime is already bigger then rtime. Sergey, could you verify that
by adding check before scale_stime() ?
Note that having stime rtime should be fine to handle. This can happen for
example if the task runs on tiny timeslices but is unlucky enough that all these
timeslices are interrupted by the tick.
Stanislaw
--
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 RFC 1/6] reset: is_reset and clear_reset api's
Enhance reset framework with is_reset and clear_reset api's.
is_reset - used by client driver to know reset status
clear_reset - used by client driver to clear reset status
These functionalities may sometimes be achieved by using existing api
like deassert. But in some scenarios, steps to achieve reset requires
clearing reset, deassert reset, enabling clock to module and then
checking reset status. Here enabling clock module is coming in between
reset procedure, hence enhance framework with additional api's.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/reset/core.c | 32
include/linux/reset-controller.h | 2 ++
include/linux/reset.h| 2 ++
3 files changed, 36 insertions(+)
diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index d1b6089..ba12171 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -127,6 +127,38 @@ int reset_control_deassert(struct reset_control *rstc)
EXPORT_SYMBOL_GPL(reset_control_deassert);
/**
+ * reset_control_is_reset - check reset status
+ * @rstc: reset controller
+ *
+ * Returns a boolean or negative error code
+ *
+ */
+int reset_control_is_reset(struct reset_control *rstc)
+{
+ if (rstc-rcdev-ops-is_reset)
+ return rstc-rcdev-ops-is_reset(rstc-rcdev, rstc-id);
+
+ return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(reset_control_is_reset);
+
+/**
+ * reset_control_clear_reset - clear the reset
+ * @rstc: reset controller
+ *
+ * Returns zero on success or negative error code
+ *
+ */
+int reset_control_clear_reset(struct reset_control *rstc)
+{
+ if (rstc-rcdev-ops-clear_reset)
+ return rstc-rcdev-ops-clear_reset(rstc-rcdev, rstc-id);
+
+ return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(reset_control_clear_reset);
+
+/**
* reset_control_get - Lookup and obtain a reference to a reset controller.
* @dev: device to be reset by the controller
* @id: reset line name
diff --git a/include/linux/reset-controller.h b/include/linux/reset-controller.h
index 2f61311..c9bbadb 100644
--- a/include/linux/reset-controller.h
+++ b/include/linux/reset-controller.h
@@ -17,6 +17,8 @@ struct reset_control_ops {
int (*reset)(struct reset_controller_dev *rcdev, unsigned long id);
int (*assert)(struct reset_controller_dev *rcdev, unsigned long id);
int (*deassert)(struct reset_controller_dev *rcdev, unsigned long id);
+ int (*is_reset)(struct reset_controller_dev *rcdev, unsigned long id);
+ int (*clear_reset)(struct reset_controller_dev *rcdev, unsigned long i);
};
struct module;
diff --git a/include/linux/reset.h b/include/linux/reset.h
index 6082247..da59f9f 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -7,6 +7,8 @@ struct reset_control;
int reset_control_reset(struct reset_control *rstc);
int reset_control_assert(struct reset_control *rstc);
int reset_control_deassert(struct reset_control *rstc);
+int reset_control_is_reset(struct reset_control *rstc);
+int reset_control_clear_reset(struct reset_control *rstc);
struct reset_control *reset_control_get(struct device *dev, const char *id);
void reset_control_put(struct reset_control *rstc);
--
1.8.3.4
--
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 RFC 2/6] doc: dt: binding: omap: am43x/am335x prcm reset
prcm reset binding for AM43x/AM335x SoC's.
This was started with an attempt to add reset binding without a clear
idea on the device node where binding should appear. So a new node
with compatible am4372-reset to represent reset managment in prcm
was added. But finally ended up with a node to represent prcm (with
compatible am4372-prcm) which was felt to be the natural one.
Signed-off-by: Afzal Mohammed af...@ti.com
---
Documentation/devicetree/bindings/arm/omap/prcm.txt | 13 +
1 file changed, 13 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/prcm.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/prcm.txt
b/Documentation/devicetree/bindings/arm/omap/prcm.txt
new file mode 100644
index 000..ad25abc
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/prcm.txt
@@ -0,0 +1,13 @@
+TI Power Reset Clock Manager (PRCM)
+
+Properties:
+- compatible: ti,am4372-prcm for prcm in am43x SoC's
+ ti,am3352-prcm for prcm in am335x SoC's
+- #reset-cells: 1 (refer generic reset bindings for details)
+
+example:
+ prcm: prcm@44df {
+ compatible = ti,am4372-prcm;
+ reg = 0x44df 0xa000;
+ #reset-cells = 1;
+ };
--
1.8.3.4
--
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 RFC 3/6] reset: am43x/am335x support
Driver to handle reset block in prcm of AM43x, AM335x SoC's. There are
three reset's that can be handled by this reset driver - gfx, m3 and
pruss. Of this only gfx has been handled here, adding support for the
remaining only require adding array entries with details of pruss and
m3.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/reset/Kconfig | 14
drivers/reset/Makefile | 1 +
drivers/reset/amx3_reset.c | 157 +
3 files changed, 172 insertions(+)
create mode 100644 drivers/reset/amx3_reset.c
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index c9d04f7..2af81b9 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -11,3 +11,17 @@ menuconfig RESET_CONTROLLER
via GPIOs or SoC-internal reset controller modules.
If unsure, say no.
+
+if RESET_CONTROLLER
+
+config RESET_AMX3
+ bool AMx3 reset controller
+ help
+ Reset controller support for AM43x/AM335x SoC's
+
+ Reset controller found in TI's AM series of SoC's like
+ AM335x and AM43x
+
+ If unsure, say no.
+
+endif
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 1e2d83f..b8c1afe 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_RESET_CONTROLLER) += core.o
+obj-$(CONFIG_RESET_AMX3) += amx3_reset.o
diff --git a/drivers/reset/amx3_reset.c b/drivers/reset/amx3_reset.c
new file mode 100644
index 000..4e476a5
--- /dev/null
+++ b/drivers/reset/amx3_reset.c
@@ -0,0 +1,157 @@
+/*
+ * PRCM reset driver for AM335x AM43x SoC's
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include linux/device.h
+#include linux/err.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/reset.h
+#include linux/reset-controller.h
+#include linux/platform_device.h
+#include linux/io.h
+
+#define DRIVER_NAME amx3_reset
+
+struct amx3_reset_reg_data {
+ u32 rstctrl_offs;
+ u32 rstst_offs;
+ u8 rstctrl_bit;
+ u8 rstst_bit;
+};
+
+struct amx3_reset_data {
+ struct amx3_reset_reg_data *reg_data;
+ u8 nr_resets;
+};
+
+static void __iomem *reg_base;
+static const struct amx3_reset_data *amx3_reset_data;
+
+static struct amx3_reset_reg_data am335x_reset_reg_data[] = {
+ {
+ .rstctrl_offs = 0x1104,
+ .rstst_offs = 0x1114,
+ .rstctrl_bit= 0,
+ .rstst_bit = 0,
+ },
+};
+
+static struct amx3_reset_data am335x_reset_data = {
+ .reg_data = am335x_reset_reg_data,
+ .nr_resets = ARRAY_SIZE(am335x_reset_reg_data),
+};
+
+static struct amx3_reset_reg_data am43x_reset_reg_data[] = {
+ {
+ .rstctrl_offs = 0x410,
+ .rstst_offs = 0x414,
+ .rstctrl_bit= 0,
+ .rstst_bit = 0,
+ },
+};
+
+static struct amx3_reset_data am43x_reset_data = {
+ .reg_data = am43x_reset_reg_data,
+ .nr_resets = ARRAY_SIZE(am43x_reset_reg_data),
+};
+
+static int amx3_reset_clear_reset(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ void __iomem *reg = amx3_reset_data-reg_data[id].rstst_offs + reg_base;
+ u8 bit = amx3_reset_data-reg_data[id].rstst_bit;
+ u32 val = readl(reg);
+
+ val = ~(1 bit);
+ val |= 1 bit;
+ writel(val, reg);
+ return 0;
+}
+
+static int amx3_reset_is_reset(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ void __iomem *reg = amx3_reset_data-reg_data[id].rstst_offs + reg_base;
+ u8 bit = amx3_reset_data-reg_data[id].rstst_bit;
+ u32 val = readl(reg);
+
+ val = (1 bit);
+ return !!val;
+}
+
+static int amx3_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ void __iomem *reg = amx3_reset_data-reg_data[id].rstctrl_offs +
+ reg_base;
+ u8 bit = amx3_reset_data-reg_data[id].rstctrl_bit;
+ u32 val = readl(reg);
+
+ val = ~(1 bit);
+ writel(val, reg);
+ return 0;
+}
+
+static struct reset_control_ops amx3_reset_ops = {
+ .deassert = amx3_reset_deassert,
+ .is_reset = amx3_reset_is_reset,
+ .clear_reset = amx3_reset_clear_reset,
+};
+
+static struct reset_controller_dev amx3_reset_controller = {
+ .ops = amx3_reset_ops,
+};
+
+static const struct of_device_id amx3_reset_of_match[] = {
+ { .compatible = ti,am3352-prcm, .data = am335x_reset_data,},
+ { .compatible = ti,am4372-prcm, .data = am43x_reset_data,},
+ {},
+};
+
+static int
[PATCH RFC 4/6] ARM: OMAP2+: AM43x/AM335x: have reset controller
AM43x, AM335x have reset block as part of prcm, let reset driver be usable with these SoC's. Signed-off-by: Afzal Mohammed af...@ti.com --- arch/arm/mach-omap2/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 3eed000..fa28d1d 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -72,6 +72,7 @@ config SOC_AM33XX select CPU_V7 select MULTI_IRQ_HANDLER select COMMON_CLK + select ARCH_HAS_RESET_CONTROLLER config SOC_AM43XX bool TI AM43x @@ -82,6 +83,7 @@ config SOC_AM43XX select ARM_GIC select COMMON_CLK select MACH_OMAP_GENERIC + select ARCH_HAS_RESET_CONTROLLER config ARCH_OMAP2PLUS bool -- 1.8.3.4 -- 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 RFC 6/6] ARM: dts: AM4372: prcm node (for reset)
Add AM4372 prcm node with reset binding.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 5a68fde..d0d11b3 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -411,6 +411,12 @@
ti,hwmods = epwmss5;
status = disabled;
};
+
+ prcm: prcm@44df {
+ compatible = ti,am4372-prcm;
+ reg = 0x44df 0xa000;
+ #reset-cells = 1;
+ };
};
clocks {
--
1.8.3.4
--
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 RFC 5/6] ARM: dts: AM335x: prcm node (for reset)
Add AM335x prcm node with reset binding.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 4701e3c..c2ccf94 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -530,6 +530,12 @@
#size-cells = 1;
status = disabled;
};
+
+ prcm: prcm@44e0 {
+ compatible = ti,am3352-prcm;
+ reg = 0x44e0 0x1300;
+ #reset-cells = 1;
+ };
};
clocks {
--
1.8.3.4
--
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: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat
On (09/02/13 16:13), Frederic Weisbecker wrote:
On Mon, Sep 02, 2013 at 03:07:45PM +0200, Frederic Weisbecker wrote:
Hope this may help.
I've added a silly check to make sure that `stime rtime'
@@ -579,6 +582,10 @@ static void cputime_adjust(struct task_cputime
*curr,
if (total) {
stime = scale_stime((__force u64)stime,
(__force u64)rtime, (__force
u64)total);
+ if (stime rtime) {
+ printk(KERN_ERR Ooops: stime:%llu
rtime:%llu\n, stime, rtime);
+ WARN_ON(1);
+ }
utime = rtime - stime;
} else {
stime = rtime;
[snip]
Thanks a lot Sergey for testing this further!
Interesting results, so rtime is always one or two units off stime after
scaling.
Stanislaw made the scaling code with Linus and he has a better idea on
the math guts
here.
I don't think this is scale issue, but rather at scale_stime() input
stime is already bigger then rtime. Sergey, could you verify that
by adding check before scale_stime() ?
Note that having stime rtime should be fine to handle. This can happen for
example if the task runs on tiny timeslices but is unlucky enough that all
these
timeslices are interrupted by the tick.
even is stime rtime, scale_stime() fixes it:
if (stime rtime)
swap(rtime, stime);
-ss
--
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 0/7] fs: Introduce new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate
From: Namjae Jeon namjae.j...@samsung.com This patch series is in response of the following post: http://lwn.net/Articles/556136/ ext4: introduce two new ioctls Dave chinner suggested that truncate_block_range (which was one of the ioctls name) should be an fallocate operation and not any fs specific ioctl, hence we add this functionality to fallocate. This patch series introduces new flag FALLOC_FL_COLLAPSE_RANGE for fallocate and implements it for XFS and Ext4. The semantics of this flag are following: 1) It collapses the range lying between offset and length by removing any data blocks which are present in this range and than updates all the logical offsets of extents beyond offset + len to nullify the hole created by removing blocks. In short, it does not leave a hole. 2) It should be used exclusively. No other fallocate flag in combination. 3) Offset and length supplied to fallocate should be fs block size aligned. This new functionality of collapsing range could be used by media editing tools which does non linear editing to quickly purge and edit parts of a media file. This will immensely improve the performance of these operations. The limitation of fs block size aligned offsets can be easily handled by media codecs which are encapsulated in a conatiner as they have to just change the offset to next keyframe value to match the proper alignment. Change log v2: Fix review points from Dave Chinner. - merge adjacent extents - fix journal log usage. - change reasonable function name. - update xfsio, xfstest, manpage - etc. Namjae Jeon (7): fs: add new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate xfs: add new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate ext4: add new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate xfsprogs: xfsio: add support FALLOC_FL_COLLAPSE_RANGE for fallocate xfstest: Add test case to check various corner cases for collapsing range xfstest: Add test case to test multiple collapse range call manpage: update FALLOC_FL_COLLAPSE_RANGE flag in fallocate -- 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 v2 2/7] xfs: add support FALLOC_FL_COLLAPSE_RANGE for fallocate
From: Namjae Jeon namjae.j...@samsung.com
Add support FALLOC_FL_COLLAPSE_RANGE for fallocate.
Signed-off-by: Namjae Jeon namjae.j...@samsung.com
Signed-off-by: Ashish Sangwan a.sang...@samsung.com
---
fs/xfs/xfs_bmap.c | 174
fs/xfs/xfs_bmap.h |3 +
fs/xfs/xfs_bmap_util.c | 96 ++
fs/xfs/xfs_bmap_util.h |2 +
fs/xfs/xfs_file.c | 20 --
fs/xfs/xfs_fs.h|6 ++
6 files changed, 296 insertions(+), 5 deletions(-)
diff --git a/fs/xfs/xfs_bmap.c b/fs/xfs/xfs_bmap.c
index 92b8309..c12358e 100644
--- a/fs/xfs/xfs_bmap.c
+++ b/fs/xfs/xfs_bmap.c
@@ -5356,3 +5356,177 @@ error0:
}
return error;
}
+
+/*
+ * Update extents by shifting them downwards into a hole.
+ * At max count number of extents will be shifted and *current_ext
+ * is the extent number which is currently being shifted.
+ * This function will return error if the hole is not present
+ * while shifting extents. On success, 0 is returned.
+ */
+int
+xfs_bmap_shift_extents(
+ struct xfs_trans*tp,
+ struct xfs_inode*ip,
+ int *done,
+ xfs_fileoff_t start_fsb,
+ xfs_fileoff_t shift,
+ xfs_extnum_t*current_ext,
+ xfs_fsblock_t *firstblock,
+ struct xfs_bmap_free*flist,
+ int count)
+{
+ struct xfs_btree_cur*cur;
+ struct xfs_bmbt_rec_host*gotp;
+ struct xfs_bmbt_irecleft;
+ struct xfs_mount*mp = ip-i_mount;
+ struct xfs_ifork*ifp;
+ xfs_extnum_tnexts = 0;
+ xfs_fileoff_t startoff;
+ int error = 0;
+ int i;
+ int whichfork = XFS_DATA_FORK;
+ int state;
+ int logflags;
+ xfs_filblks_t blockcount = 0;
+
+ if (unlikely(XFS_TEST_ERROR(
+ (XFS_IFORK_FORMAT(ip, whichfork) != XFS_DINODE_FMT_EXTENTS
+XFS_IFORK_FORMAT(ip, whichfork) != XFS_DINODE_FMT_BTREE),
+mp, XFS_ERRTAG_BMAPIFORMAT, XFS_RANDOM_BMAPIFORMAT))) {
+ XFS_ERROR_REPORT(xfs_bmap_shift_extents,
+XFS_ERRLEVEL_LOW, mp);
+ return XFS_ERROR(EFSCORRUPTED);
+ }
+
+ if (XFS_FORCED_SHUTDOWN(mp))
+ return XFS_ERROR(EIO);
+
+ ifp = XFS_IFORK_PTR(ip, whichfork);
+
+ if (!(ifp-if_flags XFS_IFEXTENTS)) {
+ /* Read in all the extents */
+ error = xfs_iread_extents(tp, ip, whichfork);
+ if (error)
+ return error;
+ }
+
+ if (!*current_ext) {
+ gotp = xfs_iext_bno_to_ext(ifp, start_fsb, current_ext);
+ /*
+* gotp can be null in 2 cases: 1) if there are no extents
+* or 2) start_fsb lies in a hole beyond which there are
+* no extents. Either way, we are done.
+*/
+ if (!gotp) {
+ *done = 1;
+ return 0;
+ }
+ }
+
+ /* We are going to change core inode */
+ logflags = XFS_ILOG_CORE;
+
+ if (ifp-if_flags XFS_IFBROOT) {
+ cur = xfs_bmbt_init_cursor(mp, tp, ip, whichfork);
+ cur-bc_private.b.firstblock = *firstblock;
+ cur-bc_private.b.flist = flist;
+ cur-bc_private.b.flags = 0;
+ }
+ else {
+ cur = NULL;
+ logflags |= XFS_ILOG_DEXT;
+ }
+
+ while (nexts++ count
+ *current_ext XFS_IFORK_NEXTENTS(ip, whichfork)) {
+ state = 0;
+
+ gotp = xfs_iext_get_ext(ifp, *current_ext);
+ startoff = xfs_bmbt_get_startoff(gotp);
+ startoff -= shift;
+
+ /*
+* Before shifting extent into hole, make sure that the hole
+* is large enough to accomodate the shift.
+*/
+ if (*current_ext) {
+ state |= BMAP_LEFT_VALID;
+ xfs_bmbt_get_all(xfs_iext_get_ext(ifp,
+ *current_ext - 1), left);
+
+ if (isnullstartblock(left.br_startblock))
+ state |= BMAP_LEFT_DELAY;
+
+ if (startoff left.br_startoff + left.br_blockcount)
+ error = XFS_ERROR(EFSCORRUPTED);
+
+ } else if (startoff xfs_bmbt_get_startoff(gotp))
+ /* Hole is at the start but not large enough */
+ error = XFS_ERROR(EFSCORRUPTED);
+
+ if (error)
+
[PATCH v2 1/7] fs: add new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate
From: Namjae Jeon namjae.j...@samsung.com
Add new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate.
updated detailed semantics in comments.
Signed-off-by: Namjae Jeon namjae.j...@samsung.com
Signed-off-by: Ashish Sangwan a.sang...@samsung.com
---
fs/open.c | 24 +---
include/uapi/linux/falloc.h | 17 +
2 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/fs/open.c b/fs/open.c
index 7931f76..85d243a 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -225,12 +225,14 @@ int do_fallocate(struct file *file, int mode, loff_t
offset, loff_t len)
{
struct inode *inode = file_inode(file);
long ret;
+ unsigned blksize_mask = (1 inode-i_blkbits) - 1;
if (offset 0 || len = 0)
return -EINVAL;
/* Return error if mode is not supported */
- if (mode ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
+ if (mode ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE |
+FALLOC_FL_COLLAPSE_RANGE))
return -EOPNOTSUPP;
/* Punch hole must have keep size set */
@@ -241,8 +243,12 @@ int do_fallocate(struct file *file, int mode, loff_t
offset, loff_t len)
if (!(file-f_mode FMODE_WRITE))
return -EBADF;
- /* It's not possible punch hole on append only file */
- if (mode FALLOC_FL_PUNCH_HOLE IS_APPEND(inode))
+ /*
+* It's not possible to punch hole or perform collapse range
+* on append only file
+*/
+ if (mode (FALLOC_FL_PUNCH_HOLE | FALLOC_FL_COLLAPSE_RANGE)
+IS_APPEND(inode))
return -EPERM;
if (IS_IMMUTABLE(inode))
@@ -270,6 +276,18 @@ int do_fallocate(struct file *file, int mode, loff_t
offset, loff_t len)
if (((offset + len) inode-i_sb-s_maxbytes) || ((offset + len) 0))
return -EFBIG;
+ /*
+* Collapse range works only on fs block size aligned offsets.
+* Check if collapse range is contained within (aligned)i_size.
+* Collapse range can only be used exclusively.
+*/
+ if ((mode FALLOC_FL_COLLAPSE_RANGE)
+ (offset blksize_mask || len blksize_mask ||
+mode ~FALLOC_FL_COLLAPSE_RANGE ||
+(offset + len
+ round_up(i_size_read(inode), (blksize_mask + 1)
+ return -EINVAL;
+
if (!file-f_op-fallocate)
return -EOPNOTSUPP;
diff --git a/include/uapi/linux/falloc.h b/include/uapi/linux/falloc.h
index 990c4cc..9614b72 100644
--- a/include/uapi/linux/falloc.h
+++ b/include/uapi/linux/falloc.h
@@ -4,6 +4,23 @@
#define FALLOC_FL_KEEP_SIZE0x01 /* default is extend size */
#define FALLOC_FL_PUNCH_HOLE 0x02 /* de-allocates range */
#define FALLOC_FL_NO_HIDE_STALE0x04 /* reserved codepoint */
+/*
+ * FALLOC_FL_COLLAPSE_RANGE:
+ * This flag works in 2 steps.
+ * Firstly, it deallocates any data blocks present between [offset, offset+len)
+ * This step is same as punch hole and leaves a hole in the place from where
+ * the blocks are removed.
+ * Next, it eliminates the hole created by moving data blocks into it.
+ * For extent based file systems, we achieve this functionality simply by
+ * updating the starting logical offset of each extent which appears beyond
+ * the hole. As this flag works on blocks of filesystem, the offset and len
+ * provided to fallocate should be aligned with block size of filesystem.
+ * The semantics of this flag are:
+ * 1) It should be used exclusively. No other fallocate flag in combination.
+ * 2) Offset and len supplied to fallocate should be aligned with block size.
+ * 3) (offset + len) could not be greater than file size.
+ */
+#define FALLOC_FL_COLLAPSE_RANGE 0x08 /* it does not leave a hole */
#endif /* _UAPI_FALLOC_H_ */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/7] ext4: add support FALLOC_FL_COLLAPSE_RANGE for fallocate
From: Namjae Jeon namjae.j...@samsung.com
Add support FALLOC_FL_COLLAPSE_RANGE for fallocate.
Signed-off-by: Namjae Jeon namjae.j...@samsung.com
Signed-off-by: Ashish Sangwan a.sang...@samsung.com
---
fs/ext4/ext4.h |3 +
fs/ext4/extents.c | 286 ++-
fs/ext4/move_extent.c |2 +-
include/trace/events/ext4.h | 25
4 files changed, 314 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index f3c43fc..a13e0f4 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -2737,6 +2737,7 @@ extern int ext4_find_delalloc_cluster(struct inode
*inode, ext4_lblk_t lblk);
extern int ext4_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
__u64 start, __u64 len);
extern int ext4_ext_precache(struct inode *inode);
+extern int ext4_collapse_range(struct inode *inode, loff_t offset, loff_t len);
/* move_extent.c */
extern void ext4_double_down_write_data_sem(struct inode *first,
@@ -2748,6 +2749,8 @@ void ext4_inode_double_unlock(struct inode *inode1,
struct inode *inode2);
extern int ext4_move_extents(struct file *o_filp, struct file *d_filp,
__u64 start_orig, __u64 start_donor,
__u64 len, __u64 *moved_len);
+extern int mext_next_extent(struct inode *inode, struct ext4_ext_path *path,
+ struct ext4_extent **extent);
/* page-io.c */
extern int __init ext4_init_pageio(void);
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 54d52af..baf1faf 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4580,12 +4580,16 @@ long ext4_fallocate(struct file *file, int mode, loff_t
offset, loff_t len)
unsigned int credits, blkbits = inode-i_blkbits;
/* Return error if mode is not supported */
- if (mode ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
+ if (mode ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE |
+FALLOC_FL_COLLAPSE_RANGE))
return -EOPNOTSUPP;
if (mode FALLOC_FL_PUNCH_HOLE)
return ext4_punch_hole(inode, offset, len);
+ if (mode FALLOC_FL_COLLAPSE_RANGE)
+ return ext4_collapse_range(inode, offset, len);
+
ret = ext4_convert_inline_data(inode);
if (ret)
return ret;
@@ -4884,3 +4888,283 @@ int ext4_fiemap(struct inode *inode, struct
fiemap_extent_info *fieinfo,
ext4_es_lru_add(inode);
return error;
}
+
+/*
+ * ext4_access_path:
+ * Function to access the path buffer for marking it dirty.
+ * It also checks if there are sufficient credits left in the journal handle
+ * to update path.
+ */
+static int
+ext4_access_path(handle_t *handle, struct inode *inode,
+ struct ext4_ext_path *path)
+{
+ int credits, err;
+
+ /*
+* Check if need to extend journal credits
+* 3 for leaf, sb, and inode plus 2 (bmap and group
+* descriptor) for each block group; assume two block
+* groups
+*/
+ if (handle-h_buffer_credits 7) {
+ credits = ext4_writepage_trans_blocks(inode);
+ err = ext4_ext_truncate_extend_restart(handle, inode, credits);
+ /* EAGAIN is success */
+ if (err err != -EAGAIN)
+ return err;
+ }
+
+ err = ext4_ext_get_access(handle, inode, path);
+ return err;
+}
+
+/*
+ * ext4_ext_shift_path_extents:
+ * Shift the extents of a path structure lying between path[depth].p_ext
+ * and EXT_LAST_EXTENT(path[depth].p_hdr) downwards, by subtracting shift
+ * from starting block for each extent.
+ */
+static int
+ext4_ext_shift_path_extents(struct ext4_ext_path *path, ext4_lblk_t shift,
+ struct inode *inode, handle_t *handle,
+ ext4_lblk_t *start)
+{
+ int depth, err = 0;
+ struct ext4_extent *ex_start, *ex_last;
+ bool update = 0;
+ depth = path-p_depth;
+
+ while (depth = 0) {
+ if (depth == path-p_depth) {
+ ex_start = path[depth].p_ext;
+ if (!ex_start)
+ return -EIO;
+
+ ex_last = EXT_LAST_EXTENT(path[depth].p_hdr);
+ if (!ex_last)
+ return -EIO;
+
+ err = ext4_access_path(handle, inode, path + depth);
+ if (err)
+ goto out;
+
+ if (ex_start == EXT_FIRST_EXTENT(path[depth].p_hdr))
+ update = 1;
+
+ *start = ex_last-ee_block +
+ ext4_ext_get_actual_len(ex_last);
+
+ while (ex_start = ex_last) {
+ ex_start-ee_block -= shift;
+ ext4_ext_try_to_merge(handle, inode,
+
[PATCH v4 4/7] xfsprogs: xfsio: add support FALLOC_FL_COLLAPSE_RANGE for fallocate
From: Namjae Jeon namjae.j...@samsung.com
Add support FALLOC_FL_COLLAPSE_RANGE for fallocate.
Signed-off-by: Namjae Jeon namjae.j...@samsung.com
Signed-off-by: Ashish Sangwan a.sang...@samsung.com
---
io/prealloc.c | 39 ++-
man/man8/xfs_io.8 |6 ++
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/io/prealloc.c b/io/prealloc.c
index 8380646..e7ff940 100644
--- a/io/prealloc.c
+++ b/io/prealloc.c
@@ -29,6 +29,10 @@
#define FALLOC_FL_PUNCH_HOLE 0x02
#endif
+#ifndef FALLOC_FL_COLLAPSE_RANGE
+#define FALLOC_FL_COLLAPSE_RANGE 0x08
+#endif
+
static cmdinfo_t allocsp_cmd;
static cmdinfo_t freesp_cmd;
static cmdinfo_t resvsp_cmd;
@@ -37,6 +41,7 @@ static cmdinfo_t zero_cmd;
#if defined(HAVE_FALLOCATE)
static cmdinfo_t falloc_cmd;
static cmdinfo_t fpunch_cmd;
+static cmdinfo_t fcollapse_cmd;
#endif
static int
@@ -159,8 +164,11 @@ fallocate_f(
int mode = 0;
int c;
- while ((c = getopt(argc, argv, kp)) != EOF) {
+ while ((c = getopt(argc, argv, ckp)) != EOF) {
switch (c) {
+ case 'c':
+ mode = FALLOC_FL_COLLAPSE_RANGE;
+ break;
case 'k':
mode = FALLOC_FL_KEEP_SIZE;
break;
@@ -203,6 +211,25 @@ fpunch_f(
}
return 0;
}
+
+static int
+fcollapse_f(
+ int argc,
+ char**argv)
+{
+ xfs_flock64_t segment;
+ int mode = FALLOC_FL_COLLAPSE_RANGE;
+
+ if(!offset_length(argv[1], argv[2], segment))
+ return 0;
+
+ if (fallocate(file-fd, mode,
+ segment.l_start, segment.l_len)) {
+ perror(fallocate);
+ return 0;
+ }
+ return 0;
+}
#endif /* HAVE_FALLOCATE */
void
@@ -277,5 +304,15 @@ prealloc_init(void)
fpunch_cmd.oneline =
_(de-allocates space assocated with part of a file via
fallocate);
add_command(fpunch_cmd);
+
+ fcollapse_cmd.name = fcollapse;
+ fcollapse_cmd.cfunc = fcollapse_f;
+ fcollapse_cmd.argmin = 2;
+ fcollapse_cmd.argmax = 2;
+ fcollapse_cmd.flags = CMD_NOMAP_OK | CMD_FOREIGN_OK;
+ fcollapse_cmd.args = _(off len);
+ fcollapse_cmd.oneline =
+ _(de-allocates space and nullify the hole by shifting extents
into it);
+ add_command(fcollapse_cmd);
#endif /* HAVE_FALLOCATE */
}
diff --git a/man/man8/xfs_io.8 b/man/man8/xfs_io.8
index 767b50e..9543b20 100644
--- a/man/man8/xfs_io.8
+++ b/man/man8/xfs_io.8
@@ -380,6 +380,12 @@ will set the FALLOC_FL_KEEP_SIZE flag as described in
.PD
.RE
.TP
+.BI fcollapse offset length
+Call fallocate with FALLOC_FL_COLLAPSE_RANGE flag as described in the
+.BR fallocate (2)
+manual page to de-allocates blocks and eliminates the hole created in this
process
+by shifting data blocks into the hole.
+.TP
.BI fpunch offset length
Punches (de-allocates) blocks in the file by calling fallocate with
the FALLOC_FL_PUNCH_HOLE flag as described in the
--
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 v2 5/7] xfstest: Add test case to check various corner cases for collapsing range
From: Namjae Jeon namjae.j...@samsung.com
This patch checks various corner cases for collapsing a range.
This patch is based on generic/255 test case which checks various corner
cases for punch hole.
Signed-off-by: Namjae Jeon namjae.j...@samsung.com
Signed-off-by: Ashish Sangwan a.sang...@samsung.com
---
common/collapse | 264 ++
common/rc| 14 +++
tests/shared/316 | 70 +
tests/shared/316.out | 221 ++
tests/shared/group |2 +-
5 files changed, 570 insertions(+), 1 deletion(-)
create mode 100644 common/collapse
create mode 100644 tests/shared/316
create mode 100644 tests/shared/316.out
diff --git a/common/collapse b/common/collapse
new file mode 100644
index 000..dd3be5e
--- /dev/null
+++ b/common/collapse
@@ -0,0 +1,264 @@
+##/bin/bash
+#
+# Copyright (c) 2013 Samsung Electronics. All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+#
+# Test procedure for checking collapse range feature
+
+# Test different corner cases for collapsing a range:
+#
+# 1. into a hole
+# 2. into allocated space
+# 3. into unwritten space
+# 4. hole - data
+# 5. hole - unwritten
+# 6. data - hole
+# 7. data - unwritten
+# 8. unwritten - hole
+# 9. unwritten - data
+# 10. hole - data - hole
+# 11. data - hole - data
+# 12. unwritten - data - unwritten
+# 13. data - unwritten - data
+# 14. data - hole @ EOF
+# 15. data - hole @ 0
+# 16. data - cache cold -hole
+#
+# Test file is removed, created and sync'd between tests.
+#
+# Use -k flag to keep the file between tests. This will
+# test the handling of pre-existing holes.
+#
+# Use the -d flag to not sync the file between tests.
+# This will test the handling of delayed extents
+#
+_test_generic_collapse()
+{
+
+ remove_testfile=1
+ sync_cmd=-c fsync
+ OPTIND=1
+ while getopts 'dk' OPTION
+ do
+ case $OPTION in
+ k) remove_testfile=
+ ;;
+ d) sync_cmd=
+ ;;
+ ?) echo Invalid flag
+ exit 1
+ ;;
+ esac
+ done
+ shift $(($OPTIND - 1))
+
+ alloc_cmd=$1
+ collapse_cmd=$2
+ punch_cmd=$3
+ map_cmd=$4
+ filter_cmd=$5
+ testfile=$6
+
+ echo 1. into a hole
+ if [ $remove_testfile ]; then
+ rm -f $testfile
+ fi
+ $XFS_IO_PROG -f -c truncate 80k \
+ -c $collapse_cmd 16k 32k \
+ -c $map_cmd -v $testfile | $filter_cmd
+ [ $? -ne 0 ] die_now
+ _md5_checksum $testfile
+
+ echo 2. into allocated space
+ if [ $remove_testfile ]; then
+ rm -f $testfile
+ fi
+ $XFS_IO_PROG -f -c truncate 80k \
+ -c pwrite 0 80k $sync_cmd \
+ -c $collapse_cmd 16k 32k \
+ -c $map_cmd -v $testfile | $filter_cmd
+ [ $? -ne 0 ] die_now
+ _md5_checksum $testfile
+
+ echo 3. into unwritten space
+ if [ $remove_testfile ]; then
+ rm -f $testfile
+ fi
+ $XFS_IO_PROG -f -c truncate 80k \
+ -c $alloc_cmd 0 80k \
+ -c $collapse_cmd 16k 32k \
+ -c $map_cmd -v $testfile | $filter_cmd
+ [ $? -ne 0 ] die_now
+ _md5_checksum $testfile
+
+ echo 4. hole - data
+ if [ $remove_testfile ]; then
+ rm -f $testfile
+ fi
+ $XFS_IO_PROG -f -c truncate 80k \
+ -c pwrite 32k 32k $sync_cmd \
+ -c $collapse_cmd 16k 32k \
+ -c $map_cmd -v $testfile | $filter_cmd
+ [ $? -ne 0 ] die_now
+ _md5_checksum $testfile
+
+ echo 5. hole - unwritten
+ if [ $remove_testfile ]; then
+ rm -f $testfile
+ fi
+ $XFS_IO_PROG -f -c truncate 80k \
+ -c $alloc_cmd 32k 32k \
+ -c $collapse_cmd 16k 32k \
+ -c $map_cmd -v $testfile | $filter_cmd
+ [ $? -ne 0 ] die_now
+ _md5_checksum $testfile
+
+ echo 6. data - hole
+ if [ $remove_testfile ]; then
+ rm -f $testfile
+ fi
+ $XFS_IO_PROG -f -c truncate 80k \
+ -c pwrite 0 32k
[PATCH v2 7/7] manpage: update FALLOC_FL_COLLAPSE_RANGE flag in fallocate
From: Namjae Jeon namjae.j...@samsung.com Update FALLOC_FL_COLLAPSE_RANGE flag in fallocate. Signed-off-by: Namjae Jeon namjae.j...@samsung.com Signed-off-by: Ashish Sangwan a.sang...@samsung.com --- man2/fallocate.2 | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/man2/fallocate.2 b/man2/fallocate.2 index f5c395d..b042c59 100644 --- a/man2/fallocate.2 +++ b/man2/fallocate.2 @@ -7,6 +7,7 @@ .\ .\ 2011-09-19: Added FALLOC_FL_PUNCH_HOLE .\ 2011-09-19: Substantial restructuring of the page +.\ 2013-09-01: Added FALLOC_FL_COLLAPSE_RANGE .\ .TH FALLOCATE 2 2013-06-10 Linux Linux Programmer's Manual .SH NAME @@ -109,6 +110,19 @@ does not change. Not all filesystems support .BR FALLOC_FL_PUNCH_HOLE ; if a filesystem doesn't support the operation, an error is returned. +.SS Collapsing file space +Specifiying the +.BR FALLOC_FL_COLLAPSE_RANGE +flag in +.I mode +collpse space in the byte range starting at +.I offset +and continuing for +.I len +bytes, where the offset and len are aligned with block size of filesystem. +Within the specified range, it first de-allocates blocks and eliminates +the hole created in this process by shifting data blocks into the hole. + .SH RETURN VALUE On success, .BR fallocate () @@ -139,7 +153,8 @@ was less than 0, or .\ See Re: [PATCH] fallocate.2: add FALLOC_FL_PUNCH_HOLE flag definition .\ 21 Sep 2012 .\ http://thread.gmane.org/gmane.linux.file-systems/48331/focus=1193526 -was less than or equal to 0. +was less than or equal to 0 or in case of FALLOC_FL_COLLAPSE_RANGE +offset and len are not aligned with file system's block size. .TP .B EIO An I/O error occurred while reading from or writing to a filesystem. -- 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 v2 6/7] xfstest: Add test case to test multiple collapse range call
From: Namjae Jeon namjae.j...@samsung.com
We execute collapse range multiple times on same file.
Each collapse range call collapses a single alternate block.
After the test execution, file will be left with 80 blocks and
as much number of extents.
We also check for file system consistency after the completion.
Signed-off-by: Namjae Jeon namjae.j...@samsung.com
Signed-off-by: Ashish Sangwan a.sang...@samsung.com
---
tests/shared/317 | 96 ++
tests/shared/317.out | 85
tests/shared/group |1 +
3 files changed, 182 insertions(+)
create mode 100644 tests/shared/317
create mode 100644 tests/shared/317.out
diff --git a/tests/shared/317 b/tests/shared/317
new file mode 100644
index 000..1d7c384
--- /dev/null
+++ b/tests/shared/317
@@ -0,0 +1,96 @@
+#! /bin/bash
+# FS QA Test No. 317
+#
+# Test multiple fallocate collapse range calls
+#
+#---
+# Copyright (c) 2013 Samsung Electronics. All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+#
+#---
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo QA output created by $seq
+
+here=`pwd`
+tmp=/tmp/$$
+status=1 # failure is the default!
+trap rm -f $tmp.*; exit \$status 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common/rc
+. ./common/filter
+
+# real QA test starts here
+_supported_fs xfs ext4
+_supported_os Linux
+
+_require_scratch
+_require_xfs_io_fiemap
+_require_xfs_io_falloc_collapse
+_do_die_on_error=y
+test=$SCRATCH_MNT/test
+testfile=$SCRATCH_MNT/317.$$
+BSIZE=4096
+BLOCKS=10240
+
+# Filters fiemap output
+_filter_fiemap()
+{
+ awk --posix '
+ $3 ~ /hole/ {
+ print $1, $2, $3;
+ next;
+ }
+ $5 ~ /0x[[:xdigit:]]+/ {
+ print $1, $2, extent;
+ }'
+}
+
+case $FSTYP in
+ ext4)
+ export MKFS_OPTIONS=-F -b $BSIZE
+ ;;
+ xfs)
+ export MKFS_OPTIONS=-f -b size=$BSIZE
+ ;;
+esac
+
+# make filesystem on scratch with 4KB blocksize
+_do 'make filesystem on $SCRATCH_DEV' '_scratch_mkfs'
+_do 'mount filesytem' '_scratch_mount'
+
+# Write file
+length=$(($BLOCKS*$BSIZE))
+$XFS_IO_PROG -f -c pwrite 0 $length -c fsync $testfile /dev/null
+
+# Collapse alternate blocks
+for (( i = 1; i = 7; i++ )); do
+ for(( j=0 ; j $(($BLOCKS/(2**$i))) ; j++ )); do
+ offset=$(($j*$BSIZE))
+ $XFS_IO_PROG -c fcollapse $offset $BSIZE $testfile /dev/null
+ done
+done
+
+# Check if 80 extents are present
+$XFS_IO_PROG -c fiemap -v $testfile | _filter_fiemap
+
+_do 'unmount $SCRATCH_DEV' 'umount $SCRATCH_DEV'
+_do 'repair filesystem' '_check_scratch_fs'
+
+# success, all done
+status=0; exit
diff --git a/tests/shared/317.out b/tests/shared/317.out
new file mode 100644
index 000..836f0fe
--- /dev/null
+++ b/tests/shared/317.out
@@ -0,0 +1,85 @@
+QA output created by 317
+make filesystem on $SCRATCH_DEV... done
+mount filesytem... done
+0: [0..7]: extent
+1: [8..15]: extent
+2: [16..23]: extent
+3: [24..31]: extent
+4: [32..39]: extent
+5: [40..47]: extent
+6: [48..55]: extent
+7: [56..63]: extent
+8: [64..71]: extent
+9: [72..79]: extent
+10: [80..87]: extent
+11: [88..95]: extent
+12: [96..103]: extent
+13: [104..111]: extent
+14: [112..119]: extent
+15: [120..127]: extent
+16: [128..135]: extent
+17: [136..143]: extent
+18: [144..151]: extent
+19: [152..159]: extent
+20: [160..167]: extent
+21: [168..175]: extent
+22: [176..183]: extent
+23: [184..191]: extent
+24: [192..199]: extent
+25: [200..207]: extent
+26: [208..215]: extent
+27: [216..223]: extent
+28: [224..231]: extent
+29: [232..239]: extent
+30: [240..247]: extent
+31: [248..255]: extent
+32: [256..263]: extent
+33: [264..271]: extent
+34: [272..279]: extent
+35: [280..287]: extent
+36: [288..295]: extent
+37: [296..303]: extent
+38: [304..311]: extent
+39: [312..319]: extent
+40: [320..327]: extent
+41: [328..335]: extent
+42: [336..343]: extent
+43: [344..351]: extent
+44: [352..359]: extent
+45: [360..367]: extent
+46: [368..375]: extent
+47: [376..383]: extent
+48: [384..391]: extent
+49: [392..399]: extent
[PATCH v2 3/7] ext4: add support FALLOC_FL_COLLAPSE_RANGE for fallocate
From: Namjae Jeon namjae.j...@samsung.com
Add support FALLOC_FL_COLLAPSE_RANGE for fallocate.
Signed-off-by: Namjae Jeon namjae.j...@samsung.com
Signed-off-by: Ashish Sangwan a.sang...@samsung.com
---
fs/ext4/ext4.h |3 +
fs/ext4/extents.c | 286 ++-
fs/ext4/move_extent.c |2 +-
include/trace/events/ext4.h | 25
4 files changed, 314 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index f3c43fc..a13e0f4 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -2737,6 +2737,7 @@ extern int ext4_find_delalloc_cluster(struct inode
*inode, ext4_lblk_t lblk);
extern int ext4_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
__u64 start, __u64 len);
extern int ext4_ext_precache(struct inode *inode);
+extern int ext4_collapse_range(struct inode *inode, loff_t offset, loff_t len);
/* move_extent.c */
extern void ext4_double_down_write_data_sem(struct inode *first,
@@ -2748,6 +2749,8 @@ void ext4_inode_double_unlock(struct inode *inode1,
struct inode *inode2);
extern int ext4_move_extents(struct file *o_filp, struct file *d_filp,
__u64 start_orig, __u64 start_donor,
__u64 len, __u64 *moved_len);
+extern int mext_next_extent(struct inode *inode, struct ext4_ext_path *path,
+ struct ext4_extent **extent);
/* page-io.c */
extern int __init ext4_init_pageio(void);
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 54d52af..baf1faf 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4580,12 +4580,16 @@ long ext4_fallocate(struct file *file, int mode, loff_t
offset, loff_t len)
unsigned int credits, blkbits = inode-i_blkbits;
/* Return error if mode is not supported */
- if (mode ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
+ if (mode ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE |
+FALLOC_FL_COLLAPSE_RANGE))
return -EOPNOTSUPP;
if (mode FALLOC_FL_PUNCH_HOLE)
return ext4_punch_hole(inode, offset, len);
+ if (mode FALLOC_FL_COLLAPSE_RANGE)
+ return ext4_collapse_range(inode, offset, len);
+
ret = ext4_convert_inline_data(inode);
if (ret)
return ret;
@@ -4884,3 +4888,283 @@ int ext4_fiemap(struct inode *inode, struct
fiemap_extent_info *fieinfo,
ext4_es_lru_add(inode);
return error;
}
+
+/*
+ * ext4_access_path:
+ * Function to access the path buffer for marking it dirty.
+ * It also checks if there are sufficient credits left in the journal handle
+ * to update path.
+ */
+static int
+ext4_access_path(handle_t *handle, struct inode *inode,
+ struct ext4_ext_path *path)
+{
+ int credits, err;
+
+ /*
+* Check if need to extend journal credits
+* 3 for leaf, sb, and inode plus 2 (bmap and group
+* descriptor) for each block group; assume two block
+* groups
+*/
+ if (handle-h_buffer_credits 7) {
+ credits = ext4_writepage_trans_blocks(inode);
+ err = ext4_ext_truncate_extend_restart(handle, inode, credits);
+ /* EAGAIN is success */
+ if (err err != -EAGAIN)
+ return err;
+ }
+
+ err = ext4_ext_get_access(handle, inode, path);
+ return err;
+}
+
+/*
+ * ext4_ext_shift_path_extents:
+ * Shift the extents of a path structure lying between path[depth].p_ext
+ * and EXT_LAST_EXTENT(path[depth].p_hdr) downwards, by subtracting shift
+ * from starting block for each extent.
+ */
+static int
+ext4_ext_shift_path_extents(struct ext4_ext_path *path, ext4_lblk_t shift,
+ struct inode *inode, handle_t *handle,
+ ext4_lblk_t *start)
+{
+ int depth, err = 0;
+ struct ext4_extent *ex_start, *ex_last;
+ bool update = 0;
+ depth = path-p_depth;
+
+ while (depth = 0) {
+ if (depth == path-p_depth) {
+ ex_start = path[depth].p_ext;
+ if (!ex_start)
+ return -EIO;
+
+ ex_last = EXT_LAST_EXTENT(path[depth].p_hdr);
+ if (!ex_last)
+ return -EIO;
+
+ err = ext4_access_path(handle, inode, path + depth);
+ if (err)
+ goto out;
+
+ if (ex_start == EXT_FIRST_EXTENT(path[depth].p_hdr))
+ update = 1;
+
+ *start = ex_last-ee_block +
+ ext4_ext_get_actual_len(ex_last);
+
+ while (ex_start = ex_last) {
+ ex_start-ee_block -= shift;
+ ext4_ext_try_to_merge(handle, inode,
+
[PATCH v2 4/7] xfsprogs: xfsio: add support FALLOC_FL_COLLAPSE_RANGE for fallocate
From: Namjae Jeon namjae.j...@samsung.com
Add support FALLOC_FL_COLLAPSE_RANGE for fallocate.
Signed-off-by: Namjae Jeon namjae.j...@samsung.com
Signed-off-by: Ashish Sangwan a.sang...@samsung.com
---
io/prealloc.c | 39 ++-
man/man8/xfs_io.8 |6 ++
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/io/prealloc.c b/io/prealloc.c
index 8380646..e7ff940 100644
--- a/io/prealloc.c
+++ b/io/prealloc.c
@@ -29,6 +29,10 @@
#define FALLOC_FL_PUNCH_HOLE 0x02
#endif
+#ifndef FALLOC_FL_COLLAPSE_RANGE
+#define FALLOC_FL_COLLAPSE_RANGE 0x08
+#endif
+
static cmdinfo_t allocsp_cmd;
static cmdinfo_t freesp_cmd;
static cmdinfo_t resvsp_cmd;
@@ -37,6 +41,7 @@ static cmdinfo_t zero_cmd;
#if defined(HAVE_FALLOCATE)
static cmdinfo_t falloc_cmd;
static cmdinfo_t fpunch_cmd;
+static cmdinfo_t fcollapse_cmd;
#endif
static int
@@ -159,8 +164,11 @@ fallocate_f(
int mode = 0;
int c;
- while ((c = getopt(argc, argv, kp)) != EOF) {
+ while ((c = getopt(argc, argv, ckp)) != EOF) {
switch (c) {
+ case 'c':
+ mode = FALLOC_FL_COLLAPSE_RANGE;
+ break;
case 'k':
mode = FALLOC_FL_KEEP_SIZE;
break;
@@ -203,6 +211,25 @@ fpunch_f(
}
return 0;
}
+
+static int
+fcollapse_f(
+ int argc,
+ char**argv)
+{
+ xfs_flock64_t segment;
+ int mode = FALLOC_FL_COLLAPSE_RANGE;
+
+ if(!offset_length(argv[1], argv[2], segment))
+ return 0;
+
+ if (fallocate(file-fd, mode,
+ segment.l_start, segment.l_len)) {
+ perror(fallocate);
+ return 0;
+ }
+ return 0;
+}
#endif /* HAVE_FALLOCATE */
void
@@ -277,5 +304,15 @@ prealloc_init(void)
fpunch_cmd.oneline =
_(de-allocates space assocated with part of a file via
fallocate);
add_command(fpunch_cmd);
+
+ fcollapse_cmd.name = fcollapse;
+ fcollapse_cmd.cfunc = fcollapse_f;
+ fcollapse_cmd.argmin = 2;
+ fcollapse_cmd.argmax = 2;
+ fcollapse_cmd.flags = CMD_NOMAP_OK | CMD_FOREIGN_OK;
+ fcollapse_cmd.args = _(off len);
+ fcollapse_cmd.oneline =
+ _(de-allocates space and nullify the hole by shifting extents
into it);
+ add_command(fcollapse_cmd);
#endif /* HAVE_FALLOCATE */
}
diff --git a/man/man8/xfs_io.8 b/man/man8/xfs_io.8
index 767b50e..9543b20 100644
--- a/man/man8/xfs_io.8
+++ b/man/man8/xfs_io.8
@@ -380,6 +380,12 @@ will set the FALLOC_FL_KEEP_SIZE flag as described in
.PD
.RE
.TP
+.BI fcollapse offset length
+Call fallocate with FALLOC_FL_COLLAPSE_RANGE flag as described in the
+.BR fallocate (2)
+manual page to de-allocates blocks and eliminates the hole created in this
process
+by shifting data blocks into the hole.
+.TP
.BI fpunch offset length
Punches (de-allocates) blocks in the file by calling fallocate with
the FALLOC_FL_PUNCH_HOLE flag as described in the
--
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] smp: harmonize prototypes of smp functions
Avoid unnecessary casts from int to bool in smp functions. Some
functions in kernel/smp.c have a wait parameter that can be set to one
if you want to wait for the command to complete. It's defined as bool
in a few of them and int in the rest. If a function with wait
declared as int calls a function whose prototype has wait defined as
bool, the compiler needs to test if the int is != 0 and change it to 1
if so. This useless check can be avoided if we are consistent and
make all the functions use the same type for this parameter.
For example in arm, before this patch:
800464e4 smp_call_function:
800464e4: b538push{r3, r4, r5, lr}
800464e6: 460dmov r5, r1
800464e8: 4613mov r3, r2 ; move wait to r3
800464ea: f64f 448c movwr4, #64652
800464ee: 3300addsr3, #0 ; test if wait is 0
800464f0: f2c8 0425 movtr4, #32805
800464f4: 4601mov r1, r0
800464f6: bf18it ne
800464f8: 2301movne r3, #1 ; if it is not, wait = 1
800464fa: 462amov r2, r5
800464fc: 6820ldr r0, [r4, #0]
800464fe: f7ff fea9 bl 80046254 smp_call_function_many
80046502: 2000movsr0, #0
80046504: bd38pop {r3, r4, r5, pc}
80046506: bf00nop
After the patch:
800464e4 smp_call_function:
800464e4: b538push{r3, r4, r5, lr}
800464e6: 460dmov r5, r1
800464e8: 4613mov r3, r2 ; just move it to r3
800464ea: f64f 448c movwr4, #64652
800464ee: 4601mov r1, r0
800464f0: f2c8 0425 movtr4, #32805
800464f4: 462amov r2, r5
800464f6: 6820ldr r0, [r4, #0]
800464f8: f7ff feac bl 80046254 smp_call_function_many
800464fc: 2000movsr0, #0
800464fe: bd38pop {r3, r4, r5, pc}
Same for x86. Before:
8109bf10 smp_call_function:
8109bf10: 55 push %rbp
8109bf11: 48 89 e5mov%rsp,%rbp
8109bf14: 31 c9 xor%ecx,%ecx ; ecx = 0
8109bf16: 85 d2 test %edx,%edx ; test if
wait is 0
8109bf18: 48 89 f2mov%rsi,%rdx
8109bf1b: 48 89 femov%rdi,%rsi
8109bf1e: 48 8b 3d 4b d3 76 00mov0x76d34b(%rip),%rdi
# 81809270 cpu_online_mask
8109bf25: 0f 95 c1setne %cl; if it is
not, ecx = 1
8109bf28: e8 43 fc ff ff callq 8109bb70
smp_call_function_many
8109bf2d: 31 c0 xor%eax,%eax
8109bf2f: 5d pop%rbp
8109bf30: c3 retq
After:
8109bf20 smp_call_function:
8109bf20: 55 push %rbp
8109bf21: 48 89 e5mov%rsp,%rbp
8109bf24: 89 d1 mov%edx,%ecx ; just move
wait to ecx
8109bf26: 48 89 f2mov%rsi,%rdx
8109bf29: 48 89 femov%rdi,%rsi
8109bf2c: 48 8b 3d 3d d3 76 00mov0x76d33d(%rip),%rdi
# 81809270 cpu_online_mask
8109bf33: e8 48 fc ff ff callq 8109bb80
smp_call_function_many
8109bf38: 31 c0 xor%eax,%eax
8109bf3a: 5d pop%rbp
8109bf3b: c3 retq
8109bf3c: 0f 1f 40 00 nopl 0x0(%rax)
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Javi Merino javi.mer...@arm.com
---
include/linux/smp.h |6 +++---
kernel/smp.c|6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/smp.h b/include/linux/smp.h
index c181399..a894405 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -72,7 +72,7 @@ extern void smp_cpus_done(unsigned int max_cpus);
*/
int smp_call_function(smp_call_func_t func, void *info, int wait);
void smp_call_function_many(const struct cpumask *mask,
- smp_call_func_t func, void *info, bool wait);
+ smp_call_func_t func, void *info, int wait);
void __smp_call_function_single(int cpuid, struct call_single_data *data,
int wait);
@@ -104,7 +104,7 @@ int on_each_cpu(smp_call_func_t func, void *info, int wait);
* the local one.
*/
void on_each_cpu_mask(const struct cpumask *mask, smp_call_func_t func,
- void *info, bool wait);
+ void *info, int wait);
/*
* Call a function
RE: linux-next: build failure after merge of the final tree (drm tree related)
-Original Message-
From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
Sent: Monday, September 02, 2013 5:01 AM
To: Dave Airlie
Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Deucher,
Alexander
Subject: linux-next: build failure after merge of the final tree (drm tree
related)
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/gpu/drm/radeon/ci_dpm.c: In function
'ci_request_link_speed_change_before_state_change':
drivers/gpu/drm/radeon/ci_dpm.c:4212:4: error: implicit declaration of
function 'radeon_acpi_pcie_performance_request' [-Werror=implicit-
function-declaration]
if (radeon_acpi_pcie_performance_request(rdev,
PCIE_PERF_REQ_PECI_GEN3, false) == 0)
^
Caused by commit cc8dbbb4f62a (drm/radeon: add dpm support for CI
dGPUs
(v2)). These calls need protecting with CONFIG_ACPI (like is done in
cypress_dpm.c, I guess).
I tried reverting commit 9c725e5bcdae (Merge branch 'drm-next-3.12' of
git://people.freedesktop.org/~agd5f/linux into drm-next) but that failed
because that branch is based on v3.11-rc7 (!) which is later than the
base of the drm tree (v3.11-rc3). :-(
I added this fix up patch for today (it may be wrong, butfixes the build
failure).
From: Stephen Rothwell s...@canb.auug.org.au
Date: Mon, 2 Sep 2013 18:57:41 +1000
Subject: [PATCH] drm/radeon: protect ACPI calls with CONFIG_ACPI
Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
The patch looks fine.
Thanks,
Alex
---
drivers/gpu/drm/radeon/ci_dpm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c
b/drivers/gpu/drm/radeon/ci_dpm.c
index 916630f..3cce533 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -4208,6 +4208,7 @@ static void
ci_request_link_speed_change_before_state_change(struct radeon_devic
pi-pspp_notify_required = false;
if (target_link_speed current_link_speed) {
switch (target_link_speed) {
+#ifdef CONFIG_ACPI
case RADEON_PCIE_GEN3:
if (radeon_acpi_pcie_performance_request(rdev,
PCIE_PERF_REQ_PECI_GEN3, false) == 0)
break;
@@ -4217,6 +4218,7 @@ static void
ci_request_link_speed_change_before_state_change(struct radeon_devic
case RADEON_PCIE_GEN2:
if (radeon_acpi_pcie_performance_request(rdev,
PCIE_PERF_REQ_PECI_GEN2, false) == 0)
break;
+#endif
default:
pi-force_pcie_gen =
ci_get_current_pcie_speed(rdev);
break;
@@ -4248,7 +4250,9 @@ static void
ci_notify_link_speed_change_after_state_change(struct radeon_device
(ci_get_current_pcie_speed(rdev) 0))
return;
+#ifdef CONFIG_ACPI
radeon_acpi_pcie_performance_request(rdev, request,
false);
+#endif
}
}
--
1.8.4.rc3
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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] ipv6: ipv6_create_tempaddr cleanup
于 2013/9/2 2:35, Hannes Frederic Sowa 写道: On Fri, Aug 30, 2013 at 05:02:38PM +0200, Petr Holasek wrote: This two-liner removes max_addresses variable which is now unecessary related to patch [ipv6: remove max_addresses check from ipv6_create_tempaddr]. Signed-off-by: Petr Holasek phola...@redhat.com Uh, yes, I missed that. Thanks a lot! Acked-by: Hannes Frederic Sowa han...@stressinduktion.org Acked-by: Ding Tianhong dingtianh...@huawei.com -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: [Xen-devel] [PATCH v5 02/13] arm: introduce a global dma_ops pointer
On 08/29/2013 07:32 PM, Stefano Stabellini wrote:
Initially set dma_ops to arm_dma_ops.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
CC: will.dea...@arm.com
CC: li...@arm.linux.org.uk
Changes in v3:
- keep using arm_dma_ops in dmabounce.
---
arch/arm/include/asm/dma-mapping.h |3 ++-
arch/arm/mm/dma-mapping.c |3 +++
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index 0982206..7d6e4f9 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -13,6 +13,7 @@
#include asm/cacheflush.h
#define DMA_ERROR_CODE (~0)
+extern struct dma_map_ops *dma_ops;
Hi,
I tried to build your swiotlb patch series for the Arndale. I have a compilation
error because dma_ops is already used in samsung sound driver
(sound/soc/samsung/dma.c).
This small fix allow me to built this serie for the Arndale.
Do I need to send it separately?
===
commit 73d4ceded87f52fa958b92d8d8d65be485e90857
Author: Julien Grall julien.gr...@linaro.org
Date: Mon Sep 2 15:36:35 2013 +0100
ASoC: Samsung: Rename dma_ops by samsung_dma_ops
The commit arm: introduce a global dma_ops pointer introduce compilation
issue
when CONFIG_SND_SOC_SAMSUNG is enabled.
sound/soc/samsung/dma.c:345:27: error: conflicting types for 'dma_ops'
/local/home/julien/works/arndale/linux/arch/arm/include/asm/dma-mapping.h:16:28:
note: previous declaration of 'dma_ops' was here
Signed-off-by: Julien Grall julien.gr...@linaro.org
diff --git a/sound/soc/samsung/dma.c b/sound/soc/samsung/dma.c
index ddea134..c341603 100644
--- a/sound/soc/samsung/dma.c
+++ b/sound/soc/samsung/dma.c
@@ -342,7 +342,7 @@ static int dma_mmap(struct snd_pcm_substream *substream,
runtime-dma_bytes);
}
-static struct snd_pcm_ops dma_ops = {
+static struct snd_pcm_ops samsung_dma_ops = {
.open = dma_open,
.close = dma_close,
.ioctl = snd_pcm_lib_ioctl,
@@ -429,7 +429,7 @@ out:
}
static struct snd_soc_platform_driver samsung_asoc_platform = {
- .ops= dma_ops,
+ .ops= samsung_dma_ops,
.pcm_new= dma_new,
.pcm_free = dma_free_dma_buffers,
};
--
Julien Grall
--
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: Clock framework deadlock with external SPI clockchip
On 09/02/2013 01:18 PM, Peter De Schrijver wrote: On Fri, Aug 30, 2013 at 03:24:45PM +0200, Lars-Peter Clausen wrote: Hi, I'm currently facing a deadlock in the common clock framework that unfortunately is not addressed by the reentrancy patches. I have a external clock chip that is controlled via SPI. So for example to configure the rate of the clock chip you need to send a SPI message. Naturally the clock framework will hold the prepare lock while configuring the rate. Communication in the SPI framework happens asynchronously, spi_sync() will enqueue a message in the SPI masters queue and then wait using wait_for_completion(). The master will call complete() once the transfer has been finished. The SPI master runs in it's own thread in which it processes the messages. In this thread it also calls clk_set_rate() to configure the SPI transfer clock rate based on what the message says. Now the deadlock happens as we try to take the prepare_lock again and since the clock chip and the SPI master run in different threads the reentrancy code does not kick in. The basic sequence is like this: === Clock chip driver ====== SPI master driver === clk_prepare_lock() spi_sync() wait_for_completion(X) clk_get_rate() clk_prepare_lock() --- DEADLOCK clk_prepare_unlock() ... complete(X) ... clk_prepare_unlock() I'm wondering if you have any idea how this can be fixed. In my opinion we'd need a per clock mutex to address this properly. One workaround is to leave the SPI masters clock always prepared. A similar problem can occur with I2C and DVFS using notifiers. That's kind of what I'm doing right now as a temporary solution. But we'd basically need to have all SPI or I2C master drivers to be aware that they might be used for controlling a external clock chip. And there are also situations where the workaround does not work. E.g. if the clk API is used to configure the rate of the SPI SCK signal, since the rate can be set by the spi message. - Lars -- 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] dmaengine: dma_slave_caps: remove sg entries
On 09/02/2013 02:21 PM, Vinod Koul wrote: As pointed by Russell in [1], the sg properties are already availble in struct device, so no need to duplicate here. [1]: http://marc.info/?l=linux-omapm=137416733628831 Hm, I guess that will work as well, but shouldn't we update the drivers that already implementing this interface first? - Lars -- 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] drm/i2c: Fix broken TDA998x audio (was: Re: [PATCH v2 5/8] drm/i2c: tda998x: add video and audio input configuration)
On Wed, Aug 14, 2013 at 09:43:30PM +0200, Sebastian Hesselbarth wrote:
From: Russell King rmk+ker...@arm.linux.org.uk
This patch adds tda998x specific parameters to allow it to be configured
for different boards using it. Also, this implements rudimentary audio
support for S/PDIF attached controllers.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Tested-by: Darren Etheridge detheri...@ti.com
---
It looks like there's been a bug introduced in this patch (which wasn't
in my original).
@@ -445,8 +681,7 @@ tda998x_encoder_dpms(struct drm_encoder *encoder, int
mode)
switch (mode) {
case DRM_MODE_DPMS_ON:
- /* enable audio and video ports */
- reg_write(encoder, REG_ENA_AP, 0xff);
+ /* enable video ports, audio will be enabled later */
reg_write(encoder, REG_ENA_VP_0, 0xff);
reg_write(encoder, REG_ENA_VP_1, 0xff);
reg_write(encoder, REG_ENA_VP_2, 0xff);
I also disabled the writing to REG_ENA_AP in the DPMS off path as well,
which clears this register.
That seems to be missing from this patch, and it means that when the
display is placed into DPMS-off mode, the audio inputs are disabled,
never to be re-enabled. There is no need to disable the audio input
in DPMS-off mode.
8=
From: Russell King rmk+ker...@arm.linux.org.uk
Subject: [PATCH] drm/i2c: Fix broken TDA998x audio
In patch drm/i2c: tda998x: add video and audio input configuration in
its original version, disabling the audio input port was removed. The
version which was submitted for merging had this change deleted, which
results in audio being non-functional. Fix this by removing the write.
While here, update the comment too.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/gpu/drm/i2c/tda998x_drv.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 5742cfc..59878af 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -705,8 +705,7 @@ tda998x_encoder_dpms(struct drm_encoder *encoder, int mode)
reg_write(encoder, REG_VIP_CNTRL_2, priv-vip_cntrl_2);
break;
case DRM_MODE_DPMS_OFF:
- /* disable audio and video ports */
- reg_write(encoder, REG_ENA_AP, 0x00);
+ /* disable video ports */
reg_write(encoder, REG_ENA_VP_0, 0x00);
reg_write(encoder, REG_ENA_VP_1, 0x00);
reg_write(encoder, REG_ENA_VP_2, 0x00);
--
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 PULL] ARM/ARM64 architected timer updates for v3.12, take 2
On 08/30/2013 06:52 PM, Sudeep KarkadaNagesha wrote: git://linux-arm.org/linux-skn.git timer_evtstrm Hi Sudeep, I don't see the acked-by from Olof or Kevin. Your patchset touches files under arch/arm which are maintained by them and I won't take the patchset if they don't agree the modifications on the files falling under my umbrella that will pass through my tree. Please do it ASAP if you want a chance to hit 3.12, it is already very late. Thanks -- Daniel -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- 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/1] drivers/acpi: acpi_ipmi.c replace mutex with spin_lock_irqsave
From: tcam...@redhat.com
From: Tony Camuso tcam...@redhat.com
We were getting occasional Scheduling while atomic call traces
during boot on some systems. Problem was first seen on a Cisco C210
but we were able to reproduce it on a Cisco c220m3. Setting
CONFIG_LOCKDEP and LOCKDEP_SUPPORT to 'y' exposed a lockdep around
tx_msg_lock in acpi_ipmi.c struct acpi_ipmi_device.
=
[ INFO: inconsistent lock state ]
2.6.32-415.el6.x86_64-debug-splck #1
-
inconsistent {SOFTIRQ-ON-W} - {IN-SOFTIRQ-W} usage.
ksoftirqd/3/17 [HC0[0]:SC1[1]:HE1:SE0] takes:
(ipmi_device-tx_msg_lock){+.?...}, at: [81337a27]
ipmi_msg_handler+0x71/0x126
{SOFTIRQ-ON-W} state was registered at:
[810ba11c] __lock_acquire+0x63c/0x1570
[810bb0f4] lock_acquire+0xa4/0x120
[815581cc] __mutex_lock_common+0x4c/0x400
[815586ea] mutex_lock_nested+0x4a/0x60
[8133789d] acpi_ipmi_space_handler+0x11b/0x234
[81321c62] acpi_ev_address_space_dispatch+0x170/0x1be
The ipmi_msg_handler() function in drivers/acpi/acpi_ipmi was taking
a mutex_lock after ultimately being called from a call chain initiated
by function smi_rcv_tasklet() in drivers/char/ipmi/ipmi_msghandler.c.
Documentation/mutex-design.txt on lines 93 and 94 says, mutexes may
not be used in hardware or software interrupt contexts such as
tasklets and timers.
The patch changes the mutex member tx_msg_lock in acpi_ipmi.c struct
acpi_ipmi_device to a spinlock_t and replaces mutex_lock/unlock pairs
with spin_lock_irqsave/unlock_irqrestore around tx_msg_lock for
accesses to that struct.
Tested the patch in a boot loop with lockdep debug enabled and never
saw the problem in over 400 reboots.
Signed-off-by: Tony Camuso tcam...@redhat.com
---
drivers/acpi/acpi_ipmi.c | 24 ++--
1 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c
index f40acef..a4b428d 100644
--- a/drivers/acpi/acpi_ipmi.c
+++ b/drivers/acpi/acpi_ipmi.c
@@ -57,7 +57,7 @@ struct acpi_ipmi_device {
struct list_head head;
/* the IPMI request message list */
struct list_head tx_msg_list;
- struct mutextx_msg_lock;
+ spinlock_t tx_msg_lock;
acpi_handle handle;
struct pnp_dev *pnp_dev;
ipmi_user_t user_interface;
@@ -147,6 +147,7 @@ static void acpi_format_ipmi_msg(struct acpi_ipmi_msg
*tx_msg,
struct kernel_ipmi_msg *msg;
struct acpi_ipmi_buffer *buffer;
struct acpi_ipmi_device *device;
+ unsigned long flags;
msg = tx_msg-tx_message;
/*
@@ -177,10 +178,10 @@ static void acpi_format_ipmi_msg(struct acpi_ipmi_msg
*tx_msg,
/* Get the msgid */
device = tx_msg-device;
- mutex_lock(device-tx_msg_lock);
+ spin_lock_irqsave(device-tx_msg_lock, flags);
device-curr_msgid++;
tx_msg-tx_msgid = device-curr_msgid;
- mutex_unlock(device-tx_msg_lock);
+ spin_unlock_irqrestore(device-tx_msg_lock, flags);
}
static void acpi_format_ipmi_response(struct acpi_ipmi_msg *msg,
@@ -242,6 +243,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg,
void *user_msg_data)
int msg_found = 0;
struct acpi_ipmi_msg *tx_msg;
struct pnp_dev *pnp_dev = ipmi_device-pnp_dev;
+ unsigned long flags;
if (msg-user != ipmi_device-user_interface) {
dev_warn(pnp_dev-dev, Unexpected response is returned.
@@ -250,7 +252,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg,
void *user_msg_data)
ipmi_free_recv_msg(msg);
return;
}
- mutex_lock(ipmi_device-tx_msg_lock);
+ spin_lock_irqsave(ipmi_device-tx_msg_lock, flags);
list_for_each_entry(tx_msg, ipmi_device-tx_msg_list, head) {
if (msg-msgid == tx_msg-tx_msgid) {
msg_found = 1;
@@ -258,7 +260,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg,
void *user_msg_data)
}
}
- mutex_unlock(ipmi_device-tx_msg_lock);
+ spin_unlock_irqrestore(ipmi_device-tx_msg_lock, flags);
if (!msg_found) {
dev_warn(pnp_dev-dev, Unexpected response (msg id %ld) is
returned.\n, msg-msgid);
@@ -378,6 +380,8 @@ acpi_ipmi_space_handler(u32 function, acpi_physical_address
address,
struct acpi_ipmi_device *ipmi_device = handler_context;
int err, rem_time;
acpi_status status;
+ unsigned long flags;
+
/*
* IPMI opregion message.
* IPMI message is firstly written to the BMC and system software
@@ -395,9 +399,9 @@ acpi_ipmi_space_handler(u32 function, acpi_physical_address
address,
return AE_NO_MEMORY;
acpi_format_ipmi_msg(tx_msg, address, value);
- mutex_lock(ipmi_device-tx_msg_lock);
+
Re: [GIT PULL] ARM/ARM64 architected timer updates for v3.12, take 2
On 02/09/13 15:54, Daniel Lezcano wrote: On 08/30/2013 06:52 PM, Sudeep KarkadaNagesha wrote: git://linux-arm.org/linux-skn.git timer_evtstrm Hi Sudeep, I don't see the acked-by from Olof or Kevin. Your patchset touches files under arch/arm which are maintained by them and I won't take the patchset if they don't agree the modifications on the files falling under my umbrella that will pass through my tree. Please do it ASAP if you want a chance to hit 3.12, it is already very late. As Olof already mentioned, I think its too late for v3.12. He wants me to repost after v3.12 merge window. I will do the same. Regards, Sudeep -- 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 PULL] ARM/ARM64 architected timer updates for v3.12, take 2
On 09/02/2013 05:04 PM, Sudeep KarkadaNagesha wrote: On 02/09/13 15:54, Daniel Lezcano wrote: On 08/30/2013 06:52 PM, Sudeep KarkadaNagesha wrote: git://linux-arm.org/linux-skn.git timer_evtstrm Hi Sudeep, I don't see the acked-by from Olof or Kevin. Your patchset touches files under arch/arm which are maintained by them and I won't take the patchset if they don't agree the modifications on the files falling under my umbrella that will pass through my tree. Please do it ASAP if you want a chance to hit 3.12, it is already very late. As Olof already mentioned, I think its too late for v3.12. He wants me to repost after v3.12 merge window. I will do the same. ok. -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- 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] Remove support for score architecture
Before we start the development of the S+core, Sunplus had licensed ARM and MIPS. We develop S+core for other reason such as the price. Some products on the web of Sunplus adopt S+core , for example the SPV7050.(http://w3.sunplus.com/products/spv7050.asp) These products could still be bought from the market. Some high-end products adopt ARM or MIPS. So, there is no conflict for a company adopts multiple architectures. As I said, we recognize that we rarely update because of the limited applications and rare requests from customers. Maybe we don’t understand the culture enough; we think that it is unnecessary if we have no new bugs or new functions, the thought seems wrong. We can commit some patches in the near future. Best, Lennox 2013/9/2 Guenter Roeck li...@roeck-us.net: On 09/01/2013 09:13 PM, Lennox Wu wrote: Dear all, Indeed, Sunplus S+core is not a popular architecture and there is no standalone to be sold so you should not find related news on the Internet. However, the s+core is adopted by our SoCs and these SoCs are indeed adopted by some companies, we hope the architecture can be reserved to provide the more and more powerful Linux for our customers. It is true that we rarely update the code because that we are rarely requested to add new functions and to correct bugs by our customers, and it is also because we have no new product to release. In the near future, we will release some patches for the existed S+core architecture. Key question is not if the platform is popular, but if it is maintained. The commit log over the last two years strongly suggests that this is not the case. I suspect that the code is far from compilable at this point, much less executable. Unfortunately this is hard to verify, as a pre-built or even buildable toolchain is not easily available. From a company perspective, you might want to decide if you want to put resources into this architecture to keep it alive, or focus on more recent chips and architectures. Information available on the internet suggests that Suncore's more recent chips are based on ARM. Given that, it appears somewhat unlikely that resources for maintaining S+core will be made available. Guess we'll see if the situation changes. Guenter 2013/8/31 Guenter Roeck li...@roeck-us.net: The web site associated with the score architecture in MAINTAINERS is non-functional and available for sale. The last Ack from one of the maintainers was in December 2012. The main maintainer's last commit was in 2011. The last maintainer pull request was early 2011. Cc: Lennox Wu lennox...@gmail.com Cc: Chen Liqin liqin.c...@sunplusct.com Signed-off-by: Guenter Roeck li...@roeck-us.net --- More housekeeping. Maybe this removal request is a bit early, but architecture support seems to have vanished entirely. At the very least this puts interested parties (if there are any) on notice. -- 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/
