Re: [PATCH v3 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c

[Yasuaki Ishimatsu]

2013/02/05 16:35, liguang wrote:
> srat table should present only on acpi domain,
> seems mm/ is not the right place for it.
> 
> Signed-off-by: liguang 
> ---

Reviewed-by: Yasuaki Ishimatsu 

Thanks,
Yasuaki Ishimatsu

>   arch/x86/kernel/acpi/Makefile |1 +
>   arch/x86/kernel/acpi/srat.c   |  198 
> +
>   arch/x86/mm/Makefile  |1 -
>   arch/x86/mm/srat.c|  198 
> -
>   4 files changed, 199 insertions(+), 199 deletions(-)
>   create mode 100644 arch/x86/kernel/acpi/srat.c
>   delete mode 100644 arch/x86/mm/srat.c
> 
> diff --git a/arch/x86/kernel/acpi/Makefile b/arch/x86/kernel/acpi/Makefile
> index 163b225..98cea92 100644
> --- a/arch/x86/kernel/acpi/Makefile
> +++ b/arch/x86/kernel/acpi/Makefile
> @@ -1,5 +1,6 @@
>   obj-$(CONFIG_ACPI)  += boot.o
>   obj-$(CONFIG_ACPI_SLEEP)+= sleep.o wakeup_$(BITS).o
> +obj-$(CONFIG_ACPI_NUMA)  += srat.o
>   
>   ifneq ($(CONFIG_ACPI_PROCESSOR),)
>   obj-y   += cstate.o
> diff --git a/arch/x86/kernel/acpi/srat.c b/arch/x86/kernel/acpi/srat.c
> new file mode 100644
> index 000..cdd0da9
> --- /dev/null
> +++ b/arch/x86/kernel/acpi/srat.c
> @@ -0,0 +1,198 @@
> +/*
> + * ACPI 3.0 based NUMA setup
> + * Copyright 2004 Andi Kleen, SuSE Labs.
> + *
> + * Reads the ACPI SRAT table to figure out what memory belongs to which CPUs.
> + *
> + * Called from acpi_numa_init while reading the SRAT and SLIT tables.
> + * Assumes all memory regions belonging to a single proximity domain
> + * are in one chunk. Holes between them will be included in the node.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +int acpi_numa __initdata;
> +
> +static __init int setup_node(int pxm)
> +{
> + return acpi_map_pxm_to_node(pxm);
> +}
> +
> +static __init void bad_srat(void)
> +{
> + printk(KERN_ERR "SRAT: SRAT not used.\n");
> + acpi_numa = -1;
> +}
> +
> +static __init inline int srat_disabled(void)
> +{
> + return acpi_numa < 0;
> +}
> +
> +/* Callback for SLIT parsing */
> +void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
> +{
> + int i, j;
> +
> + for (i = 0; i < slit->locality_count; i++)
> + for (j = 0; j < slit->locality_count; j++)
> + numa_set_distance(pxm_to_node(i), pxm_to_node(j),
> + slit->entry[slit->locality_count * i + j]);
> +}
> +
> +/* Callback for Proximity Domain -> x2APIC mapping */
> +void __init
> +acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
> +{
> + int pxm, node;
> + int apic_id;
> +
> + if (srat_disabled())
> + return;
> + if (pa->header.length < sizeof(struct acpi_srat_x2apic_cpu_affinity)) {
> + bad_srat();
> + return;
> + }
> + if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0)
> + return;
> + pxm = pa->proximity_domain;
> + apic_id = pa->apic_id;
> + if (!apic->apic_id_valid(apic_id)) {
> + printk(KERN_INFO "SRAT: PXM %u -> X2APIC 0x%04x ignored\n",
> +  pxm, apic_id);
> + return;
> + }
> + node = setup_node(pxm);
> + if (node < 0) {
> + printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
> + bad_srat();
> + return;
> + }
> +
> + if (apic_id >= MAX_LOCAL_APIC) {
> + printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u 
> skipped apicid that is too big\n", pxm, apic_id, node);
> + return;
> + }
> + set_apicid_to_node(apic_id, node);
> + node_set(node, numa_nodes_parsed);
> + acpi_numa = 1;
> + printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u\n",
> +pxm, apic_id, node);
> +}
> +
> +/* Callback for Proximity Domain -> LAPIC mapping */
> +void __init
> +acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
> +{
> + int pxm, node;
> + int apic_id;
> +
> + if (srat_disabled())
> + return;
> + if (pa->header.length != sizeof(struct acpi_srat_cpu_affinity)) {
> + bad_srat();
> + return;
> + }
> + if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0)
> + return;
> + pxm = pa->proximity_domain_lo;
> + if (acpi_srat_revision >= 2)
> + pxm |= *((unsigned int*)pa->proximity_domain_hi) << 8;
> + node = setup_node(pxm);
> + if (node < 0) {
> + printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
> + bad_srat();
> + return;
> + }
> +
> + if (get_uv_system_type() >= UV_X2APIC)
> + apic_id = (pa->apic_id << 8) | pa->local_sapic_eid;
> + else
> + apic_id = pa->apic_id;
> +
> + if (apic_id >= MAX_LOCAL_APIC) {
> + 

Re: [PATCH v3 2/4] numa: avoid export acpi_numa variable

[Yasuaki Ishimatsu]

2013/02/05 16:36, liguang wrote:
> acpi_numa is used to prevent srat table
> being parsed, seems a little miss-named,
> if 'noacpi' was specified by cmdline and
> CONFIG_ACPI_NUMA was enabled, acpi_numa
> will be operated directly from everywhere
> it needed to disable/enable numa in acpi
> mode which was a bad thing, so, try to
> export a fuction to get srat table
> enable/disable info.
> 
> Signed-off-by: liguang 
> ---

Hmm. Did you test the patch?
By the patch, srat_disable() returns false(0) or 1. As a result,
acpi_numa_x2apic_affinity_init(), acpi_numa_processor_affinity_init()
and acpi_numa_memory_affinity_init() go wrong at following if sentence.

---
if (srat_disable())
return -1;
---

When you change a return value of function, you should check othe
functions which use it carefully.

And if you use acpi_numa as bool, you should use "acpi_numa = true"
instead of "acpi_numa = 1"

Thanks,
Yasuaki Ishimatsu

>   arch/x86/include/asm/acpi.h |2 +-
>   arch/x86/kernel/acpi/srat.c |   17 +++--
>   arch/x86/mm/numa.c  |2 +-
>   arch/x86/xen/enlighten.c|2 +-
>   4 files changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
> index b31bf97..449e12a 100644
> --- a/arch/x86/include/asm/acpi.h
> +++ b/arch/x86/include/asm/acpi.h
> @@ -177,7 +177,7 @@ static inline void disable_acpi(void) { }
>   #define ARCH_HAS_POWER_INIT 1
>   
>   #ifdef CONFIG_ACPI_NUMA
> -extern int acpi_numa;
> +extern void disable_acpi_numa(void);
>   extern int x86_acpi_numa_init(void);
>   #endif /* CONFIG_ACPI_NUMA */
>   
> diff --git a/arch/x86/kernel/acpi/srat.c b/arch/x86/kernel/acpi/srat.c
> index cdd0da9..8d7f3f8 100644
> --- a/arch/x86/kernel/acpi/srat.c
> +++ b/arch/x86/kernel/acpi/srat.c
> @@ -24,22 +24,27 @@
>   #include 
>   #include 
>   
> -int acpi_numa __initdata;
> +static bool acpi_numa __initdata;
>   
>   static __init int setup_node(int pxm)
>   {
>   return acpi_map_pxm_to_node(pxm);
>   }
>   
> -static __init void bad_srat(void)
> +void __init disable_acpi_numa(void)
>   {
> - printk(KERN_ERR "SRAT: SRAT not used.\n");
> - acpi_numa = -1;
> + acpi_numa = false;
>   }
>   
> -static __init inline int srat_disabled(void)
> +static void __init bad_srat(void)
>   {
> - return acpi_numa < 0;
> + disable_acpi_numa();
> + printk(KERN_ERR "SRAT: SRAT will not be used.\n");
> +}
> +
> +static bool __init srat_disabled(void)
> +{
> + return acpi_numa;
>   }
>   
>   /* Callback for SLIT parsing */
> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> index 245a4ba..1ebc907 100644
> --- a/arch/x86/mm/numa.c
> +++ b/arch/x86/mm/numa.c
> @@ -47,7 +47,7 @@ static __init int numa_setup(char *opt)
>   #endif
>   #ifdef CONFIG_ACPI_NUMA
>   if (!strncmp(opt, "noacpi", 6))
> - acpi_numa = -1;
> + disable_acpi_numa();
>   #endif
>   return 0;
>   }
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 657eca9..3636bc6 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1447,7 +1447,7 @@ asmlinkage void __init xen_start_kernel(void)
>* any NUMA information the kernel tries to get from ACPI will
>* be meaningless.  Prevent it from trying.
>*/
> - acpi_numa = -1;
> + disable_acpi_numa();
>   #endif
>   
>   /* Don't do the full vcpu_info placement stuff until we have a
> 


--
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/2] mm: hotplug: implement non-movable version of get_user_pages() to kill long-time pin pages

[Minchan Kim]

On Tue, Feb 05, 2013 at 02:18:42PM +0800, Lin Feng wrote:
> 
> 
> On 02/05/2013 01:25 PM, Minchan Kim wrote:
> > Hi Lin,
> > 
> > On Tue, Feb 05, 2013 at 12:42:48PM +0800, Lin Feng wrote:
> >> Hi Minchan,
> >>
> >> On 02/05/2013 08:58 AM, Minchan Kim wrote:
> >>> Hello,
> >>>
> >>> On Mon, Feb 04, 2013 at 06:04:06PM +0800, Lin Feng wrote:
>  Currently get_user_pages() always tries to allocate pages from movable 
>  zone,
>  as discussed in thread https://lkml.org/lkml/2012/11/29/69, in some case 
>  users
>  of get_user_pages() is easy to pin user pages for a long time(for now we 
>  found
>  that pages pinned as aio ring pages is such case), which is fatal for 
>  memory
>  hotplug/remove framework.
> 
>  So the 1st patch introduces a new library function called
>  get_user_pages_non_movable() to pin pages only from zone non-movable in 
>  memory.
>  It's a wrapper of get_user_pages() but it makes sure that all pages come 
>  from
>  non-movable zone via additional page migration.
> 
>  The 2nd patch gets around the aio ring pages can't be migrated bug 
>  caused by
>  get_user_pages() via using the new function. It only works when configed 
>  with
>  CONFIG_MEMORY_HOTREMOVE, otherwise it uses the old version of 
>  get_user_pages().
> >>>
> >>> CMA has same issue but the problem is the driver developers or any 
> >>> subsystem
> >>> using GUP can't know their pages is in CMA area or not in advance.
> >>> So all of client of GUP should use GUP_NM to work them with 
> >>> CMA/MEMORY_HOTPLUG well?
> >>> Even some driver module in embedded side doesn't open their source code.
> >> Yes, it somehow depends on the users of GUP. In MEMORY_HOTPLUG case, as 
> >> for most users
> >> of GUP, they will release the pinned pages immediately and to such users 
> >> they should get
> >> a good performance, using the old style interface is a smart way. And we 
> >> had better just
> >> deal with the cases we have to by using the new interface.
> > 
> > Hmm, I think you can't make sure most of user for MEMORY_HOTPLUG will 
> > release pinned pages
> > immediately. Because MEMORY_HOTPLUG could be used for embedded system for 
> > reducing power
> > by PASR and some drivers in embedded could use GUP anytime and anywhere. 
> > They can't know
> > in advance they will use pinned pages long time or release in short time 
> > because it depends
> > on some event like user's response which is very not predetermined.
> > So for solving it, we can add some WARN_ON in CMA/MEMORY_HOTPLUG part just 
> > in case of
> > failing migration by page count and then, investigate they are really using 
> > GUP and it's
> > REALLY a culprit. If so, yell to them "Please use GUP_NM instead"?
> > 
> > Yes. it could be done but it would be rather trobulesome job.
> Yes WARN_ON may be easy while troubleshooting for finding the immigrate-able 
> page is 
> a big job.
> If we want to kill all the potential immigrate-able pages caused by GUP we'd 
> better use the
> *non_movable* version of GUP.
> But in some server environment we want to keep the performance but also want 
> to use hotremove
> feature in case. Maybe patch the place as we need is a trade off for such 
> support.
> 
> Mel also said in the last discussion:
> 
> On 11/30/2012 07:00 PM, Mel Gorman wrote:> On Thu, Nov 29, 2012 at 11:55:02PM 
> -0800, Andrew Morton wrote:
> >> Well, that's a fairly low-level implementation detail.  A more typical
> >> approach would be to add a new get_user_pages_non_movable() or such. 
> >> That would probably have the same signature as get_user_pages(), with
> >> one additional argument.  Then get_user_pages() becomes a one-line
> >> wrapper which passes in a particular value of that argument.
> >>
> > 
> > That is going in the direction that all pinned pages become 
> > MIGRATE_UNMOVABLE
> > allocations.  That will impact THP availability by increasing the number
> > of MIGRATE_UNMOVABLE blocks that exist and it would hit every user --
> > not just those that care about ZONE_MOVABLE.
> > 
> > I'm likely to NAK such a patch if it's only about node hot-remove because
> > it's much more of a corner case than wanting to use THP.
> > 
> > I would prefer if get_user_pages() checked if the page it was about to
> > pin was in ZONE_MOVABLE and if so, migrate it at that point before it's
> > pinned. It'll be expensive but will guarantee ZONE_MOVABLE availability
> > if that's what they want. The CMA people might also want to take
> > advantage of this if the page happened to be in the MIGRATE_CMA
> > pageblock.
> > 
> 
> So it may not a good idea that we all fall into calling the *non_movable* 
> version of
> GUP when CONFIG_MIGRATE_ISOLATE is on. What do you think?

Frankly speaking, I can't understand Mel's comment.
AFAIUC, he said GUP checks the page before get_page and if the page is movable 
zone,
then migrate it out of movable zone and get_page again.
That's exactly 

Re: [PATCHv5,RESEND 1/8] gpu: host1x: Add host1x driver

[Thierry Reding]

On Mon, Feb 04, 2013 at 07:30:08PM -0800, Terje Bergström wrote:
> On 04.02.2013 01:09, Thierry Reding wrote:
> > On Tue, Jan 15, 2013 at 01:43:57PM +0200, Terje Bergstrom wrote:
> >> Add host1x, the driver for host1x and its client unit 2D.
> > 
> > Maybe this could be a bit more verbose. Perhaps describe what host1x is.
> 
> Sure. I could just steal the paragraph from Stephen:
> 
> The Tegra host1x module is the DMA engine for register access to Tegra's
> graphics- and multimedia-related modules. The modules served by host1x
> are referred to as clients. host1x includes some other  functionality,
> such as synchronization.

Yes, that sound good.

> >> + err = host1x_syncpt_init(host);
> >> + if (err)
> >> + return err;
> > [...]
> >> + host1x_syncpt_reset(host);
> > 
> > Why separate host1x_syncpt_reset() from host1x_syncpt_init()? I see why
> > it might be useful to have host1x_syncpt_reset() as a separate function
> > but couldn't it be called as part of host1x_syncpt_init()?
> 
> host1x_syncpt_init() is used for initializing the syncpt structures, and
> is called in probe. host1x_syncpt_reset() should be called whenever we
> think hardware state is lost, for example if VDD_CORE was rail gated due
> to system suspend.

My point was that you could include the call to host1x_syncpt_reset()
within host1x_syncpt_init(). That will keep unneeded code out of the
host1x_probe() function. Also you don't want to use the syncpoints
uninitialized, right?

> >> +#include "hw/syncpt_hw.c"
> > 
> > Why include the source file here? Can't you compile it separately
> > instead?
> 
> It's because we need to compile with the hardware headers of that host1x
> version, because we haven't been good at keeping compatibility. So
> host1x01.c #includes version 01 headers, and syncpt_hw.c in this
> compilation unit gets compiled with that. 02 would include 02 headers,
> and syncpt_hw.c would get compiled with its register definitions etc.

Okay, fair enough.

> >> + */
> >> +static u32 syncpt_load_min(struct host1x_syncpt *sp)
> >> +{
> >> + struct host1x *dev = sp->dev;
> >> + u32 old, live;
> >> +
> >> + do {
> >> + old = host1x_syncpt_read_min(sp);
> >> + live = host1x_sync_readl(dev,
> >> + HOST1X_SYNC_SYNCPT_0 + sp->id * 4);
> >> + } while ((u32)atomic_cmpxchg(>min_val, old, live) != old);
> > 
> > I think this warrants a comment.
> 
> Sure. It just loops in case there's a race writing to min_val.

Oh, I see. That'd make a good comment. Is the cast to (u32) really
necessary?

> >> +/*
> >> + * Resets syncpoint and waitbase values to sw shadows
> >> + */
> >> +void host1x_syncpt_reset(struct host1x *dev)
> > 
> > Maybe host1x_syncpt_flush() would be a better name given the above
> > description? Reset does have this hardware reset connotation so my first
> > intuition had been that this would reset the syncpt value to 0.
> 
> Right, it actually reloads values stored in shadow registers back to
> host1x. Flush doesn't feel like it's conveying the meaning. Would
> host1x_syncpt_restore() work? That'd match with host1x_syncpt_save(),
> which just updates all shadow registers from hardware and is used just
> before host1x loses power.

Save/restore has the disadvantage of the direction not being implicit.
Save could mean save to hardware or save to software. The same is true
for restore. However if the direction is clearly defined, save and
restore work for me.

Maybe the comment could be changed to be more explicit. Something like:

/*
 * Write cached syncpoint and waitbase values to hardware.
 */

And for host1x_syncpt_save():

/*
 * For client-managed registers, update the cached syncpoint and
 * waitbase values by reading from the registers.
 */

> >> +/*
> >> + * Updates the last value read from hardware.
> >> + */
> >> +u32 host1x_syncpt_load_min(struct host1x_syncpt *sp)
> >> +{
> >> + u32 val;
> >> + val = sp->dev->syncpt_op.load_min(sp);
> >> + trace_host1x_syncpt_load_min(sp->id, val);
> >> +
> >> + return val;
> >> +}
> > 
> > I don't know I understand what this means exactly. Does it read the
> > value that hardware last incremented? Perhaps this will become clearer
> > when you add a comment to the syncpt_load_min() implementation.
> 
> It just loads the current syncpt value to shadow register. The shadow
> register is called min, because host1x tracks the range of sync point
> increments that hardware is still going to do, so min is the lower
> boundary of the range.
> 
> max tells what the sync point is expected to reach for hardware to be
> considered idle.
> 
> host1x will f.ex. nop out waits for sync point values outside the range,
> because hardware isn't good at handling syncpt value wrapping.

Maybe the function should be called host1x_syncpt_load() if there is no
equivalent way to load the maximum value (since there is no register to
read 

Re: [Intel-gfx] [PATCH V2 3/3] i915: ignore lid open event when resuming

[Zhang Rui]

On Tue, 2013-02-05 at 07:58 +0800, Zhang Rui wrote:
> On Mon, 2013-02-04 at 16:25 +0100, Daniel Vetter wrote:
> > On Mon, Feb 04, 2013 at 03:10:11PM +0800, Zhang Rui wrote:
> > > i915 driver needs to do modeset when
> > > 1. system resumes from sleep
> > > 2. lid is opened
> > > 
> > > In PM_SUSPEND_MEM state, all the GPEs are cleared when system resumes,
> > > thus it is the i915_resume code does the modeset rather than 
> > > intel_lid_notify().
> > > 
> > > But in PM_SUSPEND_FREEZE state, this will be broken because
> > > system is still responsive to the lid events.
> > > 1. When we close the lid in Freeze state, intel_lid_notify() sets 
> > > modeset_on_lid.
> > > 2. When we reopen the lid, intel_lid_notify() will do a modeset,
> > >before the system is resumed.
> > > here is the error log,
> > > 
> > > [92146.548074] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 
> > > intel_wait_for_pipe_off+0x184/0x190 [i915]()
> > > [92146.548076] Hardware name: VGN-Z540N
> > > [92146.548078] pipe_off wait timed out
> > > [92146.548167] Modules linked in: hid_generic usbhid hid 
> > > snd_hda_codec_realtek snd_hda_intel snd_hda_codec parport_pc snd_hwdep 
> > > ppdev snd_pcm_oss i915 snd_mixer_oss snd_pcm arc4 iwldvm snd_seq_dummy 
> > > mac80211 snd_seq_oss snd_seq_midi fbcon tileblit font bitblit softcursor 
> > > drm_kms_helper snd_rawmidi snd_seq_midi_event coretemp drm snd_seq kvm 
> > > btusb bluetooth snd_timer iwlwifi pcmcia tpm_infineon i2c_algo_bit joydev 
> > > snd_seq_device intel_agp cfg80211 snd intel_gtt yenta_socket pcmcia_rsrc 
> > > sony_laptop agpgart microcode psmouse tpm_tis serio_raw mxm_wmi soundcore 
> > > snd_page_alloc tpm acpi_cpufreq lpc_ich pcmcia_core tpm_bios mperf 
> > > processor lp parport firewire_ohci firewire_core crc_itu_t sdhci_pci 
> > > sdhci thermal e1000e
> > > [92146.548173] Pid: 4304, comm: kworker/0:0 Tainted: GW
> > > 3.8.0-rc3-s0i3-v3-test+ #9
> > > [92146.548175] Call Trace:
> > > [92146.548189]  [] warn_slowpath_common+0x72/0xa0
> > > [92146.548227]  [] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
> > > [92146.548263]  [] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
> > > [92146.548270]  [] warn_slowpath_fmt+0x33/0x40
> > > [92146.548307]  [] intel_wait_for_pipe_off+0x184/0x190 [i915]
> > > [92146.548344]  [] intel_disable_pipe+0x102/0x190 [i915]
> > > [92146.548380]  [] ? intel_disable_plane+0x64/0x80 [i915]
> > > [92146.548417]  [] i9xx_crtc_disable+0xbc/0x150 [i915]
> > > [92146.548456]  [] intel_crtc_update_dpms+0x5e/0x90 [i915]
> > > [92146.548493]  [] intel_modeset_setup_hw_state+0x42f/0x8f0 
> > > [i915]
> > > [92146.548535]  [] intel_lid_notify+0x9b/0xc0 [i915]
> > > [92146.548543]  [] notifier_call_chain+0x43/0x60
> > > [92146.548550]  [] __blocking_notifier_call_chain+0x41/0x80
> > > [92146.548556]  [] blocking_notifier_call_chain+0x1f/0x30
> > > [92146.548563]  [] acpi_lid_send_state+0x78/0xa4
> > > [92146.548569]  [] acpi_button_notify+0x3b/0xf1
> > > [92146.548577]  [] ? acpi_os_execute+0x17/0x19
> > > [92146.548582]  [] ? acpi_ec_sync_query+0xa5/0xbc
> > > [92146.548589]  [] acpi_device_notify+0x16/0x18
> > > [92146.548595]  [] acpi_ev_notify_dispatch+0x38/0x4f
> > > [92146.548600]  [] acpi_os_execute_deferred+0x20/0x2b
> > > [92146.548607]  [] process_one_work+0x128/0x3f0
> > > [92146.548613]  [] ? common_interrupt+0x33/0x38
> > > [92146.548618]  [] ? wake_up_worker+0x30/0x30
> > > [92146.548624]  [] ? acpi_os_wait_events_complete+0x1e/0x1e
> > > [92146.548629]  [] worker_thread+0x119/0x3b0
> > > [92146.548634]  [] ? manage_workers+0x240/0x240
> > > [92146.548640]  [] kthread+0x94/0xa0
> > > [92146.548647]  [] ? 
> > > ftrace_raw_output_sched_stat_runtime+0x70/0xf0
> > > [92146.548652]  [] ret_from_kernel_thread+0x1b/0x28
> > > [92146.548658]  [] ? kthread_create_on_node+0xc0/0xc0
> > > 
> > > three different modeset flags are introduced in this patch
> > > MODESET_ON_LID: do modeset on next lid open event
> > > MODESET_DONE:  modeset already done
> > > MODESET_ON_RESUME:  do modeset when system is resumed
> > > 
> > > In this way,
> > > 1. when lid is closed, MODESET_ON_LID is set so that
> > >we'll do modeset on next lid open event.
> > > 2. when lid is opened, MODESET_DONE is set
> > >so that duplicate lid open events will be ignored.
> > > 3. when system suspends, MODESET_ON_RESUME is set.
> > >In this case, we will not do modeset on any lid events.
> > > 
> > > Plus, locking mechanism is also introduced to avoid racing.
> > > 
> > > Signed-off-by: Zhang Rui 
> > 
> > Looks nice, two tiny bikesheds below.
> > 
> Great, thanks for reviewing. Refreshed patch attached.

oops, forgot to update the changelog and comments.
refreshed patch attached.

>From b584fcebb6d715a317f192c88606b875ee88ce78 Mon Sep 17 00:00:00 2001
From: Zhang Rui 
Date: Thu, 24 Jan 2013 13:27:22 +0800
Subject: [PATCH V3 3/3] i915: ignore lid open event when resuming

i915 driver needs to do modeset when
1. system resumes from sleep
2. lid is 

[PATCH v3 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c

[liguang]

srat table should present only on acpi domain,
seems mm/ is not the right place for it.

Signed-off-by: liguang 
---
 arch/x86/kernel/acpi/Makefile |1 +
 arch/x86/kernel/acpi/srat.c   |  198 +
 arch/x86/mm/Makefile  |1 -
 arch/x86/mm/srat.c|  198 -
 4 files changed, 199 insertions(+), 199 deletions(-)
 create mode 100644 arch/x86/kernel/acpi/srat.c
 delete mode 100644 arch/x86/mm/srat.c

diff --git a/arch/x86/kernel/acpi/Makefile b/arch/x86/kernel/acpi/Makefile
index 163b225..98cea92 100644
--- a/arch/x86/kernel/acpi/Makefile
+++ b/arch/x86/kernel/acpi/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_ACPI) += boot.o
 obj-$(CONFIG_ACPI_SLEEP)   += sleep.o wakeup_$(BITS).o
+obj-$(CONFIG_ACPI_NUMA)+= srat.o
 
 ifneq ($(CONFIG_ACPI_PROCESSOR),)
 obj-y  += cstate.o
diff --git a/arch/x86/kernel/acpi/srat.c b/arch/x86/kernel/acpi/srat.c
new file mode 100644
index 000..cdd0da9
--- /dev/null
+++ b/arch/x86/kernel/acpi/srat.c
@@ -0,0 +1,198 @@
+/*
+ * ACPI 3.0 based NUMA setup
+ * Copyright 2004 Andi Kleen, SuSE Labs.
+ *
+ * Reads the ACPI SRAT table to figure out what memory belongs to which CPUs.
+ *
+ * Called from acpi_numa_init while reading the SRAT and SLIT tables.
+ * Assumes all memory regions belonging to a single proximity domain
+ * are in one chunk. Holes between them will be included in the node.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int acpi_numa __initdata;
+
+static __init int setup_node(int pxm)
+{
+   return acpi_map_pxm_to_node(pxm);
+}
+
+static __init void bad_srat(void)
+{
+   printk(KERN_ERR "SRAT: SRAT not used.\n");
+   acpi_numa = -1;
+}
+
+static __init inline int srat_disabled(void)
+{
+   return acpi_numa < 0;
+}
+
+/* Callback for SLIT parsing */
+void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
+{
+   int i, j;
+
+   for (i = 0; i < slit->locality_count; i++)
+   for (j = 0; j < slit->locality_count; j++)
+   numa_set_distance(pxm_to_node(i), pxm_to_node(j),
+   slit->entry[slit->locality_count * i + j]);
+}
+
+/* Callback for Proximity Domain -> x2APIC mapping */
+void __init
+acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
+{
+   int pxm, node;
+   int apic_id;
+
+   if (srat_disabled())
+   return;
+   if (pa->header.length < sizeof(struct acpi_srat_x2apic_cpu_affinity)) {
+   bad_srat();
+   return;
+   }
+   if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0)
+   return;
+   pxm = pa->proximity_domain;
+   apic_id = pa->apic_id;
+   if (!apic->apic_id_valid(apic_id)) {
+   printk(KERN_INFO "SRAT: PXM %u -> X2APIC 0x%04x ignored\n",
+pxm, apic_id);
+   return;
+   }
+   node = setup_node(pxm);
+   if (node < 0) {
+   printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
+   bad_srat();
+   return;
+   }
+
+   if (apic_id >= MAX_LOCAL_APIC) {
+   printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u 
skipped apicid that is too big\n", pxm, apic_id, node);
+   return;
+   }
+   set_apicid_to_node(apic_id, node);
+   node_set(node, numa_nodes_parsed);
+   acpi_numa = 1;
+   printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u\n",
+  pxm, apic_id, node);
+}
+
+/* Callback for Proximity Domain -> LAPIC mapping */
+void __init
+acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
+{
+   int pxm, node;
+   int apic_id;
+
+   if (srat_disabled())
+   return;
+   if (pa->header.length != sizeof(struct acpi_srat_cpu_affinity)) {
+   bad_srat();
+   return;
+   }
+   if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0)
+   return;
+   pxm = pa->proximity_domain_lo;
+   if (acpi_srat_revision >= 2)
+   pxm |= *((unsigned int*)pa->proximity_domain_hi) << 8;
+   node = setup_node(pxm);
+   if (node < 0) {
+   printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
+   bad_srat();
+   return;
+   }
+
+   if (get_uv_system_type() >= UV_X2APIC)
+   apic_id = (pa->apic_id << 8) | pa->local_sapic_eid;
+   else
+   apic_id = pa->apic_id;
+
+   if (apic_id >= MAX_LOCAL_APIC) {
+   printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u 
skipped apicid that is too big\n", pxm, apic_id, node);
+   return;
+   }
+
+   set_apicid_to_node(apic_id, node);
+   node_set(node, numa_nodes_parsed);
+   acpi_numa = 1;
+   printk(KERN_INFO 

[PATCH v3 2/4] numa: avoid export acpi_numa variable

[liguang]

acpi_numa is used to prevent srat table
being parsed, seems a little miss-named,
if 'noacpi' was specified by cmdline and
CONFIG_ACPI_NUMA was enabled, acpi_numa
will be operated directly from everywhere
it needed to disable/enable numa in acpi
mode which was a bad thing, so, try to
export a fuction to get srat table
enable/disable info.

Signed-off-by: liguang 
---
 arch/x86/include/asm/acpi.h |2 +-
 arch/x86/kernel/acpi/srat.c |   17 +++--
 arch/x86/mm/numa.c  |2 +-
 arch/x86/xen/enlighten.c|2 +-
 4 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index b31bf97..449e12a 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -177,7 +177,7 @@ static inline void disable_acpi(void) { }
 #define ARCH_HAS_POWER_INIT1
 
 #ifdef CONFIG_ACPI_NUMA
-extern int acpi_numa;
+extern void disable_acpi_numa(void);
 extern int x86_acpi_numa_init(void);
 #endif /* CONFIG_ACPI_NUMA */
 
diff --git a/arch/x86/kernel/acpi/srat.c b/arch/x86/kernel/acpi/srat.c
index cdd0da9..8d7f3f8 100644
--- a/arch/x86/kernel/acpi/srat.c
+++ b/arch/x86/kernel/acpi/srat.c
@@ -24,22 +24,27 @@
 #include 
 #include 
 
-int acpi_numa __initdata;
+static bool acpi_numa __initdata;
 
 static __init int setup_node(int pxm)
 {
return acpi_map_pxm_to_node(pxm);
 }
 
-static __init void bad_srat(void)
+void __init disable_acpi_numa(void)
 {
-   printk(KERN_ERR "SRAT: SRAT not used.\n");
-   acpi_numa = -1;
+   acpi_numa = false;
 }
 
-static __init inline int srat_disabled(void)
+static void __init bad_srat(void)
 {
-   return acpi_numa < 0;
+   disable_acpi_numa();
+   printk(KERN_ERR "SRAT: SRAT will not be used.\n");
+}
+
+static bool __init srat_disabled(void)
+{
+   return acpi_numa;
 }
 
 /* Callback for SLIT parsing */
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 245a4ba..1ebc907 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -47,7 +47,7 @@ static __init int numa_setup(char *opt)
 #endif
 #ifdef CONFIG_ACPI_NUMA
if (!strncmp(opt, "noacpi", 6))
-   acpi_numa = -1;
+   disable_acpi_numa();
 #endif
return 0;
 }
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 657eca9..3636bc6 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1447,7 +1447,7 @@ asmlinkage void __init xen_start_kernel(void)
 * any NUMA information the kernel tries to get from ACPI will
 * be meaningless.  Prevent it from trying.
 */
