Re: [RFC PATCH 3/4] gcov: compile specific gcov implementation based on gcc version
On Saturday 24 August 2013, Frantisek Hrbata wrote: > If I understand it correctly, this would mean that you will be able to use > only > one implementation of gcov format at the time. Meaning you will be able to get > coverage data for module, but not for kernel if it was compiled with different > gcc(gcda format). This is probably ok if you work only on your module, but I'm > not sure this is generally the right approach. In this case I would probably > rather see some support for more gcov formats at the same time(e.g. set of > callback operations per gcov version). Again I'm probably missing something, > but > I still cannot see reason why to add such feature. If you want gcov support > just > compile your kernel and modules with the same gcc version(gcda format). But if > this is really needed maybe it would be better to consider some parallel > support > for more gcov formats based on the gcov_info version. The kernel is always built with exactly one version, including all the modules. I don't see any reason whatsoever to support externally built modules with gcov, in particular when they are not built with the system compiler. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 fixes for 3.11-rc7
The following changes since commit b36f4be3de1b123d8601de062e7dbfc904f305fb: Linux 3.11-rc6 (2013-08-18 14:36:53 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.11-rc7 for you to fetch changes up to 52d5b9aba1f5790ca3231c262979c2c3e26dd99b: usb: phy: fix build breakage (2013-08-23 10:41:46 -0700) USB fixes for 3.11-rc7 Here are two USB fixes for 3.11-rc7 One fixes a reported regression in the OHCI driver, and the other fixes a reported build breakage in the USB phy drivers. Signed-off-by: Greg Kroah-Hartman Alan Stern (1): USB: OHCI: add missing PCI PM callbacks to ohci-pci.c Anatolij Gustschin (1): usb: phy: fix build breakage drivers/usb/host/ohci-pci.c | 5 + drivers/usb/phy/phy-fsl-usb.h | 2 +- drivers/usb/phy/phy-fsm-usb.c | 2 +- 3 files changed, 7 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] Staging driver fixes for 3.11-rc7
The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8: Linux 3.11-rc5 (2013-08-11 18:04:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ tags/staging-3.11-rc7 for you to fetch changes up to 3955dfa8216f712bc204a5ad2f4e51efff252fde: staging: comedi: bug-fix NULL pointer dereference on failed attach (2013-08-23 10:31:47 -0700) Staging fixes for 3.11-rc7 Here are two tiny staging tree fixes (well, one is for an iio driver, but those updates come through the staging tree due to dependancies.) One fixes a problem with an IIO driver, and the other fixes a bug in the comedi driver core. Signed-off-by: Greg Kroah-Hartman Greg Kroah-Hartman (1): Merge tag 'iio-fixes-for-3.11c' of git://git.kernel.org/.../jic23/iio into staging-linus Ian Abbott (1): staging: comedi: bug-fix NULL pointer dereference on failed attach Peter Meerwald (1): iio: adjd_s311: Fix non-scan mode data read drivers/iio/light/adjd_s311.c| 3 ++- drivers/staging/comedi/drivers.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1] anon_inodefs: forbid open via /proc
On 08/25, Oleg Nesterov wrote: > > > I find it hard to believe that anything actually relies on open(2) > > succeeding, given that it returns an fd with the wrong f_ops. > > OK, let me send the patch then. I won't argue if it is ignored or > nacked. Damn. Sorry for noise, I removed lkml by accident, let me resend. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] anon_inodefs: forbid open via /proc
open("/proc/pid/$anon-fd") should fail, we can't create the new
file with correct f_op/etc correctly. Currently this creates the
bogus file with the empty anon_inode_fops, this is harmless but
still wrong and misleading.
Add anon_inode_fops->anon_open() which simply returns ENXIO like
sock_no_open() does in this case.
Signed-off-by: Oleg Nesterov
---
fs/anon_inodes.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
index 47a65df..af25036 100644
--- a/fs/anon_inodes.c
+++ b/fs/anon_inodes.c
@@ -24,7 +24,15 @@
static struct vfsmount *anon_inode_mnt __read_mostly;
static struct inode *anon_inode_inode;
-static const struct file_operations anon_inode_fops;
+
+static int anon_open(struct inode *inode, struct file *file)
+{
+ return -ENXIO;
+}
+
+static const struct file_operations anon_inode_fops = {
+ .open = anon_open,
+};
/*
* anon_inodefs_dname() is called from d_path().
--
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: [PATCH v2] ARM: dts: exynos5420/5250: add ADC device tree node
On 08/23/13 17:02, Naveen Krishna Chatradhi wrote:
Add ADC device tree node for exynos5420 and exynos5250
Signed-off-by: Naveen Krishna Chatradhi
Signed-off-by: Doug Anderson
---
Added recipients accordingly,
./scripts/get_maintainer.pl -f of the modified files
arch/arm/boot/dts/exynos5250.dtsi | 11 +++
arch/arm/boot/dts/exynos5420.dtsi | 11 +++
2 files changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 1eec646..518f8cd 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -641,4 +641,15 @@
clocks =< 133>,< 339>;
clock-names = "sclk_fimd", "fimd";
};
+
+ adc: adc@12D1 {
+ compatible = "samsung,exynos-adc-v1";
+ reg =<0x12D1 0x100>,<0x10040718 0x4>;
+ interrupts =<0 106 0>;
+ clocks =< 303>;
+ clock-names = "adc";
+ #io-channel-cells =<1>;
+ io-channel-ranges;
+ status = "disabled";
+ };
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 5353e32..0c5c055 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -218,4 +218,15 @@
clocks =< 147>,< 421>;
clock-names = "sclk_fimd", "fimd";
};
+
+ adc: adc@12D1 {
+ compatible = "samsung,exynos-adc-v2";
+ reg =<0x12D1 0x100>,<0x10040720 0x4>;
+ interrupts =<0 106 0>;
+ clocks =< 270>;
+ clock-names = "adc";
+ #io-channel-cells =<1>;
+ io-channel-ranges;
+ status = "disabled";
+ };
};
Looks good to me, applied.
Thanks,
Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
On Sun, Aug 25, 2013 at 11:19:37PM +0800, Lai Jiangshan wrote:
> Hi, Steven
>
> Any comments about this patch?
For whatever it is worth, it ran without incident for two hours worth
of rcutorture on my P5 test (boosting but no CPU hotplug).
Lai, do you have a specific test for this patch? Your deadlock
scenario looks plausible, but is apparently not occurring in the
mainline kernel.
Thanx, Paul
> Thanks,
> Lai
>
>
> On Fri, Aug 23, 2013 at 2:26 PM, Lai Jiangshan wrote:
>
> > [PATCH] rcu/rt_mutex: eliminate a kind of deadlock for rcu read site
> >
> > Current rtmutex's lock->wait_lock doesn't disables softirq nor irq, it will
> > cause rcu read site deadlock when rcu overlaps with any
> > softirq-context/irq-context lock.
> >
> > @L is a spinlock of softirq or irq context.
> >
> > CPU1cpu2(rcu boost)
> > rcu_read_lock() rt_mutext_lock()
> > raw_spin_lock(lock->wait_lock)
> > spin_lock_XX(L)> irq>
> > rcu_read_unlock() do_softirq()
> > rcu_read_unlock_special()
> > rt_mutext_unlock()
> > raw_spin_lock(lock->wait_lock)spin_lock_XX(L) **DEADLOCK**
> >
> > This patch fixes this kind of deadlock by removing rt_mutext_unlock() from
> > rcu_read_unlock(), new rt_mutex_rcu_deboost_unlock() is called instead.
> > Thus rtmutex's lock->wait_lock will not be called from rcu_read_unlock().
> >
> > This patch does not eliminate all kinds of rcu-read-site deadlock,
> > if @L is a scheduler lock, it will be deadlock, we should apply Paul's rule
> > in this case.(avoid overlapping or preempt_disable()).
> >
> > rt_mutex_rcu_deboost_unlock() requires the @waiter is queued, so we
> > can't directly call rt_mutex_lock() in the rcu_boost thread,
> > we split rt_mutex_lock() into two steps just like pi-futex.
> > This result a internal state in rcu_boost thread and cause
> > rcu_boost thread a bit more complicated.
> >
> > Thanks
> > Lai
> >
> > diff --git a/include/linux/init_task.h b/include/linux/init_task.h
> > index 5cd0f09..8830874 100644
> > --- a/include/linux/init_task.h
> > +++ b/include/linux/init_task.h
> > @@ -102,7 +102,7 @@ extern struct group_info init_groups;
> >
> > #ifdef CONFIG_RCU_BOOST
> > #define INIT_TASK_RCU_BOOST() \
> > - .rcu_boost_mutex = NULL,
> > + .rcu_boost_waiter = NULL,
> > #else
> > #define INIT_TASK_RCU_BOOST()
> > #endif
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index e9995eb..1eca99f 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -1078,7 +1078,7 @@ struct task_struct {
> > struct rcu_node *rcu_blocked_node;
> > #endif /* #ifdef CONFIG_TREE_PREEMPT_RCU */
> > #ifdef CONFIG_RCU_BOOST
> > - struct rt_mutex *rcu_boost_mutex;
> > + struct rt_mutex_waiter *rcu_boost_waiter;
> > #endif /* #ifdef CONFIG_RCU_BOOST */
> >
> > #if defined(CONFIG_SCHEDSTATS) || defined(CONFIG_TASK_DELAY_ACCT)
> > @@ -1723,7 +1723,7 @@ static inline void rcu_copy_process(struct
> > task_struct *p)
> > p->rcu_blocked_node = NULL;
> > #endif /* #ifdef CONFIG_TREE_PREEMPT_RCU */
> > #ifdef CONFIG_RCU_BOOST
> > - p->rcu_boost_mutex = NULL;
> > + p->rcu_boost_waiter = NULL;
> > #endif /* #ifdef CONFIG_RCU_BOOST */
> > INIT_LIST_HEAD(>rcu_node_entry);
> > }
> > diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
> > index 769e12e..d207ddd 100644
> > --- a/kernel/rcutree_plugin.h
> > +++ b/kernel/rcutree_plugin.h
> > @@ -33,6 +33,7 @@
> > #define RCU_KTHREAD_PRIO 1
> >
> > #ifdef CONFIG_RCU_BOOST
> > +#include "rtmutex_common.h"
> > #define RCU_BOOST_PRIO CONFIG_RCU_BOOST_PRIO
> > #else
> > #define RCU_BOOST_PRIO RCU_KTHREAD_PRIO
> > @@ -340,7 +341,7 @@ void rcu_read_unlock_special(struct task_struct *t)
> > unsigned long flags;
> > struct list_head *np;
> > #ifdef CONFIG_RCU_BOOST
> > - struct rt_mutex *rbmp = NULL;
> > + struct rt_mutex_waiter *waiter = NULL;
> > #endif /* #ifdef CONFIG_RCU_BOOST */
> > struct rcu_node *rnp;
> > int special;
> > @@ -397,10 +398,10 @@ void rcu_read_unlock_special(struct task_struct *t)
> > #ifdef CONFIG_RCU_BOOST
> > if (>rcu_node_entry == rnp->boost_tasks)
> > rnp->boost_tasks = np;
> > - /* Snapshot/clear ->rcu_boost_mutex with rcu_node lock
> > held. */
> > - if (t->rcu_boost_mutex) {
> > - rbmp = t->rcu_boost_mutex;
> > - t->rcu_boost_mutex = NULL;
> > + /* Snapshot/clear ->rcu_boost_waiter with rcu_node lock
> > held. */
> > + if (t->rcu_boost_waiter) {
> > + waiter = t->rcu_boost_waiter;
> > + t->rcu_boost_waiter = NULL;
> > }
> > #endif /* #ifdef
[PATCH] acpi: blacklist win8 OSI for buggy laptops
Since v3.7 the acpi backlight driver doesn't work correctly in several
machines because ACPI code has different code for Windows 8, and the
rest.
The commit ea45ea7 (in v3.11-rc2) tried to fix this problem by using the
intel backlight driver, however it introduced several other issues in
different machines.
This patch fixes both regressions by blacklisting the win8 OSI, so we
are back to v3.6 behavior, and it should remain that way until the intel
backlight driver is fixed.
Since v3.7, users have been forced to fix the initial regression by
modifying the boot arguments (acpi_osi="!Windows 2012").
Once the Intel backlight driver works correctly for all machines, this
blacklist can be removed and that driver can be used instead.
https://bugzilla.kernel.org/show_bug.cgi?id=60682
Signed-off-by: Felipe Contreras
---
drivers/acpi/blacklist.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
index cb96296..42cccbe 100644
--- a/drivers/acpi/blacklist.c
+++ b/drivers/acpi/blacklist.c
@@ -192,6 +192,12 @@ static int __init dmi_disable_osi_win7(const struct
dmi_system_id *d)
acpi_osi_setup("!Windows 2009");
return 0;
}
+static int __init dmi_disable_osi_win8(const struct dmi_system_id *d)
+{
+ printk(KERN_NOTICE PREFIX "DMI detected: %s\n", d->ident);
+ acpi_osi_setup("!Windows 2012");
+ return 0;
+}
static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
{
@@ -269,6 +275,35 @@ static struct dmi_system_id acpi_osi_dmi_table[]
__initdata = {
},
/*
+* The following machines have broken backlight support when reporting
+* the Windows 2012 OSI, so disable it until their support is fixed.
+*/
+ {
+ .callback = dmi_disable_osi_win8,
+ .ident = "ASUS Zenbook Prime UX31A",
+ .matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+DMI_MATCH(DMI_PRODUCT_NAME, "UX31A"),
+ },
+ },
+ {
+ .callback = dmi_disable_osi_win8,
+ .ident = "Dell Inspiron 15R SE",
+ .matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 7520"),
+ },
+ },
+ {
+ .callback = dmi_disable_osi_win8,
+ .ident = "Lenovo ThinkPad Edge E530",
+ .matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "3259A2G"),
+ },
+ },
+
+ /*
* BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
* Linux ignores it, except for the machines enumerated below.
*/
--
1.8.4-fc
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Asus F5RL laptop unable to resume from S3 because of radeon module
On Sunday 25 August 2013 16:51:06 Deucher, Alexander wrote:
> > -Original Message-
> > From: Ondrej Zary [mailto:li...@rainbow-software.org]
> > Sent: Friday, August 23, 2013 1:55 PM
> > To: Deucher, Alexander
> > Cc: Kernel development list
> > Subject: Re: Asus F5RL laptop unable to resume from S3 because of radeon
> > module
> >
> > On Friday 23 August 2013 00:08:33 Ondrej Zary wrote:
> > > On Thursday 22 August 2013 22:56:03 Ondrej Zary wrote:
> > > > On Thursday 22 August 2013 22:24:17 Deucher, Alexander wrote:
> > > > > > -Original Message-
> > > > > > From: Ondrej Zary [mailto:li...@rainbow-software.org]
> > > > > > Sent: Thursday, August 22, 2013 4:00 PM
> > > > > > To: Deucher, Alexander
> > > > > > Cc: Kernel development list
> > > > > > Subject: Re: Asus F5RL laptop unable to resume from S3 because of
> > > > > > radeon module
> > > > > >
> > > > > > On Thursday 22 August 2013 21:49:41 Deucher, Alexander wrote:
> > > > > > > > -Original Message-
> > > > > > > > From: Ondrej Zary [mailto:li...@rainbow-software.org]
> > > > > > > > Sent: Thursday, August 22, 2013 2:18 PM
> > > > > > > > To: Kernel development list
> > > > > > > > Cc: Deucher, Alexander
> > > > > > > > Subject: Asus F5RL laptop unable to resume from S3 because of
> > > > > > > > radeon module
> > > > > > > >
> > > > > > > > Hello,
> > > > > > > > resume from suspend-to-RAM (S3) on Asus F5RL laptop does not
> > > > > > > > work. According to many reports found by Google, it was
> > > > > > > > always been that and there
> > > > > > > > is no fix or workaround.
> > > > > > >
> > > > > > > Make sure your kernel has this patch:
> > > > > > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
> > > > > > >comm it /? id=c ef1d00cd56f600121ad121875655ad410a001b8
> > > > > >
> > > > > > Just tried latest git (3.11-rc6+) and the problem persists.
> > > > >
> > > > > You might try adding a quirk for your system in
> > > > > radeon_combios_asic_init() in radeon_combios.c. You can try
> >
> > something
> >
> > > > > like this for testing:
> > > > >
> > > > > diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
> > > > > b/drivers/gpu/drm/radeon/radeon_combios.c index 68ce360..0419a2c
> >
> > 100644
> >
> > > > > --- a/drivers/gpu/drm/radeon/radeon_combios.c
> > > > > +++ b/drivers/gpu/drm/radeon/radeon_combios.c
> > > > > @@ -3398,6 +3398,8 @@ void radeon_combios_asic_init(struct
> >
> > drm_device
> >
> > > > > *dev) rdev->pdev->subsystem_device == 0x30ae)
> > > > > return;
> > > > >
> > > > > + return;
> > > > > +
> > > > > /* DYN CLK 1 */
> > > > > table = combios_get_table_offset(dev,
> >
> > COMBIOS_DYN_CLK_1_TABLE);
> >
> > > > > if (table)
> > > > >
> > > > > If that doesn't work, you'll probably have to track down where it's
> > > > > hanging during resume, or compare registers before and after resume
> >
> > to
> >
> > > > > see if it's some particular state that's causing a problem.
> > > >
> > > > No change.
> > > >
> > > > Inserted "return -1;" before radeon_device_init() to
> > > > radeon_driver_load_kms() - driver fails to load and resume works.
> > > > Moved it (and changed to "r = -1; goto out;") a bit down before
> > > > radeon_modeset_init() - driver fails to load and resume stopped
> >
> > working.
> >
> > > Going deeper... it works before rs400_startup() and does not work after
> > > that. Will continue later.
> >
> > Tracked the problem down to rs400_gart_enable(). When this "Disable AGP
> > mode"
> > code is commented out, the machine resumes fine:
> >
> > if ((rdev->family == CHIP_RS690) || (rdev->family == CHIP_RS740))
> > { WREG32_MC(RS480_MC_MISC_CNTL,
> > (RS480_GART_INDEX_REG_EN |
> > RS690_BLOCK_GFX_D3_EN)); } else {
> > WREG32_MC(RS480_MC_MISC_CNTL, RS480_GART_INDEX_REG_EN);
> > }
>
> Does the driver work properly after resume with that part commented out or
> does it just avoid the hang?
Console seems to work fine, haven't tested X, 3D or video.
> Alex
>
> > > > > Alex
> > > > >
> > > > > > > Alex
> > > > > > >
> > > > > > > > Did some tests:
> > > > > > > >
> > > > > > > > radeon module loaded (usual state):
> > > > > > > > After "echo mem>/sys/power/state", the laptop suspends
> >
> > correctly
> >
> > > > > > (power
> > > > > >
> > > > > > > > LED
> > > > > > > > blinks). When power button is pressed, power LED goes on and
> > > > > > > > that's all. No more activity, machine is frozen completely.
> > > > > > > >
> > > > > > > > radeon module not loaded at all:
> > > > > > > > Laptop resumes correctly (keyboard LED work, network works),
> >
> > only
> >
> > > > > > > > the
> > > > > >
> > > > > > LCD
> > > > > >
> > > > > > > > is
> > > > > > > > blank (obviously). Loading radeon module now initializes the
> > > > > > > > card properly: LCD goes on and console works.
> > > > > > > >
> > > > > > > > radeon module loaded (but fbcon module not loaded) and then
> > > > > >
>
Re: [PATCH v2] vfs: Tighten up linkat(..., AT_EMPTY_PATH)
On Sun, Aug 25, 2013 at 7:23 AM, Al Viro wrote:
> On Sun, Aug 25, 2013 at 12:26:34AM -0700, Andy Lutomirski wrote:
>
>> I think this is more screwed up than just flink and open. For example:
>>
>> $ echo 'WTF' >test
>> $ truncate -s 1 /proc/self/fd/3 3> $ cat test
>> W$
>>
>> IMO that should have failed.
>
> Why? truncate() always follows links, so what's the problem with that
> one? That you get checks of truncate() and not ftruncate()?
The same as the issue with all these other things: the fd might have
survived a privilege drop or been passed through exec or SCM_RIGHTS,
and the holder of the fd might not be able to see the inode.
For example, suppose a daemon creates a file with O_TMPFILE | O_RDWR.
Then it does open("/proc/self/fd/N", O_RDONLY) to get a read-only fd
for the same temporary file. It passes that fd to something else.
It's rather surprising that the recipient would be able to truncate it
using /proc/self/fd when it couldn't ftruncate it due to its being
O_RDONLY.
(Of course, this can be worked around by setting the mode to 0644, but
I doubt that everyone will get that right.)
>
>> In an ideal world (I think) ffrob(N), frobat(N, "", AT_EMPTY_PATH),
>> and frobat(AT_FDCWD, "/proc/self/fd/N) should generally do the same
>> thing.
>
> What about the cases where frob() and ffrob() check for different things?
I'll go out on a limb and say that every single case where ffrob has a
check that frob("/proc/self/fd/N") doesn't is wrong. Maybe we're
stuck with them for backwards compatibility, but that doesn't mean
they're good ideas.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 17/18] Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash algorithm
On Thu 2013-08-22 19:01:56, Lee, Chun-Yi wrote: > This patch introduced SNAPSHOT_SIG_HASH config for user to select which > hash algorithm will be used during signature generation of snapshot. > > v2: > Add define check of oCONFIG_SNAPSHOT_VERIFICATION in snapshot.c before > declare pkey_hash(). > > Reviewed-by: Jiri Kosina > Signed-off-by: Lee, Chun-Yi > --- > kernel/power/Kconfig| 46 ++ > kernel/power/snapshot.c | 27 ++- > 2 files changed, 68 insertions(+), 5 deletions(-) > > diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig > index b592d88..79b34fa 100644 > --- a/kernel/power/Kconfig > +++ b/kernel/power/Kconfig > @@ -78,6 +78,52 @@ config SNAPSHOT_VERIFICATION > dependent on UEFI environment. EFI bootloader should generate the > key-pair. > > +choice > + prompt "Which hash algorithm should snapshot be signed with?" > +depends on SNAPSHOT_VERIFICATION > +help > + This determines which sort of hashing algorithm will be used during > + signature generation of snapshot. This algorithm _must_ be built > into > + the kernel directly so that signature verification can take place. > + It is not possible to load a signed snapshot containing the algorithm > + to check the signature on that module. Like if 1000 ifdefs you already added to the code are not enough, you make some new ones? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/18] Hibernate: adapt to UEFI secure boot with signature check
On Thu 2013-08-22 19:01:54, Lee, Chun-Yi wrote:
> In current solution, the snapshot signature check used the RSA key-pair
> that are generated by bootloader(e.g. shim) and pass the key-pair to
> kernel through EFI variables. I choice to binding the snapshot
> signature check mechanism with UEFI secure boot for provide stronger
> protection of hibernate. Current behavior is following:
>
> + UEFI Secure Boot ON, Kernel found key-pair from shim:
>Will do the S4 signature check.
>
> + UEFI Secure Boot ON, Kernel didn't find key-pair from shim:
>Will lock down S4 function.
>
> + UEFI Secure Boot OFF
>Will NOT do the S4 signature check.
>Ignore any keys from bootloader.
>
> v2:
> Replace sign_key_data_loaded() by skey_data_available() to check sign key data
> is available for hibernate.
>
> Reviewed-by: Jiri Kosina
> Signed-off-by: Lee, Chun-Yi
> ---
> kernel/power/hibernate.c | 36 +-
> kernel/power/main.c | 11 +-
> kernel/power/snapshot.c | 95
> ++
> kernel/power/swap.c |4 +-
> kernel/power/user.c | 11 +
> 5 files changed, 112 insertions(+), 45 deletions(-)
>
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index c545b15..0f19f3d 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
>
> #include "power.h"
>
> @@ -632,7 +633,14 @@ static void power_down(void)
> int hibernate(void)
> {
> int error;
> - int skey_error;
> +
> +#ifdef CONFIG_SNAPSHOT_VERIFICATION
> + if (!capable(CAP_COMPROMISE_KERNEL) && !skey_data_available()) {
> +#else
> + if (!capable(CAP_COMPROMISE_KERNEL)) {
> +#endif
> + return -EPERM;
> + }
>
> lock_system_sleep();
> /* The snapshot device should not be opened while we're running */
> @@ -799,6 +807,15 @@ static int software_resume(void)
> if (error)
> goto Unlock;
>
> +#ifdef CONFIG_SNAPSHOT_VERIFICATION
> + if (!capable(CAP_COMPROMISE_KERNEL) && !wkey_data_available()) {
> +#else
> + if (!capable(CAP_COMPROMISE_KERNEL)) {
> +#endif
> + mutex_unlock(_mutex);
> + return -EPERM;
> + }
> +
> /* The snapshot device should not be opened while we're running */
> if (!atomic_add_unless(_device_available, -1, 0)) {
> error = -EBUSY;
> @@ -892,6 +909,15 @@ static ssize_t disk_show(struct kobject *kobj, struct
> kobj_attribute *attr,
> int i;
> char *start = buf;
>
> +#ifdef CONFIG_SNAPSHOT_VERIFICATION
> + if (efi_enabled(EFI_SECURE_BOOT) && !skey_data_available()) {
> +#else
> + if (efi_enabled(EFI_SECURE_BOOT)) {
> +#endif
> + buf += sprintf(buf, "[%s]\n", "disabled");
> + return buf-start;
> + }
> +
> for (i = HIBERNATION_FIRST; i <= HIBERNATION_MAX; i++) {
> if (!hibernation_modes[i])
> continue;
> @@ -926,6 +952,14 @@ static ssize_t disk_store(struct kobject *kobj, struct
> kobj_attribute *attr,
> char *p;
> int mode = HIBERNATION_INVALID;
>
> +#ifdef CONFIG_SNAPSHOT_VERIFICATION
> + if (!capable(CAP_COMPROMISE_KERNEL) && !skey_data_available()) {
> +#else
> + if (!capable(CAP_COMPROMISE_KERNEL)) {
> +#endif
> + return -EPERM;
> + }
> +
> p = memchr(buf, '\n', n);
> len = p ? p - buf : n;
>
You clearly need some helper function.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/18] Hibernate: Avoid S4 sign key data included in snapshot image
On Thu 2013-08-22 19:01:52, Lee, Chun-Yi wrote: > This patch add swsusp_page_is_sign_key() method to hibernate_key.c and > check the page is S4 sign key data when collect saveable page in > snapshot.c to avoid sign key data included in snapshot image. > > Reviewed-by: Jiri Kosina > Signed-off-by: Lee, Chun-Yi > --- > kernel/power/snapshot.c |6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c > index 72e2911..9e4c94b 100644 > --- a/kernel/power/snapshot.c > +++ b/kernel/power/snapshot.c > @@ -860,6 +860,9 @@ static struct page *saveable_highmem_page(struct zone > *zone, unsigned long pfn) > > BUG_ON(!PageHighMem(page)); > > + if (swsusp_page_is_sign_key(page)) > + return NULL; > + > if (swsusp_page_is_forbidden(page) || swsusp_page_is_free(page) || > PageReserved(page)) > return NULL; Just do set_page_forbidden() on your page? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/18] Hibernate: generate and verify signature of snapshot
On Thu 2013-08-22 19:01:51, Lee, Chun-Yi wrote:
> This patch add the code for generate/verify signature of snapshot, it
> put the signature to snapshot header. This approach can support both
> on userspace hibernate and in-kernel hibernate.
>
> v2:
> - Due to loaded S4 sign key before ExitBootServices, we need forward key from
> boot kernel to resume target kernel. So this patch add a empty page in
> snapshot image, then we keep the pfn of this empty page in snapshot header.
> When system resume from hibernate, we fill new sign key to this empty page
> space after snapshot image checked pass. This mechanism let boot kernel can
> forward new sign key to resume target kernel but don't need write new
> private
> key to any other storage, e.g. swap.
>
> Cc: Matthew Garrett
> Reviewed-by: Jiri Kosina
> Signed-off-by: Lee, Chun-Yi
> ---
> kernel/power/power.h|6 +
> kernel/power/snapshot.c | 280 +-
> kernel/power/swap.c | 14 +++
> kernel/power/user.c |9 ++
> 4 files changed, 302 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/power/power.h b/kernel/power/power.h
> index 69a81d8..84e0b06 100644
> --- a/kernel/power/power.h
> +++ b/kernel/power/power.h
> @@ -3,6 +3,9 @@
> #include
> #include
>
> +/* The maximum length of snapshot signature */
> +#define SIG_LENG 512
> +
> struct swsusp_info {
> struct new_utsname uts;
> u32 version_code;
> @@ -11,6 +14,8 @@ struct swsusp_info {
> unsigned long image_pages;
> unsigned long pages;
> unsigned long size;
> + unsigned long skey_data_buf_pfn;
> + u8 signature[SIG_LENG];
> } __attribute__((aligned(PAGE_SIZE)));
SIG_LEN or SIG_LENGTH. Select one.
> +static int
> copy_data_pages(struct memory_bitmap *copy_bm, struct memory_bitmap *orig_bm)
> {
> struct zone *zone;
> - unsigned long pfn;
> + unsigned long pfn, dst_pfn;
...
> + tfm = crypto_alloc_shash(SNAPSHOT_HASH, 0, 0);
> + if (IS_ERR(tfm)) {
> + pr_err("IS_ERR(tfm): %ld", PTR_ERR(tfm));
> + return PTR_ERR(tfm);
> + }
> +
> + desc_size = crypto_shash_descsize(tfm) + sizeof(*desc);
> + digest_size = crypto_shash_digestsize(tfm);
> + digest = kzalloc(digest_size + desc_size, GFP_KERNEL);
Are you sure GFP_KERNEL allocation is okay at this phase of
hibernation?
Could the hashing be done at later phase, when writing the image to
disk?
>
> +void **h_buf;
helpfully named.
> + ret = verify_signature(s4_wake_key, pks);
> + if (ret) {
> + pr_err("snapshot S4 signature verification fail: %d\n", ret);
> + goto error_verify;
> + } else
> + pr_info("snapshot S4 signature verification pass!\n");
> +
> + if (pks->rsa.s)
> + mpi_free(pks->rsa.s);
> + kfree(pks);
ret = 0 and fall through?
> + return 0;
> +
> +error_verify:
> + if (pks->rsa.s)
> + mpi_free(pks->rsa.s);
> +error_mpi:
> + kfree(pks);
> + return ret;
> +}
> + ret = crypto_shash_final(desc, digest);
> + if (ret)
> + goto error_shash;
> +
> + ret = snapshot_verify_signature(digest, digest_size);
> + if (ret)
> + goto error_verify;
> +
> + kfree(h_buf);
> + kfree(digest);
> + crypto_free_shash(tfm);
> + return 0;
These four lines can be deleted.
> +
> +error_verify:
> +error_shash:
> + kfree(h_buf);
> + kfree(digest);
> +error_digest:
> + crypto_free_shash(tfm);
> + return ret;
> +}
> +
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/18] efi: Enable secure boot lockdown automatically when enabled in firmware
On Sun, Aug 25, 2013 at 06:22:43PM +0200, Pavel Machek wrote: > On Thu 2013-08-22 19:01:49, Lee, Chun-Yi wrote: > > From: Matthew Garrett > > > > The firmware has a set of flags that indicate whether secure boot is enabled > > and enforcing. Use them to indicate whether the kernel should lock itself > > down. We also indicate the machine is in secure boot mode by adding the > > EFI_SECURE_BOOT bit for use with efi_enabled. > > > + status = efi_call_phys5(sys_table->runtime->get_variable, > > + L"SecureBoot", _guid, NULL, , ); > > What is this L"..." thing? http://en.wikipedia.org/wiki/C_syntax#Wide_character_strings -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 11/18] Hibernate: introduced RSA key-pair to verify signature of snapshot
On Thu 2013-08-22 19:01:50, Lee, Chun-Yi wrote:
> Introduced a hibernate_key.c file to query the key pair from EFI variables
> and maintain key pair for check signature of S4 snapshot image. We
> loaded the private key when snapshot image stored success.
>
> This patch introduced 2 EFI variables for store the key to sign S4 image and
> verify signature when S4 wake up. The names and GUID are:
> S4SignKey-fe141863-c070-478e-b8a3-878a5dc9ef21
> S4WakeKey-fe141863-c070-478e-b8a3-878a5dc9ef21
>
> S4SignKey is used by EFI bootloader to pass the RSA private key that packaged
> by PKCS#8 format, kernel will read and parser it when system boot and reload
> it when S4 resume. EFI bootloader need gnerate a new private key when every
> time system boot.
>
> S4WakeKey is used to pass the RSA public key that packaged by X.509
> certificate, kernel will read and parser it for check the signature of
> S4 snapshot image when S4 resume.
>
> The follow-up patch will remove S4SignKey and S4WakeKey after load them
> to kernel for avoid anyone can access it through efivarfs.
>
> v3:
> - Load S4 sign key before ExitBootServices.
> Load private key before ExitBootServices() then bootloader doesn't need
> generate key-pair for each booting:
>+ Add setup_s4_keys() to eboot.c to load S4 sign key before
> ExitBootServices.
>+ Reserve the memory block of sign key data blob in efi.c
> - In Makefile, moved hibernate_keys.o before hibernate.o for load S4 sign
> key before check hibernate image. It makes sure the new sign key will be
> transfer to resume target kernel.
> - Set "depends on EFI_STUB" in Kconfig
>
> v2:
> Add CONFIG_SNAPSHOT_VERIFICATION for build of hibernate_keys.c depend on
> Kconfig.
>
> Cc: Matthew Garrett
> Cc: Takashi Iwai
> Reviewed-by: Jiri Kosina
> Signed-off-by: Lee, Chun-Yi
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -368,6 +368,91 @@ free_handle:
> return status;
> }
>
> +#ifdef CONFIG_SNAPSHOT_VERIFICATION
> +static efi_status_t setup_s4_keys(struct boot_params *params)
> +{
> + struct setup_data *data;
> + unsigned long datasize;
> + u32 attr;
> + struct efi_s4_key *s4key;
> + efi_status_t status;
> +
> + data = (struct setup_data *)(unsigned long)params->hdr.setup_data;
A bit too many casts.
> @@ -1205,6 +1290,10 @@ struct boot_params *efi_main(void *handle,
> efi_system_table_t *_table,
>
> setup_efi_pci(boot_params);
>
> +#ifdef CONFIG_SNAPSHOT_VERIFICATION
> + setup_s4_keys(boot_params);
> +#endif
> +
Move ifdef inside the function?
> @@ -729,6 +792,11 @@ void __init efi_init(void)
>
> set_bit(EFI_SYSTEM_TABLES, _efi_facility);
>
> +#ifdef CONFIG_SNAPSHOT_VERIFICATION
> + /* keep s4 key from setup_data */
> + efi_reserve_s4_skey_data();
> +#endif
> +
Here too.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/18] efi: Enable secure boot lockdown automatically when enabled in firmware
On Thu 2013-08-22 19:01:49, Lee, Chun-Yi wrote: > From: Matthew Garrett > > The firmware has a set of flags that indicate whether secure boot is enabled > and enforcing. Use them to indicate whether the kernel should lock itself > down. We also indicate the machine is in secure boot mode by adding the > EFI_SECURE_BOOT bit for use with efi_enabled. > + status = efi_call_phys5(sys_table->runtime->get_variable, > + L"SecureBoot", _guid, NULL, , ); What is this L"..." thing? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/18] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode
You may want to check subject. If it does something, it is not dummy.
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2784,6 +2784,13 @@ bytes respectively. Such letter suffixes can also be
> entirely omitted.
> Note: increases power consumption, thus should only be
> enabled if running jitter sensitive (HPC/RT) workloads.
>
> + secureboot_enable=
> + [KNL] Enables an emulated UEFI Secure Boot mode. This
> + locks down various aspects of the kernel guarded by the
> + CAP_COMPROMISE_KERNEL capability. This includes things
> + like /dev/mem, IO port access, and other areas. It can
> + be used on non-UEFI machines for testing purposes.
> +
> security= [SECURITY] Choose a security module to enable at boot.
> If this boot parameter is not specified, only the first
> security module asking for security registration will be
> diff --git a/kernel/cred.c b/kernel/cred.c
> index e0573a4..c3f4e3e 100644
> --- a/kernel/cred.c
> +++ b/kernel/cred.c
> @@ -565,6 +565,23 @@ void __init cred_init(void)
>0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
> }
>
> +void __init secureboot_enable()
> +{
> + pr_info("Secure boot enabled\n");
> + cap_lower((_cred)->cap_bset, CAP_COMPROMISE_KERNEL);
> + cap_lower((_cred)->cap_permitted, CAP_COMPROMISE_KERNEL);
> +}
OTOH you don't implement CAP_COMPROMISE_KERNEL, so it is dummy after
all. But CAP_COMPROMISE_KERNEL is infeasible to implement, right?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/18] Secure boot: Add new capability
On Thu 2013-08-22 19:01:47, Lee, Chun-Yi wrote:
> From: Matthew Garrett
>
> Secure boot adds certain policy requirements, including that root must not
> be able to do anything that could cause the kernel to execute arbitrary code.
> The simplest way to handle this would seem to be to add a new capability
> and gate various functionality on that. We'll then strip it from the initial
> capability set if required.
There was some discussion about this before, right? And I don't think
conclusion was it was acceptable...?
> Signed-off-by: Matthew Garrett
> Acked-by: Lee, Chun-Yi
> Signed-off-by: Lee, Chun-Yi
> ---
> include/uapi/linux/capability.h |6 +-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index ba478fa..7109e65 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -343,7 +343,11 @@ struct vfs_cap_data {
>
> #define CAP_BLOCK_SUSPEND36
>
> -#define CAP_LAST_CAP CAP_BLOCK_SUSPEND
> +/* Allow things that trivially permit root to modify the running kernel */
> +
> +#define CAP_COMPROMISE_KERNEL 37
> +
> +#define CAP_LAST_CAP CAP_COMPROMISE_KERNEL
>
> #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/18] asymmetric keys: explicitly add the leading zero byte to encoded message
On Thu 2013-08-22 19:01:46, Lee, Chun-Yi wrote: > Per PKCS1 spec, the EMSA-PKCS1-v1_5 encoded message is leading by 0x00 0x01 in > its first 2 bytes. The leading zero byte is suppressed by MPI so we pass a > pointer to the _preceding_ byte to RSA_verify() in original code, but it has > risk for the byte is not zero because it's not in EM buffer's scope, neither > RSA_verify() nor mpi_get_buffer() didn't take care the leading byte. > > To avoid the risk, that's better we explicitly add the leading zero byte to EM > for pass to RSA_verify(). This patch allocate a _EM buffer to capture the > result from RSA_I2OSP(), then set the first byte to zero in EM and copy the > remaining bytes from _EM. > > Reviewed-by: Jiri Kosina > Signed-off-by: Lee, Chun-Yi > - ret = RSA_verify(H, EM - 1, k, sig->digest_size, > + EM = kmalloc(k, GFP_KERNEL); > + memset(EM, 0, 1); > + memcpy(EM + 1, _EM, k-1); > + kfree(_EM); Spot a crash waiting to happen. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/18] asymmetric keys: support parsing PKCS #8 private key information
On Thu 2013-08-22 19:01:45, Lee, Chun-Yi wrote:
> Add ASN.1 files and parser to support parsing PKCS #8 noncompressed private
> key information. It's better than direct parsing pure private key because
> PKCS #8 has a privateKeyAlgorithm to indicate the algorithm of private
> key, e.g. RSA from PKCS #1
>
> Reviewed-by: Jiri Kosina
> Signed-off-by: Lee, Chun-Yi
> +#include
> +
> +struct pkcs8_info {
> + enum pkey_algo privkey_algo:8; /* Private key algorithm */
Are you sure this is well-defined?
> +struct private_key_algorithm *pkcs8_private_key_algorithms[PKEY_ALGO__LAST]
> = {
> + [PKEY_ALGO_DSA] = NULL,
> +#if defined(CONFIG_PUBLIC_KEY_ALGO_RSA) || \
> + defined(CONFIG_PUBLIC_KEY_ALGO_RSA_MODULE)
> + [PKEY_ALGO_RSA] = _private_key_algorithm,
> +#endif
> +};
pkey_algo
privkey_algo
private_key_algorithm
...you use all variants.
Having symbols with "__" inside them is "interesting". I'd not do it.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/18] asymmetric keys: separate the length checking of octet string from RSA_I2OSP
On Thu 2013-08-22 19:01:42, Lee, Chun-Yi wrote:
> Due to RSA_I2OSP is not only used by signature verification path but also used
> in signature generation path. So, separate the length checking of octet string
> because it's not for generate 0x00 0x01 leading string when used in signature
> generation.
>
> Reviewed-by: Jiri Kosina
> Signed-off-by: Lee, Chun-Yi
> +static int RSA_I2OSP(MPI x, size_t xLen, u8 **_X)
> +{
> + unsigned x_size;
> + unsigned X_size;
> + u8 *X = NULL;
Is this kernel code or entry into obfuscated C code contest? This is not funny.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regulator: Add devm_regulator_get_exclusive()
Add a resource managed regulator_get_exclusive()
Signed-off-by: Matthias Kaehlcke
---
drivers/regulator/core.c | 30 ++
include/linux/regulator/consumer.h |2 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 288c75a..0e8ff09 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1435,6 +1435,36 @@ static void _regulator_put(struct regulator *regulator)
}
/**
+ * devm_regulator_get_exclusive - Resource managed regulator_get_exclusive()
+ * @dev: device for regulator "consumer"
+ * @id: Supply name or regulator ID.
+ *
+ * Managed regulator_get_exclusive(). Regulators returned from this function
+ * are automatically regulator_put() on driver detach. See regulator_get() for
+ * more information.
+ */
+struct regulator *devm_regulator_get_exclusive(struct device *dev,
+ const char *id)
+{
+ struct regulator **ptr, *regulator;
+
+ ptr = devres_alloc(devm_regulator_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ regulator = _regulator_get(dev, id, 1);
+ if (!IS_ERR(regulator)) {
+ *ptr = regulator;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return regulator;
+}
+EXPORT_SYMBOL_GPL(devm_regulator_get_exclusive);
+
+/**
* regulator_put - "free" the regulator source
* @regulator: regulator source
*
diff --git a/include/linux/regulator/consumer.h
b/include/linux/regulator/consumer.h
index 3a76389..399d4a1 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -137,6 +137,8 @@ struct regulator *__must_check devm_regulator_get(struct
device *dev,
const char *id);
struct regulator *__must_check regulator_get_exclusive(struct device *dev,
const char *id);
+struct regulator *__must_check devm_regulator_get_exclusive(struct device *dev,
+ const char *id);
void regulator_put(struct regulator *regulator);
void devm_regulator_put(struct regulator *regulator);
--
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: [PATCH 02/18] asymmetric keys: implement EMSA_PKCS1-v1_5-ENCODE in rsa
On Thu 2013-08-22 19:01:41, Lee, Chun-Yi wrote:
> Implement EMSA_PKCS1-v1_5-ENCODE [RFC3447 sec 9.2] in rsa.c. It's the
> first step of signature generation operation
> (RSASSA-PKCS1-v1_5-SIGN).
Is this your own code, or did you copy it from somewhere?
> + if (!T)
> + goto error_T;
> +
> + memcpy(T, RSA_ASN1_templates[hash_algo].data,
> RSA_ASN1_templates[hash_algo].size);
> + memcpy(T + RSA_ASN1_templates[hash_algo].size, pks->digest,
> pks->digest_size);
> +
> + /* 3) check If emLen < tLen + 11, output "intended encoded message
> length too short" */
> + if (emLen < tLen + 11) {
> + ret = EINVAL;
> + goto error_emLen;
> + }
Normal kernel calling convention is 0 / -EINVAL.
> + memcpy(EM + 2, PS, emLen - tLen - 3);
> + EM[2 + emLen - tLen - 3] = 0x00;
> + memcpy(EM + 2 + emLen - tLen - 3 + 1, T, tLen);
ThisDoesNotLookLikeKernelCode, NoCamelCase, please.
> + *_EM = EM;
And we don't usually use _ prefix like this.
> --- a/include/crypto/public_key.h
> +++ b/include/crypto/public_key.h
> @@ -110,6 +110,8 @@ extern void public_key_destroy(void *payload);
> struct public_key_signature {
> u8 *digest;
> u8 digest_size; /* Number of bytes in digest */
> + u8 *S; /* signature S of length k octets */
u8 *signature?
> + size_t k; /* length k of signature S */
u8 *signature_length.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/pid/fd && anon_inode_fops
Hi Willy, On 08/24, Willy Tarreau wrote: > > On Sat, Aug 24, 2013 at 08:29:39PM +0200, Oleg Nesterov wrote: > > > > On 08/22, Willy Tarreau wrote: > > > > > > It's not only that, it also supports sockets and pipes that you can access > > > via /proc/pid/fd and not via a real symlink which would try to open eg > > > "pipe:[23456]" instead of the real file. > > > > But sock_no_open() disallows this, and for good reason I guess. > > Hmmm not exactly, it works for a pipe but not for a socket. But this is what I meant, sorry for confusion. Let me try to explain. Just in case, this has nothing to do with security and I do not see any problem, still I think there is something wrong (but harmless). Suppose that you are trying to open(/proc/pid/$pipe-or-socket-fd). nd_jump_link() sets nd->inode correctly, then dentry_open() does the rest. Everything is correct at this stage, the new file gets the correct f_inode/f_op. However, unlike fifo_open(), socket_file_ops->open() can not actually create the file/sock connection, so sock_no_open() just fails and nothing bad happens. But if you open an anon_inodefs file via proc, you get the "bogus" file. There is a single anon_inode_inode, its ->i_fop points to the empty anon_inode_fops, this has nothing to do with ->f_op of the actual file you tried to open. Nothing bad happens, still I think this is simply wrong and misleading, and thus I think it would be better to disallow this via anon_open(). Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[REGRESSION 3.11-rc] wm8775 9-001b: I2C: cannot write ??? to register R??
Booting current git kernel dmesg shows a set of new warnings: "wm8775 9-001b: I2C: cannot write ??? to register R??" Nevertheless, the hardware seems to work fine. This is a new problem, introduced after kernel 3.10. If necessary I can bisect. dmesg snippet: [ 11.841431] Linux video capture interface: v2.00 [ 11.972078] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.9 loaded [ 11.998497] cx88/0: cx2388x v4l2 driver version 0.0.9 loaded [ 12.035020] cx88[0]: subsystem: 0070:6906, board: Hauppauge WinTV-HVR4000(Lite) DVB-S/S2 [card=69,autodetected], frontend(s): 1 [ 12.227528] Adding 7119316k swap on /dev/sda3. Priority:-1 extents:1 across:7119316k SS [ 12.707144] snd_hda_intel :00:1b.0: irq 46 for MSI/MSI-X [ 12.709339] tveeprom 9-0050: Hauppauge model 69100, rev B4C3, serial# 7900937 [ 12.713245] tveeprom 9-0050: MAC address is 00:0d:fe:78:8f:09 [ 12.716836] tveeprom 9-0050: tuner model is Conexant CX24118A (idx 123, type 4) [ 12.720783] tveeprom 9-0050: TV standards ATSC/DVB Digital (eeprom 0x80) [ 12.727678] tveeprom 9-0050: audio processor is None (idx 0) [ 12.731462] tveeprom 9-0050: decoder processor is CX880 (idx 20) [ 12.736219] tveeprom 9-0050: has no radio, has IR receiver, has no IR transmitter [ 12.741662] cx88[0]: hauppauge eeprom: model=69100 [ 12.749368] ALSA sound/pci/hda/hda_auto_parser.c:393 autoconfig: line_outs=3 (0x14/0x17/0x16/0x0/0x0) type:line [ 12.749375] ALSA sound/pci/hda/hda_auto_parser.c:397 speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 12.749380] ALSA sound/pci/hda/hda_auto_parser.c:401hp_outs=1 (0x19/0x0/0x0/0x0/0x0) [ 12.749384] ALSA sound/pci/hda/hda_auto_parser.c:402mono: mono_out=0x0 [ 12.749388] ALSA sound/pci/hda/hda_auto_parser.c:405 dig-out=0x1e/0x0 [ 12.749391] ALSA sound/pci/hda/hda_auto_parser.c:406inputs: [ 12.749396] ALSA sound/pci/hda/hda_auto_parser.c:410 Rear Mic=0x18 [ 12.749400] ALSA sound/pci/hda/hda_auto_parser.c:410 Front Mic=0x1b [ 12.749404] ALSA sound/pci/hda/hda_auto_parser.c:410 Line=0x1a [ 12.749408] ALSA sound/pci/hda/patch_realtek.c:490 realtek: No valid SSID, checking pincfg 0x41f0 for NID 0x1d [ 12.749412] ALSA sound/pci/hda/patch_realtek.c:573 realtek: Enable default setup for auto mode as fallback [ 12.753148] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input5 [ 12.768712] input: HDA Intel Line Out CLFE as /devices/pci:00/:00:1b.0/sound/card0/input6 [ 12.774247] input: HDA Intel Line Out Surround as /devices/pci:00/:00:1b.0/sound/card0/input7 [ 12.778535] input: HDA Intel Line Out Front as /devices/pci:00/:00:1b.0/sound/card0/input8 [ 12.782526] input: HDA Intel Line as /devices/pci:00/:00:1b.0/sound/card0/input9 [ 12.786746] input: HDA Intel Front Mic as /devices/pci:00/:00:1b.0/sound/card0/input10 [ 12.791001] input: HDA Intel Rear Mic as /devices/pci:00/:00:1b.0/sound/card0/input11 [ 12.796098] Registered IR keymap rc-hauppauge [ 12.803188] input: cx88 IR (Hauppauge WinTV-HVR400 as /devices/pci:00/:00:1e.0/:05:05.2/rc/rc0/input12 [ 12.809256] rc0: cx88 IR (Hauppauge WinTV-HVR400 as /devices/pci:00/:00:1e.0/:05:05.2/rc/rc0 [ 12.864326] IR RC5(x) protocol handler initialized [ 12.871896] cx88[0]/2: cx2388x 8802 Driver Manager [ 12.876574] cx88[0]/2: found at :05:05.2, rev: 5, irq: 17, latency: 32, mmio: 0xd200 [ 12.881395] lirc_dev: IR Remote Control driver registered, major 250 [ 12.887849] cx88[0]/0: found at :05:05.0, rev: 5, irq: 17, latency: 32, mmio: 0xd000 [ 12.894323] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at minor = 0 [ 12.904754] IR LIRC bridge handler initialized [ 12.926877] wm8775 9-001b: chip found @ 0x36 (cx88[0]) [ 12.935488] cx88/2: cx2388x dvb driver version 0.0.9 loaded [ 12.942346] cx88/2: registering cx8802 driver, type: dvb access: shared [ 12.948247] cx88[0]/2: subsystem: 0070:6906, board: Hauppauge WinTV-HVR4000(Lite) DVB-S/S2 [card=69] [ 12.956345] cx88[0]/2: cx2388x based DVB/ATSC card [ 12.966600] cx8802_alloc_frontends() allocating 1 frontend(s) [ 12.971340] wm8775 9-001b: I2C: cannot write 000 to register R23 [ 13.001070] DVB: registering new adapter (cx88[0]) [ 13.008323] cx88-mpeg driver manager :05:05.2: DVB: registering adapter 0 frontend 0 (Conexant CX24116/CX24118)... [ 13.045893] wm8775 9-001b: I2C: cannot write 000 to register R7 [ 13.057800] wm8775 9-001b: I2C: cannot write 021 to register R11 [ 13.076171] wm8775 9-001b: I2C: cannot write 102 to register R12 [ 13.086551] wm8775 9-001b: I2C: cannot write 000 to register R13 [ 13.094695] wm8775 9-001b: I2C: cannot write 1d4 to register R14 [ 13.112437] wm8775 9-001b: I2C: cannot write 1d4 to register R15 [ 13.122719] wm8775 9-001b: I2C: cannot write 1bf to register R16 [ 13.136414] wm8775 9-001b: I2C: cannot write 185 to register R17 [
Re: [PATCH RFC 1/2] PM / Hibernate: use name_to_dev_t to parse resume
Hi!
> Use the name_to_dev_t call to parse the device name echo'd to
> to /sys/power/resume. This imitates the method used in hibernate.c
> in software_resume, and allows the resume partition to be specified
> using other equivalent device formats as well. By allowing
> /sys/debug/resume to accept the same syntax as the resume=device
> parameter, we can parse the resume=device in the init script and
> use the resume device directly from the kernel command line.
>
> Signed-off-by: Sebastian Capella
> ---
> kernel/power/hibernate.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index b26f5f1..51d4c29 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -971,15 +971,19 @@ static ssize_t resume_show(struct kobject *kobj, struct
> kobj_attribute *attr,
> static ssize_t resume_store(struct kobject *kobj, struct kobj_attribute
> *attr,
> const char *buf, size_t n)
> {
> - unsigned int maj, min;
> dev_t res;
> int ret = -EINVAL;
> + int len = n;
> + char *devcpy;
>
> - if (sscanf(buf, "%u:%u", , ) != 2)
> - goto out;
> + if (buf[len-1] == '\n')
> + len--;
> +
> + devcpy = kstrndup(buf, len, GFP_KERNEL);
> + res = name_to_dev_t(devcpy);
> + kfree(devcpy);
Is the allocation actually neccessary? At the very least this should
test for NULL...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] media: i2c: tvp7002: add OF support
Sent from my iPhone On 23 Aug 2013, at 18:25, Sylwester Nawrocki wrote: > On 08/13/2013 03:00 AM, Kumar Gala wrote: >> On Aug 11, 2013, at 1:25 AM, Lad, Prabhakar wrote: >> >>> From: "Lad, Prabhakar" >>> >>> add OF support for the tvp7002 driver. >>> >>> Signed-off-by: Lad, Prabhakar >>> --- > [...] >>> .../devicetree/bindings/media/i2c/tvp7002.txt | 53 >>> drivers/media/i2c/tvp7002.c| 67 >>> ++-- >>> 2 files changed, 113 insertions(+), 7 deletions(-) >>> create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp7002.txt >>> >>> diff --git a/Documentation/devicetree/bindings/media/i2c/tvp7002.txt >>> b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt >>> new file mode 100644 >>> index 000..5f28b5d >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt >>> @@ -0,0 +1,53 @@ >>> +* Texas Instruments TV7002 video decoder >>> + >>> +The TVP7002 device supports digitizing of video and graphics signal in RGB >>> and >>> +YPbPr color space. >>> + >>> +Required Properties : >>> +- compatible : Must be "ti,tvp7002" >>> + >>> +Optional Properties: >> >> >>> +- hsync-active: HSYNC Polarity configuration for the bus. Default value >>> when >>> + this property is not specified is <0>. >>> + >>> +- vsync-active: VSYNC Polarity configuration for the bus. Default value >>> when >>> + this property is not specified is <0>. >>> + >>> +- pclk-sample: Clock polarity of the bus. Default value when this property >>> is >>> + not specified is <0>. >>> + >>> +- sync-on-green-active: Active state of Sync-on-green signal property of >>> the >>> + endpoint. >>> + 0 = Normal Operation (Active Low, Default) >>> + 1 = Inverted operation >> >> These seems better than what you have in video-interfaces.txt > > We probably should specify default values in in the common binding > description. > Then duplication could be avoided. Not sure if it's not too late for this, all > drivers would need to have same default values. > > What's normal and what's inverted depends on a particular device. > >>> +- field-even-active: Active-high Field ID output polarity control of the >>> bus. >>> + Under normal operation, the field ID output is set to logic 1 for an odd >>> field >>> + (field 1) and set to logic 0 for an even field (field 0). >>> + 0 = Normal Operation (Active Low, Default) >>> + 1 = FID output polarity inverted >>> + >> >> Why the duplication if this is covered in video-interfaces.txt? > > Yes, it would be better to avoid redefining these properties in each specific > device's binding. Presumably, for easier matching of DT properties with the > hardware's description, we could only say in device specific document which > value of a property corresponds to "normal" and which to "inverted" operation > ? > >>> +For further reading of port node refer >>> Documentation/devicetree/bindings/media/ >>> +video-interfaces.txt. > > -- > Sylwester Nawrocki > Samsung R Institute Poland > ___ > Davinci-linux-open-source mailing list > davinci-linux-open-sou...@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ppc: kvm: use anon_inode_getfd() with O_CLOEXEC flag
On 24.08.2013, at 21:14, Yann Droneaud wrote: > KVM uses anon_inode_get() to allocate file descriptors as part > of some of its ioctls. But those ioctls are lacking a flag argument > allowing userspace to choose options for the newly opened file descriptor. > > In such case it's advised to use O_CLOEXEC by default so that > userspace is allowed to choose, without race, if the file descriptor > is going to be inherited across exec(). > > This patch set O_CLOEXEC flag on all file descriptors created > with anon_inode_getfd() to not leak file descriptors across exec(). > > Signed-off-by: Yann Droneaud > Link: http://lkml.kernel.org/r/cover.1377372576.git.ydrone...@opteya.com Reviewed-by: Alexander Graf Would it make sense to simply inherit the O_CLOEXEC flag from the parent kvm fd instead? That would give user space the power to keep fds across exec() if it wants to. Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Asus F5RL laptop unable to resume from S3 because of radeon module
> -Original Message-
> From: Ondrej Zary [mailto:li...@rainbow-software.org]
> Sent: Friday, August 23, 2013 1:55 PM
> To: Deucher, Alexander
> Cc: Kernel development list
> Subject: Re: Asus F5RL laptop unable to resume from S3 because of radeon
> module
>
> On Friday 23 August 2013 00:08:33 Ondrej Zary wrote:
> > On Thursday 22 August 2013 22:56:03 Ondrej Zary wrote:
> > > On Thursday 22 August 2013 22:24:17 Deucher, Alexander wrote:
> > > > > -Original Message-
> > > > > From: Ondrej Zary [mailto:li...@rainbow-software.org]
> > > > > Sent: Thursday, August 22, 2013 4:00 PM
> > > > > To: Deucher, Alexander
> > > > > Cc: Kernel development list
> > > > > Subject: Re: Asus F5RL laptop unable to resume from S3 because of
> > > > > radeon module
> > > > >
> > > > > On Thursday 22 August 2013 21:49:41 Deucher, Alexander wrote:
> > > > > > > -Original Message-
> > > > > > > From: Ondrej Zary [mailto:li...@rainbow-software.org]
> > > > > > > Sent: Thursday, August 22, 2013 2:18 PM
> > > > > > > To: Kernel development list
> > > > > > > Cc: Deucher, Alexander
> > > > > > > Subject: Asus F5RL laptop unable to resume from S3 because of
> > > > > > > radeon module
> > > > > > >
> > > > > > > Hello,
> > > > > > > resume from suspend-to-RAM (S3) on Asus F5RL laptop does not
> > > > > > > work. According to many reports found by Google, it was always
> > > > > > > been that and there
> > > > > > > is no fix or workaround.
> > > > > >
> > > > > > Make sure your kernel has this patch:
> > > > > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/comm
> > > > > >it /? id=c ef1d00cd56f600121ad121875655ad410a001b8
> > > > >
> > > > > Just tried latest git (3.11-rc6+) and the problem persists.
> > > >
> > > > You might try adding a quirk for your system in
> > > > radeon_combios_asic_init() in radeon_combios.c. You can try
> something
> > > > like this for testing:
> > > >
> > > > diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
> > > > b/drivers/gpu/drm/radeon/radeon_combios.c index 68ce360..0419a2c
> 100644
> > > > --- a/drivers/gpu/drm/radeon/radeon_combios.c
> > > > +++ b/drivers/gpu/drm/radeon/radeon_combios.c
> > > > @@ -3398,6 +3398,8 @@ void radeon_combios_asic_init(struct
> drm_device
> > > > *dev) rdev->pdev->subsystem_device == 0x30ae)
> > > > return;
> > > >
> > > > + return;
> > > > +
> > > > /* DYN CLK 1 */
> > > > table = combios_get_table_offset(dev,
> COMBIOS_DYN_CLK_1_TABLE);
> > > > if (table)
> > > >
> > > > If that doesn't work, you'll probably have to track down where it's
> > > > hanging during resume, or compare registers before and after resume
> to
> > > > see if it's some particular state that's causing a problem.
> > >
> > > No change.
> > >
> > > Inserted "return -1;" before radeon_device_init() to
> > > radeon_driver_load_kms() - driver fails to load and resume works.
> > > Moved it (and changed to "r = -1; goto out;") a bit down before
> > > radeon_modeset_init() - driver fails to load and resume stopped
> working.
> >
> > Going deeper... it works before rs400_startup() and does not work after
> > that. Will continue later.
>
> Tracked the problem down to rs400_gart_enable(). When this "Disable AGP
> mode"
> code is commented out, the machine resumes fine:
>
> if ((rdev->family == CHIP_RS690) || (rdev->family == CHIP_RS740)) {
> WREG32_MC(RS480_MC_MISC_CNTL,
> (RS480_GART_INDEX_REG_EN | RS690_BLOCK_GFX_D3_EN));
> } else {
> WREG32_MC(RS480_MC_MISC_CNTL, RS480_GART_INDEX_REG_EN);
> }
>
Does the driver work properly after resume with that part commented out or does
it just avoid the hang?
Alex
>
> > > > Alex
> > > >
> > > > > > Alex
> > > > > >
> > > > > > > Did some tests:
> > > > > > >
> > > > > > > radeon module loaded (usual state):
> > > > > > > After "echo mem>/sys/power/state", the laptop suspends
> correctly
> > > > >
> > > > > (power
> > > > >
> > > > > > > LED
> > > > > > > blinks). When power button is pressed, power LED goes on and
> > > > > > > that's all. No more activity, machine is frozen completely.
> > > > > > >
> > > > > > > radeon module not loaded at all:
> > > > > > > Laptop resumes correctly (keyboard LED work, network works),
> only
> > > > > > > the
> > > > >
> > > > > LCD
> > > > >
> > > > > > > is
> > > > > > > blank (obviously). Loading radeon module now initializes the card
> > > > > > > properly: LCD goes on and console works.
> > > > > > >
> > > > > > > radeon module loaded (but fbcon module not loaded) and then
> > > > >
> > > > > unloaded:
> > > > > > > Machine freezes the same way as when the module is loaded.
> > > > > > >
> > > > > > > So it looks like the radeon module does some initialization that
> > > > > > > prevents resume from working.
> > > > > > >
> > > > > > > Hibernation works fine.
> > > > > > >
> > > > > > > Any ideas what to test or how to debug this?
> > > > > > >
> > > > >
Re: [PATCH v2] vfs: Tighten up linkat(..., AT_EMPTY_PATH)
On Sun, Aug 25, 2013 at 12:26:34AM -0700, Andy Lutomirski wrote: > I think this is more screwed up than just flink and open. For example: > > $ echo 'WTF' >test > $ truncate -s 1 /proc/self/fd/3 3 $ cat test > W$ > > IMO that should have failed. Why? truncate() always follows links, so what's the problem with that one? That you get checks of truncate() and not ftruncate()? > In an ideal world (I think) ffrob(N), frobat(N, "", AT_EMPTY_PATH), > and frobat(AT_FDCWD, "/proc/self/fd/N) should generally do the same > thing. What about the cases where frob() and ffrob() check for different things? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Documentation/trace: Correcting and extending tracepoint documentation
On 08/22/2013 04:49:31 PM, Zoltan Kiss wrote: The sample missed the moving of the header files into the events subdirectory. I've also extended it based on the existing headers, and mentioned the tiny but important role of CREATE_TRACE_POINTS. Signed-off-by: Zoltan Kiss --- Documentation/trace/tracepoints.txt | 19 +-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/Documentation/trace/tracepoints.txt b/Documentation/trace/tracepoints.txt index da49437..e8e3c4b 100644 --- a/Documentation/trace/tracepoints.txt +++ b/Documentation/trace/tracepoints.txt @@ -40,7 +40,13 @@ Two elements are required for tracepoints : In order to use tracepoints, you should include linux/tracepoint.h. -In include/trace/subsys.h : +In include/trace/events/subsys.h : + +#undef TRACE_SYSTEM +#define TRACE_SYSTEM subsys That addition I can sort of see, I guess? +#if !defined(_TRACE_SUBSYS_H) || defined(TRACE_HEADER_MULTI_READ) +#define _TRACE_SUBSYS_H But this makes no sense to me: why is it needed? (I.E. why must it be block copied into each _user_ of tracepoints?) #include @@ -48,10 +54,16 @@ DECLARE_TRACE(subsys_eventname, TP_PROTO(int firstarg, struct task_struct *p), TP_ARGS(firstarg, p)); +#endif /* _TRACE_SUBSYS_H */ + +/* This part must be outside protection */ +#include + Why? (Both why do you need to #include a header outside a multiple inclusion guard, and why is the additional header needed at all in _every_ subsystem trace header?) In subsys/file.c (where the tracing statement must be added) : -#include +#include +#define CREATE_TRACE_POINTS DEFINE_TRACE(subsys_eventname); void somefct(void) @@ -72,6 +84,9 @@ Where : - TP_ARGS(firstarg, p) are the parameters names, same as found in the prototype. +- if you use the header in multiple source files, #define CREATE_TRACE_POINTS + should appear only in one source file + Connecting a function (probe) to a tracepoint is done by providing a probe (function to call) for the specific tracepoint through register_trace_subsys_eventname(). Removing a probe is done through I guess the documentation isn't at fault if the tracepoint subsystem is suddenly becoming a lot more repetitive and complicated for no readily apparent reason, but did anybody ask _why_ this thing changed? Can we document why the extra redundancy is needed? Rob-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V12 3/5] kvm : Fold pv_unhalt flag into GET_MP_STATE ioctl to aid migration
On Wed, Aug 07, 2013 at 12:40:36AM +0530, Raghavendra K T wrote: > On 08/07/2013 12:02 AM, Eric Northup wrote: > > > >If this is about migration correctness, could it get folded into the > >previous patch 2/5, so that there's not a broken commit which could > >hurt bisection? > > Yes. It could be. Only reason I maintained like that was, > original author in the previous patch is different (Srivatsa) and I did > not want to merge this hunk when the patch series got evolved to mix > the sign-offs. > > Gleb, Paolo please let me know. > Yes please, do so. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Vážení E-mail užívateľa;
Vážení E-mail užívateľa; Prekročili ste 23432 boxy nastaviť svoje Webová služba / Administrátor, a budete mať problémy pri odosielaní a prijímať e-maily, kým znova overiť. Musíte aktualizovať kliknutím na odkaz nižšie a vyplňte údaje pre overenie vášho účtu Prosím, kliknite na odkaz nižšie alebo skopírovať vložiť do e-prehliadač pre overenie Schránky. http://webmailupdate3023432.jimdo.com/ Pozor! Ak tak neurobíte, budú mať obmedzený prístup k e-mailu schránky. Ak sa nepodarí aktualizovať svoj účet do troch dní od aktualizácie oznámenia, bude váš účet natrvalo uzavretá. S pozdravom, System Administrator ® -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] zswap bugfix: memory leaks when re-swapon
2013/8/23 Seth Jennings :
> On Fri, Aug 23, 2013 at 07:03:37PM +0800, Weijie Yang wrote:
>> zswap_tree is not freed when swapoff, and it got re-kzalloc in swapon,
>> memory leak occurs.
>> Add check statement in zswap_frontswap_init so that zswap_tree is
>> inited only once.
>>
>> ---
>> mm/zswap.c |5 +
>> 1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/mm/zswap.c b/mm/zswap.c
>> index deda2b6..1cf1c07 100644
>> --- a/mm/zswap.c
>> +++ b/mm/zswap.c
>> @@ -826,6 +826,11 @@ static void zswap_frontswap_init(unsigned type)
>> {
>> struct zswap_tree *tree;
>>
>> + if (zswap_trees[type]) {
>> + BUG_ON(zswap_trees[type]->rbroot != RB_ROOT); /*
>> invalidate_area set it */
>
> Lets leave this BUG_ON() out. If we want to make sure that the rbtree has
> been properly emptied out, we should do it in
> zswap_frontswap_invalidate_area() after the while loop and make it a
> WARN_ON() since the problem is not fatal.
>
> Seth
>
ok.
>> + return;
>> + }
>> +
>> tree = kzalloc(sizeof(struct zswap_tree), GFP_KERNEL);
>> if (!tree)
>> goto err;
>> --
>> 1.7.0.4
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] acpi-dma, doc: append managed function to the list
On Wed, Aug 21, 2013 at 02:27:05PM +0300, Andy Shevchenko wrote: > ACPI DMA provides managed function to register the slave DMA controller in the > internal container. This patch anounces that function in the corresponding > documentation file. Applied, thanks ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] vhost_net: remove the max pending check
On Fri, Aug 23, 2013 at 04:55:49PM +0800, Jason Wang wrote: > On 08/20/2013 10:48 AM, Jason Wang wrote: > > On 08/16/2013 06:02 PM, Michael S. Tsirkin wrote: > >> > On Fri, Aug 16, 2013 at 01:16:30PM +0800, Jason Wang wrote: > >>> >> We used to limit the max pending DMAs to prevent guest from pinning > >>> >> too many > >>> >> pages. But this could be removed since: > >>> >> > >>> >> - We have the sk_wmem_alloc check in both tun/macvtap to do the same > >>> >> work > >>> >> - This max pending check were almost useless since it was one done > >>> >> when there's > >>> >> no new buffers coming from guest. Guest can easily exceeds the > >>> >> limitation. > >>> >> - We've already check upend_idx != done_idx and switch to non zerocopy > >>> >> then. So > >>> >> even if all vq->heads were used, we can still does the packet > >>> >> transmission. > >> > We can but performance will suffer. > > The check were in fact only done when no new buffers submitted from > > guest. So if guest keep sending, the check won't be done. > > > > If we really want to do this, we should do it unconditionally. Anyway, I > > will do test to see the result. > > There's a bug in PATCH 5/6, the check: > > nvq->upend_idx != nvq->done_idx > > makes the zerocopy always been disabled since we initialize both > upend_idx and done_idx to zero. So I change it to: > > (nvq->upend_idx + 1) % UIO_MAXIOV != nvq->done_idx. But what I would really like to try is limit ubuf_info to VHOST_MAX_PEND. I think this has a chance to improve performance since we'll be using less cache. Of course this means we must fix the code to really never submit more than VHOST_MAX_PEND requests. Want to try? > > With this change on top, I didn't see performance difference w/ and w/o > this patch. Did you try small message sizes btw (like 1K)? Or just netperf default of 64K? -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] vhost_net: use vhost_add_used_and_signal_n() in vhost_zerocopy_signal_used()
On Fri, Aug 23, 2013 at 04:50:38PM +0800, Jason Wang wrote: > On 08/20/2013 10:33 AM, Jason Wang wrote: > > On 08/16/2013 05:54 PM, Michael S. Tsirkin wrote: > >> On Fri, Aug 16, 2013 at 01:16:26PM +0800, Jason Wang wrote: > Switch to use vhost_add_used_and_signal_n() to avoid multiple calls to > vhost_add_used_and_signal(). With the patch we will call at most 2 times > (consider done_idx warp around) compared to N times w/o this patch. > > Signed-off-by: Jason Wang > >> So? Does this help performance then? > >> > > Looks like it can especially when guest does support event index. When > > guest enable tx interrupt, this can saves us some unnecessary signal to > > guest. I will do some test. > > Have done some test. I can see 2% - 3% increasing in both aggregate > transaction rate and per cpu transaction rate in TCP_RR and UDP_RR test. > > I'm using ixgbe. W/o this patch, I can see more than 100 calls of > vhost_add_used_signal() in one vhost_zerocopy_signaled_used(). This is > because ixgbe (and other modern ethernet driver) tends to free old tx > skbs in a loop during tx interrupt, and vhost tend to batch the adding > used and signal in vhost_zerocopy_callback(). Switching to use > vhost_add_use_and_signal_n() means saving 100 times of used idx updating > and memory barriers. Well it's only smp_wmb so a nop on most architectures, so a 2% gain is surprising. I'm guessing the cache miss on the write is what's giving us a speedup here. I'll review the code, thanks. -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dma: ste_dma: Fix warning when CONFIG_ARM_LPAE=y
On Wed, Aug 21, 2013 at 09:34:02PM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > When CONFIG_ARM_LPAE=y the following build warning are generated: > > drivers/dma/ste_dma40.c:3228:2: warning: format '%x' expects argument of type > 'unsigned int', but argument 4 has type 'resource_size_t' [-Wformat] > drivers/dma/ste_dma40.c:3582:3: warning: format '%x' expects argument of type > 'unsigned int', but argument 4 has type 'resource_size_t' [-Wformat] > drivers/dma/ste_dma40.c:3582:3: warning: format '%x' expects argument of type > 'unsigned int', but argument 5 has type 'resource_size_t' [-Wformat] > drivers/dma/ste_dma40.c:3593:5: warning: format '%x' expects argument of type > 'unsigned int', but argument 5 has type 'resource_size_t' [-Wformat] > > According to Documentation/printk-formats.txt '%pa' can be used to properly > print 'resource_size_t'. > > Also, for printing memory region the '%pr' is more convenient. Applied, Thanks ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma/Kconfig: TI_EDMA needs to be boolean
On Thu, Aug 22, 2013 at 02:03:24PM -0700, Guenter Roeck wrote: > Fix: > > arch/arm/common/built-in.o: undefined reference to `edma_filter_fn' > > seen with "make ARCH=arm allmodconfig" > > Commit 6cba4355 (ARM: edma: Add DT and runtime PM support to the private EDMA > API) adds a dependency on edma_filter_fn() into arch/arm/common/edma.c. Since > this file is always built into the kernel, edma_filter_fn() must be built into > the kernel as well. Applied, thanks ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ath5k: debugfs: NULL-terminate strings
Avoid processing garbage data by NULL terminating the strings.
Signed-off-by: Djalal Harouni
---
Patch compile tested only.
drivers/net/wireless/ath/ath5k/debug.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/debug.c
b/drivers/net/wireless/ath/ath5k/debug.c
index 9d00dab..b8d031a 100644
--- a/drivers/net/wireless/ath/ath5k/debug.c
+++ b/drivers/net/wireless/ath/ath5k/debug.c
@@ -245,9 +245,11 @@ static ssize_t write_file_beacon(struct file *file,
struct ath5k_hw *ah = file->private_data;
char buf[20];
- if (copy_from_user(buf, userbuf, min(count, sizeof(buf
+ count = min_t(size_t, count, sizeof(buf) - 1);
+ if (copy_from_user(buf, userbuf, count))
return -EFAULT;
+ buf[count] = '\0';
if (strncmp(buf, "disable", 7) == 0) {
AR5K_REG_DISABLE_BITS(ah, AR5K_BEACON, AR5K_BEACON_ENABLE);
pr_info("debugfs disable beacons\n");
@@ -345,9 +347,11 @@ static ssize_t write_file_debug(struct file *file,
unsigned int i;
char buf[20];
- if (copy_from_user(buf, userbuf, min(count, sizeof(buf
+ count = min_t(size_t, count, sizeof(buf) - 1);
+ if (copy_from_user(buf, userbuf, count))
return -EFAULT;
+ buf[count] = '\0';
for (i = 0; i < ARRAY_SIZE(dbg_info); i++) {
if (strncmp(buf, dbg_info[i].name,
strlen(dbg_info[i].name)) == 0) {
@@ -448,9 +452,11 @@ static ssize_t write_file_antenna(struct file *file,
unsigned int i;
char buf[20];
- if (copy_from_user(buf, userbuf, min(count, sizeof(buf
+ count = min_t(size_t, count, sizeof(buf) - 1);
+ if (copy_from_user(buf, userbuf, count))
return -EFAULT;
+ buf[count] = '\0';
if (strncmp(buf, "diversity", 9) == 0) {
ath5k_hw_set_antenna_mode(ah, AR5K_ANTMODE_DEFAULT);
pr_info("debug: enable diversity\n");
@@ -619,9 +625,11 @@ static ssize_t write_file_frameerrors(struct file *file,
struct ath5k_statistics *st = >stats;
char buf[20];
- if (copy_from_user(buf, userbuf, min(count, sizeof(buf
+ count = min_t(size_t, count, sizeof(buf) - 1);
+ if (copy_from_user(buf, userbuf, count))
return -EFAULT;
+ buf[count] = '\0';
if (strncmp(buf, "clear", 5) == 0) {
st->rxerr_crc = 0;
st->rxerr_phy = 0;
@@ -766,9 +774,11 @@ static ssize_t write_file_ani(struct file *file,
struct ath5k_hw *ah = file->private_data;
char buf[20];
- if (copy_from_user(buf, userbuf, min(count, sizeof(buf
+ count = min_t(size_t, count, sizeof(buf) - 1);
+ if (copy_from_user(buf, userbuf, count))
return -EFAULT;
+ buf[count] = '\0';
if (strncmp(buf, "sens-low", 8) == 0) {
ath5k_ani_init(ah, ATH5K_ANI_MODE_MANUAL_HIGH);
} else if (strncmp(buf, "sens-high", 9) == 0) {
@@ -862,9 +872,11 @@ static ssize_t write_file_queue(struct file *file,
struct ath5k_hw *ah = file->private_data;
char buf[20];
- if (copy_from_user(buf, userbuf, min(count, sizeof(buf
+ count = min_t(size_t, count, sizeof(buf) - 1);
+ if (copy_from_user(buf, userbuf, count))
return -EFAULT;
+ buf[count] = '\0';
if (strncmp(buf, "start", 5) == 0)
ieee80211_wake_queues(ah->hw);
else if (strncmp(buf, "stop", 4) == 0)
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] scsi: ufs: read door bell register after clearing interrupt aggregation
In interrupt context, after reading and comparing the UTRLDBR to
hba->outstanding_request and before resetting the interrupt aggregation,
there might be completion of another transfer request (TR). Such TRs might
get stuck, pending, until the next interrupt is generated.
The fix reads the UTRLDBR after resetting the interrupt aggregation and
handles completed TRs.
Signed-off-by: Dolev Raviv
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 4dca9b4..30c84d8 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1915,6 +1915,13 @@ static void ufshcd_uic_cmd_compl(struct ufs_hba *hba)
/**
* ufshcd_transfer_req_compl - handle SCSI and query command completion
* @hba: per adapter instance
+ *
+ * Resetting interrupt aggregation counters first and reading the DOOR_BELL
+ * afterward , allows us to handle all the completed requests.
+ * In order to prevent other interrupts starvation the DB is read once
+ * after reset. The down side of this solution is the possibility of false
+ * interrupt if device completes another request after resetting aggregation
+ * and before reading the DB.
*/
static void ufshcd_transfer_req_compl(struct ufs_hba *hba)
{
@@ -1924,47 +1931,36 @@ static void ufshcd_transfer_req_compl(struct ufs_hba
*hba)
u32 tr_doorbell;
int result;
int index;
- bool int_aggr_reset = false;
+
+ /* Reset interrupt aggregation counters */
+ ufshcd_config_int_aggr(hba, INT_AGGR_RESET);
tr_doorbell = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
completed_reqs = tr_doorbell ^ hba->outstanding_reqs;
- for (index = 0; index < hba->nutrs; index++) {
- if (test_bit(index, _reqs)) {
- lrbp = >lrb[index];
- cmd = lrbp->cmd;
- /*
-* Don't skip resetting interrupt aggregation counters
-* if a regular command is present.
-*/
- int_aggr_reset |= !lrbp->intr_cmd;
-
- if (cmd) {
- result = ufshcd_transfer_rsp_status(hba, lrbp);
- scsi_dma_unmap(cmd);
- cmd->result = result;
- /* Mark completed command as NULL in LRB */
- lrbp->cmd = NULL;
- clear_bit_unlock(index, >lrb_in_use);
- /* Do not touch lrbp after scsi done */
- cmd->scsi_done(cmd);
- } else if (lrbp->command_type ==
- UTP_CMD_TYPE_DEV_MANAGE) {
- if (hba->dev_cmd.complete)
- complete(hba->dev_cmd.complete);
- }
- } /* end of if */
- } /* end of for */
+ for_each_set_bit(index, _reqs, hba->nutrs) {
+ lrbp = >lrb[index];
+ cmd = lrbp->cmd;
+ if (cmd) {
+ result = ufshcd_transfer_rsp_status(hba, lrbp);
+ scsi_dma_unmap(cmd);
+ cmd->result = result;
+ /* Mark completed command as NULL in LRB */
+ lrbp->cmd = NULL;
+ clear_bit_unlock(index, >lrb_in_use);
+ /* Do not touch lrbp after scsi done */
+ cmd->scsi_done(cmd);
+ } else if (lrbp->command_type == UTP_CMD_TYPE_DEV_MANAGE) {
+ if (hba->dev_cmd.complete)
+ complete(hba->dev_cmd.complete);
+ }
+ } /* end of for_each_set_bit */
/* clear corresponding bits of completed commands */
hba->outstanding_reqs ^= completed_reqs;
/* we might have free'd some tags above */
wake_up(>dev_cmd.tag_wq);
-
- /* Reset interrupt aggregation counters */
- if (int_aggr_reset)
- ufshcd_config_int_aggr(hba, INT_AGGR_RESET);
}
/**
@@ -2569,6 +2565,7 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
int poll_cnt;
u8 resp = 0xF;
struct ufshcd_lrb *lrbp;
+ u32 reg;
host = cmd->device->host;
hba = shost_priv(host);
@@ -2578,6 +2575,13 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
if (!(test_bit(tag, >outstanding_reqs)))
goto out;
+ reg = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
+ if (!(reg & (1 << tag))) {
+ dev_err(hba->dev,
+ "%s: cmd was completed, but without a notifying intr, tag = %d",
+ __func__, tag);
+ }
+
lrbp = >lrb[tag];
for (poll_cnt = 100; poll_cnt; poll_cnt--) {
err = ufshcd_issue_tm_cmd(hba, lrbp->lun, lrbp->task_tag,
@@ -2586,8 +2590,6 @@ static int
Re: [PATCH 1/2] gpio: mcp23s08: rename the device tree property
Am Freitag 23 August 2013, 21:10:00 schrieb Linus Walleij: > On Thu, Aug 22, 2013 at 11:56 AM, Lars Poeschel wrote: > > From: Lars Poeschel > > > > The device tree property should be more descriptive. > > microchip seems more reasonable than mcp. As there are no > > in tree users of this property, so the rename can still be > > done without pain. > > > > Signed-off-by: Lars Poeschel > > So do I apply this to the GPIO tree now or what? > > Are the DT custodians happy? No Linus, do not take this. There will be a new version. Thanks, Lars -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] um: prctl: Do not include linux/ptrace.h
Tested-by: David Oberhollenzer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dma: ipu: remove unnecessary platform_set_drvdata()
On Wed, Aug 21, 2013 at 06:52:54PM +0900, Jingoo Han wrote: > The driver core clears the driver data to NULL after device_release > or on probe failure. Thus, it is not needed to manually clear the > device driver data to NULL. Applied, thanks ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[3.10][PATCH 0/4] resume reset fixes for stable 3.10
Tomas Winkler (4): mei: me: fix reset state machine mei: don't have to clean the state on power up mei: me: fix waiting for hw ready mei: me: fix hardware reset flow drivers/misc/mei/hw-me.c | 22 +- drivers/misc/mei/init.c | 3 ++- 2 files changed, 15 insertions(+), 10 deletions(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[3.10][PATCH 4/4] mei: me: fix hardware reset flow
stable: 3.10 commit ff96066e3171acdea356b331163495957cb833d0 char-misc Both H_IS and H_IE needs to be set to receive H_RDY interrupt 1. Assert H_IS to clear the interrupts during hw reset and use mei_me_reg_write instead of mei_hcsr_set as the later strips down the H_IS 2. fix interrupt disablement embarrassing typo hcsr |= ~H_IE -> hcsr &= ~H_IE; this will remove the unwanted interrupt on power down 3. remove useless debug print outs Cc: sta...@vger.kernel.org Cc: Shuah Khan Cc: Konstantin Khlebnikov Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman Conflicts: drivers/misc/mei/hw-me.c --- drivers/misc/mei/hw-me.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c index 700fe55..1bf3f8b 100644 --- a/drivers/misc/mei/hw-me.c +++ b/drivers/misc/mei/hw-me.c @@ -176,16 +176,14 @@ static void mei_me_hw_reset(struct mei_device *dev, bool intr_enable) struct mei_me_hw *hw = to_me_hw(dev); u32 hcsr = mei_hcsr_read(hw); - dev_dbg(>pdev->dev, "before reset HCSR = 0x%08x.\n", hcsr); - - hcsr |= (H_RST | H_IG); + hcsr |= H_RST | H_IG | H_IS; if (intr_enable) hcsr |= H_IE; else - hcsr |= ~H_IE; + hcsr &= ~H_IE; - mei_hcsr_set(hw, hcsr); + mei_me_reg_write(hw, H_CSR, hcsr); if (dev->dev_state == MEI_DEV_POWER_DOWN) mei_me_hw_reset_release(dev); -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[3.10][PATCH 1/4] mei: me: fix reset state machine
stable: 3.10
commit 315a383ad7dbd484fafb93ef08038e3dbafbb7a8 upstream
ME HW ready bit is down after hw reset was asserted or on error.
Only on error we need to enter the reset flow, additional reset
need to be prevented when reset was triggered during
initialization , power up/down or a reset is already in progress
Cc: sta...@vger.kernel.org
Tested-by: Shuah Khan
Signed-off-by: Tomas Winkler
Signed-off-by: Greg Kroah-Hartman
---
drivers/misc/mei/hw-me.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 822170f..0310859 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -482,7 +482,9 @@ irqreturn_t mei_me_irq_thread_handler(int irq, void *dev_id)
/* check if ME wants a reset */
if (!mei_hw_is_ready(dev) &&
dev->dev_state != MEI_DEV_RESETTING &&
- dev->dev_state != MEI_DEV_INITIALIZING) {
+ dev->dev_state != MEI_DEV_INITIALIZING &&
+ dev->dev_state != MEI_DEV_POWER_DOWN &&
+ dev->dev_state != MEI_DEV_POWER_UP) {
dev_dbg(>pdev->dev, "FW not ready.\n");
mei_reset(dev, 1);
mutex_unlock(>device_lock);
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[3.10][PATCH 2/4] mei: don't have to clean the state on power up
stable: 3.10
commit 99f22c4ef24cf87b0dae6aabe6b5e620b62961d9 upstream
When powering up, we don't have to clean up the device state
nothing is connected.
Cc: sta...@vger.kernel.org
Tested-by: Shuah Khan
Signed-off-by: Tomas Winkler
Signed-off-by: Greg Kroah-Hartman
---
drivers/misc/mei/init.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c
index f580d30..6eec689 100644
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@ -143,7 +143,8 @@ void mei_reset(struct mei_device *dev, int
interrupts_enabled)
dev->hbm_state = MEI_HBM_IDLE;
- if (dev->dev_state != MEI_DEV_INITIALIZING) {
+ if (dev->dev_state != MEI_DEV_INITIALIZING &&
+ dev->dev_state != MEI_DEV_POWER_UP) {
if (dev->dev_state != MEI_DEV_DISABLED &&
dev->dev_state != MEI_DEV_POWER_DOWN)
dev->dev_state = MEI_DEV_RESETTING;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[3.10][PATCH 3/4] mei: me: fix waiting for hw ready
stable: 3.10
commit dab9bf41b23fe700c4a74133e41eb6a21706031e upstream
1. MEI_INTEROP_TIMEOUT is in seconds not in jiffies
so we use mei_secs_to_jiffies macro
While cold boot is fast this is relevant in resume
2. wait_event_interruptible_timeout can return with
-ERESTARTSYS so do not override it with -ETIMEDOUT
3.Adjust error message
Cc: sta...@vger.kernel.org
Tested-by: Shuah Khan
Signed-off-by: Tomas Winkler
Signed-off-by: Greg Kroah-Hartman
---
drivers/misc/mei/hw-me.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 0310859..700fe55 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -238,14 +238,18 @@ static int mei_me_hw_ready_wait(struct mei_device *dev)
if (mei_me_hw_is_ready(dev))
return 0;
+ dev->recvd_hw_ready = false;
mutex_unlock(>device_lock);
err = wait_event_interruptible_timeout(dev->wait_hw_ready,
- dev->recvd_hw_ready, MEI_INTEROP_TIMEOUT);
+ dev->recvd_hw_ready,
+ mei_secs_to_jiffies(MEI_INTEROP_TIMEOUT));
mutex_lock(>device_lock);
if (!err && !dev->recvd_hw_ready) {
+ if (!err)
+ err = -ETIMEDOUT;
dev_err(>pdev->dev,
- "wait hw ready failed. status = 0x%x\n", err);
- return -ETIMEDOUT;
+ "wait hw ready failed. status = %d\n", err);
+ return err;
}
dev->recvd_hw_ready = false;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: sh: remove unnecessary platform_set_drvdata()
On Wed, Aug 21, 2013 at 06:51:56PM +0900, Jingoo Han wrote: > The driver core clears the driver data to NULL after device_release > or on probe failure. Thus, it is not needed to manually clear the > device driver data to NULL. Can you pls rebase this as resend. I have applied bunch of sh-dma patches and this doenst apply for me ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tps_init] BUG: unable to handle kernel paging request at 484970c9
On Sat, Aug 24, 2013 at 09:09:39PM -0700, Greg Kroah-Hartman wrote:
> Same as before, are you unloading and loading modules? We have a fix
> for modules that cause problems when unloading with the config option
> above enabled. But that shouldn't be this issue.
What seems to be is going on here is that something creates a kobject,
which gets exported into sysfs, then removed and then immediately
recreated.
It appears that sysfs entries are deleted in the cleanup function:
static void kobject_cleanup(struct kobject *kobj)
{
...
/* remove from sysfs if the caller did not do it */
if (kobj->state_in_sysfs) {
pr_debug("kobject: '%s' (%p): auto cleanup kobject_del\n",
kobject_name(kobj), kobj);
kobject_del(kobj);
}
which is now delayed. I don't think this is specifically a problem of
my patch - I think my patch is revealing a problem here.
Let's take it from the point of view of a struct device. Lets say that
a device with name "foo" gets created. This creates a sysfs directory
entry called "foo". Various things take a reference on the device.
You then unregister that struct device because it's been removed. As
all the references haven't yet been released, it means that the sysfs
directory persists. Now, if the device is recreated with the same
name, sysfs complains that the directory exists.
In this case, it's not a struct device, but a device driver itself:
/* some boards have startup glitches */
while (tries--) {
status = i2c_add_driver(_driver);
if (the_tps)
break;
i2c_del_driver(_driver);
if (!tries) {
printk(KERN_ERR "%s: no chip?\n", DRIVER_NAME);
return -ENODEV;
}
pr_debug("%s: re-probe ...\n", DRIVER_NAME);
msleep(10);
}
Notice how the (i2c) driver is registered and removed multiple times.
If something can independently grab a reference to the kobject associated
with that driver, then it can cause the sysfs directory to persist longer
than the re-probe, which will cause sysfs to complain.
I don't think moving the sysfs directory cleanup (via kobject_del()) before
the delayed release fixes the fundamental problem here, because that just
covers up what happens if a reference is held.
Commit 0f4dafc05 (Kobject: auto-cleanup on final unref) introduced the
kobject_del() into the cleanup function.
Any thoughts?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [trivial]treewide: Fix typo in Kconfig
Correct spelling typo in various Kconfig files. Signed-off-by: Masanari Iida --- arch/arm/mach-sti/Kconfig| 4 ++-- drivers/cpufreq/Kconfig.x86 | 2 +- drivers/dma/Kconfig | 2 +- drivers/fmc/Kconfig | 2 +- drivers/infiniband/ulp/isert/Kconfig | 4 ++-- drivers/media/i2c/Kconfig| 2 +- drivers/mfd/Kconfig | 4 ++-- drivers/usb/core/Kconfig | 2 +- init/Kconfig | 2 +- net/vmw_vsock/Kconfig| 2 +- 10 files changed, 13 insertions(+), 13 deletions(-) diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig index 835833e..a67f83f 100644 --- a/arch/arm/mach-sti/Kconfig +++ b/arch/arm/mach-sti/Kconfig @@ -30,7 +30,7 @@ config SOC_STIH415 default y help This enables support for STMicroelectronics Digital Consumer - Electronics family StiH415 parts, primarily targetted at set-top-box + Electronics family StiH415 parts, primarily targeted at set-top-box and other digital audio/video applications using Flattned Device Trees. @@ -39,7 +39,7 @@ config SOC_STIH416 default y help This enables support for STMicroelectronics Digital Consumer - Electronics family StiH416 parts, primarily targetted at set-top-box + Electronics family StiH416 parts, primarily targeted at set-top-box and other digital audio/video applications using Flattened Device Trees. diff --git a/drivers/cpufreq/Kconfig.x86 b/drivers/cpufreq/Kconfig.x86 index e2b6eab..b80bb4d 100644 --- a/drivers/cpufreq/Kconfig.x86 +++ b/drivers/cpufreq/Kconfig.x86 @@ -136,7 +136,7 @@ config X86_AMD_FREQ_SENSITIVITY help This adds AMD-specific powersave bias function to the ondemand governor, which allows it to make more power-conscious frequency - change decisions based on feedback from hardware (availble on AMD + change decisions based on feedback from hardware (available on AMD Family 16h and above). Hardware feedback tells software how "sensitive" to frequency changes diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 77bc480..6a737d9 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -300,7 +300,7 @@ config MMP_PDMA depends on (ARCH_MMP || ARCH_PXA) select DMA_ENGINE help - Support the MMP PDMA engine for PXA and MMP platfrom. + Support the MMP PDMA engine for PXA and MMP platform. config DMA_JZ4740 tristate "JZ4740 DMA support" diff --git a/drivers/fmc/Kconfig b/drivers/fmc/Kconfig index c01cf45..3a75f42 100644 --- a/drivers/fmc/Kconfig +++ b/drivers/fmc/Kconfig @@ -46,6 +46,6 @@ config FMC_CHARDEV This driver matches every mezzanine device and allows user space to read and write registers using a char device. It can be used to write user-space drivers, or just get - aquainted with a mezzanine before writing its specific driver. + acquainted with a mezzanine before writing its specific driver. endif # FMC diff --git a/drivers/infiniband/ulp/isert/Kconfig b/drivers/infiniband/ulp/isert/Kconfig index ce3fd32..02f9759 100644 --- a/drivers/infiniband/ulp/isert/Kconfig +++ b/drivers/infiniband/ulp/isert/Kconfig @@ -1,5 +1,5 @@ config INFINIBAND_ISERT - tristate "iSCSI Extentions for RDMA (iSER) target support" + tristate "iSCSI Extensions for RDMA (iSER) target support" depends on INET && INFINIBAND_ADDR_TRANS && TARGET_CORE && ISCSI_TARGET ---help--- - Support for iSCSI Extentions for RDMA (iSER) Target on Infiniband fabrics. + Support for iSCSI Extensions for RDMA (iSER) Target on Infiniband fabrics. diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index b2cd8ca..70c4671 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -623,7 +623,7 @@ config VIDEO_UPD64083 To compile this driver as a module, choose M here: the module will be called upd64083. -comment "Miscelaneous helper chips" +comment "Miscellaneous helper chips" config VIDEO_THS7303 tristate "THS7303/53 Video Amplifier" diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index e0e46f5..36d8edb 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -665,14 +665,14 @@ menu "STMicroelectronics STMPE Interface Drivers" depends on MFD_STMPE config STMPE_I2C - bool "STMicroelectronics STMPE I2C Inteface" + bool "STMicroelectronics STMPE I2C Interface" depends on I2C=y default y help This is used to enable I2C interface of STMPE config STMPE_SPI - bool "STMicroelectronics STMPE SPI Inteface" + bool "STMicroelectronics STMPE SPI Interface" depends on SPI_MASTER help This is used to enable SPI interface of STMPE diff --git
Re: [PATCH v5 0/7] DMA: shdma: switch DT to use OF device ID tables
On Fri, Aug 02, 2013 at 04:50:35PM +0200, Guennadi Liakhovetski wrote: > In this version of shdma Device Tree support I preserved the DT > configuration approach via OF device ID tables from v4, but now it is only > used for the DT-mode, the C-version is left untouched. In this series I > only include one platform: r8a73a4-based APE6EVM, if accepted, others can > be added easily. I also took care not to include mach/*.h headers in > driver .c files. To illustrate the use of DT DMA support for MMC DMA on > APE6EVM a patch from a previously separate patch series "DMA for MMCIF and > SDHI devices in DT mode" I have applied all the dma patches, the ARM ones fail for me so should possible go thru ARM tree. thanks ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] DMA: shdma: make a pointer const
On Fri, Aug 02, 2013 at 04:18:09PM +0200, Guennadi Liakhovetski wrote: > Platform data shouldn't be changed at run-time, so, pointers to it should > be const. Applied, thanks ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] DMA: shdma: several stylistic improvements and support for new SoCs
On Tue, Jul 02, 2013 at 05:45:49PM +0200, Guennadi Liakhovetski wrote: > Hi > > The first two patches in this small series improve driver internals a bit > by using preferred APIs, the 3rd patch adds support for new DMAC versions, > present on AG5, APE6, H2. Applied, thanks Although the patch 1 didnt apply for me :( I have manually remove a hunk, I dont which tree yoy genertaed this agaisnt! ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] DMA: shdma: fix CHCLR register address calculation
On Tue, Jul 02, 2013 at 05:37:58PM +0200, Guennadi Liakhovetski wrote: > struct sh_dmae_device::chan_reg is a pointer to u32, therefore when adding > offsets to it care should be taken to add offsets in sizeof(u32) units, not > in bytes. This patch corrects such a bug. While at it we also remove the > redundant parameter of the affected function. Applied, thanks ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] gpio: pcf857x: Add OF support
On 08/25/2013 02:26 AM, Laurent Pinchart wrote:
Add DT bindings for the pcf857x-compatible chips and parse the device
tree node in the driver.
Signed-off-by: Laurent Pinchart
---
.../devicetree/bindings/gpio/gpio-pcf857x.txt | 71 ++
drivers/gpio/gpio-pcf857x.c| 57 ++---
2 files changed, 119 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
Changes since v2
- Replace mention about interrupts software configuration in DT bindings
documentation with an explanation of the hardware configuration.
[...]
@@ -257,14 +280,29 @@ fail:
static int pcf857x_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- struct pcf857x_platform_data*pdata;
+ struct pcf857x_platform_data*pdata = dev_get_platdata(>dev);
+ struct device_node *np = client->dev.of_node;
struct pcf857x *gpio;
+ unsigned intn_latch = 0;
+ unsigned intngpio;
int status;
- pdata = dev_get_platdata(>dev);
- if (!pdata) {
+#ifdef CONFIG_OF
+ if (np) {
+ const struct of_device_id *of_id;
+
+ of_id = of_match_device(pcf857x_of_table,>dev);
+ ngpio = (unsigned int)of_id->data;
It is potentially unsafe, since of_match_device() can return NULL.
+ } else
+#endif
+ ngpio = id->driver_data;
CodingStyle: braces are missing for the second part of the if statement.
How about something along the lines of:
const struct of_device_id *of_id;
of_id = of_match_device(of_match_ptr(pcf857x_of_table), >dev);
if (of_id)
ngpio = (unsigned int)of_id->data;
else
ngpio = id->driver_data;
to get rid of the #ifdef ?
But still DT has priority over platform data here.
+
+ if (pdata)
+ n_latch = pdata->n_latch;
+ else if (IS_ENABLED(CONFIG_OF)&& np)
+ of_property_read_u32(np, "pins-initial-state",_latch);
And here platform data has priority over DT.
+ else
dev_dbg(>dev, "no platform data\n");
- }
/* Allocate, initialize, and register this gpio_chip. */
gpio = devm_kzalloc(>dev, sizeof(*gpio), GFP_KERNEL);
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] gpio: pcf857x: Add OF support
On 08/25/2013 02:15 AM, Laurent Pinchart wrote:
On Saturday 24 August 2013 16:13:11 Tomasz Figa wrote:
On Saturday 24 of August 2013 02:54:07 Laurent Pinchart wrote:
On Saturday 24 August 2013 02:41:59 Tomasz Figa wrote:
On Tuesday 20 of August 2013 01:04:54 Laurent Pinchart wrote:
Add DT bindings for the pcf857x-compatible chips and parse the
device tree node in the driver.
Signed-off-by: Laurent Pinchart
---
.../devicetree/bindings/gpio/gpio-pcf857x.txt | 71 +
drivers/gpio/gpio-pcf857x.c| 57 ++---
2 files changed, 119 insertions(+), 9 deletions(-)
create mode 100644
[snip]
diff --git a/drivers/gpio/gpio-pcf857x.c
b/drivers/gpio/gpio-pcf857x.c
index 070e81f..50a90f1 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
[snip]
@@ -50,6 +52,27 @@ static const struct i2c_device_id pcf857x_id[] =
{
};
MODULE_DEVICE_TABLE(i2c, pcf857x_id);
+#ifdef CONFIG_OF
+static const struct of_device_id pcf857x_of_table[] = {
+ { .compatible = "nxp,pcf8574", .data = (void *)8 },
+ { .compatible = "nxp,pcf8574a", .data = (void *)8 },
+ { .compatible = "nxp,pca8574", .data = (void *)8 },
+ { .compatible = "nxp,pca9670", .data = (void *)8 },
+ { .compatible = "nxp,pca9672", .data = (void *)8 },
+ { .compatible = "nxp,pca9674", .data = (void *)8 },
+ { .compatible = "nxp,pcf8575", .data = (void *)16 },
+ { .compatible = "nxp,pca8575", .data = (void *)16 },
+ { .compatible = "nxp,pca9671", .data = (void *)16 },
+ { .compatible = "nxp,pca9673", .data = (void *)16 },
+ { .compatible = "nxp,pca9675", .data = (void *)16 },
+ { .compatible = "maxim,max7328", .data = (void *)8 },
+ { .compatible = "maxim,max7329", .data = (void *)8 },
+ { .compatible = "ti,tca9554", .data = (void *)8 },
+ { }
+};
+MODULE_DEVICE_TABLE(of, pcf857x_of_table);
+#endif
+
/*
* The pcf857x, pca857x, and pca967x chips only expose one read and
* one write register. Writing a "one" bit (to match the reset
@@ -257,14 +280,29 @@ fail:
static int pcf857x_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- struct pcf857x_platform_data*pdata;
+ struct pcf857x_platform_data*pdata = client->dev.platform_data;
+ struct device_node *np = client->dev.of_node;
> > > struct pcf857x *gpio;
+ unsigned intn_latch = 0;
+ unsigned intngpio;
int status;
- pdata = client->dev.platform_data;
- if (!pdata) {
+#ifdef CONFIG_OF
+ if (np) {
Wouldn't if (IS_ENABLED(CONFIG_OF)&& np) be sufficient here, without
the #ifdef? You would have to move the match table out of the #ifdef
in this case, though...
That's the exact reason why I've used #ifdef CONFIG_OF here, I didn't
want to add the overhead of the pcf857x_of_table when CONFIG_OF isn't
defined.
I'm not sure if I remember correctly, but I think there was something said
in one of discussions some time ago, that we should be moving away from
ifdef'ing such things, in favour of just having them compiled
unconditionally.
There seems to be a general consensus to favor if (IS_ENABLED(CONFIG_OF))
instead of #ifdef CONFIG_OF when possible. I'm not sure what the opinion is
regarding using conditional compilation to avoid compiling unnecessary data
tables in. I would vote for using it (there's no need to bloat the kernel
unnecessarily on non-OF platforms), but I'll conform to whatever is decided to
be best.
[Adding DT maintainers on Cc for more opinions.]
I'll resubmit the patch with the DT bindings documentation fixed, and will
submit yet another version if I need to remove the #ifdef.
I think it makes sense to keep this table compiled in conditionally,
size of
struct of_device_id is relatively large. While absolute increase in size
might not be that significant the relative increase is quite large -
appr. 130%.
Before $subject patch:
$ size drivers/gpio/gpio-pcf857x.o
textdata bss dec hex filename
2228 140 02368 940 drivers/gpio/gpio-pcf857x.o
After applying the patch:
$ size drivers/gpio/gpio-pcf857x.o
textdata bss dec hex filename
5284 140 054241530 drivers/gpio/gpio-pcf857x.o
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] vfs: Tighten up linkat(..., AT_EMPTY_PATH)
On Sat, Aug 24, 2013 at 8:37 PM, Al Viro wrote:
> On Fri, Aug 23, 2013 at 02:07:26AM +0100, Al Viro wrote:
>> On Thu, Aug 22, 2013 at 01:54:15PM -0700, Linus Torvalds wrote:
>> > On Thu, Aug 22, 2013 at 1:48 PM, Andy Lutomirski
>> > wrote:
>> > >
>> > > Sure. But aren't they always last?
>> >
>> > What do you mean? I'd say that the /proc lookup is always *innermost*.
>> > Which means that it certainly cannot bail out, since there are many
>> > levels of nesting outside of it.
>> >
>> > > With the current code structure, trying to enforce some kind of
>> > > security restriction in the middle of lookup seems really unpleasant.
>> >
>> > If it's conditional (ie "linkat behaves differently from openat"), it
>> > certainly means that we'd have to pass in that info in annoying ways.
>>
>> Nope. All we need to pass is one more LOOKUP_... Add
>> if (unlikely(nd->last_type == LAST_BIND)) {
>> if ((nd->flags & LOOKUP_BLAH) && !may_flink(...)) {
>> terminate_walk(nd);
>> return -EINVAL;
>> }
>> }
>> in the beginning of lookup_last() and pass LOOKUP_BLAH in flags when
>> linkat() calls user_path_at(). That will affect *only* the terminal
>> symlinks and cost nothing in all normal cases. The same check can
>> bloody well go into path_init() - take
>> if (*name) {
>> if (!can_lookup(dentry->d_inode)) {
>> fdput(f);
>> return -ENOTDIR;
>> }
>> }
>> in there and slap
>> else {
>> if ((flags & LOOKUP_BLAH) && !may_flink(...)) {
>> fdput(f);
>> return -EINVAL;
>> }
>> }
>> after it.
>
> OK, let me summarize these threads so far:
> * restrictions for flink() are needed and they'd better be
> consistent for AT_SYMLINK_FOLLOW + /proc//fd/ and simply
> passing the descriptor as dfd.
> * CAP_DAC_OVERRIDE is sufficient; so should be O_TMPFILE used
> to open that sucker.
> * lookup_last() is the natural place for catching the case
> of following a trailing procfs symlink - it can be done very cheaply
> there.
>
> FWIW, I'm tempted to try the following trick:
> * introduce FMODE_FLINK in file->f_mode; O_TMPFILE would set it,
> unless O_EXCL is present.
> * introduce LOOKUP_LINK, to be passed by sys_linkat() when
> resolving the target.
> * have path_init() called with empty pathname and LOOKUP_LINK in
> flags do checks for FMODE_FLINK or CAP_DAC_OVERRIDE
> * have ->proc_get_link() report whether the target is linkable
> (either as bool * or by returning 1 instead of 0). After the call of
> ->proc_get_link() check that and set nd->last_type to LAST_BIND_LINKABLE.
> Note that *all* places looking at ->last_type treat LAST_BIND as "none
> of the above" - we never compare with it, so splitting it in two wouldn't
> break anything.
> * have lookup_last() check if LOOKUP_LINK is present and ->last_type
> is LAST_BIND; fail unless we have CAP_DAC_OVERRIDE.
>
> AFAICS, it gets more or less sane behaviour; additionally, it makes possible
> to introduce explicit "I want that descriptor to be suitable for flink()"
> open(2) flag - that would require teaching do_last() about LOOKUP_LINK,
> making it check for CAP_DAC_OVERRIDE if it sees LAST_BIND / LOOKUP_LINK,
> same as lookup_last() above (we obviously want to avoid the possibility
> to take a non-flinkable descriptor and use it to reopen the sucker in
> flinkable way).
>
> Alternatively we can revert "fs: Allow unprivileged linkat(..., AT_EMPTY_PATH)
> aka flink" for the time being. flink() is certainly an awful mess and I
> seriously regret touching it ;-/
>
> Comments? Hell, maybe somebody even has printable ones - stranger things
> have happened...
I think this is more screwed up than just flink and open. For example:
$ echo 'WTF' >test
$ truncate -s 1 /proc/self/fd/3 3http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net] net: add cpu_relax to busy poll loop
Add a cpu_relaxt to sk_busy_loop. Julie Cummings reported performance issues when hyperthreading is on. Arjan van de Ven observed that we should have a cpu_relax() in the busy poll loop. Reported-by: Julie Cummings Signed-off-by: Eliezer Tamir --- include/net/busy_poll.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/net/busy_poll.h b/include/net/busy_poll.h index 8a358a2..829627d 100644 --- a/include/net/busy_poll.h +++ b/include/net/busy_poll.h @@ -123,6 +123,7 @@ static inline bool sk_busy_loop(struct sock *sk, int nonblock) /* local bh are disabled so it is ok to use _BH */ NET_ADD_STATS_BH(sock_net(sk), LINUX_MIB_BUSYPOLLRXPACKETS, rc); + cpu_relax(); } while (!nonblock && skb_queue_empty(>sk_receive_queue) && !need_resched() && !busy_loop_timeout(end_time)); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] jump_label: also include linux/atomic.h when jump label is enabled
The struct static_key will have a atomic_t type member no matter
whether jump label is enabled or not. We would include linux/atomic.h
when jump label is not enabled. But it also does make sense to include
this header file when jump label is enabled.
Signed-off-by: Kevin Hao
---
include/linux/jump_label_base.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/jump_label_base.h b/include/linux/jump_label_base.h
index 20df08f..d5c8f4b 100644
--- a/include/linux/jump_label_base.h
+++ b/include/linux/jump_label_base.h
@@ -5,6 +5,8 @@
#include
#include
+#include
+
#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
struct static_key {
@@ -77,8 +79,6 @@ extern void jump_label_apply_nops(struct module *mod);
#else /* !HAVE_JUMP_LABEL */
-#include
-
struct static_key {
atomic_t enabled;
};
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] powerpc: use jump label for cpu/mmu_has_feature
Inspired by Benjamin Herrenschmidt, this patch series try to reduce the cpu/mmu feature checking overhead by using jump label. The following is the difference of the run path of cpu_has_feature between before and after applying these patches: before after addis r10,r2,1 b xxx addir9,r10,-2280 b xxx (This will also be omitted if the ld r9,0(r9) feature is not set) ld r9,16(r9) rldicl. r8,r9,55,63 beq c0037c94 This patch series passed the build test for almost all the defconfig of ppc. There does have some broken for some configs. But they are not related to this change. This also passed allyesconfig for x86. Boot test on p2020rdb and p5020ds boards. Kevin Hao (5): jump_label: factor out the base part of jump_label.h to a separate file jump_label: also include linux/atomic.h when jump label is enabled powerpc: move the cpu_has_feature to a separate file powerpc: use the jump label for cpu_has_feature powerpc: use jump label for mmu_has_feature arch/powerpc/include/asm/cacheflush.h | 1 + arch/powerpc/include/asm/cpufeatures.h | 42 ++ arch/powerpc/include/asm/cputable.h | 8 -- arch/powerpc/include/asm/cputime.h | 1 + arch/powerpc/include/asm/dbell.h| 1 + arch/powerpc/include/asm/dcr-native.h | 1 + arch/powerpc/include/asm/mman.h | 1 + arch/powerpc/include/asm/mmu.h | 19 + arch/powerpc/include/asm/time.h | 1 + arch/powerpc/kernel/align.c | 1 + arch/powerpc/kernel/cputable.c | 43 ++ arch/powerpc/kernel/irq.c | 1 + arch/powerpc/kernel/process.c | 1 + arch/powerpc/kernel/setup-common.c | 1 + arch/powerpc/kernel/setup_32.c | 1 + arch/powerpc/kernel/smp.c | 1 + arch/powerpc/oprofile/op_model_rs64.c | 1 + arch/powerpc/platforms/cell/pervasive.c | 1 + arch/powerpc/xmon/ppc-dis.c | 1 + include/linux/jump_label.h | 132 + include/linux/jump_label_base.h | 142 21 files changed, 263 insertions(+), 138 deletions(-) create mode 100644 arch/powerpc/include/asm/cpufeatures.h create mode 100644 include/linux/jump_label_base.h -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] jump_label: factor out the base part of jump_label.h to a separate file
We plan to use the jump label in the cpu/mmu feature check on ppc.
This will need to include the jump_label.h in several very basic header
files of ppc which seems to be included by most of the other head
files implicitly or explicitly. But in the current jump_label.h,
it also include the "linux/workqueue.h" and this will cause recursive
inclusion. In order to fix this, we choose to factor out the base
part of jump_label.h to a separate header file and we can include
that file instead of jump_label.h to avoid the recursive inclusion.
No functional change.
Signed-off-by: Kevin Hao
---
include/linux/jump_label.h | 132 +
include/linux/jump_label_base.h | 142
2 files changed, 144 insertions(+), 130 deletions(-)
create mode 100644 include/linux/jump_label_base.h
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 0976fc4..14bae65 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -46,20 +46,11 @@
*
*/
-#include
-#include
#include
+#include
-#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
-struct static_key {
- atomic_t enabled;
-/* Set lsb bit to 1 if branch is default true, 0 ot */
- struct jump_entry *entries;
-#ifdef CONFIG_MODULES
- struct static_key_mod *next;
-#endif
-};
+#ifdef HAVE_JUMP_LABEL
struct static_key_deferred {
struct static_key key;
@@ -67,145 +58,26 @@ struct static_key_deferred {
struct delayed_work work;
};
-# include
-# define HAVE_JUMP_LABEL
-#endif /* CC_HAVE_ASM_GOTO && CONFIG_JUMP_LABEL */
-
-enum jump_label_type {
- JUMP_LABEL_DISABLE = 0,
- JUMP_LABEL_ENABLE,
-};
-
-struct module;
-
-#ifdef HAVE_JUMP_LABEL
-
-#define JUMP_LABEL_TRUE_BRANCH 1UL
-
-static
-inline struct jump_entry *jump_label_get_entries(struct static_key *key)
-{
- return (struct jump_entry *)((unsigned long)key->entries
- & ~JUMP_LABEL_TRUE_BRANCH);
-}
-
-static inline bool jump_label_get_branch_default(struct static_key *key)
-{
- if ((unsigned long)key->entries & JUMP_LABEL_TRUE_BRANCH)
- return true;
- return false;
-}
-
-static __always_inline bool static_key_false(struct static_key *key)
-{
- return arch_static_branch(key);
-}
-
-static __always_inline bool static_key_true(struct static_key *key)
-{
- return !static_key_false(key);
-}
-
-extern struct jump_entry __start___jump_table[];
-extern struct jump_entry __stop___jump_table[];
-
-extern void jump_label_init(void);
-extern void jump_label_lock(void);
-extern void jump_label_unlock(void);
-extern void arch_jump_label_transform(struct jump_entry *entry,
- enum jump_label_type type);
-extern void arch_jump_label_transform_static(struct jump_entry *entry,
-enum jump_label_type type);
-extern int jump_label_text_reserved(void *start, void *end);
-extern void static_key_slow_inc(struct static_key *key);
-extern void static_key_slow_dec(struct static_key *key);
extern void static_key_slow_dec_deferred(struct static_key_deferred *key);
-extern void jump_label_apply_nops(struct module *mod);
extern void
jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl);
-#define STATIC_KEY_INIT_TRUE ((struct static_key) \
- { .enabled = ATOMIC_INIT(1), .entries = (void *)1 })
-#define STATIC_KEY_INIT_FALSE ((struct static_key) \
- { .enabled = ATOMIC_INIT(0), .entries = (void *)0 })
-
#else /* !HAVE_JUMP_LABEL */
-#include
-
-struct static_key {
- atomic_t enabled;
-};
-
-static __always_inline void jump_label_init(void)
-{
-}
-
struct static_key_deferred {
struct static_key key;
};
-static __always_inline bool static_key_false(struct static_key *key)
-{
- if (unlikely(atomic_read(>enabled)) > 0)
- return true;
- return false;
-}
-
-static __always_inline bool static_key_true(struct static_key *key)
-{
- if (likely(atomic_read(>enabled)) > 0)
- return true;
- return false;
-}
-
-static inline void static_key_slow_inc(struct static_key *key)
-{
- atomic_inc(>enabled);
-}
-
-static inline void static_key_slow_dec(struct static_key *key)
-{
- atomic_dec(>enabled);
-}
-
static inline void static_key_slow_dec_deferred(struct static_key_deferred
*key)
{
static_key_slow_dec(>key);
}
-static inline int jump_label_text_reserved(void *start, void *end)
-{
- return 0;
-}
-
-static inline void jump_label_lock(void) {}
-static inline void jump_label_unlock(void) {}
-
-static inline int jump_label_apply_nops(struct module *mod)
-{
- return 0;
-}
-
static inline void
jump_label_rate_limit(struct static_key_deferred *key,
unsigned long rl)
{
}
-#define STATIC_KEY_INIT_TRUE ((struct static_key) \
- { .enabled = ATOMIC_INIT(1) })
Re: [PATCH 1/2] HID: apple: Add another device ID for the mid-2013 Macbook Air
Hi Ian,
> This patch adds a device ID found for mid-2013 Macbook Air 6,1 from
> lsusb:
>
> Bus 001 Device 003: ID 05ac:0290 Apple, Inc.
>
> Since IDs already exist for this generation Macbook air as WELLSPRING8,
> name this one WELLSPRING8A. This only adds an ANSI version since it's
> device ID is only one less than the existing WELLSPRING8 IDs.
This seems to indicate that we got the ANSI/ISO numbers wrong in a
recent patch. IIRC, there was doubt already when the patch was
applied (Linus T CC'd). Most likely the right patch is this:
diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
index 4ef4d5e..a73f961 100644
--- a/drivers/input/mouse/bcm5974.c
+++ b/drivers/input/mouse/bcm5974.c
@@ -89,9 +89,9 @@
#define USB_DEVICE_ID_APPLE_WELLSPRING7A_ISO 0x025a
#define USB_DEVICE_ID_APPLE_WELLSPRING7A_JIS 0x025b
/* MacbookAir6,2 (unibody, June 2013) */
-#define USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI 0x0291
-#define USB_DEVICE_ID_APPLE_WELLSPRING8_ISO0x0292
-#define USB_DEVICE_ID_APPLE_WELLSPRING8_JIS0x0293
+#define USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI 0x0290
+#define USB_DEVICE_ID_APPLE_WELLSPRING8_ISO0x0291
+#define USB_DEVICE_ID_APPLE_WELLSPRING8_JIS0x0292
#define BCM5974_DEVICE(prod) { \
.match_flags = (USB_DEVICE_ID_MATCH_DEVICE |\
Brad, Linus, does the above patch work for you as well as for Ian?
Thanks,
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] X86: MM: Add PAT Type write-through in combination with mtrr
This patch adds the Write-through memory type in combination with mtrr.
If you call ioremap_cache to request cachable memory (write-back) the function
tries to set the PAT to write-back only if the mtrr setting of the requested
region
is also marked as Write-Back.
If the mttr regions are marked e.g. as Write-through or with other types, the
function will
always return UC- memory.
If you check the Intel document " IA-32 SDM vol 3a table Effective Memory
Type", there
are many other combinations possible.
This patch will only add the following combination:
PAT=Write-Back + MTRR=Write-Through = Effective Memory of Write-Through
Tested on - Intel (R) Atom E680 (Tunnel Creek)
- Intel (R) Core(TM)2 Duo
Signed-off-by: Andreas Werner
---
arch/x86/mm/pat.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 6574388..9cfe107 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -149,10 +149,15 @@ static unsigned long pat_x_mtrr_type(u64 start, u64 end,
unsigned long req_type)
u8 mtrr_type;
mtrr_type = mtrr_type_lookup(start, end);
- if (mtrr_type != MTRR_TYPE_WRBACK)
- return _PAGE_CACHE_UC_MINUS;
- return _PAGE_CACHE_WB;
+ switch (mtrr_type) {
+ case MTRR_TYPE_WRBACK:
+ case MTRR_TYPE_WRTHROUGH:
+ return _PAGE_CACHE_WB;
+
+ default:
+ return _PAGE_CACHE_UC_MINUS;
+ }
}
return req_type;
--
1.8.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] kvm: use anon_inode_getfd() with O_CLOEXEC flag
Il 24/08/2013 22:14, Yann Droneaud ha scritto:
> KVM uses anon_inode_get() to allocate file descriptors as part
> of some of its ioctls. But those ioctls are lacking a flag argument
> allowing userspace to choose options for the newly opened file descriptor.
>
> In such case it's advised to use O_CLOEXEC by default so that
> userspace is allowed to choose, without race, if the file descriptor
> is going to be inherited across exec().
>
> This patch set O_CLOEXEC flag on all file descriptors created
> with anon_inode_getfd() to not leak file descriptors across exec().
>
> Signed-off-by: Yann Droneaud
> Link: http://lkml.kernel.org/r/cover.1377372576.git.ydrone...@opteya.com
Reviewed-by: Paolo Bonzini
> ---
> virt/kvm/kvm_main.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 89f74d1..d65cc0c 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1896,7 +1896,7 @@ static struct file_operations kvm_vcpu_fops = {
> */
> static int create_vcpu_fd(struct kvm_vcpu *vcpu)
> {
> - return anon_inode_getfd("kvm-vcpu", _vcpu_fops, vcpu, O_RDWR);
> + return anon_inode_getfd("kvm-vcpu", _vcpu_fops, vcpu, O_RDWR |
> O_CLOEXEC);
> }
>
> /*
> @@ -2306,7 +2306,7 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
> return ret;
> }
>
> - ret = anon_inode_getfd(ops->name, _device_fops, dev, O_RDWR);
> + ret = anon_inode_getfd(ops->name, _device_fops, dev, O_RDWR |
> O_CLOEXEC);
> if (ret < 0) {
> ops->destroy(dev);
> return ret;
> @@ -2590,7 +2590,7 @@ static int kvm_dev_ioctl_create_vm(unsigned long type)
> return r;
> }
> #endif
> - r = anon_inode_getfd("kvm-vm", _vm_fops, kvm, O_RDWR);
> + r = anon_inode_getfd("kvm-vm", _vm_fops, kvm, O_RDWR | O_CLOEXEC);
> if (r < 0)
> kvm_put_kvm(kvm);
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] HID: apple: Add another device ID for the mid-2013 Macbook Air
On Sat, Aug 24, 2013 at 04:26:30PM -0700, Dmitry Torokhov wrote: > Hi Ian, > > On Sun, Aug 25, 2013 at 12:17:52AM +1000, Ian Munsie wrote: > > This patch adds a device ID found for mid-2013 Macbook Air 6,1 from > > lsusb: > > > > Bus 001 Device 003: ID 05ac:0290 Apple, Inc. > > > > Since IDs already exist for this generation Macbook air as WELLSPRING8, > > name this one WELLSPRING8A. This only adds an ANSI version since it's > > device ID is only one less than the existing WELLSPRING8 IDs. > > > > Signed-off-by: Ian Munsie > > Thank you for the patch! > > Jiri, can I take it through my tree for 3.11? Wait, we probably want to resolve the USB ID inconsistency first. :-) Thanks, Henrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: /proc/pid/fd && anon_inode_fops
On Sun, Aug 25, 2013 at 06:23:17AM +0100, Al Viro wrote:
> On Sat, Aug 24, 2013 at 11:24:32PM +0200, Willy Tarreau wrote:
>
> > I doubt it. It seems to me that most such entries are implemented
> > for completeness while most valid uses only concern /proc/self/fd.
> > Maybe if we had an option so that only /proc/self/fd would actually
> > allow to access the fds while all /proc/pid/fd would only show what
> > they map to, it would be a good step forward.
>
> How? The fundamental problem is not visibility of that stuff, it's
> new opened file for the same object (Linux behaviour) vs. new descriptor
> refering to the same opened file (*BSD and friends). We can't get
> anon_... sanely reopened in the former semantics and they are very
> visibly different for regular files, so switching to *BSD one is not
> feasible - too high odds of userland breakage. The difference in
> semantics, of course, is that on Linux opening /dev/stdin gives you
> a descriptor with independent current IO position; on *BSD you get
> a descriptor sharing the current IO position with stdin. IOW, it's
> independent open() of the same file vs. dup().
>
> We are really stuck with the current semantics here - switching to
> *BSD one would not only mean serious surgery on descriptor handling
> (it's one of the wartier areas in *BSD VFS, in large part because
> of magic-open-really-a-dup kludges they have to do), it would change
> a long-standing userland API that had been there for nearly 20 years
> _and_ one that tends to be used in corner cases of hell knows how many
> scripts.
Thanks for explaining Al, that really helps me understand. However
there's still a difference between /proc/pid called from the process
itself (=/proc/self) and called from other processes that seems to
suit the situation :
willy@eeepc:~$ ls -la /tmp/bash
-r-x--x--x 1 root users 916852 2013-08-25 08:19 /tmp/bash*
willy@eeepc:~$ exec /tmp/bash -i
willy@eeepc:~$ echo $$
22678
willy@eeepc:~$ ls -la /proc/22678/fd
ls: cannot open directory /proc/22678/fd: Permission denied
willy@eeepc:~$ ls -la /proc/22678/exe
ls: cannot read symbolic link /proc/22678/exe: Permission denied
willy@eeepc:~$ cat /proc/22678/fd/0
cat: /proc/22678/fd/0: Permission denied
but :
willy@eeepc:~$ read < /proc/22678/fd/0
azerazerazer
willy@eeepc:~$ echo $REPLY
azerazerazer
strace clearly shows that the process was allowed to inspect itself
and the other ones were not :
willy@eeepc:~$ strace -p 22678
open("/proc/22678/fd/0", O_RDONLY|O_LARGEFILE) = 3
willy@eeepc:~$ strace cat /proc/22678/fd/0
open("/proc/22678/fd/0", O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied)
It looks like this difference was introduced by this patch (which also fixes
this issue we've been having for a very long time on 2.4 and early 2.6) :
8948e11 Allow access to /proc/$PID/fd after setuid()
Thus I'm wondering if something like this could help, the idea would be
that a with the appropriate mount option, a task could only look at its
own descriptors unless it's running with privileges :
static int proc_fd_permission(struct inode *inode, int mask,
struct nameidata *nd)
{
if (task_pid(current) == proc_pid(inode))
return 0;
if (capable(CAP_DAC_OVERRIDE))
return 0;
if (proc_mounted_with_strict_option)
return -EACCES;
return generic_permission(inode, mask, NULL);
}
Thus it would not change the default behaviour except for people who would
mount /proc with a special option.
Thanks,
Willy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: /proc/pid/fd anon_inode_fops
On Sun, Aug 25, 2013 at 06:23:17AM +0100, Al Viro wrote:
On Sat, Aug 24, 2013 at 11:24:32PM +0200, Willy Tarreau wrote:
I doubt it. It seems to me that most such entries are implemented
for completeness while most valid uses only concern /proc/self/fd.
Maybe if we had an option so that only /proc/self/fd would actually
allow to access the fds while all /proc/pid/fd would only show what
they map to, it would be a good step forward.
How? The fundamental problem is not visibility of that stuff, it's
new opened file for the same object (Linux behaviour) vs. new descriptor
refering to the same opened file (*BSD and friends). We can't get
anon_... sanely reopened in the former semantics and they are very
visibly different for regular files, so switching to *BSD one is not
feasible - too high odds of userland breakage. The difference in
semantics, of course, is that on Linux opening /dev/stdin gives you
a descriptor with independent current IO position; on *BSD you get
a descriptor sharing the current IO position with stdin. IOW, it's
independent open() of the same file vs. dup().
We are really stuck with the current semantics here - switching to
*BSD one would not only mean serious surgery on descriptor handling
(it's one of the wartier areas in *BSD VFS, in large part because
of magic-open-really-a-dup kludges they have to do), it would change
a long-standing userland API that had been there for nearly 20 years
_and_ one that tends to be used in corner cases of hell knows how many
scripts.
Thanks for explaining Al, that really helps me understand. However
there's still a difference between /proc/pid called from the process
itself (=/proc/self) and called from other processes that seems to
suit the situation :
willy@eeepc:~$ ls -la /tmp/bash
-r-x--x--x 1 root users 916852 2013-08-25 08:19 /tmp/bash*
willy@eeepc:~$ exec /tmp/bash -i
willy@eeepc:~$ echo $$
22678
willy@eeepc:~$ ls -la /proc/22678/fd
ls: cannot open directory /proc/22678/fd: Permission denied
willy@eeepc:~$ ls -la /proc/22678/exe
ls: cannot read symbolic link /proc/22678/exe: Permission denied
willy@eeepc:~$ cat /proc/22678/fd/0
cat: /proc/22678/fd/0: Permission denied
but :
willy@eeepc:~$ read /proc/22678/fd/0
azerazerazer
willy@eeepc:~$ echo $REPLY
azerazerazer
strace clearly shows that the process was allowed to inspect itself
and the other ones were not :
willy@eeepc:~$ strace -p 22678
open(/proc/22678/fd/0, O_RDONLY|O_LARGEFILE) = 3
willy@eeepc:~$ strace cat /proc/22678/fd/0
open(/proc/22678/fd/0, O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied)
It looks like this difference was introduced by this patch (which also fixes
this issue we've been having for a very long time on 2.4 and early 2.6) :
8948e11 Allow access to /proc/$PID/fd after setuid()
Thus I'm wondering if something like this could help, the idea would be
that a with the appropriate mount option, a task could only look at its
own descriptors unless it's running with privileges :
static int proc_fd_permission(struct inode *inode, int mask,
struct nameidata *nd)
{
if (task_pid(current) == proc_pid(inode))
return 0;
if (capable(CAP_DAC_OVERRIDE))
return 0;
if (proc_mounted_with_strict_option)
return -EACCES;
return generic_permission(inode, mask, NULL);
}
Thus it would not change the default behaviour except for people who would
mount /proc with a special option.
Thanks,
Willy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] kvm: use anon_inode_getfd() with O_CLOEXEC flag
Il 24/08/2013 22:14, Yann Droneaud ha scritto:
KVM uses anon_inode_get() to allocate file descriptors as part
of some of its ioctls. But those ioctls are lacking a flag argument
allowing userspace to choose options for the newly opened file descriptor.
In such case it's advised to use O_CLOEXEC by default so that
userspace is allowed to choose, without race, if the file descriptor
is going to be inherited across exec().
This patch set O_CLOEXEC flag on all file descriptors created
with anon_inode_getfd() to not leak file descriptors across exec().
Signed-off-by: Yann Droneaud ydrone...@opteya.com
Link: http://lkml.kernel.org/r/cover.1377372576.git.ydrone...@opteya.com
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
---
virt/kvm/kvm_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 89f74d1..d65cc0c 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1896,7 +1896,7 @@ static struct file_operations kvm_vcpu_fops = {
*/
static int create_vcpu_fd(struct kvm_vcpu *vcpu)
{
- return anon_inode_getfd(kvm-vcpu, kvm_vcpu_fops, vcpu, O_RDWR);
+ return anon_inode_getfd(kvm-vcpu, kvm_vcpu_fops, vcpu, O_RDWR |
O_CLOEXEC);
}
/*
@@ -2306,7 +2306,7 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
return ret;
}
- ret = anon_inode_getfd(ops-name, kvm_device_fops, dev, O_RDWR);
+ ret = anon_inode_getfd(ops-name, kvm_device_fops, dev, O_RDWR |
O_CLOEXEC);
if (ret 0) {
ops-destroy(dev);
return ret;
@@ -2590,7 +2590,7 @@ static int kvm_dev_ioctl_create_vm(unsigned long type)
return r;
}
#endif
- r = anon_inode_getfd(kvm-vm, kvm_vm_fops, kvm, O_RDWR);
+ r = anon_inode_getfd(kvm-vm, kvm_vm_fops, kvm, O_RDWR | O_CLOEXEC);
if (r 0)
kvm_put_kvm(kvm);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] HID: apple: Add another device ID for the mid-2013 Macbook Air
On Sat, Aug 24, 2013 at 04:26:30PM -0700, Dmitry Torokhov wrote: Hi Ian, On Sun, Aug 25, 2013 at 12:17:52AM +1000, Ian Munsie wrote: This patch adds a device ID found for mid-2013 Macbook Air 6,1 from lsusb: Bus 001 Device 003: ID 05ac:0290 Apple, Inc. Since IDs already exist for this generation Macbook air as WELLSPRING8, name this one WELLSPRING8A. This only adds an ANSI version since it's device ID is only one less than the existing WELLSPRING8 IDs. Signed-off-by: Ian Munsie darkstarsw...@gmail.com Thank you for the patch! Jiri, can I take it through my tree for 3.11? Wait, we probably want to resolve the USB ID inconsistency first. :-) Thanks, Henrik -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] X86: MM: Add PAT Type write-through in combination with mtrr
This patch adds the Write-through memory type in combination with mtrr.
If you call ioremap_cache to request cachable memory (write-back) the function
tries to set the PAT to write-back only if the mtrr setting of the requested
region
is also marked as Write-Back.
If the mttr regions are marked e.g. as Write-through or with other types, the
function will
always return UC- memory.
If you check the Intel document IA-32 SDM vol 3a table Effective Memory
Type, there
are many other combinations possible.
This patch will only add the following combination:
PAT=Write-Back + MTRR=Write-Through = Effective Memory of Write-Through
Tested on - Intel (R) Atom E680 (Tunnel Creek)
- Intel (R) Core(TM)2 Duo
Signed-off-by: Andreas Werner wernera...@gmx.de
---
arch/x86/mm/pat.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 6574388..9cfe107 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -149,10 +149,15 @@ static unsigned long pat_x_mtrr_type(u64 start, u64 end,
unsigned long req_type)
u8 mtrr_type;
mtrr_type = mtrr_type_lookup(start, end);
- if (mtrr_type != MTRR_TYPE_WRBACK)
- return _PAGE_CACHE_UC_MINUS;
- return _PAGE_CACHE_WB;
+ switch (mtrr_type) {
+ case MTRR_TYPE_WRBACK:
+ case MTRR_TYPE_WRTHROUGH:
+ return _PAGE_CACHE_WB;
+
+ default:
+ return _PAGE_CACHE_UC_MINUS;
+ }
}
return req_type;
--
1.8.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] HID: apple: Add another device ID for the mid-2013 Macbook Air
Hi Ian,
This patch adds a device ID found for mid-2013 Macbook Air 6,1 from
lsusb:
Bus 001 Device 003: ID 05ac:0290 Apple, Inc.
Since IDs already exist for this generation Macbook air as WELLSPRING8,
name this one WELLSPRING8A. This only adds an ANSI version since it's
device ID is only one less than the existing WELLSPRING8 IDs.
This seems to indicate that we got the ANSI/ISO numbers wrong in a
recent patch. IIRC, there was doubt already when the patch was
applied (Linus T CC'd). Most likely the right patch is this:
diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
index 4ef4d5e..a73f961 100644
--- a/drivers/input/mouse/bcm5974.c
+++ b/drivers/input/mouse/bcm5974.c
@@ -89,9 +89,9 @@
#define USB_DEVICE_ID_APPLE_WELLSPRING7A_ISO 0x025a
#define USB_DEVICE_ID_APPLE_WELLSPRING7A_JIS 0x025b
/* MacbookAir6,2 (unibody, June 2013) */
-#define USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI 0x0291
-#define USB_DEVICE_ID_APPLE_WELLSPRING8_ISO0x0292
-#define USB_DEVICE_ID_APPLE_WELLSPRING8_JIS0x0293
+#define USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI 0x0290
+#define USB_DEVICE_ID_APPLE_WELLSPRING8_ISO0x0291
+#define USB_DEVICE_ID_APPLE_WELLSPRING8_JIS0x0292
#define BCM5974_DEVICE(prod) { \
.match_flags = (USB_DEVICE_ID_MATCH_DEVICE |\
Brad, Linus, does the above patch work for you as well as for Ian?
Thanks,
Henrik
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 0/5] powerpc: use jump label for cpu/mmu_has_feature
Inspired by Benjamin Herrenschmidt, this patch series try to reduce the cpu/mmu feature checking overhead by using jump label. The following is the difference of the run path of cpu_has_feature between before and after applying these patches: before after addis r10,r2,1 b xxx addir9,r10,-2280 b xxx (This will also be omitted if the ld r9,0(r9) feature is not set) ld r9,16(r9) rldicl. r8,r9,55,63 beq c0037c94 This patch series passed the build test for almost all the defconfig of ppc. There does have some broken for some configs. But they are not related to this change. This also passed allyesconfig for x86. Boot test on p2020rdb and p5020ds boards. Kevin Hao (5): jump_label: factor out the base part of jump_label.h to a separate file jump_label: also include linux/atomic.h when jump label is enabled powerpc: move the cpu_has_feature to a separate file powerpc: use the jump label for cpu_has_feature powerpc: use jump label for mmu_has_feature arch/powerpc/include/asm/cacheflush.h | 1 + arch/powerpc/include/asm/cpufeatures.h | 42 ++ arch/powerpc/include/asm/cputable.h | 8 -- arch/powerpc/include/asm/cputime.h | 1 + arch/powerpc/include/asm/dbell.h| 1 + arch/powerpc/include/asm/dcr-native.h | 1 + arch/powerpc/include/asm/mman.h | 1 + arch/powerpc/include/asm/mmu.h | 19 + arch/powerpc/include/asm/time.h | 1 + arch/powerpc/kernel/align.c | 1 + arch/powerpc/kernel/cputable.c | 43 ++ arch/powerpc/kernel/irq.c | 1 + arch/powerpc/kernel/process.c | 1 + arch/powerpc/kernel/setup-common.c | 1 + arch/powerpc/kernel/setup_32.c | 1 + arch/powerpc/kernel/smp.c | 1 + arch/powerpc/oprofile/op_model_rs64.c | 1 + arch/powerpc/platforms/cell/pervasive.c | 1 + arch/powerpc/xmon/ppc-dis.c | 1 + include/linux/jump_label.h | 132 + include/linux/jump_label_base.h | 142 21 files changed, 263 insertions(+), 138 deletions(-) create mode 100644 arch/powerpc/include/asm/cpufeatures.h create mode 100644 include/linux/jump_label_base.h -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] jump_label: factor out the base part of jump_label.h to a separate file
We plan to use the jump label in the cpu/mmu feature check on ppc.
This will need to include the jump_label.h in several very basic header
files of ppc which seems to be included by most of the other head
files implicitly or explicitly. But in the current jump_label.h,
it also include the linux/workqueue.h and this will cause recursive
inclusion. In order to fix this, we choose to factor out the base
part of jump_label.h to a separate header file and we can include
that file instead of jump_label.h to avoid the recursive inclusion.
No functional change.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
include/linux/jump_label.h | 132 +
include/linux/jump_label_base.h | 142
2 files changed, 144 insertions(+), 130 deletions(-)
create mode 100644 include/linux/jump_label_base.h
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 0976fc4..14bae65 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -46,20 +46,11 @@
*
*/
-#include linux/types.h
-#include linux/compiler.h
#include linux/workqueue.h
+#include linux/jump_label_base.h
-#if defined(CC_HAVE_ASM_GOTO) defined(CONFIG_JUMP_LABEL)
-struct static_key {
- atomic_t enabled;
-/* Set lsb bit to 1 if branch is default true, 0 ot */
- struct jump_entry *entries;
-#ifdef CONFIG_MODULES
- struct static_key_mod *next;
-#endif
-};
+#ifdef HAVE_JUMP_LABEL
struct static_key_deferred {
struct static_key key;
@@ -67,145 +58,26 @@ struct static_key_deferred {
struct delayed_work work;
};
-# include asm/jump_label.h
-# define HAVE_JUMP_LABEL
-#endif /* CC_HAVE_ASM_GOTO CONFIG_JUMP_LABEL */
-
-enum jump_label_type {
- JUMP_LABEL_DISABLE = 0,
- JUMP_LABEL_ENABLE,
-};
-
-struct module;
-
-#ifdef HAVE_JUMP_LABEL
-
-#define JUMP_LABEL_TRUE_BRANCH 1UL
-
-static
-inline struct jump_entry *jump_label_get_entries(struct static_key *key)
-{
- return (struct jump_entry *)((unsigned long)key-entries
-~JUMP_LABEL_TRUE_BRANCH);
-}
-
-static inline bool jump_label_get_branch_default(struct static_key *key)
-{
- if ((unsigned long)key-entries JUMP_LABEL_TRUE_BRANCH)
- return true;
- return false;
-}
-
-static __always_inline bool static_key_false(struct static_key *key)
-{
- return arch_static_branch(key);
-}
-
-static __always_inline bool static_key_true(struct static_key *key)
-{
- return !static_key_false(key);
-}
-
-extern struct jump_entry __start___jump_table[];
-extern struct jump_entry __stop___jump_table[];
-
-extern void jump_label_init(void);
-extern void jump_label_lock(void);
-extern void jump_label_unlock(void);
-extern void arch_jump_label_transform(struct jump_entry *entry,
- enum jump_label_type type);
-extern void arch_jump_label_transform_static(struct jump_entry *entry,
-enum jump_label_type type);
-extern int jump_label_text_reserved(void *start, void *end);
-extern void static_key_slow_inc(struct static_key *key);
-extern void static_key_slow_dec(struct static_key *key);
extern void static_key_slow_dec_deferred(struct static_key_deferred *key);
-extern void jump_label_apply_nops(struct module *mod);
extern void
jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl);
-#define STATIC_KEY_INIT_TRUE ((struct static_key) \
- { .enabled = ATOMIC_INIT(1), .entries = (void *)1 })
-#define STATIC_KEY_INIT_FALSE ((struct static_key) \
- { .enabled = ATOMIC_INIT(0), .entries = (void *)0 })
-
#else /* !HAVE_JUMP_LABEL */
-#include linux/atomic.h
-
-struct static_key {
- atomic_t enabled;
-};
-
-static __always_inline void jump_label_init(void)
-{
-}
-
struct static_key_deferred {
struct static_key key;
};
-static __always_inline bool static_key_false(struct static_key *key)
-{
- if (unlikely(atomic_read(key-enabled)) 0)
- return true;
- return false;
-}
-
-static __always_inline bool static_key_true(struct static_key *key)
-{
- if (likely(atomic_read(key-enabled)) 0)
- return true;
- return false;
-}
-
-static inline void static_key_slow_inc(struct static_key *key)
-{
- atomic_inc(key-enabled);
-}
-
-static inline void static_key_slow_dec(struct static_key *key)
-{
- atomic_dec(key-enabled);
-}
-
static inline void static_key_slow_dec_deferred(struct static_key_deferred
*key)
{
static_key_slow_dec(key-key);
}
-static inline int jump_label_text_reserved(void *start, void *end)
-{
- return 0;
-}
-
-static inline void jump_label_lock(void) {}
-static inline void jump_label_unlock(void) {}
-
-static inline int jump_label_apply_nops(struct module *mod)
-{
- return 0;
-}
-
static inline void
jump_label_rate_limit(struct static_key_deferred *key,
unsigned
[PATCH 2/5] jump_label: also include linux/atomic.h when jump label is enabled
The struct static_key will have a atomic_t type member no matter
whether jump label is enabled or not. We would include linux/atomic.h
when jump label is not enabled. But it also does make sense to include
this header file when jump label is enabled.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
include/linux/jump_label_base.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/jump_label_base.h b/include/linux/jump_label_base.h
index 20df08f..d5c8f4b 100644
--- a/include/linux/jump_label_base.h
+++ b/include/linux/jump_label_base.h
@@ -5,6 +5,8 @@
#include linux/types.h
#include linux/compiler.h
+#include linux/atomic.h
+
#if defined(CC_HAVE_ASM_GOTO) defined(CONFIG_JUMP_LABEL)
struct static_key {
@@ -77,8 +79,6 @@ extern void jump_label_apply_nops(struct module *mod);
#else /* !HAVE_JUMP_LABEL */
-#include linux/atomic.h
-
struct static_key {
atomic_t enabled;
};
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net] net: add cpu_relax to busy poll loop
Add a cpu_relaxt to sk_busy_loop. Julie Cummings reported performance issues when hyperthreading is on. Arjan van de Ven observed that we should have a cpu_relax() in the busy poll loop. Reported-by: Julie Cummings julie.a.cummi...@intel.com Signed-off-by: Eliezer Tamir eliezer.ta...@linux.intel.com --- include/net/busy_poll.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/net/busy_poll.h b/include/net/busy_poll.h index 8a358a2..829627d 100644 --- a/include/net/busy_poll.h +++ b/include/net/busy_poll.h @@ -123,6 +123,7 @@ static inline bool sk_busy_loop(struct sock *sk, int nonblock) /* local bh are disabled so it is ok to use _BH */ NET_ADD_STATS_BH(sock_net(sk), LINUX_MIB_BUSYPOLLRXPACKETS, rc); + cpu_relax(); } while (!nonblock skb_queue_empty(sk-sk_receive_queue) !need_resched() !busy_loop_timeout(end_time)); -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] vfs: Tighten up linkat(..., AT_EMPTY_PATH)
On Sat, Aug 24, 2013 at 8:37 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Fri, Aug 23, 2013 at 02:07:26AM +0100, Al Viro wrote:
On Thu, Aug 22, 2013 at 01:54:15PM -0700, Linus Torvalds wrote:
On Thu, Aug 22, 2013 at 1:48 PM, Andy Lutomirski l...@amacapital.net
wrote:
Sure. But aren't they always last?
What do you mean? I'd say that the /proc lookup is always *innermost*.
Which means that it certainly cannot bail out, since there are many
levels of nesting outside of it.
With the current code structure, trying to enforce some kind of
security restriction in the middle of lookup seems really unpleasant.
If it's conditional (ie linkat behaves differently from openat), it
certainly means that we'd have to pass in that info in annoying ways.
Nope. All we need to pass is one more LOOKUP_... Add
if (unlikely(nd-last_type == LAST_BIND)) {
if ((nd-flags LOOKUP_BLAH) !may_flink(...)) {
terminate_walk(nd);
return -EINVAL;
}
}
in the beginning of lookup_last() and pass LOOKUP_BLAH in flags when
linkat() calls user_path_at(). That will affect *only* the terminal
symlinks and cost nothing in all normal cases. The same check can
bloody well go into path_init() - take
if (*name) {
if (!can_lookup(dentry-d_inode)) {
fdput(f);
return -ENOTDIR;
}
}
in there and slap
else {
if ((flags LOOKUP_BLAH) !may_flink(...)) {
fdput(f);
return -EINVAL;
}
}
after it.
OK, let me summarize these threads so far:
* restrictions for flink() are needed and they'd better be
consistent for AT_SYMLINK_FOLLOW + /proc/pid/fd/n and simply
passing the descriptor as dfd.
* CAP_DAC_OVERRIDE is sufficient; so should be O_TMPFILE used
to open that sucker.
* lookup_last() is the natural place for catching the case
of following a trailing procfs symlink - it can be done very cheaply
there.
FWIW, I'm tempted to try the following trick:
* introduce FMODE_FLINK in file-f_mode; O_TMPFILE would set it,
unless O_EXCL is present.
* introduce LOOKUP_LINK, to be passed by sys_linkat() when
resolving the target.
* have path_init() called with empty pathname and LOOKUP_LINK in
flags do checks for FMODE_FLINK or CAP_DAC_OVERRIDE
* have -proc_get_link() report whether the target is linkable
(either as bool * or by returning 1 instead of 0). After the call of
-proc_get_link() check that and set nd-last_type to LAST_BIND_LINKABLE.
Note that *all* places looking at -last_type treat LAST_BIND as none
of the above - we never compare with it, so splitting it in two wouldn't
break anything.
* have lookup_last() check if LOOKUP_LINK is present and -last_type
is LAST_BIND; fail unless we have CAP_DAC_OVERRIDE.
AFAICS, it gets more or less sane behaviour; additionally, it makes possible
to introduce explicit I want that descriptor to be suitable for flink()
open(2) flag - that would require teaching do_last() about LOOKUP_LINK,
making it check for CAP_DAC_OVERRIDE if it sees LAST_BIND / LOOKUP_LINK,
same as lookup_last() above (we obviously want to avoid the possibility
to take a non-flinkable descriptor and use it to reopen the sucker in
flinkable way).
Alternatively we can revert fs: Allow unprivileged linkat(..., AT_EMPTY_PATH)
aka flink for the time being. flink() is certainly an awful mess and I
seriously regret touching it ;-/
Comments? Hell, maybe somebody even has printable ones - stranger things
have happened...
I think this is more screwed up than just flink and open. For example:
$ echo 'WTF' test
$ truncate -s 1 /proc/self/fd/3 3test
$ cat test
W$
IMO that should have failed.
In an ideal world (I think) ffrob(N), frobat(N, , AT_EMPTY_PATH),
and frobat(AT_FDCWD, /proc/self/fd/N) should generally do the same
thing. This includes flink (even though the flink variant doesn't
exist). open is a bit special.
Of course, we're rather inconsistent with AT_EMPTY_PATH. utimensat
accepts a null filename instead of a blank filename, and it doesn't
appear to check the file mode at all.
Sigh.
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] gpio: pcf857x: Add OF support
On 08/25/2013 02:15 AM, Laurent Pinchart wrote:
On Saturday 24 August 2013 16:13:11 Tomasz Figa wrote:
On Saturday 24 of August 2013 02:54:07 Laurent Pinchart wrote:
On Saturday 24 August 2013 02:41:59 Tomasz Figa wrote:
On Tuesday 20 of August 2013 01:04:54 Laurent Pinchart wrote:
Add DT bindings for the pcf857x-compatible chips and parse the
device tree node in the driver.
Signed-off-by: Laurent Pinchart
laurent.pinchart+rene...@ideasonboard.com ---
.../devicetree/bindings/gpio/gpio-pcf857x.txt | 71 +
drivers/gpio/gpio-pcf857x.c| 57 ++---
2 files changed, 119 insertions(+), 9 deletions(-)
create mode 100644
[snip]
diff --git a/drivers/gpio/gpio-pcf857x.c
b/drivers/gpio/gpio-pcf857x.c
index 070e81f..50a90f1 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
[snip]
@@ -50,6 +52,27 @@ static const struct i2c_device_id pcf857x_id[] =
{
};
MODULE_DEVICE_TABLE(i2c, pcf857x_id);
+#ifdef CONFIG_OF
+static const struct of_device_id pcf857x_of_table[] = {
+ { .compatible = nxp,pcf8574, .data = (void *)8 },
+ { .compatible = nxp,pcf8574a, .data = (void *)8 },
+ { .compatible = nxp,pca8574, .data = (void *)8 },
+ { .compatible = nxp,pca9670, .data = (void *)8 },
+ { .compatible = nxp,pca9672, .data = (void *)8 },
+ { .compatible = nxp,pca9674, .data = (void *)8 },
+ { .compatible = nxp,pcf8575, .data = (void *)16 },
+ { .compatible = nxp,pca8575, .data = (void *)16 },
+ { .compatible = nxp,pca9671, .data = (void *)16 },
+ { .compatible = nxp,pca9673, .data = (void *)16 },
+ { .compatible = nxp,pca9675, .data = (void *)16 },
+ { .compatible = maxim,max7328, .data = (void *)8 },
+ { .compatible = maxim,max7329, .data = (void *)8 },
+ { .compatible = ti,tca9554, .data = (void *)8 },
+ { }
+};
+MODULE_DEVICE_TABLE(of, pcf857x_of_table);
+#endif
+
/*
* The pcf857x, pca857x, and pca967x chips only expose one read and
* one write register. Writing a one bit (to match the reset
@@ -257,14 +280,29 @@ fail:
static int pcf857x_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- struct pcf857x_platform_data*pdata;
+ struct pcf857x_platform_data*pdata = client-dev.platform_data;
+ struct device_node *np = client-dev.of_node;
struct pcf857x *gpio;
+ unsigned intn_latch = 0;
+ unsigned intngpio;
int status;
- pdata = client-dev.platform_data;
- if (!pdata) {
+#ifdef CONFIG_OF
+ if (np) {
Wouldn't if (IS_ENABLED(CONFIG_OF) np) be sufficient here, without
the #ifdef? You would have to move the match table out of the #ifdef
in this case, though...
That's the exact reason why I've used #ifdef CONFIG_OF here, I didn't
want to add the overhead of the pcf857x_of_table when CONFIG_OF isn't
defined.
I'm not sure if I remember correctly, but I think there was something said
in one of discussions some time ago, that we should be moving away from
ifdef'ing such things, in favour of just having them compiled
unconditionally.
There seems to be a general consensus to favor if (IS_ENABLED(CONFIG_OF))
instead of #ifdef CONFIG_OF when possible. I'm not sure what the opinion is
regarding using conditional compilation to avoid compiling unnecessary data
tables in. I would vote for using it (there's no need to bloat the kernel
unnecessarily on non-OF platforms), but I'll conform to whatever is decided to
be best.
[Adding DT maintainers on Cc for more opinions.]
I'll resubmit the patch with the DT bindings documentation fixed, and will
submit yet another version if I need to remove the #ifdef.
I think it makes sense to keep this table compiled in conditionally,
size of
struct of_device_id is relatively large. While absolute increase in size
might not be that significant the relative increase is quite large -
appr. 130%.
Before $subject patch:
$ size drivers/gpio/gpio-pcf857x.o
textdata bss dec hex filename
2228 140 02368 940 drivers/gpio/gpio-pcf857x.o
After applying the patch:
$ size drivers/gpio/gpio-pcf857x.o
textdata bss dec hex filename
5284 140 054241530 drivers/gpio/gpio-pcf857x.o
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] gpio: pcf857x: Add OF support
On 08/25/2013 02:26 AM, Laurent Pinchart wrote:
Add DT bindings for the pcf857x-compatible chips and parse the device
tree node in the driver.
Signed-off-by: Laurent Pinchartlaurent.pinchart+rene...@ideasonboard.com
---
.../devicetree/bindings/gpio/gpio-pcf857x.txt | 71 ++
drivers/gpio/gpio-pcf857x.c| 57 ++---
2 files changed, 119 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
Changes since v2
- Replace mention about interrupts software configuration in DT bindings
documentation with an explanation of the hardware configuration.
[...]
@@ -257,14 +280,29 @@ fail:
static int pcf857x_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- struct pcf857x_platform_data*pdata;
+ struct pcf857x_platform_data*pdata = dev_get_platdata(client-dev);
+ struct device_node *np = client-dev.of_node;
struct pcf857x *gpio;
+ unsigned intn_latch = 0;
+ unsigned intngpio;
int status;
- pdata = dev_get_platdata(client-dev);
- if (!pdata) {
+#ifdef CONFIG_OF
+ if (np) {
+ const struct of_device_id *of_id;
+
+ of_id = of_match_device(pcf857x_of_table,client-dev);
+ ngpio = (unsigned int)of_id-data;
It is potentially unsafe, since of_match_device() can return NULL.
+ } else
+#endif
+ ngpio = id-driver_data;
CodingStyle: braces are missing for the second part of the if statement.
How about something along the lines of:
const struct of_device_id *of_id;
of_id = of_match_device(of_match_ptr(pcf857x_of_table), client-dev);
if (of_id)
ngpio = (unsigned int)of_id-data;
else
ngpio = id-driver_data;
to get rid of the #ifdef ?
But still DT has priority over platform data here.
+
+ if (pdata)
+ n_latch = pdata-n_latch;
+ else if (IS_ENABLED(CONFIG_OF) np)
+ of_property_read_u32(np, pins-initial-state,n_latch);
And here platform data has priority over DT.
+ else
dev_dbg(client-dev, no platform data\n);
- }
/* Allocate, initialize, and register this gpio_chip. */
gpio = devm_kzalloc(client-dev, sizeof(*gpio), GFP_KERNEL);
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] DMA: shdma: fix CHCLR register address calculation
On Tue, Jul 02, 2013 at 05:37:58PM +0200, Guennadi Liakhovetski wrote: struct sh_dmae_device::chan_reg is a pointer to u32, therefore when adding offsets to it care should be taken to add offsets in sizeof(u32) units, not in bytes. This patch corrects such a bug. While at it we also remove the redundant parameter of the affected function. Applied, thanks ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] DMA: shdma: several stylistic improvements and support for new SoCs
On Tue, Jul 02, 2013 at 05:45:49PM +0200, Guennadi Liakhovetski wrote: Hi The first two patches in this small series improve driver internals a bit by using preferred APIs, the 3rd patch adds support for new DMAC versions, present on AG5, APE6, H2. Applied, thanks Although the patch 1 didnt apply for me :( I have manually remove a hunk, I dont which tree yoy genertaed this agaisnt! ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] DMA: shdma: make a pointer const
On Fri, Aug 02, 2013 at 04:18:09PM +0200, Guennadi Liakhovetski wrote: Platform data shouldn't be changed at run-time, so, pointers to it should be const. Applied, thanks ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/7] DMA: shdma: switch DT to use OF device ID tables
On Fri, Aug 02, 2013 at 04:50:35PM +0200, Guennadi Liakhovetski wrote: In this version of shdma Device Tree support I preserved the DT configuration approach via OF device ID tables from v4, but now it is only used for the DT-mode, the C-version is left untouched. In this series I only include one platform: r8a73a4-based APE6EVM, if accepted, others can be added easily. I also took care not to include mach/*.h headers in driver .c files. To illustrate the use of DT DMA support for MMC DMA on APE6EVM a patch from a previously separate patch series DMA for MMCIF and SDHI devices in DT mode I have applied all the dma patches, the ARM ones fail for me so should possible go thru ARM tree. thanks ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [trivial]treewide: Fix typo in Kconfig
Correct spelling typo in various Kconfig files. Signed-off-by: Masanari Iida standby2...@gmail.com --- arch/arm/mach-sti/Kconfig| 4 ++-- drivers/cpufreq/Kconfig.x86 | 2 +- drivers/dma/Kconfig | 2 +- drivers/fmc/Kconfig | 2 +- drivers/infiniband/ulp/isert/Kconfig | 4 ++-- drivers/media/i2c/Kconfig| 2 +- drivers/mfd/Kconfig | 4 ++-- drivers/usb/core/Kconfig | 2 +- init/Kconfig | 2 +- net/vmw_vsock/Kconfig| 2 +- 10 files changed, 13 insertions(+), 13 deletions(-) diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig index 835833e..a67f83f 100644 --- a/arch/arm/mach-sti/Kconfig +++ b/arch/arm/mach-sti/Kconfig @@ -30,7 +30,7 @@ config SOC_STIH415 default y help This enables support for STMicroelectronics Digital Consumer - Electronics family StiH415 parts, primarily targetted at set-top-box + Electronics family StiH415 parts, primarily targeted at set-top-box and other digital audio/video applications using Flattned Device Trees. @@ -39,7 +39,7 @@ config SOC_STIH416 default y help This enables support for STMicroelectronics Digital Consumer - Electronics family StiH416 parts, primarily targetted at set-top-box + Electronics family StiH416 parts, primarily targeted at set-top-box and other digital audio/video applications using Flattened Device Trees. diff --git a/drivers/cpufreq/Kconfig.x86 b/drivers/cpufreq/Kconfig.x86 index e2b6eab..b80bb4d 100644 --- a/drivers/cpufreq/Kconfig.x86 +++ b/drivers/cpufreq/Kconfig.x86 @@ -136,7 +136,7 @@ config X86_AMD_FREQ_SENSITIVITY help This adds AMD-specific powersave bias function to the ondemand governor, which allows it to make more power-conscious frequency - change decisions based on feedback from hardware (availble on AMD + change decisions based on feedback from hardware (available on AMD Family 16h and above). Hardware feedback tells software how sensitive to frequency changes diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 77bc480..6a737d9 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -300,7 +300,7 @@ config MMP_PDMA depends on (ARCH_MMP || ARCH_PXA) select DMA_ENGINE help - Support the MMP PDMA engine for PXA and MMP platfrom. + Support the MMP PDMA engine for PXA and MMP platform. config DMA_JZ4740 tristate JZ4740 DMA support diff --git a/drivers/fmc/Kconfig b/drivers/fmc/Kconfig index c01cf45..3a75f42 100644 --- a/drivers/fmc/Kconfig +++ b/drivers/fmc/Kconfig @@ -46,6 +46,6 @@ config FMC_CHARDEV This driver matches every mezzanine device and allows user space to read and write registers using a char device. It can be used to write user-space drivers, or just get - aquainted with a mezzanine before writing its specific driver. + acquainted with a mezzanine before writing its specific driver. endif # FMC diff --git a/drivers/infiniband/ulp/isert/Kconfig b/drivers/infiniband/ulp/isert/Kconfig index ce3fd32..02f9759 100644 --- a/drivers/infiniband/ulp/isert/Kconfig +++ b/drivers/infiniband/ulp/isert/Kconfig @@ -1,5 +1,5 @@ config INFINIBAND_ISERT - tristate iSCSI Extentions for RDMA (iSER) target support + tristate iSCSI Extensions for RDMA (iSER) target support depends on INET INFINIBAND_ADDR_TRANS TARGET_CORE ISCSI_TARGET ---help--- - Support for iSCSI Extentions for RDMA (iSER) Target on Infiniband fabrics. + Support for iSCSI Extensions for RDMA (iSER) Target on Infiniband fabrics. diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index b2cd8ca..70c4671 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -623,7 +623,7 @@ config VIDEO_UPD64083 To compile this driver as a module, choose M here: the module will be called upd64083. -comment Miscelaneous helper chips +comment Miscellaneous helper chips config VIDEO_THS7303 tristate THS7303/53 Video Amplifier diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index e0e46f5..36d8edb 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -665,14 +665,14 @@ menu STMicroelectronics STMPE Interface Drivers depends on MFD_STMPE config STMPE_I2C - bool STMicroelectronics STMPE I2C Inteface + bool STMicroelectronics STMPE I2C Interface depends on I2C=y default y help This is used to enable I2C interface of STMPE config STMPE_SPI - bool STMicroelectronics STMPE SPI Inteface + bool STMicroelectronics STMPE SPI Interface depends on SPI_MASTER help This is used to enable SPI interface of STMPE diff --git a/drivers/usb/core/Kconfig
Re: [tps_init] BUG: unable to handle kernel paging request at 484970c9
On Sat, Aug 24, 2013 at 09:09:39PM -0700, Greg Kroah-Hartman wrote:
Same as before, are you unloading and loading modules? We have a fix
for modules that cause problems when unloading with the config option
above enabled. But that shouldn't be this issue.
What seems to be is going on here is that something creates a kobject,
which gets exported into sysfs, then removed and then immediately
recreated.
It appears that sysfs entries are deleted in the cleanup function:
static void kobject_cleanup(struct kobject *kobj)
{
...
/* remove from sysfs if the caller did not do it */
if (kobj-state_in_sysfs) {
pr_debug(kobject: '%s' (%p): auto cleanup kobject_del\n,
kobject_name(kobj), kobj);
kobject_del(kobj);
}
which is now delayed. I don't think this is specifically a problem of
my patch - I think my patch is revealing a problem here.
Let's take it from the point of view of a struct device. Lets say that
a device with name foo gets created. This creates a sysfs directory
entry called foo. Various things take a reference on the device.
You then unregister that struct device because it's been removed. As
all the references haven't yet been released, it means that the sysfs
directory persists. Now, if the device is recreated with the same
name, sysfs complains that the directory exists.
In this case, it's not a struct device, but a device driver itself:
/* some boards have startup glitches */
while (tries--) {
status = i2c_add_driver(tps65010_driver);
if (the_tps)
break;
i2c_del_driver(tps65010_driver);
if (!tries) {
printk(KERN_ERR %s: no chip?\n, DRIVER_NAME);
return -ENODEV;
}
pr_debug(%s: re-probe ...\n, DRIVER_NAME);
msleep(10);
}
Notice how the (i2c) driver is registered and removed multiple times.
If something can independently grab a reference to the kobject associated
with that driver, then it can cause the sysfs directory to persist longer
than the re-probe, which will cause sysfs to complain.
I don't think moving the sysfs directory cleanup (via kobject_del()) before
the delayed release fixes the fundamental problem here, because that just
covers up what happens if a reference is held.
Commit 0f4dafc05 (Kobject: auto-cleanup on final unref) introduced the
kobject_del() into the cleanup function.
Any thoughts?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] dma: sh: remove unnecessary platform_set_drvdata()
On Wed, Aug 21, 2013 at 06:51:56PM +0900, Jingoo Han wrote: The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Can you pls rebase this as resend. I have applied bunch of sh-dma patches and this doenst apply for me ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[3.10][PATCH 3/4] mei: me: fix waiting for hw ready
stable: 3.10
commit dab9bf41b23fe700c4a74133e41eb6a21706031e upstream
1. MEI_INTEROP_TIMEOUT is in seconds not in jiffies
so we use mei_secs_to_jiffies macro
While cold boot is fast this is relevant in resume
2. wait_event_interruptible_timeout can return with
-ERESTARTSYS so do not override it with -ETIMEDOUT
3.Adjust error message
Cc: sta...@vger.kernel.org
Tested-by: Shuah Khan shuah...@samsung.com
Signed-off-by: Tomas Winkler tomas.wink...@intel.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/misc/mei/hw-me.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 0310859..700fe55 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -238,14 +238,18 @@ static int mei_me_hw_ready_wait(struct mei_device *dev)
if (mei_me_hw_is_ready(dev))
return 0;
+ dev-recvd_hw_ready = false;
mutex_unlock(dev-device_lock);
err = wait_event_interruptible_timeout(dev-wait_hw_ready,
- dev-recvd_hw_ready, MEI_INTEROP_TIMEOUT);
+ dev-recvd_hw_ready,
+ mei_secs_to_jiffies(MEI_INTEROP_TIMEOUT));
mutex_lock(dev-device_lock);
if (!err !dev-recvd_hw_ready) {
+ if (!err)
+ err = -ETIMEDOUT;
dev_err(dev-pdev-dev,
- wait hw ready failed. status = 0x%x\n, err);
- return -ETIMEDOUT;
+ wait hw ready failed. status = %d\n, err);
+ return err;
}
dev-recvd_hw_ready = false;
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[3.10][PATCH 4/4] mei: me: fix hardware reset flow
stable: 3.10 commit ff96066e3171acdea356b331163495957cb833d0 char-misc Both H_IS and H_IE needs to be set to receive H_RDY interrupt 1. Assert H_IS to clear the interrupts during hw reset and use mei_me_reg_write instead of mei_hcsr_set as the later strips down the H_IS 2. fix interrupt disablement embarrassing typo hcsr |= ~H_IE - hcsr = ~H_IE; this will remove the unwanted interrupt on power down 3. remove useless debug print outs Cc: sta...@vger.kernel.org Cc: Shuah Khan shuah...@samsung.com Cc: Konstantin Khlebnikov khlebni...@openvz.org Signed-off-by: Tomas Winkler tomas.wink...@intel.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Conflicts: drivers/misc/mei/hw-me.c --- drivers/misc/mei/hw-me.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c index 700fe55..1bf3f8b 100644 --- a/drivers/misc/mei/hw-me.c +++ b/drivers/misc/mei/hw-me.c @@ -176,16 +176,14 @@ static void mei_me_hw_reset(struct mei_device *dev, bool intr_enable) struct mei_me_hw *hw = to_me_hw(dev); u32 hcsr = mei_hcsr_read(hw); - dev_dbg(dev-pdev-dev, before reset HCSR = 0x%08x.\n, hcsr); - - hcsr |= (H_RST | H_IG); + hcsr |= H_RST | H_IG | H_IS; if (intr_enable) hcsr |= H_IE; else - hcsr |= ~H_IE; + hcsr = ~H_IE; - mei_hcsr_set(hw, hcsr); + mei_me_reg_write(hw, H_CSR, hcsr); if (dev-dev_state == MEI_DEV_POWER_DOWN) mei_me_hw_reset_release(dev); -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[3.10][PATCH 1/4] mei: me: fix reset state machine
stable: 3.10
commit 315a383ad7dbd484fafb93ef08038e3dbafbb7a8 upstream
ME HW ready bit is down after hw reset was asserted or on error.
Only on error we need to enter the reset flow, additional reset
need to be prevented when reset was triggered during
initialization , power up/down or a reset is already in progress
Cc: sta...@vger.kernel.org
Tested-by: Shuah Khan shuah...@samsung.com
Signed-off-by: Tomas Winkler tomas.wink...@intel.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/misc/mei/hw-me.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 822170f..0310859 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -482,7 +482,9 @@ irqreturn_t mei_me_irq_thread_handler(int irq, void *dev_id)
/* check if ME wants a reset */
if (!mei_hw_is_ready(dev)
dev-dev_state != MEI_DEV_RESETTING
- dev-dev_state != MEI_DEV_INITIALIZING) {
+ dev-dev_state != MEI_DEV_INITIALIZING
+ dev-dev_state != MEI_DEV_POWER_DOWN
+ dev-dev_state != MEI_DEV_POWER_UP) {
dev_dbg(dev-pdev-dev, FW not ready.\n);
mei_reset(dev, 1);
mutex_unlock(dev-device_lock);
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[3.10][PATCH 2/4] mei: don't have to clean the state on power up
stable: 3.10
commit 99f22c4ef24cf87b0dae6aabe6b5e620b62961d9 upstream
When powering up, we don't have to clean up the device state
nothing is connected.
Cc: sta...@vger.kernel.org
Tested-by: Shuah Khan shuah...@samsung.com
Signed-off-by: Tomas Winkler tomas.wink...@intel.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/misc/mei/init.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c
index f580d30..6eec689 100644
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@ -143,7 +143,8 @@ void mei_reset(struct mei_device *dev, int
interrupts_enabled)
dev-hbm_state = MEI_HBM_IDLE;
- if (dev-dev_state != MEI_DEV_INITIALIZING) {
+ if (dev-dev_state != MEI_DEV_INITIALIZING
+ dev-dev_state != MEI_DEV_POWER_UP) {
if (dev-dev_state != MEI_DEV_DISABLED
dev-dev_state != MEI_DEV_POWER_DOWN)
dev-dev_state = MEI_DEV_RESETTING;
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[3.10][PATCH 0/4] resume reset fixes for stable 3.10
Tomas Winkler (4): mei: me: fix reset state machine mei: don't have to clean the state on power up mei: me: fix waiting for hw ready mei: me: fix hardware reset flow drivers/misc/mei/hw-me.c | 22 +- drivers/misc/mei/init.c | 3 ++- 2 files changed, 15 insertions(+), 10 deletions(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: ipu: remove unnecessary platform_set_drvdata()
On Wed, Aug 21, 2013 at 06:52:54PM +0900, Jingoo Han wrote: The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Applied, thanks ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] um: prctl: Do not include linux/ptrace.h
Tested-by: David Oberhollenzer david.oberhollen...@tele2.at -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] gpio: mcp23s08: rename the device tree property
Am Freitag 23 August 2013, 21:10:00 schrieb Linus Walleij: On Thu, Aug 22, 2013 at 11:56 AM, Lars Poeschel la...@wh2.tu-dresden.de wrote: From: Lars Poeschel poesc...@lemonage.de The device tree property should be more descriptive. microchip seems more reasonable than mcp. As there are no in tree users of this property, so the rename can still be done without pain. Signed-off-by: Lars Poeschel poesc...@lemonage.de So do I apply this to the GPIO tree now or what? Are the DT custodians happy? No Linus, do not take this. There will be a new version. Thanks, Lars -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] scsi: ufs: read door bell register after clearing interrupt aggregation
In interrupt context, after reading and comparing the UTRLDBR to
hba-outstanding_request and before resetting the interrupt aggregation,
there might be completion of another transfer request (TR). Such TRs might
get stuck, pending, until the next interrupt is generated.
The fix reads the UTRLDBR after resetting the interrupt aggregation and
handles completed TRs.
Signed-off-by: Dolev Raviv dra...@codeaurora.org
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 4dca9b4..30c84d8 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1915,6 +1915,13 @@ static void ufshcd_uic_cmd_compl(struct ufs_hba *hba)
/**
* ufshcd_transfer_req_compl - handle SCSI and query command completion
* @hba: per adapter instance
+ *
+ * Resetting interrupt aggregation counters first and reading the DOOR_BELL
+ * afterward , allows us to handle all the completed requests.
+ * In order to prevent other interrupts starvation the DB is read once
+ * after reset. The down side of this solution is the possibility of false
+ * interrupt if device completes another request after resetting aggregation
+ * and before reading the DB.
*/
static void ufshcd_transfer_req_compl(struct ufs_hba *hba)
{
@@ -1924,47 +1931,36 @@ static void ufshcd_transfer_req_compl(struct ufs_hba
*hba)
u32 tr_doorbell;
int result;
int index;
- bool int_aggr_reset = false;
+
+ /* Reset interrupt aggregation counters */
+ ufshcd_config_int_aggr(hba, INT_AGGR_RESET);
tr_doorbell = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
completed_reqs = tr_doorbell ^ hba-outstanding_reqs;
- for (index = 0; index hba-nutrs; index++) {
- if (test_bit(index, completed_reqs)) {
- lrbp = hba-lrb[index];
- cmd = lrbp-cmd;
- /*
-* Don't skip resetting interrupt aggregation counters
-* if a regular command is present.
-*/
- int_aggr_reset |= !lrbp-intr_cmd;
-
- if (cmd) {
- result = ufshcd_transfer_rsp_status(hba, lrbp);
- scsi_dma_unmap(cmd);
- cmd-result = result;
- /* Mark completed command as NULL in LRB */
- lrbp-cmd = NULL;
- clear_bit_unlock(index, hba-lrb_in_use);
- /* Do not touch lrbp after scsi done */
- cmd-scsi_done(cmd);
- } else if (lrbp-command_type ==
- UTP_CMD_TYPE_DEV_MANAGE) {
- if (hba-dev_cmd.complete)
- complete(hba-dev_cmd.complete);
- }
- } /* end of if */
- } /* end of for */
+ for_each_set_bit(index, completed_reqs, hba-nutrs) {
+ lrbp = hba-lrb[index];
+ cmd = lrbp-cmd;
+ if (cmd) {
+ result = ufshcd_transfer_rsp_status(hba, lrbp);
+ scsi_dma_unmap(cmd);
+ cmd-result = result;
+ /* Mark completed command as NULL in LRB */
+ lrbp-cmd = NULL;
+ clear_bit_unlock(index, hba-lrb_in_use);
+ /* Do not touch lrbp after scsi done */
+ cmd-scsi_done(cmd);
+ } else if (lrbp-command_type == UTP_CMD_TYPE_DEV_MANAGE) {
+ if (hba-dev_cmd.complete)
+ complete(hba-dev_cmd.complete);
+ }
+ } /* end of for_each_set_bit */
/* clear corresponding bits of completed commands */
hba-outstanding_reqs ^= completed_reqs;
/* we might have free'd some tags above */
wake_up(hba-dev_cmd.tag_wq);
-
- /* Reset interrupt aggregation counters */
- if (int_aggr_reset)
- ufshcd_config_int_aggr(hba, INT_AGGR_RESET);
}
/**
@@ -2569,6 +2565,7 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
int poll_cnt;
u8 resp = 0xF;
struct ufshcd_lrb *lrbp;
+ u32 reg;
host = cmd-device-host;
hba = shost_priv(host);
@@ -2578,6 +2575,13 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
if (!(test_bit(tag, hba-outstanding_reqs)))
goto out;
+ reg = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
+ if (!(reg (1 tag))) {
+ dev_err(hba-dev,
+ %s: cmd was completed, but without a notifying intr, tag = %d,
+ __func__, tag);
+ }
+
lrbp = hba-lrb[tag];
for (poll_cnt = 100; poll_cnt; poll_cnt--) {
err = ufshcd_issue_tm_cmd(hba, lrbp-lun, lrbp-task_tag,
@@ -2586,8
[PATCH] ath5k: debugfs: NULL-terminate strings
Avoid processing garbage data by NULL terminating the strings.
Signed-off-by: Djalal Harouni tix...@opendz.org
---
Patch compile tested only.
drivers/net/wireless/ath/ath5k/debug.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/debug.c
b/drivers/net/wireless/ath/ath5k/debug.c
index 9d00dab..b8d031a 100644
--- a/drivers/net/wireless/ath/ath5k/debug.c
+++ b/drivers/net/wireless/ath/ath5k/debug.c
@@ -245,9 +245,11 @@ static ssize_t write_file_beacon(struct file *file,
struct ath5k_hw *ah = file-private_data;
char buf[20];
- if (copy_from_user(buf, userbuf, min(count, sizeof(buf
+ count = min_t(size_t, count, sizeof(buf) - 1);
+ if (copy_from_user(buf, userbuf, count))
return -EFAULT;
+ buf[count] = '\0';
if (strncmp(buf, disable, 7) == 0) {
AR5K_REG_DISABLE_BITS(ah, AR5K_BEACON, AR5K_BEACON_ENABLE);
pr_info(debugfs disable beacons\n);
@@ -345,9 +347,11 @@ static ssize_t write_file_debug(struct file *file,
unsigned int i;
char buf[20];
- if (copy_from_user(buf, userbuf, min(count, sizeof(buf
+ count = min_t(size_t, count, sizeof(buf) - 1);
+ if (copy_from_user(buf, userbuf, count))
return -EFAULT;
+ buf[count] = '\0';
for (i = 0; i ARRAY_SIZE(dbg_info); i++) {
if (strncmp(buf, dbg_info[i].name,
strlen(dbg_info[i].name)) == 0) {
@@ -448,9 +452,11 @@ static ssize_t write_file_antenna(struct file *file,
unsigned int i;
char buf[20];
- if (copy_from_user(buf, userbuf, min(count, sizeof(buf
+ count = min_t(size_t, count, sizeof(buf) - 1);
+ if (copy_from_user(buf, userbuf, count))
return -EFAULT;
+ buf[count] = '\0';
if (strncmp(buf, diversity, 9) == 0) {
ath5k_hw_set_antenna_mode(ah, AR5K_ANTMODE_DEFAULT);
pr_info(debug: enable diversity\n);
@@ -619,9 +625,11 @@ static ssize_t write_file_frameerrors(struct file *file,
struct ath5k_statistics *st = ah-stats;
char buf[20];
- if (copy_from_user(buf, userbuf, min(count, sizeof(buf
+ count = min_t(size_t, count, sizeof(buf) - 1);
+ if (copy_from_user(buf, userbuf, count))
return -EFAULT;
+ buf[count] = '\0';
if (strncmp(buf, clear, 5) == 0) {
st-rxerr_crc = 0;
st-rxerr_phy = 0;
@@ -766,9 +774,11 @@ static ssize_t write_file_ani(struct file *file,
struct ath5k_hw *ah = file-private_data;
char buf[20];
- if (copy_from_user(buf, userbuf, min(count, sizeof(buf
+ count = min_t(size_t, count, sizeof(buf) - 1);
+ if (copy_from_user(buf, userbuf, count))
return -EFAULT;
+ buf[count] = '\0';
if (strncmp(buf, sens-low, 8) == 0) {
ath5k_ani_init(ah, ATH5K_ANI_MODE_MANUAL_HIGH);
} else if (strncmp(buf, sens-high, 9) == 0) {
@@ -862,9 +872,11 @@ static ssize_t write_file_queue(struct file *file,
struct ath5k_hw *ah = file-private_data;
char buf[20];
- if (copy_from_user(buf, userbuf, min(count, sizeof(buf
+ count = min_t(size_t, count, sizeof(buf) - 1);
+ if (copy_from_user(buf, userbuf, count))
return -EFAULT;
+ buf[count] = '\0';
if (strncmp(buf, start, 5) == 0)
ieee80211_wake_queues(ah-hw);
else if (strncmp(buf, stop, 4) == 0)
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] dma/Kconfig: TI_EDMA needs to be boolean
On Thu, Aug 22, 2013 at 02:03:24PM -0700, Guenter Roeck wrote: Fix: arch/arm/common/built-in.o: undefined reference to `edma_filter_fn' seen with make ARCH=arm allmodconfig Commit 6cba4355 (ARM: edma: Add DT and runtime PM support to the private EDMA API) adds a dependency on edma_filter_fn() into arch/arm/common/edma.c. Since this file is always built into the kernel, edma_filter_fn() must be built into the kernel as well. Applied, thanks ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: ste_dma: Fix warning when CONFIG_ARM_LPAE=y
On Wed, Aug 21, 2013 at 09:34:02PM -0300, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com When CONFIG_ARM_LPAE=y the following build warning are generated: drivers/dma/ste_dma40.c:3228:2: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t' [-Wformat] drivers/dma/ste_dma40.c:3582:3: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t' [-Wformat] drivers/dma/ste_dma40.c:3582:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'resource_size_t' [-Wformat] drivers/dma/ste_dma40.c:3593:5: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'resource_size_t' [-Wformat] According to Documentation/printk-formats.txt '%pa' can be used to properly print 'resource_size_t'. Also, for printing memory region the '%pr' is more convenient. Applied, Thanks ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
