date:20120725

* Oleg Nesterov  [2012-07-12 19:10:25]:

> Like do_wp_page(), __replace_page() should do munlock_vma_page()
> for the case when the old page still has other !VM_LOCKED mappings.
> Unfortunately this needs mm/internal.h.
> 
> Also, move put_page() outside of ptl lock. This doesn't really
> matter but looks a bit better.
> 
> Signed-off-by: Oleg Nesterov 

One thing I wanted to check is, should we mlock the new page, i.e the
replacing page. It may not a good idea to mlock the new page
because then we can end up adding too many pages to the unevictable
list.

Acked-by: Srikar Dronamraju 

> ---
>  kernel/events/uprobes.c |8 ++--
>  1 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index fc1df43..aeea41b 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -32,6 +32,7 @@
>  #include   /* try_to_free_swap */
>  #include /* user_enable_single_step */
>  #include /* notifier mechanism */
> +#include "../../mm/internal.h"   /* munlock_vma_page */
> 
>  #include 
> 
> @@ -141,7 +142,7 @@ static int __replace_page(struct vm_area_struct *vma, 
> unsigned long addr,
>   pte_t *ptep;
>   int err;
> 
> - /* freeze PageSwapCache() for try_to_free_swap() below */
> + /* For try_to_free_swap() and munlock_vma_page() below */
>   lock_page(page);
> 
>   err = -EAGAIN;
> @@ -164,9 +165,12 @@ static int __replace_page(struct vm_area_struct *vma, 
> unsigned long addr,
>   page_remove_rmap(page);
>   if (!page_mapped(page))
>   try_to_free_swap(page);
> - put_page(page);
>   pte_unmap_unlock(ptep, ptl);
> 
> + if (vma->vm_flags & VM_LOCKED)
> + munlock_vma_page(page);
> + put_page(page);
> +
>   err = 0;
>   unlock:
>   unlock_page(page);
> -- 
> 1.5.5.1
> 

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

Re: [git patches] libata updates

2012-07-25 Thread Aaron Lu


On 07/26/2012 01:05 PM, James Bottomley wrote:

On Thu, 2012-07-26 at 12:47 +0800, Aaron Lu wrote:

On 07/26/2012 05:38 AM, Jeff Garzik wrote:

On 07/25/2012 04:35 PM, Jeff Garzik wrote:

* Updating libata to directly bind with ACPI / runtime power mgmt.
This is a pre-req for SATA ZPODD (CD-ROM power management).

Touches ACPI (exports++) and SCSI in minor ways. Has been in linux-next
for weeks.

The rest of [ZPODD] will probably come via SCSI tree, as it involves
a lot of updates to the 'sr' driver etc.


BTW Lin and Aaron, note that this did not include these changes:

sr: check support for device busy class events
sr: support zero power ODD
sr: make sure ODD is in resumed state in block ioctl

as in the end I wanted to put the brakes on SCSI-touching patches. These
should be able to go into James' scsi-misc tree with the other SCSI-area
ZPODD changes.

For those three 'sr' changes listed above, you may add

Acked-by: Jeff Garzik

when moving them over.


Thanks Jeff.

Hi James,
I'll prepare these dropped patches plus some other fixes for ZPODD which
I've sent v2 recently and merge them into v3 for you to review.


They weren't exactly dropped ... I've been waiting for you to address
Alan Stern's comments, since he's our resident expert on suspend/resume.


Oh, I forgot to mention, that I agree with Alan's comments and have
addressed them in my v2 patches here:
http://marc.info/?l=linux-scsi=134312317325650=2

The 2 patches Alan has comments are:
http://marc.info/?l=linux-scsi=134312311025619=2
http://marc.info/?l=linux-scsi=134312308225610=2

Hi Alan,
Are the v2 patches look OK to you?

And James,
Do you want me to rebase these patches on top of scsi-misc tree?

Thanks,
Aaron

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/11] perf tool: precise mode requires exclude_guest

2012-07-25 Thread David Ahern


On 7/24/12 12:03 PM, Arnaldo Carvalho de Melo wrote:

Em Tue, Jul 24, 2012 at 11:28:48AM -0600, David Ahern escreveu:

On 7/24/12 10:15 AM, Robert Richter wrote:

On AMD cpus precise_ip maps to IBS, which does not support hardware
options as perfctrs do. Thus, following attr flags are not supported:



  exclude_user, exclude_kernel, exclude_host, exclude_guest



Counting in guest mode is possible with IBS, but not the exclusion of
a certain mode. If precise_ip counting is enabled on AMD we may not
set the exclude_guest flag.



Ok, so with AMD precise_ip requires exclude_guest to be unset; for
Intel we need it set.



So then we look at vendor_id in /proc/cpuinfo?


Does it return EOPNOTSUPP or something similar if something not
supported is asked for?

Fallbacking, or capability querying if you will, may be the way to do it
without having to maintain an userland table for what is possible,
leaving it to the kernel drivers for each arch.


Peter's patch (see https://lkml.org/lkml/2012/7/9/298) changes kernel 
side to require the use of exclude_guest if the precise modifier is 
used, returning -EOPNOTSUPP if exclude_guest is not set. This patch goes 
after the user experience: Today if a user specifies -e :p all 
other modifiers are reset - including exclude_guest. Going forward we 
need :p to imply :pH if a user has not specified a GH modifer.


We could do nothing and handle the unsupported error and try setting the 
exclude_guest option - like perf handles other new parameters. But 
EOPNOTSUPP is not uniquely tied to this error -- e.g., it could be the 
BTS is not supported (:pp). Also, we have no easy way to discriminate :p 
from :pG or :pGH. It seems to me perf should not silently undo a user 
request on the modifier, but inform the user the request is wrong. For 
example if a user request -e cycles:pG it should not be silently turned 
into :pH.


And then yesterday, Robert stated that none of the exclude_ 
modifiers can be set for the AMD if the precise modifier is used, so we 
cannot blindly set exclude_guest if precise_ip is set.


So, seems to me perf need's one action for Intel processors and another 
for AMD.


David



We do it now for sample_id_all and some other newer stuff, maybe we can
do it for this as well.

- Arnaldo



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

[PATCH v2] KVM: x86: simplify read_emulated

No need split mmio read region into 8-bits pieces since we do it in
emulator_read_write_onepage

Changelog:
  Add a WARN_ON to check read-cache overflow

Acked-by: Marcelo Tosatti 
Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/emulate.c |   31 ++-
 1 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 97d9a99..e33eb02 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -1166,24 +1166,21 @@ static int read_emulated(struct x86_emulate_ctxt *ctxt,
int rc;
struct read_cache *mc = >mem_read;

-   while (size) {
-   int n = min(size, 8u);
-   size -= n;
-   if (mc->pos < mc->end)
-   goto read_cached;
-
-   rc = ctxt->ops->read_emulated(ctxt, addr, mc->data + mc->end, n,
- >exception);
-   if (rc != X86EMUL_CONTINUE)
-   return rc;
-   mc->end += n;
+   if (mc->pos < mc->end)
+   goto read_cached;

-   read_cached:
-   memcpy(dest, mc->data + mc->pos, n);
-   mc->pos += n;
-   dest += n;
-   addr += n;
-   }
+   WARN_ON((mc->end + size) >= sizeof(mc->data));
+
+   rc = ctxt->ops->read_emulated(ctxt, addr, mc->data + mc->end, size,
+ >exception);
+   if (rc != X86EMUL_CONTINUE)
+   return rc;
+
+   mc->end += size;
+
+read_cached:
+   memcpy(dest, mc->data + mc->pos, size);
+   mc->pos += size;
return X86EMUL_CONTINUE;
 }

-- 
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: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks on v3.6

2012-07-25 Thread Michael Wang

On 07/26/2012 05:16 AM, Sasha Levin wrote:
> On 07/25/2012 10:36 AM, Michael Wang wrote:
>> On 07/25/2012 01:10 AM, Sasha Levin wrote:
>>> Hi all,
>>>
>>> I was fuzzing with trinity inside a KVM tools guest, on the current 3.6, 
>>> and stumbled on the following:
>>
>> Hi, Sasha
>>
>> I'm currently trying to reproduce this issue on my machine but keep
>> failing, it's really make me think the issue has been solved...
> 
> I see this happening on both with -next and current Linus' master.
> 
>> Could you please provide more info about you environment? like the
>> .config and is there some plugin devices which is rarely.
> 
> I've attached the .config. The only device attached to the guest is a 
> virtio-9p device which provides the filesystem, but I don't think it's 
> related to the issue.
> 
>> It will be better if you can make your test environment as clean as
>> possible (remove the devices which could be remove) and then see whether
>> the issue still exist.
> 
> I can't remove the filesystem device, other that that nothing else is 
> attached to the guest.
> 
> On 07/25/2012 11:06 AM, Michael Wang wrote:
>> And is this a host dmesg or from the guest?
> 
> guest dmesg, nothing appeared in the host.

Then the situation will be more complicated...

If you are running on a X86 platform, the interrupt bit in
eflag should be 0x200, so according to the dmesg, this bit
is not set and the interrupt is disabled.

But then how to explain the timer interrupt in cpu 1's trace?
that makes me doubt there are some issues while simulating
the timer interrupt for guest.

> 
>> Could you please provide more details about your testing environment?
> 
> The guest is running a -next/3.6 kernel built with the attached .config. In 
> that guest I run an instance of the trinity fuzzer.

Could you provide the option you have used with trinity
(the full command)?
Are you running it as a root or a normal user?

I've test again with a 3.5.0 guest(fedora 16) according
to your .config, running trinity with out any option as
a normal user, the rcu stall warning doesn't appear, but
got some different warning which I have attached below.

I'm not sure whether those info also appear on your machine?

--Michael Wang

Jul 26 12:50:10 localhost kernel: [  585.900620] [ cut here 
]
Jul 26 12:50:10 localhost kernel: [  585.900652] WARNING: at 
kernel/futex.c:2452 sys_get_robust_list+0x4f/0xe5()
Jul 26 12:50:10 localhost kernel: [  585.900658] Hardware name: Bochs
Jul 26 12:50:10 localhost kernel: [  585.900660] deprecated: get_robust_list 
will be deleted in 2013.
Jul 26 12:50:10 localhost kernel: [  585.900661] Modules linked in: binfmt_misc 
bnep can_raw hidp af_802154 phonet bluetooth rfkill can pppoe pppox ppp_generic 
slhc irda crc_ccitt rds af_key rose ax25 appletalk ipx p8022 psnap llc p8023 
atm tcp_lp nls_utf8 fuse lockd ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter 
ip6_tables ppdev parport_pc microcode parport 8139too i2c_piix4 8139cp i2c_core 
pcspkr mii uinput sunrpc floppy [last unloaded: scsi_wait_scan]
Jul 26 12:50:10 localhost kernel: [  585.900737] Pid: 6627, comm: 
trinity-child11 Not tainted 3.5.0+ #16
Jul 26 12:50:10 localhost kernel: [  585.900739] Call Trace:
Jul 26 12:50:10 localhost kernel: [  585.900755]  [] 
warn_slowpath_common+0x83/0x9b
Jul 26 12:50:10 localhost kernel: [  585.900760]  [] 
warn_slowpath_fmt+0x46/0x48
Jul 26 12:50:10 localhost kernel: [  585.900771]  [] ? 
__audit_syscall_entry+0x11f/0x14b
Jul 26 12:50:10 localhost kernel: [  585.900777]  [] 
sys_get_robust_list+0x4f/0xe5
Jul 26 12:50:10 localhost kernel: [  585.900796]  [] 
system_call_fastpath+0x16/0x1b
Jul 26 12:50:10 localhost kernel: [  585.900799] ---[ end trace 
d35e4e89c7922e91 ]---
Jul 26 12:50:10 localhost kernel: [  585.968401] trinity-child11 (6627): Using 
mlock ulimits for SHM_HUGETLB is deprecated
Jul 26 12:50:10 localhost kernel: [  586.002344] warning: process 
`trinity-child7' used the deprecated sysctl system call with 
Jul 26 12:50:11 localhost dbus[919]: [system] Successfully activated service 
'org.fedoraproject.Setroubleshootd'
Jul 26 12:50:11 localhost dbus-daemon[919]: dbus[919]: [system] Successfully 
activated service 'org.fedoraproject.Setroubleshootd'
Jul 26 12:50:11 localhost abrtd: Directory 'oops-2012-07-26-12:50:11-868-0' 
creation detected
Jul 26 12:50:11 localhost abrt-dump-oops: Reported 1 kernel oopses to Abrt
Jul 26 12:50:11 localhost abrtd: Can't open file 
'/var/spool/abrt/oops-2012-07-26-12:50:11-868-0/uid': No such file or directory
Jul 26 12:50:11 localhost abrtd: DUP_OF_DIR: 
/var/spool/abrt/oops-2012-07-26-10:59:11-864-0
Jul 26 12:50:11 localhost abrtd: Dump directory is a duplicate of 
/var/spool/abrt/oops-2012-07-26-10:59:11-864-0
Jul 26 12:50:11 localhost abrtd: Deleting dump directory 
oops-2012-07-26-12:50:11-868-0 (dup of oops-2012-07-26-10:59:11-864-0), sending 
dbus signal



Jul 26 12:52:58

Re: [git patches] libata updates

2012-07-25 Thread James Bottomley

On Thu, 2012-07-26 at 12:47 +0800, Aaron Lu wrote:
> On 07/26/2012 05:38 AM, Jeff Garzik wrote:
> > On 07/25/2012 04:35 PM, Jeff Garzik wrote:
> >> * Updating libata to directly bind with ACPI / runtime power mgmt.
> >> This is a pre-req for SATA ZPODD (CD-ROM power management).
> >>
> >> Touches ACPI (exports++) and SCSI in minor ways. Has been in linux-next
> >> for weeks.
> >>
> >> The rest of [ZPODD] will probably come via SCSI tree, as it involves
> >> a lot of updates to the 'sr' driver etc.
> >
> > BTW Lin and Aaron, note that this did not include these changes:
> >
> > sr: check support for device busy class events
> > sr: support zero power ODD
> > sr: make sure ODD is in resumed state in block ioctl
> >
> > as in the end I wanted to put the brakes on SCSI-touching patches. These
> > should be able to go into James' scsi-misc tree with the other SCSI-area
> > ZPODD changes.
> >
> > For those three 'sr' changes listed above, you may add
> >
> > Acked-by: Jeff Garzik 
> >
> > when moving them over.
> 
> Thanks Jeff.
> 
> Hi James,
> I'll prepare these dropped patches plus some other fixes for ZPODD which
> I've sent v2 recently and merge them into v3 for you to review.

They weren't exactly dropped ... I've been waiting for you to address
Alan Stern's comments, since he's our resident expert on suspend/resume.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 July 26

Hi all,

Please do not add anything to linux-next included branches/series that is
destined for v3.7 until after v3.6-rc1 is released.

Reminder: do not rebase your branches before asking Linus to pull them ...

Changes since 20120725:

The libata tree lost its merge fix patch.

The scsi tree lost a conflict.

The slave-dma tree lost its conflicts.

The rr tree gained a conflict against the arm tree.

The omap_dss2 tree lost its conflicts.

The tty tree still has its build failures for which I have disabled 2
staging drivers and applied a patch.

I have still reverted 3 commits from the signal tree at the request of the
arm maintainer.

The clk tree lost its conflict.

The akpm tree gained conflicts against the rr tree.  I restored several
patches to the akpm tree with a supplied fix.



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 197 trees (counting Linus' and 26 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 (bdc0077 Merge tag 'scsi-misc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging fixes/master (9023a40 Merge tag 'mmc-fixes-for-3.5-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc)
Merging kbuild-current/rc-fixes (f8f5701 Linux 3.5-rc1)
Merging arm-current/fixes (ff081e0 ARM: 7457/1: smp: Fix suspicious RCU 
originating from cpu_die())
Merging m68k-current/for-linus (1525e06 m68k/apollo: Rename "timer" to 
"apollo_timer")
Merging powerpc-merge/merge (50fb31c tty/hvc_opal: Fix debug function name)
Merging sparc/master (d55de60 sparc64: remove unused function 
straddles_64bit_va_hole())
Merging net/master (5243e7b hyperv: Add error handling to 
rndis_filter_device_add())
Merging sound-current/for-linus (bc733d4 ALSA: mpu401: Fix missing 
initialization of irq field)
Merging pci-current/for-linus (314489b Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging wireless/master (8a70e7f NFC: NCI module license 'unspecified' taints 
kernel)
Merging driver-core.current/driver-core-linus (84a1caf Linux 3.5-rc7)
Merging tty.current/tty-linus (84a1caf Linux 3.5-rc7)
Merging usb.current/usb-linus (84a1caf Linux 3.5-rc7)
Merging staging.current/staging-linus (6887a41 Linux 3.5-rc5)
Merging char-misc.current/char-misc-linus (84a1caf Linux 3.5-rc7)
Merging input-current/for-linus (314820c Merge branch 'next' into for-linus)
Merging md-current/for-linus (58e94ae md/raid1: close some possible races on 
write errors during resync)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (a434788 crypto: twofish-avx - remove useless 
instruction)
Merging ide/master (39a50b4 Merge branch 'hfsplus')
Merging dwmw2/master (244dc4e Merge 
git://git.infradead.org/users/dwmw2/random-2.6)
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs 
formatting)
Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for 
of_parse_phandle_with_args)
Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module

Re: [PATCH] leds: triggers: send uevent when changing triggers

2012-07-25 Thread Bryan Wu

On Thu, Jul 26, 2012 at 11:59 AM, Greg KH  wrote:
> On Thu, Jul 26, 2012 at 11:29:48AM +0800, Bryan Wu wrote:
>> On Thu, Jul 26, 2012 at 2:54 AM, Colin Cross  wrote:
>> > On Tue, Jul 24, 2012 at 11:11 PM, Bryan Wu  wrote:
>> >> On Wed, Jul 25, 2012 at 8:32 AM, Colin Cross  wrote:
>> >>> Some triggers create sysfs files when they are enabled.  Send a uevent
>> >>> "change" notification whenever the trigger is changed to allow userspace
>> >>> processes such as udev to modify permissions on the new files.
>> >>>
>> >>
>> >> This looks like an workaround only for led trigger, can we fix this in
>> >> sysfs level?
>> >
>> > See the previous discussion here: https://lkml.org/lkml/2012/7/20/458
>>
>> Thanks, I went through this thread here. Actually it was archived in
>> my email account, so I missed that during a trip.
>>
>> Basically, I think this issue is a kind of general issue related to
>> sysfs, not just only for led trigger system. And adding this uevent
>> notification to a upper level LED driver is not good to me, if we got
>> similar issue in other subsystem, we should add similar fix there. Why
>> not we add this in sysfs when we call device_create_file(). And this
>> will be benefit for other drivers.
>>
>> Please point out me why we can't do that in sysfs level. Thanks.
>
> Please point out to me how you _can_ do this at a sysfs level :)
>
> greg k-h

Just one quick patch for my idea: emitting a uevent in sysfs_create_file().

--
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index 00012e3..04da869 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -570,10 +570,14 @@ int sysfs_add_file(struct sysfs_dirent *dir_sd,
const struct attribute *attr,

 int sysfs_create_file(struct kobject * kobj, const struct attribute * attr)
 {
+   int err = 0;
+
BUG_ON(!kobj || !kobj->sd || !attr);

-   return sysfs_add_file(kobj->sd, attr, SYSFS_KOBJ_ATTR);
+   err = sysfs_add_file(kobj->sd, attr, SYSFS_KOBJ_ATTR);
+   kobject_uevent(kobj, KOBJ_CHANGE);

+   return err;
 }

 int sysfs_create_files(struct kobject *kobj, const struct attribute **ptr)
--


-- 
Bryan Wu 
Kernel Developer+86.186-168-78255 Mobile
Canonical Ltd.  www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RAID extremely slow

2012-07-25 Thread Kevin Ross






unused devices:

# cat /proc/sys/dev/raid/speed_limit_min
1

MD is unable to reach its minimum rebuild rate while other system
activity is ongoing.  You might want to lower this number to see if that
gets you out of the stalls.

Or temporarily shut down mythtv.


I will try lowering those numbers next time this happens, which will 
probably be within the next day or two.  That's about how often this 
happens.


Unfortunately, it has happened again, with speeds at near zero.

# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid6 sdh1[0] sdd1[9] sde1[10] sdb1[6] sdi1[7] sdc1[4] 
sdf1[3] sdg1[8] sdj1[1]
  6837311488 blocks super 1.2 level 6, 512k chunk, algorithm 2 
[9/9] [U]
  [=>...]  resync =  8.3% (81251712/976758784) 
finish=1057826.4min speed=14K/sec


unused devices: 

atop doesn't show ANY activity on the raid device or the individual drives.
http://img687.imageshack.us/img687/2913/screenshotfrom201207252.png

Also, I tried writing to a test file with the following command, and it 
hangs.  I let it go for about 30 minutes, with no change.


# dd if=/dev/zero of=test bs=1M count=1

dmesg only reports hung tasks.  It doesn't report any other problems.  
Here's my dmesg output:

http://pastebin.ca/2174778

I'm going to try rebooting into single user mode, and see if the rebuild 
succeeds without stalling.


-- Kevin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] uprobes: fix register_for_each_vma()->vma_address() check

* Oleg Nesterov  [2012-07-12 19:10:20]:

> 1. register_for_each_vma() checks that vma_address() == vaddr but
>this is not enough. We should also ensure that vaddr >= vm_start,
>find_vma() guarantees "vaddr < vm_end" only.
> 
> 2. After the prevous changes, register_for_each_vma() is the only
>reason why vma_address() has to return loff_t, all other users
>know that we have the valid mapping at this offset and thus the
>overflow is not possible.
> 
>Change the code to use vaddr_to_offset() instead, imho this looks
>more clean/understandable and now we can change vma_address().
> 
> 3. While at it, remove the unnecessary type-cast.
> 
> Signed-off-by: Oleg Nesterov 

Acked-by: Srikar Dronamraju 

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

Re: [PATCH 3/4] uprobes: rename vma_address() and make it return "unsigned long"

* Oleg Nesterov  [2012-07-12 19:10:22]:

> 1. vma_address() returns loff_t, this looks confusing and this is
>unnecessary after the previous change. Make it return "ulong",
>all callers truncate the result anyway.
> 
> 2. Its name conflicts with mm/rmap.c:vma_address(), rename it to
>offset_to_vaddr(), this matches vaddr_to_offset().
> 
> Signed-off-by: Oleg Nesterov 

Acked-by: Srikar Dronamraju 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] uprobes: teach build_probe_list() to consider the range

* Oleg Nesterov  [2012-07-09 15:35:10]:

> Currently build_probe_list() builds the list of all uprobes attached
> to the given inode, and the caller should filter out those who don't
> fall into the [start,end) range, this is sub-optimal.
> 
> This patch turns find_least_offset_node() into find_node_in_range()
> which returns the first node inside the [min,max] range, and changes
> build_probe_list() to use this node as a starting point for rb_prev()
> and rb_next() to find all other nodes the caller needs. The resulting
> list is no longer sorted but we do not care.
> 
> This can speed up both build_probe_list() and the callers, but there
> is another reason to introduce find_node_in_range(). It can be used
> to figure out whether the given vma has uprobes or not, this will be
> needed soon.
> 
> While at it, shift INIT_LIST_HEAD(tmp_list) into build_probe_list().
> 
> Signed-off-by: Oleg Nesterov 

Acked-by: Srikar Dronamraju 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] uprobes: introduce vaddr_to_offset(vma, vaddr)

* Oleg Nesterov  [2012-07-12 19:10:17]:

> Add the new helper, vaddr_to_offset(vma, vaddr) which returns the
> offset in vma->vm_file this vaddr is mapped at.
> 
> Change build_probe_list() and find_active_uprobe() to use the new
> helper, the next patch adds another user.
> 
> Signed-off-by: Oleg Nesterov 

Acked-by: Srikar Dronamraju 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 patches] libata updates

2012-07-25 Thread Aaron Lu


On 07/26/2012 05:38 AM, Jeff Garzik wrote:

On 07/25/2012 04:35 PM, Jeff Garzik wrote:

* Updating libata to directly bind with ACPI / runtime power mgmt.
This is a pre-req for SATA ZPODD (CD-ROM power management).

Touches ACPI (exports++) and SCSI in minor ways. Has been in linux-next
for weeks.

The rest of [ZPODD] will probably come via SCSI tree, as it involves
a lot of updates to the 'sr' driver etc.


BTW Lin and Aaron, note that this did not include these changes:

sr: check support for device busy class events
sr: support zero power ODD
sr: make sure ODD is in resumed state in block ioctl

as in the end I wanted to put the brakes on SCSI-touching patches. These
should be able to go into James' scsi-misc tree with the other SCSI-area
ZPODD changes.

For those three 'sr' changes listed above, you may add

Acked-by: Jeff Garzik 

when moving them over.


Thanks Jeff.

Hi James,
I'll prepare these dropped patches plus some other fixes for ZPODD which
I've sent v2 recently and merge them into v3 for you to review.

Thanks,
Aaron

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

linux-next: manual merge of the akpm tree with the rr tree

Hi Andrew,

Today's linux-next merge of the akpm tree got conflicts in
arch/alpha/Kconfig, arch/avr32/Kconfig, arch/blackfin/Kconfig,
arch/cris/Kconfig, arch/h8300/Kconfig, arch/m32r/Kconfig,
arch/m68k/Kconfig, arch/microblaze/Kconfig, arch/mips/Kconfig,
arch/mn10300/Kconfig, arch/powerpc/Kconfig, arch/sh/Kconfig and
arch/sparc/Kconfig between commit 380470027b5c ("Make most arch
asm/module.h files use asm-generic/module.h") from the rr tree and commit
"ipc: use Kconfig options for __ARCH_WANT_[COMPAT_]IPC_PARSE_VERSION"
from the akpm tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/alpha/Kconfig
index 6f580de,1c2172b..000
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@@ -17,8 -17,7 +17,9 @@@ config ALPH
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select GENERIC_SMP_IDLE_THREAD
select GENERIC_CMOS_UPDATE
 +  select HAVE_MOD_ARCH_SPECIFIC
 +  select MODULES_USE_ELF_RELA
+   select ARCH_WANT_IPC_PARSE_VERSION
help
  The Alpha is a 64-bit general-purpose processor designed and
  marketed by the Digital Equipment Corporation of blessed memory,
diff --cc arch/avr32/Kconfig
index 2779913,5602831..000
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@@ -14,8 -14,7 +14,9 @@@ config AVR3
select ARCH_HAVE_CUSTOM_GPIO_H
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select GENERIC_CLOCKEVENTS
 +  select HAVE_MOD_ARCH_SPECIFIC
 +  select MODULES_USE_ELF_RELA
+   select ARCH_WANT_IPC_PARSE_VERSION
help
  AVR32 is a high-performance 32-bit RISC microprocessor core,
  designed for cost-sensitive embedded applications, with particular
diff --cc arch/blackfin/Kconfig
index d8dcd9f,0bc1298..000
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@@ -40,8 -40,7 +40,9 @@@ config BLACKFI
select HAVE_NMI_WATCHDOG if NMI_WATCHDOG
select GENERIC_SMP_IDLE_THREAD
select ARCH_USES_GETTIMEOFFSET if !GENERIC_CLOCKEVENTS
 +  select HAVE_MOD_ARCH_SPECIFIC
 +  select MODULES_USE_ELF_RELA
+   select ARCH_WANT_IPC_PARSE_VERSION
  
  config GENERIC_CSUM
def_bool y
diff --cc arch/cris/Kconfig
index 67ff98b,253cc2f..000
--- a/arch/cris/Kconfig
+++ b/arch/cris/Kconfig
@@@ -46,7 -46,7 +46,8 @@@ config CRI
select GENERIC_IOMAP
select GENERIC_SMP_IDLE_THREAD if ETRAX_ARCH_V32
select GENERIC_CMOS_UPDATE
 +  select MODULES_USE_ELF_RELA
+   select ARCH_WANT_IPC_PARSE_VERSION
  
  config HZ
int
diff --cc arch/h8300/Kconfig
index 9eaefdd,82379089..000
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@@ -5,7 -5,7 +5,8 @@@ config H830
select HAVE_GENERIC_HARDIRQS
select GENERIC_IRQ_SHOW
select GENERIC_CPU_DEVICES
 +  select MODULES_USE_ELF_RELA
+   select ARCH_WANT_IPC_PARSE_VERSION
  
  config SYMBOL_PREFIX
string
diff --cc arch/m32r/Kconfig
index a30478e,828e5af..000
--- a/arch/m32r/Kconfig
+++ b/arch/m32r/Kconfig
@@@ -12,7 -12,7 +12,8 @@@ config M32
select GENERIC_IRQ_SHOW
select GENERIC_ATOMIC64
select ARCH_USES_GETTIMEOFFSET
 +  select MODULES_USE_ELF_RELA
+   select ARCH_WANT_IPC_PARSE_VERSION
  
  config SBUS
bool
diff --cc arch/m68k/Kconfig
index 02fe99e,fd1c1cb..000
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@@ -11,9 -11,7 +11,10 @@@ config M68
select GENERIC_STRNLEN_USER if MMU
select FPU if MMU
select ARCH_USES_GETTIMEOFFSET if MMU && !COLDFIRE
 +  select HAVE_MOD_ARCH_SPECIFIC
 +  select MODULES_USE_ELF_REL
 +  select MODULES_USE_ELF_RELA
+   select ARCH_WANT_IPC_PARSE_VERSION
  
  config RWSEM_GENERIC_SPINLOCK
bool
diff --cc arch/microblaze/Kconfig
index ee395d3,b5ebd9f..000
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@@ -23,7 -23,7 +23,8 @@@ config MICROBLAZ
select GENERIC_CPU_DEVICES
select GENERIC_ATOMIC64
select GENERIC_CLOCKEVENTS
 +  select MODULES_USE_ELF_RELA
+   select ARCH_WANT_IPC_PARSE_VERSION
  
  config SWAP
def_bool n
diff --cc arch/mips/Kconfig
index ce65880,6c71388..000
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@@ -35,9 -35,7 +35,10 @@@ config MIP
select BUILDTIME_EXTABLE_SORT
select GENERIC_CLOCKEVENTS
select GENERIC_CMOS_UPDATE
 +  select HAVE_MOD_ARCH_SPECIFIC
 +  select MODULES_USE_ELF_REL
 +  select MODULES_USE_ELF_RELA if 64BIT
+   select ARCH_WANT_IPC_PARSE_VERSION
  
  menu "Machine selection"
  
diff --cc arch/mn10300/Kconfig
index f8fec1c,17f0ada..000
--- a/arch/mn10300/Kconfig
+++ b/arch/mn10300/Kconfig
@@@ -7,7 -7,7 +7,8 @@@ config MN1030
select HAVE_ARCH_KGDB
select HAVE_NMI_WATCHDOG if MN10300_WD_TIMER
select GENERIC_CLOCKEVENTS
 +  select MODULES_USE_ELF_RELA
+   select

ACPI & Power Management Patches for Linux-3.6-merge

2012-07-25 Thread Len Brown

Hi Linus,

Please pull these ACPI & Power Management patches.

re-write of the turbostat tool.
lower overhead was necessary for measuring very large system
when they are very idle.

IVB support in intel_idle
It's what I run on my IVB, others should be able to also:-)

ACPICA core update
We have found some bugs due to divergence between Linux
and the upstream ACPICA base.  Most of these patches
are to reduce that divergence to reduce the risk
of future bugs.

Some cpuidle updates, mostly for non-Intel
more will be coming, as they depend on this part.

Some thermal management changes needed by non-ACPI systems.

Some _OST (OS Status Indication) updates for hot ACPI hot-plug.

thanks!
Len Brown, Intel Open Source Technology Center

The following changes since commit 28a33cbc24e4256c143dce96c7d93bf423229f92:

  Linux 3.5 (2012-07-21 13:58:29 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git release

for you to fetch changes up to ec033d0a02901551346b9f43f8ff9bad51378891:

  Merge branches 'acpi_pad', 'acpica', 'apei-bugzilla-43282', 'battery', 
'cpuidle-coupled', 'cpuidle-tweaks', 'intel_idle-ivb', 'ost', 
'red-hat-bz-772730', 'thermal', 'thermal-spear' and 'turbostat-v2' into release 
(2012-07-26 00:03:58 -0400)



Bob Moore (24):
  ACPICA: Object dump routines: Use common function for string output
  ACPICA: Lint fixes for acpi_write, no functional changes
  ACPICA: Add support for multiple notify handlers
  ACPICA: Update to version 20120420
  ACPICA: Disassembler: Add support for Operation Region externals
  ACPICA: ACPI 5/iASL: Add support for PCC keyword
  ACPICA: iASL: Improved pathname support
  ACPICA: Add FADT error message for GAS BitWidth overflow
  ACPICA: Update to version 20120518
  ACPICA: Disassembler: Emit descriptions for ACPI predefined names
  ACPICA: Utilities: conditionally compile backslash removal function
  ACPICA: Update comments; no functional change
  ACPICA: Add support for implicit notify on multiple devices
  ACPICA: Update to version 20120620
  ACPICA: Split exception code utilities to a new file, utexcep.c
  ACPICA: Add new interfaces for BIOS(firmware) errors and warnings
  ACPICA: Table manager: deploy new firmware error/warning interfaces
  ACPICA: Fix some comment fields
  ACPICA: Add PCC address space to space ID decode function
  ACPICA: Split file: tbxface.c -> tbxfload.c
  ACPICA: Add new ACPI table load/unload external interfaces
  ACPICA: Update header files copyrights to 2012
  ACPICA: AcpiSrc: Fix some translation issues for Linux conversion
  ACPICA: Update to version 20120711

Colin Cross (4):
  cpuidle: refactor out cpuidle_enter_state
  cpuidle: fix error handling in __cpuidle_register_device
  cpuidle: add support for states that affect multiple cpus
  cpuidle: coupled: add parallel barrier function

Durgadoss R (2):
  Thermal: Make Thermal trip points writeable
  Thermal: Add Hysteresis attributes

Jean Delvare (1):
  ACPI, APEI: Fixup common access width firmware bug

Jesper Juhl (1):
  ACPICA: AML Parser: Fix two possible memory leaks in error path

Lan Tianyu (1):
  ACPI/AC: prevent OOPS on some boxes due to missing check 
power_supply_register() return value check

Len Brown (7):
  intel_idle: initial IVB support
  ACPI: remove acpi_pad MAINTAINERS entry
  ACPI: acpi_pad: rename "power_saving" thread to "acpi_pad" thread
  ACPI: acpi_pad: tune round_robin_time
  tools/power: turbostat v2 - re-write for efficiency
  tools/power: turbostat: fix large c1% issue
  Merge branches 'acpi_pad', 'acpica', 'apei-bugzilla-43282', 'battery', 
'cpuidle-coupled', 'cpuidle-tweaks', 'intel_idle-ivb', 'ost', 
'red-hat-bz-772730', 'thermal', 'thermal-spear' and 'turbostat-v2' into release

Lin Ming (1):
  ACPICA: Remove argument of acpi_os_wait_events_complete

Sergey Senozhatsky (1):
  cpuidle: remove unused hrtimer_peek_ahead_timers() call

Srivatsa S. Bhat (1):
  cpuidle: add checks to avoid NULL pointer dereference

Toshi Kani (6):
  ACPI: Add an interface to evaluate _OST
  ACPI: Add _OST support for sysfs eject
  ACPI: Add _OST support for ACPI CPU hotplug
  ACPI: Add _OST support for ACPI memory hotplug
  ACPI: Add _OST support for ACPI container hotplug
  ACPI: Set hotplug _OST support bit to _OSC

Viresh Kumar (1):
  drivers/thermal/spear_thermal.c: add Device Tree probing capability

Zhang Rui (1):
  Thermal: Documentation update

srinivas pandruvada (1):
  ACPI Battery: Added capacity

 .../devicetree/bindings/thermal/spear-thermal.txt  |   14 +
 Documentation/thermal/sysfs-api.txt|   30 +-
 MAINTAINERS|7 -

linux-next: manual merge of the akpm tree with the rr tree

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
arch/s390/Kconfig arch/x86/Kconfig between commit 380470027b5c ("Make
most arch asm/module.h files use asm-generic/module.h") from the rr tree
and commit 3fcc9766e733 ("atomic64_test: simplify the #ifdef for
atomic64_dec_if_positive() test") from the akpm tree.

Just context changes.  I fixed it up and can carry it as necessary.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp9EGMXLDiG5.pgp
Description: PGP signature

Re: [PATCH v5 8/8] Added /proc/net/sco via bt_procfs_init()

2012-07-25 Thread Gustavo Padovan

Hi Masatake,

* Masatake YAMATO  [2012-07-26 01:30:12 +0900]:

> Added /proc/net/sco via bt_procfs_init().
> 
> Signed-off-by: Masatake YAMATO 
> ---
>  net/bluetooth/sco.c |9 +
>  1 file changed, 9 insertions(+)

All 8 patches have been applied to bluetooth-next. Thanks.

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

[git pull] drm tree for v3.6-rc1

2012-07-25 Thread Dave Airlie


Hi Linus,

one of the smaller drm -next pulls in ages!

Ben (nouveau) has a rewrite in progress but we decided to leave it stew 
for another cycle, so just some fixes from him.

radeon: lots of documentation work, fixes, more ring and locking changes,
pcie gen2, more dp fixes,
i915: haswell features, gpu reset fixes, /dev/agpgart removal on machines 
that we never used it on, more VGA/HDP fix., more DP fixes
drm core: cleanups from Daniel, sis 64-bit fixes, range allocator 
colouring.

but yeah fairly quiet merge this time, probably because I missed half of 
it!

Dave.

The following changes since commit 84a1caf1453c3d44050bd22db958af4a7f99315c:

  Linux 3.5-rc7 (2012-07-14 15:40:28 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux.git drm-next

for you to fetch changes up to 98c7b42375011ec37251e6fc85a0471cfe499eea:

  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-next (2012-07-26 
10:40:31 +1000)



Alex Deucher (18):
  drm/radeon: clean up CS functions in r100.c
  drm/radeon: move r100_enable_bm to a more logic place
  drm/radeon: update ib_execute for SI (v2)
  drm/radeon: remove radeon_ring_index()
  drm/radeon: update rptr saving logic for memory buffers
  drm/radeon: add rptr save support for r1xx-r5xx
  drm/radeon: document radeon_device.c (v2)
  drm/radeon: document radeon_kms.c
  drm/radeon: document radeon_irq_kms.c
  drm/radeon: document radeon_asic.c
  drm/radeon: document radeon_fence.c (v2)
  drm/radeon: document radeon_ring.c (v4)
  drm/radeon: document non-VM functions in radeon_gart.c (v2)
  drm/radeon: document VM functions in radeon_gart.c (v3)
  drm/radeon: start to document the functions r100.c
  drm/radeon: start to document evergreen.c
  drm/radeon: fix up pll selection on DCE5/6
  drm/radeon: fix SS setup for DCPLL

Ander Conselvan de Oliveira (1):
  drm/i915: mask tiled bit when updating ILK sprites

Ben Skeggs (5):
  drm/nouveau: dcb table quirk for fdo#50830
  drm/nouveau/gem: fix object reference leak in a failure path
  drm/nouveau: move current gpuobj code out of nouveau_object.c
  drm/nouveau: mark most of our ioctls as deprecated, move to compat layer
  drm/nv50: extend vblank semaphore to generic dmaobj + offset pair

Ben Widawsky (29):
  drm/i915: timeout parameter for seqno wait
  drm/i915: improve i915_wait_request_begin trace
  drm/i915: wait render timeout ioctl
  drm/i915: s/i915_wait_request/i915_wait_seqno/g
  drm/i915: Dynamic Parity Detection handling
  drm/i915: enable parity error interrupts
  drm/i915: remap l3 on hw init
  drm/i915: l3 parity sysfs interface
  drm/i915: Inifite timeout for wait ioctl
  drm/i915: Add wait render timeout get param
  drm/i915: CXT_SIZE register offsets added
  drm/i915: preliminary context support
  drm/i915: context basic create & destroy
  drm/i915: context switch implementation
  drm/i915: Ivybridge MI_ARB_ON_OFF context w/a
  drm/i915: PIPE_CONTROL_TLB_INVALIDATE
  drm/i915: possibly invalidate TLB before context switch
  drm/i915: use the default context
  drm/i915: add ccid to error state
  drm/i915: switch to default context on idle
  drm/i915/context: create & destroy ioctls
  drm/i915/context: switch contexts with execbuf2
  drm/i915: reset the GPU on context fini
  drm/i915: disable contexts on old HW
  drm/i915: set IDICOS to medium uncore resources
  drm/i915: linuxify create_hw_context()
  drm/i915/context/: s/CTX/CXT
  drm/i915/context: Add missing IVB context sizes
  drm/i915: missing error case in init status page

Chris Wilson (18):
  drm/i915: All members of gen4 have hotplug, so unconditionally enable its 
irq
  drm/i915: Inspect the right status bits for DP/HDMI hotplug on gen4
  drm/i915: SDVO hotplug have different interrupt status bits for 
i915/i965/g4x
  drm/i915/hdmi: Query the live connector status bit for G4x
  drm/i915/dp: For consistency use the DP hotplug synonyms
  drm/i915/hdmi: Fix reg values for g4x_hdmi_connected
  drm/i915: Switch off FBC when disabling the primary plane when obscured
  drm/i915: Group the GT routines together in both code and vtable
  drm/i915: Implement w/a for sporadic read failures on waking from rc6
  drm: Add colouring to the range allocator
  drm/i915: Only request PM interrupts for the events we handled
  drm/i915: Disable the BLT on pre-production SNB hardware
  drm/i915: Add comments to explain the BSD tail write workaround
  drm/i915: Insert a flush between batches if the breadcrumb was dropped
  drm/i915: Make the lock for pageflips interruptible
  drm/i915: Flush the context object from the CPU caches upon switching
  drm/i915: Add

RE: [PATCH v4] mmc: dw_mmc: Disable low power mode if SDIO interrupts are used

2012-07-25 Thread Seungwon Jeon

July 26, 2012, Doug Anderson  wrote:
> The documentation for the dw_mmc part says that the low power
> mode should normally only be set for MMC and SD memory and should
> be turned off for SDIO cards that need interrupts detected.
> 
> The best place I could find to do this is when the SDIO interrupt
> was first enabled.  I rely on the fact that dw_mci_setup_bus()
> will be called when it's time to reenable.
> 
> Signed-off-by: Doug Anderson 
> ---
> Changes in v4:
> - Don't regenerate slot variable when we already had it.
> 
> Changes in v3:
> - Commenting fixes requested by Seungwoon Jeon and Jaehoon Chung.
> - Only pass 'slot' to the low power disable function since whole mmc
>   structure wasn't needed.
> 
> Changes in v2:
> - Commenting fixes requested by Grant Grundler.
> - Be extra certain that we don't re-turn on the low power mode in
>   CLKENA in dw_mci_setup_bus() if SDIO interrupts are enabled.
>   There are no known instances of this happening but it's good to be safe.
> 
>  drivers/mmc/host/dw_mmc.c |   41 ++---
>  1 files changed, 38 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 72dc3cd..882748b 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -627,6 +627,7 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot)
>  {
>   struct dw_mci *host = slot->host;
>   u32 div;
> + u32 clk_en_a;
> 
>   if (slot->clock != host->current_speed) {
>   div = host->bus_hz / slot->clock;
> @@ -659,9 +660,11 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot)
>   mci_send_cmd(slot,
>SDMMC_CMD_UPD_CLK | SDMMC_CMD_PRV_DAT_WAIT, 0);
> 
> - /* enable clock */
> - mci_writel(host, CLKENA, ((SDMMC_CLKEN_ENABLE |
> -SDMMC_CLKEN_LOW_PWR) << slot->id));
> + /* enable clock; only low power if no SDIO */
> + clk_en_a = SDMMC_CLKEN_ENABLE << slot->id;
> + if (!(mci_readl(host, INTMASK) & SDMMC_INT_SDIO(slot->id)))
> + clk_en_a |= SDMMC_CLKEN_LOW_PWR << slot->id;
> + mci_writel(host, CLKENA, clk_en_a);
> 
>   /* inform CIU */
>   mci_send_cmd(slot,
> @@ -862,6 +865,30 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
>   return present;
>  }
> 
> +/*
> + * Disable lower power mode.
> + *
> + * Low power mode will stop the card clock when idle.  According to the
> + * description of the CLKENA register we should disable low power mode
> + * for SDIO cards if we need SDIO interrupts to work.
> + *
> + * This function is fast if low power mode is already disabled.
> + */
> +static void dw_mci_disable_low_power(struct dw_mci_slot *slot)
> +{
> + struct dw_mci *host = slot->host;
> + u32 clk_en_a;
> + const u32 clken_low_pwr = SDMMC_CLKEN_LOW_PWR << slot->id;
> +
> + clk_en_a = mci_readl(host, CLKENA);
> +
> + if (clk_en_a & clken_low_pwr) {
> + mci_writel(host, CLKENA, clk_en_a & ~clken_low_pwr);
> + mci_send_cmd(slot, SDMMC_CMD_UPD_CLK |
> +  SDMMC_CMD_PRV_DAT_WAIT, 0);
> + }
> +}
> +
>  static void dw_mci_enable_sdio_irq(struct mmc_host *mmc, int enb)
>  {
>   struct dw_mci_slot *slot = mmc_priv(mmc);
> @@ -871,6 +898,14 @@ static void dw_mci_enable_sdio_irq(struct mmc_host *mmc, 
> int enb)
>   /* Enable/disable Slot Specific SDIO interrupt */
>   int_mask = mci_readl(host, INTMASK);
>   if (enb) {
> + /*
> +  * Turn off low power mode if it was enabled.  This is a bit of
> +  * a heavy operation and we disable / enable IRQs a lot, so
> +  * we'll leave low power mode disabled and it will get
> +  * re-enabled again in dw_mci_setup_bus().
> +  */
> + dw_mci_disable_low_power(slot);
> +
>   mci_writel(host, INTMASK,
>  (int_mask | SDMMC_INT_SDIO(slot->id)));
>   } else {

Basically, disabling low power mode doesn't affect origin working.
This patch will guarantees to supply the clock while sdio interrupt is 
activated.
Looks good to me.
Chris, feel free to add my ack.

Acked-by: Seungwon Jeon 

> --
> 1.7.7.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Re: [PATCH] leds: triggers: send uevent when changing triggers

2012-07-25 Thread Greg KH

On Thu, Jul 26, 2012 at 11:29:48AM +0800, Bryan Wu wrote:
> On Thu, Jul 26, 2012 at 2:54 AM, Colin Cross  wrote:
> > On Tue, Jul 24, 2012 at 11:11 PM, Bryan Wu  wrote:
> >> On Wed, Jul 25, 2012 at 8:32 AM, Colin Cross  wrote:
> >>> Some triggers create sysfs files when they are enabled.  Send a uevent
> >>> "change" notification whenever the trigger is changed to allow userspace
> >>> processes such as udev to modify permissions on the new files.
> >>>
> >>
> >> This looks like an workaround only for led trigger, can we fix this in
> >> sysfs level?
> >
> > See the previous discussion here: https://lkml.org/lkml/2012/7/20/458
> 
> Thanks, I went through this thread here. Actually it was archived in
> my email account, so I missed that during a trip.
> 
> Basically, I think this issue is a kind of general issue related to
> sysfs, not just only for led trigger system. And adding this uevent
> notification to a upper level LED driver is not good to me, if we got
> similar issue in other subsystem, we should add similar fix there. Why
> not we add this in sysfs when we call device_create_file(). And this
> will be benefit for other drivers.
> 
> Please point out me why we can't do that in sysfs level. Thanks.

Please point out to me how you _can_ do this at a sysfs level :)

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

[PATCH v2 3/3] KVM: remove dummy pages

Currently, kvm allocates some pages and use them as error indicators,
it wastes memory and is not good for scalability

Base on Avi's suggestion, we use the error codes instead of these pages
to indicate the error conditions

Signed-off-by: Xiao Guangrong 
---
 include/linux/kvm_host.h |3 +-
 virt/kvm/async_pf.c  |3 +-
 virt/kvm/kvm_main.c  |  121 +++---
 3 files changed, 52 insertions(+), 75 deletions(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 6d1a51e..f4e132c 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -411,6 +411,7 @@ void kvm_arch_flush_shadow(struct kvm *kvm);
 int gfn_to_page_many_atomic(struct kvm *kvm, gfn_t gfn, struct page **pages,
int nr_pages);

+struct page *get_bad_page(void);
 struct page *gfn_to_page(struct kvm *kvm, gfn_t gfn);
 unsigned long gfn_to_hva(struct kvm *kvm, gfn_t gfn);
 void kvm_release_page_clean(struct page *page);
@@ -564,7 +565,7 @@ void kvm_arch_sync_events(struct kvm *kvm);
 int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu);
 void kvm_vcpu_kick(struct kvm_vcpu *vcpu);

-int kvm_is_mmio_pfn(pfn_t pfn);
+bool kvm_is_mmio_pfn(pfn_t pfn);

 struct kvm_irq_ack_notifier {
struct hlist_node link;
diff --git a/virt/kvm/async_pf.c b/virt/kvm/async_pf.c
index ebae24b..7972278 100644
--- a/virt/kvm/async_pf.c
+++ b/virt/kvm/async_pf.c
@@ -203,8 +203,7 @@ int kvm_async_pf_wakeup_all(struct kvm_vcpu *vcpu)
if (!work)
return -ENOMEM;

-   work->page = bad_page;
-   get_page(bad_page);
+   work->page = get_bad_page();
INIT_LIST_HEAD(>queue); /* for list_del to work */

spin_lock(>async_pf.lock);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index eb15833..92aae8b 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -100,17 +100,11 @@ EXPORT_SYMBOL_GPL(kvm_rebooting);

 static bool largepages_enabled = true;

-struct page *bad_page;
-static pfn_t bad_pfn;
-
-static struct page *hwpoison_page;
-static pfn_t hwpoison_pfn;
-
-static struct page *fault_page;
-static pfn_t fault_pfn;
-
-inline int kvm_is_mmio_pfn(pfn_t pfn)
+bool kvm_is_mmio_pfn(pfn_t pfn)
 {
+   if (is_error_pfn(pfn))
+   return false;
+
if (pfn_valid(pfn)) {
int reserved;
struct page *tail = pfn_to_page(pfn);
@@ -936,34 +930,55 @@ EXPORT_SYMBOL_GPL(kvm_disable_largepages);

 int is_error_page(struct page *page)
 {
-   return page == bad_page || page == hwpoison_page || page == fault_page;
+   return IS_ERR(page);
 }
 EXPORT_SYMBOL_GPL(is_error_page);

 int is_error_pfn(pfn_t pfn)
 {
-   return pfn == bad_pfn || pfn == hwpoison_pfn || pfn == fault_pfn;
+   return IS_ERR_VALUE(pfn);
 }
 EXPORT_SYMBOL_GPL(is_error_pfn);

+static pfn_t get_bad_pfn(void)
+{
+   return -ENOENT;
+}
+
+pfn_t get_fault_pfn(void)
+{
+   return -EFAULT;
+}
+EXPORT_SYMBOL_GPL(get_fault_pfn);
+
+static pfn_t get_hwpoison_pfn(void)
+{
+   return -EHWPOISON;
+}
+
 int is_hwpoison_pfn(pfn_t pfn)
 {
-   return pfn == hwpoison_pfn;
+   return pfn == -EHWPOISON;
 }
 EXPORT_SYMBOL_GPL(is_hwpoison_pfn);

 int is_noslot_pfn(pfn_t pfn)
 {
-   return pfn == bad_pfn;
+   return pfn == -ENOENT;
 }
 EXPORT_SYMBOL_GPL(is_noslot_pfn);

 int is_invalid_pfn(pfn_t pfn)
 {
-   return pfn == hwpoison_pfn || pfn == fault_pfn;
+   return !is_noslot_pfn(pfn) && is_error_pfn(pfn);
 }
 EXPORT_SYMBOL_GPL(is_invalid_pfn);

+struct page *get_bad_page(void)
+{
+   return ERR_PTR(-ENOENT);
+}
+
 static inline unsigned long bad_hva(void)
 {
return PAGE_OFFSET;
@@ -1035,13 +1050,6 @@ unsigned long gfn_to_hva(struct kvm *kvm, gfn_t gfn)
 }
 EXPORT_SYMBOL_GPL(gfn_to_hva);

-pfn_t get_fault_pfn(void)
-{
-   get_page(fault_page);
-   return fault_pfn;
-}
-EXPORT_SYMBOL_GPL(get_fault_pfn);
-
 int get_user_page_nowait(struct task_struct *tsk, struct mm_struct *mm,
unsigned long start, int write, struct page **page)
 {
@@ -1119,8 +1127,7 @@ static pfn_t hva_to_pfn(unsigned long addr, bool atomic, 
bool *async,
if (npages == -EHWPOISON ||
(!async && check_user_page_hwpoison(addr))) {
up_read(>mm->mmap_sem);
-   get_page(hwpoison_page);
-   return page_to_pfn(hwpoison_page);
+   return get_hwpoison_pfn();
}

vma = find_vma_intersection(current->mm, addr, addr+1);
@@ -1158,10 +1165,8 @@ static pfn_t __gfn_to_pfn(struct kvm *kvm, gfn_t gfn, 
bool atomic, bool *async,
*async = false;

addr = gfn_to_hva(kvm, gfn);
-   if (kvm_is_error_hva(addr)) {
-   get_page(bad_page);
-   return page_to_pfn(bad_page);
-   }
+   if (kvm_is_error_hva(addr))
+   return get_bad_pfn();

return hva_to_pfn(addr, atomic, async,

Re: realtek card reader core driver

2012-07-25 Thread gre...@linuxfoundation.org

On Thu, Jul 26, 2012 at 11:11:50AM +0800, wwang wrote:
> Hi Dan:
> 
> Sorry to bother you.
> I can't find the maintainer of drivers/misc. So if I want to submit my
> driver as misc device, who should I contact to send my patch?

>From the MAINTAINERS file:

CHAR and MISC DRIVERS
M:  Arnd Bergmann 
M:  Greg Kroah-Hartman 
T:  git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
S:  Supported
F:  drivers/char/*
F:  drivers/misc/*

But note, this is the merge window time, when patches are sent to Linus
that have been in linux-next prior to the opening of the window.  That
means I can't look at any new patches like this driver, until after
3.6-rc1 is out in a week or so.

So please be patient.

thanks,

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

[PATCH v2 1/3] KVM: MMU: use kvm_release_pfn_clean to release pfn

The current code depends on the fact that fault_page is the normal page,
however, we will use the error code instead of these dummy pages in the
later patch, so we use kvm_release_pfn_clean to release pfn which will
release the error code properly

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

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 2419934..a9a2052 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3275,7 +3275,7 @@ static bool try_async_pf(struct kvm_vcpu *vcpu, bool 
prefault, gfn_t gfn,
if (!async)
return false; /* *pfn has correct page already */

-   put_page(pfn_to_page(*pfn));
+   kvm_release_pfn_clean(*pfn);

if (!prefault && can_do_async_pf(vcpu)) {
trace_kvm_try_async_get_page(gva, gfn);
-- 
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 v2 2/3] KVM: use kvm_release_page_clean to release the page

In kvm_async_pf_wakeup_all, it uses bad_page to generate broadcast wakeup,
and uses put_page to release bad_page, the work depends on the fact that
bad_page is the normal page. But we will use the error code instead of
bad_page, so use kvm_release_page_clean to release the page which will
release the error code properly

Signed-off-by: Xiao Guangrong 
---
 virt/kvm/async_pf.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/virt/kvm/async_pf.c b/virt/kvm/async_pf.c
index 74268b4..ebae24b 100644
--- a/virt/kvm/async_pf.c
+++ b/virt/kvm/async_pf.c
@@ -112,7 +112,7 @@ void kvm_clear_async_pf_completion_queue(struct kvm_vcpu 
*vcpu)
   typeof(*work), link);
list_del(>link);
if (work->page)
-   put_page(work->page);
+   kvm_release_page_clean(work->page);
kmem_cache_free(async_pf_cache, work);
}
spin_unlock(>async_pf.lock);
@@ -139,7 +139,7 @@ void kvm_check_async_pf_completion(struct kvm_vcpu *vcpu)
list_del(>queue);
vcpu->async_pf.queued--;
if (work->page)
-   put_page(work->page);
+   kvm_release_page_clean(work->page);
kmem_cache_free(async_pf_cache, work);
}
 }
-- 
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 v2 0/3] KVM: remove dummy pages

Changelog:
  correct some typos in the title/changelog.

Currently, kvm allocates some pages (e.g: bad_page/fault_page) and use them
as error indicators, it wastes memory and is not good for scalability.

Base on Avi's suggestion, in this patchset, we introduce some error codes
instead of these pages to indicate the error conditions.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] posix_types.h: Cleanup stale __NFDBITS and related definitions

2012-07-25 Thread Jonathan Nieder

Josh Boyer wrote:

> That should be the question, yes.  The answer is:
>
> However far back people wish to use older stable kernel-headers to build
> applications against newer glibc.
>
> It isn't a clear answer.

Thanks for explaining.

>   Some people stick with older kernels while
> they update their userspace.  I was thinking along the lines of the 3.0
> kernel being the oldest I'd check for but if people think we shouldn't
> bother than that's fine by me.

Based on your explanation, I think 3.0 makes sense, while older
kernels like 2.6.32 are less likely to benefit.  Even when you are
stuck with an old kernel, it is possible to use newer kernel headers.

Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] leds: triggers: send uevent when changing triggers

2012-07-25 Thread Bryan Wu

On Thu, Jul 26, 2012 at 2:54 AM, Colin Cross  wrote:
> On Tue, Jul 24, 2012 at 11:11 PM, Bryan Wu  wrote:
>> On Wed, Jul 25, 2012 at 8:32 AM, Colin Cross  wrote:
>>> Some triggers create sysfs files when they are enabled.  Send a uevent
>>> "change" notification whenever the trigger is changed to allow userspace
>>> processes such as udev to modify permissions on the new files.
>>>
>>
>> This looks like an workaround only for led trigger, can we fix this in
>> sysfs level?
>
> See the previous discussion here: https://lkml.org/lkml/2012/7/20/458

Thanks, I went through this thread here. Actually it was archived in
my email account, so I missed that during a trip.

Basically, I think this issue is a kind of general issue related to
sysfs, not just only for led trigger system. And adding this uevent
notification to a upper level LED driver is not good to me, if we got
similar issue in other subsystem, we should add similar fix there. Why
not we add this in sysfs when we call device_create_file(). And this
will be benefit for other drivers.

Please point out me why we can't do that in sysfs level. Thanks.
-- 
Bryan Wu 
Kernel Developer+86.186-168-78255 Mobile
Canonical Ltd.  www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 07/10] random: add new get_random_bytes_arch() function

2012-07-25 Thread H. Peter Anvin


On 07/25/2012 08:16 PM, H. Peter Anvin wrote:

On 07/25/2012 08:10 AM, Theodore Ts'o wrote:

Aside from whether it's better to do this step in
xfer_secondary_pool() or extract_entropy() ...


By the way, I looked at doing this in xfer_secondary_pool()... the
problem there is that xfer_secondary_pool() is called exactly once per
invocation of extract_entropy() and so there is no way to make it inject
the same amount of material as it consumes.

One could put it in extract_entropy[_user]() and if you prefer I'll
rewrite the patch to do that, however that code would look very similar
to the one in extract_buf() -- pretty much the same code in the caller
rather than the callee -- but would have the same downside with being
processed on 10-byte chunks because the final buffer might be misaligned
and/or partial.  It would mean just running it once rather than twice
per output datum, but I actually expected you would prefer the
additional mashing and security margin.



One final reason for this (although this would work in extract_buf() as 
well): the Bull Mountain internal buffer size is 16 bytes long.  This 
means that the interleaving of the buffer operation and the RDRAND pulls 
makes it quite likely that the output of RDRAND used will be 100% 
entropic, since the SHA-1 operations will typically take much longer 
than the RDRAND automatic reseed interval.


-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 07/10] random: add new get_random_bytes_arch() function

2012-07-25 Thread H. Peter Anvin


On 07/25/2012 08:10 AM, Theodore Ts'o wrote:

Aside from whether it's better to do this step in
xfer_secondary_pool() or extract_entropy() ...


By the way, I looked at doing this in xfer_secondary_pool()... the 
problem there is that xfer_secondary_pool() is called exactly once per 
invocation of extract_entropy() and so there is no way to make it inject 
the same amount of material as it consumes.


One could put it in extract_entropy[_user]() and if you prefer I'll 
rewrite the patch to do that, however that code would look very similar 
to the one in extract_buf() -- pretty much the same code in the caller 
rather than the callee -- but would have the same downside with being 
processed on 10-byte chunks because the final buffer might be misaligned 
and/or partial.  It would mean just running it once rather than twice 
per output datum, but I actually expected you would prefer the 
additional mashing and security margin.


-hpa

P.S. Anyone who have any insider info on when we can expect the SHA-3 
selection?  Switching to SHA-2 at this time with SHA-3 around the corner 
(and based on numbers I have seen, likely to be faster) seems a bit silly...


--
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] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling

On 7/26/12, Vlad Yasevich  wrote:
> Xufeng Zhang  wrote:
>
>>On 7/26/12, Xufeng Zhang  wrote:
>>> On 7/25/12, Vlad Yasevich  wrote:
> And after take a moment to look into the relative codes, I think we
> can implement it
> by below way:
> 1). Add a flag(isi_err_needed) in the embedded struct peer of
>>struct
> struct sctp_association
> just like sack_needed flag.
> 2). When "invalid stream identifier" ERROR happens in
>>sctp_eat_data()
> function, we just
> set isi_err_needed flag and don't create ERROR chunk and also don't
> insert SCTP_CMD_REPLY command.
> 3). In sctp_gen_sack() function, we create ERROR chunk and also
>>insert
> SCTP_CMD_REPLY command if isi_err_needed flag is set.
>
> Is this way proper?
>

 So, I looked at the code, and it looks very simple to do.  We
>>already
 return a specific status from sctp_eat_data() when the error was
 generated.  All you have to do is take the code that generates the
>>error
 and adds it to the command list and give it its own small function
>>that
 you can then call if SCTP_IERROR_BAD_STREAM error was returned.
>>>
>>> No, it will still has the same problem by just doing this.
>>> SCTP_CMD_GEN_SACK command actually don't enqueue SACK to outqueue,
>>> sctp_gen_sack() do this things when processing SCTP_CMD_GEN_SACK
>>command
>>> in sctp_cmd_interpreter().
>>> So it's not enough if we just insert SCTP_ERROR_INV_STRM command
>>after
>>> sctp_eat_data() return SCTP_IERROR_BAD_STREAM in
>>sctp_sf_eat_data_6_2().
>>
>>Yes, I just tried this way, SACK is still bundled after ERROR chunk.
>>But I think my above method is also not fine if there are multiple
>>error DATA chunks
>>bundled in a packet.
>>Really awesome!
>
> 1. Catch the error return.
> 2.  Set flag indicating error is needed.
> 3.  Queue sack as needed.
> 4.  If error flag set call new function to queue error chunk.

Both step 3 and 4 need lots of changes to make it working since
SACK is ready to queue only at the end of the packet and we also
need to deal with multiple "invalid stream identifier" ERROR chunks
in a single packet.


Thanks,
Xufeng Zhang
>
> That should fix things.  Do this in all callers of sctp_eat_data.
>
> -vlad
>
>>
>>
>>Thanks,
>>Xufeng Zhang
>>
>>>
>>>
>>>
>>> Thanks,
>>> Xufeng Zhang
>>>

 -vlad

>
> Thanks,
> Xufeng Zhang
>>
>>
>>
>> Thanks,
>> Xufeng Zhang
>>>
>>> -vlad

 Thanks,
 Xufeng Zhang
>
> -vlad
>>>
>>>
>>> --
>>> Sent from my Android phone with SkitMail. Please excuse my
>>brevity.
>>>
>>



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

realtek card reader core driver

2012-07-25 Thread wwang

Hi Dan:

Sorry to bother you.
I can't find the maintainer of drivers/misc. So if I want to submit my
driver as misc device, who should I contact to send my patch?

Thank you very much. I really appreciate this help.

BR,
wwang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mainline 3.5, fcoe: remove the __exit annotation of fcoe_transport_exit()

2012-07-25 Thread Sha Zhengju

From: Sha Zhengju 

While testing linux mainline v3.5, it comes out the following warning:

WARNING: drivers/scsi/fcoe/libfcoe.o(.init.text+0x21): Section mismatch in 
reference from the function
init_module() to the function .exit.text:fcoe_transport_exit()
The function __init init_module() references a function __exit 
fcoe_transport_exit().
This is often seen when error handling in the init function uses functionality 
in the exit path.
The fix is often to remove the __exit annotation of fcoe_transport_exit() so it 
may be used outside an exit section.


Signed-off-by: Sha Zhengju 
Cc: robert.w.l...@intel.com
---
 drivers/scsi/fcoe/fcoe_transport.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/fcoe/fcoe_transport.c 
b/drivers/scsi/fcoe/fcoe_transport.c
index b46f43d..71cc909 100644
--- a/drivers/scsi/fcoe/fcoe_transport.c
+++ b/drivers/scsi/fcoe/fcoe_transport.c
@@ -502,7 +502,7 @@ static int __init fcoe_transport_init(void)
return 0;
 }
 
-static int __exit fcoe_transport_exit(void)
+static int fcoe_transport_exit(void)
 {
struct fcoe_transport *ft;
 
-- 
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: [RFC PATCH 08/13] driver core: firmware loader: fix device lifetime

On Thu, Jul 26, 2012 at 12:04 AM, Borislav Petkov  wrote:
>> Also this patch holds the reference cound of @device before
>
> count

Good catch, will fix it in -v1.


>> - *   it is not possible to sleep for long time. It can't be called
>> - *   in atomic contexts.
>> + *   it is not possible to sleep for long time.
>
> Let's state it explicitly:
>
> "it is not allowed to sleep for it is called in atomic context."

Looks you understand it incorrectly, the sentence is below

 *  Asynchronous variant of request_firmware() for user contexts where
 *  it is not possible to sleep for long time.

and maybe it should be changed to below:

 *  Asynchronous variant of request_firmware() for user contexts where
 *  it is not possible to sleep for long time or can't sleep at all.

Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling

2012-07-25 Thread Vlad Yasevich

Xufeng Zhang  wrote:

>On 7/26/12, Xufeng Zhang  wrote:
>> On 7/25/12, Vlad Yasevich  wrote:
 And after take a moment to look into the relative codes, I think we
 can implement it
 by below way:
 1). Add a flag(isi_err_needed) in the embedded struct peer of
>struct
 struct sctp_association
 just like sack_needed flag.
 2). When "invalid stream identifier" ERROR happens in
>sctp_eat_data()
 function, we just
 set isi_err_needed flag and don't create ERROR chunk and also don't
 insert SCTP_CMD_REPLY command.
 3). In sctp_gen_sack() function, we create ERROR chunk and also
>insert
 SCTP_CMD_REPLY command if isi_err_needed flag is set.

 Is this way proper?

>>>
>>> So, I looked at the code, and it looks very simple to do.  We
>already
>>> return a specific status from sctp_eat_data() when the error was
>>> generated.  All you have to do is take the code that generates the
>error
>>> and adds it to the command list and give it its own small function
>that
>>> you can then call if SCTP_IERROR_BAD_STREAM error was returned.
>>
>> No, it will still has the same problem by just doing this.
>> SCTP_CMD_GEN_SACK command actually don't enqueue SACK to outqueue,
>> sctp_gen_sack() do this things when processing SCTP_CMD_GEN_SACK
>command
>> in sctp_cmd_interpreter().
>> So it's not enough if we just insert SCTP_ERROR_INV_STRM command
>after
>> sctp_eat_data() return SCTP_IERROR_BAD_STREAM in
>sctp_sf_eat_data_6_2().
>
>Yes, I just tried this way, SACK is still bundled after ERROR chunk.
>But I think my above method is also not fine if there are multiple
>error DATA chunks
>bundled in a packet.
>Really awesome!

1. Catch the error return. 
2.  Set flag indicating error is needed.
3.  Queue sack as needed.
4.  If error flag set call new function to queue error chunk.

That should fix things.  Do this in all callers of sctp_eat_data.

-vlad

>
>
>Thanks,
>Xufeng Zhang
>
>>
>>
>>
>> Thanks,
>> Xufeng Zhang
>>
>>>
>>> -vlad
>>>

 Thanks,
 Xufeng Zhang
>
>
>
> Thanks,
> Xufeng Zhang
>>
>> -vlad
>>>
>>> Thanks,
>>> Xufeng Zhang

 -vlad
>>
>>
>> --
>> Sent from my Android phone with SkitMail. Please excuse my
>brevity.
>>
>
>>>
>>>
>>>
>>


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

Re: [RFC PATCH 05/13] driver core: firmware loader: introduce firmware_buf

On Wed, Jul 25, 2012 at 9:59 PM, Borislav Petkov  wrote:

> This is subtle: the caller of fw_free_buf might forget to assign NULL to
> the buf ptr.

Who is the caller? Since it is always called inside firmware loader, we should
make sure that.

> Why not pass struct firmware_priv *fw_priv to the function instead and ...

No, it shouldn't. The lifetime of fw_priv is just same with request_firmware or
its work_func pair, but firmware_buf may live much longer than fw_priv. You
will see that fw_free_buf is the release function of kref in firmware_buf.

>
>> +
>> + for (i = 0; i < buf->nr_pages; i++)
>> + __free_page(buf->pages[i]);
>> + kfree(buf->pages);
>
> assign NULL to the ptr as a last step, when all is done:
>
> fw_priv->buf = NULL;
>
> This way you're making sure ->buf is NULL after all pages are freed and
> your check above is always correct.

It has been done in _request_firmware_load


>> - kunmap(fw_priv->pages[page_nr]);
>> + kunmap(buf->pages[page_nr]);
>>   buffer += page_cnt;
>>   offset += page_cnt;
>>   count -= page_cnt;
>> @@ -320,12 +334,13 @@ out:
>
> While you're at it, you can indent this "out:" label one space to the
> right so that the diff can pick up the function name in the hunk tag
> above instead of the label.

Suppose you are right, it shouldn't be done in this patch since this patch
just converts to firmware_buf.


Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] leds: add new lp8788 led driver

2012-07-25 Thread Bryan Wu

On Thu, Jul 26, 2012 at 2:43 AM, Mark Brown
 wrote:
> On Wed, Jul 25, 2012 at 12:46:56PM +0800, Bryan Wu wrote:
>
>> I'm going to Ack this driver and Mark will you merge this as whole patchset?
>
>> Acked-by: Bryan Wu 
>
> It's an MFD so Samuel would normally apply if it were going via the MFD
> tree, though if the dependencies are correct there should be no harm
> merging via LEDs (until the core is merged it won't be possible to
> enable the build in Kconfig).

OK, thanks, I've merge this patch through my tree and can I add your ack to it?

-- 
Bryan Wu 
Kernel Developer+86.186-168-78255 Mobile
Canonical Ltd.  www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling

On 7/26/12, Xufeng Zhang  wrote:
> On 7/25/12, Vlad Yasevich  wrote:
>>> And after take a moment to look into the relative codes, I think we
>>> can implement it
>>> by below way:
>>> 1). Add a flag(isi_err_needed) in the embedded struct peer of struct
>>> struct sctp_association
>>> just like sack_needed flag.
>>> 2). When "invalid stream identifier" ERROR happens in sctp_eat_data()
>>> function, we just
>>> set isi_err_needed flag and don't create ERROR chunk and also don't
>>> insert SCTP_CMD_REPLY command.
>>> 3). In sctp_gen_sack() function, we create ERROR chunk and also insert
>>> SCTP_CMD_REPLY command if isi_err_needed flag is set.
>>>
>>> Is this way proper?
>>>
>>
>> So, I looked at the code, and it looks very simple to do.  We already
>> return a specific status from sctp_eat_data() when the error was
>> generated.  All you have to do is take the code that generates the error
>> and adds it to the command list and give it its own small function that
>> you can then call if SCTP_IERROR_BAD_STREAM error was returned.
>
> No, it will still has the same problem by just doing this.
> SCTP_CMD_GEN_SACK command actually don't enqueue SACK to outqueue,
> sctp_gen_sack() do this things when processing SCTP_CMD_GEN_SACK command
> in sctp_cmd_interpreter().
> So it's not enough if we just insert SCTP_ERROR_INV_STRM command after
> sctp_eat_data() return SCTP_IERROR_BAD_STREAM in sctp_sf_eat_data_6_2().

Yes, I just tried this way, SACK is still bundled after ERROR chunk.
But I think my above method is also not fine if there are multiple
error DATA chunks
bundled in a packet.
Really awesome!



Thanks,
Xufeng Zhang

>
>
>
> Thanks,
> Xufeng Zhang
>
>>
>> -vlad
>>
>>>
>>> Thanks,
>>> Xufeng Zhang



 Thanks,
 Xufeng Zhang
>
> -vlad
>>
>> Thanks,
>> Xufeng Zhang
>>>
>>> -vlad
>
>
> --
> Sent from my Android phone with SkitMail. Please excuse my brevity.
>

>>
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling

2012-07-25 Thread Vlad Yasevich

Xufeng Zhang  wrote:

>On 7/25/12, Vlad Yasevich  wrote:
>>> And after take a moment to look into the relative codes, I think we
>>> can implement it
>>> by below way:
>>> 1). Add a flag(isi_err_needed) in the embedded struct peer of struct
>>> struct sctp_association
>>> just like sack_needed flag.
>>> 2). When "invalid stream identifier" ERROR happens in
>sctp_eat_data()
>>> function, we just
>>> set isi_err_needed flag and don't create ERROR chunk and also don't
>>> insert SCTP_CMD_REPLY command.
>>> 3). In sctp_gen_sack() function, we create ERROR chunk and also
>insert
>>> SCTP_CMD_REPLY command if isi_err_needed flag is set.
>>>
>>> Is this way proper?
>>>
>>
>> So, I looked at the code, and it looks very simple to do.  We already
>> return a specific status from sctp_eat_data() when the error was
>> generated.  All you have to do is take the code that generates the
>error
>> and adds it to the command list and give it its own small function
>that
>> you can then call if SCTP_IERROR_BAD_STREAM error was returned.
>
>No, it will still has the same problem by just doing this.
>SCTP_CMD_GEN_SACK command actually don't enqueue SACK to outqueue,
>sctp_gen_sack() do this things when processing SCTP_CMD_GEN_SACK
>command
>in sctp_cmd_interpreter().
>So it's not enough if we just insert SCTP_ERROR_INV_STRM command after
>sctp_eat_data() return SCTP_IERROR_BAD_STREAM in
>sctp_sf_eat_data_6_2().
>
>

All you have to do is change the order of side effect commands and the above is 
a guide.  Ill prototype it tomorrow when I have time.

-vlad
>
>Thanks,
>Xufeng Zhang
>
>>
>> -vlad
>>
>>>
>>> Thanks,
>>> Xufeng Zhang



 Thanks,
 Xufeng Zhang
>
> -vlad
>>
>> Thanks,
>> Xufeng Zhang
>>>
>>> -vlad
>
>
> --
> Sent from my Android phone with SkitMail. Please excuse my
>brevity.
>

>>
>>
>>


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

Re: [RFC PATCH 07/13] driver core: firmware loader: introduce cache_firmware and uncache_firmware

On Wed, Jul 25, 2012 at 11:52 PM, Borislav Petkov  wrote:
>
> You have similar functionality in fw_lookup_and_alloate_buf() above.
> Can't you reuse it instead of defining a new function?

The problem is that the lock can't be released between lookup and allocate
inside fw_lookup_and_alloate_buf(). I will try to introduce __fw_lookup_buf
and reuse it in both fw_lookup_and_alloate_buf and fw_lookup_buf.

Also will fix the comments and code style you mentioned in -v1.

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

Re: [RFC PATCH 07/13] driver core: firmware loader: introduce cache_firmware and uncache_firmware

On Wed, Jul 25, 2012 at 3:54 PM, Stephen Boyd  wrote:
> On 7/24/2012 10:00 AM, Ming Lei wrote:
>>
>> +
>> +int cache_firmware(const char *name)
>> +{
>> + return -ENOENT;
>> +}
>> +
>> +int uncache_firmware(const char *name)
>> +{
>> + return -EINVAL;
>> +}
>
> These stubs need to be static inline to avoid compiler warnings.

Good catch, will fix it in v1.

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

Re: [RFC PATCH 00/13] firmware loader: introduce cache/uncache firmware

On Thu, Jul 26, 2012 at 1:23 AM, Linus Torvalds
 wrote:
>
> So *if* the only problem wrt the USB hub code comes from this area,

IMO,  USB hub code may not be the only one because both device_add and
device_del can just be run in process context, so any hotplug bus
may have this kind of problem since the devices in the bus may be
unplugged and plugged again during suspend or experience power loss
, then the bus driver may take similar handling policy as USB.

> then I think the solution might be as simple as just moving the
> "usermodehelper_enable()" up a few lines, with a comment. Something
> like the *untested* and whitespace-damaged thing below..
>
> Rafael? Who has one of those isight things and has seen the warning to test?

I fake one USB device disconnect in reset_resume path and looks the patch
is good: the device driver can request firmware successfully in its .probe().

>
>Linus
>
> ---
> diff --git a/kernel/power/process.c b/kernel/power/process.c
> index 19db29f67558..5bf50e488196 100644
> --- a/kernel/power/process.c
> +++ b/kernel/power/process.c
> @@ -181,6 +181,12 @@ void thaw_processes(void)
> pm_freezing = false;
> pm_nosig_freezing = false;
>
> +   /*
> +* User mode helper are available again (or will be,
> +* modulo scheduling)
> +*/
> +   usermodehelper_enable();

This may wake up tasks earlier than before, not sure if it might have
side effects.

Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: RAID extremely slow

2012-07-25 Thread Kevin Ross


On 07/25/2012 07:09 PM, CoolCold wrote:
You might be interested in write intent bitmap then, it gonna help a 
lot. (resending in plain text)


Thanks, I'll look into that!

-- Kevin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tlg2300: Declare MODULE_FIRMWARE usage

2012-07-25 Thread Huang Shijie

thanks.

Acked-by: Huang Shijie 

On Thu, Jul 26, 2012 at 3:41 AM, Tim Gardner  wrote:
> Cc: Huang Shijie 
> Cc: Kang Yong 
> Cc: Zhang Xiaobing 
> Cc: Mauro Carvalho Chehab 
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Tim Gardner 
> ---
>  drivers/media/video/tlg2300/pd-main.c |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/video/tlg2300/pd-main.c 
> b/drivers/media/video/tlg2300/pd-main.c
> index c096b3f..7b1f6eb 100644
> --- a/drivers/media/video/tlg2300/pd-main.c
> +++ b/drivers/media/video/tlg2300/pd-main.c
> @@ -53,7 +53,8 @@ int debug_mode;
>  module_param(debug_mode, int, 0644);
>  MODULE_PARM_DESC(debug_mode, "0 = disable, 1 = enable, 2 = verbose");
>
> -static const char *firmware_name = "tlg2300_firmware.bin";
> +#define TLG2300_FIRMWARE "tlg2300_firmware.bin"
> +static const char *firmware_name = TLG2300_FIRMWARE;
>  static struct usb_driver poseidon_driver;
>  static LIST_HEAD(pd_device_list);
>
> @@ -532,3 +533,4 @@ MODULE_AUTHOR("Telegent Systems");
>  MODULE_DESCRIPTION("For tlg2300-based USB device ");
>  MODULE_LICENSE("GPL");
>  MODULE_VERSION("0.0.2");
> +MODULE_FIRMWARE(TLG2300_FIRMWARE);
> --
> 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 patches] libata updates

2012-07-25 Thread Jeff Garzik


On 07/25/2012 07:30 PM, Linus Torvalds wrote:

On Wed, Jul 25, 2012 at 3:58 PM, Jeff Garzik  wrote:


What is the right course in when a post-merge change is needed?


Just describe the issue and the required change. Than I can just do it
as part of the merge, and now the whole series is bisectable,
including the merge itself.

Here's a (fairly bad) example:

   http://www.spinics.net/lists/netdev/msg192349.html

and the reason I call that a bad example is not because that's a bad
pull request, but simply that those are all real data conflicts, not
the more subtle kind of "it merges fine, but because new code
introduced uses an interface that changed, you need to do xyz".


Thanks, so noted.  I guess if the merge gets more complex than something 
easily described in an email, that implies that maintainers should do 
more cross-coordination and maybe a merge tree.


What's the best way for libata to move forward, now that this hideous 
merge has been pushed out to the Well Known libata branches?  The 
pre-jgarzik-merge commit you would have pulled is 
dc7f71f486f4f5fa96f6dcf86833da020cde8a11 had my pull request been proper.


I can lop off the top 3 commits and force-update the libata-dev.git 
branches, then send a new pull request -- but you have grumbled at that 
sort of behavior in maintainer trees before too...


Jeff


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: RAID extremely slow

2012-07-25 Thread CoolCold

On Thu, Jul 26, 2012 at 5:55 AM, Kevin Ross  wrote:
>
> Thank you very much for taking the time to look into this.
>
>
> On 07/25/2012 06:00 PM, Phil Turmel wrote:
>>
>> Piles of small reads  scattered across multiple drives, and a
>> concentration of queued writes to /dev/sda.  What's on /dev/sda?
>> It's not a member of the raid, so it must be some other system task
>> involved.
>
>
> /dev/sda1 is the root filesystem.  The writes were most likely by MySQL,
> but I would have to run iotop to be sure.
>
>
>> [ The output of "lsdrv" [1] might be useful here, along with
>> "mdadm -D /dev/md0" and "mdadm -E /dev/[b-j]" ]
>
>
> Here you go: http://pastebin.ca/2174740
>
>
>> MythTV is trying to flush recorded video to disk, I presume.  Sync is
>> known to cause stalls--a great deal of work is on-going to improve
>> this.  How old is this kernel?
>
>
> After rebooting, MythTV is currently recording two shows, and the resync
> is running at full speed.
>
>
> # cat /proc/mdstat
> Personalities : [raid6] [raid5] [raid4]
> md0 : active raid6 sdh1[0] sdd1[9] sde1[10] sdb1[6] sdi1[7] sdc1[4]
> sdf1[3] sdg1[8] sdj1[1]
>   6837311488 blocks super 1.2 level 6, 512k chunk, algorithm 2 [9/9]
> [U]
>   [=>...]  resync =  9.3% (91363840/976758784)
> finish=1434.3min speed=10287K/sec
>
> unused devices: 
>
> atop shows the avio of all the drives to be less than 1ms, where before
> they were much higher.  It will run for a couple days under load just fine,
> and then it will come to a halt.
>
> It's a 3.2.21 kernel.  I'm running Debian Testing, and the exact Debian
> package version is:
>
> ii  linux-image-3.2.0-3-686-pae3.2.21-3
> Linux 3.2 for modern PCs
>
>
>>
>>> [51000.672258]  [] ? sysenter_do_call+0x12/0x28
>>> [51000.672261]  [] ? quirk_usb_early_handoff+0x4a9/0x522
>>>
>>> Here is some other possibly relevant info:
>>>
>>> # cat /proc/mdstat
>>> Personalities : [raid6] [raid5] [raid4]
>>> md0 : active raid6 sdh1[0] sdd1[9] sde1[10] sdb1[6] sdi1[7] sdc1[4]
>>> sdf1[3] sdg1[8] sdj1[1]
>>>6837311488 blocks super 1.2 level 6, 512k chunk, algorithm 2
>>> [9/9]
>>> [U]
>>>[==>..]  resync = 51.3% (501954432/976758784)
>>> finish=28755.6min speed=275K/sec
>>
>> Is this resync a weekly check, or did something else trigger it?
>
>
> This is not a scheduled check.  It was triggered by, I believe, an unclean
> shutdown.  An unclean shutdown will trigger a resync.  I don't think it used
> to do this, but I could be remembering wrong.
>
>
>>
>>> unused devices:
>>>
>>> # cat /proc/sys/dev/raid/speed_limit_min
>>> 1
>>
>> MD is unable to reach its minimum rebuild rate while other system
>> activity is ongoing.  You might want to lower this number to see if that
>> gets you out of the stalls.
>>
>> Or temporarily shut down mythtv.
>
>
> I will try lowering those numbers next time this happens, which will
> probably be within the next day or two.  That's about how often this
> happens.
You might be interested in write intent bitmap then, it gonna help a lot.
(resending in plain text)
>
>
>>> # cat /proc/sys/dev/raid/speed_limit_max
>>> 20
>>>
>>> Thanks in advance!
>>> -- Kevin
>>
>> HTH,
>>
>> Phil
>>
>> [1] http://github.com/pturmel/lsdrv
>>
>
> Thanks!
> -- Kevin
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html




--
Best regards,
[COOLCOLD-RIPN]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] posix_types.h: Cleanup stale __NFDBITS and related definitions

On Wed, 2012-07-25 at 21:27 -0400, Josh Boyer wrote:
> On Thu, Jul 26, 2012 at 12:26:36AM +0100, Ben Hutchings wrote:
> > On Wed, 2012-07-25 at 10:40 -0400, Josh Boyer wrote:
> > > Recently, glibc made a change to suppress sign-conversion warnings in 
> > > FD_SET
> > > (glibc commit ceb9e56b3d1).  This uncovered an issue with the kernel's
> > > definition of __NFDBITS if applications #include  after
> > > including .  A build failure would be seen when passing the
> > > -Werror=sign-compare and -D_FORTIFY_SOURCE=2 flags to gcc.
> > > 
> > > It was suggested that the kernel should either match the glibc definition 
> > > of
> > > __NFDBITS or remove that entirely.  The current in-kernel uses of 
> > > __NFDBITS
> > > can be replaced with BITS_PER_LONG, and there are no uses of the related
> > > __FDELT and __FDMASK defines.  Given that, we'll continue the cleanup that
> > > was started with commit 8b3d1cda4f5f ("posix_types: Remove fd_set macros")
> > > and drop the remaining unused macros.
> > > 
> > > Additionally, linux/time.h has similar macros defined that expand to 
> > > nothing
> > > so we'll remove those at the same time.
> > > 
> > > Reported-by: Jeff Law 
> > > Suggested-by: Linus Torvalds 
> > > CC: 
> > 
> > # v3.4+
> > 
> > (as 8b3d1cda4f5f went into 3.4)
> >
> 
> Indeed.  However, I believe Linus pointed out that even before
> 8b3d1cda4f5f the macros that were removed weren't actually used.
> It's likely safe to go back further than just 3.4.
> 
> I'll verify again in the morning and include the furthest back we could
> remove these.  For now, let's go with what you suggest to be safe.

Yes, on reflection, this is mostly independent of commit 8b3d1cda4f5f.

The problem is that userland might accidentally be depending on getting
the definitions of NFDBITS and FD_SETSIZE from .  But,
having now read Linus's history of the rotting of these particular bits
, I agree this is
very unlikely.  So, I withdraw my request to restrict the target stable
versions.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


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

linux-next: manual merge of the rr tree with the arm tree

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
arch/arm/Kconfig between commits 8c56cc8be5b3 ("ARM: 7449/1: use generic
strnlen_user and strncpy_from_user functions") and b9a50f74905a ("ARM:
7450/1: dcache: select DCACHE_WORD_ACCESS for little-endian ARMv6+ CPUs")
from the arm tree and commit 380470027b5c ("Make most arch asm/module.h
files use asm-generic/module.h") from the rr tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/arm/Kconfig
index 71257da,af8bf36..000
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@@ -45,9 -45,8 +45,11 @@@ config AR
select GENERIC_SMP_IDLE_THREAD
select KTIME_SCALAR
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
 +  select GENERIC_STRNCPY_FROM_USER
 +  select GENERIC_STRNLEN_USER
 +  select DCACHE_WORD_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && 
!CPU_BIG_ENDIAN
+   select HAVE_MOD_ARCH_SPECIFIC if ARM_UNWIND
+   select MODULES_USE_ELF_REL
help
  The ARM series is a line of low-power-consumption RISC chip designs
  licensed by ARM Ltd and targeted at embedded applications and


pgpb0lUs2m9MQ.pgp
Description: PGP signature

[PATCH] perf target: Fix check on buffer size

2012-07-25 Thread Namhyung Kim

From: Namhyung Kim 

It was a mistake just replace assert to BUG_ON since its condition
should be negated. Fix it.

Cc: Kirill A. Shutemov 
Cc: Ulrich Drepper 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/target.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/target.c b/tools/perf/util/target.c
index 3f59c496e64c..051eaa68095e 100644
--- a/tools/perf/util/target.c
+++ b/tools/perf/util/target.c
@@ -110,7 +110,7 @@ int perf_target__strerror(struct perf_target *target, int 
errnum,
int idx;
const char *msg;
 
-   BUG_ON(buflen > 0);
+   BUG_ON(buflen == 0);
 
if (errnum >= 0) {
const char *err = strerror_r(errnum, buf, buflen);
-- 
1.7.10.4

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

Re: RAID extremely slow

2012-07-25 Thread Kevin Ross


Thank you very much for taking the time to look into this.

On 07/25/2012 06:00 PM, Phil Turmel wrote:

Piles of small reads  scattered across multiple drives, and a
concentration of queued writes to /dev/sda.  What's on /dev/sda?
It's not a member of the raid, so it must be some other system task
involved.


/dev/sda1 is the root filesystem.  The writes were most likely by MySQL, 
but I would have to run iotop to be sure.



[ The output of "lsdrv" [1] might be useful here, along with
"mdadm -D /dev/md0" and "mdadm -E /dev/[b-j]" ]


Here you go: http://pastebin.ca/2174740


MythTV is trying to flush recorded video to disk, I presume.  Sync is
known to cause stalls--a great deal of work is on-going to improve
this.  How old is this kernel?


After rebooting, MythTV is currently recording two shows, and the resync 
is running at full speed.


# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid6 sdh1[0] sdd1[9] sde1[10] sdb1[6] sdi1[7] sdc1[4] 
sdf1[3] sdg1[8] sdj1[1]
  6837311488 blocks super 1.2 level 6, 512k chunk, algorithm 2 
[9/9] [U]
  [=>...]  resync =  9.3% (91363840/976758784) 
finish=1434.3min speed=10287K/sec


unused devices: 

atop shows the avio of all the drives to be less than 1ms, where before 
they were much higher.  It will run for a couple days under load just 
fine, and then it will come to a halt.


It's a 3.2.21 kernel.  I'm running Debian Testing, and the exact Debian 
package version is:


ii  linux-image-3.2.0-3-686-pae
3.2.21-3   Linux 3.2 for modern PCs





[51000.672258]  [] ? sysenter_do_call+0x12/0x28
[51000.672261]  [] ? quirk_usb_early_handoff+0x4a9/0x522

Here is some other possibly relevant info:

# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid6 sdh1[0] sdd1[9] sde1[10] sdb1[6] sdi1[7] sdc1[4]
sdf1[3] sdg1[8] sdj1[1]
   6837311488 blocks super 1.2 level 6, 512k chunk, algorithm 2 [9/9]
[U]
   [==>..]  resync = 51.3% (501954432/976758784)
finish=28755.6min speed=275K/sec

Is this resync a weekly check, or did something else trigger it?


This is not a scheduled check.  It was triggered by, I believe, an 
unclean shutdown.  An unclean shutdown will trigger a resync.  I don't 
think it used to do this, but I could be remembering wrong.





unused devices:

# cat /proc/sys/dev/raid/speed_limit_min
1

MD is unable to reach its minimum rebuild rate while other system
activity is ongoing.  You might want to lower this number to see if that
gets you out of the stalls.

Or temporarily shut down mythtv.


I will try lowering those numbers next time this happens, which will 
probably be within the next day or two.  That's about how often this 
happens.



# cat /proc/sys/dev/raid/speed_limit_max
20

Thanks in advance!
-- Kevin

HTH,

Phil

[1] http://github.com/pturmel/lsdrv



Thanks!
-- Kevin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] posix_types.h: Cleanup stale __NFDBITS and related definitions

2012-07-25 Thread Josh Boyer

On Wed, Jul 25, 2012 at 08:33:22PM -0500, Jonathan Nieder wrote:
> Hi,
> 
> Josh Boyer wrote:
> 
> > Indeed.  However, I believe Linus pointed out that even before
> > 8b3d1cda4f5f the macros that were removed weren't actually used.
> > It's likely safe to go back further than just 3.4.
> >
> > I'll verify again in the morning and include the furthest back we could
> > remove these.  For now, let's go with what you suggest to be safe.
> 
> I may be in the minority in having this view or missing a subtlety,
> but shouldn't the question be the furthest back we need to remove
> these rather than the furthest back we could?

That should be the question, yes.  The answer is:

However far back people wish to use older stable kernel-headers to build
applications against newer glibc.

It isn't a clear answer.  Some people stick with older kernels while
they update their userspace.  I was thinking along the lines of the 3.0
kernel being the oldest I'd check for but if people think we shouldn't
bother than that's fine by me.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Fetch dmi version from SMBIOS if it exist

2012-07-25 Thread zhenzhong.duan




于 2012-07-26 03:55, Andrew Morton 写道:

On Wed, 25 Jul 2012 19:05:09 +0800
"zhenzhong.duan"  wrote:


The right dmi version is in SMBIOS if it's zero in DMI region


This description is too brief to permit me to understand the patch.
Can you please provide a more detailed explanation?


This issue was originally found from an oracle bug.
One customer noticed system UUID doesn't match between dmidecode & uek2.
HP ProLiant BL460c G6 :
# cat /sys/devices/virtual/dmi/id/product_uuid
--4C48-3031-4D5030333531
# dmidecode | grep -i uuid
UUID: --484C-3031-4D5030333531
From SMBIOS 2.6 on, spec use little-endian encoding for UUID other than 
network byte order.
So we need to get dmi version to distinguish. If version is 0.0, the 
real version is taken from the SMBIOS version. This is part of original 
kernel comment in code.


thanks
zduan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] vsprintf: Fix %ps on non symbols when using kallsyms

2012-07-25 Thread Stephen Boyd

Hi Andrew,

On 4/23/2012 2:55 PM, Andrew Morton wrote:
> On Mon, 23 Apr 2012 14:45:24 -0700
> Stephen Boyd  wrote:
>
>> Using %ps in a printk format will sometimes fail silently and
>> print the empty string if the address passed in does not match a
>> symbol that kallsyms knows about.

A coworker pointed out that the second patch in this series now prints
the symbol closest to the address passed in if kallsyms sees the address
is between two symbols. So if I have a pointer to some member of a
structure %ps prints the symbol for the containing structure, which is
not really helpful.

For example

struct test {
  int i;
  int j;
} my_test;

printk("%ps\n", _test.j)

would print out "my_test" instead of "0xc4523400".

This is especially bad for the spinlock debugging case where there could
be two locks embedded in some static structure. I think it would be a
good idea to apply this patch so we get a good middle ground by printing
the name and the offset. Or we can revert the patch and I'll add more
info by printing lockdep information about the lock.

-8<--

From: Stephen Boyd 
Subject: [PATCH] spinlock_debug: Print offset in addition to symbol name

If there are two spinlocks embedded in a structure that kallsyms
knows about and one of the spinlocks locks up we will print the
name of the containing structure instead of the address of the
lock. This is quite bad, so let's use %pS instead of %ps so we
get an offset in addition to the symbol so we can determine which
particular lock is having problems.

Signed-off-by: Stephen Boyd 
---
 lib/spinlock_debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/spinlock_debug.c b/lib/spinlock_debug.c
index e91fbc2..eb10578 100644
--- a/lib/spinlock_debug.c
+++ b/lib/spinlock_debug.c
@@ -58,7 +58,7 @@ static void spin_dump(raw_spinlock_t *lock, const char *msg)
printk(KERN_EMERG "BUG: spinlock %s on CPU#%d, %s/%d\n",
msg, raw_smp_processor_id(),
current->comm, task_pid_nr(current));
-   printk(KERN_EMERG " lock: %ps, .magic: %08x, .owner: %s/%d, "
+   printk(KERN_EMERG " lock: %pS, .magic: %08x, .owner: %s/%d, "
".owner_cpu: %d\n",
lock, lock->magic,
owner ? owner->comm : "",

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drivers/misc: Add realtek card reader core driver

2012-07-25 Thread wwang


Hi Aaron:

Thank you. I will modify our host per your suggestion.

BR,
wwang

于 2012年07月25日 18:16, Aaron Lu 写道:

Hi Wei,

We do not use MMC_CAP_MAX_CURRENT_* anymore, for your host, I would
sugget you do something like this:

static void realtek_init(struct realtek_sdmmc *host)
{
struct mmc_host *mmc = host->mmc;
... ...
/*
 * since you have set MMC_CAP_MAX_CURRENT_800 in your
 * original code, I assume your host can provide more than
 * 800mA, and you've set the 1.8v support bit in your original
 * code for the host, so I also set the max_current_180 to 800mA.
 */
mmc->max_current_330 = 800;
mmc->max_current_180 = 800;
... ...
}

Does this look right to you?

Thanks,
Aaron




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling

On 7/25/12, Neil Horman  wrote:
> On Wed, Jul 25, 2012 at 05:22:19PM +0800, Xufeng Zhang wrote:
>> On 7/25/12, Xufeng Zhang  wrote:
>> > On 7/25/12, Vlad Yasevich  wrote:
>> >>
>> >> Actually not true.  AUTH can be before SACK.  So can any addip chunks
>> >> that
>> >> aid in locating an association.
>> >>
>> >> Now AUTH isn't a big issue since its autogenerated to the packet but
>> >> ADDIP
>> >> is since it could be queued up for retransmission.
>> >>
>> >> There could be other extensions as well.  It really needs to be done
>> >> either
>> >> through side effects or making error chunks go at the end of other
>> >> control
>> >> chunks.  Need to audit the spec to see if that's ok.
>> > You are right, I just found SHUTDOWN chunks are also before SACK based
>> > on
>> > your commit "[SCTP]: Fix SACK sequence during shutdown".
>> > Maybe the only solution is to do some work on side effects just as you
>> > said.
>> > Thanks for your explanation!
>>
>> And after take a moment to look into the relative codes, I think we
>> can implement it
>> by below way:
>> 1). Add a flag(isi_err_needed) in the embedded struct peer of struct
>> struct sctp_association
>> just like sack_needed flag.
>> 2). When "invalid stream identifier" ERROR happens in sctp_eat_data()
>> function, we just
>> set isi_err_needed flag and don't create ERROR chunk and also don't
>> insert SCTP_CMD_REPLY command.
>> 3). In sctp_gen_sack() function, we create ERROR chunk and also insert
>> SCTP_CMD_REPLY command if isi_err_needed flag is set.
>>
>> Is this way proper?
>>
> That would probably work yes.  Another way might just be to do some
> re-ordering
> in sctp_outq_flush.  Before processing the control chunk list, scan it,
> and:
> 1) move all error chunks to the head of the list
> 2) move all sack chunks to the head of the list
> 3) move all shutdown chunks to the head of the list
>
> You can do that in a single iteration of the list if you use a few on-stack
> lists and list_splice

Thank you very much for your suggestion!
I'll compare it with side effects modification and make a decision.


Thanks,
Xufeng Zhang

>
> Neil
>
>>
>> Thanks,
>> Xufeng Zhang
>> >
>> >
>> >
>> > Thanks,
>> > Xufeng Zhang
>> >>
>> >> -vlad
>> >>>
>> >>>Thanks,
>> >>>Xufeng Zhang
>> 
>>  -vlad
>> >>
>> >>
>> >> --
>> >> Sent from my Android phone with SkitMail. Please excuse my brevity.
>> >>
>> >
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] posix_types.h: Cleanup stale __NFDBITS and related definitions

2012-07-25 Thread Jonathan Nieder

Hi,

Josh Boyer wrote:

> Indeed.  However, I believe Linus pointed out that even before
> 8b3d1cda4f5f the macros that were removed weren't actually used.
> It's likely safe to go back further than just 3.4.
>
> I'll verify again in the morning and include the furthest back we could
> remove these.  For now, let's go with what you suggest to be safe.

I may be in the minority in having this view or missing a subtlety,
but shouldn't the question be the furthest back we need to remove
these rather than the furthest back we could?

Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling

On 7/25/12, Vlad Yasevich  wrote:
>> And after take a moment to look into the relative codes, I think we
>> can implement it
>> by below way:
>> 1). Add a flag(isi_err_needed) in the embedded struct peer of struct
>> struct sctp_association
>> just like sack_needed flag.
>> 2). When "invalid stream identifier" ERROR happens in sctp_eat_data()
>> function, we just
>> set isi_err_needed flag and don't create ERROR chunk and also don't
>> insert SCTP_CMD_REPLY command.
>> 3). In sctp_gen_sack() function, we create ERROR chunk and also insert
>> SCTP_CMD_REPLY command if isi_err_needed flag is set.
>>
>> Is this way proper?
>>
>
> So, I looked at the code, and it looks very simple to do.  We already
> return a specific status from sctp_eat_data() when the error was
> generated.  All you have to do is take the code that generates the error
> and adds it to the command list and give it its own small function that
> you can then call if SCTP_IERROR_BAD_STREAM error was returned.

No, it will still has the same problem by just doing this.
SCTP_CMD_GEN_SACK command actually don't enqueue SACK to outqueue,
sctp_gen_sack() do this things when processing SCTP_CMD_GEN_SACK command
in sctp_cmd_interpreter().
So it's not enough if we just insert SCTP_ERROR_INV_STRM command after
sctp_eat_data() return SCTP_IERROR_BAD_STREAM in sctp_sf_eat_data_6_2().



Thanks,
Xufeng Zhang

>
> -vlad
>
>>
>> Thanks,
>> Xufeng Zhang
>>>
>>>
>>>
>>> Thanks,
>>> Xufeng Zhang

 -vlad
>
> Thanks,
> Xufeng Zhang
>>
>> -vlad


 --
 Sent from my Android phone with SkitMail. Please excuse my brevity.

>>>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] posix_types.h: Cleanup stale __NFDBITS and related definitions

2012-07-25 Thread Josh Boyer

On Thu, Jul 26, 2012 at 12:26:36AM +0100, Ben Hutchings wrote:
> On Wed, 2012-07-25 at 10:40 -0400, Josh Boyer wrote:
> > Recently, glibc made a change to suppress sign-conversion warnings in FD_SET
> > (glibc commit ceb9e56b3d1).  This uncovered an issue with the kernel's
> > definition of __NFDBITS if applications #include  after
> > including .  A build failure would be seen when passing the
> > -Werror=sign-compare and -D_FORTIFY_SOURCE=2 flags to gcc.
> > 
> > It was suggested that the kernel should either match the glibc definition of
> > __NFDBITS or remove that entirely.  The current in-kernel uses of __NFDBITS
> > can be replaced with BITS_PER_LONG, and there are no uses of the related
> > __FDELT and __FDMASK defines.  Given that, we'll continue the cleanup that
> > was started with commit 8b3d1cda4f5f ("posix_types: Remove fd_set macros")
> > and drop the remaining unused macros.
> > 
> > Additionally, linux/time.h has similar macros defined that expand to nothing
> > so we'll remove those at the same time.
> > 
> > Reported-by: Jeff Law 
> > Suggested-by: Linus Torvalds 
> > CC: 
> 
> # v3.4+
> 
> (as 8b3d1cda4f5f went into 3.4)
>

Indeed.  However, I believe Linus pointed out that even before
8b3d1cda4f5f the macros that were removed weren't actually used.
It's likely safe to go back further than just 3.4.

I'll verify again in the morning and include the furthest back we could
remove these.  For now, let's go with what you suggest to be safe.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: RAID extremely slow

2012-07-25 Thread Phil Turmel

[Added linux-raid to the CC]

Hi Kevin,

Notes interleaved:

On 07/25/2012 06:52 PM, Kevin Ross wrote:
> Hello,
> 
> I'm having a problem.  After a while, my software RAID rebuild becomes
> extremely slow, and the filesystem on the RAID is essentially blocked. 
> I don't know what is causing this.  I guess it could be a bad drive, but
> how can I find out?

Probably not.  That pretty much always shows up in dmesg.

> I used atop to show the transfer speeds to each drive. Here's a
> screenshot:
> http://img402.imageshack.us/img402/6484/screenshotfrom201207251.png

Piles of small reads  scattered across multiple drives, and a
concentration of queued writes to /dev/sda.  What's on /dev/sda?
It's not a member of the raid, so it must be some other system task
involved.

[ The output of "lsdrv" [1] might be useful here, along with
"mdadm -D /dev/md0" and "mdadm -E /dev/[b-j]" ]

> "smartctl -a" for all the drives looks good to me, no pending failures,
> or errors logged.  dmesg doesn't report anything wrong with any of the
> drives.  It does, however, report lots of hung tasks, which are trying
> to access the RAID volume.  For example:
> 
> [51000.672064] INFO: task mythbackend:10677 blocked for more than 120
> seconds.
> [51000.672098] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this message.
> [51000.672143] mythbackend D 000e 0 10677  1 0x
> [51000.672146]  f38bea00 0086 c1095415 000e 0002 
>  c147aac0
> [51000.672152]  f38bebac c147aac0 eb2cff04 003d2f4b  c109cacb
> 01872f02 eb2cfe50
> [51000.672157]  c100f28b c13df480 01872f02 eb2cfe68 c10532b1 0069a8d0
> f79d6ac0 
> [51000.672162] Call Trace:
> [51000.672169]  [] ? find_get_pages_tag+0x2f/0xa2
> [51000.672173]  [] ? pagevec_lookup_tag+0x18/0x1e
> [51000.672176]  [] ? read_tsc+0xa/0x28
> [51000.672179]  [] ? timekeeping_get_ns+0x11/0x55
> [51000.672182]  [] ? ktime_get_ts+0x7a/0x82
> [51000.672186]  [] ? io_schedule+0x4a/0x5f
> [51000.672188]  [] ? sleep_on_page+0x5/0x8
> [51000.672191]  [] ? __wait_on_bit+0x2f/0x54
> [51000.672193]  [] ? lock_page+0x1d/0x1d
> [51000.672196]  [] ? wait_on_page_bit+0x57/0x5e
> [51000.672199]  [] ? autoremove_wake_function+0x29/0x29
> [51000.672201]  [] ? filemap_fdatawait_range+0x71/0x11e
> [51000.672205]  [] ? filemap_write_and_wait_range+0x3e/0x4c
> [51000.672232]  [] ? xfs_file_fsync+0x68/0x214 [xfs]
> [51000.672246]  [] ? xfs_file_splice_write+0x144/0x144 [xfs]
> [51000.672249]  [] ? vfs_fsync_range+0x27/0x2d
> [51000.672252]  [] ? vfs_fsync+0x11/0x15
> [51000.672254]  [] ? sys_fdatasync+0x20/0x2e

MythTV is trying to flush recorded video to disk, I presume.  Sync is
known to cause stalls--a great deal of work is on-going to improve
this.  How old is this kernel?

> [51000.672258]  [] ? sysenter_do_call+0x12/0x28
> [51000.672261]  [] ? quirk_usb_early_handoff+0x4a9/0x522
> 
> Here is some other possibly relevant info:
> 
> # cat /proc/mdstat
> Personalities : [raid6] [raid5] [raid4]
> md0 : active raid6 sdh1[0] sdd1[9] sde1[10] sdb1[6] sdi1[7] sdc1[4]
> sdf1[3] sdg1[8] sdj1[1]
>   6837311488 blocks super 1.2 level 6, 512k chunk, algorithm 2 [9/9]
> [U]
>   [==>..]  resync = 51.3% (501954432/976758784)
> finish=28755.6min speed=275K/sec

Is this resync a weekly check, or did something else trigger it?

> unused devices: 
> 
> # cat /proc/sys/dev/raid/speed_limit_min
> 1

MD is unable to reach its minimum rebuild rate while other system
activity is ongoing.  You might want to lower this number to see if that
gets you out of the stalls.

Or temporarily shut down mythtv.

> # cat /proc/sys/dev/raid/speed_limit_max
> 20
> 
> Thanks in advance!
> -- Kevin

HTH,

Phil

[1] http://github.com/pturmel/lsdrv

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] firmware: remove computone driver firmware and documentation

2012-07-25 Thread Rob Landley

On 07/25/2012 11:42 AM, Tim Gardner wrote:
> As far as I can tell, the only Computone support left in the
> kernel is in drivers/tty/serial/8250/8250_pci.c. CONFIG_COMPUTONE
> is no longer a valid option. Therefore, remove firmware, documentation,
> and the last vestiges of this driver.
>
> Cc: Rob Landley 

Acked-by same.

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 15/19] perf tools: use XSI-complaint version of strerror_r() instead of GNU-specific

2012-07-25 Thread Namhyung Kim

On Wed, 25 Jul 2012 14:41:30 -0300, Arnaldo Carvalho de Melo wrote:
> From: Kirill A. Shutemov 
>
> Perf uses GNU-specific version of strerror_r(). The GNU-specific strerror_r()
> returns a pointer to a string containing the error message.  This may be 
> either
> a pointer to a string that the function stores in buf, or a pointer to some
> (immutable) static string (in which case buf is unused).
>
> In glibc-2.16 GNU version was marked with attribute warn_unused_result.  It
> triggers few warnings in perf:
>
> util/target.c: In function ‘perf_target__strerror’:
> util/target.c:114:13: error: ignoring return value of ‘strerror_r’, declared 
> with attribute warn_unused_result [-Werror=unused-result]
> ui/browsers/hists.c: In function ‘hist_browser__dump’:
> ui/browsers/hists.c:981:13: error: ignoring return value of ‘strerror_r’, 
> declared with attribute warn_unused_result [-Werror=unused-result]
>
> They are bugs.
>
> Let's fix strerror_r() usage.
>
> Signed-off-by: Kirill A. Shutemov 
> Acked-by: Ulrich Drepper 
> Cc: Ingo Molnar 
> Cc: Paul Mackerras 
> Cc: Peter Zijlstra 
> Cc: Ulrich Drepper 
> Link: http://lkml.kernel.org/r/20120723210654.ga25...@shutemov.name
> [ committer note: s/assert/BUG_ON/g ]
> Signed-off-by: Arnaldo Carvalho de Melo 
> ---
>  tools/perf/ui/browsers/hists.c |4 ++--
>  tools/perf/util/target.c   |   11 ++-
>  2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
> index 482f051..413bd62 100644
> --- a/tools/perf/ui/browsers/hists.c
> +++ b/tools/perf/ui/browsers/hists.c
> @@ -978,8 +978,8 @@ static int hist_browser__dump(struct hist_browser 
> *browser)
>   fp = fopen(filename, "w");
>   if (fp == NULL) {
>   char bf[64];
> - strerror_r(errno, bf, sizeof(bf));
> - ui_helpline__fpush("Couldn't write to %s: %s", filename, bf);
> + const char *err = strerror_r(errno, bf, sizeof(bf));
> + ui_helpline__fpush("Couldn't write to %s: %s", filename, err);
>   return -1;
>   }
>  
> diff --git a/tools/perf/util/target.c b/tools/perf/util/target.c
> index 1064d5b..3f59c49 100644
> --- a/tools/perf/util/target.c
> +++ b/tools/perf/util/target.c
> @@ -110,8 +110,17 @@ int perf_target__strerror(struct perf_target *target, 
> int errnum,
>   int idx;
>   const char *msg;
>  
> + BUG_ON(buflen > 0);
> +

No! It should be

BUG_ON(buflen == 0);

Thanks,
Namhyung


>   if (errnum >= 0) {
> - strerror_r(errnum, buf, buflen);
> + const char *err = strerror_r(errnum, buf, buflen);
> +
> + if (err != buf) {
> + size_t len = strlen(err);
> + char *c = mempcpy(buf, err, min(buflen - 1, len));
> + *c = '\0';
> + }
> +
>   return 0;
>   }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)

2012-07-25 Thread Kevin Hilman

"Rafael J. Wysocki"  writes:

> On Wednesday, July 25, 2012, Arnd Bergmann wrote:
>> On Tuesday 24 July 2012, Rafael J. Wysocki wrote:
>> > On Tuesday, July 24, 2012, Arnd Bergmann wrote:
>> > > On Tuesday 24 July 2012, Rafael J. Wysocki wrote:
>> > > > On Tuesday, July 24, 2012, Arnd Bergmann wrote:
>> > > > > On Saturday 21 July 2012, Rafael J. Wysocki wrote:
>> > > 
>> > > > > 
>> > > > > Sorry for taking so long to reply. I am really not that familiar 
>> > > > > with the
>> > > > > power domain requirements, but I do have two comments on your 
>> > > > > approach:
>> > > > > 
>> > > > > * I think when we want to add a generic concept to the device tree 
>> > > > > such
>> > > > >   as power domains, we should always make it specified in a generic 
>> > > > > way.
>> > > > 
>> > > > Do we really want that?  I'm a bit skeptical, because apparently nobody
>> > > > cares, as the (zero) response to this patchset evidently indicates and
>> > > > since nobody cares, it's probably better not to add such "generic" 
>> > > > things
>> > > > just yet.

Sorry to jump in late, but it's been another busy dev cycle and I
haven't had the time to look at this series in detail.  But just so you
know that somebody cares, we're also interested in bindings that will be
useful on other SoCs for PM domains.

However, since OMAP powerdomain support pre-dates generic powerdomains ,
the "generic" power domains aren't quite generic enough get for OMAP,
and I haven't had the time to extend the generic code, we haven't yet
moved to generic powerdomains.

>> > > 
>> > > Well, the trouble with bindings is that they are much harder to change
>> > > later, at least in incompatible ways. 
>> > 
>> > Hmm, so I think you wanted to say that it might be burdensome to retain the
>> > code handling the old binding once we had started to use a new generic one.
>> > 
>> > I can agree with that, but that's quite similar to user space interfaces.
>> > Once we've exposed a user space interface of some kind and someone starts
>> > to use it, we'll have to maintain it going forward for the user in 
>> > question.
>> > However, there is a way to deprecate old user space interfaces and it has
>> > happened.
>> > 
>> > In this particular case the burden would be on Renesas, but I don't think 
>> > it
>> > would affect anybody else.
>> 
>> [adding devicetree-disc...@lists.ozlabs.org]
>> 
>> In case of user space interfaces, we also try very hard to avoid cases
>> where we know that we will have to change things later.
>
> [Cough, cough]  Yeah, sure.  Except that that's rather difficult to anticipate
> usually.
>
>> I don't think it's that hard to define a generic binding here, we just
>> need to make sure it's extensible.
>> 
>> One thing I would like to avoid is having to add to every single
>> device binding two separate optional properties defined like
>> 
>> diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt 
>> b/Documentation/devicetree/bindings/mmc/mmci.txt
>> index 2b584ca..353152e 100644
>> --- a/Documentation/devicetree/bindings/mmc/mmci.txt
>> +++ b/Documentation/devicetree/bindings/mmc/mmci.txt
>> @@ -13,3 +13,9 @@ Required properties:
>>  Optional properties:
>>  - mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable
>>  - mmc-cap-sd-highspeed   : indicates whether SD is high speed capable
>> +- pm-domain  : a phandle pointing to the power domain
>> +   controlling this device
>> +   See ../pm-domain/generic.txt
>> +- renesas,pm-domain  : a string with the name of the power domain
>> +   controlling this device.
>> +   See ../pm-domain/renesas.txt
>> 
>> Even if you say that the burden is only on Renesas to maintain all those
>> changes to every binding they use, there is also a burden on people trying
>> to understand the binding and deciding which one to use.
>
> What about (tongue in cheek) "renesas,hwmod", then?  That won't be confused
> with the generic "pm-domain" in any way, will it?  And since TI did that, we
> surely should be allowed to do it as well, no?
>
> Seriously, I'm not fundamentally opposed to using phandles for that in analogy
> with regulators, but I'm afraid we won't get it right from the start and it
> will turn out that we need to change the definition of the binding somehow
> and _that_ is going to be painful.  Pretty much like changing generic user
> space interfaces is (as opposed to changing interfaces of limited scope).
>
> However, if that route is taken, I'll expect you to require TI to change their
> hwmod binding in the analogous way.

FWIW, we're already working on making ti,hwmods disappear.  That was a
temporary step to allow us to easily migrate to DT using our existing,
in-tree description of device IP blocks (hwmods.)

That being said, I'm not sure why ti,hwmods is being used as an example
for powerdomains.  hwmods describe the integration of SoC IP blocks
(base addr, IRQ, DMA channel

Re: [PATCH] random: mix in architectural randomness in extract_buf()

2012-07-25 Thread H. Peter Anvin

On 07/25/2012 04:50 PM, Ben Hutchings wrote:
> On Wed, 2012-07-25 at 10:37 -0700, H. Peter Anvin wrote:
>> From: "H. Peter Anvin" 
>>
>> RDRAND is so much faster than the Linux pool system that we can
>> always just mix in architectural randomness.
> [...]
>> Signed-off-by: H. Peter Anvin 
>> Acked-by: Ingo Molnar 
>> Cc: DJ Johnston 
> [...]
> 
> This is not the correct way to submit patches for stable; see
> Documentation/stable_kernel_rules.txt
> 

The patch is intended to fix the security regression that would be
caused if Ted's random.git patches are accepted in -stable, which isn't
clear to me if they will be or not, so I added the Cc: to keep it from
getting lost.

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

[RESEND][PATCH] audit: replace defines with C stubs

This replaces the #defines used when CONFIG_AUDIT or CONFIG_AUDIT_SYSCALLS
are disabled so we get type checking during those builds.

Suggested-by: Andrew Morton 
Signed-off-by: Kees Cook 
---
 include/linux/audit.h |  173 -
 1 files changed, 127 insertions(+), 46 deletions(-)

diff --git a/include/linux/audit.h b/include/linux/audit.h
index 22f292a..fa55743 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -622,37 +622,92 @@ static inline void audit_mmap_fd(int fd, int flags)
 extern int audit_n_rules;
 extern int audit_signals;
 #else /* CONFIG_AUDITSYSCALL */
-#define audit_alloc(t) ({ 0; })
-#define audit_free(t) do { ; } while (0)
-#define audit_syscall_entry(ta,a,b,c,d,e) do { ; } while (0)
-#define audit_syscall_exit(r) do { ; } while (0)
-#define audit_dummy_context() 1
-#define audit_getname(n) do { ; } while (0)
-#define audit_putname(n) do { ; } while (0)
-#define __audit_inode(n,d) do { ; } while (0)
-#define __audit_inode_child(i,p) do { ; } while (0)
-#define audit_inode(n,d) do { (void)(d); } while (0)
-#define audit_inode_child(i,p) do { ; } while (0)
-#define audit_core_dumps(i) do { ; } while (0)
-#define audit_seccomp(i,s,c) do { ; } while (0)
-#define auditsc_get_stamp(c,t,s) (0)
+static inline int  audit_alloc(struct task_struct *task)
+{
+   return 0;
+}
+static inline void audit_free(struct task_struct *task)
+{ }
+static inline void audit_syscall_entry(int arch, int major, unsigned long a0,
+  unsigned long a1, unsigned long a2,
+  unsigned long a3)
+{ }
+static inline void audit_syscall_exit(void *pt_regs)
+{ }
+static inline int audit_dummy_context(void)
+{
+   return 1;
+}
+static inline void audit_getname(const char *name)
+{ }
+static inline void audit_putname(const char *name)
+{ }
+static inline void __audit_inode(const char *name, const struct dentry *dentry)
+{ }
+static inline void __audit_inode_child(const struct dentry *dentry,
+   const struct inode *parent)
+{ }
+static inline void audit_inode(const char *name, const struct dentry *dentry)
+{ }
+static inline void audit_inode_child(const struct dentry *dentry,
+const struct inode *parent)
+{ }
+static inline void audit_core_dumps(long signr)
+{ }
+static inline void __audit_seccomp(unsigned long syscall, long signr, int code)
+{ }
+static inline void audit_seccomp(unsigned long syscall, long signr, int code)
+{ }
+static inline int auditsc_get_stamp(struct audit_context *ctx,
+ struct timespec *t, unsigned int *serial)
+{
+   return 0;
+}
 #define audit_get_loginuid(t) (-1)
 #define audit_get_sessionid(t) (-1)
-#define audit_log_task_context(b) do { ; } while (0)
-#define audit_ipc_obj(i) ((void)0)
-#define audit_ipc_set_perm(q,u,g,m) ((void)0)
-#define audit_bprm(p) ({ 0; })
-#define audit_socketcall(n,a) ((void)0)
-#define audit_fd_pair(n,a) ((void)0)
-#define audit_sockaddr(len, addr) ({ 0; })
-#define audit_mq_open(o,m,a) ((void)0)
-#define audit_mq_sendrecv(d,l,p,t) ((void)0)
-#define audit_mq_notify(d,n) ((void)0)
-#define audit_mq_getsetattr(d,s) ((void)0)
-#define audit_log_bprm_fcaps(b, ncr, ocr) ({ 0; })
-#define audit_log_capset(pid, ncr, ocr) ((void)0)
-#define audit_mmap_fd(fd, flags) ((void)0)
-#define audit_ptrace(t) ((void)0)
+static inline void audit_log_task_context(struct audit_buffer *ab)
+{ }
+static inline void audit_ipc_obj(struct kern_ipc_perm *ipcp)
+{ }
+static inline void audit_ipc_set_perm(unsigned long qbytes, uid_t uid,
+   gid_t gid, umode_t mode)
+{ }
+static inline int audit_bprm(struct linux_binprm *bprm)
+{
+   return 0;
+}
+static inline void audit_socketcall(int nargs, unsigned long *args)
+{ }
+static inline void audit_fd_pair(int fd1, int fd2)
+{ }
+static inline int audit_sockaddr(int len, void *addr)
+{
+   return 0;
+}
+static inline void audit_mq_open(int oflag, umode_t mode, struct mq_attr *attr)
+{ }
+static inline void audit_mq_sendrecv(mqd_t mqdes, size_t msg_len,
+unsigned int msg_prio,
+const struct timespec *abs_timeout)
+{ }
+static inline void audit_mq_notify(mqd_t mqdes,
+  const struct sigevent *notification)
+{ }
+static inline void audit_mq_getsetattr(mqd_t mqdes, struct mq_attr *mqstat)
+{ }
+static inline int audit_log_bprm_fcaps(struct linux_binprm *bprm,
+  const struct cred *new,
+  const struct cred *old)
+{
+   return 0;
+}
+static inline void audit_log_capset(pid_t pid, const struct cred *new,
+  const struct cred *old)
+{ }
+static inline void audit_mmap_fd(int fd, int flags)
+{ }
+static inline void audit_ptrace(struct task_struct *t)
+{ }
 #define

[PATCH 1/2] fs: add link restrictions

This adds symlink and hardlink restrictions to the Linux VFS.

Symlinks:

A long-standing class of security issues is the symlink-based
time-of-check-time-of-use race, most commonly seen in world-writable
directories like /tmp. The common method of exploitation of this flaw
is to cross privilege boundaries when following a given symlink (i.e. a
root process follows a symlink belonging to another user). For a likely
incomplete list of hundreds of examples across the years, please see:
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp

The solution is to permit symlinks to only be followed when outside
a sticky world-writable directory, or when the uid of the symlink and
follower match, or when the directory owner matches the symlink's owner.

Some pointers to the history of earlier discussion that I could find:

1996 Aug, Zygo Blaxell
http://marc.info/?l=bugtraq=87602167419830=2
1996 Oct, Andrew Tridgell
http://lkml.indiana.edu/hypermail/linux/kernel/9610.2/0086.html
1997 Dec, Albert D Cahalan
http://lkml.org/lkml/1997/12/16/4
2005 Feb, Lorenzo Hernández García-Hierro
http://lkml.indiana.edu/hypermail/linux/kernel/0502.0/1896.html
2010 May, Kees Cook
https://lkml.org/lkml/2010/5/30/144

Past objections and rebuttals could be summarized as:

- Violates POSIX.
- POSIX didn't consider this situation and it's not useful to follow
a broken specification at the cost of security.
- Might break unknown applications that use this feature.
- Applications that break because of the change are easy to spot and
fix. Applications that are vulnerable to symlink ToCToU by not having
the change aren't. Additionally, no applications have yet been found
that rely on this behavior.
- Applications should just use mkstemp() or O_CREATE|O_EXCL.
- True, but applications are not perfect, and new software is written
all the time that makes these mistakes; blocking this flaw at the
kernel is a single solution to the entire class of vulnerability.
- This should live in the core VFS.
- This should live in an LSM. (https://lkml.org/lkml/2010/5/31/135)
- This should live in an LSM.
- This should live in the core VFS. (https://lkml.org/lkml/2010/8/2/188)

Hardlinks:

On systems that have user-writable directories on the same partition
as system files, a long-standing class of security issues is the
hardlink-based time-of-check-time-of-use race, most commonly seen in
world-writable directories like /tmp. The common method of exploitation
of this flaw is to cross privilege boundaries when following a given
hardlink (i.e. a root process follows a hardlink created by another
user). Additionally, an issue exists where users can "pin" a potentially
vulnerable setuid/setgid file so that an administrator will not actually
upgrade a system fully.

The solution is to permit hardlinks to only be created when the user is
already the existing file's owner, or if they already have read/write
access to the existing file.

Many Linux users are surprised when they learn they can link to files
they have no access to, so this change appears to follow the doctrine
of "least surprise". Additionally, this change does not violate POSIX,
which states "the implementation may require that the calling process
has permission to access the existing file"[1].

This change is known to break some implementations of the "at" daemon,
though the version used by Fedora and Ubuntu has been fixed[2] for
a while. Otherwise, the change has been undisruptive while in use in
Ubuntu for the last 1.5 years.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/linkat.html
[2]
http://anonscm.debian.org/gitweb/?p=collab-maint/at.git;a=commitdiff;h=f4114656c3a6c6f6070e315ffdf940a49eda3279

This patch is based on the patches in Openwall and grsecurity, along with
suggestions from Al Viro. I have added a sysctl to enable the protected
behavior, and documentation.

Signed-off-by: Kees Cook
Acked-by: Ingo Molnar
Signed-off-by: Andrew Morton

---
v2012.5:
- updates requested by Al Viro:
- remove CONFIGs
- pass nd for parent checking
- release path on error
v2012.4:
- split audit functions into a separate patch, suggested by Eric Paris.
v2012.3:
While this code has been living in -mm and linux-next for 2 releases,
this is a small rework based on feedback from Al Viro:
- Moved audit functions into audit.c.
- Added tests directly to path_openat/path_lookupat.
- Merged with hardlink restriction patch to make things more sensible.
v2012.2:
- Change sysctl mode to 0600, suggested by Ingo Molnar.
- Rework CONFIG logic to split code from default behavior.
- Renamed sysctl to have a "sysctl_" prefix, suggested by Andrew Morton.
- Use "true/false" instead of "1/0" for bool arg, thanks to Andrew Morton.
- Do not trust s_id to be safe to print, suggested by Andrew Morton.
v2012.1:
- Use GFP_KERNEL for audit log allocation, thanks to Ingo Molnar.
v2011.3:
- Add pid/comm back to logging.
v2011.2:
-

[PATCH 2/2] fs: add link restriction audit reporting

Adds audit messages for unexpected link restriction violations so that
system owners will have some sort of potentially actionable information
about misbehaving processes.

Signed-off-by: Kees Cook 
---
 fs/namei.c|2 ++
 include/linux/audit.h |4 
 kernel/audit.c|   21 +
 3 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index e5ad2db..cb3856f 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -691,6 +691,7 @@ static inline int may_follow_link(struct path *link, struct 
nameidata *nd)
return 0;
 
path_put(>path);
+   audit_log_link_denied("follow_link", link);
return -EACCES;
 }
 
@@ -759,6 +760,7 @@ static int may_linkat(struct path *link)
capable(CAP_FOWNER))
return 0;
 
+   audit_log_link_denied("linkat", link);
return -EPERM;
 }
 
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 22f292a..36abf2a 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -130,6 +130,7 @@
 #define AUDIT_LAST_KERN_ANOM_MSG1799
 #define AUDIT_ANOM_PROMISCUOUS  1700 /* Device changed promiscuous mode */
 #define AUDIT_ANOM_ABEND1701 /* Process ended abnormally */
+#define AUDIT_ANOM_LINK1702 /* Suspicious use of file 
links */
 #define AUDIT_INTEGRITY_DATA   1800 /* Data integrity verification */
 #define AUDIT_INTEGRITY_METADATA1801 /* Metadata integrity verification */
 #define AUDIT_INTEGRITY_STATUS 1802 /* Integrity enable status */
@@ -687,6 +688,8 @@ extern void audit_log_d_path(struct 
audit_buffer *ab,
 const struct path *path);
 extern voidaudit_log_key(struct audit_buffer *ab,
  char *key);
+extern voidaudit_log_link_denied(const char *operation,
+ struct path *link);
 extern voidaudit_log_lost(const char *message);
 #ifdef CONFIG_SECURITY
 extern voidaudit_log_secctx(struct audit_buffer *ab, u32 
secid);
@@ -716,6 +719,7 @@ extern int audit_enabled;
 #define audit_log_untrustedstring(a,s) do { ; } while (0)
 #define audit_log_d_path(b, p, d) do { ; } while (0)
 #define audit_log_key(b, k) do { ; } while (0)
+#define audit_log_link_denied(o, l) do { ; } while (0)
 #define audit_log_secctx(b,s) do { ; } while (0)
 #define audit_enabled 0
 #endif
diff --git a/kernel/audit.c b/kernel/audit.c
index 4a3f28d..ea3b7b6 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1456,6 +1456,27 @@ void audit_log_key(struct audit_buffer *ab, char *key)
 }
 
 /**
+ * audit_log_link_denied - report a link restriction denial
+ * @operation: specific link opreation
+ * @link: the path that triggered the restriction
+ */
+void audit_log_link_denied(const char *operation, struct path *link)
+{
+   struct audit_buffer *ab;
+
+   ab = audit_log_start(current->audit_context, GFP_KERNEL,
+AUDIT_ANOM_LINK);
+   audit_log_format(ab, "op=%s action=denied", operation);
+   audit_log_format(ab, " pid=%d comm=", current->pid);
+   audit_log_untrustedstring(ab, current->comm);
+   audit_log_d_path(ab, " path=", link);
+   audit_log_format(ab, " dev=");
+   audit_log_untrustedstring(ab, link->dentry->d_inode->i_sb->s_id);
+   audit_log_format(ab, " ino=%lu", link->dentry->d_inode->i_ino);
+   audit_log_end(ab);
+}
+
+/**
  * audit_log_end - end one audit record
  * @ab: the audit_buffer
  *
-- 
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/

[RESEND][PATCH v2012.5 0/2] fs: add link restrictions

Resending; originally posted 2012-07-02: https://lkml.org/lkml/2012/7/2/394

This cleans up the various issues that Al Viro pointed out[1], and 
rebases to Linus's current tree.

Thanks,

-Kees

[1] https://lkml.org/lkml/2012/6/30/42

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [media] davinci: vpfe: Add documentation

2012-07-25 Thread Laurent Pinchart

Hi Manjunath,

On Tuesday 17 July 2012 10:43:54 Hadli, Manjunath wrote:
> On Sun, Jul 15, 2012 at 18:16:25, Laurent Pinchart wrote:
> > On Wednesday 11 July 2012 21:09:26 Manjunath Hadli wrote:
> > > Add documentation on the Davinci VPFE driver. Document the subdevs,
> > > and private IOTCLs the driver implements
> > > 
> > > Signed-off-by: Manjunath Hadli 
> > > Signed-off-by: Lad, Prabhakar 

[snip]

> > > +Private IOCTLs
> > > +==
> > > +
> > > +The Davinci Video processing Front End (VPFE) driver supports standard
> > > V4L2 +IOCTLs and controls where possible and practical. Much of the
> > > functions provided
> > > +by the VPFE, however, does not fall under the standard IOCTLs.
> > > +
> > > +In general, there is a private ioctl for configuring each of the blocks
> > > +containing hardware-dependent functions.
> > > +
> > > +The following private IOCTLs are supported:
> > > +
> > > +1: IOCTL: PREV_S_PARAM/PREV_G_PARAM
> > > +Description:
> > > + Sets/Gets the parameters required by the previewer module
> > > +Parameter:
> > > + /**
> > > +  * struct prev_module_param- structure to configure preview modules
> > > +  * @version: Version of the preview module
> > 
> > Who is responsible for filling this field, the application or the driver ?
> 
> The application is responsible for filling this info. He would enumerate the
> capabilities first and  set them using S_PARAM/G_PARAM.

And what's the point of the application setting the version field ? How does 
the driver use it ?

> > > +  * @len: Length of the module config structure
> > > +  * @module_id: Module id
> > > +  * @param: pointer to module config parameter.
> > 
> > What is module_id for ? What does param point to ?
> 
> There are a lot of tiny modules in the previewer/resizer which are
> enumerated as individual modules. The param points to the parameter set
> that the module expects to be set.

Why don't you implement something similar to 
VPFE_CMD_S_CCDC_RAW_PARAMS/VPFE_CMD_G_CCDC_RAW_PARAMS instead ?

> > > +  */
> > > + struct prev_module_param {
> > > + char version[IMP_MAX_NAME_SIZE];
> > 
> > Is there a need to express the version as a string instead of an integer ?
> 
> It could be integer. It is generally a fixed point num, and easy to read it
> as a string than an integer. Can I keep it as a string?

Let's first decide whether a version field is needed at all :-)

> > > + unsigned short len;
> > > + unsigned short module_id;
> > > + void *param;
> > > + };
> > > +
> > > +2: IOCTL: PREV_S_CONFIG/PREV_G_CONFIG
> > > +Description:
> > > + Sets/Gets the configuration required by the previewer channel
> > > +Parameter:
> > > + /**
> > > +  * struct prev_channel_config - structure for configuring the
> > > previewer
> > > channel
> > > +  * @len: Length of the user configuration
> > > +  * @config: pointer to either single shot config or continuous
> > > +  */
> > > + struct prev_channel_config {
> > > + unsigned short len;
> > > + void *config;
> > > + };
> > 
> > What's the difference between parameters and configuration ? What does
> > config point to ?
> 
> Config is setting which is required for a subdev to function based on what
> it is set for (single shot/continuous.) common to all platforms. Parameters
> are the settings for individual small sub-ips which might be slightly
> different from one platform to another. Config points to
> prev_single_shot_config or  prev_continuous_config currently defined in
> linux/dm3656ipipe.h. I think we will move it to a common location.

Why don't you implement something similar to 
VPFE_CMD_S_CCDC_RAW_PARAMS/VPFE_CMD_G_CCDC_RAW_PARAMS here as well (same for 
the resizer configuration ioctls) ?

> > > +
> > > +3: IOCTL: PREV_ENUM_CAP
> > > +Description:
> > > + Queries the modules available in the image processor for preview the
> > > + input image.
> > > +Parameter:
> > > + /**
> > > +  * struct prev_cap - structure to enumerate capabilities of previewer
> > > +  * @index: application use this to iterate over the available modules
> > > +  * @version: version of the preview module
> > > +  * @module_id: module id
> > > +  * @control: control operation allowed in continuous mode? 1 -
> > > allowed, 0
> > > - not allowed
> > > +  * @path: path on which the module is sitting
> > > +  * @module_name: module name
> > > +  */
> > > + struct prev_cap {
> > > + unsigned short index;
> > > + char version[IMP_MAX_NAME_SIZE];
> > > + unsigned short module_id;
> > > + char control;
> > > + enum imp_data_paths path;
> > > + char module_name[IMP_MAX_NAME_SIZE];
> > > + };
> > 
> > Enumerating internal modules is exactly what the MC API was designed for.
> > Why do you reimplement that using private ioctls ?
> 
> The number of these sub-Ips are quite a few in DM365 and Dm355, having a lot
> of them In a way that may be bewildering to the end-user to be able to
> connect them quickly and properly. But

Linux 3.2.24

I'm announcing the release of the 3.2.24 kernel.

All users of the 3.2 kernel series should upgrade.

The updated 3.2.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.2.y
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git

Ben.



 Makefile  |2 +-
 arch/arm/plat-samsung/adc.c   |8 +-
 arch/mips/include/asm/thread_info.h   |4 +-
 arch/mips/kernel/vmlinux.lds.S|3 +-
 arch/powerpc/include/asm/cputime.h|6 +-
 arch/powerpc/kernel/time.c|   10 +-
 arch/x86/kernel/acpi/boot.c   |   27 +-
 arch/x86/kernel/reboot.c  |8 +
 block/scsi_ioctl.c|5 +-
 drivers/acpi/processor_core.c |6 +-
 drivers/acpi/sleep.c  |4 +-
 drivers/acpi/sysfs.c  |4 +-
 drivers/gpio/gpio-wm8994.c|5 +-
 drivers/gpu/drm/i915/intel_display.c  |4 +-
 drivers/hid/hid-apple.c   |6 +
 drivers/hid/hid-core.c|7 +
 drivers/hid/hid-ids.h |6 +
 drivers/hwmon/it87.c  |2 +-
 drivers/hwspinlock/hwspinlock_core.c  |4 +-
 drivers/input/joystick/xpad.c |6 +-
 drivers/input/mouse/bcm5974.c |   20 ++
 drivers/iommu/amd_iommu.c |7 +
 drivers/iommu/amd_iommu_init.c|3 +-
 drivers/md/dm-raid1.c |3 +-
 drivers/md/dm-region-hash.c   |5 +-
 drivers/md/md.c   |   36 ++-
 drivers/md/raid1.c|   13 +-
 drivers/md/raid5.c|4 +-
 drivers/media/dvb/dvb-core/dvbdev.c   |1 +
 drivers/mtd/nand/nandsim.c|   12 +-
 drivers/net/bonding/bond_debugfs.c|2 +-
 drivers/net/bonding/bond_main.c   |9 +-
 drivers/net/ethernet/atheros/atl1c/atl1c_main.c   |1 -
 drivers/net/ethernet/broadcom/bnx2x/bnx2x.h   |   15 --
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c   |   36 ++-
 drivers/net/ethernet/broadcom/tg3.c   |3 +-
 drivers/net/ethernet/intel/e1000e/82571.c |3 +
 drivers/net/ethernet/realtek/r8169.c  |3 +
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |3 +
 drivers/net/macvtap.c |   57 +++--
 drivers/net/usb/ipheth.c  |5 +
 drivers/net/wireless/brcm80211/brcmsmac/main.c|3 +-
 drivers/net/wireless/ipw2x00/ipw.h|   23 ++
 drivers/net/wireless/ipw2x00/ipw2100.c|4 +
 drivers/net/wireless/ipw2x00/ipw2200.c|4 +
 drivers/net/wireless/iwlegacy/iwl-4965-sta.c  |4 +-
 drivers/net/wireless/iwlegacy/iwl-core.c  |   14 +-
 drivers/net/wireless/rt2x00/rt2x00usb.c   |2 +-
 drivers/net/wireless/rtl818x/rtl8187/leds.c   |2 +-
 drivers/pci/pci-driver.c  |   12 +
 drivers/pci/pci.c |5 -
 drivers/pci/quirks.c  |   26 --
 drivers/platform/x86/intel_ips.c  |   22 ++
 drivers/platform/x86/samsung-laptop.c |  225 +
 drivers/rtc/rtc-mxc.c |5 +-
 drivers/scsi/aic94xx/aic94xx_task.c   |2 +-
 drivers/scsi/libsas/sas_ata.c |   12 +-
 drivers/target/target_core_cdb.c  |2 +-
 drivers/target/target_core_pr.c   |7 +-
 drivers/target/tcm_fc/tfc_cmd.c   |2 +
 drivers/usb/class/cdc-wdm.c   |2 +
 drivers/usb/core/hub.c|   18 +-
 drivers/usb/host/xhci-hub.c   |   44 +++-
 drivers/usb/host/xhci.h   |6 +-
 drivers/usb/serial/option.c   |   26 ++
 drivers/vhost/vhost.c |2 +
 fs/buffer.c   |   22 +-
 fs/cifs/connect.c |   18 ++
 fs/cifs/readdir.c |7 +-
 fs/ecryptfs/kthread.c |2 +-
 fs/ecryptfs/miscdev.c |   48 ++--
 fs/eventpoll.c|4 +-
 fs/exofs/ore.c|8 +-
 fs/exofs/ore_raid.c   |   67 ++---
 fs/ext4/super.c   |2 +-
 fs/fifo.c

Re: PM: Summary of changes for v3.6

2012-07-25 Thread Kevin Hilman

Len Brown  writes:

>> The disappeared from Len's tree for a little while after the 3.5 merge
>> window, which is why they started appearing other places.  Now that
>> they have returned to Len's tree, hopefully to stay, they should be
>> considered the official version.
>
> Yes, they are staged for 3.6 in my tree.
>
> The intent was to push them for 3.5, but some unrelated patches
> exploded and stopped that push.  I then had to re-merge my tree
> to push only the bug-fixes to 3.5, which is why the feature
> patches went away for a bit.

Great, thanks for clarifying.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dynamic_debug: Restore dev_dbg/netdev_dbg functionality, reduce stack use

2012-07-25 Thread David Miller

From: Joe Perches 
Date: Wed, 25 Jul 2012 17:10:00 -0700

> commit c4e00daaa9 ("driver-core: extend dev_printk() to pass structured data")
> changed __dev_printk and broke dynamic-debug's ability to control the
> dynamic prefix of dev_dbg(dev,..).
> 
> dynamic_emit_prefix() adds "[tid] module:func:line:" to the output and
> those additions got lost.
> 
> In addition, the current dynamic debug code uses up to 3 recursion
> levels via %pV.  This can consume quite a bit of stack.  Directly
> call printk_emit to reduce the recursion by one depth.
> 
> These changes include:
> 
> o Remove KERN_DEBUG from dynamic_emit_prefix
> o Create and use function create_syslog_header to format the syslog
>   header for printk_emit uses.
> o Call create_syslog_header and neaten __dev_printk
> o Call create_syslog_header and printk_emit from dynamic_dev_dbg
> o Call create_syslog_header and printk_emit from dynamic_netdev_dbg
> o Make __dev_printk and __netdev_printk static not global
> o Remove include header declarations of __dev_printk and __netdev_printk
> o Remove now unused EXPORT_SYMBOL()s of __dev_printk and __netdev_printk
> o Whitespace neatening
> 
> Signed-off-by: Joe Perches 

For networking parts:

Acked-by: David S. Miller 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [media] davinci: vpfe: Add documentation

2012-07-25 Thread Laurent Pinchart

Hi Manjunath,

Please ignore the previous reply, I've hit the sent button too soon by 
mistake.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [media] davinci: vpfe: Add documentation

2012-07-25 Thread Laurent Pinchart

Hi Manjunath,

On Tuesday 17 July 2012 10:43:54 Hadli, Manjunath wrote:
> On Sun, Jul 15, 2012 at 18:16:25, Laurent Pinchart wrote:
> > On Wednesday 11 July 2012 21:09:26 Manjunath Hadli wrote:
> > > Add documentation on the Davinci VPFE driver. Document the subdevs,
> > > and private IOTCLs the driver implements
> > > 
> > > Signed-off-by: Manjunath Hadli 
> > > Signed-off-by: Lad, Prabhakar 

[snip]

> > > + DAVINCI CCDC
> > > + DAVINCI PREVIEWER
> > > + DAVINCI RESIZER
> > 
> > the DM36x VPFE documentation doesn't split the hardware in CCDC, PREVIEWER
> > and RESIZER modules, but in ISIF, IPIPEIF and IPIPE. Why don't you use
> > those names ? It looks like you're introducing an abstraction layer on
> > top of the existing driver. Why is that needed, why don't you just port
> > the driver to the MC API instead ?
> 
> Please see below my comment for "enumerating internal modules".
> 
> > > + DAVINCI AEW
> > > + DAVINCI AF
> > > +
> > > +Each possible link in the VPFE is modeled by a link in the Media
> > > controller +interface. For an example program see [1].
> > > +
> > > +
> > > +Private IOCTLs
> > > +==
> > > +
> > > +The Davinci Video processing Front End (VPFE) driver supports standard
> > > V4L2 +IOCTLs and controls where possible and practical. Much of the
> > > functions provided
> > > +by the VPFE, however, does not fall under the standard IOCTLs.
> > > +
> > > +In general, there is a private ioctl for configuring each of the blocks
> > > +containing hardware-dependent functions.
> > > +
> > > +The following private IOCTLs are supported:
> > > +
> > > +1: IOCTL: PREV_S_PARAM/PREV_G_PARAM
> > > +Description:
> > > + Sets/Gets the parameters required by the previewer module
> > > +Parameter:
> > > + /**
> > > +  * struct prev_module_param- structure to configure preview modules
> > > +  * @version: Version of the preview module
> > 
> > Who is responsible for filling this field, the application or the driver ?
> 
> The application is responsible for filling this info. He would enumerate the
> capabilities first and  set them using S_PARAM/G_PARAM.
> 
> > > +  * @len: Length of the module config structure
> > > +  * @module_id: Module id
> > > +  * @param: pointer to module config parameter.
> > 
> > What is module_id for ? What does param point to ?
> 
> There are a lot of tiny modules in the previewer/resizer which are
> enumerated as individual modules. The param points to the parameter set
> that the module expects to be set.
> 
> > > +  */
> > > + struct prev_module_param {
> > > + char version[IMP_MAX_NAME_SIZE];
> > 
> > Is there a need to express the version as a string instead of an integer ?
> 
> It could be integer. It is generally a fixed point num, and easy to read it
> as a string than an integer. Can I keep it as a string?
> 
> > > + unsigned short len;
> > > + unsigned short module_id;
> > > + void *param;
> > > + };
> > > +
> > > +2: IOCTL: PREV_S_CONFIG/PREV_G_CONFIG
> > > +Description:
> > > + Sets/Gets the configuration required by the previewer channel
> > > +Parameter:
> > > + /**
> > > +  * struct prev_channel_config - structure for configuring the
> > > previewer
> > > channel
> > > +  * @len: Length of the user configuration
> > > +  * @config: pointer to either single shot config or continuous
> > > +  */
> > > + struct prev_channel_config {
> > > + unsigned short len;
> > > + void *config;
> > > + };
> > 
> > What's the difference between parameters and configuration ? What does
> > config point to ?
> 
> Config is setting which is required for a subdev to function based on what
> it is set for (single shot/continuous.) common to all platforms. Parameters
> are the settings for individual small sub-ips which might be slightly
> different from one platform to another. Config points to
> prev_single_shot_config or  prev_continuous_config currently defined in
> linux/dm3656ipipe.h. I think we will move it to a common location.
> > > +
> > > +3: IOCTL: PREV_ENUM_CAP
> > > +Description:
> > > + Queries the modules available in the image processor for preview the
> > > + input image.
> > > +Parameter:
> > > + /**
> > > +  * struct prev_cap - structure to enumerate capabilities of previewer
> > > +  * @index: application use this to iterate over the available modules
> > > +  * @version: version of the preview module
> > > +  * @module_id: module id
> > > +  * @control: control operation allowed in continuous mode? 1 -
> > > allowed, 0
> > > - not allowed
> > > +  * @path: path on which the module is sitting
> > > +  * @module_name: module name
> > > +  */
> > > + struct prev_cap {
> > > + unsigned short index;
> > > + char version[IMP_MAX_NAME_SIZE];
> > > + unsigned short module_id;
> > > + char control;
> > > + enum imp_data_paths path;
> > > + char module_name[IMP_MAX_NAME_SIZE];
> > > + };
> > 
> > Enumerating internal modules is exactly what the MC API was designed

Re: [PATCH] extcon: arizona: Implement button detection support

2012-07-25 Thread Chanwoo Choi

On 07/25/2012 08:11 PM, Mark Brown wrote:

>> Why do you should report released event to all of buttons? I think that
>> you should only
>> report released event to previous pressed button. If user press two
>> button on the headset
>> at the same time and then user release only one button with pressed
>> another button, extcon-arizona driver have to report released event to
>> previous pressed button except for still pressed another button.
> 
> The input API already supresses duplicate reports, they won't be
> propagated to userspace, so there's no point in duplicating the work
> to remember what buttons are pressed in individual drivers.  Userspace
> will only see events reported that refect changes in state.

The extcon-arizona include six buttons(BTN_0, BTN_1, BTN_2, BTN_3,
BTN_4, BTN_5). Currently, extcon-arizona driver will report released
event to all buttons (BTN_0, BTN_1, BTN_2, BTN_3, BTN_4, BTN_5)
when released event irrespective of the type of buttons is happened.

If user press BTN_0 and BTN_1 at the same time and then user only
released BTN_0 but BTN_1 is still pressed, is it right that report
released event to all of buttons? I think that different event between
BTN_0 and BTN_1.

Thank you,
Chanwoo Choi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dynamic_debug: Restore dev_dbg/netdev_dbg functionality, reduce stack use

2012-07-25 Thread Joe Perches

commit c4e00daaa9 ("driver-core: extend dev_printk() to pass structured data")
changed __dev_printk and broke dynamic-debug's ability to control the
dynamic prefix of dev_dbg(dev,..).

dynamic_emit_prefix() adds "[tid] module:func:line:" to the output and
those additions got lost.

In addition, the current dynamic debug code uses up to 3 recursion
levels via %pV.  This can consume quite a bit of stack.  Directly
call printk_emit to reduce the recursion by one depth.

These changes include:

o Remove KERN_DEBUG from dynamic_emit_prefix
o Create and use function create_syslog_header to format the syslog
  header for printk_emit uses.
o Call create_syslog_header and neaten __dev_printk
o Call create_syslog_header and printk_emit from dynamic_dev_dbg
o Call create_syslog_header and printk_emit from dynamic_netdev_dbg
o Make __dev_printk and __netdev_printk static not global
o Remove include header declarations of __dev_printk and __netdev_printk
o Remove now unused EXPORT_SYMBOL()s of __dev_printk and __netdev_printk
o Whitespace neatening

Signed-off-by: Joe Perches 
---
 drivers/base/core.c   |   57 -
 include/linux/device.h|   11 +++-
 include/linux/netdevice.h |3 --
 lib/dynamic_debug.c   |   61 -
 net/core/dev.c|5 ++-
 5 files changed, 89 insertions(+), 48 deletions(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 346be8b..320a32c 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1844,25 +1844,19 @@ void device_shutdown(void)
  */
 
 #ifdef CONFIG_PRINTK
-int __dev_printk(const char *level, const struct device *dev,
-struct va_format *vaf)
+int create_syslog_header(const struct device *dev, char *hdr, size_t hdrlen)
 {
-   char dict[128];
-   size_t dictlen = 0;
const char *subsys;
-
-   if (!dev)
-   return printk("%s(NULL device *): %pV", level, vaf);
+   size_t pos = 0;
 
if (dev->class)
subsys = dev->class->name;
else if (dev->bus)
subsys = dev->bus->name;
else
-   goto skip;
+   return 0;
 
-   dictlen += snprintf(dict + dictlen, sizeof(dict) - dictlen,
-   "SUBSYSTEM=%s", subsys);
+   pos += snprintf(hdr + pos, hdrlen - pos, "SUBSYSTEM=%s", subsys);
 
/*
 * Add device identifier DEVICE=:
@@ -1878,28 +1872,41 @@ int __dev_printk(const char *level, const struct device 
*dev,
c = 'b';
else
c = 'c';
-   dictlen++;
-   dictlen += snprintf(dict + dictlen, sizeof(dict) - dictlen,
-  "DEVICE=%c%u:%u",
-  c, MAJOR(dev->devt), MINOR(dev->devt));
+   pos++;
+   pos += snprintf(hdr + pos, hdrlen - pos,
+   "DEVICE=%c%u:%u",
+   c, MAJOR(dev->devt), MINOR(dev->devt));
} else if (strcmp(subsys, "net") == 0) {
struct net_device *net = to_net_dev(dev);
 
-   dictlen++;
-   dictlen += snprintf(dict + dictlen, sizeof(dict) - dictlen,
-   "DEVICE=n%u", net->ifindex);
+   pos++;
+   pos += snprintf(hdr + pos, hdrlen - pos,
+   "DEVICE=n%u", net->ifindex);
} else {
-   dictlen++;
-   dictlen += snprintf(dict + dictlen, sizeof(dict) - dictlen,
-   "DEVICE=+%s:%s", subsys, dev_name(dev));
+   pos++;
+   pos += snprintf(hdr + pos, hdrlen - pos,
+   "DEVICE=+%s:%s", subsys, dev_name(dev));
}
-skip:
-   return printk_emit(0, level[1] - '0',
-  dictlen ? dict : NULL, dictlen,
+
+   return pos;
+}
+EXPORT_SYMBOL(create_syslog_header);
+
+static int __dev_printk(const char *level, const struct device *dev,
+   struct va_format *vaf)
+{
+   char hdr[128];
+   size_t hdrlen;
+
+   if (!dev)
+   return printk("%s(NULL device *): %pV", level, vaf);
+
+   hdrlen = create_syslog_header(dev, hdr, sizeof(hdr));
+
+   return printk_emit(0, level[1] - '0', hdrlen ? hdr : NULL, hdrlen,
   "%s %s: %pV",
   dev_driver_string(dev), dev_name(dev), vaf);
 }
-EXPORT_SYMBOL(__dev_printk);
 
 int dev_printk(const char *level, const struct device *dev,
   const char *fmt, ...)
@@ -1914,6 +1921,7 @@ int dev_printk(const char *level, const struct device 
*dev,
vaf.va = 
 
r = __dev_printk(level, dev, );
+
va_end(args);
 
return r;
@@ -1933,6 +1941,7 @@ int func(const struct device *dev, const char *fmt, ...)  
\
vaf.va =  \

Re: linux-next: build failure after merge of the tty tree

2012-07-25 Thread Alan Cox

On Thu, 26 Jul 2012 08:51:27 +1000
Stephen Rothwell  wrote:

> Hi Greg, Alan,
> 
> [Sorry, Alan, I forgot to cc you the first time around.]
> 
> On Fri, 20 Jul 2012 13:33:49 +1000 Stephen Rothwell
>  wrote:
> >
> > After merging the tty tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > drivers/staging/serqt_usb2/serqt_usb2.c: In function
> > 'qt_set_termios': drivers/staging/serqt_usb2/serqt_usb2.c:1198:29:
> > error: incompatible types when initializing type 'struct ktermios
> > *' using type 'struct ktermios'
> > drivers/staging/serqt_usb2/serqt_usb2.c:1304:14: error: invalid
> > type argument of '->' (have 'struct ktermios')
> > 

I sent you a fix for that one (I've not done the ipoctal one yet)

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

Re: linux-next: build failure after merge of the final tree (tty tree related)

2012-07-25 Thread Alan Cox

> > if (serial->type->set_termios) {
> > -   tty->termios->c_cflag = cflag;
> > -   tty_termios_encode_baud_rate(tty->termios,
> > baud, baud);
> > +   tty->termios.c_cflag = cflag;
> > +
> > tty_termios_encode_baud_rate(>termios, baud, baud);
> > memset(, 0, sizeof(struct ktermios));
> > serial->type->set_termios(tty, port, ); 
> 
> Alan, any objection to this?

The fix looks correct to me.

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

[GIT PATCH] USB merge for 3.6-rc1

2012-07-25 Thread Greg KH

The following changes since commit 84a1caf1453c3d44050bd22db958af4a7f99315c:

  Linux 3.5-rc7 (2012-07-14 15:40:28 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.6-rc1

for you to fetch changes up to e387ef5c47ddeaeaa3cbdc54424cdb7a28dae2c0:

  usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams (2012-07-19 
15:46:32 -0700)


USB patches for 3.6-rc1

Here's the big USB patch set for the 3.6-rc1 merge window.

Lots of little changes in here, primarily for gadget controllers and drivers.
There's some scsi changes that I think also went in through the scsi tree, but
they merge just fine.  All of these patches have been in the linux-next tree
for a while now.

Signed-off-by: Greg Kroah-Hartman 


Alan Stern (28):
  USB: EHCI: define extension registers like normal ones
  EHCI: centralize controller suspend/resume
  EHCI: centralize controller initialization
  USB: EHCI: initialize data before resetting hardware
  USB: EHCI: remove unneeded suspend/resume code
  USB: EHCI: don't refcount QHs
  USB: EHCI: add symbolic constants for QHs
  USB: EHCI: rename "reclaim"
  USB: EHCI: add pointer to end of async-unlink list
  USB: EHCI: add new root-hub state: STOPPING
  USB: EHCI: introduce high-res timer
  USB: EHCI: use hrtimer for the periodic schedule
  USB: EHCI: return void instead of 0
  USB: EHCI: remove PS3 status polling
  USB: EHCI: use hrtimer for async schedule
  USB: EHCI: use hrtimer for interrupt QH unlink
  USB: EHCI: use hrtimer for controller death
  USB: EHCI: use hrtimer for (s)iTD deallocation
  USB: EHCI: don't refcount iso_stream structures
  USB: EHCI: use hrtimer for the IAA watchdog
  USB: EHCI: unlink multiple async QHs together
  USB: EHCI: use hrtimer for unlinking empty async QHs
  USB: EHCI: don't lose events during a scan
  USB: EHCI: always scan each interrupt QH
  USB: EHCI: use hrtimer for the I/O watchdog
  USB: EHCI: simplify isochronous scanning
  USB: EHCI: fix up locking
  USB: EHCI: resolve some unlikely races

Alexander Shishkin (1):
  usb: chipidea: remove unneeded NULL check

Alexandre Pereira da Silva (6):
  USB: ohci-nxp: add usbd and otg clock initialization
  usb: gadget: lpc32xx_udc: move clock init to clock framework
  usb: gadget: lpc32xx_udc: Propagate devicetree to gadget drivers
  usb: gadget: s3c-hsotg: Propagate devicetree to gadget drivers
  usb: gadget: fsl_udc: Propagate devicetree to gadget drivers
  usb: gadget: at91_udc: Propagate devicetree to gadget drivers

Ben Minerds (5):
  USB: serial: keyspan: Fix spacing around conditional.
  USB: serial: keyspan: Fixed space around equals.
  USB: serial: keyspan: Fixed space near open parenthesis.
  USB: serial: keyspan: Removed trailing whitespace.
  USB: serial: keyspan: Removed unrequired parentheses.

Bhupesh Sharma (3):
  usb: gadget: uvc: Fix string descriptor STALL issue when multiple uvc 
functions are added to a configuration
  usb: gadget: uvc: Use macro for interrupt endpoint status size instead of 
using a MAGIC number
  usb: gadget: uvc: Add super-speed support to UVC webcam gadget

Bill Pemberton (2):
  USB: serial: Remove unused s_priv variable
  USB: serial: Remove unused serial_priv variable

Bjørn Mork (9):
  USB: allow match on bInterfaceNumber
  USB: cdc-wdm: QMI devices are now handled by qmi_wwan
  USB: qcserial: consolidate usb_set_interface calls
  USB: qcserial: centralize probe exit path
  USB: qcserial: make probe more flexible
  USB: qcserial: support generic Qualcomm serial ports
  USB: qcserial: adding Sierra Wireless devices
  USB: sierra: QMI mode MC7710 moved to qcserial
  USB: option: add ZTE MF821D

Daniel Mack (1):
  usb: gadget: hidg: register OUT INT endpoint for SET_REPORT

Du, ChangbinX (1):
  testusb: expose looping forever option "l" to user

Fabio Estevam (4):
  usb: fsl_mxc_udc.c : Use clk_prepare_enable/clk_disable_unprepare
  usb: imx_udc.c: Use clk_prepare_enable/clk_disable_unprepare
  usb: imx21-hcd.c: Use clk_prepare_enable/clk_disable_unprepare
  usb: gadget: fsl_mxc_udc: do not depend on grouped clocks

Felipe Balbi (30):
  usb: dwc3: fix a WARN and a comment
  usb: dwc3: handle pending unaligned Control OUT data phase correctly
  usb: dwc3: ep0: switch over to IS_ALIGNED
  usb: dwc3: ep0: align on function signature
  usb: dwc3: ep0: fix a typo in comment
  usb: dwc3: gadget: remove trailing semicolon
  usb: dwc3: gadget: prevent DCTL register corruption
  usb: dwc3: gadget: disable U1/U2 on disconnect
  usb: dwc3: ep0: simplify error handling on dwc3_ep0_inspect_setup
  usb:

Re: [PATCH] random: mix in architectural randomness in extract_buf()

On Wed, 2012-07-25 at 10:37 -0700, H. Peter Anvin wrote:
> From: "H. Peter Anvin" 
> 
> RDRAND is so much faster than the Linux pool system that we can
> always just mix in architectural randomness.
[...]
> Signed-off-by: H. Peter Anvin 
> Acked-by: Ingo Molnar 
> Cc: DJ Johnston 
[...]

This is not the correct way to submit patches for stable; see
Documentation/stable_kernel_rules.txt

Ben.
(needs to get one of those form letters like Greg)

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


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

Re: [PATCH] Rewrite Documentation/SubmittingPatches.

2012-07-25 Thread Junio C Hamano

Stefan Beller  writes:

> +5) "git format-patch HEAD~n"
> +
> +Use "git format-patch HEAD~n" to extract the last n patches from your
> +git repository. They will be be saved in textfiles named
> +
> +0001-Introduce-new-Feature.patch
> +0002-Improve-Documentation.patch

Two comments and a half-nit.


 - "--subject-prefix='PATCH v4'" is handy to know (since the
   workflow already assumes reviews and resubmissions in #11).

 - "--cover-letter" is handy to know when sending a multi-patch
   series.

 - "git format-patch -20" or "git format-patch origin" might be more
   familiar looking form than "git format-patch HEAD~20".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/4] ACPI: hotplug messages improvement

On Wed, 2012-07-25 at 16:31 -0700, Joe Perches wrote:
> On Wed, 2012-07-25 at 17:12 -0600, Toshi Kani wrote:
> > This patchset improves logging messages for ACPI CPU, Memory, and
> > Container hotplug notify handlers.  The patchset introduces a set of
> > new macro interfaces, acpi_pr_(), and updates the notify
> > handlers to use them.  acpi_pr_() appends "ACPI" prefix and
> > ACPI object path to the messages, and its usage model is similar to
> > dev_().  This improves diagnostics in hotplug operations
> > since it identifies an object that caused an issue in a log file.
> > 
> > v3:
> >  - Changed acpi_pr_debug() to NOP when !DEBUG and !DYNAMIC_DEBUG.
> >DYNAMIC_DEBUG will be supported later.
> >  - Added const to a path variable in acpi_printk().
> >  - Added more descriptions to the change log of patch 1/4.
> 
> Thanks Toshi.
> 
> This seems sensible to me.  I've no more comments either.

Thanks Joe for the valuable suggestions!
-Toshi



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/12] block: Generalized bio pool freeing

2012-07-25 Thread Kent Overstreet

On Wed, Jul 25, 2012 at 02:06:23PM +0300, Boaz Harrosh wrote:
> On 07/24/2012 11:11 PM, Kent Overstreet wrote:
> 
> > With the old code, when you allocate a bio from a bio pool you have to
> > implement your own destructor that knows how to find the bio pool the
> > bio was originally allocated from.
> > 
> > This adds a new field to struct bio (bi_pool) and changes
> > bio_alloc_bioset() to use it. This makes various bio destructors
> > unnecessary, so they're then deleted.
> > 
> > Signed-off-by: Kent Overstreet 
> 
> 
> 
> > diff --git a/drivers/target/target_core_iblock.c 
> > b/drivers/target/target_core_iblock.c
> > index fd47950..be65582 100644
> > --- a/drivers/target/target_core_iblock.c
> > +++ b/drivers/target/target_core_iblock.c
> > @@ -447,14 +447,6 @@ static void iblock_complete_cmd(struct se_cmd *cmd)
> > kfree(ibr);
> >  }
> >  
> > -static void iblock_bio_destructor(struct bio *bio)
> > -{
> > -   struct se_cmd *cmd = bio->bi_private;
> > -   struct iblock_dev *ib_dev = cmd->se_dev->dev_ptr;
> > -
> > -   bio_free(bio, ib_dev->ibd_bio_set);
> > -}
> > -
> >  static struct bio *
> >  iblock_get_bio(struct se_cmd *cmd, sector_t lba, u32 sg_num)
> >  {
> > @@ -475,8 +467,15 @@ iblock_get_bio(struct se_cmd *cmd, sector_t lba, u32 
> > sg_num)
> > }
> >  
> > bio->bi_bdev = ib_dev->ibd_bd;
> > +<<< HEAD
> > bio->bi_private = cmd;
> > bio->bi_destructor = iblock_bio_destructor;
> > +||| merged common ancestors
> > +   bio->bi_private = task;
> > +   bio->bi_destructor = iblock_bio_destructor;
> > +===
> > +   bio->bi_private = task;
> > +>>> block: Generalized bio pool freeing
> > bio->bi_end_io = _bio_done;
> > bio->bi_sector = lba;
> > return bio;
> 
> 
> You left out a rebase merge conflict. Did you allmodconfig compile
> these patches?

Argh, clearly not. And I even fixed that rebase merge conflict at one
point, that's distressing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] remove __GFP_NO_KSWAPD fixes

2012-07-25 Thread Minchan Kim

On Wed, Jul 25, 2012 at 02:51:19PM -0400, Rik van Riel wrote:
> Turns out I missed two spots where __GFP_NO_KSWAPD is used.
> 
> The removal from the trace code is obvious, since the flag
> got removed there is no need to print it.
> 
> For mtdcore.c, now that memory compaction has been fixed,
> we should no longer see large swap storms from an attempt
> to allocate a large buffer, removing the need to specify
> __GFP_NO_KSWAPD.
> 
> Signed-off-by: Rik van Riel 
Reviewed-by: Minchan Kim 

You should have tidied up comment of the function.
I hope Andrew can do it if he see this review.

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index fcfce24..6ff1308 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -1065,8 +1065,7 @@ EXPORT_SYMBOL_GPL(mtd_writev);
  * until the request succeeds or until the allocation size falls below
  * the system page size. This attempts to make sure it does not adversely
  * impact system performance, so when allocating more than one page, we
- * ask the memory allocator to avoid re-trying, swapping, writing back
- * or performing I/O.
+ * ask the memory allocator to avoid re-trying.
  *
  * Note, this function also makes sure that the allocated buffer is aligned to
  * the MTD device's min. I/O unit, i.e. the "mtd->writesize" value.

Thanks.

-- 
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 v3 0/4] ACPI: hotplug messages improvement

2012-07-25 Thread Joe Perches

On Wed, 2012-07-25 at 17:12 -0600, Toshi Kani wrote:
> This patchset improves logging messages for ACPI CPU, Memory, and
> Container hotplug notify handlers.  The patchset introduces a set of
> new macro interfaces, acpi_pr_(), and updates the notify
> handlers to use them.  acpi_pr_() appends "ACPI" prefix and
> ACPI object path to the messages, and its usage model is similar to
> dev_().  This improves diagnostics in hotplug operations
> since it identifies an object that caused an issue in a log file.
> 
> v3:
>  - Changed acpi_pr_debug() to NOP when !DEBUG and !DYNAMIC_DEBUG.
>DYNAMIC_DEBUG will be supported later.
>  - Added const to a path variable in acpi_printk().
>  - Added more descriptions to the change log of patch 1/4.

Thanks Toshi.

This seems sensible to me.  I've no more comments either.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 patches] libata updates

2012-07-25 Thread Linus Torvalds

On Wed, Jul 25, 2012 at 3:58 PM, Jeff Garzik  wrote:
>
> What is the right course in when a post-merge change is needed?

Just describe the issue and the required change. Than I can just do it
as part of the merge, and now the whole series is bisectable,
including the merge itself.

Here's a (fairly bad) example:

  http://www.spinics.net/lists/netdev/msg192349.html

and the reason I call that a bad example is not because that's a bad
pull request, but simply that those are all real data conflicts, not
the more subtle kind of "it merges fine, but because new code
introduced uses an interface that changed, you need to do xyz".

I couldn't find an example of that in a quick look, it's fairly
uncommon to have non-conflicting merges that had semantic - but not
contextual - conflicts. (Although it does happen, and sometimes it's
actually not the developer, but Stephen Rothwell who notices it in
-next and lets me know before the merge).

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

RE: [PATCH] x86/ioapic: Fix NULL pointer dereference on CPU hotplug after disabling irqs

2012-07-25 Thread Siddha, Suresh B

Tomoki wrote:
> In current Linux, percpu variable `vector_irq' is not always cleared when
> a CPU is offlined. If the cpu that has the disabled irqs in vector_irq is
> hotplugged again, __setup_vector_irq() hits invalid irq vector and may
> crash.
>
> Commit f6175f5bfb4c partially fixes this, but was not enough in
> environments with IOMMU IRQ remapper.

So, this patch essentially makes the commit f6175f5bfb4c unnecessary, right?

Can you revert that too as part of this new proposed patch?

thanks,
suresh--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] posix_types.h: Cleanup stale __NFDBITS and related definitions