-   acpi_numa = -1;
+   disable_acpi_numa();
 #endif
 
/* Don't do the full vcpu_info placement stuff until we have a
-- 
1.7.2.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 4/4] remove include asm/acpi.h in process_driver.c

[liguang]

process_driver.c include linux/acpi.h which already
include asm/acpi.h, so remove it.

Reviewed-by: Yasuaki Ishimatsu 
Acked-by: David Rientjes 
Signed-off-by: liguang 
---
 drivers/acpi/processor_driver.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index d57e32c..2f3bc09 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -53,7 +53,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
-- 
1.7.2.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/4] acpi: add clock_domain field to acpi_srat_cpu_affinity

[liguang]

according to ACPI SPEC v5.0, page 152,
5.2.16.1 Processor Local APIC/SAPIC Affinity Structure,
the last member of it is clock_domain.

Reviewed-by: Yasuaki Ishimatsu 
Acked-by: David Rientjes 
Signed-off-by: liguang 
---
 include/acpi/actbl1.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index 0bd750e..e21d22b 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -922,7 +922,7 @@ struct acpi_srat_cpu_affinity {
u32 flags;
u8 local_sapic_eid;
u8 proximity_domain_hi[3];
-   u32 reserved;   /* Reserved, must be zero */
+   u32 clock_domain;
 };
 
 /* Flags */
-- 
1.7.2.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 0/4] acpi: do some changes for numa info

[liguang]

just do some trivial changes to make acpi's numa info
operation more cleaner.

ChangeLog

v2->v3
 1. rebase on linux-next
 2. bring back lost Makefile changes
 spotted by David Rientjes 
 spotted by Yasuaki Ishimatsu 

v1->v2
 1. fix-up several coding issues
 2. finish srat.c change
 spotted by David Rientjes 

Li Guang(4)
numa: avoid export acpi_numa variable
acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c
acpi: add clock_domain field to acpi_srat_cpu_affinity
remove include asm/acpi.h in process_driver.c

 arch/x86/include/asm/acpi.h|2 +-
 arch/x86/kernel/acpi/Makefile  |1 +
 arch/x86/kernel/acpi/srat.c|  212 
+++---
 arch/x86/mm/Makefile   |1 -
 arch/x86/mm/srat.c |  198 
---
 arch/x86/mm/numa.c |2 +-
 arch/x86/xen/enlighten.c   |2 +-
 include/acpi/actbl1.h  |2 +-
 drivers/acpi/processor_driver.c|1 -

 9 files changed, 212 insertions(+), 208 deletions(-)
 create mode 100644 arch/x86/kernel/acpi/srat.c
 delete mode 100644 arch/x86/mm/srat.c

 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: cma: fix accounting of CMA pages placed in high memory

[Minchan Kim]

Hi Marek,

On Tue, Feb 05, 2013 at 08:10:19AM +0100, Marek Szyprowski wrote:
> Hello,
> 
> On 2/5/2013 12:34 AM, Minchan Kim wrote:
> >On Mon, Feb 04, 2013 at 11:27:05AM +0100, Marek Szyprowski wrote:
> >> The total number of low memory pages is determined as
> >> totalram_pages - totalhigh_pages, so without this patch all CMA
> >> pageblocks placed in highmem were accounted to low memory.
> >
> >So what's the end user effect? With the effect, we have to decide
> >routing it on stable.
> >
> >>
> >> Signed-off-by: Marek Szyprowski 
> >> ---
> >>  mm/page_alloc.c |4 
> >>  1 file changed, 4 insertions(+)
> >>
> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> >> index f5bab0a..6415d93 100644
> >> --- a/mm/page_alloc.c
> >> +++ b/mm/page_alloc.c
> >> @@ -773,6 +773,10 @@ void __init init_cma_reserved_pageblock(struct page 
> >> *page)
> >>set_pageblock_migratetype(page, MIGRATE_CMA);
> >>__free_pages(page, pageblock_order);
> >>totalram_pages += pageblock_nr_pages;
> >> +#ifdef CONFIG_HIGHMEM
> >
> >We don't need #ifdef/#endif.
> 
> #ifdef is required to let this code compile when highmem is not enabled,
> becuase totalhigh_pages is defined as 0, see include/linux/highmem.h

Argh, Sorry for the noise.
I think it would be better to use accessor but it's a just nitpick. :)
Thanks!

> 
> >> +  if (PageHighMem(page))
> >> +  totalhigh_pages += pageblock_nr_pages;
> >> +#endif
> >>  }
> >>  #endif
> >>
> 
> Best regards
> -- 
> Marek Szyprowski
> Samsung Poland R Center
> 
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] 3.6.11-rt26

[Qiang Huang]

On 2013/2/4 22:58, Thomas Gleixner wrote:
> Dear RT Folks,
> 
> I'm pleased to announce the 3.6.11-rt26 release.
> 
> Changes since 3.6.11-rt25:
> 
>1) Fix the RT highmem implementation on x86

Hi Thomas,

>From patches-3.6.11-rt28.patch.gz, your patch x86-highmem-make-it-work.patch
did this work. And you said
"It had been enabled quite some time, but never really worked."

But I think there is a previous patch mm-rt-kmap-atomic-scheduling.patch did
the job, so I think RT highmem on x86 should have worked.

Now with your patch, if we use kmap instead of kmap_atomic on RT, do we need
to revert Peter's patch as well?

I haven't tested it, but if Peter's patch did solved the problem, is his way
better than use kmap? Because we can use more highmem virtual address,
although with some switch latency in some small probability scenarios.

> 
>2) Support highmem + RT on ARM
> 
>3) Fix an one off error in the generic highmem code (upstream fix
>   did not make it into 3.6.stable)
> 
>4) Upstream SLUB fixes (Christoph Lameter)
> 
>5) Fix a few RT issues in mmc and amba drivers
> 
>6) Initialize local locks in mm/swap.c early
> 
>7) Use simple wait queues for completions. This is a performance
>   improvement.
> 
>   Completions do not have complex callbacks and the wakeup path is
>   disabling interrupts anyway. So using simple wait locks with the
>   raw spinlock is not a latency problem, but the "sleeping lock"
>   in the normal waitqueue is a source for lock bouncing:
> 
>   T1 T2
>   lock(WQ)
>   wakeup(T2)
>   ---> preemption
>  lock(WQ)
>  pi_boost(T1)
>  wait_for_lock(WQ)
>   unlock(WQ)
>   deboost(T1)
>   ---> preemption
>  
> 
>   The simple waitqueue reduces this to:
>  
>   T1 T2
>   raw_lock(WQ)
>   wakeup(T2)
>   raw_unlock(WQ)
>   ---> preemption
>  raw_lock(WQ) 
>  
> 
> @Steven: Sorry, I forgot the stable tags on:
>drivers-tty-pl011-irq-disable-madness.patch
>mmci-remove-bogus-irq-save.patch
>idle-state.patch
>might-sleep-check-for-idle.patch
>mm-swap-fix-initialization.patch
> 
> I'm still digging through my mail backlog, so I have not yet decided
> whether this is the last RT release for 3.6.
> 
> 
> The delta patch against 3.6.11-rt25 is appended below and can be found
> here:
> 
>   
> http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/incr/patch-3.6.11-rt25-rt26.patch.xz
> 
> The RT patch against 3.6.11 can be found here:
> 
>   
> http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patch-3.6.11-rt26.patch.xz
> 
> The split quilt queue is available at:
> 
>   
> http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patches-3.6.11-rt26.tar.xz
> 
> Enjoy,
> 
>   tglx
> 


--
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/3] KVM: MMU: cleanup __direct_map

[Xiao Guangrong]

Use link_shadow_page to link the sp to the spte in __direct_map

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mmu.c |   12 
 1 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 2112c1b..8041454 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1961,9 +1961,9 @@ static void link_shadow_page(u64 *sptep, struct 
kvm_mmu_page *sp)
 {
u64 spte;

-   spte = __pa(sp->spt)
-   | PT_PRESENT_MASK | PT_ACCESSED_MASK
-   | PT_WRITABLE_MASK | PT_USER_MASK;
+   spte = __pa(sp->spt) | PT_PRESENT_MASK | PT_WRITABLE_MASK |
+  shadow_user_mask | shadow_x_mask | shadow_accessed_mask;
+
mmu_spte_set(sptep, spte);
 }

@@ -2607,11 +2607,7 @@ static int __direct_map(struct kvm_vcpu *vcpu, gpa_t v, 
int write,
  iterator.level - 1,
  1, ACC_ALL, iterator.sptep);

-   mmu_spte_set(iterator.sptep,
-__pa(sp->spt)
-| PT_PRESENT_MASK | PT_WRITABLE_MASK
-| shadow_user_mask | shadow_x_mask
-| shadow_accessed_mask);
+   link_shadow_page(iterator.sptep, sp);
}
}
return emulate;
-- 
1.7.7.6

--
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 2/3] KVM: MMU: remove pt_access in mmu_set_spte

[Xiao Guangrong]

It is only used in debug code, so drop it

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mmu.c |   17 +++--
 arch/x86/kvm/paging_tmpl.h |9 -
 2 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index fe877da..2112c1b 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2403,16 +2403,15 @@ done:
 }

 static void mmu_set_spte(struct kvm_vcpu *vcpu, u64 *sptep,
-unsigned pt_access, unsigned pte_access,
-int write_fault, int *emulate, int level, gfn_t gfn,
-pfn_t pfn, bool speculative, bool host_writable)
+unsigned pte_access, int write_fault, int *emulate,
+int level, gfn_t gfn, pfn_t pfn, bool speculative,
+bool host_writable)
 {
int was_rmapped = 0;
int rmap_count;

-   pgprintk("%s: spte %llx access %x write_fault %d gfn %llx\n",
-__func__, *sptep, pt_access,
-write_fault, gfn);
+   pgprintk("%s: spte %llx write_fault %d gfn %llx\n", __func__,
+*sptep, write_fault, gfn);

if (is_rmap_spte(*sptep)) {
/*
@@ -2528,7 +2527,7 @@ static int direct_pte_prefetch_many(struct kvm_vcpu *vcpu,
return -1;

for (i = 0; i < ret; i++, gfn++, start++)
-   mmu_set_spte(vcpu, start, ACC_ALL, access, 0, NULL,
+   mmu_set_spte(vcpu, start, access, 0, NULL,
 sp->role.level, gfn, page_to_pfn(pages[i]),
 true, true);

@@ -2589,9 +2588,7 @@ static int __direct_map(struct kvm_vcpu *vcpu, gpa_t v, 
int write,

for_each_shadow_entry(vcpu, (u64)gfn << PAGE_SHIFT, iterator) {
if (iterator.level == level) {
-   unsigned pte_access = ACC_ALL;
-
-   mmu_set_spte(vcpu, iterator.sptep, ACC_ALL, pte_access,
+   mmu_set_spte(vcpu, iterator.sptep, ACC_ALL,
 write, , level, gfn, pfn,
 prefault, map_writable);
direct_pte_prefetch(vcpu, iterator.sptep);
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 34c5c99..105dd5b 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -326,8 +326,8 @@ FNAME(prefetch_gpte)(struct kvm_vcpu *vcpu, struct 
kvm_mmu_page *sp,
 * we call mmu_set_spte() with host_writable = true because
 * pte_prefetch_gfn_to_pfn always gets a writable pfn.
 */
-   mmu_set_spte(vcpu, spte, sp->role.access, pte_access, 0,
-NULL, PT_PAGE_TABLE_LEVEL, gfn, pfn, true, true);
+   mmu_set_spte(vcpu, spte, pte_access, 0, NULL, PT_PAGE_TABLE_LEVEL,
+gfn, pfn, true, true);

return true;
 }
@@ -470,9 +470,8 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gva_t addr,
}

clear_sp_write_flooding_count(it.sptep);
-   mmu_set_spte(vcpu, it.sptep, access, gw->pte_access,
-write_fault, , it.level,
-gw->gfn, pfn, prefault, map_writable);
+   mmu_set_spte(vcpu, it.sptep, gw->pte_access, write_fault, ,
+it.level, gw->gfn, pfn, prefault, map_writable);
FNAME(pte_prefetch)(vcpu, gw, it.sptep);

return emulate;
-- 
1.7.7.6

--
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 1/3] KVM: MMU: cleanup mapping-level

[Xiao Guangrong]

Use min() to cleanup mapping_level

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mmu.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ff2fc80..fe877da 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -832,8 +832,7 @@ static int mapping_level(struct kvm_vcpu *vcpu, gfn_t 
large_gfn)
if (host_level == PT_PAGE_TABLE_LEVEL)
return host_level;

-   max_level = kvm_x86_ops->get_lpage_level() < host_level ?
-   kvm_x86_ops->get_lpage_level() : host_level;
+   max_level = min(kvm_x86_ops->get_lpage_level(), host_level);

for (level = PT_DIRECTORY_LEVEL; level <= max_level; ++level)
if (has_wrprotected_page(vcpu->kvm, large_gfn, level))
-- 
1.7.7.6

--
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 0/3] KVM: MMU: simple cleanups

[Xiao Guangrong]

There are the simple cleanups for MMU, no function / logic changed.

Marcelo, Gleb, please apply them after applying
"[PATCH v3] KVM: MMU: lazily drop large spte"

Changelog:
no change, just split them from the previous patchset for good review.

Thanks!

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re:[PATCH] sched/rt: Decrease number of calls of push_rt_task() in push_rt_tasks()

[Kirill Tkhai]

> On 2013/2/1 5:57, Kirill Tkhai wrote:
> 
>> 31.01.2013, 20:08, "Steven Rostedt" :
>>
>>> On Mon, 2013-01-28 at 03:46 +0400, Kirill Tkhai wrote:
>>>
 The patch aims to decrease the number of calls of push_rt_task()
 in push_rt_tasks().

 It's not necessary to push more than 'num_online_cpus() - 1' tasks.
 If just pushed task doesn't leave its new CPU during our local call
 of push_rt_tasks() than we won't push another task to the CPU.
 If it leave or change priority than it will pull new task by itself.
>>>
>>> I'm curious. Have you hit situations where this was an issue? Or was
>>> this just discovered by code review?
>>
>> No, I did't hit this situation. It's impossible to hook every situation.
>>
>> Thanks for your explanation.
>>
>> Kirill
> 
> Suppose we have a large number of cpus(say 4096), with the last one running
> a low-priority task on it. Is it possible with this patch we will never reach
> the last cpu in case that previous cpu has complete the pulled task?

Yes. But this patch is about several pushable tasks on the same cpu.

Kirill

 -- 
--
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/4] CPUFreq: Implement per policy instances of governors

[Viresh Kumar]

On Mon, Feb 4, 2013 at 10:20 PM, Borislav Petkov  wrote:
> On Mon, Feb 04, 2013 at 09:07:11PM +0530, Viresh Kumar wrote:
>> └── ondemand
>> ├── sampling_rate
>> ├── up_threshold
>> └── ignore_nice
>
> So this is adding the current governor as a per-cpu thing.

Its per policy, but yes it is replicated into all cpus as all policy->cpus
share the same directory.

>> > One thing I've come to realize with the current interface is that if
>> > you want to change stuff, you need to iterate over all cpus instead of
>> > writing to a system-wide node.
>>
>> Not really. Following is the way by which cpu/cpu*/cpufreq directories
>> are created:
>
> That's not what I meant - I meant from userspace:
>
> for $i in $(grep processor /proc/cpuinfo | awk '{ print $3 }');
> do
> echo "performance" > 
> /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor;
> done
>
> Instead of
>
> echo "performance" > /sys/devices/system/cpu/cpufreq/scaling_governor
>
> which is hypothetical but sets it for the whole system without fuss.

We actually need to do this only for policy->cpu, but yes the user might not
be well aware of policy cpu-groups and may do what you wrote.

But that is true even today, when we need to change any policy tunables or
P-states.

>> I want to control it over clock-domain, but can't get that in cpu/cpufreq/.
>> Policies don't have numbers assigned to them.
>
> So, give them names.

IMHO, names doesn't suit policies.

>> So, i am working on ARM's big.LITTLE system where we have two
>> clusters. One of A15s and other of A7s. Because of their different
>> power ratings or performance figures, we need to have separate set of
>> ondemand tunables for them. And hence this patch. Though this patch is
>> required for any multi-cluster system.
>
> So you want this (values after "="):
>
> cpu/cpufreq/
> |-> policy0
> |-> name= A15
> |-> min_freq= ...
> |-> max_freq= ...
> |-> affected_cpus   = 0,1,2,...
> |-> ondemand
> |-> sampling_rate
> |-> up_threshold
> |-> ignore_nice
> ...
> |-> policy1
> |-> name= A7
> |-> min_freq= ...
> |-> max_freq= ...
> |-> affected_cpus   = n,n+1,n+2,...
> |-> performance
> |-> sampling_rate
> |-> up_threshold
> |-> ignore_nice
> ...

We may have two clusters of A7's also, in a non-big little arch. Then
these names become very confusing.

> Other arches create other policies and that's it. If you need another
> policy added to the set, you simply add 'policyN++' and that's it.

For me, adding policy->names per arch is increasing complexity without
much gain. We already have an existing infrastructure where this info
is present inside cpus and that looks good to me.

> I think this is cleaner but whatever - I don't care that much. My
> only strong concern is that this thing should be a Kconfig option and
> optional for arches where it doesn't apply.

Your concern is: we don't want to fix userspace for existing platforms
where we have just a single cluster and so struct policy in the system.

so, a good solution instead of Kconfig stuff is, add another field in policy
structure that would be filled by platform specific cpufreq drivers init()
routine. Based on which we can decide to put governor directory in
cpu/cpufreq/gov-name or cpu/cpu*/cpufreq/gov-name.

But i am not sure if keeping both kind of directory locations for separate
platforms is a good idea. Userspace needs to adapt to these changes as
well for multi-cluster platforms.

@Rafael: you know about any other multi-cluster/multi-clock-domain
platform leaving big.LITTLE, where we have multiple structs policy?
--
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 10/18] mm: teach truncate_inode_pages_range() to handle non page aligned ranges

[Lukáš Czerner]

On Mon, 4 Feb 2013, Andrew Morton wrote:

> Date: Mon, 4 Feb 2013 12:51:36 -0800
> From: Andrew Morton 
> To: Lukáš Czerner 
> Cc: linux...@kvack.org, linux-kernel@vger.kernel.org,
> linux-fsde...@vger.kernel.org, linux-e...@vger.kernel.org,
> x...@oss.sgi.com, Hugh Dickins 
> Subject: Re: [PATCH 10/18] mm: teach truncate_inode_pages_range() to handle
> non page aligned ranges
> 
> On Mon, 4 Feb 2013 15:51:19 +0100 (CET)
> Luk Czerner  wrote:
> 
> > I hope I explained myself well enough :). Are you ok with this king
> > of approach ? If so, I'll resend the patch set without the
> > initialisation-at-declaration.
> 
> uh, maybe.  Next time I'll apply the patch and look at the end result! 
> Try to make it as understandable and (hence) maintainable as possible,
> OK?

Agreed.

Thanks!
-Lukas

Re: [PATCH] f2fs: add compat_ioctl to provide backward compatability

[Jaegeuk Kim]

2013-02-05 (화), 16:02 +0900, Namjae Jeon:
> 2013/2/5, Jaegeuk Kim :
> > Hi,
> >
> > 2013-02-05 (화), 14:28 +0900, Namjae Jeon:
> >> Hi Jaegeuk.
> >>
> >> Oops!, I was missing include header.
> >> Sorry, I will send v2 patch again.
> >
> > I got a build error, and simply added the following header file in your
> > patch.
> >
> > #include 
> >
> > Is it correct?
> Yes, Right :) It should be needed.
> Sorry for my mistake again. Could you add this header instead of me
> ?(because I can resend the patch tonight).

No problem. I've already done it. :)
Thanks,

> 
> Thanks!
> >
> > Thanks,
> >
> >>
> >> Thanks.
> >>
> >> 2013/2/4, Namjae Jeon :
> >> > From: Namjae Jeon 
> >> >
> >> > adding compat_ioctl to provide support for backward comptability -
> >> > 32bit
> >> > binary
> >> > execution on 64bit kernel.
> >> >
> >> > Signed-off-by: Namjae Jeon 
> >> > Signed-off-by: Amit Sahrawat 
> >> > ---
> >> >  fs/f2fs/f2fs.h |   15 +++
> >> >  fs/f2fs/file.c |   20 
> >> >  2 files changed, 35 insertions(+)
> >> >
> >> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> >> > index 58dd608..7bf86c8 100644
> >> > --- a/fs/f2fs/f2fs.h
> >> > +++ b/fs/f2fs/f2fs.h
> >> > @@ -104,6 +104,20 @@ static inline int update_sits_in_cursum(struct
> >> > f2fs_summary_block *rs, int i)
> >> >  }
> >> >
> >> >  /*
> >> > + * ioctl commands
> >> > + */
> >> > +#define F2FS_IOC_GETFLAGS   FS_IOC_GETFLAGS
> >> > +#define F2FS_IOC_SETFLAGS   FS_IOC_SETFLAGS
> >> > +
> >> > +#if defined(__KERNEL__) && defined(CONFIG_COMPAT)
> >> > +/*
> >> > + * ioctl commands in 32 bit emulation
> >> > + */
> >> > +#define F2FS_IOC32_GETFLAGS FS_IOC32_GETFLAGS
> >> > +#define F2FS_IOC32_SETFLAGS FS_IOC32_SETFLAGS
> >> > +#endif
> >> > +
> >> > +/*
> >> >   * For INODE and NODE manager
> >> >   */
> >> >  #define XATTR_NODE_OFFSET   (-1)/*
> >> > @@ -850,6 +864,7 @@ void f2fs_truncate(struct inode *);
> >> >  int f2fs_setattr(struct dentry *, struct iattr *);
> >> >  int truncate_hole(struct inode *, pgoff_t, pgoff_t);
> >> >  long f2fs_ioctl(struct file *, unsigned int, unsigned long);
> >> > +long f2fs_compat_ioctl(struct file *, unsigned int, unsigned long);
> >> >
> >> >  /*
> >> >   * inode.c
> >> > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> >> > index 633667e..e79d26a 100644
> >> > --- a/fs/f2fs/file.c
> >> > +++ b/fs/f2fs/file.c
> >> > @@ -644,6 +644,23 @@ out:
> >> >  }
> >> >  }
> >> >
> >> > +#ifdef CONFIG_COMPAT
> >> > +long f2fs_compat_ioctl(struct file *file, unsigned int cmd, unsigned
> >> > long
> >> > arg)
> >> > +{
> >> > +switch (cmd) {
> >> > +case F2FS_IOC32_GETFLAGS:
> >> > +cmd = F2FS_IOC_GETFLAGS;
> >> > +break;
> >> > +case F2FS_IOC32_SETFLAGS:
> >> > +cmd = F2FS_IOC_SETFLAGS;
> >> > +break;
> >> > +default:
> >> > +return -ENOIOCTLCMD;
> >> > +}
> >> > +return f2fs_ioctl(file, cmd, (unsigned long) compat_ptr(arg));
> >> > +}
> >> > +#endif
> >> > +
> >> >  const struct file_operations f2fs_file_operations = {
> >> >  .llseek = generic_file_llseek,
> >> >  .read   = do_sync_read,
> >> > @@ -655,6 +672,9 @@ const struct file_operations f2fs_file_operations =
> >> > {
> >> >  .fsync  = f2fs_sync_file,
> >> >  .fallocate  = f2fs_fallocate,
> >> >  .unlocked_ioctl = f2fs_ioctl,
> >> > +#ifdef CONFIG_COMPAT
> >> > +.compat_ioctl   = f2fs_compat_ioctl,
> >> > +#endif
> >> >  .splice_read= generic_file_splice_read,
> >> >  .splice_write   = generic_file_splice_write,
> >> >  };
> >> > --
> >> > 1.7.9.5
> >> >
> >> >
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"
> >> in
> >> the body of a message to majord...@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> > --
> > Jaegeuk Kim
> > Samsung
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Jaegeuk Kim
Samsung


signature.asc
Description: This is a digitally signed message part

Re: [PATCH] f2fs: add compat_ioctl to provide backward compatability

[Namjae Jeon]

2013/2/5, Namjae Jeon :
> 2013/2/5, Jaegeuk Kim :
>> Hi,
>>
>> 2013-02-05 (화), 14:28 +0900, Namjae Jeon:
>>> Hi Jaegeuk.
>>>
>>> Oops!, I was missing include header.
>>> Sorry, I will send v2 patch again.
>>
>> I got a build error, and simply added the following header file in your
>> patch.
>>
>> #include 
>>
>> Is it correct?
> Yes, Right :) It should be needed.
> Sorry for my mistake again. Could you add this header instead of me
> ?(because I can resend the patch tonight).
>
> Thanks!
>>
>> Thanks,
>>
Hi Jaegeuk.
I tried to paste the patch in mail.
Could you take below patch instead of previous patch ?

Thanks.



Subject: [PATCH] f2fs: add compat_ioctl to provide backward compatibility
From: Namjae Jeon 

adding compat_ioctl to provide support for backward comptability - 32bit binary
execution on 64bit kernel.

Signed-off-by: Namjae Jeon 
Signed-off-by: Amit Sahrawat 
---
 fs/f2fs/f2fs.h |   15 +++
 fs/f2fs/file.c |   21 +
 2 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 5022a7d..e980dd5 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -104,6 +104,20 @@ static inline int update_sits_in_cursum(struct
f2fs_summary_block *rs, int i)
 }

 /*
+ * ioctl commands
+ */
+#define F2FS_IOC_GETFLAGS   FS_IOC_GETFLAGS
+#define F2FS_IOC_SETFLAGS   FS_IOC_SETFLAGS
+
+#if defined(__KERNEL__) && defined(CONFIG_COMPAT)
+/*
+ * ioctl commands in 32 bit emulation
+ */
+#define F2FS_IOC32_GETFLAGS FS_IOC32_GETFLAGS
+#define F2FS_IOC32_SETFLAGS FS_IOC32_SETFLAGS
+#endif
+
+/*
  * For INODE and NODE manager
  */
 #define XATTR_NODE_OFFSET  (-1)/*
@@ -842,6 +856,7 @@ void f2fs_truncate(struct inode *);
 int f2fs_setattr(struct dentry *, struct iattr *);
 int truncate_hole(struct inode *, pgoff_t, pgoff_t);
 long f2fs_ioctl(struct file *, unsigned int, unsigned long);
+long f2fs_compat_ioctl(struct file *, unsigned int, unsigned long);

 /*
  * inode.c
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 33d1736..de3e533 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "f2fs.h"
 #include "node.h"
@@ -634,6 +635,23 @@ out:
}
 }

+#ifdef CONFIG_COMPAT
+long f2fs_compat_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
+{
+   switch (cmd) {
+   case F2FS_IOC32_GETFLAGS:
+   cmd = F2FS_IOC_GETFLAGS;
+   break;
+   case F2FS_IOC32_SETFLAGS:
+   cmd = F2FS_IOC_SETFLAGS;
+   break;
+   default:
+   return -ENOIOCTLCMD;
+   }
+   return f2fs_ioctl(file, cmd, (unsigned long) compat_ptr(arg));
+}
+#endif
+
 const struct file_operations f2fs_file_operations = {
.llseek = generic_file_llseek,
.read   = do_sync_read,
@@ -645,6 +663,9 @@ const struct file_operations f2fs_file_operations = {
.fsync  = f2fs_sync_file,
.fallocate  = f2fs_fallocate,
.unlocked_ioctl = f2fs_ioctl,
+#ifdef CONFIG_COMPAT
+   .compat_ioctl   = f2fs_compat_ioctl,
+#endif
.splice_read= generic_file_splice_read,
.splice_write   = generic_file_splice_write,
 };
-- 
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] KVM: MMU: lazily drop large spte

[Xiao Guangrong]

Currently, kvm zaps the large spte if write-protected is needed, the later
read can fault on that spte. Actually, we can make the large spte readonly
instead of making them un-present, the page fault caused by read access can
be avoid

The idea is from Avi:
| As I mentioned before, write-protecting a large spte is a good idea,
| since it moves some work from protect-time to fault-time, so it reduces
| jitter.  This removes the need for the return value.

Signed-off-by: Xiao Guangrong 
---
Changelog:
v3:
- address Gleb's comments, we make the function return true if flush is
  needed instead of returning it via pointer to a variable
- improve the changelog

 arch/x86/kvm/mmu.c |   23 +++
 1 files changed, 7 insertions(+), 16 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 42ba85c..ff2fc80 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1106,8 +1106,7 @@ static void drop_large_spte(struct kvm_vcpu *vcpu, u64 
*sptep)

 /*
  * Write-protect on the specified @sptep, @pt_protect indicates whether
- * spte writ-protection is caused by protecting shadow page table.
- * @flush indicates whether tlb need be flushed.
+ * spte write-protection is caused by protecting shadow page table.
  *
  * Note: write protection is difference between drity logging and spte
  * protection:
@@ -1116,10 +1115,9 @@ static void drop_large_spte(struct kvm_vcpu *vcpu, u64 
*sptep)
  * - for spte protection, the spte can be writable only after unsync-ing
  *   shadow page.
  *
- * Return true if the spte is dropped.
+ * Return true if tlb need be flushed.
  */
-static bool
-spte_write_protect(struct kvm *kvm, u64 *sptep, bool *flush, bool pt_protect)
+static bool spte_write_protect(struct kvm *kvm, u64 *sptep, bool pt_protect)
 {
u64 spte = *sptep;

@@ -1129,17 +1127,11 @@ spte_write_protect(struct kvm *kvm, u64 *sptep, bool 
*flush, bool pt_protect)

rmap_printk("rmap_write_protect: spte %p %llx\n", sptep, *sptep);

-   if (__drop_large_spte(kvm, sptep)) {
-   *flush |= true;
-   return true;
-   }
-
if (pt_protect)
spte &= ~SPTE_MMU_WRITEABLE;
spte = spte & ~PT_WRITABLE_MASK;

-   *flush |= mmu_spte_update(sptep, spte);
-   return false;
+   return mmu_spte_update(sptep, spte);
 }

 static bool __rmap_write_protect(struct kvm *kvm, unsigned long *rmapp,
@@ -1151,11 +1143,8 @@ static bool __rmap_write_protect(struct kvm *kvm, 
unsigned long *rmapp,

for (sptep = rmap_get_first(*rmapp, ); sptep;) {
BUG_ON(!(*sptep & PT_PRESENT_MASK));
-   if (spte_write_protect(kvm, sptep, , pt_protect)) {
-   sptep = rmap_get_first(*rmapp, );
-   continue;
-   }

+   flush |= spte_write_protect(kvm, sptep, pt_protect);
sptep = rmap_get_next();
}

@@ -2611,6 +2600,8 @@ static int __direct_map(struct kvm_vcpu *vcpu, gpa_t v, 
int write,
break;
}

+   drop_large_spte(vcpu, iterator.sptep);
+
if (!is_shadow_present_pte(*iterator.sptep)) {
u64 base_addr = iterator.addr;

-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: cma: fix accounting of CMA pages placed in high memory

[Marek Szyprowski]

Hello,

On 2/5/2013 12:34 AM, Minchan Kim wrote:

On Mon, Feb 04, 2013 at 11:27:05AM +0100, Marek Szyprowski wrote:
> The total number of low memory pages is determined as
> totalram_pages - totalhigh_pages, so without this patch all CMA
> pageblocks placed in highmem were accounted to low memory.

So what's the end user effect? With the effect, we have to decide
routing it on stable.

>
> Signed-off-by: Marek Szyprowski 
> ---
>  mm/page_alloc.c |4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index f5bab0a..6415d93 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -773,6 +773,10 @@ void __init init_cma_reserved_pageblock(struct page 
*page)
>set_pageblock_migratetype(page, MIGRATE_CMA);
>__free_pages(page, pageblock_order);
>totalram_pages += pageblock_nr_pages;
> +#ifdef CONFIG_HIGHMEM

We don't need #ifdef/#endif.


#ifdef is required to let this code compile when highmem is not enabled,
becuase totalhigh_pages is defined as 0, see include/linux/highmem.h


> +  if (PageHighMem(page))
> +  totalhigh_pages += pageblock_nr_pages;
> +#endif
>  }
>  #endif
>


Best regards
--
Marek Szyprowski
Samsung Poland R 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: [PATCH 2/3 v2] fb: udlfb: fix hang at disconnect

[Alexander Holler]

Am 04.02.2013 20:25, schrieb Greg KH:
> On Mon, Feb 04, 2013 at 08:17:04PM +0100, Alexander Holler wrote:
>> Am 04.02.2013 13:05, schrieb Alexander Holler:
>>> Am 04.02.2013 02:14, schrieb Greg KH:
>>>
 So you are right in that your driver will wait for forever for a
 disconnect() to happen, as it will never be called.  I don't understand
 the problem that this is causing when it happens.  What's wrong with
 udlfb that having the cpu suddently reset as the powerdown happened
 without it knowing about it?
>>>
>>> There is nothing wrong with that. I've just explained why a problem
>>> doesn't occur on shutdown but on disconnect (of the device).
>>
>> Maybe my explanation before was just to long and I try to explain it
>> a bit shorter:
>>
>> If a device gets disconnected, the disconnect in udlfb might wait
>> forever in down_interruptible() (because it waits for an urb it
>> never receives). This even prevents a shutdown afterwards, because
>> that down_interruptible() never receives a signal (at shutdown,
>> because kernel threads don't get such).
> 
> Where was that urb when the disconnect happened?  The USB core should
> call your urb callback for any outstanding urbs at that point in time,
> with the proper error flag being set, are you handling that properly?

I don't know where that urb is as I don't handle it. I just know that
_interruptible doesn't make any sense and _timeout is necessary here.
But as nobody else seems to have a problem, nobody else see seems to see
the problem there and I seem to be unable to explain it, just ignore
that patch.

Regards,

Alexander

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/6] cpufreq: balance out cpufreq_cpu_{get,put} for scaling drivers using setpolicy

[Viresh Kumar]

On 4 February 2013 23:55, Dirk Brandewie  wrote:
> Hi Viresh,
>
> I have rebased onto bleeding-edge when I reboot the system I get a kernel
> panic.
> Any idea what I could have done that would have broken the restructured
> cpufreq_{add/remove}_dev.

Dirk, there are two mail chains for similar issue. Lets discuss these
issues in the
other thread: "BUG in bleeding edge c560f3d".
--
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] f2fs: add compat_ioctl to provide backward compatability

[Namjae Jeon]

2013/2/5, Jaegeuk Kim :
> Hi,
>
> 2013-02-05 (화), 14:28 +0900, Namjae Jeon:
>> Hi Jaegeuk.
>>
>> Oops!, I was missing include header.
>> Sorry, I will send v2 patch again.
>
> I got a build error, and simply added the following header file in your
> patch.
>
> #include 
>
> Is it correct?
Yes, Right :) It should be needed.
Sorry for my mistake again. Could you add this header instead of me
?(because I can resend the patch tonight).

Thanks!
>
> Thanks,
>
>>
>> Thanks.
>>
>> 2013/2/4, Namjae Jeon :
>> > From: Namjae Jeon 
>> >
>> > adding compat_ioctl to provide support for backward comptability -
>> > 32bit
>> > binary
>> > execution on 64bit kernel.
>> >
>> > Signed-off-by: Namjae Jeon 
>> > Signed-off-by: Amit Sahrawat 
>> > ---
>> >  fs/f2fs/f2fs.h |   15 +++
>> >  fs/f2fs/file.c |   20 
>> >  2 files changed, 35 insertions(+)
>> >
>> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
>> > index 58dd608..7bf86c8 100644
>> > --- a/fs/f2fs/f2fs.h
>> > +++ b/fs/f2fs/f2fs.h
>> > @@ -104,6 +104,20 @@ static inline int update_sits_in_cursum(struct
>> > f2fs_summary_block *rs, int i)
>> >  }
>> >
>> >  /*
>> > + * ioctl commands
>> > + */
>> > +#define F2FS_IOC_GETFLAGS   FS_IOC_GETFLAGS
>> > +#define F2FS_IOC_SETFLAGS   FS_IOC_SETFLAGS
>> > +
>> > +#if defined(__KERNEL__) && defined(CONFIG_COMPAT)
>> > +/*
>> > + * ioctl commands in 32 bit emulation
>> > + */
>> > +#define F2FS_IOC32_GETFLAGS FS_IOC32_GETFLAGS
>> > +#define F2FS_IOC32_SETFLAGS FS_IOC32_SETFLAGS
>> > +#endif
>> > +
>> > +/*
>> >   * For INODE and NODE manager
>> >   */
>> >  #define XATTR_NODE_OFFSET (-1)/*
>> > @@ -850,6 +864,7 @@ void f2fs_truncate(struct inode *);
>> >  int f2fs_setattr(struct dentry *, struct iattr *);
>> >  int truncate_hole(struct inode *, pgoff_t, pgoff_t);
>> >  long f2fs_ioctl(struct file *, unsigned int, unsigned long);
>> > +long f2fs_compat_ioctl(struct file *, unsigned int, unsigned long);
>> >
>> >  /*
>> >   * inode.c
>> > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
>> > index 633667e..e79d26a 100644
>> > --- a/fs/f2fs/file.c
>> > +++ b/fs/f2fs/file.c
>> > @@ -644,6 +644,23 @@ out:
>> >}
>> >  }
>> >
>> > +#ifdef CONFIG_COMPAT
>> > +long f2fs_compat_ioctl(struct file *file, unsigned int cmd, unsigned
>> > long
>> > arg)
>> > +{
>> > +  switch (cmd) {
>> > +  case F2FS_IOC32_GETFLAGS:
>> > +  cmd = F2FS_IOC_GETFLAGS;
>> > +  break;
>> > +  case F2FS_IOC32_SETFLAGS:
>> > +  cmd = F2FS_IOC_SETFLAGS;
>> > +  break;
>> > +  default:
>> > +  return -ENOIOCTLCMD;
>> > +  }
>> > +  return f2fs_ioctl(file, cmd, (unsigned long) compat_ptr(arg));
>> > +}
>> > +#endif
>> > +
>> >  const struct file_operations f2fs_file_operations = {
>> >.llseek = generic_file_llseek,
>> >.read   = do_sync_read,
>> > @@ -655,6 +672,9 @@ const struct file_operations f2fs_file_operations =
>> > {
>> >.fsync  = f2fs_sync_file,
>> >.fallocate  = f2fs_fallocate,
>> >.unlocked_ioctl = f2fs_ioctl,
>> > +#ifdef CONFIG_COMPAT
>> > +  .compat_ioctl   = f2fs_compat_ioctl,
>> > +#endif
>> >.splice_read= generic_file_splice_read,
>> >.splice_write   = generic_file_splice_write,
>> >  };
>> > --
>> > 1.7.9.5
>> >
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> Jaegeuk Kim
> Samsung
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] PM / devfreq: set min/max freq limit from freq table

[MyungJoo Ham]

On Tue, Jan 15, 2013 at 8:21 PM, Rajagopal Venkat
 wrote:
> On 14 January 2013 20:06, MyungJoo Ham  wrote:
>> On Tue, Jan 8, 2013 at 2:50 PM, Rajagopal Venkat
>>  wrote:
>>> Set devfreq device min and max frequency limits when device
>>> is added to devfreq, provided frequency table is supplied.
>>> This helps governors to suggest target frequency with in
>>> limits.
>>>
>>> Signed-off-by: Rajagopal Venkat 
>>
>> Could you please elaborate the benefit of the patch?
>>
>
> When freq table is supplied, it's unreasonable to suggest the target frequency
> which is - target_freq < min_freq and target_freq > max_freq. It avoids
> unnecessary checks at devfreq drivers.

Is it a safety barrier against userspace processes or devfreq governors?
Users are allowed to enter min_freq and max_freq via sysfs interfaces anyway.
Also, as mentioned earlier, users are allowed to enter 0 in order to
"disengage" the min/max_freq.
If we need "hardware-specific" min/max value, we'd need another sysfs
interfaces and values (i.e., scaling_min/max_freq vs
cpuinfo_min/max_freq).

Besides, if you are able to provide "freq_table", it means that you
are able to provide OPP for the device.
Then, you can use OPP APIs to avoid unnecessary checks at devfreq
driver (even you can use the devfreq helper functions)

>
>> The devfreq device drivers are required to choose proper frequencies
>> anyway regardless which values the governors may give (hopefully by
>> choosing the closest value that can support the required performance).
>>
>
> Yes. but then each driver needs to have conditional checks for choosing
> closet value even though freq table is provided.

Even with this min/max-freq, when governors suggests some values
between min/max, each driver needs to have checks unless it uses OPP.

>
>> Besides, the min/max values are to be set by userspace. Users may
>> enter 0 in order to express that they do not want to limit the
>> behaviors of governors.

Because of this, this patch will create discrepency from/to userspace
interfaces.




Cheers,
MyungJoo.

>>
>>
>> Cheers,
>> MyungJoo.
>>
>>> ---
>>>  drivers/devfreq/devfreq.c |   24 
>>>  1 file changed, 24 insertions(+)
>>>
>>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>>> index a8f0173..5782c9b 100644
>>> --- a/drivers/devfreq/devfreq.c
>>> +++ b/drivers/devfreq/devfreq.c
>>> @@ -69,6 +69,29 @@ static struct devfreq *find_device_devfreq(struct device 
>>> *dev)
>>>  }
>>>
>>>  /**
>>> + * devfreq_set_freq_limits() - Set min and max frequency from freq_table
>>> + * @devfreq:   the devfreq instance
>>> + */
>>> +static void devfreq_set_freq_limits(struct devfreq *devfreq)
>>> +{
>>> +   int idx;
>>> +   unsigned long min = ~0, max = 0;
>>> +
>>> +   if (!devfreq->profile->freq_table)
>>> +   return;
>>> +
>>> +   for (idx = 0; idx < devfreq->profile->max_state; idx++) {
>>> +   if (min > devfreq->profile->freq_table[idx])
>>> +   min = devfreq->profile->freq_table[idx];
>>> +   if (max < devfreq->profile->freq_table[idx])
>>> +   max = devfreq->profile->freq_table[idx];
>>> +   }
>>> +
>>> +   devfreq->min_freq = min;
>>> +   devfreq->max_freq = max;
>>> +}
>>> +
>>> +/**
>>>   * devfreq_get_freq_level() - Lookup freq_table for the frequency
>>>   * @devfreq:   the devfreq instance
>>>   * @freq:  the target frequency
>>> @@ -476,6 +499,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
>>> devfreq->profile->max_state,
>>> GFP_KERNEL);
>>> devfreq->last_stat_updated = jiffies;
>>> +   devfreq_set_freq_limits(devfreq);
>>>
>>> dev_set_name(>dev, dev_name(dev));
>>> err = device_register(>dev);
>>> --
>>> 1.7.10.4
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> MyungJoo Ham, Ph.D.
>> Mobile Software Platform Lab, DMC Business, Samsung Electronics
>
>
>
> --
> Regards,
> Rajagopal



-- 
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
--
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: No sysfs directory for openvswitch module when built-in

[Ben Pfaff]

Stephen Hemminger  writes:

> On Tue, 29 Jan 2013 22:15:18 +0800
> Cong Wang  wrote:
>
>> Hello, Rusty, Jesse,
>> 
>> I met an interesting problem when I compile openvswitch module as a
>> built-in (actually I compile ALL kernel modules as built-in), there is
>> no /sys/module/openvswitch/ directory created by the kernel in this
>> case.
>> 
>> What's worse, the user-space init script thinks openvswitch module is
>> not loaded by checking the exist of this directory, therefore refuses
>> to start.
>
> Shouldn't the OVS init script be testing for some other API.

I agree that's a bug in the OVS init script.  I will fix it.
--
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] f2fs: add compat_ioctl to provide backward compatability

[Jaegeuk Kim]

Hi,

2013-02-05 (화), 14:28 +0900, Namjae Jeon:
> Hi Jaegeuk.
> 
> Oops!, I was missing include header.
> Sorry, I will send v2 patch again.

I got a build error, and simply added the following header file in your
patch.

#include 

Is it correct?

Thanks,

> 
> Thanks.
> 
> 2013/2/4, Namjae Jeon :
> > From: Namjae Jeon 
> >
> > adding compat_ioctl to provide support for backward comptability - 32bit
> > binary
> > execution on 64bit kernel.
> >
> > Signed-off-by: Namjae Jeon 
> > Signed-off-by: Amit Sahrawat 
> > ---
> >  fs/f2fs/f2fs.h |   15 +++
> >  fs/f2fs/file.c |   20 
> >  2 files changed, 35 insertions(+)
> >
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index 58dd608..7bf86c8 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -104,6 +104,20 @@ static inline int update_sits_in_cursum(struct
> > f2fs_summary_block *rs, int i)
> >  }
> >
> >  /*
> > + * ioctl commands
> > + */
> > +#define F2FS_IOC_GETFLAGS   FS_IOC_GETFLAGS
> > +#define F2FS_IOC_SETFLAGS   FS_IOC_SETFLAGS
> > +
> > +#if defined(__KERNEL__) && defined(CONFIG_COMPAT)
> > +/*
> > + * ioctl commands in 32 bit emulation
> > + */
> > +#define F2FS_IOC32_GETFLAGS FS_IOC32_GETFLAGS
> > +#define F2FS_IOC32_SETFLAGS FS_IOC32_SETFLAGS
> > +#endif
> > +
> > +/*
> >   * For INODE and NODE manager
> >   */
> >  #define XATTR_NODE_OFFSET  (-1)/*
> > @@ -850,6 +864,7 @@ void f2fs_truncate(struct inode *);
> >  int f2fs_setattr(struct dentry *, struct iattr *);
> >  int truncate_hole(struct inode *, pgoff_t, pgoff_t);
> >  long f2fs_ioctl(struct file *, unsigned int, unsigned long);
> > +long f2fs_compat_ioctl(struct file *, unsigned int, unsigned long);
> >
> >  /*
> >   * inode.c
> > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> > index 633667e..e79d26a 100644
> > --- a/fs/f2fs/file.c
> > +++ b/fs/f2fs/file.c
> > @@ -644,6 +644,23 @@ out:
> > }
> >  }
> >
> > +#ifdef CONFIG_COMPAT
> > +long f2fs_compat_ioctl(struct file *file, unsigned int cmd, unsigned long
> > arg)
> > +{
> > +   switch (cmd) {
> > +   case F2FS_IOC32_GETFLAGS:
> > +   cmd = F2FS_IOC_GETFLAGS;
> > +   break;
> > +   case F2FS_IOC32_SETFLAGS:
> > +   cmd = F2FS_IOC_SETFLAGS;
> > +   break;
> > +   default:
> > +   return -ENOIOCTLCMD;
> > +   }
> > +   return f2fs_ioctl(file, cmd, (unsigned long) compat_ptr(arg));
> > +}
> > +#endif
> > +
> >  const struct file_operations f2fs_file_operations = {
> > .llseek = generic_file_llseek,
> > .read   = do_sync_read,
> > @@ -655,6 +672,9 @@ const struct file_operations f2fs_file_operations = {
> > .fsync  = f2fs_sync_file,
> > .fallocate  = f2fs_fallocate,
> > .unlocked_ioctl = f2fs_ioctl,
> > +#ifdef CONFIG_COMPAT
> > +   .compat_ioctl   = f2fs_compat_ioctl,
> > +#endif
> > .splice_read= generic_file_splice_read,
> > .splice_write   = generic_file_splice_write,
> >  };
> > --
> > 1.7.9.5
> >
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Jaegeuk Kim
Samsung


signature.asc
Description: This is a digitally signed message part

RE: [PATCH 2/2] ARM: davinci: da850: add wdt OF_DEV_AUXDATA entry

[Kumar, Anil]

Hi Serqei,

On Mon, Feb 04, 2013 at 17:30:20, Sergei Shtylyov wrote:
> Hello.
> 
> On 04-02-2013 15:50, Sekhar Nori wrote:
> 
> > Auxdata is not evm specific. This can instead be called 
> > da850_auxdata_lookup[].
> 
> > Also, I dont think it is necessary to add auxdata in a separate patch
> > from dt nodes. So, I fixed these issues and came up with below patch. I
> > tested basic wdt reboot. reboot command is still broken (with or
> > without this patch). Can you please look at that?
> 
> > Thanks,
> > Sekhar
> 
> > 8<
> > From: "Kumar, Anil" 
> > Date: Thu, 24 Jan 2013 14:08:14 +0530
> > Subject: [PATCH 1/1] ARM: davinci: da850: add wdt DT node
> 
> > Add da850 wdt DT node.
> 
> > Signed-off-by: Kumar, Anil 
> > Signed-off-by: Sekhar Nori 
> [...]
> 
> > diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> > index 8dd15c0..2800090 100644
> > --- a/arch/arm/boot/dts/da850.dtsi
> > +++ b/arch/arm/boot/dts/da850.dtsi
> > @@ -88,6 +88,11 @@
> >   19>;
> > status = "disabled";
> > };
> > +   wdt: wdt@1c21000 {
> > +   compatible = "ti,davinci-wdt";
> > +   reg = <0x21000 0xfff>;
> 
> Not 0x1000? This is region size, not upper limit.

Oh, you are right. It should be 0x1000. Thanks for correcting. 

In da850 timer1 is used as wdt and according to da850 data sheet.

Timer1 start address is 0x01C21000
Timer1 end address is   0x01C21FFF 

I had wrongly calculated upper limit. I will fix it. 

Thanks,
Anil
--
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: ISO/IEC 7811 driver for Magnetic Cards.

[H. Peter Anvin]

There is no reason for that to be in the kernel.

Priyaranjan Das  wrote:

>Hi Peter,
>
>On Tue, Feb 5, 2013 at 11:26 AM, H. Peter Anvin  wrote:
>> On 02/04/2013 09:08 PM, Priyaranjan Das wrote:
>>>
>>> Hi All,
>>>
>>> I am working on a Magnetic Card driver which would support ISO/IEC
>>> 7811 standard for track data. Can anyone tell me if such an
>>> implementation is available in existing kernel or not? I am
>basically
>>> looking for  code that implements the ISO/IEC 7811 standard or any
>>> similar standards.
>>>
>>
>> You have to write a driver for whatever reader/writer you are using. 
>A lot
>> of them simply show up as a USB HID (i.e. a keyboard) and thus don't
>need
>> any driver at all.
>>
>
>Thanks for your reply!
>
>However my question was more of related to ISO/IEC 7811 standard, As
>this is the format of the data read from the magnetic card. I wish to
>know whether any such module is there in the Linux kernel currently
>which works to decode the data as per as these ISO standards.
>
>For e.g,
>
>The first track read from a magnetic card could be as per below
>standard format :
>
>Track 1, Format :
>Start sentinel — one character (generally '%')
>Format code="B" — one character (alpha only)
>Primary account number (PAN) — up to 19 characters. Usually, but not
>always, matches the credit card number printed on the front of the
>card.
>Field Separator — one character (generally '^')
>Name — two to 26 characters
>Field Separator — one character (generally '^')
>Expiration date — four characters in the form YYMM.
>Service code — three characters
>Discretionary data — may include Pin Verification Key Indicator (PVKI,
>1 character), PIN Verification Value (PVV, 4 characters), Card
>Verification Value or Card Verification Code (CVV or CVC, 3
>characters)
>End sentinel — one character (generally '?')
>Longitudinal redundancy check (LRC) — it is one character and a
>validity character calculated from other data on the track.

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
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 2/2] usb: phy: samsung: Add PHY support for USB 3.0 controller

[Vivek Gautam]

Hi Kukjin,


On Wed, Jan 30, 2013 at 11:31 AM, Kukjin Kim  wrote:
> Vivek Gautam wrote:
>>
>> Adding PHY driver support for USB 3.0 controller for Samsung's
>> SoCs.
>>
>> Signed-off-by: Vivek Gautam 
>> ---
>>
>> Changes from v3:
>>  - Making SAMSUNG_USB3PHY dependent on SAMSUNG_USBPHY.
>>  - Adding USB_DWC3 to dependencies of SAMSUNG_USB2PHY since
>>dwc3 controller also looks for USB2 type PHY.
>>
>>  drivers/usb/phy/Kconfig  |   11 +-
>>  drivers/usb/phy/Makefile |1 +
>>  drivers/usb/phy/samsung-usb3.c   |  349
>> ++
>>  drivers/usb/phy/samsung-usbphy.h |   81 +
>>  4 files changed, 441 insertions(+), 1 deletions(-)
>>  create mode 100644 drivers/usb/phy/samsung-usb3.c
>>
>> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
>> index cc0d230..9325a95 100644
>> --- a/drivers/usb/phy/Kconfig
>> +++ b/drivers/usb/phy/Kconfig
>> @@ -52,14 +52,23 @@ config SAMSUNG_USBPHY
>>   help
>> Enable this to support Samsung USB phy controllers for Samsung
>> SoCs.
>> +   Further enable USB 2.0 type PHY or USB 3.0 type PHY as required
>> +   for USB controllers in use.
>>
>>  if SAMSUNG_USBPHY
>>
>>  config SAMSUNG_USB2PHY
>>   bool "Samsung USB 2.0 PHY controller Driver"
>> - depends on USB_S3C_HSOTG || USB_EHCI_S5P ||
>> USB_OHCI_EXYNOS
>> + depends on USB_S3C_HSOTG || USB_EHCI_S5P ||
>> USB_OHCI_EXYNOS || USB_DWC3
>>   help
>> Enable this to support Samsung USB 2.0 (High Speed) phy controller
>> for Samsung SoCs.
>>
>> +config SAMSUNG_USB3PHY
>> + bool "Samsung USB 3.0 PHY controller Driver"
>> + depends on USB_DWC3
>> + help
>> +   Enable this to support Samsung USB 3.0 (Super Speed) phy
>> controller
>> +   for samsung SoCs.
>> +
>>  endif
>
> It mean, when USB_DWC3 is selected, we can select only one USB2PHY or
> USB3PHY?
>

Actually, DWC3 expects both USB2PHY and USB3PHY, so went this way.
But this seems bad :-(
Will remove these dependencies as suggested by Felipe also.

> [...]
>
>> +#ifdef CONFIG_OF
>> +static const struct of_device_id samsung_usbphy_dt_match[] = {
>> + {
>> + .compatible = "samsung,exynos5250-usb3-phy",
>> + .data = _phy_exynos5
>> + },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, samsung_usbphy_dt_match);
>> +#endif
>> +
>> +static struct platform_device_id samsung_usbphy_driver_ids[] = {
>> + {
>> + .name   = "exynos5250-usb3-phy",
>
> According to the name of file, exynos5250-usb3phy? Just it is imho...
>

Ok, sure will amend this.

>> + .driver_data= (unsigned long)_phy_exynos5,
>> + },
>> + {},
>> +};
>> +
>> +MODULE_DEVICE_TABLE(platform, samsung_usbphy_driver_ids);
>> +
>> +static struct platform_driver samsung_usb3_phy_driver = {
>> + .probe  = samsung_usb3_phy_probe,
>> + .remove = samsung_usb3_phy_remove,
>> + .id_table   = samsung_usbphy_driver_ids,
>> + .driver = {
>> + .name   = "samsung-usb3-phy",
>> + .owner  = THIS_MODULE,
>> + .of_match_table =
>> of_match_ptr(samsung_usbphy_dt_match),
>> + },
>> +};
>> +
>> +module_platform_driver(samsung_usb3_phy_driver);
>> +
>> +MODULE_DESCRIPTION("Samsung USB 3.0 phy controller");
>> +MODULE_AUTHOR("Vivek Gautam ");
>> +MODULE_LICENSE("GPL");
>> +MODULE_ALIAS("platform:samsung-usb3-phy");
>
> I want you to use same naming rule.
>

Sure.


-- 
Thanks & Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH V2 1/6] pinctrl: pinctrl-single: use arch_initcall and module_exit

[Vishwanathrao Badarkhe, Manish]

On Fri, Feb 01, 2013 at 22:41:24, Tony Lindgren wrote:
> * Tony Lindgren  [130201 09:12]:
> > * Linus Walleij  [130129 03:03]:
> > > On Tue, Jan 29, 2013 at 8:38 AM, Vishwanathrao Badarkhe, Manish 
> > >  wrote:
> > > 
> > > > Currently, I2C driver gets probed before pinctrl driver.
> > > > To achieve I2C pin muxing via pinctrl driver before I2C probe get 
> > > > called, register pinctrl driver in arch_initcall.
> > > > Also, add module_exit to unregister pinctrl driver.
> > > >
> > > > Signed-off-by: Vishwanathrao Badarkhe, Manish 
> > > 
> > > So your I2C driver is not returning -EPROBE_DEFER if it cannot find 
> > > its pins?
> > > 
> > > Hm, well I can live with this, if Tony ACKs it.
> > 
> > Hmm pinctrl is before i2c in drivers/Makefile.
> > Making initcalls happen earlier and earlier is usually the wrong way 
> > to go. Sounds like there's some other issue here that needs to be 
> > fixed instead.
> 
> Let me guess: The i2c driver is wrongly set to run with arch_initcall?
>  

Hi Tony

No, Currently i2c driver is set to subsys_initcall. I have seen some
problem while using pin control grab functionality. Please see detailed
explanation as below.

Hi Linus

I am using auto grab pin control facility to do pin muxing of I2C0 
pins and seen problem as below:

Currently, probe of I2C0 driver gets called before pin control driver. 
Hence, while calling I2C0 probe because of unavailability of  
pin control node information, its probe get deferred giving following 
messages:

"i2c_davinci i2c_davinci.1: could not find pctldev for node /soc/pinmux@1c14120
/pinmux_i2c0_pins, deferring probe"

As I2C0 is in deferred list (as auto grab patch handle this), its probe 
get called once again, During this second time probe of I2C0, I have 
observed following crash:

"Unable to handle kernel paging request at virtual address fe07"

As per code analysis of auto grab functionality, I have seen in 
"pinctrl_bind_pin" function, pin control handle (dpi->p) is returned by 
"devm_pinctrl_get" function.

Pin control handle is assigned with error pointer during 1st time probing of 
I2C0 (as pin control information is not available at this time). 
During 2nd time probing (deferred probe) of I2C0, same pin control handle 
(which was get assigned during 1st probe) is getting used instead of getting 
updated to correct pin control handle which leads to system crash.

I made following changes, in order to update "dip->p" pointer with 
correct value:

-   if (!dpi->p) {
+   if (IS_ERR_OR_NULL(dpi->p)) {
dpi->p = devm_pinctrl_get(dev);
-   if (IS_ERR_OR_NULL(dpi->p)) {
-   int ret = PTR_ERR(dpi->p);
-
-   dev_dbg(dev, "no pinctrl handle\n");
-   /* Only return deferrals */
-   if (ret == -EPROBE_DEFER)
-   return ret;
-   return 0;
-   }
+   ret = PTR_ERR(dpi->p);
+   dev_dbg(dev, "no pinctrl handle\n");
+   /* Only return deferrals */
+   if (ret == -EPROBE_DEFER)
+   return ret;
+   return 0;

Is this intended change? or am I missing something in order to use this auto 
grab
functionality?

With the above change, now deferred probing is working fine and there is no need
to register pin control driver in arch_initcall.


Regards, 
Manish
--
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/2] mm: hotplug: implement non-movable version of get_user_pages() to kill long-time pin pages

[Lin Feng]

On 02/05/2013 01:25 PM, Minchan Kim wrote:
> Hi Lin,
> 
> On Tue, Feb 05, 2013 at 12:42:48PM +0800, Lin Feng wrote:
>> Hi Minchan,
>>
>> On 02/05/2013 08:58 AM, Minchan Kim wrote:
>>> Hello,
>>>
>>> On Mon, Feb 04, 2013 at 06:04:06PM +0800, Lin Feng wrote:
 Currently get_user_pages() always tries to allocate pages from movable 
 zone,
 as discussed in thread https://lkml.org/lkml/2012/11/29/69, in some case 
 users
 of get_user_pages() is easy to pin user pages for a long time(for now we 
 found
 that pages pinned as aio ring pages is such case), which is fatal for 
 memory
 hotplug/remove framework.

 So the 1st patch introduces a new library function called
 get_user_pages_non_movable() to pin pages only from zone non-movable in 
 memory.
 It's a wrapper of get_user_pages() but it makes sure that all pages come 
 from
 non-movable zone via additional page migration.

 The 2nd patch gets around the aio ring pages can't be migrated bug caused 
 by
 get_user_pages() via using the new function. It only works when configed 
 with
 CONFIG_MEMORY_HOTREMOVE, otherwise it uses the old version of 
 get_user_pages().
>>>
>>> CMA has same issue but the problem is the driver developers or any subsystem
>>> using GUP can't know their pages is in CMA area or not in advance.
>>> So all of client of GUP should use GUP_NM to work them with 
>>> CMA/MEMORY_HOTPLUG well?
>>> Even some driver module in embedded side doesn't open their source code.
>> Yes, it somehow depends on the users of GUP. In MEMORY_HOTPLUG case, as for 
>> most users
>> of GUP, they will release the pinned pages immediately and to such users 
>> they should get
>> a good performance, using the old style interface is a smart way. And we had 
>> better just
>> deal with the cases we have to by using the new interface.
> 
> Hmm, I think you can't make sure most of user for MEMORY_HOTPLUG will release 
> pinned pages
> immediately. Because MEMORY_HOTPLUG could be used for embedded system for 
> reducing power
> by PASR and some drivers in embedded could use GUP anytime and anywhere. They 
> can't know
> in advance they will use pinned pages long time or release in short time 
> because it depends
> on some event like user's response which is very not predetermined.
> So for solving it, we can add some WARN_ON in CMA/MEMORY_HOTPLUG part just in 
> case of
> failing migration by page count and then, investigate they are really using 
> GUP and it's
> REALLY a culprit. If so, yell to them "Please use GUP_NM instead"?
> 
> Yes. it could be done but it would be rather trobulesome job.
Yes WARN_ON may be easy while troubleshooting for finding the immigrate-able 
page is 
a big job.
If we want to kill all the potential immigrate-able pages caused by GUP we'd 
better use the
*non_movable* version of GUP.
But in some server environment we want to keep the performance but also want to 
use hotremove
feature in case. Maybe patch the place as we need is a trade off for such 
support.

Mel also said in the last discussion:

On 11/30/2012 07:00 PM, Mel Gorman wrote:> On Thu, Nov 29, 2012 at 11:55:02PM 
-0800, Andrew Morton wrote:
>> Well, that's a fairly low-level implementation detail.  A more typical
>> approach would be to add a new get_user_pages_non_movable() or such. 
>> That would probably have the same signature as get_user_pages(), with
>> one additional argument.  Then get_user_pages() becomes a one-line
>> wrapper which passes in a particular value of that argument.
>>
> 
> That is going in the direction that all pinned pages become MIGRATE_UNMOVABLE
> allocations.  That will impact THP availability by increasing the number
> of MIGRATE_UNMOVABLE blocks that exist and it would hit every user --
> not just those that care about ZONE_MOVABLE.
> 
> I'm likely to NAK such a patch if it's only about node hot-remove because
> it's much more of a corner case than wanting to use THP.
> 
> I would prefer if get_user_pages() checked if the page it was about to
> pin was in ZONE_MOVABLE and if so, migrate it at that point before it's
> pinned. It'll be expensive but will guarantee ZONE_MOVABLE availability
> if that's what they want. The CMA people might also want to take
> advantage of this if the page happened to be in the MIGRATE_CMA
> pageblock.
> 

So it may not a good idea that we all fall into calling the *non_movable* 
version of
GUP when CONFIG_MIGRATE_ISOLATE is on. What do you think?

> #ifdef CONFIG_MIGRATE_ISOLATE
> 
> int get_user_pages_non_movable()
> {
> ..
> old_get_user_pages()
> ..
> }
> 
> int get_user_pages()
> {
> return get_user_pages_non_movable();
> }
> #else
> int get_user_pages()
> {
> return old_get_user_pages()
> }
> #endif


thanks,
linfeng
--
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  

Re: [PATCH v4 1/2] usb: phy: samsung: Common out the generic stuff

[Vivek Gautam]

Hi Kukjin,


On Wed, Jan 30, 2013 at 11:26 AM, Kukjin Kim  wrote:
> Vivek Gautam wrote:
>>
>> Moving register and structure definitions to header file,
>> and keeping the generic functions to be used across
>> multiple PHYs in common file "samsung-usbphy.c".
>> Also renaming the usb 2.0 phy driver to "samsung-usb2.c"
>
> Just in my opinion, Samsung-usb2phy is more clear?...In addition, I looked
> at using SAMSUNG_USB2PHY as a statement.
>

Sure will change the file names as suggested
samsung-usbphy.c : common PHY controller driver
samsung-usb2phy.c : USB 2.0 PHY controller driver

Will change the names for CONFIG_XX also accordingly.