On Wed, 2012-07-25 at 10:40 -0400, Josh Boyer wrote:
> Recently, glibc made a change to suppress sign-conversion warnings in FD_SET
> (glibc commit ceb9e56b3d1).  This uncovered an issue with the kernel's
> definition of __NFDBITS if applications #include  after
> including .  A build failure would be seen when passing the
> -Werror=sign-compare and -D_FORTIFY_SOURCE=2 flags to gcc.
> 
> It was suggested that the kernel should either match the glibc definition of
> __NFDBITS or remove that entirely.  The current in-kernel uses of __NFDBITS
> can be replaced with BITS_PER_LONG, and there are no uses of the related
> __FDELT and __FDMASK defines.  Given that, we'll continue the cleanup that
> was started with commit 8b3d1cda4f5f ("posix_types: Remove fd_set macros")
> and drop the remaining unused macros.
> 
> Additionally, linux/time.h has similar macros defined that expand to nothing
> so we'll remove those at the same time.
> 
> Reported-by: Jeff Law 
> Suggested-by: Linus Torvalds 
> CC: 

# v3.4+

(as 8b3d1cda4f5f went into 3.4)

> Signed-off-by: Josh Boyer 
[...]

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


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

Re: [PATCH v4 08/12] block: Introduce new bio_split()