>>
>> Signed-off-by: Vivek Gautam 
>> ---
>>
>> Changes from v3:
>>  - Using separate config SAMSUNG_USB2PHY dependent on
>>SAMSUNG_USBPHY for samsung-usb2 type PHY controller.
>>
>>  drivers/usb/phy/Kconfig  |   14 +-
>>  drivers/usb/phy/Makefile |1 +
>>  drivers/usb/phy/samsung-usb2.c   |  511 +++
>>  drivers/usb/phy/samsung-usbphy.c |  714
> +-
>>  drivers/usb/phy/samsung-usbphy.h |  247 +
>>  5 files changed, 778 insertions(+), 709 deletions(-)
>>  create mode 100644 drivers/usb/phy/samsung-usb2.c
>>  create mode 100644 drivers/usb/phy/samsung-usbphy.h
>>
>> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
>> index fae4d08..cc0d230 100644
>> --- a/drivers/usb/phy/Kconfig
>> +++ b/drivers/usb/phy/Kconfig
>> @@ -48,8 +48,18 @@ config USB_RCAR_PHY
>>
>>  config SAMSUNG_USBPHY
>>   bool "Samsung USB PHY controller Driver"
>> - depends on USB_S3C_HSOTG || USB_EHCI_S5P ||
>> USB_OHCI_EXYNOS
>
> So this can be selected without any dependency?
>

The idea was SAMSUNG_USBPHY is selected for usb2 type PHY as well as
usb 3 type PHY.
But this seems to be bad :-(
Better we do something like this ?

config SAMSUNG_USB2
bool "Samsung USB 2.0 PHY controller Driver"
select SAMSUNG_USBPHY
select USB_OTG_UTILS
help
  Enable this to support Samsung USB 2.0 (High Speed) PHY controller
  driver for Samsung SoCs.

config SAMSUNG_USBPHY
bool "Samsung USB PHY controller Driver"
help
  Enable this to support Samsung USB phy helper driver for Samsung SoCs.
  This driver provides common interface for Samsung USB 2.0 PHY driver
  and later for Samsung USB 3.0 PHY driver.

>>   select USB_OTG_UTILS
>>   help
>> -   Enable this to support Samsung USB phy controller for samsung
>> +   Enable this to support Samsung USB phy controllers for Samsung
>> SoCs.
>
> Hmm, according to above comments, this should be enabled under Samsung SoC?
>

May we just add these configs under USB as mentioned above ?

>> +
>> +if SAMSUNG_USBPHY
>
> Why is this needed here?
>

We will not need this if we change to something like mentioned above.

>> +
>> +config SAMSUNG_USB2PHY
>> + bool "Samsung USB 2.0 PHY controller Driver"
>> + depends on USB_S3C_HSOTG || USB_EHCI_S5P ||
>> USB_OHCI_EXYNOS
>> + help
>> +   Enable this to support Samsung USB 2.0 (High Speed) phy controller
>> +   for Samsung SoCs.
>> +
>> +endif
>> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
>> index ec304f6..7ba9862 100644
>> --- a/drivers/usb/phy/Makefile
>> +++ b/drivers/usb/phy/Makefile
>> @@ -10,3 +10,4 @@ obj-$(CONFIG_MV_U3D_PHY)+=
>> mv_u3d_phy.o
>>  obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
>>  obj-$(CONFIG_USB_RCAR_PHY)   += rcar-phy.o
>>  obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o
>> +obj-$(CONFIG_SAMSUNG_USB2PHY)+= samsung-usb2.o
>> diff --git a/drivers/usb/phy/samsung-usb2.c b/drivers/usb/phy/samsung-
>> usb2.c
>> new file mode 100644
>> index 000..9a9d1d0
>> --- /dev/null
>> +++ b/drivers/usb/phy/samsung-usb2.c
>> @@ -0,0 +1,511 @@
>> +/* linux/drivers/usb/phy/samsung-usb2.c
>> + *
>> + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
>> + *  http://www.samsung.com
>> + *
>> + * Author: Praveen Paneri 
>> + *
>> + * Samsung USB2.0 PHY transceiver; talks to S3C HS OTG controller,
> EHCI-S5P
>> and
>> + * OHCI-EXYNOS controllers.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "samsung-usbphy.h"
>> +
>> +int samsung_usbphy_set_host(struct usb_otg *otg, struct usb_bus *host)
>
> For naming, if you want to 

Re: [PATCH 3/3] PM / devfreq: account suspend/resume for stats

[MyungJoo Ham]

On Tue, Jan 15, 2013 at 8:46 PM, Rajagopal Venkat
 wrote:
> On 14 January 2013 20:18, MyungJoo Ham  wrote:
>> On Tue, Jan 8, 2013 at 2:50 PM, Rajagopal Venkat
>>  wrote:
>>> devfreq stats is not taking device suspend and resume into
>>> account. Fix it.
>>>
>>> Signed-off-by: Rajagopal Venkat 
>>
>> With monitor_suspend(), we are suspending the DVFS mechanism of a
>> device, not the device itself.
>>
>> Thus, the device may keep its frequency running and we may assume that
>> the frequency is constant as the DVFS mechanism is in suspend.
>>
>> Why do you want to stop the statistics as well?
>>
>
> There seems to be misunderstanding of devfreq_monitor_suspend() and
> devfreq_monitor_resume() apis usage.
>
> Typically devfreq_monitor_suspend() would be called to suspend the device
> devfreq when device is entering idle state by powering off(clocks and 
> voltage).
> When device itself is off, it's incorrect to allow stats to continue.

Ah.. yes... you're right. It is meant to be called by suspend of
pm-sleep or pm-suspend.
This will be applied soon.


Acked-by: MyungJoo Ham 

>
>>
>>
>> Again, as in the other patch, this is about the semantics of the
>> "devfreq statistics".
>>
>> It does not seem to be a problem of which is correct and which is not,
>> but it seems to be a problem of which is more convenient.
>>
>> Could you please give me some cases where your semantics is more helpful?
>
> When gpu is powered off, gpu devfreq should be suspended and hence the stats.



>
>>
>>
>>
>> I've been using the stat feature like this:
>>
>> # cat stat; run benchmark; cat stat
>> and look at the differences with any ops done during "run benchmark".
>>
>>
>>
>> Cheers,
>> MyungJoo.
>>
>>> ---
>>>  drivers/devfreq/devfreq.c |   15 ---
>>>  1 file changed, 12 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>>> index 2843a22..4c50235 100644
>>> --- a/drivers/devfreq/devfreq.c
>>> +++ b/drivers/devfreq/devfreq.c
>>> @@ -297,6 +297,7 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
>>> return;
>>> }
>>>
>>> +   devfreq_update_status(devfreq, devfreq->previous_freq);
>>> devfreq->stop_polling = true;
>>> mutex_unlock(>lock);
>>> cancel_delayed_work_sync(>work);
>>> @@ -313,6 +314,8 @@ EXPORT_SYMBOL(devfreq_monitor_suspend);
>>>   */
>>>  void devfreq_monitor_resume(struct devfreq *devfreq)
>>>  {
>>> +   unsigned long freq;
>>> +
>>> mutex_lock(>lock);
>>> if (!devfreq->stop_polling)
>>> goto out;
>>> @@ -321,8 +324,14 @@ void devfreq_monitor_resume(struct devfreq *devfreq)
>>> devfreq->profile->polling_ms)
>>> queue_delayed_work(devfreq_wq, >work,
>>> msecs_to_jiffies(devfreq->profile->polling_ms));
>>> +
>>> +   devfreq->last_stat_updated = jiffies;
>>> devfreq->stop_polling = false;
>>>
>>> +   if (devfreq->profile->get_cur_freq &&
>>> +   !devfreq->profile->get_cur_freq(devfreq->dev.parent, ))
>>> +   devfreq->previous_freq = freq;
>>> +
>>>  out:
>>> mutex_unlock(>lock);
>>>  }
>>> @@ -931,11 +940,11 @@ static ssize_t show_trans_table(struct device *dev, 
>>> struct device_attribute *att
>>>  {
>>> struct devfreq *devfreq = to_devfreq(dev);
>>> ssize_t len;
>>> -   int i, j, err;
>>> +   int i, j;
>>> unsigned int max_state = devfreq->profile->max_state;
>>>
>>> -   err = devfreq_update_status(devfreq, devfreq->previous_freq);
>>> -   if (err)
>>> +   if (!devfreq->stop_polling &&
>>> +   devfreq_update_status(devfreq, 
>>> devfreq->previous_freq))
>>> return 0;
>>>
>>> len = sprintf(buf, "   From  :   To\n");
>>> --
>>> 1.7.10.4
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> MyungJoo Ham, Ph.D.
>> Mobile Software Platform Lab, DMC Business, Samsung Electronics
>
>
>
> --
> Regards,
> Rajagopal



-- 
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
--
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 4/4] zram: get rid of lockdep warning

[Ric Mason]

On Tue, 2013-02-05 at 15:06 +0900, Minchan Kim wrote:
> On Mon, Feb 04, 2013 at 01:39:24AM -0600, Ric Mason wrote:
> > On Mon, 2013-02-04 at 08:46 +0900, Minchan Kim wrote:
> > > Lockdep complains about recursive deadlock of zram->init_lock.
> > > [1] made it false positive because we can't request IO to zram
> > > before setting disksize. Anyway, we should shut lockdep up to
> > > avoid many reporting from user.
> > > 
> > > [1] : zram: force disksize setting before using zram
> > > 
> > > Acked-by: Jerome Marchand 
> > > Signed-off-by: Minchan Kim 
> > > ---
> > >  drivers/staging/zram/zram_drv.c   |  189 
> > > +++--
> > >  drivers/staging/zram/zram_drv.h   |   12 ++-
> > >  drivers/staging/zram/zram_sysfs.c |   11 ++-
> > >  3 files changed, 116 insertions(+), 96 deletions(-)
> > > 
> > > diff --git a/drivers/staging/zram/zram_drv.c 
> > > b/drivers/staging/zram/zram_drv.c
> > > index 85055c4..56e3203 100644
> > > --- a/drivers/staging/zram/zram_drv.c
> > > +++ b/drivers/staging/zram/zram_drv.c
> > > @@ -61,22 +61,22 @@ static void zram_stat64_inc(struct zram *zram, u64 *v)
> > >   zram_stat64_add(zram, v, 1);
> > >  }
> > >  
> > > -static int zram_test_flag(struct zram *zram, u32 index,
> > > +static int zram_test_flag(struct zram_meta *meta, u32 index,
> > >   enum zram_pageflags flag)
> > >  {
> > > - return zram->table[index].flags & BIT(flag);
> > > + return meta->table[index].flags & BIT(flag);
> > >  }
> > >  
> > > -static void zram_set_flag(struct zram *zram, u32 index,
> > > +static void zram_set_flag(struct zram_meta *meta, u32 index,
> > >   enum zram_pageflags flag)
> > >  {
> > > - zram->table[index].flags |= BIT(flag);
> > > + meta->table[index].flags |= BIT(flag);
> > >  }
> > >  
> > > -static void zram_clear_flag(struct zram *zram, u32 index,
> > > +static void zram_clear_flag(struct zram_meta *meta, u32 index,
> > >   enum zram_pageflags flag)
> > >  {
> > > - zram->table[index].flags &= ~BIT(flag);
> > > + meta->table[index].flags &= ~BIT(flag);
> > >  }
> > >  
> > >  static int page_zero_filled(void *ptr)
> > > @@ -96,16 +96,17 @@ static int page_zero_filled(void *ptr)
> > >  
> > >  static void zram_free_page(struct zram *zram, size_t index)
> > >  {
> > > - unsigned long handle = zram->table[index].handle;
> > > - u16 size = zram->table[index].size;
> > > + struct zram_meta *meta = zram->meta;
> > > + unsigned long handle = meta->table[index].handle;
> > > + u16 size = meta->table[index].size;
> > >  
> > >   if (unlikely(!handle)) {
> > >   /*
> > >* No memory is allocated for zero filled pages.
> > >* Simply clear zero page flag.
> > >*/
> > > - if (zram_test_flag(zram, index, ZRAM_ZERO)) {
> > > - zram_clear_flag(zram, index, ZRAM_ZERO);
> > > + if (zram_test_flag(meta, index, ZRAM_ZERO)) {
> > > + zram_clear_flag(meta, index, ZRAM_ZERO);
> > >   zram->stats.pages_zero--;
> > >   }
> > >   return;
> > > @@ -114,17 +115,17 @@ static void zram_free_page(struct zram *zram, 
> > > size_t index)
> > >   if (unlikely(size > max_zpage_size))
> > >   zram->stats.bad_compress--;
> > >  
> > > - zs_free(zram->mem_pool, handle);
> > > + zs_free(meta->mem_pool, handle);
> > >  
> > >   if (size <= PAGE_SIZE / 2)
> > >   zram->stats.good_compress--;
> > >  
> > >   zram_stat64_sub(zram, >stats.compr_size,
> > > - zram->table[index].size);
> > > + meta->table[index].size);
> > >   zram->stats.pages_stored--;
> > >  
> > > - zram->table[index].handle = 0;
> > > - zram->table[index].size = 0;
> > > + meta->table[index].handle = 0;
> > > + meta->table[index].size = 0;
> > >  }
> > >  
> > >  static void handle_zero_page(struct bio_vec *bvec)
> > > @@ -149,20 +150,21 @@ static int zram_decompress_page(struct zram *zram, 
> > > char *mem, u32 index)
> > >   int ret = LZO_E_OK;
> > >   size_t clen = PAGE_SIZE;
> > >   unsigned char *cmem;
> > > - unsigned long handle = zram->table[index].handle;
> > > + struct zram_meta *meta = zram->meta;
> > > + unsigned long handle = meta->table[index].handle;
> > >  
> > > - if (!handle || zram_test_flag(zram, index, ZRAM_ZERO)) {
> > > + if (!handle || zram_test_flag(meta, index, ZRAM_ZERO)) {
> > >   memset(mem, 0, PAGE_SIZE);
> > >   return 0;
> > >   }
> > >  
> > > - cmem = zs_map_object(zram->mem_pool, handle, ZS_MM_RO);
> > > - if (zram->table[index].size == PAGE_SIZE)
> > > + cmem = zs_map_object(meta->mem_pool, handle, ZS_MM_RO);
> > > + if (meta->table[index].size == PAGE_SIZE)
> > >   memcpy(mem, cmem, PAGE_SIZE);
> > >   else
> > > - ret = lzo1x_decompress_safe(cmem, zram->table[index].size,
> > > + ret = lzo1x_decompress_safe(cmem, meta->table[index].size,
> > >   mem, );
> > > - zs_unmap_object(zram->mem_pool, 

Re: User-triggerable WARNING with fuse

[Tero Roponen]

On Mon, 4 Feb 2013, Miklos Szeredi wrote:

> On Fri, Feb 1, 2013 at 12:39 PM, Tero Roponen  wrote:
> >
> > Using the attached program I can trigger the following WARNING
> > reliably as a normal user. This happens at least both in 3.8-rc6
> > and 3.7.5.
> >
> > The kernel is tainted by proprietary NVIDIA module, but I don't
> > thinks it matters in this case.
> >
> 
> Thanks, the attached patch should fix it.

Yes, that fixed it.

-- 
Tero Roponen
--
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 05/10] spi/pxa2xx: break out the private DMA API usage into a separate file

[Mika Westerberg]

On Mon, Feb 04, 2013 at 08:43:42PM +0100, Linus Walleij wrote:
> On Tue, Jan 22, 2013 at 11:26 AM, Mika Westerberg
>  wrote:
> 
> > The PXA SPI driver uses PXA platform specific private DMA implementation
> > which does not work on non-PXA platforms. In order to use this driver on
> > other platforms we break out the private DMA implementation into a separate
> > file that gets compiled only when CONFIG_SPI_PXA2XX_PXADMA is set. The DMA
> > functions are stubbed out if there is no DMA implementation selected (i.e
> > we are building on non-PXA platform).
> >
> > While we are there we can kill the dummy DMA bits in pxa2xx_spi.h as they
> > are not needed anymore for CE4100.
> >
> > Once this is done we can add the generic DMA engine support to the driver
> > that allows usage of any DMA controller that implements DMA engine API.
> >
> > Signed-off-by: Mika Westerberg 
> > ---
> > This patch was already acked by Linus W but since I changed this by
> > breaking out the PXA private implementation into a separate file, I'm
> > hoping to get new ack from him ;-)
> 
> Sorry for the long delay. This is a nice and clean cut.
> Acked-by: Linus Walleij 

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/

Alerta de seguridad (kf03#7^2)

[Sistema Administrador]

--
Estimado titular de la cuenta,


 En estos momentos estamos actualizando nuestra 
basede datos central, e-mail para el primer trimestre de 2013, al darse 
cuenta de que su cuenta de correo web se ha visto comprometida por el 
acceso spammers.They tenía a su cuenta de correo web y he estado usando 
el Internet para actividades ilegales. para habilitar la auditoría de 
seguridad para restaurar y mantener su cuenta de correo electrónico 
activa. Haz clic en el enlace de abajo y llene la información necesaria 
para mantener activo e-mail.



https://docs.google.com/forms/d/1KZ-CxcvEX14qXzB6Qwb8JlcXuvvKeHmLierTNZjvmUE/viewform

Advertencia!

En la insuficiencia para verificar su cuenta dentro de 48 horas sobre 
la recepción de esta notificación, su cuenta será automáticamente 
desactivada.

Gracias por usar la cuenta de webmail.
Código Advertencia: QATO8B52AXV

Saludos cordiales,
Cuenta Webmail Equipo de Servicio de Gestión.
Gracias por su cooperación.
Copyright @ 2013 OFICINAS WEBMAIL Todos los derechos reservados.
--
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 4/4] zram: get rid of lockdep warning

[Minchan Kim]

On Mon, Feb 04, 2013 at 01:39:24AM -0600, Ric Mason wrote:
> On Mon, 2013-02-04 at 08:46 +0900, Minchan Kim wrote:
> > Lockdep complains about recursive deadlock of zram->init_lock.
> > [1] made it false positive because we can't request IO to zram
> > before setting disksize. Anyway, we should shut lockdep up to
> > avoid many reporting from user.
> > 
> > [1] : zram: force disksize setting before using zram
> > 
> > Acked-by: Jerome Marchand 
> > Signed-off-by: Minchan Kim 
> > ---
> >  drivers/staging/zram/zram_drv.c   |  189 
> > +++--
> >  drivers/staging/zram/zram_drv.h   |   12 ++-
> >  drivers/staging/zram/zram_sysfs.c |   11 ++-
> >  3 files changed, 116 insertions(+), 96 deletions(-)
> > 
> > diff --git a/drivers/staging/zram/zram_drv.c 
> > b/drivers/staging/zram/zram_drv.c
> > index 85055c4..56e3203 100644
> > --- a/drivers/staging/zram/zram_drv.c
> > +++ b/drivers/staging/zram/zram_drv.c
> > @@ -61,22 +61,22 @@ static void zram_stat64_inc(struct zram *zram, u64 *v)
> > zram_stat64_add(zram, v, 1);
> >  }
> >  
> > -static int zram_test_flag(struct zram *zram, u32 index,
> > +static int zram_test_flag(struct zram_meta *meta, u32 index,
> > enum zram_pageflags flag)
> >  {
> > -   return zram->table[index].flags & BIT(flag);
> > +   return meta->table[index].flags & BIT(flag);
> >  }
> >  
> > -static void zram_set_flag(struct zram *zram, u32 index,
> > +static void zram_set_flag(struct zram_meta *meta, u32 index,
> > enum zram_pageflags flag)
> >  {
> > -   zram->table[index].flags |= BIT(flag);
> > +   meta->table[index].flags |= BIT(flag);
> >  }
> >  
> > -static void zram_clear_flag(struct zram *zram, u32 index,
> > +static void zram_clear_flag(struct zram_meta *meta, u32 index,
> > enum zram_pageflags flag)
> >  {
> > -   zram->table[index].flags &= ~BIT(flag);
> > +   meta->table[index].flags &= ~BIT(flag);
> >  }
> >  
> >  static int page_zero_filled(void *ptr)
> > @@ -96,16 +96,17 @@ static int page_zero_filled(void *ptr)
> >  
> >  static void zram_free_page(struct zram *zram, size_t index)
> >  {
> > -   unsigned long handle = zram->table[index].handle;
> > -   u16 size = zram->table[index].size;
> > +   struct zram_meta *meta = zram->meta;
> > +   unsigned long handle = meta->table[index].handle;
> > +   u16 size = meta->table[index].size;
> >  
> > if (unlikely(!handle)) {
> > /*
> >  * No memory is allocated for zero filled pages.
> >  * Simply clear zero page flag.
> >  */
> > -   if (zram_test_flag(zram, index, ZRAM_ZERO)) {
> > -   zram_clear_flag(zram, index, ZRAM_ZERO);
> > +   if (zram_test_flag(meta, index, ZRAM_ZERO)) {
> > +   zram_clear_flag(meta, index, ZRAM_ZERO);
> > zram->stats.pages_zero--;
> > }
> > return;
> > @@ -114,17 +115,17 @@ static void zram_free_page(struct zram *zram, size_t 
> > index)
> > if (unlikely(size > max_zpage_size))
> > zram->stats.bad_compress--;
> >  
> > -   zs_free(zram->mem_pool, handle);
> > +   zs_free(meta->mem_pool, handle);
> >  
> > if (size <= PAGE_SIZE / 2)
> > zram->stats.good_compress--;
> >  
> > zram_stat64_sub(zram, >stats.compr_size,
> > -   zram->table[index].size);
> > +   meta->table[index].size);
> > zram->stats.pages_stored--;
> >  
> > -   zram->table[index].handle = 0;
> > -   zram->table[index].size = 0;
> > +   meta->table[index].handle = 0;
> > +   meta->table[index].size = 0;
> >  }
> >  
> >  static void handle_zero_page(struct bio_vec *bvec)
> > @@ -149,20 +150,21 @@ static int zram_decompress_page(struct zram *zram, 
> > char *mem, u32 index)
> > int ret = LZO_E_OK;
> > size_t clen = PAGE_SIZE;
> > unsigned char *cmem;
> > -   unsigned long handle = zram->table[index].handle;
> > +   struct zram_meta *meta = zram->meta;
> > +   unsigned long handle = meta->table[index].handle;
> >  
> > -   if (!handle || zram_test_flag(zram, index, ZRAM_ZERO)) {
> > +   if (!handle || zram_test_flag(meta, index, ZRAM_ZERO)) {
> > memset(mem, 0, PAGE_SIZE);
> > return 0;
> > }
> >  
> > -   cmem = zs_map_object(zram->mem_pool, handle, ZS_MM_RO);
> > -   if (zram->table[index].size == PAGE_SIZE)
> > +   cmem = zs_map_object(meta->mem_pool, handle, ZS_MM_RO);
> > +   if (meta->table[index].size == PAGE_SIZE)
> > memcpy(mem, cmem, PAGE_SIZE);
> > else
> > -   ret = lzo1x_decompress_safe(cmem, zram->table[index].size,
> > +   ret = lzo1x_decompress_safe(cmem, meta->table[index].size,
> > mem, );
> > -   zs_unmap_object(zram->mem_pool, handle);
> > +   zs_unmap_object(meta->mem_pool, handle);
> >  
> > /* Should NEVER happen. Return bio error if it does. */
> > if (unlikely(ret != LZO_E_OK)) {
> > @@ 

Re: [PATCH v7 2/4] zram: force disksize setting before using zram

[Minchan Kim]

On Mon, Feb 04, 2013 at 01:33:15AM -0600, Ric Mason wrote:
> Hi Minchan,
> On Mon, 2013-02-04 at 08:46 +0900, Minchan Kim wrote:
> > Now zram document syas "set disksize is optional"
> > but partly it's wrong. When you try to use zram firstly after
> > booting, you must set disksize, otherwise zram can't work because
> > zram gendisk's size is 0. But once you do it, you can use zram freely
> > after reset because reset doesn't reset to zero paradoxically.
> > So in this time, disksize setting is optional.:(
> > It's inconsitent for user behavior and not straightforward.
> > 
> > This patch forces always setting disksize firstly before using zram.
> > Yes. It changes current behavior so someone could complain when
> > he upgrades zram. Apparently it could be a problem if zram is mainline
> > but it still lives in staging so behavior could be changed for right
> > way to go. Let them excuse.
> > 
> > Acked-by: Jerome Marchand 
> > Acked-by: Nitin Gupta 
> > Acked-by: Dan Magenheimer 
> > Signed-off-by: Minchan Kim 
> > ---
> >  drivers/staging/zram/zram.txt |   27 ++--
> >  drivers/staging/zram/zram_drv.c   |   51 
> > +
> >  drivers/staging/zram/zram_drv.h   |5 +---
> >  drivers/staging/zram/zram_sysfs.c |6 +
> >  4 files changed, 34 insertions(+), 55 deletions(-)
> > 
> > diff --git a/drivers/staging/zram/zram.txt b/drivers/staging/zram/zram.txt
> > index 5f75d29..765d790 100644
> > --- a/drivers/staging/zram/zram.txt
> > +++ b/drivers/staging/zram/zram.txt
> > @@ -23,17 +23,17 @@ Following shows a typical sequence of steps for using 
> > zram.
> > This creates 4 devices: /dev/zram{0,1,2,3}
> > (num_devices parameter is optional. Default: 1)
> >  
> > -2) Set Disksize (Optional):
> > -   Set disk size by writing the value to sysfs node 'disksize'
> > -   (in bytes). If disksize is not given, default value of 25%
> > -   of RAM is used.
> > -
> > -   # Initialize /dev/zram0 with 50MB disksize
> > -   echo $((50*1024*1024)) > /sys/block/zram0/disksize
> > -
> > -   NOTE: disksize cannot be changed if the disk contains any
> > -   data. So, for such a disk, you need to issue 'reset' (see below)
> > -   before you can change its disksize.
> > +2) Set Disksize
> > +Set disk size by writing the value to sysfs node 'disksize'.
> > +The value can be either in bytes or you can use mem suffixes.
> > +Examples:
> > +# Initialize /dev/zram0 with 50MB disksize
> > +echo $((50*1024*1024)) > /sys/block/zram0/disksize
> > +
> > +# Using mem suffixes
> > +echo 256K > /sys/block/zram0/disksize
> > +echo 512M > /sys/block/zram0/disksize
> > +echo 1G > /sys/block/zram0/disksize
> >  
> >  3) Activate:
> > mkswap /dev/zram0
> > @@ -65,8 +65,9 @@ Following shows a typical sequence of steps for using 
> > zram.
> > echo 1 > /sys/block/zram0/reset
> > echo 1 > /sys/block/zram1/reset
> >  
> > -   (This frees all the memory allocated for the given device).
> > -
> > +   This frees all the memory allocated for the given device and
> > +   resets the disksize to zero. You must set the disksize again
> > +   before reusing the device.
> >  
> >  Please report any problems at:
> >   - Mailing list: linux-mm-cc at laptop dot org
> > diff --git a/drivers/staging/zram/zram_drv.c 
> > b/drivers/staging/zram/zram_drv.c
> > index 262265e..1114cad 100644
> > --- a/drivers/staging/zram/zram_drv.c
> > +++ b/drivers/staging/zram/zram_drv.c
> > @@ -94,34 +94,6 @@ static int page_zero_filled(void *ptr)
> > return 1;
> >  }
> >  
> > -static void zram_set_disksize(struct zram *zram, size_t totalram_bytes)
> > -{
> > -   if (!zram->disksize) {
> > -   pr_info(
> > -   "disk size not provided. You can use disksize_kb module "
> > -   "param to specify size.\nUsing default: (%u%% of RAM).\n",
> > -   default_disksize_perc_ram
> > -   );
> > -   zram->disksize = default_disksize_perc_ram *
> > -   (totalram_bytes / 100);
> > -   }
> > -
> > -   if (zram->disksize > 2 * (totalram_bytes)) {
> > -   pr_info(
> > -   "There is little point creating a zram of greater than "
> > -   "twice the size of memory since we expect a 2:1 compression "
> > -   "ratio. Note that zram uses about 0.1%% of the size of "
> > -   "the disk when not in use so a huge zram is "
> > -   "wasteful.\n"
> > -   "\tMemory Size: %zu kB\n"
> > -   "\tSize you selected: %llu kB\n"
> > -   "Continuing anyway ...\n",
> > -   totalram_bytes >> 10, zram->disksize >> 10);
> > -   }
> > -
> > -   zram->disksize &= PAGE_MASK;
> > -}
> > -
> >  static void zram_free_page(struct zram *zram, size_t index)
> >  {
> > unsigned long handle = zram->table[index].handle;
> > @@ -497,6 +469,9 @@ void __zram_reset_device(struct zram *zram)
> >  {
> > 

Re: [PATCH] mm: break circular include from linux/mmzone.h

[li guang]

在 2013-02-04一的 21:20 -0800，David Rientjes写道：
> On Tue, 5 Feb 2013, liguang wrote:
> 
> > linux/mmzone.h included linux/memory_hotplug.h,
> > and linux/memory_hotplug.h also included
> > linux/mmzone.h, so there's a bad cirlular.
> > 
> 
> And both of these are protected by _LINUX_MMZONE_H and 
> __LINUX_MEMORY_HOTPLUG_H, respectively, so what's the problem?

obviously, It's a logical error,
and It has no more effect other than
combination of these 2 header files.
so, why don't we separate them?





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c

[li guang]

在 2013-02-04一的 21:35 -0800，David Rientjes写道：
> On Tue, 5 Feb 2013, liguang wrote:
> 
> > srat table should present only on acpi domain,
> > seems mm/ is not the right place for it.
> > 
> > Reviewed-by: David Rientjes 
> 
> I certainly didn't review this, please read 
> Documentation/SubmittingPatches.
> 
> > Signed-off-by: liguang 
> 
> Couple of issues with this:
> 
>  - it doesn't include your followup change "acpi: change Makefile for
>srat.c building" which is required for this to build, please fold it in 
>and repost,
> 
>  - there is whitespace damage, we use tabs for indentation in Makefiles,
> 
>  - you're basing your patches on Linus' tree when arch/x86/mm/srat has
>changed in linux-next (15 insertions(+), 14 deletions(-)), please 
>rebase this on the linux-next tree at git.kernel.org.
> 
> Otherwise, looks good.

OK, I'll rebase on linux-next.
Thanks!


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/4] numa: avoid export acpi_numa variable

[li guang]

在 2013-02-04一的 21:39 -0800，David Rientjes写道：
> On Tue, 5 Feb 2013, liguang wrote:
> 
> > acpi_numa is used to prevent srat table
> > being parsed, seems a little miss-named,
> > if 'noacpi' was specified by cmdline and
> > CONFIG_ACPI_NUMA was enabled, acpi_numa
> > will be operated directly from everywhere
> > it needed to disable/enable numa in acpi
> > mode which was a bad thing, so, try to
> > export a fuction to get srat table
> > enable/disable info.
> > 
> > Reviewed-by: David Rientjes 
> 
> Again, this was never reviewed by me, please learn how to use these tags 
> appropriately by reading Documentation/SubmittingPatches.

OK.

> 
> > Signed-off-by: liguang 
> > ---
> >  arch/x86/include/asm/acpi.h |2 +-
> >  arch/x86/kernel/acpi/srat.c |   15 ++-
> >  arch/x86/mm/numa.c  |2 +-
> >  arch/x86/xen/enlighten.c|2 +-
> >  4 files changed, 13 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
> > index 0c44630..6b9c861 100644
> > --- a/arch/x86/include/asm/acpi.h
> > +++ b/arch/x86/include/asm/acpi.h
> > @@ -181,7 +181,7 @@ static inline void disable_acpi(void) { }
> >  #define ARCH_HAS_POWER_INIT1
> >  
> >  #ifdef CONFIG_ACPI_NUMA
> > -extern int acpi_numa;
> > +extern void disable_acpi_numa(void);
> >  extern int x86_acpi_numa_init(void);
> >  #endif /* CONFIG_ACPI_NUMA */
> >  
> > diff --git a/arch/x86/kernel/acpi/srat.c b/arch/x86/kernel/acpi/srat.c
> > index 4ddf497..0a4d7ee 100644
> > --- a/arch/x86/kernel/acpi/srat.c
> > +++ b/arch/x86/kernel/acpi/srat.c
> > @@ -24,22 +24,27 @@
> >  #include 
> >  #include 
> >  
> > -int acpi_numa __initdata;
> > +static bool acpi_numa __initdata;
> >  
> >  static __init int setup_node(int pxm)
> >  {
> > return acpi_map_pxm_to_node(pxm);
> >  }
> >  
> > -static __init void bad_srat(void)
> > +void __init disable_acpi_numa(void)
> > +{
> > +   acpi_numa = false;
> > +}
> > +
> > +static void __init bad_srat(void)
> >  {
> > -   printk(KERN_ERR "SRAT: SRAT not used.\n");
> > acpi_numa = -1;
> > +   printk(KERN_ERR "SRAT: SRAT will not be used.\n");
> >  }
> >  
> > -static __init inline int srat_disabled(void)
> > +static bool __init srat_disabled(void)
> >  {
> > -   return acpi_numa < 0;
> > +   return acpi_numa;
> >  }
> >  
> >  /* Callback for SLIT parsing */
> > diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> > index 2d125be..870ca6b 100644
> > --- a/arch/x86/mm/numa.c
> > +++ b/arch/x86/mm/numa.c
> > @@ -47,7 +47,7 @@ static __init int numa_setup(char *opt)
> >  #endif
> >  #ifdef CONFIG_ACPI_NUMA
> > if (!strncmp(opt, "noacpi", 6))
> > -   acpi_numa = -1;
> > +   disable_acpi_numa();
> >  #endif
> > return 0;
> >  }
> > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> > index 138e566..a5f6353 100644
> > --- a/arch/x86/xen/enlighten.c
> > +++ b/arch/x86/xen/enlighten.c
> > @@ -1415,7 +1415,7 @@ asmlinkage void __init xen_start_kernel(void)
> >  * any NUMA information the kernel tries to get from ACPI will
> >  * be meaningless.  Prevent it from trying.
> >  */
> > -   acpi_numa = -1;
> > +   disable_acpi_numa();
> >  #endif
> >  
> > /* Don't do the full vcpu_info placement stuff until we have a
> 
> You've declared disable_acpi_numa() but never defined it so this will 
> fail at link time.  Please compile and test all of your changes with care 
> before posting them or people will start to ignore your contributions.

It did pass build.



--
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: ISO/IEC 7811 driver for Magnetic Cards.

[H. Peter Anvin]

On 02/04/2013 09:08 PM, Priyaranjan Das wrote:

Hi All,

I am working on a Magnetic Card driver which would support ISO/IEC
7811 standard for track data. Can anyone tell me if such an
implementation is available in existing kernel or not? I am basically
looking for  code that implements the ISO/IEC 7811 standard or any
similar standards.



You have to write a driver for whatever reader/writer you are using.  A 
lot of them simply show up as a USB HID (i.e. a keyboard) and thus don't 
need any driver at all.


-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 4/4] remove include asm/acpi.h in process_driver.c

[Yasuaki Ishimatsu]

2013/02/05 11:37, liguang wrote:
> process_driver.c include linux/acpi.h which already
> include asm/acpi.h, so remove it.
> 
> Signed-off-by: liguang 
> ---

Reviewed-by: Yasuaki Ishimatsu 

Thanks,
Yasuaki Ishimatsu

>   drivers/acpi/processor_driver.c |1 -
>   1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> index e83311b..752eedb 100644
> --- a/drivers/acpi/processor_driver.c
> +++ b/drivers/acpi/processor_driver.c
> @@ -52,7 +52,6 @@
>   #include 
>   #include 
>   #include 
> -#include 
>   
>   #include 
>   #include 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 09/10] clk: tegra: Implement clocks for Tegra114

[Prashant Gaikwad]

On Monday 04 February 2013 08:04 PM, Peter De Schrijver wrote:

On Mon, Feb 04, 2013 at 08:08:55AM +0100, Prashant Gaikwad wrote:

On Friday 01 February 2013 03:48 PM, Peter De Schrijver wrote:

...


+   /* xusb_hs_src */
+   val = readl(clk_base + CLK_SOURCE_XUSB_SS_SRC);
+   val |= BIT(25); /* always select PLLU_60M */
+   writel(val, clk_base + CLK_SOURCE_XUSB_SS_SRC);
+
+   clk = clk_register_fixed_factor(NULL, "xusb_hs_src", "pll_u_60M", 0,
+   1, 1);
+   clks[xusb_hs_src] = clk;
+

With device tree we can directly use pll_u_60M, no need to register
clock with fixed factor 1.
Same comment for dis1-fixed, dsi2-fixed and mipi-cal-fast clocks.


Does it make sense to have separate DT IDs at all then?


We can use same DT ID.


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/

Re: [PATCH v2 4/4] remove include asm/acpi.h in process_driver.c

[David Rientjes]

On Tue, 5 Feb 2013, liguang wrote:

> process_driver.c include linux/acpi.h which already
> include asm/acpi.h, so remove it.
> 
> Signed-off-by: liguang 

Acked-by: David Rientjes 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 01/10] clk: tegra: Refactor PLL programming code

[Prashant Gaikwad]

On Monday 04 February 2013 08:02 PM, Peter De Schrijver wrote:

On Mon, Feb 04, 2013 at 07:06:47AM +0100, Prashant Gaikwad wrote:

On Friday 01 February 2013 03:48 PM, Peter De Schrijver wrote:

...


-static int clk_pll_wait_for_lock(struct tegra_clk_pll *pll,
-void __iomem *lock_addr, u32 lock_bit_idx)
+static int clk_pll_wait_for_lock(struct tegra_clk_pll *pll)
   {
  int i;
-   u32 val;
+   u32 val, lock_bit;
+   void __iomem *lock_addr;

  if (!(pll->flags & TEGRA_PLL_USE_LOCK)) {
  udelay(pll->params->lock_delay);
  return 0;
  }

+   lock_addr = pll->clk_base + pll->params->base_reg;

This will not work for PLLE. Lock bit for PLLE is in misc register.


+   lock_bit = BIT(pll->params->lock_bit_idx);
+
  for (i = 0; i < pll->params->lock_delay; i++) {
  val = readl_relaxed(lock_addr);
-   if (val & BIT(lock_bit_idx)) {
+   if (val & lock_bit) {

Need to change the lock bit idx parameter for Tegra20 and Tegra30 PLLs
else this patch will break those.


Looking at commit 37c26a906527b8a6a252614ca83d21ad318c4e84 and commit
b08e8c0ecc42afa3a2e1019851af741980dd5a6b, these fields seem correctly
initialized for both Tegra20 and Tegra30? Or am I missing something?


Ohh, I missed to read

lock_bit = BIT(pll->params->lock_bit_idx);


Am I missing something about PLLE lock_addr also?


Thanks,

Peter.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] ARM: dts: Adding RTC device node

[Kukjin Kim]

Dongjin Kim wrote:
> 
> This patch enables RTC device node defined in
> arch/arm/boot/dts/exynos4.dtsi.
> 
> Signed-off-by: Dongjin Kim 
> ---
>  arch/arm/boot/dts/exynos4412-odroidx.dts |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
> b/arch/arm/boot/dts/exynos4412-odroidx.dts
> index 54fe32f..85c958a 100644
> --- a/arch/arm/boot/dts/exynos4412-odroidx.dts
> +++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
> @@ -83,6 +83,10 @@
>   regulator-boot-on;
>   };
> 
> + rtc@1007 {
> + status = "okay";
> + };
> +
>   sdhci@1253 {
>   bus-width = <4>;
>   pinctrl-0 = <_clk _cmd _cd _bus4>;
> --
> 1.7.10.4

Applied, thanks.

- Kukjin

--
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 2/4] numa: avoid export acpi_numa variable

[David Rientjes]

On Tue, 5 Feb 2013, liguang wrote:

> acpi_numa is used to prevent srat table
> being parsed, seems a little miss-named,
> if 'noacpi' was specified by cmdline and
> CONFIG_ACPI_NUMA was enabled, acpi_numa
> will be operated directly from everywhere
> it needed to disable/enable numa in acpi
> mode which was a bad thing, so, try to
> export a fuction to get srat table
> enable/disable info.
> 
> Reviewed-by: David Rientjes 

Again, this was never reviewed by me, please learn how to use these tags 
appropriately by reading Documentation/SubmittingPatches.

> Signed-off-by: liguang 
> ---
>  arch/x86/include/asm/acpi.h |2 +-
>  arch/x86/kernel/acpi/srat.c |   15 ++-
>  arch/x86/mm/numa.c  |2 +-
>  arch/x86/xen/enlighten.c|2 +-
>  4 files changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
> index 0c44630..6b9c861 100644
> --- a/arch/x86/include/asm/acpi.h
> +++ b/arch/x86/include/asm/acpi.h
> @@ -181,7 +181,7 @@ static inline void disable_acpi(void) { }
>  #define ARCH_HAS_POWER_INIT  1
>  
>  #ifdef CONFIG_ACPI_NUMA
> -extern int acpi_numa;
> +extern void disable_acpi_numa(void);
>  extern int x86_acpi_numa_init(void);
>  #endif /* CONFIG_ACPI_NUMA */
>  
> diff --git a/arch/x86/kernel/acpi/srat.c b/arch/x86/kernel/acpi/srat.c
> index 4ddf497..0a4d7ee 100644
> --- a/arch/x86/kernel/acpi/srat.c
> +++ b/arch/x86/kernel/acpi/srat.c
> @@ -24,22 +24,27 @@
>  #include 
>  #include 
>  
> -int acpi_numa __initdata;
> +static bool acpi_numa __initdata;
>  
>  static __init int setup_node(int pxm)
>  {
>   return acpi_map_pxm_to_node(pxm);
>  }
>  
> -static __init void bad_srat(void)
> +void __init disable_acpi_numa(void)
> +{
> + acpi_numa = false;
> +}
> +
> +static void __init bad_srat(void)
>  {
> - printk(KERN_ERR "SRAT: SRAT not used.\n");
>   acpi_numa = -1;
> + printk(KERN_ERR "SRAT: SRAT will not be used.\n");
>  }
>  
> -static __init inline int srat_disabled(void)
> +static bool __init srat_disabled(void)
>  {
> - return acpi_numa < 0;
> + return acpi_numa;
>  }
>  
>  /* Callback for SLIT parsing */
> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> index 2d125be..870ca6b 100644
> --- a/arch/x86/mm/numa.c
> +++ b/arch/x86/mm/numa.c
> @@ -47,7 +47,7 @@ static __init int numa_setup(char *opt)
>  #endif
>  #ifdef CONFIG_ACPI_NUMA
>   if (!strncmp(opt, "noacpi", 6))
> - acpi_numa = -1;
> + disable_acpi_numa();
>  #endif
>   return 0;
>  }
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 138e566..a5f6353 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1415,7 +1415,7 @@ asmlinkage void __init xen_start_kernel(void)
>* any NUMA information the kernel tries to get from ACPI will
>* be meaningless.  Prevent it from trying.
>*/
> - acpi_numa = -1;
> + disable_acpi_numa();
>  #endif
>  
>   /* Don't do the full vcpu_info placement stuff until we have a

You've declared disable_acpi_numa() but never defined it so this will 
fail at link time.  Please compile and test all of your changes with care 
before posting them or people will start to ignore your contributions.
--
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/4] SUNRPC: remove cache_detail->cache_upcall callback

[Stanislav Kinsbursky]

04.02.2013 20:50, Jeff Layton пишет:

On Tue, 15 Jan 2013 11:09:36 +0300
Stanislav Kinsbursky  wrote:


This callback is redundant since all that its' implementations are doing is
calling sunrpc_cache_pipe_upcall() with proper function address argument. This
function address is now stored on cache_detail structure and thus all the code
can be simplified.

Signed-off-by: Stanislav Kinsbursky 
---
  fs/nfsd/export.c  |   12 
  fs/nfsd/nfs4idmap.c   |   14 --
  include/linux/sunrpc/cache.h  |3 ---
  net/sunrpc/auth_gss/svcauth_gss.c |7 ---
  net/sunrpc/cache.c|6 +++---
  net/sunrpc/svcauth_unix.c |   12 
  6 files changed, 3 insertions(+), 51 deletions(-)

diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
index 63ee3bc..6f030a5 100644
--- a/fs/nfsd/export.c
+++ b/fs/nfsd/export.c
@@ -67,11 +67,6 @@ static void expkey_request(struct cache_detail *cd,
(*bpp)[-1] = '\n';
  }

-static int expkey_upcall(struct cache_detail *cd, struct cache_head *h)
-{
-   return sunrpc_cache_pipe_upcall(cd, h, cd->cache_request);
-}
-
  static struct svc_expkey *svc_expkey_update(struct cache_detail *cd, struct 
svc_expkey *new,
struct svc_expkey *old);
  static struct svc_expkey *svc_expkey_lookup(struct cache_detail *cd, struct 
svc_expkey *);
@@ -245,7 +240,6 @@ static struct cache_detail svc_expkey_cache_template = {
.hash_size  = EXPKEY_HASHMAX,
.name   = "nfsd.fh",
.cache_put  = expkey_put,
-   .cache_upcall   = expkey_upcall,
.cache_request  = expkey_request,
.cache_parse= expkey_parse,
.cache_show = expkey_show,
@@ -338,11 +332,6 @@ static void svc_export_request(struct cache_detail *cd,
(*bpp)[-1] = '\n';
  }

-static int svc_export_upcall(struct cache_detail *cd, struct cache_head *h)
-{
-   return sunrpc_cache_pipe_upcall(cd, h, cd->cache_request);
-}
-
  static struct svc_export *svc_export_update(struct svc_export *new,
struct svc_export *old);
  static struct svc_export *svc_export_lookup(struct svc_export *);
@@ -712,7 +701,6 @@ static struct cache_detail svc_export_cache_template = {
.hash_size  = EXPORT_HASHMAX,
.name   = "nfsd.export",
.cache_put  = svc_export_put,
-   .cache_upcall   = svc_export_upcall,
.cache_request  = svc_export_request,
.cache_parse= svc_export_parse,
.cache_show = svc_export_show,
diff --git a/fs/nfsd/nfs4idmap.c b/fs/nfsd/nfs4idmap.c
index 9033dfd..d9402ea 100644
--- a/fs/nfsd/nfs4idmap.c
+++ b/fs/nfsd/nfs4idmap.c
@@ -140,12 +140,6 @@ idtoname_request(struct cache_detail *cd, struct 
cache_head *ch, char **bpp,
  }

  static int
-idtoname_upcall(struct cache_detail *cd, struct cache_head *ch)
-{
-   return sunrpc_cache_pipe_upcall(cd, ch, cd->cache_request);
-}
-
-static int
  idtoname_match(struct cache_head *ca, struct cache_head *cb)
  {
struct ent *a = container_of(ca, struct ent, h);
@@ -192,7 +186,6 @@ static struct cache_detail idtoname_cache_template = {
.hash_size  = ENT_HASHMAX,
.name   = "nfs4.idtoname",
.cache_put  = ent_put,
-   .cache_upcall   = idtoname_upcall,
.cache_request  = idtoname_request,
.cache_parse= idtoname_parse,
.cache_show = idtoname_show,
@@ -322,12 +315,6 @@ nametoid_request(struct cache_detail *cd, struct 
cache_head *ch, char **bpp,
  }

  static int
-nametoid_upcall(struct cache_detail *cd, struct cache_head *ch)
-{
-   return sunrpc_cache_pipe_upcall(cd, ch, cd->cache_request);
-}
-
-static int
  nametoid_match(struct cache_head *ca, struct cache_head *cb)
  {
struct ent *a = container_of(ca, struct ent, h);
@@ -366,7 +353,6 @@ static struct cache_detail nametoid_cache_template = {
.hash_size  = ENT_HASHMAX,
.name   = "nfs4.nametoid",
.cache_put  = ent_put,
-   .cache_upcall   = nametoid_upcall,
.cache_request  = nametoid_request,
.cache_parse= nametoid_parse,
.cache_show = nametoid_show,
diff --git a/include/linux/sunrpc/cache.h b/include/linux/sunrpc/cache.h
index 4f1c858..249e73a 100644
--- a/include/linux/sunrpc/cache.h
+++ b/include/linux/sunrpc/cache.h
@@ -80,9 +80,6 @@ struct cache_detail {
char*name;
void(*cache_put)(struct kref *);

-   int (*cache_upcall)(struct cache_detail *,
-   struct cache_head *);
-
void(*cache_request)(struct cache_detail *cd,
 struct cache_head *ch,
 char **bpp, int *blen);
diff --git a/net/sunrpc/auth_gss/svcauth_gss.c 

Re: [PATCH 2/2] fs/aio.c: use get_user_pages_non_movable() to pin ring pages when support memory hotremove

[Lin Feng]

Hi Zach,

On 02/05/2013 07:02 AM, Zach Brown wrote:
>>> index 71f613c..0e9b30a 100644
>>> --- a/fs/aio.c
>>> +++ b/fs/aio.c
>>> @@ -138,9 +138,15 @@ static int aio_setup_ring(struct kioctx *ctx)
>>> }
>>>  
>>> dprintk("mmap address: 0x%08lx\n", info->mmap_base);
>>> +#ifdef CONFIG_MEMORY_HOTREMOVE
>>> +   info->nr_pages = get_user_pages_non_movable(current, ctx->mm,
>>> +   info->mmap_base, nr_pages,
>>> +   1, 0, info->ring_pages, NULL);
>>> +#else
>>> info->nr_pages = get_user_pages(current, ctx->mm,
>>> info->mmap_base, nr_pages, 
>>> 1, 0, info->ring_pages, NULL);
>>> +#endif
>>
>> Can't you hide this in your 1/1 patch, by providing this function as
>> just a static inline wrapper around get_user_pages when
>> CONFIG_MEMORY_HOTREMOVE is not enabled?
> 
> Yes, please.  Having callers duplicate the call site for a single
> optional boolean input is unacceptable.
I will deal with it in next version :)

> 
> But do we want another input argument as a name?  Should aio have been
> using get_user_pages_fast()? (and so now _fast_non_movable?)
> 
> I wonder if it's time to offer the booleans as a _flags() variant, much
> like the current internal flags for __get_user_pages().  The write and
> force arguments are already booleans, we have a different fast api, and
> now we're adding non-movable.  The NON_MOVABLE flag would be 0 without
> MEMORY_HOTREMOVE, easy peasy.
As my next reply-mail mentioned, IIUC in GUP case additional flags seems 
doesn't work,
 I abstract here:

As I debuged the get_user_pages(), I found that some pages is already there and 
may be
allocated before we call get_user_pages(). __get_user_pages() have following 
logic to
handle such case.
1786 while (!(page = follow_page(vma, start, 
foll_flags))) {
1787 int ret;
To such case an additional alloc-flag or such doesn't work, it's difficult to 
keep GUP
as smart as we want  , so I worked out the migration approach to get around and 
avoid messing up the current code.

And even worse we have already got *8* arguments...Maybe we have to rework the 
boolean 
arguments into bit flags... It seems not a little work :(
> 
> Turning current callers' mysterious '1, 1' in to 'WRITE|FORCE' might
> also be nice :).
Agree, maybe we could handle them later :)

thanks,
linfeng
--
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] SUNRPC: rework cache upcall to avoid NFSd root

[Stanislav Kinsbursky]

04.02.2013 18:17, J. Bruce Fields пишет:

On Mon, Feb 04, 2013 at 02:02:29PM +0300, Stanislav Kinsbursky wrote:

swapping

The main idea of this patch set is to call cache request not on kthread
upcall, but on userspace daemon cache_read call. This fixes the problem with
gaining of wrong dentry path after calling d_path() in kthread root context
(svc_export_request() callback), which always work in init root context, but
containers can work in "root jail" - i.e. have it's own nested root.

v2:
1) NFS DNS cache update wasn't done in the firest version. So this patch set
does preparation cleanup of the NFS DNS cache routines.
2) Also, this patch set doesn't remove cache_upcall helper anymore, because
it's still required for NFS DNS cache.


Argh--I really prefer incremental patches once I've already committed
something, but OK.



Sorry. I was thinking about incremental patches. Next time I'll do so.


Backing out the old patches, I'll take a look at these.  The first two
should probably get an ACK from Trond.



Trond, could you review first two patches, please?
They are just clean-ups, actually. Nothing special. Required to unify the 
interfaces for latter patches in the series.

--
Best regards,
Stanislav Kinsbursky
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c

[David Rientjes]

On Tue, 5 Feb 2013, liguang wrote:

> srat table should present only on acpi domain,
> seems mm/ is not the right place for it.
> 
> Reviewed-by: David Rientjes 

I certainly didn't review this, please read 
Documentation/SubmittingPatches.

> Signed-off-by: liguang 

Couple of issues with this:

 - it doesn't include your followup change "acpi: change Makefile for
   srat.c building" which is required for this to build, please fold it in 
   and repost,

 - there is whitespace damage, we use tabs for indentation in Makefiles,

 - you're basing your patches on Linus' tree when arch/x86/mm/srat has
   changed in linux-next (15 insertions(+), 14 deletions(-)), please 
   rebase this on the linux-next tree at git.kernel.org.

Otherwise, looks good.
--
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 3/4] acpi: add clock_domain field to acpi_srat_cpu_affinity

[Yasuaki Ishimatsu]

2013/02/05 11:37, liguang wrote:
> according to ACPI SPEC v5.0, page 152,
> 5.2.16.1 Processor Local APIC/SAPIC Affinity Structure,
> the last member of it is clock_domain.
> 
> Signed-off-by: liguang 
> ---

Reviewed-by: Yasuaki Ishimatsu 

Thanks,
Yasuaki Ishimatsu

>   include/acpi/actbl1.h |2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
> index 280fc45..98031a3 100644
> --- a/include/acpi/actbl1.h
> +++ b/include/acpi/actbl1.h
> @@ -922,7 +922,7 @@ struct acpi_srat_cpu_affinity {
>   u32 flags;
>   u8 local_sapic_eid;
>   u8 proximity_domain_hi[3];
> - u32 reserved;   /* Reserved, must be zero */
> + u32 clock_domain;
>   };
>   
>   /* Flags */
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: Tree for Feb 5

[Stephen Rothwell]

Hi all,

Changes since 20130204:

The powerpc tree still had a build failure.

The nfsd tree lost its build.

The sound-asoc tree gained a build failure so I used the version from
next-20130204.



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 213 trees (counting Linus' and 28 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (3f4e5aa Merge branch 'x86-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (d287b87 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging kbuild-current/rc-fixes (02f3e53 Merge branch 'yem-kconfig-rc-fixes' of 
git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes)
Merging arm-current/fixes (58b9f3b ARM: DMA mapping: fix bad atomic test)
Merging m68k-current/for-linus (91a420e xtensa: Provide dummy 
dma_mmap_coherent() and dma_get_sgtable())
Merging powerpc-merge/merge (eda8eeb powerpc/mm: Fix hash computation function)
Merging sparc/master (04cef49 sparc: kernel/sbus.c: fix memory leakage)
Merging net/master (bf414b3 net: usbnet: fix tx_dropped statistics)
Merging ipsec/master (6642f91 dm9601: support dm9620 variant)
Merging sound-current/for-linus (edac894 ALSA: aloop: Fix Oops while PM resume)
Merging pci-current/for-linus (444ee9b PCI: remove depends on 
CONFIG_EXPERIMENTAL)
Merging wireless/master (7b2385b brcmsmac: rework of mac80211 .flush() callback 
operation)
Merging driver-core.current/driver-core-linus (7d1f9ae Linux 3.8-rc4)
Merging tty.current/tty-linus (949db15 Linux 3.8-rc5)
Merging usb.current/usb-linus (200e0d9 USB: storage: optimize to match the 
Huawei USB storage devices and support new switch command)
Merging staging.current/staging-linus (949db15 Linux 3.8-rc5)
Merging char-misc.current/char-misc-linus (949db15 Linux 3.8-rc5)
Merging input-current/for-linus (9937c02 Input: wacom - fix wacom_set_report 
retry logic)
Merging md-current/for-linus (0ecfa11 md: protect against crash upon fsync on 
ro array)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (a2c0911 crypto: caam - Updated SEC-4.0 device 
tree binding for ERA information.)
Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops)
Merging dwmw2/master (084a0ec x86: add CONFIG_X86_MOVBE option)
CONFLICT (content): Merge conflict in arch/x86/Kconfig
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3.6)
Merging devicetree-current/devicetree/merge (ab28698 of: define struct device 
in of_platform.h if !OF_DEVICE and !OF_ADDRESS)
Merging spi-current/spi/merge (d3601e5 spi/sh-hspi: fix return value check in 
hspi_probe().)
Merging gpio-current/gpio/merge (bc1008c gpio/mvebu-gpio: Make mvebu-gpio 
depend on OF_CONFIG)
Merging rr-fixes/fixes (b26ada9 virtio_console: Don't access uninitialized 
data.)
Merging asm-generic/master (fb9de7e xtensa: Use generic asm/mmu.h for nommu)
Merging arc/arc-next (7414cae ARC: Don't fiddle with non-existent caches)
Merging arm/for-next (96fac09 Merge branches 'devel-sta

RE: [PATCH] ARM: dts: Fix the timing property of MSHC controller

[Kukjin Kim]

Dongjin Kim wrote:
> 
> This fixes the property of dw-mshc-sdr-timing and dw-mshc-ddr-timing as
> per
> its current binding, it only has two cells.
> 
> Signed-off-by: Dongjin Kim 
> ---
>  arch/arm/boot/dts/exynos4412-odroidx.dts |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
> b/arch/arm/boot/dts/exynos4412-odroidx.dts
> index f41a84e..009a9c2 100644
> --- a/arch/arm/boot/dts/exynos4412-odroidx.dts
> +++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
> @@ -49,8 +49,8 @@
>   fifo-depth = <0x80>;
>   card-detect-delay = <200>;
>   samsung,dw-mshc-ciu-div = <3>;
> - samsung,dw-mshc-sdr-timing = <2 3 3>;
> - samsung,dw-mshc-ddr-timing = <1 2 3>;
> + samsung,dw-mshc-sdr-timing = <2 3>;
> + samsung,dw-mshc-ddr-timing = <1 2>;
> 
>   slot@0 {
>   reg = <0>;
> --
> 1.7.10.4

Looks good to me, applied.

Thanks.

- Kukjin

--
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 3/4] acpi: add clock_domain field to acpi_srat_cpu_affinity

[David Rientjes]

On Tue, 5 Feb 2013, liguang wrote:

> according to ACPI SPEC v5.0, page 152,
> 5.2.16.1 Processor Local APIC/SAPIC Affinity Structure,
> the last member of it is clock_domain.
> 
> Signed-off-by: liguang 

Acked-by: David Rientjes 
--
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] f2fs: add compat_ioctl to provide backward compatability

[Namjae Jeon]

Hi Jaegeuk.

Oops!, I was missing include header.
Sorry, I will send v2 patch again.

Thanks.

2013/2/4, Namjae Jeon :
> From: Namjae Jeon 
>
> adding compat_ioctl to provide support for backward comptability - 32bit
> binary
> execution on 64bit kernel.
>
> Signed-off-by: Namjae Jeon 
> Signed-off-by: Amit Sahrawat 
> ---
>  fs/f2fs/f2fs.h |   15 +++
>  fs/f2fs/file.c |   20 
>  2 files changed, 35 insertions(+)
>
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 58dd608..7bf86c8 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -104,6 +104,20 @@ static inline int update_sits_in_cursum(struct
> f2fs_summary_block *rs, int i)
>  }
>
>  /*
> + * ioctl commands
> + */
> +#define F2FS_IOC_GETFLAGS   FS_IOC_GETFLAGS
> +#define F2FS_IOC_SETFLAGS   FS_IOC_SETFLAGS
> +
> +#if defined(__KERNEL__) && defined(CONFIG_COMPAT)
> +/*
> + * ioctl commands in 32 bit emulation
> + */
> +#define F2FS_IOC32_GETFLAGS FS_IOC32_GETFLAGS
> +#define F2FS_IOC32_SETFLAGS FS_IOC32_SETFLAGS
> +#endif
> +
> +/*
>   * For INODE and NODE manager
>   */
>  #define XATTR_NODE_OFFSET(-1)/*
> @@ -850,6 +864,7 @@ void f2fs_truncate(struct inode *);
>  int f2fs_setattr(struct dentry *, struct iattr *);
>  int truncate_hole(struct inode *, pgoff_t, pgoff_t);
>  long f2fs_ioctl(struct file *, unsigned int, unsigned long);
> +long f2fs_compat_ioctl(struct file *, unsigned int, unsigned long);
>
>  /*
>   * inode.c
> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> index 633667e..e79d26a 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -644,6 +644,23 @@ out:
>   }
>  }
>
> +#ifdef CONFIG_COMPAT
> +long f2fs_compat_ioctl(struct file *file, unsigned int cmd, unsigned long
> arg)
> +{
> + switch (cmd) {
> + case F2FS_IOC32_GETFLAGS:
> + cmd = F2FS_IOC_GETFLAGS;
> + break;
> + case F2FS_IOC32_SETFLAGS:
> + cmd = F2FS_IOC_SETFLAGS;
> + break;
> + default:
> + return -ENOIOCTLCMD;
> + }
> + return f2fs_ioctl(file, cmd, (unsigned long) compat_ptr(arg));
> +}
> +#endif
> +
>  const struct file_operations f2fs_file_operations = {
>   .llseek = generic_file_llseek,
>   .read   = do_sync_read,
> @@ -655,6 +672,9 @@ const struct file_operations f2fs_file_operations = {
>   .fsync  = f2fs_sync_file,
>   .fallocate  = f2fs_fallocate,
>   .unlocked_ioctl = f2fs_ioctl,
> +#ifdef CONFIG_COMPAT
> + .compat_ioctl   = f2fs_compat_ioctl,
> +#endif
>   .splice_read= generic_file_splice_read,
>   .splice_write   = generic_file_splice_write,
>  };
> --
> 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 v2 2/4] numa: avoid export acpi_numa variable

[Yasuaki Ishimatsu]

2013/02/05 11:37, liguang wrote:
> acpi_numa is used to prevent srat table
> being parsed, seems a little miss-named,
> if 'noacpi' was specified by cmdline and
> CONFIG_ACPI_NUMA was enabled, acpi_numa
> will be operated directly from everywhere
> it needed to disable/enable numa in acpi
> mode which was a bad thing, so, try to
> export a fuction to get srat table
> enable/disable info.

The patch is wrong.
By the patch, acpi_numa is set to one of three values, either -1, false(0), 1.
By this, x86_acpi_numa_init() goes wrong.

How about using bool to acpi_numa?

Thanks,
Yasuaki Ishimatsu

> Reviewed-by: David Rientjes 
> Signed-off-by: liguang 
> ---
>   arch/x86/include/asm/acpi.h |2 +-
>   arch/x86/kernel/acpi/srat.c |   15 ++-
>   arch/x86/mm/numa.c  |2 +-
>   arch/x86/xen/enlighten.c|2 +-
>   4 files changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
> index 0c44630..6b9c861 100644
> --- a/arch/x86/include/asm/acpi.h
> +++ b/arch/x86/include/asm/acpi.h
> @@ -181,7 +181,7 @@ static inline void disable_acpi(void) { }
>   #define ARCH_HAS_POWER_INIT 1
>   
>   #ifdef CONFIG_ACPI_NUMA
> -extern int acpi_numa;
> +extern void disable_acpi_numa(void);
>   extern int x86_acpi_numa_init(void);
>   #endif /* CONFIG_ACPI_NUMA */
>   
> diff --git a/arch/x86/kernel/acpi/srat.c b/arch/x86/kernel/acpi/srat.c
> index 4ddf497..0a4d7ee 100644
> --- a/arch/x86/kernel/acpi/srat.c
> +++ b/arch/x86/kernel/acpi/srat.c
> @@ -24,22 +24,27 @@
>   #include 
>   #include 
>   
> -int acpi_numa __initdata;
> +static bool acpi_numa __initdata;
>   
>   static __init int setup_node(int pxm)
>   {
>   return acpi_map_pxm_to_node(pxm);
>   }
>   
> -static __init void bad_srat(void)
> +void __init disable_acpi_numa(void)
> +{
> + acpi_numa = false;
> +}
> +
> +static void __init bad_srat(void)
>   {
> - printk(KERN_ERR "SRAT: SRAT not used.\n");
>   acpi_numa = -1;
> + printk(KERN_ERR "SRAT: SRAT will not be used.\n");
>   }
>   
> -static __init inline int srat_disabled(void)
> +static bool __init srat_disabled(void)
>   {
> - return acpi_numa < 0;
> + return acpi_numa;
>   }
>   
>   /* Callback for SLIT parsing */
> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> index 2d125be..870ca6b 100644
> --- a/arch/x86/mm/numa.c
> +++ b/arch/x86/mm/numa.c
> @@ -47,7 +47,7 @@ static __init int numa_setup(char *opt)
>   #endif
>   #ifdef CONFIG_ACPI_NUMA
>   if (!strncmp(opt, "noacpi", 6))
> - acpi_numa = -1;
> + disable_acpi_numa();
>   #endif
>   return 0;
>   }
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 138e566..a5f6353 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1415,7 +1415,7 @@ asmlinkage void __init xen_start_kernel(void)
>* any NUMA information the kernel tries to get from ACPI will
>* be meaningless.  Prevent it from trying.
>*/
> - acpi_numa = -1;
> + disable_acpi_numa();
>   #endif
>   
>   /* Don't do the full vcpu_info placement stuff until we have a
> 


--
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/2] mm: hotplug: implement non-movable version of get_user_pages() to kill long-time pin pages

[Minchan Kim]

Hi Lin,

On Tue, Feb 05, 2013 at 12:42:48PM +0800, Lin Feng wrote:
> Hi Minchan,
> 
> On 02/05/2013 08:58 AM, Minchan Kim wrote:
> > Hello,
> > 
> > On Mon, Feb 04, 2013 at 06:04:06PM +0800, Lin Feng wrote:
> >> Currently get_user_pages() always tries to allocate pages from movable 
> >> zone,
> >> as discussed in thread https://lkml.org/lkml/2012/11/29/69, in some case 
> >> users
> >> of get_user_pages() is easy to pin user pages for a long time(for now we 
> >> found
> >> that pages pinned as aio ring pages is such case), which is fatal for 
> >> memory
> >> hotplug/remove framework.
> >>
> >> So the 1st patch introduces a new library function called
> >> get_user_pages_non_movable() to pin pages only from zone non-movable in 
> >> memory.
> >> It's a wrapper of get_user_pages() but it makes sure that all pages come 
> >> from
> >> non-movable zone via additional page migration.
> >>
> >> The 2nd patch gets around the aio ring pages can't be migrated bug caused 
> >> by
> >> get_user_pages() via using the new function. It only works when configed 
> >> with
> >> CONFIG_MEMORY_HOTREMOVE, otherwise it uses the old version of 
> >> get_user_pages().
> > 
> > CMA has same issue but the problem is the driver developers or any subsystem
> > using GUP can't know their pages is in CMA area or not in advance.
> > So all of client of GUP should use GUP_NM to work them with 
> > CMA/MEMORY_HOTPLUG well?
> > Even some driver module in embedded side doesn't open their source code.
> Yes, it somehow depends on the users of GUP. In MEMORY_HOTPLUG case, as for 
> most users
> of GUP, they will release the pinned pages immediately and to such users they 
> should get
> a good performance, using the old style interface is a smart way. And we had 
> better just
> deal with the cases we have to by using the new interface.

Hmm, I think you can't make sure most of user for MEMORY_HOTPLUG will release 
pinned pages
immediately. Because MEMORY_HOTPLUG could be used for embedded system for 
reducing power
by PASR and some drivers in embedded could use GUP anytime and anywhere. They 
can't know
in advance they will use pinned pages long time or release in short time 
because it depends
on some event like user's response which is very not predetermined.
So for solving it, we can add some WARN_ON in CMA/MEMORY_HOTPLUG part just in 
case of
failing migration by page count and then, investigate they are really using GUP 
and it's
REALLY a culprit. If so, yell to them "Please use GUP_NM instead"?

Yes. it could be done but it would be rather trobulesome job.

>   
> > 
> > I would like to make GUP smart so it allocates a page from 
> > non-movable/non-cma area
> > when memory-hotplug/cma is enabled(CONFIG_MIGRATE_ISOLATE). Yeb. it might 
> > hurt GUP
> > performance but it is just trade-off for using CMA/memory-hotplug, IMHO. :(
> As I debuged the get_user_pages(), I found that some pages is already there 
> and may be
> allocated before we call get_user_pages(). __get_user_pages() have following 
> logic to
> handle such case.
> 1786 while (!(page = follow_page(vma, start, 
> foll_flags))) {
> 1787 int ret;
> To such case an additional alloc-flag or such doesn't work, it's difficult to 
> keep GUP
> as smart as we want :( , so I worked out the migration approach to get around 
> and 
> avoid messing up the current code :)

I didn't look at your code in detail yet but What's wrong following this?

Change curret GUP with old_GUP.

#ifdef CONFIG_MIGRATE_ISOLATE

int get_user_pages_non_movable()
{
..
old_get_user_pages()
..
}

int get_user_pages()
{
return get_user_pages_non_movable();
}
#else
int get_user_pages()
{
return old_get_user_pages()
}
#endif

> 
> thanks,
> linfeng 
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: break circular include from linux/mmzone.h

[David Rientjes]

On Tue, 5 Feb 2013, liguang wrote:

> linux/mmzone.h included linux/memory_hotplug.h,
> and linux/memory_hotplug.h also included
> linux/mmzone.h, so there's a bad cirlular.
> 

And both of these are protected by _LINUX_MMZONE_H and 
__LINUX_MEMORY_HOTPLUG_H, respectively, so what's the problem?
--
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: [PATCHv5,RESEND 8/8] drm: tegra: Add gr2d device

[Terje Bergström]

On 04.02.2013 04:56, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Tue, Jan 15, 2013 at 01:44:04PM +0200, Terje Bergstrom wrote:
> [...]
>> diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
>> @@ -270,7 +274,29 @@ static int tegra_drm_unload(struct drm_device *drm)
>>
>>  static int tegra_drm_open(struct drm_device *drm, struct drm_file *filp)
>>  {
>> - return 0;
>> + struct host1x_drm_fpriv *fpriv;
>> + int err = 0;
> 
> Can be dropped.
> 
>> +
>> + fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL);
>> + if (!fpriv)
>> + return -ENOMEM;
>> +
>> + INIT_LIST_HEAD(>contexts);
>> + filp->driver_priv = fpriv;
>> +
>> + return err;
> 
> return 0;

Ok.

> 
>> +static void tegra_drm_close(struct drm_device *drm, struct drm_file *filp)
>> +{
>> + struct host1x_drm_fpriv *fpriv = host1x_drm_fpriv(filp);
>> + struct host1x_drm_context *context, *tmp;
>> +
>> + list_for_each_entry_safe(context, tmp, >contexts, list) {
>> + context->client->ops->close_channel(context);
>> + kfree(context);
>> + }
>> + kfree(fpriv);
>>  }
> 
> Maybe you should add host1x_drm_context_free() to wrap the loop
> contents?

Makes sense. Will do.

> 
>> @@ -280,7 +306,204 @@ static void tegra_drm_lastclose(struct drm_device *drm)
>>   drm_fbdev_cma_restore_mode(host1x->fbdev);
>>  }
>>
>> +static int
>> +tegra_drm_ioctl_syncpt_read(struct drm_device *drm, void *data,
>> +  struct drm_file *file_priv)
> 
> static int and function name on one line, please.

Ok, will re-split the lines.

> 
>> +{
>> + struct host1x *host1x = drm->dev_private;
>> + struct tegra_drm_syncpt_read_args *args = data;
>> + struct host1x_syncpt *sp =
>> + host1x_syncpt_get_bydev(host1x->dev, args->id);
> 
> I don't know if we need this, except maybe to work around the problem
> that we have two different structures named host1x. The _bydev() suffix
> is misleading because all you really do here is obtain the syncpt from
> the host1x.

Yeah, it's actually working around the host1x duplicate naming.
host1x_syncpt_get takes struct host1x as parameter, but that's different
host1x than in this code.

> 
>> +static int
>> +tegra_drm_ioctl_open_channel(struct drm_device *drm, void *data,
>> +  struct drm_file *file_priv)
>> +{
>> + struct tegra_drm_open_channel_args *args = data;
>> + struct host1x_client *client;
>> + struct host1x_drm_context *context;
>> + struct host1x_drm_fpriv *fpriv = host1x_drm_fpriv(file_priv);
>> + struct host1x *host1x = drm->dev_private;
>> + int err = 0;
> 
> err = -ENODEV; (see below)

Ok, makes sense.

> 
>> +
>> + context = kzalloc(sizeof(*context), GFP_KERNEL);
>> + if (!context)
>> + return -ENOMEM;
>> +
>> + list_for_each_entry(client, >clients, list) {
>> + if (client->class == args->class) {
>> + context->client = client;
>> + err = client->ops->open_channel(client, context);
>> + if (err)
>> + goto out;
>> +
>> + list_add(>list, >contexts);
>> + args->context = (uintptr_t)context;
> 
> Perhaps cast this to __u64 directly instead? There's little sense in
> taking the detour via uintptr_t.

I think compiler complained about a direct cast to __u64, but I'll try
again.

> 
>> + goto out;
> 
> return 0;
> 
>> + }
>> + }
>> + err = -ENODEV;
>> +
>> +out:
>> + if (err)
>> + kfree(context);
>> +
>> + return err;
>> +}
> 
> Then this simply becomes:
> 
> kfree(context);
> return err;

Sounds good.

> 
>> +static int
>> +tegra_drm_ioctl_close_channel(struct drm_device *drm, void *data,
>> +  struct drm_file *file_priv)
>> +{
>> + struct tegra_drm_open_channel_args *args = data;
>> + struct host1x_drm_context *context, *tmp;
>> + struct host1x_drm_fpriv *fpriv = host1x_drm_fpriv(file_priv);
>> + int err = 0;
>> +
>> + list_for_each_entry_safe(context, tmp, >contexts, list) {
>> + if ((uintptr_t)context == args->context) {
>> + context->client->ops->close_channel(context);
>> + list_del(>list);
>> + kfree(context);
>> + goto out;
>> + }
>> + }
>> + err = -EINVAL;
>> +
>> +out:
>> + return err;
>> +}
> 
> Same comments as for tegra_drm_ioctl_open_channel().

Ok, will apply.

> 
>> +static int
>> +tegra_drm_ioctl_get_syncpoint(struct drm_device *drm, void *data,
>> +  struct drm_file *file_priv)
>> +{
>> + struct tegra_drm_get_channel_param_args *args = data;
>> + struct host1x_drm_context *context;
>> + struct host1x_drm_fpriv *fpriv = host1x_drm_fpriv(file_priv);
>> + int err = 0;
>> +
>> + 

[PATCH] acpi: change Makefile for srat.c building

[liguang]

this patch is an addition of the previous
patch-set v2 acpi: do some changes for numa info,
aimed to bring back the lost Makefile changes.
mail-archive-address:
http://lkml.indiana.edu/hypermail/linux/kernel/1302.0/02107.html

Signed-off-by: liguang 
---
 arch/x86/kernel/acpi/Makefile |1 +
 arch/x86/mm/Makefile  |1 -
 2 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/acpi/Makefile b/arch/x86/kernel/acpi/Makefile
index 163b225..e24b64d 100644
--- a/arch/x86/kernel/acpi/Makefile
+++ b/arch/x86/kernel/acpi/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_ACPI) += boot.o
 obj-$(CONFIG_ACPI_SLEEP)   += sleep.o wakeup_$(BITS).o
+obj-$(CONFIG_ACPI_NUMA) += srat.o
 
 ifneq ($(CONFIG_ACPI_PROCESSOR),)
 obj-y  += cstate.o
diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile
index 23d8e5f..d6f3692 100644
--- a/arch/x86/mm/Makefile
+++ b/arch/x86/mm/Makefile
@@ -24,7 +24,6 @@ obj-$(CONFIG_MMIOTRACE_TEST)  += testmmiotrace.o
 
 obj-$(CONFIG_NUMA) += numa.o numa_$(BITS).o
 obj-$(CONFIG_AMD_NUMA) += amdtopology.o
-obj-$(CONFIG_ACPI_NUMA)+= srat.o
 obj-$(CONFIG_NUMA_EMU) += numa_emulation.o
 
 obj-$(CONFIG_MEMTEST)  += memtest.o
-- 
1.7.2.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] pm: print the name of failed suspend function for platform device

[fli24]

Print more info when platform device suspend function failed.
Without this patch, we can not get the real platform device suspend
API info.

Example without this patch:
pm_op(): platform_pm_suspend+0x0/0x50 returns -11
PM: Device power.0 failed to suspend: error -11

And with this patch:
platform_pm_suspend(): power_suspend+0x0/0x30 returns -11
pm_op(): platform_pm_suspend+0x0/0x80 returns -11
PM: Device power.0 failed to suspend: error -11

Signed-off-by: liu chuansheng 
Signed-off-by: Li Fei 
---
 drivers/base/platform.c |   19 +++
 1 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index c0b8df3..96a452a 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -747,8 +747,10 @@ static int platform_legacy_suspend(struct device *dev, 
pm_message_t mesg)
struct platform_device *pdev = to_platform_device(dev);
int ret = 0;
 
-   if (dev->driver && pdrv->suspend)
+   if (dev->driver && pdrv->suspend) {
ret = pdrv->suspend(pdev, mesg);
+   suspend_report_result(pdrv->suspend, ret);
+   }
 
return ret;
 }
@@ -778,10 +780,13 @@ int platform_pm_suspend(struct device *dev)
return 0;
 
if (drv->pm) {
-   if (drv->pm->suspend)
+   if (drv->pm->suspend) {
ret = drv->pm->suspend(dev);
+   suspend_report_result(drv->pm->suspend, ret);
+   }
} else {
ret = platform_legacy_suspend(dev, PMSG_SUSPEND);
+   suspend_report_result(platform_legacy_suspend, ret);
}
 
return ret;
@@ -818,10 +823,13 @@ int platform_pm_freeze(struct device *dev)
return 0;
 
if (drv->pm) {
-   if (drv->pm->freeze)
+   if (drv->pm->freeze) {
ret = drv->pm->freeze(dev);
+   suspend_report_result(drv->pm->freeze, ret);
+   }
} else {
ret = platform_legacy_suspend(dev, PMSG_FREEZE);
+   suspend_report_result(platform_legacy_suspend, ret);
}
 
return ret;
@@ -854,10 +862,13 @@ int platform_pm_poweroff(struct device *dev)
return 0;
 
if (drv->pm) {
-   if (drv->pm->poweroff)
+   if (drv->pm->poweroff) {
ret = drv->pm->poweroff(dev);
+   suspend_report_result(drv->pm->poweroff, ret);
+   }
} else {
ret = platform_legacy_suspend(dev, PMSG_HIBERNATE);
+   suspend_report_result(platform_legacy_suspend, ret);
}
 
return ret;
-- 
1.7.4.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 2/2] fs/aio.c: use get_user_pages_non_movable() to pin ring pages when support memory hotremove

[Lin Feng]

Hi Jeff,

On 02/04/2013 11:18 PM, Jeff Moyer wrote:
>> ---
>>  fs/aio.c | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/fs/aio.c b/fs/aio.c
>> index 71f613c..0e9b30a 100644
>> --- a/fs/aio.c
>> +++ b/fs/aio.c
>> @@ -138,9 +138,15 @@ static int aio_setup_ring(struct kioctx *ctx)
>>  }
>>  
>>  dprintk("mmap address: 0x%08lx\n", info->mmap_base);
>> +#ifdef CONFIG_MEMORY_HOTREMOVE
>> +info->nr_pages = get_user_pages_non_movable(current, ctx->mm,
>> +info->mmap_base, nr_pages,
>> +1, 0, info->ring_pages, NULL);
>> +#else
>>  info->nr_pages = get_user_pages(current, ctx->mm,
>>  info->mmap_base, nr_pages, 
>>  1, 0, info->ring_pages, NULL);
>> +#endif
> 
> Can't you hide this in your 1/1 patch, by providing this function as
> just a static inline wrapper around get_user_pages when
> CONFIG_MEMORY_HOTREMOVE is not enabled?
Good idea, it makes the callers more neatly :)

thanks,
linfeng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c

[li guang]

在 2013-02-05二的 13:44 +0900，Yasuaki Ishimatsu写道：
> Hi Liguang,
> 
> 2013/02/05 11:37, liguang wrote:
> > srat table should present only on acpi domain,
> > seems mm/ is not the right place for it.
> > 
> > Reviewed-by: David Rientjes 
> > Signed-off-by: liguang 
> > ---
> >
> >   arch/x86/kernel/acpi/srat.c |  197 
> > +++
> >   arch/x86/mm/srat.c  |  197 
> > ---
> >   2 files changed, 197 insertions(+), 197 deletions(-)
> >   create mode 100644 arch/x86/kernel/acpi/srat.c
> >   delete mode 100644 arch/x86/mm/srat.c
> 
> Changes of Makefile disappeared.
> 
> Thanks,
> Yasuaki Ishimatsu

Oh, fogot it, 
Thank you so much for reminding me!

> 
> > 
> > diff --git a/arch/x86/kernel/acpi/srat.c b/arch/x86/kernel/acpi/srat.c
> > new file mode 100644
> > index 000..4ddf497
> > --- /dev/null
> > +++ b/arch/x86/kernel/acpi/srat.c
> > @@ -0,0 +1,197 @@
> > +/*
> > + * ACPI 3.0 based NUMA setup
> > + * Copyright 2004 Andi Kleen, SuSE Labs.
> > + *
> > + * Reads the ACPI SRAT table to figure out what memory belongs to which 
> > CPUs.
> > + *
> > + * Called from acpi_numa_init while reading the SRAT and SLIT tables.
> > + * Assumes all memory regions belonging to a single proximity domain
> > + * are in one chunk. Holes between them will be included in the node.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +int acpi_numa __initdata;
> > +
> > +static __init int setup_node(int pxm)
> > +{
> > +   return acpi_map_pxm_to_node(pxm);
> > +}
> > +
> > +static __init void bad_srat(void)
> > +{
> > +   printk(KERN_ERR "SRAT: SRAT not used.\n");
> > +   acpi_numa = -1;
> > +}
> > +
> > +static __init inline int srat_disabled(void)
> > +{
> > +   return acpi_numa < 0;
> > +}
> > +
> > +/* Callback for SLIT parsing */
> > +void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
> > +{
> > +   int i, j;
> > +
> > +   for (i = 0; i < slit->locality_count; i++)
> > +   for (j = 0; j < slit->locality_count; j++)
> > +   numa_set_distance(pxm_to_node(i), pxm_to_node(j),
> > +   slit->entry[slit->locality_count * i + j]);
> > +}
> > +
> > +/* Callback for Proximity Domain -> x2APIC mapping */
> > +void __init
> > +acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
> > +{
> > +   int pxm, node;
> > +   int apic_id;
> > +
> > +   if (srat_disabled())
> > +   return;
> > +   if (pa->header.length < sizeof(struct acpi_srat_x2apic_cpu_affinity)) {
> > +   bad_srat();
> > +   return;
> > +   }
> > +   if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0)
> > +   return;
> > +   pxm = pa->proximity_domain;
> > +   apic_id = pa->apic_id;
> > +   if (!apic->apic_id_valid(apic_id)) {
> > +   printk(KERN_INFO "SRAT: PXM %u -> X2APIC 0x%04x ignored\n",
> > +pxm, apic_id);
> > +   return;
> > +   }
> > +   node = setup_node(pxm);
> > +   if (node < 0) {
> > +   printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
> > +   bad_srat();
> > +   return;
> > +   }
> > +
> > +   if (apic_id >= MAX_LOCAL_APIC) {
> > +   printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u 
> > skipped apicid that is too big\n", pxm, apic_id, node);
> > +   return;
> > +   }
> > +   set_apicid_to_node(apic_id, node);
> > +   node_set(node, numa_nodes_parsed);
> > +   acpi_numa = 1;
> > +   printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u\n",
> > +  pxm, apic_id, node);
> > +}
> > +
> > +/* Callback for Proximity Domain -> LAPIC mapping */
> > +void __init
> > +acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
> > +{
> > +   int pxm, node;
> > +   int apic_id;
> > +
> > +   if (srat_disabled())
> > +   return;
> > +   if (pa->header.length != sizeof(struct acpi_srat_cpu_affinity)) {
> > +   bad_srat();
> > +   return;
> > +   }
> > +   if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0)
> > +   return;
> > +   pxm = pa->proximity_domain_lo;
> > +   if (acpi_srat_revision >= 2)
> > +   pxm |= *((unsigned int*)pa->proximity_domain_hi) << 8;
> > +   node = setup_node(pxm);
> > +   if (node < 0) {
> > +   printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
> > +   bad_srat();
> > +   return;
> > +   }
> > +
> > +   if (get_uv_system_type() >= UV_X2APIC)
> > +   apic_id = (pa->apic_id << 8) | pa->local_sapic_eid;
> > +   else
> > +   apic_id = pa->apic_id;
> > +
> > +   if (apic_id >= MAX_LOCAL_APIC) {
> > +   printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u 
> > skipped apicid that is too big\n", pxm, apic_id, node);
> > +   return;
> > +   }
> > +
> > +   

Re: [PATCHv5,RESEND 7/8] ARM: tegra: Add board data and 2D clocks

[Terje Bergström]

On 04.02.2013 03:26, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Tue, Jan 15, 2013 at 01:44:03PM +0200, Terje Bergstrom wrote:
>> Add a driver alias gr2d for Tegra 2D device, and assign a duplicate
>> of 2D clock to that driver alias.
>>
>> Signed-off-by: Terje Bergstrom 
>> ---
>>  arch/arm/mach-tegra/board-dt-tegra20.c|1 +
>>  arch/arm/mach-tegra/board-dt-tegra30.c|1 +
>>  arch/arm/mach-tegra/tegra20_clocks_data.c |2 +-
>>  arch/arm/mach-tegra/tegra30_clocks_data.c |1 +
>>  4 files changed, 4 insertions(+), 1 deletion(-)
> 
> With Prashant's clock rework patches now merged this patch can be
> dropped.

Yes, and I'll also need to start calling 2D clock with name NULL in gr2d.c.

Terje
--
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: [PATCHv5,RESEND 5/8] drm: tegra: Move drm to live under host1x

[Terje Bergström]

On 04.02.2013 03:08, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Tue, Jan 15, 2013 at 01:44:01PM +0200, Terje Bergstrom wrote:
> [...]
>> diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
>> index 697d49a..ffc8bf1 100644
>> --- a/drivers/gpu/host1x/Makefile
>> +++ b/drivers/gpu/host1x/Makefile
>> @@ -12,4 +12,10 @@ host1x-y = \
>>  hw/host1x01.o
>>  
>>  host1x-$(CONFIG_TEGRA_HOST1X_CMA) += cma.o
>> +
>> +ccflags-y += -Iinclude/drm
>> +ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG
>> +
>> +host1x-$(CONFIG_DRM_TEGRA) += drm/drm.o drm/fb.o drm/dc.o drm/host1x.o
>> +host1x-$(CONFIG_DRM_TEGRA) += drm/output.o drm/rgb.o drm/hdmi.o
>>  obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
> 
> Can this be moved into a separate Makefile in the drm subdirectory?

I tried, and kernel build helpfully created two .ko files. As having
cyclic dependencies between two modules isn't nice, I merged them to
same module and that seemed to force merging Makefile.

If anybody has an idea on how to do it otherwise, I'd be happy to keep
the Makefiles separate.

> 
>> diff --git a/drivers/gpu/host1x/host1x_client.h 
>> b/drivers/gpu/host1x/host1x_client.h
> [...]
>> new file mode 100644
>> index 000..fdd2920
>> --- /dev/null
>> +++ b/drivers/gpu/host1x/host1x_client.h
>> @@ -0,0 +1,25 @@
>> +/*
>> + * Copyright (c) 2013, NVIDIA Corporation.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see .
>> + */
>> +
>> +#ifndef HOST1X_CLIENT_H
>> +#define HOST1X_CLIENT_H
>> +
>> +struct platform_device;
>> +
>> +void host1x_set_drm_data(struct platform_device *pdev, void *data);
>> +void *host1x_get_drm_data(struct platform_device *pdev);
>> +
>> +#endif
> 
> These aren't defined or used yet.

Hmm, right, they would go to patch 7.

Terje
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c

[Yasuaki Ishimatsu]

Hi Liguang,

2013/02/05 11:37, liguang wrote:
> srat table should present only on acpi domain,
> seems mm/ is not the right place for it.
> 
> Reviewed-by: David Rientjes 
> Signed-off-by: liguang 
> ---
>
>   arch/x86/kernel/acpi/srat.c |  197 
> +++
>   arch/x86/mm/srat.c  |  197 
> ---
>   2 files changed, 197 insertions(+), 197 deletions(-)
>   create mode 100644 arch/x86/kernel/acpi/srat.c
>   delete mode 100644 arch/x86/mm/srat.c

Changes of Makefile disappeared.

Thanks,
Yasuaki Ishimatsu

> 
> diff --git a/arch/x86/kernel/acpi/srat.c b/arch/x86/kernel/acpi/srat.c
> new file mode 100644
> index 000..4ddf497
> --- /dev/null
> +++ b/arch/x86/kernel/acpi/srat.c
> @@ -0,0 +1,197 @@
> +/*
> + * ACPI 3.0 based NUMA setup
> + * Copyright 2004 Andi Kleen, SuSE Labs.
> + *
> + * Reads the ACPI SRAT table to figure out what memory belongs to which CPUs.
> + *
> + * Called from acpi_numa_init while reading the SRAT and SLIT tables.
> + * Assumes all memory regions belonging to a single proximity domain
> + * are in one chunk. Holes between them will be included in the node.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +int acpi_numa __initdata;
> +
> +static __init int setup_node(int pxm)
> +{
> + return acpi_map_pxm_to_node(pxm);
> +}
> +
> +static __init void bad_srat(void)
> +{
> + printk(KERN_ERR "SRAT: SRAT not used.\n");
> + acpi_numa = -1;
> +}
> +
> +static __init inline int srat_disabled(void)
> +{
> + return acpi_numa < 0;
> +}
> +
> +/* Callback for SLIT parsing */
> +void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
> +{
> + int i, j;
> +
> + for (i = 0; i < slit->locality_count; i++)
> + for (j = 0; j < slit->locality_count; j++)
> + numa_set_distance(pxm_to_node(i), pxm_to_node(j),
> + slit->entry[slit->locality_count * i + j]);
> +}
> +
> +/* Callback for Proximity Domain -> x2APIC mapping */
> +void __init
> +acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
> +{
> + int pxm, node;
> + int apic_id;
> +
> + if (srat_disabled())
> + return;
> + if (pa->header.length < sizeof(struct acpi_srat_x2apic_cpu_affinity)) {
> + bad_srat();
> + return;
> + }
> + if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0)
> + return;
> + pxm = pa->proximity_domain;
> + apic_id = pa->apic_id;
> + if (!apic->apic_id_valid(apic_id)) {
> + printk(KERN_INFO "SRAT: PXM %u -> X2APIC 0x%04x ignored\n",
> +  pxm, apic_id);
> + return;
> + }
> + node = setup_node(pxm);
> + if (node < 0) {
> + printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
> + bad_srat();
> + return;
> + }
> +
> + if (apic_id >= MAX_LOCAL_APIC) {
> + printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u 
> skipped apicid that is too big\n", pxm, apic_id, node);
> + return;
> + }
> + set_apicid_to_node(apic_id, node);
> + node_set(node, numa_nodes_parsed);
> + acpi_numa = 1;
> + printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u\n",
> +pxm, apic_id, node);
> +}
> +
> +/* Callback for Proximity Domain -> LAPIC mapping */
> +void __init
> +acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
> +{
> + int pxm, node;
> + int apic_id;
> +
> + if (srat_disabled())
> + return;
> + if (pa->header.length != sizeof(struct acpi_srat_cpu_affinity)) {
> + bad_srat();
> + return;
> + }
> + if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0)
> + return;
> + pxm = pa->proximity_domain_lo;
> + if (acpi_srat_revision >= 2)
> + pxm |= *((unsigned int*)pa->proximity_domain_hi) << 8;
> + node = setup_node(pxm);
> + if (node < 0) {
> + printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
> + bad_srat();
> + return;
> + }
> +
> + if (get_uv_system_type() >= UV_X2APIC)
> + apic_id = (pa->apic_id << 8) | pa->local_sapic_eid;
> + else
> + apic_id = pa->apic_id;
> +
> + if (apic_id >= MAX_LOCAL_APIC) {
> + printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u 
> skipped apicid that is too big\n", pxm, apic_id, node);
> + return;
> + }
> +
> + set_apicid_to_node(apic_id, node);
> + node_set(node, numa_nodes_parsed);
> + acpi_numa = 1;
> + printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u\n",
> +pxm, apic_id, node);
> +}
> +
> +#ifdef CONFIG_MEMORY_HOTPLUG
> +static inline int save_add_info(void) {return 1;}
> +#else
> 