2012-07-25 Thread Kent Overstreet

On Wed, Jul 25, 2012 at 02:55:40PM +0300, Boaz Harrosh wrote:
> On 07/24/2012 11:11 PM, Kent Overstreet wrote:
> 
> > The new bio_split() can split arbitrary bios - it's not restricted to
> > single page bios, like the old bio_split() (previously renamed to
> > bio_pair_split()). It also has different semantics - it doesn't allocate
> > a struct bio_pair, leaving it up to the caller to handle completions.
> > 
> > Signed-off-by: Kent Overstreet 
> > ---
> >  fs/bio.c |   99 
> > ++
> >  1 files changed, 99 insertions(+), 0 deletions(-)
> > 
> > diff --git a/fs/bio.c b/fs/bio.c
> > index 5d02aa5..a15e121 100644
> > --- a/fs/bio.c
> > +++ b/fs/bio.c
> > @@ -1539,6 +1539,105 @@ struct bio_pair *bio_pair_split(struct bio *bi, int 
> > first_sectors)
> >  EXPORT_SYMBOL(bio_pair_split);
> >  
> >  /**
> > + * bio_split - split a bio
> > + * @bio:   bio to split
> > + * @sectors:   number of sectors to split from the front of @bio
> > + * @gfp:   gfp mask
> > + * @bs:bio set to allocate from
> > + *
> > + * Allocates and returns a new bio which represents @sectors from the 
> > start of
> > + * @bio, and updates @bio to represent the remaining sectors.
> > + *
> > + * If bio_sectors(@bio) was less than or equal to @sectors, returns @bio
> > + * unchanged.
> > + *
> > + * The newly allocated bio will point to @bio's bi_io_vec, if the split 
> > was on a
> > + * bvec boundry; it is the caller's responsibility to ensure that @bio is 
> > not
> > + * freed before the split.
> > + *
> > + * If bio_split() is running under generic_make_request(), it's not safe to
> > + * allocate more than one bio from the same bio set. Therefore, if it is 
> > running
> > + * under generic_make_request() it masks out __GFP_WAIT when doing the
> > + * allocation. The caller must check for failure if there's any 
> > possibility of
> > + * it being called from under generic_make_request(); it is then the 
> > caller's
> > + * responsibility to retry from a safe context (by e.g. punting to 
> > workqueue).
> > + */
> > +struct bio *bio_split(struct bio *bio, int sectors,
> > + gfp_t gfp, struct bio_set *bs)
> > +{
> > +   unsigned idx, vcnt = 0, nbytes = sectors << 9;
> > +   struct bio_vec *bv;
> > +   struct bio *ret = NULL;
> > +
> > +   BUG_ON(sectors <= 0);
> > +
> > +   /*
> > +* If we're being called from underneath generic_make_request() and we
> > +* already allocated any bios from this bio set, we risk deadlock if we
> > +* use the mempool. So instead, we possibly fail and let the caller punt
> > +* to workqueue or somesuch and retry in a safe context.
> > +*/
> > +   if (current->bio_list)
> > +   gfp &= ~__GFP_WAIT;
> 
> 
> NACK!
> 
> If as you said above in the comment:
>   if there's any possibility of it being called from under 
> generic_make_request();
> it is then the caller's responsibility to ...
> 
> So all the comment needs to say is: 
>   ... caller's responsibility to not set __GFP_WAIT at gfp.
> 
> And drop this here. It is up to the caller to decide. If the caller wants he 
> can do
> "if (current->bio_list)" by his own.
> 
> This is a general purpose utility you might not know it's context.
> for example with osdblk above will break.

Well I'm highly highly skeptical that using __GFP_WAIT under
generic_make_request() is ever a sane thing to do - it could certainly
be safe in specific circumstances, but it's just such a fragile thing to
rely on, you have to _never_ use the same bio pool more than once. And
even then I bet there's other subtle ways it could break.

But you're not the first to complain about it, and your point about
existing code is compelling.

commit ea124f899af29887e24d07497442066572012e5b
Author: Kent Overstreet 
Date:   Wed Jul 25 16:25:10 2012 -0700

block: Introduce new bio_split()

The new bio_split() can split arbitrary bios - it's not restricted to
single page bios, like the old bio_split() (previously renamed to
bio_pair_split()). It also has different semantics - it doesn't allocate
a struct bio_pair, leaving it up to the caller to handle completions.

diff --git a/fs/bio.c b/fs/bio.c
index 0470376..312e5de 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -1537,6 +1537,102 @@ struct bio_pair *bio_pair_split(struct bio *bi, int 
first_sectors)
 EXPORT_SYMBOL(bio_pair_split);
 
 /**
+ * bio_split - split a bio
+ * @bio:   bio to split
+ * @sectors:   number of sectors to split from the front of @bio
+ * @gfp:   gfp mask
+ * @bs:bio set to allocate from
+ *
+ * Allocates and returns a new bio which represents @sectors from the start of
+ * @bio, and updates @bio to represent the remaining sectors.
+ *
+ * If bio_sectors(@bio) was less than or equal to @sectors, returns @bio
+ * unchanged.
+ *
+ * The newly allocated bio will point to @bio's bi_io_vec, if the split was on 
a
+ * bvec boundry; it is the caller's

Re: [PATCH] xconfig: Display dependency values in debug_info

2012-07-25 Thread Randy Dunlap

On 07/25/2012 03:56 PM, Salar Ali Mumtaz wrote:

> Displays the current value of each of the dependencies of a menu item.
> Before, you needed to do tedious searching to find out the current values
> of the dependences. Now they all are included in the debug_info, making
> the task easier

Hi,
Would you please provide before and after examples?

I use xconfig quite a lot and it already shows me, e.g., for
CONFIG_DRM:


Symbol: DRM [=y]
Type : tristate
Prompt: Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)
Defined at drivers/gpu/drm/Kconfig:7
Depends on: HAS_IOMEM [=y] && (AGP [=y] || AGP [=y]=n) && !EMULATED_CMPXCHG && 
MMU [=y]
Location:
-> Device Drivers
-> Graphics support
Selects: I2C [=y] && I2C_ALGOBIT [=y] && DMA_SHARED_BUFFER [=y]




so what and where does this patch add debug info?

Thanks.


> Signed-off-by: Salar Ali Mumtaz 
> ---
>  scripts/kconfig/qconf.cc |   10 +-
>  1 files changed, 9 insertions(+), 1 deletions(-)
> 
> diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
> index df274fe..abd500f 100644
> --- a/scripts/kconfig/qconf.cc
> +++ b/scripts/kconfig/qconf.cc
> @@ -1073,8 +1073,10 @@ QString ConfigInfoView::debug_info(struct symbol *sym)
>   debug += " (choice)";
>   debug += "";
>   if (sym->rev_dep.expr) {
> - debug += "reverse dep: ";
> + debug += "reverse dep: (";
>   expr_print(sym->rev_dep.expr, expr_print_help, , E_NONE);
> + debug += " )  =";
> + debug += print_filter(sym_get_string_value(sym));
>   debug += "";
>   }
>   for (struct property *prop = sym->prop; prop; prop = prop->next) {
> @@ -1108,7 +1110,10 @@ QString ConfigInfoView::debug_info(struct symbol *sym)
>   }
>   if (prop->visible.expr) {
>   debug += "dep: ";
> + debug += " ( ";
>   expr_print(prop->visible.expr, expr_print_help, , 
> E_NONE);
> + debug += " )  =";
> + debug += print_filter(sym_get_string_value(sym));
>   debug += "";
>   }
>   }
> @@ -1157,6 +1162,9 @@ void ConfigInfoView::expr_print_help(void *data, struct 
> symbol *sym, const char
>   *text += QString().sprintf("", sym);
>   *text += str2;
>   *text += "";
> + *text += "   ";
> + *text += print_filter(sym_get_string_value(sym));
> + *text += "";
>   } else
>   *text += str2;
>  }



-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Update Memory hotplug messages

Updated Memory hotplug log messages with acpi_pr_()
and pr_().

Signed-off-by: Toshi Kani 
---
 drivers/acpi/acpi_memhotplug.c |   24 
 1 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 06c55cd..dcc8f4d 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -170,7 +170,7 @@ acpi_memory_get_device(acpi_handle handle,
/* Get the parent device */
result = acpi_bus_get_device(phandle, );
if (result) {
-   printk(KERN_WARNING PREFIX "Cannot get acpi bus device");
+   acpi_pr_warn(phandle, "Cannot get acpi bus device\n");
return -EINVAL;
}
 
@@ -180,14 +180,14 @@ acpi_memory_get_device(acpi_handle handle,
 */
result = acpi_bus_add(, pdevice, handle, ACPI_BUS_TYPE_DEVICE);
if (result) {
-   printk(KERN_WARNING PREFIX "Cannot add acpi bus");
+   acpi_pr_warn(handle, "Cannot add acpi bus\n");
return -EINVAL;
}
 
   end:
*mem_device = acpi_driver_data(device);
if (!(*mem_device)) {
-   printk(KERN_ERR "\n driver data not found");
+   acpi_pr_err(handle, "driver data not found\n");
return -ENODEV;
}
 
@@ -224,7 +224,7 @@ static int acpi_memory_enable_device(struct 
acpi_memory_device *mem_device)
/* Get the range from the _CRS */
result = acpi_memory_get_device_resources(mem_device);
if (result) {
-   printk(KERN_ERR PREFIX "get_device_resources failed\n");
+   pr_err(PREFIX "get_device_resources failed\n");
mem_device->state = MEMORY_INVALID_STATE;
return result;
}
@@ -257,7 +257,7 @@ static int acpi_memory_enable_device(struct 
acpi_memory_device *mem_device)
num_enabled++;
}
if (!num_enabled) {
-   printk(KERN_ERR PREFIX "add_memory failed\n");
+   acpi_pr_err(mem_device->device->handle, "add_memory failed\n");
mem_device->state = MEMORY_INVALID_STATE;
return -EINVAL;
}
@@ -353,7 +353,7 @@ static void acpi_memory_device_notify(acpi_handle handle, 
u32 event, void *data)
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
  "\nReceived DEVICE CHECK notification 
for device\n"));
if (acpi_memory_get_device(handle, _device)) {
-   printk(KERN_ERR PREFIX "Cannot find driver data\n");
+   acpi_pr_err(handle, "Cannot find driver data\n");
break;
}
 
@@ -361,7 +361,7 @@ static void acpi_memory_device_notify(acpi_handle handle, 
u32 event, void *data)
break;
 
if (acpi_memory_enable_device(mem_device)) {
-   pr_err(PREFIX "Cannot enable memory device\n");
+   acpi_pr_err(handle, "Cannot enable memory device\n");
break;
}
 
@@ -373,12 +373,12 @@ static void acpi_memory_device_notify(acpi_handle handle, 
u32 event, void *data)
  "\nReceived EJECT REQUEST notification for 
device\n"));
 
if (acpi_bus_get_device(handle, )) {
-   printk(KERN_ERR PREFIX "Device doesn't exist\n");
+   acpi_pr_err(handle, "Device doesn't exist\n");
break;
}
mem_device = acpi_driver_data(device);
if (!mem_device) {
-   printk(KERN_ERR PREFIX "Driver Data is NULL\n");
+   acpi_pr_err(handle, "Driver Data is NULL\n");
break;
}
 
@@ -389,7 +389,7 @@ static void acpi_memory_device_notify(acpi_handle handle, 
u32 event, void *data)
 *  with generic sysfs driver
 */
if (acpi_memory_disable_device(mem_device)) {
-   pr_err(PREFIX "Disable memory device\n");
+   acpi_pr_err(handle, "Disable memory device\n");
/*
 * If _EJ0 was called but failed, _OST is not
 * necessary.
@@ -449,7 +449,7 @@ static int acpi_memory_device_add(struct acpi_device 
*device)
/* Set the device state */
mem_device->state = MEMORY_POWER_ON_STATE;
 
-   printk(KERN_DEBUG "%s \n", acpi_device_name(device));
+   pr_debug("%s\n", acpi_device_name(device));
 
/*
 * Early boot code has recognized memory area by EFI/E820.
@@ -464,7 +464,7 @@ static int acpi_memory_device_add(struct acpi_device 
*device)
/* call add_memory func */
result = acpi_memory_enable_device(mem_device);
if (result)
-

[PATCH v3 4/4] ACPI: Update Container hotplug messages

Updated Container hotplug log messages with acpi_pr_()
and pr_().

Signed-off-by: Toshi Kani 
---
 drivers/acpi/container.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/container.c b/drivers/acpi/container.c
index 01a986d..643e962 100644
--- a/drivers/acpi/container.c
+++ b/drivers/acpi/container.c
@@ -99,7 +99,7 @@ static int acpi_container_add(struct acpi_device *device)
 
 
if (!device) {
-   printk(KERN_ERR PREFIX "device is NULL\n");
+   pr_err(PREFIX "device is NULL\n");
return -EINVAL;
}
 
@@ -164,7 +164,7 @@ static void container_notify_cb(acpi_handle handle, u32 
type, void *context)
case ACPI_NOTIFY_BUS_CHECK:
/* Fall through */
case ACPI_NOTIFY_DEVICE_CHECK:
-   printk(KERN_WARNING "Container driver received %s event\n",
+   pr_warn("Container driver received %s event\n",
   (type == ACPI_NOTIFY_BUS_CHECK) ?
   "ACPI_NOTIFY_BUS_CHECK" : "ACPI_NOTIFY_DEVICE_CHECK");
 
@@ -185,7 +185,7 @@ static void container_notify_cb(acpi_handle handle, u32 
type, void *context)
 
result = container_device_add(, handle);
if (result) {
-   pr_warn("Failed to add container\n");
+   acpi_pr_warn(handle, "Failed to add container\n");
break;
}
 
-- 
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/4] ACPI: Update CPU hotplug messages

Updated CPU hotplug log messages with acpi_pr_(),
dev_() and pr_().  Some messages are also
changed for clarity.

Signed-off-by: Toshi Kani 
Tested-by: Vijay Mohan Pandarathil 
---
 drivers/acpi/processor_driver.c |   36 +---
 1 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index a6bdeaa..225f252 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -282,7 +282,9 @@ static int acpi_processor_get_info(struct acpi_device 
*device)
/* Declared with "Processor" statement; match ProcessorID */
status = acpi_evaluate_object(pr->handle, NULL, NULL, );
if (ACPI_FAILURE(status)) {
-   printk(KERN_ERR PREFIX "Evaluating processor object\n");
+   acpi_pr_err(pr->handle,
+   "Failed to evaluate processor object (0x%x)\n",
+   status);
return -ENODEV;
}
 
@@ -301,8 +303,9 @@ static int acpi_processor_get_info(struct acpi_device 
*device)
status = acpi_evaluate_integer(pr->handle, METHOD_NAME__UID,
NULL, );
if (ACPI_FAILURE(status)) {
-   printk(KERN_ERR PREFIX
-   "Evaluating processor _UID [%#x]\n", status);
+   acpi_pr_err(pr->handle,
+   "Failed to evaluate processor _UID (0x%x)\n",
+   status);
return -ENODEV;
}
device_declaration = 1;
@@ -345,7 +348,7 @@ static int acpi_processor_get_info(struct acpi_device 
*device)
if (!object.processor.pblk_address)
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No PBLK (NULL address)\n"));
else if (object.processor.pblk_length != 6)
-   printk(KERN_ERR PREFIX "Invalid PBLK length [%d]\n",
+   acpi_pr_err(pr->handle, "Invalid PBLK length [%d]\n",
object.processor.pblk_length);
else {
pr->throttling.address = object.processor.pblk_address;
@@ -429,8 +432,8 @@ static int acpi_cpu_soft_notify(struct notifier_block *nfb,
 * Initialize missing things
 */
if (pr->flags.need_hotplug_init) {
-   printk(KERN_INFO "Will online and init hotplugged "
-  "CPU: %d\n", pr->id);
+   pr_info("Will online and init hotplugged CPU: %d\n",
+   pr->id);
WARN(acpi_processor_start(pr), "Failed to start CPU:"
" %d\n", pr->id);
pr->flags.need_hotplug_init = 0;
@@ -491,14 +494,16 @@ static __ref int acpi_processor_start(struct 
acpi_processor *pr)
   >cdev->device.kobj,
   "thermal_cooling");
if (result) {
-   printk(KERN_ERR PREFIX "Create sysfs link\n");
+   dev_err(>dev,
+   "Failed to create sysfs link 'thermal_cooling'\n");
goto err_thermal_unregister;
}
result = sysfs_create_link(>cdev->device.kobj,
   >dev.kobj,
   "device");
if (result) {
-   printk(KERN_ERR PREFIX "Create sysfs link\n");
+   dev_err(>cdev->device,
+   "Failed to create sysfs link 'device'\n");
goto err_remove_sysfs_thermal;
}
 
@@ -560,8 +565,7 @@ static int __cpuinit acpi_processor_add(struct acpi_device 
*device)
 */
if (per_cpu(processor_device_array, pr->id) != NULL &&
per_cpu(processor_device_array, pr->id) != device) {
-   printk(KERN_WARNING "BIOS reported wrong ACPI id "
-   "for the processor\n");
+   pr_warn("BIOS reported wrong ACPI id for the processor\n");
result = -ENODEV;
goto err_free_cpumask;
}
@@ -715,7 +719,7 @@ static void acpi_processor_hotplug_notify(acpi_handle 
handle,
 
result = acpi_processor_device_add(handle, );
if (result) {
-   pr_err(PREFIX "Unable to add the device\n");
+   acpi_pr_err(handle, "Unable to add the device\n");
break;
}
 
@@ -727,17 +731,19 @@ static void acpi_processor_hotplug_notify(acpi_handle 
handle,
  "received ACPI_NOTIFY_EJECT_REQUEST\n"));
 
if (acpi_bus_get_device(handle, )) {
-   pr_err(PREFIX "Device don't exist, dropping EJECT\n");
+   acpi_pr_err(handle,
+   "Device

[PATCH v3 1/4] ACPI: Add acpi_pr_() interfaces

This patch introduces acpi_pr_(), where  is a kernel
message level such as err/warn/info, to support improved logging
messages for ACPI, esp. in hotplug operations.  acpi_pr_()
appends "ACPI" prefix and ACPI object path to the messages.  This
improves diagnostics in hotplug operations since it identifies an
object that caused an issue in a log file.

acpi_pr_() takes acpi_handle as an argument, which is passed
to ACPI hotplug notify handlers from the ACPICA.  Therefore, it is
always available unlike other kernel objects, such as device.

For example, the statement below
  acpi_pr_err(handle, "Device don't exist, dropping EJECT\n");
logs an error message like this at KERN_ERR.
  ACPI: \_SB_.SCK4.CPU4: Device don't exist, dropping EJECT

ACPI drivers can use acpi_pr_() when they need to identify
a target ACPI object in their messages, such as error messages.
The usage model is similar to dev_().  acpi_pr_() can
be used when device is not created/valid, which may be the case for
ACPI hotplug handlers.  ACPI drivers can continue to use dev_()
when device is valid.

ACPI drivers also continue to use pr_() when ACPI device
path does not have to be appended to the messages, such as boot-up
messages.

Note: ACPI_[WARNING|INFO|ERROR]() are intended for the ACPICA and
are not associated with the kernel message level.

Signed-off-by: Toshi Kani 
Tested-by: Vijay Mohan Pandarathil 
---
 drivers/acpi/utils.c|   34 ++
 include/acpi/acpi_bus.h |   31 +++
 2 files changed, 65 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
index 3e87c9c..ec0c6f9 100644
--- a/drivers/acpi/utils.c
+++ b/drivers/acpi/utils.c
@@ -454,3 +454,37 @@ acpi_evaluate_hotplug_ost(acpi_handle handle, u32 
source_event,
 #endif
 }
 EXPORT_SYMBOL(acpi_evaluate_hotplug_ost);
+
+/**
+ * acpi_printk: Print messages with ACPI prefix and object path
+ *
+ * This function is intended to be called through acpi_pr_ macros.
+ */
+void
+acpi_printk(const char *level, acpi_handle handle, const char *fmt, ...)
+{
+   struct va_format vaf;
+   va_list args;
+   struct acpi_buffer buffer = {
+   .length = ACPI_ALLOCATE_BUFFER,
+   .pointer = NULL
+   };
+   const char *path;
+   acpi_status ret;
+
+   va_start(args, fmt);
+   vaf.fmt = fmt;
+   vaf.va = 
+
+   ret = acpi_get_name(handle, ACPI_FULL_PATHNAME, );
+   if (ret == AE_OK)
+   path = buffer.pointer;
+   else
+   path = "";
+
+   printk("%sACPI: %s: %pV", level, path, );
+
+   va_end(args);
+   kfree(buffer.pointer);
+}
+EXPORT_SYMBOL(acpi_printk);
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index bde976e..1c855b8 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -85,6 +85,37 @@ struct acpi_pld {
 
 acpi_status
 acpi_get_physical_device_location(acpi_handle handle, struct acpi_pld *pld);
+
+void acpi_printk(const char *level, acpi_handle handle, const char *fmt, ...);
+
+#define acpi_pr_emerg(handle, fmt, ...)\
+   acpi_printk(KERN_EMERG, handle, fmt, ##__VA_ARGS__)
+#define acpi_pr_alert(handle, fmt, ...)\
+   acpi_printk(KERN_ALERT, handle, fmt, ##__VA_ARGS__)
+#define acpi_pr_crit(handle, fmt, ...) \
+   acpi_printk(KERN_CRIT, handle, fmt, ##__VA_ARGS__)
+#define acpi_pr_err(handle, fmt, ...)  \
+   acpi_printk(KERN_ERR, handle, fmt, ##__VA_ARGS__)
+#define acpi_pr_warn(handle, fmt, ...) \
+   acpi_printk(KERN_WARNING, handle, fmt, ##__VA_ARGS__)
+#define acpi_pr_notice(handle, fmt, ...)   \
+   acpi_printk(KERN_NOTICE, handle, fmt, ##__VA_ARGS__)
+#define acpi_pr_info(handle, fmt, ...) \
+   acpi_printk(KERN_INFO, handle, fmt, ##__VA_ARGS__)
+
+/* REVISIT: Need to support CONFIG_DYNAMIC_DEBUG */
+#if defined(DEBUG) || defined(CONFIG_DYNAMIC_DEBUG)
+#define acpi_pr_debug(handle, fmt, ...)
\
+   acpi_printk(KERN_DEBUG, handle, fmt, ##__VA_ARGS__)
+#else
+#define acpi_pr_debug(handle, fmt, ...)
\
+({ \
+   if (0)  \
+   acpi_printk(KERN_DEBUG, handle, fmt, ##__VA_ARGS__);\
+   0;  \
+})
+#endif
+
 #ifdef CONFIG_ACPI
 
 #include 
-- 
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/4] ACPI: hotplug messages improvement