Re: [PATCH 0/2] mm: hotplug: implement non-movable version of get_user_pages() to kill long-time pin pages

[Lin Feng]

Hi Minchan,

On 02/05/2013 08:58 AM, Minchan Kim wrote:
> Hello,
> 
> On Mon, Feb 04, 2013 at 06:04:06PM +0800, Lin Feng wrote:
>> Currently get_user_pages() always tries to allocate pages from movable zone,
>> as discussed in thread https://lkml.org/lkml/2012/11/29/69, in some case 
>> users
>> of get_user_pages() is easy to pin user pages for a long time(for now we 
>> found
>> that pages pinned as aio ring pages is such case), which is fatal for memory
>> hotplug/remove framework.
>>
>> So the 1st patch introduces a new library function called
>> get_user_pages_non_movable() to pin pages only from zone non-movable in 
>> memory.
>> It's a wrapper of get_user_pages() but it makes sure that all pages come from
>> non-movable zone via additional page migration.
>>
>> The 2nd patch gets around the aio ring pages can't be migrated bug caused by
>> get_user_pages() via using the new function. It only works when configed with
>> CONFIG_MEMORY_HOTREMOVE, otherwise it uses the old version of 
>> get_user_pages().
> 
> CMA has same issue but the problem is the driver developers or any subsystem
> using GUP can't know their pages is in CMA area or not in advance.
> So all of client of GUP should use GUP_NM to work them with 
> CMA/MEMORY_HOTPLUG well?
> Even some driver module in embedded side doesn't open their source code.
Yes, it somehow depends on the users of GUP. In MEMORY_HOTPLUG case, as for 
most users
of GUP, they will release the pinned pages immediately and to such users they 
should get
a good performance, using the old style interface is a smart way. And we had 
better just
deal with the cases we have to by using the new interface.
  
> 
> I would like to make GUP smart so it allocates a page from 
> non-movable/non-cma area
> when memory-hotplug/cma is enabled(CONFIG_MIGRATE_ISOLATE). Yeb. it might 
> hurt GUP
> performance but it is just trade-off for using CMA/memory-hotplug, IMHO. :(
As I debuged the get_user_pages(), I found that some pages is already there and 
may be
allocated before we call get_user_pages(). __get_user_pages() have following 
logic to
handle such case.
1786 while (!(page = follow_page(vma, start, 
foll_flags))) {
1787 int ret;
To such case an additional alloc-flag or such doesn't work, it's difficult to 
keep GUP
as smart as we want :( , so I worked out the migration approach to get around 
and 
avoid messing up the current code :)

thanks,
linfeng 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 3/3] ARM: mm: use static_vm for managing static mapped areas

[Nicolas Pitre]

On Tue, 5 Feb 2013, Joonsoo Kim wrote:

> A static mapped area is ARM-specific, so it is better not to use
> generic vmalloc data structure, that is, vmlist and vmlist_lock
> for managing static mapped area. And it causes some needless overhead and
> reducing this overhead is better idea.
> 
> Now, we have newly introduced static_vm infrastructure.
> With it, we don't need to iterate all mapped areas. Instead, we just
> iterate static mapped areas. It helps to reduce an overhead of finding
> matched area. And architecture dependency on vmalloc layer is removed,
> so it will help to maintainability for vmalloc layer.
> 
> Signed-off-by: Joonsoo Kim 

Some comments below.

> diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
> index 904c15e..c7fef4b 100644
> --- a/arch/arm/mm/ioremap.c
> +++ b/arch/arm/mm/ioremap.c
> @@ -261,13 +261,14 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long 
> pfn,
>   const struct mem_type *type;
>   int err;
>   unsigned long addr;
> - struct vm_struct * area;
> + struct vm_struct *area;
> + phys_addr_t paddr = __pfn_to_phys(pfn);
>  
>  #ifndef CONFIG_ARM_LPAE
>   /*
>* High mappings must be supersection aligned
>*/
> - if (pfn >= 0x10 && (__pfn_to_phys(pfn) & ~SUPERSECTION_MASK))
> + if (pfn >= 0x10 && (paddr & ~SUPERSECTION_MASK))
>   return NULL;
>  #endif
>  
> @@ -283,24 +284,16 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long 
> pfn,
>   /*
>* Try to reuse one of the static mapping whenever possible.
>*/
> - read_lock(_lock);
> - for (area = vmlist; area; area = area->next) {
> - if (!size || (sizeof(phys_addr_t) == 4 && pfn >= 0x10))
> - break;
> - if (!(area->flags & VM_ARM_STATIC_MAPPING))
> - continue;
> - if ((area->flags & VM_ARM_MTYPE_MASK) != VM_ARM_MTYPE(mtype))
> - continue;
> - if (__phys_to_pfn(area->phys_addr) > pfn ||
> - __pfn_to_phys(pfn) + size-1 > area->phys_addr + 
> area->size-1)
> - continue;
> - /* we can drop the lock here as we know *area is static */
> - read_unlock(_lock);
> - addr = (unsigned long)area->addr;
> - addr += __pfn_to_phys(pfn) - area->phys_addr;
> - return (void __iomem *) (offset + addr);
> + if (size && !((sizeof(phys_addr_t) == 4 && pfn >= 0x10))) {
 ^ ^
You have a needless extra set of parents here.

[...]

> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index ce328c7..b2c0356 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -757,21 +757,24 @@ void __init iotable_init(struct map_desc *io_desc, int 
> nr)
>  {
>   struct map_desc *md;
>   struct vm_struct *vm;
> + struct static_vm *svm;
>  
>   if (!nr)
>   return;
>  
> - vm = early_alloc_aligned(sizeof(*vm) * nr, __alignof__(*vm));
> + svm = early_alloc_aligned(sizeof(*svm) * nr, __alignof__(*svm));
>  
>   for (md = io_desc; nr; md++, nr--) {
>   create_mapping(md);
> +
> + vm = >vm;
>   vm->addr = (void *)(md->virtual & PAGE_MASK);
>   vm->size = PAGE_ALIGN(md->length + (md->virtual & ~PAGE_MASK));
>   vm->phys_addr = __pfn_to_phys(md->pfn);
>   vm->flags = VM_IOREMAP | VM_ARM_STATIC_MAPPING;
>   vm->flags |= VM_ARM_MTYPE(md->type);
>   vm->caller = iotable_init;
> - vm_area_add_early(vm++);
> + add_static_vm_early(svm++);
>   }
>  }
>  
> @@ -779,13 +782,16 @@ void __init vm_reserve_area_early(unsigned long addr, 
> unsigned long size,
> void *caller)
>  {
>   struct vm_struct *vm;
> + struct static_vm *svm;
> +
> + svm = early_alloc_aligned(sizeof(*svm), __alignof__(*svm));
>  
> - vm = early_alloc_aligned(sizeof(*vm), __alignof__(*vm));
> + vm = >vm;
>   vm->addr = (void *)addr;
>   vm->size = size;
>   vm->flags = VM_IOREMAP | VM_ARM_EMPTY_MAPPING;
>   vm->caller = caller;
> - vm_area_add_early(vm);
> + add_static_vm_early(svm);
>  }
>  
>  #ifndef CONFIG_ARM_LPAE
> @@ -810,14 +816,13 @@ static void __init pmd_empty_section_gap(unsigned long 
> addr)
>  
>  static void __init fill_pmd_gaps(void)
>  {
> + struct static_vm *svm;
>   struct vm_struct *vm;
>   unsigned long addr, next = 0;
>   pmd_t *pmd;
>  
> - /* we're still single threaded hence no lock needed here */
> - for (vm = vmlist; vm; vm = vm->next) {
> - if (!(vm->flags & (VM_ARM_STATIC_MAPPING | 
> VM_ARM_EMPTY_MAPPING)))
> - continue;
> + list_for_each_entry(svm, _vmlist, list) {
> + vm = >vm;
>   addr = (unsigned long)vm->addr;
>   if (addr < next)
> 

Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming

[Andy King]

Hi Dave,

> >> Instead, what I remember doing was deferring to the feedback these
> >> folks received, stating that ideas that the virtio people had
> >> mentioned should be considered instead.
> >> 
> >> http://marc.info/?l=linux-netdev=135301515818462=2
> > 
> > I believe Andy replied to Anthony's AF_VMCHANNEL post and the
> > differences between the proposed solutions.
> 
> I'd much rather see a hypervisor neutral solution than a hypervisor
> specific one which this certainly is.

We've addressed this with the latest patch series, which I sent earlier
today.  vSockets now has support for pluggable transports, of which VMCI
happens to be the first; all transport code is separated out into its
own module.  So the core is now hypervisor neutral.  Given that, would
you be willing to re-consider it, please?  If at all possible, we'd like
to make the current merge window.

Thanks so much!
- Andy
--
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: [PATCHv5,RESEND 4/8] gpu: host1x: Add debug support

[Terje Bergström]

On 04.02.2013 03:03, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Tue, Jan 15, 2013 at 01:44:00PM +0200, Terje Bergstrom wrote:
>> diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c
> [...]
>> +static pid_t host1x_debug_null_kickoff_pid;
>> +unsigned int host1x_debug_trace_cmdbuf;
>> +
>> +static pid_t host1x_debug_force_timeout_pid;
>> +static u32 host1x_debug_force_timeout_val;
>> +static u32 host1x_debug_force_timeout_channel;
> 
> Please group static and non-static variables.

Will do.

> 
>> diff --git a/drivers/gpu/host1x/debug.h b/drivers/gpu/host1x/debug.h
> [...]
>> +struct output {
>> +void (*fn)(void *ctx, const char *str, size_t len);
>> +void *ctx;
>> +char buf[256];
>> +};
> 
> Do we really need this kind of abstraction? There really should be only
> one location where debug information is obtained, so I don't see a need
> for this.

This is used by debugfs code to direct to debugfs, and
nvhost_debug_dump() to send via printk.

> 
>> diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
> [...]
>>  struct host1x_syncpt_ops {
>>  void (*reset)(struct host1x_syncpt *);
>>  void (*reset_wait_base)(struct host1x_syncpt *);
>> @@ -117,6 +133,7 @@ struct host1x {
>>  struct host1x_channel_ops channel_op;
>>  struct host1x_cdma_ops cdma_op;
>>  struct host1x_pushbuffer_ops cdma_pb_op;
>> +struct host1x_debug_ops debug_op;
>>  struct host1x_syncpt_ops syncpt_op;
>>  struct host1x_intr_ops intr_op;
> 
> Again, better to pass in a const pointer to the ops structure.

Ok.

> 
>> diff --git a/drivers/gpu/host1x/hw/debug_hw.c 
>> b/drivers/gpu/host1x/hw/debug_hw.c
> 
>> +static int show_channel_command(struct output *o, u32 addr, u32 val, int 
>> *count)
>> +{
>> +unsigned mask;
>> +unsigned subop;
>> +
>> +switch (val >> 28) {
>> +case 0x0:
> 
> These can easily be derived by looking at the debug output, but it may
> still make sense to assign symbolic names to them.

I have another suggestion. In downstream I removed the decoding part and
I just print out a string of hex. That removes quite a bit bunch of code
from kernel. It makes the debug output also more compact.

It's much easier to write a user space program to decode than maintain
it in kernel.

> 
>> +static void show_channel_word(struct output *o, int *state, int *count,
>> +u32 addr, u32 val, struct host1x_cdma *cdma)
>> +{
>> +static int start_count, dont_print;
> 
> What if two processes read debug information at the same time?

show_channels() acquires cdma.lock, so that shouldn't happen.

> 
>> +static void do_show_channel_gather(struct output *o,
>> +phys_addr_t phys_addr,
>> +u32 words, struct host1x_cdma *cdma,
>> +phys_addr_t pin_addr, u32 *map_addr)
>> +{
>> +/* Map dmaget cursor to corresponding mem handle */
>> +u32 offset;
>> +int state, count, i;
>> +
>> +offset = phys_addr - pin_addr;
>> +/*
>> + * Sometimes we're given different hardware address to the same
>> + * page - in these cases the offset will get an invalid number and
>> + * we just have to bail out.
>> + */
> 
> Why's that?

Because of a race - memory might've been unpinned and unmapped from
IOMMU and when we re-map (pin), we are given a new address.

But, I think this comment is a bit stale - we used to dump also old
gathers. The latest code only dumps jobs in sync queue, so the race
shouldn't happen.

> 
>> +map_addr = host1x_memmgr_mmap(mem);
>> +if (!map_addr) {
>> +host1x_debug_output(o, "[could not mmap]\n");
>> +return;
>> +}
>> +
>> +/* Get base address from mem */
>> +sgt = host1x_memmgr_pin(mem);
>> +if (IS_ERR(sgt)) {
>> +host1x_debug_output(o, "[couldn't pin]\n");
>> +host1x_memmgr_munmap(mem, map_addr);
>> +return;
>> +}
> 
> Maybe you should stick with one of "could not" or "couldn't". Makes it
> easier to search for.

I prefer "could not", so I'll use that.

> 
>> +static void show_channel_gathers(struct output *o, struct host1x_cdma *cdma)
>> +{
>> +struct host1x_job *job;
>> +
>> +list_for_each_entry(job, >sync_queue, list) {
>> +int i;
>> +host1x_debug_output(o,
>> +"\n%p: JOB, syncpt_id=%d, syncpt_val=%d,"
>> +" first_get=%08x, timeout=%d"
>> +" num_slots=%d, num_handles=%d\n",
>> +job,
>> +job->syncpt_id,
>> +job->syncpt_end,
>> +job->first_get,
>> +job->timeout,
>> +job->num_slots,
>> +job->num_unpins);
> 
> This could go on fewer lines.

Yes, will merge.

> 
>> +static void host1x_debug_show_channel_cdma(struct host1x *m,
>> +struct host1x_channel *ch, struct 

RE: [PATCH 1/2] USB: storage: Define a new macro for USB storage match rules

[Fangxiaozhi (Franko)]

Dear  Greg：

OK，thank you very much.

Best Regards,
Franko Fang

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Tuesday, February 05, 2013 2:39 AM
> To: Fangxiaozhi (Franko)
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Xueguiying 
> (Zihan);
> Linlei (Lei Lin); Yili (Neil); Wangyuhua (Roger, Credit); Huqiao (C); 
> ba...@ti.com;
> mdharm-...@one-eyed-alien.net; sebast...@breakpoint.cc
> Subject: Re: [PATCH 1/2] USB: storage: Define a new macro for USB storage
> match rules
> 
> On Mon, Feb 04, 2013 at 03:14:46PM +0800, fangxiaozhi 00110321 wrote:
> > +/* Define the device is matched with Vendor ID and interface
> > +descriptors */ #define UNUSUAL_VENDOR_INTF(id_vendor, cl, sc, pr, \
> > +   vendorName, productName, useProtocol, useTransport, \
> > +   initFunction, flags) \
> > +{ \
> > +   .match_flags = USB_DEVICE_ID_MATCH_INT_INFO \
> > +   | USB_DEVICE_ID_MATCH_VENDOR, \
> > +   .idVendor= (id_vendor), \
> > +   .bInterfaceClass = (cl), \
> > +   .bInterfaceSubClass = (sc), \
> > +   .bInterfaceProtocol = (pr), \
> > +   .driver_info = (flags) \
> > +}
> 
> I'm not going to reject this given the number of times it has been submitted,
> but can't you use the USB_VENDOR_AND_INTERFACE_INFO() macro here in
> this definition?
> 
> If so, can you send me an add-on patch that makes that change?
> 
> thanks,
> 
> greg k-h

Re: [PATCHv5,RESEND 2/8] gpu: host1x: Add syncpoint wait and interrupts

[Terje Bergström]

On 04.02.2013 02:30, Thierry Reding wrote:
> On Tue, Jan 15, 2013 at 01:43:58PM +0200, Terje Bergstrom wrote:
> [...]
>> diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
> [...]
>> @@ -95,7 +96,6 @@ static int host1x_probe(struct platform_device *dev)
>>
>>   /* set common host1x device data */
>>   platform_set_drvdata(dev, host);
>> -
>>   host->regs = devm_request_and_ioremap(>dev, regs);
>>   if (!host->regs) {
>>   dev_err(>dev, "failed to remap host registers\n");
> 
> This seems an unrelated (and actually undesirable) change.
> 
>> @@ -109,28 +109,40 @@ static int host1x_probe(struct platform_device *dev)
>>   }
>>
>>   err = host1x_syncpt_init(host);
>> - if (err)
>> + if (err) {
>> + dev_err(>dev, "failed to init sync points");
>>   return err;
>> + }
> 
> This error message should probably have gone in the previous patch as
> well.

Oops, will move these to previous patch. I'm pretty sure I already fixed
this once. :-(

> 
>> diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
>> index d8f5979..8376092 100644
>> --- a/drivers/gpu/host1x/dev.h
>> +++ b/drivers/gpu/host1x/dev.h
>> @@ -17,11 +17,12 @@
>>  #ifndef HOST1X_DEV_H
>>  #define HOST1X_DEV_H
>>
>> +#include 
>>  #include "syncpt.h"
>> +#include "intr.h"
>>
>>  struct host1x;
>>  struct host1x_syncpt;
>> -struct platform_device;
> 
> Why include platform_device.h here?

host1x_get_host() actually needs that, so this #include should've also
been in previous patch.

> 
>> @@ -34,6 +35,18 @@ struct host1x_syncpt_ops {
>>   const char * (*name)(struct host1x_syncpt *);
>>  };
>>
>> +struct host1x_intr_ops {
>> + void (*init_host_sync)(struct host1x_intr *);
>> + void (*set_host_clocks_per_usec)(
>> + struct host1x_intr *, u32 clocks);
> 
> Could the above two not be combined? The only reason to keep them
> separate would be if the host1x clock was dynamically changed, but I
> don't think we support that, right?

I've left this as a placeholder to at some point start supporting host1x
clock scaling. But I don't think we're going to do that for a while, so
I could merge them.

> 
>> + void (*set_syncpt_threshold)(
>> + struct host1x_intr *, u32 id, u32 thresh);
>> + void (*enable_syncpt_intr)(struct host1x_intr *, u32 id);
>> + void (*disable_syncpt_intr)(struct host1x_intr *, u32 id);
>> + void (*disable_all_syncpt_intrs)(struct host1x_intr *);
> 
> Can disable_all_syncpt_intrs() not be implemented generically using the
> number of syncpoints as exposed by host1x_device_info and the
> .disable_syncpt_intr() function?

disable_all_syncpt_intrs() disables all interrupts in one write (or one
per 32 sync points), so it's more efficient.

> 
>> @@ -46,11 +59,13 @@ struct host1x_device_info {
>>  struct host1x {
>>   void __iomem *regs;
>>   struct host1x_syncpt *syncpt;
>> + struct host1x_intr intr;
>>   struct platform_device *dev;
>>   struct host1x_device_info info;
>>   struct clk *clk;
>>
>>   struct host1x_syncpt_ops syncpt_op;
>> + struct host1x_intr_ops intr_op;
> 
> I think carrying a const pointer to the interrupt operations structure
> is a better option here.

Ok.

> 
>> diff --git a/drivers/gpu/host1x/hw/intr_hw.c 
>> b/drivers/gpu/host1x/hw/intr_hw.c
> [...]
>> +static void host1x_intr_syncpt_thresh_isr(struct host1x_intr_syncpt 
>> *syncpt);
> 
> Can we avoid this forward declaration?

I think we can, if I just move the isr to top of file.

> 
>> +static void syncpt_thresh_cascade_fn(struct work_struct *work)
> 
> syncpt_thresh_work()?

Sounds good.

> 
>> +{
>> + struct host1x_intr_syncpt *sp =
>> + container_of(work, struct host1x_intr_syncpt, work);
>> + host1x_syncpt_thresh_fn(sp);
> 
> Couldn't we inline the host1x_syncpt_thresh_fn() implementation here?
> Why do we need to go through an external function declaration?

If I move syncpt_thresh_work() to intr.c from intr_hw.c, I could do
that. That'd simplify the interrupt path.

> 
>> +static irqreturn_t syncpt_thresh_cascade_isr(int irq, void *dev_id)
>> +{
>> + struct host1x *host1x = dev_id;
>> + struct host1x_intr *intr = >intr;
>> + unsigned long reg;
>> + int i, id;
>> +
>> + for (i = 0; i < host1x->info.nb_pts / BITS_PER_LONG; i++) {
>> + reg = host1x_sync_readl(host1x,
>> + HOST1X_SYNC_SYNCPT_THRESH_CPU0_INT_STATUS +
>> + i * REGISTER_STRIDE);
>> + for_each_set_bit(id, , BITS_PER_LONG) {
>> + struct host1x_intr_syncpt *sp =
>> + intr->syncpt + (i * BITS_PER_LONG + id);
>> + host1x_intr_syncpt_thresh_isr(sp);
> 
> Have you considered mimicking the IRQ API and name this something like
> host1x_intr_syncpt_thresh_handle() and name the actual ISR just
> syncpt_thresh_isr()? Not so important but it makes things a 

Re: [PATCH] init: fix name of root device in /proc/mounts

[William Hubbs]

On Mon, Feb 04, 2013 at 06:54:32PM -0800, H. Peter Anvin wrote:
> The difference is that it used to be customary to have a /dev/root symlink; 
> iirc udev created one.  Devtmpfs does not (for largely valid reasons, but it 
> does break some userspaces.)

Correct. The /dev/root symlink is not created any longer. If you boot
with an initramfs this path does not show up in /proc/mounts. If you
boot without one, however, it does.

This patch just makes the /dev/root path not show up at all in
/proc/mounts, regardless of whether an initramfs is used.

Thanks,

William

> Rob Landley  wrote:
> 
> >On 01/31/2013 05:22:09 PM, H. Peter Anvin wrote:
> >> On 01/31/2013 02:51 PM, William Hubbs wrote:
> >> > On a system that does not use an initramfs, /dev/root was always
> >> > listed in /proc/mounts. This breaks software which scans  
> >> /proc/mounts to
> >> > determine which file systems are mounted since /dev/root is not a  
> >> valid
> >> > device name.
> >> >
> >> > This changes that processing so that "/dev/root" is only added to
> >> > /proc/mounts if a root device is not specified with the root=  
> >> option on
> >> > the kernel command line.
> >> >
> >> > Signed-off-by: William Hubbs 
> >> 
> >> Let me also point out that most of the time, the kernel actually has
> >a
> >> udev device name for an actual device...
> >
> >So your software is broken by overmounts? /dev/root is just one example
> > 
> >of this. (And you can specify a root= on the kernel command line and  
> >have that be parsed by initramfs. I vaguely recall klibc does this...)
> >
> >For an example of how to parse this stuff, how about:
> >
> >   http://landley.net/hg/toybox/file/4ffb735aea59/toys/posix/df.c
> >
> >I.E. parse from the end of the list (most recent match is the  
> >overmount), and eliminate synthetic filesystems. Note that code is from
> > 
> >2006, other people have managed to cope all this time...
> >
> >Rob
> 
> -- 
> Sent from my mobile phone. Please excuse brevity and lack of formatting.


pgpEyb4JzQSi8.pgp
Description: PGP signature

[PATCH] mm: break circular include from linux/mmzone.h

[liguang]

linux/mmzone.h included linux/memory_hotplug.h,
and linux/memory_hotplug.h also included
linux/mmzone.h, so there's a bad cirlular.

Signed-off-by: liguang 
---
 drivers/hwmon/coretemp.c|2 ++
 drivers/hwmon/via-cputemp.c |2 ++
 include/linux/mmzone.h  |1 -
 kernel/cpu.c|1 +
 kernel/smp.c|1 +
 lib/show_mem.c  |1 +
 mm/memory_hotplug.c |1 +
 mm/nobootmem.c  |1 +
 mm/sparse.c |1 +
 9 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c
index d64923d..9a90a3b 100644
--- a/drivers/hwmon/coretemp.c
+++ b/drivers/hwmon/coretemp.c
@@ -36,6 +36,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include 
 #include 
 #include 
diff --git a/drivers/hwmon/via-cputemp.c b/drivers/hwmon/via-cputemp.c
index 76f157b..2aab52f 100644
--- a/drivers/hwmon/via-cputemp.c
+++ b/drivers/hwmon/via-cputemp.c
@@ -35,6 +35,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include 
 #include 
 #include 
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 73b64a3..9ca72f4 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -758,7 +758,6 @@ typedef struct pglist_data {
__pgdat->node_start_pfn + __pgdat->node_spanned_pages;\
 })
 
-#include 
 
 extern struct mutex zonelists_mutex;
 void build_all_zonelists(pg_data_t *pgdat, struct zone *zone);
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 3046a50..e6e53e6 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "smpboot.h"
 
diff --git a/kernel/smp.c b/kernel/smp.c
index 29dd40a..6f4d485 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "smpboot.h"
 
diff --git a/lib/show_mem.c b/lib/show_mem.c
index 4407f8c..7c90021 100644
--- a/lib/show_mem.c
+++ b/lib/show_mem.c
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index d04ed87..5a73123 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
diff --git a/mm/nobootmem.c b/mm/nobootmem.c
index b8294fc..36c1547 100644
--- a/mm/nobootmem.c
+++ b/mm/nobootmem.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/mm/sparse.c b/mm/sparse.c
index 6b5fb76..1b407d5 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Permanent SPARSEMEM data:
-- 
1.7.2.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 v5 2/3] ARM: ioremap: introduce an infrastructure for static mapped area

[Nicolas Pitre]

On Tue, 5 Feb 2013, Joonsoo Kim wrote:

> In current implementation, we used ARM-specific flag, that is,
> VM_ARM_STATIC_MAPPING, for distinguishing ARM specific static mapped area.
> The purpose of static mapped area is to re-use static mapped area when
> entire physical address range of the ioremap request can be covered
> by this area.
> 
> This implementation causes needless overhead for some cases.
> For example, assume that there is only one static mapped area and
> vmlist has 300 areas. Every time we call ioremap, we check 300 areas for
> deciding whether it is matched or not. Moreover, even if there is
> no static mapped area and vmlist has 300 areas, every time we call
> ioremap, we check 300 areas in now.
> 
> If we construct a extra list for static mapped area, we can eliminate
> above mentioned overhead.
> With a extra list, if there is one static mapped area,
> we just check only one area and proceed next operation quickly.
> 
> In fact, it is not a critical problem, because ioremap is not frequently
> used. But reducing overhead is better idea.
> 
> Another reason for doing this work is for removing architecture dependency
> on vmalloc layer. I think that vmlist and vmlist_lock is internal data
> structure for vmalloc layer. Some codes for debugging and stat inevitably
> use vmlist and vmlist_lock. But it is preferable that they are used
> as least as possible in outside of vmalloc.c
> 
> Now, I introduce an ARM-specific infrastructure for static mapped area. In
> the following patch, we will use this and resolve above mentioned problem.
> 
> Signed-off-by: Joonsoo Kim 

Reviewed-by: Nicolas Pitre 


> 
> diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
> index 88fd86c..904c15e 100644
> --- a/arch/arm/mm/ioremap.c
> +++ b/arch/arm/mm/ioremap.c
> @@ -39,6 +39,70 @@
>  #include 
>  #include "mm.h"
>  
> +
> +LIST_HEAD(static_vmlist);
> +
> +static struct static_vm *find_static_vm_paddr(phys_addr_t paddr,
> + size_t size, unsigned int mtype)
> +{
> + struct static_vm *svm;
> + struct vm_struct *vm;
> +
> + list_for_each_entry(svm, _vmlist, list) {
> + vm = >vm;
> + if (!(vm->flags & VM_ARM_STATIC_MAPPING))
> + continue;
> + if ((vm->flags & VM_ARM_MTYPE_MASK) != VM_ARM_MTYPE(mtype))
> + continue;
> +
> + if (vm->phys_addr > paddr ||
> + paddr + size - 1 > vm->phys_addr + vm->size - 1)
> + continue;
> +
> + return svm;
> + }
> +
> + return NULL;
> +}
> +
> +struct static_vm *find_static_vm_vaddr(void *vaddr)
> +{
> + struct static_vm *svm;
> + struct vm_struct *vm;
> +
> + list_for_each_entry(svm, _vmlist, list) {
> + vm = >vm;
> +
> + /* static_vmlist is ascending order */
> + if (vm->addr > vaddr)
> + break;
> +
> + if (vm->addr <= vaddr && vm->addr + vm->size > vaddr)
> + return svm;
> + }
> +
> + return NULL;
> +}
> +
> +void __init add_static_vm_early(struct static_vm *svm)
> +{
> + struct static_vm *curr_svm;
> + struct vm_struct *vm;
> + void *vaddr;
> +
> + vm = >vm;
> + vm_area_add_early(vm);
> + vaddr = vm->addr;
> +
> + list_for_each_entry(curr_svm, _vmlist, list) {
> + vm = _svm->vm;
> +
> + if (vm->addr > vaddr)
> + break;
> + }
> + list_add_tail(>list, _svm->list);
> +}
> +
>  int ioremap_page(unsigned long virt, unsigned long phys,
>const struct mem_type *mtype)
>  {
> diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
> index a8ee92d..d5a4e9a 100644
> --- a/arch/arm/mm/mm.h
> +++ b/arch/arm/mm/mm.h
> @@ -1,4 +1,6 @@
>  #ifdef CONFIG_MMU
> +#include 
> +#include 
>  
>  /* the upper-most page table pointer */
>  extern pmd_t *top_pmd;
> @@ -65,6 +67,16 @@ extern void __flush_dcache_page(struct address_space 
> *mapping, struct page *page
>  /* consistent regions used by dma_alloc_attrs() */
>  #define VM_ARM_DMA_CONSISTENT0x2000
>  
> +
> +struct static_vm {
> + struct vm_struct vm;
> + struct list_head list;
> +};
> +
> +extern struct list_head static_vmlist;
> +extern struct static_vm *find_static_vm_vaddr(void *vaddr);
> +extern __init void add_static_vm_early(struct static_vm *svm);
> +
>  #endif
>  
>  #ifdef CONFIG_ZONE_DMA
> -- 
> 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: [GIT PULL] printk: Support for full dynticks mode

[Andrew Morton]

On Mon, 04 Feb 2013 21:42:02 -0500 Steven Rostedt  wrote:

> On Mon, 2013-02-04 at 18:09 -0800, Andrew Morton wrote:
> 
> > I don't think so.  Conceptually printk() should be "inner" to the
> > scheduler and shouldn't call into sched things at all.  The (afaik
> > sole) exception to that was the klogd wakeup.
> > 
> > Traditionally the deadlock happened when calling printk() with
> > tasklist_lock (now q->lock) held.  printk() would call wake_up(klogd)
> > and wake_up() tries to take tasklist_lock and boom.  Moving the
> > wake_up() out to the tick "thread" fixed that.
> > 
> > Maybe there were other deadlock scenarios, dunno.  That knowledge
> > appears to be disappearing into the mists of time :(
> 
> Even without the printk irq_work the current printk method uses a
> delayed wakeup anyway.
> 
> The wake_up_klogd() sets PRINTK_PENDING_WAKEUP, and the wakeup happens
> at time of the tick. I don't see where there is a deadlock.
>
> ...
>
> Do we really even need that printk_sched()?

3ccf3e8306156a282 ("printk/sched: Introduce special printk_sched() for
those awkward moments") was added _after_ wake_up_klogd() was switched
to using the printk_pending->printk_tick() thing.  So presumably there
were deadlocks other than around wake_up_klogd().

The printk_pending->printk_tick() thing was added by b845b517b5e
("printk: robustify printk"), four years earlier in 2008.  It says
"Avoid deadlocks against rq->lock and xtime_lock...".

So what deadlocks was the March 2012 3ccf3e830 ("printk/sched:
Introduce special printk_sched() for those awkward moments") supposed
to fix?  grr.  I searched my lkml archives for March 2012 and few
preceding months, but couldn't find any additional info.

> I added a printk in __sched_setscheduler() where the run queue lock is held,
> and booted that with full lockdep debugging enabled. No deadlock is
> detected.

Well, you'd need to enable various printk options to get full coverage.
For example, that xtime_lock deadlock would only have occurred when
timestamping is enabled.

--
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] PCI: update device mps when doing pci hotplug

[Yijing Wang]

Currently we dont't update device's mps vaule when doing
pci device hot-add. The hot-added device's mps will be set
to default value (128B). But the upstream port device's mps
may be larger than 128B which was set by firmware during
system bootup. In this case the new added device may not
work normally.

The reference discussion at
http://marc.info/?l=linux-pci=135420434508910=2
and
http://marc.info/?l=linux-pci=134815603407842=2

Reported-by: Joe Jin 
Reported-by: Yijing Wang 
Signed-off-by: Yijing Wang 
Cc: Jon Mason 
---
 drivers/pci/probe.c |   49 +
 1 files changed, 49 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index bbe4be7..57d9a5b 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1556,6 +1556,52 @@ static int pcie_bus_configure_set(struct pci_dev *dev, 
void *data)
return 0;
 }
 
+static int pcie_bus_update_set(struct pci_dev *dev, void *data)
+{
+   int mps, p_mps;
+
+   if (!pci_is_pcie(dev) || !dev->bus->self)
+   return 0;
+
+   mps = pcie_get_mps(dev);
+   p_mps = pcie_get_mps(dev->bus->self);
+
+   if (pci_pcie_type(dev->bus->self) != PCI_EXP_TYPE_ROOT_PORT) {
+   /* update mps when current device mps is not equal to upstream 
mps */
+   if (mps != p_mps)
+   goto update;
+   } else {
+   /* update mps when current device mps is smaller than upstream 
mps */
+   if (mps < p_mps)
+   goto update;
+   }
+
+   return 0;
+
+update:
+   /* If current mpss is lager than upstream, use upstream mps to update
+* current mps, otherwise print warning info.
+*/
+   if ((128 << dev->pcie_mpss) >= p_mps)
+   pcie_write_mps(dev, p_mps);
+   else
+   dev_warn(>dev, "MPS %d MPSS %d both smaller than upstream 
MPS %d\n"
+   "If necessary, use \"pci=pcie_bus_peer2peer\" 
boot parameter to avoid this problem\n",
+   mps, 128 << dev->pcie_mpss, p_mps);
+   return 0;
+}
+
+static void pcie_bus_update_setting(struct pci_bus *bus)
+{
+
+   /*
+* After hot added a pci device, the device's mps will set to default
+* vaule(128 bytes). But the upstream port mps may be larger than 128B.
+* In this case, we should update this device's mps for better 
performance.
+*/
+   pci_walk_bus(bus, pcie_bus_update_set, NULL);
+}
+
 /* pcie_bus_configure_settings requires that pci_walk_bus work in a top-down,
  * parents then children fashion.  If this changes, then this code will not
  * work as designed.
@@ -1566,6 +1612,9 @@ void pcie_bus_configure_settings(struct pci_bus *bus, u8 
mpss)
 
if (!pci_is_pcie(bus->self))
return;
+
+   /* update mps setting for newly hot added device */
+   pcie_bus_update_setting(bus);
 
if (pcie_bus_config == PCIE_BUS_TUNE_OFF)
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 4/4] iommu: Add domain window handling functions

[Yoder Stuart-B08248]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Monday, February 04, 2013 5:36 PM
> To: Joerg Roedel
> Cc: Sethi Varun-B16395; io...@lists.linux-foundation.org; 
> linux-kernel@vger.kernel.org; Wood Scott-
> B07421; Yoder Stuart-B08248
> Subject: Re: [PATCH 4/4] iommu: Add domain window handling functions
> 
> On 02/04/2013 07:02:14 AM, Joerg Roedel wrote:
> > On Thu, Jan 31, 2013 at 09:32:26AM +, Sethi Varun-B16395 wrote:
> > > We need a mechanism to determine the maximum number of subwindows
> > supported by PAMU. How about representing it in the iommu_domain
> > structure:
> > > struct  iommu_domain {
> > >   struct iommu_ops *ops;
> > >   void *priv;
> > >   iommu_fault_handler_t handler;
> > >   void *handler_token;
> > >   struct iommu_domain_geometry geometry;
> > >   u32 max_sub_windows; -> maximum number of sub windows
> > supported by the hardware.
> > > }
> >
> > I`ll leave that flag to the private-data of the IOMMU domain. Instead
> > I
> > added a DOMAIN_ATTR_WINDOWS attribute to get/set the number of
> > subwindows. I'll post the updated patch-set soon.
> 
> If it's private data, how does the caller know what sort of geometry it
> can request?

The way I thought this could work based on the patch that Joerg posted today
was that when the domain is created the caller could read the 
DOMAIN_ATTR_WINDOWS 
domain_get_windows() to determine the max.  The initial/default value is the
max.  The caller could then set a smaller value if they wanted to.

Stuart

--
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] ia64/mm: fix a bad_page bug when crash kernel booting

[Xishi Qiu]

On 2013/2/5 0:32, Matt Fleming wrote:

> On Tue, 2013-01-29 at 11:52 +0800, Xishi Qiu wrote:
>> On ia64 platform, I set "crashkernel=1024M-:600M", and dmesg shows 128M-728M
>> memory is reserved for crash kernel. Then "echo c > /proc/sysrq-trigger" to
>> test kdump.
>>
>> When crash kernel booting, efi_init() will aligns the memory address in
>> IA64_GRANULE_SIZE(16M), so 720M-728M memory will be dropped, It means
>> crash kernel only manage 128M-720M memory.
>>
>> But initrd start and end are fixed in boot loader, it is before efi_init(),
>> so initrd size maybe overflow when free_initrd_mem().
> 
> [...]
> 
>> diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
>> index b755ea9..cfdb1eb 100644
>> --- a/arch/ia64/mm/init.c
>> +++ b/arch/ia64/mm/init.c
>> @@ -207,6 +207,17 @@ free_initrd_mem (unsigned long start, unsigned long end)
>>  start = PAGE_ALIGN(start);
>>  end = end & PAGE_MASK;
>>
>> +/*
>> + * Initrd size is fixed in boot loader, but kernel parameter max_addr
>> + * which aligns in granules is fixed after boot loader, so initrd size
>> + * maybe overflow.
>> + */
>> +if (max_addr != ~0UL) {
>> +end = GRANULEROUNDDOWN(end);
>> +if (start > end)
>> +start = end;
>> +}
>> +
>>  if (start < end)
>>  printk(KERN_INFO "Freeing initrd memory: %ldkB freed\n", (end - 
>> start) >> 10);
> 
> I don't think this is the correct fix.
> 
> Now, my ia64-fu is weak, but could it be that there's actually a bug in
> efi_init() and that the following patch would be the best way to fix
> this?
> 
> ---
> 
> diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
> index f034563..8d579f1 100644
> --- a/arch/ia64/kernel/efi.c
> +++ b/arch/ia64/kernel/efi.c
> @@ -482,7 +482,7 @@ efi_init (void)
>   if (memcmp(cp, "mem=", 4) == 0) {
>   mem_limit = memparse(cp + 4, );
>   } else if (memcmp(cp, "max_addr=", 9) == 0) {
> - max_addr = GRANULEROUNDDOWN(memparse(cp + 9, ));
> + max_addr = GRANULEROUNDUP(memparse(cp + 9, ));
>   } else if (memcmp(cp, "min_addr=", 9) == 0) {
>   min_addr = GRANULEROUNDDOWN(memparse(cp + 9, ));
>   } else {
> 
> 

Hi Matt,

Thanks for your awareness.

I have a question. If we set "crashkernel=1024M-:600M", the log shows 128M-728M 
memory
is reserved for crash kernel. So if "max_addr = GRANULEROUNDUP()", when crash 
kernel boot,
it uses 128M-736M memory, overflow! (suppose IA64_GRANULE_SIZE=16M).

Thanks,
Xishi Qiu

> 
> .
> 



--
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: [ 105/128] efi: Make efi_enabled a function to query EFI facilities

[Ben Hutchings]

On Mon, 2013-02-04 at 16:44 +, Matt Fleming wrote:
> On Sun, 2013-02-03 at 16:15 +0100, Ben Hutchings wrote:
> > As you can see this needed quite a lot of work to backport, and I
> > haven't been able to test it yet.  So I would particularly appreciate
> > careful review of this.
> 
> Everything looks fine to me but I haven't actually booted with these
> changes.

Thanks.  I've now tested this on a 64-bit EFI system myself:

x86_64 kernel build:
- Boots successfully
- x86_efi_facilities = 0x3f
- efifb works
- efivars can be loaded and creates /sys/firmware/efi/vars

i386 kernel build:
- Boots as far as an initramfs shell, but the machine doesn't have an
i386 installation to continue with
- x86_efi_facilities = 0x21
- efifb works
- efivars can be loaded but does nothing

All of which I think is correct.

Ben.

-- 
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
   - Albert Einstein


signature.asc
Description: This is a digitally signed message part

Re: [PATCH 1/4] eventfd: introduce eventfd_signal_hangup()

[Li Zefan]

On 2013/2/4 18:15, Kirill A. Shutemov wrote:
> On Sat, Feb 02, 2013 at 05:58:58PM +0200, Kirill A. Shutemov wrote:
>> On Sat, Feb 02, 2013 at 02:50:44PM +0800, Li Zefan wrote:
>>> When an eventfd is closed, a wakeup with POLLHUP will be issued,
>>> but cgroup wants to issue wakeup explicitly, so when a cgroup is
>>> removed userspace can be notified.
>>>
>>> Signed-off-by: Li Zefan 
> 
> Hm.. Looks like it will break eventfd semantics:
> 
> 1. One eventfd can be used for deliver more then one notification from
> one or more cgroups. POLLHUP on removing one of cgroups is not valid.
> 
> 2. It's valid to have eventfd opened only by one userspace application. We
> should not close it, just because cgroup is removed.
> 
> I think problem with multiple threads waiting an event on eventfd should
> be handled in userspace.
> 

I didn't realize this.. and if a cgroup is removed, the woken thread may not
be the thread that is waiting on this cgroup. How crappy.. I don't know how
userspace is going to deal with all these.

And another bug spotted. We can pass fd of memory.usage_in_bytes of cgroup A
to cgroup.event_control of cgroup B, and then we won't get memory usage
notification from A but B! What's worse, if A and B are in different mount
hierarchy, boom!


Signed-off-by: Li Zefan 
---
 kernel/cgroup.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 3d21adf..e496359 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -3825,6 +3825,7 @@ static int cgroup_write_event_control(struct cgroup 
*cgrp, struct cftype *cft,
  const char *buffer)
 {
struct cgroup_event *event = NULL;
+   struct cgroup *cgrp_cfile;
unsigned int efd, cfd;
struct file *efile = NULL;
struct file *cfile = NULL;
@@ -3880,6 +3881,16 @@ static int cgroup_write_event_control(struct cgroup 
*cgrp, struct cftype *cft,
goto fail;
}
 
+   /*
+* The file to be monitored must be in the same cgroup as
+* cgroup.event_control is.
+*/
+   cgrp_cfile = __d_cgrp(cfile->f_dentry->d_parent);
+   if (cgrp_cfile != cgrp) {
+   ret = -EINVAL;
+   goto fail;
+   }
+
if (!event->cft->register_event || !event->cft->unregister_event) {
ret = -EINVAL;
goto fail;
-- 
1.8.0.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] sched/rt: Decrease number of calls of push_rt_task() in push_rt_tasks()

[Honghui Zhang]

On 2013/2/1 5:57, Kirill Tkhai wrote:
> 
> 
> 31.01.2013, 20:08, "Steven Rostedt" :
>> On Mon, 2013-01-28 at 03:46 +0400, Kirill Tkhai wrote:
>>
>>>  The patch aims to decrease the number of calls of push_rt_task()
>>>  in push_rt_tasks().
>>>
>>>  It's not necessary to push more than 'num_online_cpus() - 1' tasks.
>>>  If just pushed task doesn't leave its new CPU during our local call
>>>  of push_rt_tasks() than we won't push another task to the CPU.
>>>  If it leave or change priority than it will pull new task by itself.
>>
>> I'm curious. Have you hit situations where this was an issue? Or was
>> this just discovered by code review?
> 
> No, I did't hit this situation. It's impossible to hook every situation.
> 
> Thanks for your explanation.
> 
> Kirill
> 

Suppose we have a large number of cpus(say 4096), with the last one running
a low-priority task on it. Is it possible with this patch we will never reach
the last cpu in case that previous cpu has complete the pulled task?


--
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: [PATCHv5,RESEND 1/8] gpu: host1x: Add host1x driver

[Terje Bergström]

On 04.02.2013 01:09, Thierry Reding wrote:
> On Tue, Jan 15, 2013 at 01:43:57PM +0200, Terje Bergstrom wrote:
>> Add host1x, the driver for host1x and its client unit 2D.
> 
> Maybe this could be a bit more verbose. Perhaps describe what host1x is.

Sure. I could just steal the paragraph from Stephen:

The Tegra host1x module is the DMA engine for register access to Tegra's
graphics- and multimedia-related modules. The modules served by host1x
are referred to as clients. host1x includes some other  functionality,
such as synchronization.

>> diff --git a/drivers/gpu/host1x/Kconfig b/drivers/gpu/host1x/Kconfig
> [...]
>> @@ -0,0 +1,6 @@
>> +config TEGRA_HOST1X
>> + tristate "Tegra host1x driver"
>> + help
>> +   Driver for the Tegra host1x hardware.
> 
> Maybe s/Tegra/NVIDIA Tegra/?

Sounds good.

>> +
>> +   Required for enabling tegradrm.
> 
> This should probably be dropped. Either encode such knowledge as
> explicit dependencies or in this case just remove it altogether since we
> will probably merge both drivers anyway.

I think this was left from previous versions. Now it just doesn't make
sense. I'll just drop it.

> 
>> diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
> [...]
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include "dev.h"
> 
> Maybe add a blank line between the previous two lines to visually
> separate standard Linux includes from driver-specific ones.

Ok. You commented in quite few places in a similar way. I'll fix all of
them to first include system includes, then driver's own includes, and
add a blank line in between.

> 
>> +#include "hw/host1x01.h"
>> +
>> +#define CREATE_TRACE_POINTS
>> +#include 
>> +
>> +#define DRIVER_NAME  "tegra-host1x"
> 
> You only ever use this once, so maybe it can just be dropped?

Yes.

> 
>> +static struct host1x_device_info host1x_info = {
> 
> Perhaps this should be host1x01_info in order to match the hardware
> revision? That'll avoid it having to be renamed later on when other
> revisions start to appear.

Ok, will do. I thought it'd be awkward being alone until the second
version appears, but I'll add it.

> 
>> +static int host1x_probe(struct platform_device *dev)
>> +{
> [...]
>> + syncpt_irq = platform_get_irq(dev, 0);
>> + if (IS_ERR_VALUE(syncpt_irq)) {
> 
> This is somewhat unusual. It should be fine to just do:
> 
> if (syncpt_irq < 0)
> 
> but IS_ERR_VALUE() should work fine too.

I'll use the simpler version.

> 
>> + memcpy(>info, devid->data, sizeof(struct host1x_device_info));
> 
> Why not make the .info field a pointer to struct host1x_device_info
> instead? That way you don't have to keep separate copies of the same
> information.

This had something to do with __init data and non-init data. But, we're
not really putting this data into __init, so we should be able to use
just a pointer.

> 
>> + /* set common host1x device data */
>> + platform_set_drvdata(dev, host);
>> +
>> + host->regs = devm_request_and_ioremap(>dev, regs);
>> + if (!host->regs) {
>> + dev_err(>dev, "failed to remap host registers\n");
>> + return -ENXIO;
>> + }
> 
> This should probably be rewritten as:
> 
> host->regs = devm_ioremap_resource(>dev, regs);
> if (IS_ERR(host->regs))
> return PTR_ERR(host->regs);
> 
> Though that function will only be available in 3.9-rc1.

Ok, 3.9-rc1 is fine as a basis.

>> + err = host1x_syncpt_init(host);
>> + if (err)
>> + return err;
> [...]
>> + host1x_syncpt_reset(host);
> 
> Why separate host1x_syncpt_reset() from host1x_syncpt_init()? I see why
> it might be useful to have host1x_syncpt_reset() as a separate function
> but couldn't it be called as part of host1x_syncpt_init()?

host1x_syncpt_init() is used for initializing the syncpt structures, and
is called in probe. host1x_syncpt_reset() should be called whenever we
think hardware state is lost, for example if VDD_CORE was rail gated due
to system suspend.

> 
>> + dev_info(>dev, "initialized\n");
> 
> I don't think this is very useful. We should make sure to tell people
> when things fail. When everything goes as planned we don't need to brag
> about it =)

True. I wish other kernel drivers followed that same philosophy. :-)
I'll remove that. It's mainly useful as debug help, but it's as easy to
check from sysfs the state.

> 
>> diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
> [...]
>> +struct host1x_syncpt_ops {
> [...]
>> + const char * (*name)(struct host1x_syncpt *);
> 
> Why do we need this? Could we not refer to the syncpt name directly
> instead of going through this wrapper? I'd expect the name to be static.

This must be a relic. I'll remove the wrapper.

> 
>> +struct host1x_device_info {
> 
> Maybe this should be called simply host1x_info? _device seems redundant.

Sure.

> 
>> + int nb_channels;   

Re: [GIT PULL] printk: Support for full dynticks mode

[Steven Rostedt]

On Mon, 2013-02-04 at 22:24 -0500, Steven Rostedt wrote:

> The reason to avoid the wake up of klogd() is that it also grabs the
> wait queue spinlock every time it's called. up() is fast when there's no
> waiters, but wake_up_interruptible() is not so fast.

I take that back. Seems up() takes the sem->lock every time too :-p

But it's just a matter of slowing things down. I don't see it causing
any deadlocks.

-- Steve


--
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] printk: Support for full dynticks mode

[Steven Rostedt]

On Tue, 2013-02-05 at 04:19 +0100, Frederic Weisbecker wrote:
> 2013/2/5 Steven Rostedt :
> > On Mon, 2013-02-04 at 18:09 -0800, Andrew Morton wrote:
> >
> >> Maybe there were other deadlock scenarios, dunno.  That knowledge
> >> appears to be disappearing into the mists of time :(
> >
> > Discussing this on IRC with Frederic, he brought up that the
> > up(_sem) can do a wake_up as well. I guess that's the issue we
> > have :-/
> 
> Also if we delay the wakeup on klogd but not on the console_sem
> waiters, it looks like a general printk() problem. Not something that
> only printk_sched() would like to avoid.

printk_sched() is a delay to printk() to avoid calling printk() which
might take the rq lock. It's to prevent printk() deadlocking in case it
wakes up. printk_sched() just delays the printk() to the next timer
tick.

The reason to avoid the wake up of klogd() is that it also grabs the
wait queue spinlock every time it's called. up() is fast when there's no
waiters, but wake_up_interruptible() is not so fast.

There's no issue calling wake_up_process() from printk() as long as you
don't do it while holding a rq lock.

-- Steve


--
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/2] mtd: torturetest: rewrite the erase-write-verify process into one block unit.

[Huang Shijie]

Rewrite the torture cycle, do the erase-write-verify process in
one block unit, not in several blocks unit.

This patch makes preparations for adding the rand data pattern support.

Signed-off-by: Huang Shijie 
---
 drivers/mtd/tests/mtd_torturetest.c |   29 +++--
 1 files changed, 7 insertions(+), 22 deletions(-)

diff --git a/drivers/mtd/tests/mtd_torturetest.c 
b/drivers/mtd/tests/mtd_torturetest.c
index c4cde1e..516cf66 100644
--- a/drivers/mtd/tests/mtd_torturetest.c
+++ b/drivers/mtd/tests/mtd_torturetest.c
@@ -313,21 +313,18 @@ static int __init tort_init(void)
int i;
void *patt;
 
-   /* Erase all eraseblocks */
for (i = eb; i < eb + ebcnt; i++) {
if (bad_ebs[i - eb])
continue;
+
+   /* Erase all eraseblocks */
err = erase_eraseblock(i);
if (err)
goto out;
cond_resched();
-   }
 
-   /* Check if the eraseblocks contain only 0xFF bytes */
-   if (check) {
-   for (i = eb; i < eb + ebcnt; i++) {
-   if (bad_ebs[i - eb])
-   continue;
+   /* Check if the eraseblocks contain only 0xFF bytes */
+   if (check) {
err = check_eraseblock(i, patt_FF);
if (err) {
pr_info("verify failed"
@@ -336,12 +333,8 @@ static int __init tort_init(void)
}
cond_resched();
}
-   }
 
-   /* Write the pattern */
-   for (i = eb; i < eb + ebcnt; i++) {
-   if (bad_ebs[i - eb])
-   continue;
+   /* Write the pattern */
if ((eb + erase_cycles) & 1)
patt = patt_5A5;
else
@@ -350,17 +343,9 @@ static int __init tort_init(void)
if (err)
goto out;
cond_resched();
-   }
 
-   /* Verify what we wrote */
-   if (check) {
-   for (i = eb; i < eb + ebcnt; i++) {
-   if (bad_ebs[i - eb])
-   continue;
-   if ((eb + erase_cycles) & 1)
-   patt = patt_5A5;
-   else
-   patt = patt_A5A;
+   /* Verify what we wrote */
+   if (check) {
err = check_eraseblock(i, patt);
if (err) {
pr_info("verify failed for %s"
-- 
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/

[PATCH 2/2] mtd: torturetest: add the support for random data pattern

[Huang Shijie]

Add a new module parameter 'pattern'. If it is set to zero,
we will use the 55/AA pattern to torture the nand blocks; if it is set
to a non-zero value, we will use the random data pattern.

Signed-off-by: Huang Shijie 
---
 drivers/mtd/tests/mtd_torturetest.c |   72 ---
 1 files changed, 50 insertions(+), 22 deletions(-)

diff --git a/drivers/mtd/tests/mtd_torturetest.c 
b/drivers/mtd/tests/mtd_torturetest.c
index 516cf66..07655bc 100644
--- a/drivers/mtd/tests/mtd_torturetest.c
+++ b/drivers/mtd/tests/mtd_torturetest.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define RETRIES 3
 
@@ -64,6 +65,11 @@ module_param(cycles_count, uint, S_IRUGO);
 MODULE_PARM_DESC(cycles_count, "how many erase cycles to do "
   "(infinite by default)");
 
+static int pattern;
+module_param(pattern, int, S_IRUGO);
+MODULE_PARM_DESC(pattern, "0 for 55/AA pattern(default), else for
+   the random pattern");
+
 static struct mtd_info *mtd;
 
 /* This buffer contains 0x55...0xAA... pattern */
@@ -72,6 +78,8 @@ static unsigned char *patt_5A5;
 static unsigned char *patt_A5A;
 /* This buffer contains all 0xFF bytes */
 static unsigned char *patt_FF;
+/* This buffer contains the random data. */
+static unsigned char *patt_rd;
 /* This a temporary buffer is use when checking data */
 static unsigned char *check_buf;
 /* How many erase cycles were done */
@@ -228,6 +236,8 @@ static int __init tort_init(void)
pr_info("torturing just %d pages per eraseblock\n",
pgcnt);
pr_info("write verify %s\n", check ? "enabled" : "disabled");
+   pr_info("Test pattern is %s\n",
+   pattern ? "random data pattern" : "55/AA pattern");
 
mtd = get_mtd_device(NULL, dev);
if (IS_ERR(mtd)) {
@@ -249,16 +259,24 @@ static int __init tort_init(void)
}
 
err = -ENOMEM;
-   patt_5A5 = kmalloc(mtd->erasesize, GFP_KERNEL);
-   if (!patt_5A5) {
-   pr_err("error: cannot allocate memory\n");
-   goto out_mtd;
-   }
+   if (!pattern) {
+   patt_5A5 = kmalloc(mtd->erasesize, GFP_KERNEL);
+   if (!patt_5A5) {
+   pr_err("error: cannot allocate memory\n");
+   goto out_mtd;
+   }
 
-   patt_A5A = kmalloc(mtd->erasesize, GFP_KERNEL);
-   if (!patt_A5A) {
-   pr_err("error: cannot allocate memory\n");
-   goto out_patt_5A5;
+   patt_A5A = kmalloc(mtd->erasesize, GFP_KERNEL);
+   if (!patt_A5A) {
+   pr_err("error: cannot allocate memory\n");
+   goto out_patt_5A5;
+   }
+   } else {
+   patt_rd = kmalloc(mtd->erasesize, GFP_KERNEL);
+   if (!patt_rd) {
+   pr_err("error: cannot allocate memory\n");
+   goto out_patt_rd;
+   }
}
 
patt_FF = kmalloc(mtd->erasesize, GFP_KERNEL);
@@ -277,13 +295,15 @@ static int __init tort_init(void)
 
/* Initialize patterns */
memset(patt_FF, 0xFF, mtd->erasesize);
-   for (i = 0; i < mtd->erasesize / pgsize; i++) {
-   if (!(i & 1)) {
-   memset(patt_5A5 + i * pgsize, 0x55, pgsize);
-   memset(patt_A5A + i * pgsize, 0xAA, pgsize);
-   } else {
-   memset(patt_5A5 + i * pgsize, 0xAA, pgsize);
-   memset(patt_A5A + i * pgsize, 0x55, pgsize);
+   if (!pattern) {
+   for (i = 0; i < mtd->erasesize / pgsize; i++) {
+   if (!(i & 1)) {
+   memset(patt_5A5 + i * pgsize, 0x55, pgsize);
+   memset(patt_A5A + i * pgsize, 0xAA, pgsize);
+   } else {
+   memset(patt_5A5 + i * pgsize, 0xAA, pgsize);
+   memset(patt_A5A + i * pgsize, 0x55, pgsize);
+   }
}
}
 
@@ -335,10 +355,15 @@ static int __init tort_init(void)
}
 
/* Write the pattern */
-   if ((eb + erase_cycles) & 1)
-   patt = patt_5A5;
-   else
-   patt = patt_A5A;
+   if (!pattern) {
+   if ((eb + erase_cycles) & 1)
+   patt = patt_5A5;
+   else
+   patt = patt_A5A;
+   } else {
+   patt = patt_rd;
+   prandom_bytes(patt, mtd->erasesize);
+   }
err = write_pattern(i, patt);
if (err)
 

Re: [GIT PULL] printk: Support for full dynticks mode

[Frederic Weisbecker]

2013/2/5 Steven Rostedt :
> On Mon, 2013-02-04 at 18:09 -0800, Andrew Morton wrote:
>
>> Maybe there were other deadlock scenarios, dunno.  That knowledge
>> appears to be disappearing into the mists of time :(
>
> Discussing this on IRC with Frederic, he brought up that the
> up(_sem) can do a wake_up as well. I guess that's the issue we
> have :-/

Also if we delay the wakeup on klogd but not on the console_sem
waiters, it looks like a general printk() problem. Not something that
only printk_sched() would like to avoid.
--
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] printk: Support for full dynticks mode

[Steven Rostedt]

On Mon, 2013-02-04 at 18:09 -0800, Andrew Morton wrote:

> Maybe there were other deadlock scenarios, dunno.  That knowledge
> appears to be disappearing into the mists of time :(

Discussing this on IRC with Frederic, he brought up that the
up(_sem) can do a wake_up as well. I guess that's the issue we
have :-/

-- Steve


--
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] mm: hotplug: implement non-movable version of get_user_pages() called get_user_pages_non_movable()

[Lin Feng]

Hi Andrew,

On 02/05/2013 08:06 AM, Andrew Morton wrote:
> 
> melreadthis
> 
> On Mon, 4 Feb 2013 18:04:07 +0800
> Lin Feng  wrote:
> 
>> get_user_pages() always tries to allocate pages from movable zone, which is 
>> not
>>  reliable to memory hotremove framework in some case.
>>
>> This patch introduces a new library function called 
>> get_user_pages_non_movable()
>>  to pin pages only from zone non-movable in memory.
>> It's a wrapper of get_user_pages() but it makes sure that all pages come from
>> non-movable zone via additional page migration.
>>
>> ...
>>
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -1049,6 +1049,11 @@ int get_user_pages(struct task_struct *tsk, struct 
>> mm_struct *mm,
>>  struct page **pages, struct vm_area_struct **vmas);
>>  int get_user_pages_fast(unsigned long start, int nr_pages, int write,
>>  struct page **pages);
>> +#ifdef CONFIG_MEMORY_HOTREMOVE
>> +int get_user_pages_non_movable(struct task_struct *tsk, struct mm_struct 
>> *mm,
>> +unsigned long start, int nr_pages, int write, int force,
>> +struct page **pages, struct vm_area_struct **vmas);
>> +#endif
> 
> The ifdefs aren't really needed here and I encourage people to omit
> them.  This keeps the header files looking neater and reduces the
> chances of things later breaking because we forgot to update some
> CONFIG_foo logic in a header file.  The downside is that errors will be
> revealed at link time rather than at compile time, but that's a pretty
> small cost.
OK, got it, thanks :)

> 
>>  struct kvec;
>>  int get_kernel_pages(const struct kvec *iov, int nr_pages, int write,
>>  struct page **pages);
>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>> index 73b64a3..5db811e 100644
>> --- a/include/linux/mmzone.h
>> +++ b/include/linux/mmzone.h
>> @@ -838,6 +838,10 @@ static inline int is_normal_idx(enum zone_type idx)
>>  return (idx == ZONE_NORMAL);
>>  }
>>  
>> +static inline int is_movable(struct zone *zone)
>> +{
>> +return zone == zone->zone_pgdat->node_zones + ZONE_MOVABLE;
>> +}
> 
> A better name would be zone_is_movable().  We haven't been very
> consistent about this in mmzone.h, but zone_is_foo() is pretty common.
> 
Yes, zone_is_xxx() should be a better name, but there are some analogous
definition like is_dma32() and is_normal() etc, if we only use zone_is_movable()
for movable zone it will break such naming rules.
Should we update other ones in a separate patch later or just keep the old 
style?
 
> And a neater implementation would be
> 
>   return zone_idx(zone) == ZONE_MOVABLE;
> 
OK. After your change, should we also update for other ones such as 
is_normal()..?

> All of which made me look at mmzone.h, and what I saw wasn't very nice :(
> 
> Please review...
> 
> 
> From: Andrew Morton 
> Subject: include/linux/mmzone.h: cleanups
> 
> - implement zone_idx() in C to fix its references-args-twice macro bug
> 
> - use zone_idx() in is_highmem() to remove large amounts of silly fluff.
> 
> Cc: Lin Feng 
> Cc: Mel Gorman 
> Signed-off-by: Andrew Morton 
> ---
> 
>  include/linux/mmzone.h |   13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff -puN include/linux/mmzone.h~include-linux-mmzoneh-cleanups 
> include/linux/mmzone.h
> --- a/include/linux/mmzone.h~include-linux-mmzoneh-cleanups
> +++ a/include/linux/mmzone.h
> @@ -815,7 +815,10 @@ unsigned long __init node_memmap_size_by
>  /*
>   * zone_idx() returns 0 for the ZONE_DMA zone, 1 for the ZONE_NORMAL zone, 
> etc.
>   */
> -#define zone_idx(zone)   ((zone) - 
> (zone)->zone_pgdat->node_zones)
> +static inline enum zone_type zone_idx(struct zone *zone)
> +{
> + return zone - zone->zone_pgdat->node_zones;
> +}
>  
>  static inline int populated_zone(struct zone *zone)
>  {
> @@ -857,10 +860,10 @@ static inline int is_normal_idx(enum zon
>  static inline int is_highmem(struct zone *zone)
>  {
>  #ifdef CONFIG_HIGHMEM
> - int zone_off = (char *)zone - (char *)zone->zone_pgdat->node_zones;
> - return zone_off == ZONE_HIGHMEM * sizeof(*zone) ||
> -(zone_off == ZONE_MOVABLE * sizeof(*zone) &&
> - zone_movable_is_highmem());
> + enum zone_type idx = zone_idx(zone);
> +
> + return idx == ZONE_HIGHMEM ||
> +(idx == ZONE_MOVABLE && zone_movable_is_highmem());
>  #else
>   return 0;
>  #endif
> _
> 
> 
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -58,6 +58,8 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>>  
>>  #include 
>> @@ -1995,6 +1997,67 @@ int get_user_pages(struct task_struct *tsk, struct 
>> mm_struct *mm,
>>  }
>>  EXPORT_SYMBOL(get_user_pages);
>>  
>> +#ifdef CONFIG_MEMORY_HOTREMOVE
>> +/**
>> + * It's a wrapper of get_user_pages() but it makes sure that all pages come 
>> from
>> + * non-movable zone via additional page migration.
>> + */
> 
> This needs a description of 

Re: [PATCH] netfilter: fix missing dependencies for NETFILTER_XT_MATCH_CONNLABEL

[Pablo Neira Ayuso]

On Sun, Feb 03, 2013 at 08:04:35AM -0800, Randy Dunlap wrote:
> On 02/03/13 03:24, Florian Westphal wrote:
> > It was possible to set
> > NF_CONNTRACK=n
> > NF_CONNTRACK_LABELS=y
> > 
> > via NETFILTER_XT_MATCH_CONNLABEL=y:
> > 
> > warning: (NETFILTER_XT_MATCH_CONNLABEL) selects NF_CONNTRACK_LABELS which 
> > has
> > unmet direct dependencies (NET && INET && NETFILTER && NF_CONNTRACK)
> > 
> > Reported-by: Randy Dunlap 
> > Signed-off-by: Florian Westphal 
> 
> Acked-by: Randy Dunlap 

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] init: fix name of root device in /proc/mounts

[H. Peter Anvin]

The difference is that it used to be customary to have a /dev/root symlink; 
iirc udev created one.  Devtmpfs does not (for largely valid reasons, but it 
does break some userspaces.)

Rob Landley  wrote:

>On 01/31/2013 05:22:09 PM, H. Peter Anvin wrote:
>> On 01/31/2013 02:51 PM, William Hubbs wrote:
>> > On a system that does not use an initramfs, /dev/root was always
>> > listed in /proc/mounts. This breaks software which scans  
>> /proc/mounts to
>> > determine which file systems are mounted since /dev/root is not a  
>> valid
>> > device name.
>> >
>> > This changes that processing so that "/dev/root" is only added to
>> > /proc/mounts if a root device is not specified with the root=  
>> option on
>> > the kernel command line.
>> >
>> > Signed-off-by: William Hubbs 
>> 
>> Let me also point out that most of the time, the kernel actually has
>a
>> udev device name for an actual device...
>
>So your software is broken by overmounts? /dev/root is just one example
> 
>of this. (And you can specify a root= on the kernel command line and  
>have that be parsed by initramfs. I vaguely recall klibc does this...)
>
>For an example of how to parse this stuff, how about:
>
>   http://landley.net/hg/toybox/file/4ffb735aea59/toys/posix/df.c
>
>I.E. parse from the end of the list (most recent match is the  
>overmount), and eliminate synthetic filesystems. Note that code is from
> 
>2006, other people have managed to cope all this time...
>
>Rob

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] MMC: rtsx: remove driving adjustment

[Roger Tseng]

Hi Dan,

Correct. I will prevent this kind of breaking in the future.

However, after our analysis the breaking of patch 1/3 and 2/3 should not 
fail old devices. And since Samuel has applied 2/3 and 3/3, it might be 
better for Chris to apply patch 1/3 and let all this things appear in 
kernel v3.9.


Hi Chris,

Would you please apply patch 1/3 for kernel v3.9. Thanks.

Best regards,
Roger Tseng

On 02/04/2013 04:47 PM, Dan Carpenter wrote:

On Mon, Feb 04, 2013 at 03:45:57PM +0800, Roger Tseng wrote:

Several new models of readers use different way to select driving
capability(a necessary adjustment along with voltage change). Removing this
from device-independent rtsx_pci_sdmmc module. It will be implemented in
device-depend calls encapsulated by rtsx_pci_switch_output_voltage().



I'm not sure I understand.

Does this patch break things and then "[PATCH 2/3] mfd: rtsx:
implement driving adjustment to device-dependent callbacks" fixes
things again?  In other words, will all the old devices run if we
only apply patch 1/3 and not 2/3?

That's not the right idea.  Just merge the two patches into one
patch.

regards,
dan carpenter


--Please consider the environment before printing this e-mail.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] net: core: Remove unnecessary alloc/OOM messages

[Joe Perches]

alloc failures already get standardized OOM
messages and a dump_stack.

Signed-off-by: Joe Perches 
---
 net/core/dev.c| 14 +-
 net/core/netprio_cgroup.c |  4 +---
 2 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index a87bc74..e04bfdc 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5958,10 +5958,9 @@ static int netif_alloc_rx_queues(struct net_device *dev)
BUG_ON(count < 1);
 
rx = kcalloc(count, sizeof(struct netdev_rx_queue), GFP_KERNEL);
-   if (!rx) {
-   pr_err("netdev: Unable to allocate %u rx queues\n", count);
+   if (!rx)
return -ENOMEM;
-   }
+
dev->_rx = rx;
 
for (i = 0; i < count; i++)
@@ -5992,10 +5991,9 @@ static int netif_alloc_netdev_queues(struct net_device 
*dev)
BUG_ON(count < 1);
 
tx = kcalloc(count, sizeof(struct netdev_queue), GFP_KERNEL);
-   if (!tx) {
-   pr_err("netdev: Unable to allocate %u tx queues\n", count);
+   if (!tx)
return -ENOMEM;
-   }
+
dev->_tx = tx;
 
netdev_for_each_tx_queue(dev, netdev_init_one_queue, NULL);
@@ -6482,10 +6480,8 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, 
const char *name,
alloc_size += NETDEV_ALIGN - 1;
 
p = kzalloc(alloc_size, GFP_KERNEL);
-   if (!p) {
-   pr_err("alloc_netdev: Unable to allocate device\n");
+   if (!p)
return NULL;
-   }
 
dev = PTR_ALIGN(p, NETDEV_ALIGN);
dev->padded = (char *)dev - (char *)p;
diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index 5e67def..0777d0a 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -69,10 +69,8 @@ static int extend_netdev_table(struct net_device *dev, u32 
target_idx)
 
/* allocate & copy */
new = kzalloc(new_sz, GFP_KERNEL);
-   if (!new) {
-   pr_warn("Unable to alloc new priomap!\n");
+   if (!new)
return -ENOMEM;
-   }
 
if (old)
memcpy(new->priomap, old->priomap,


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