Re: [PATCH 2/3] cap1106: support for active-high interrupt option
On Sun, Sep 21, 2014 at 12:06:30PM +0200, Daniel Mack wrote:
> On 09/21/2014 05:01 AM, Matt Ranostay wrote:
> > Some applications need to use the active-high push-pull interrupt
> > option. This allows it be enabled in the device tree child node.
> >
> > Signed-off-by: Matt Ranostay
> > ---
> > drivers/input/keyboard/cap1106.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/input/keyboard/cap1106.c
> > b/drivers/input/keyboard/cap1106.c
> > index b9c43b5..33e2590 100644
> > --- a/drivers/input/keyboard/cap1106.c
> > +++ b/drivers/input/keyboard/cap1106.c
> > @@ -234,6 +234,12 @@ static int cap1106_i2c_probe(struct i2c_client
> > *i2c_client,
> > dev_err(dev, "Invalid sensor-gain value %d\n", gain32);
> > }
> >
> > + if (of_property_read_bool(node, "microchip,active-high")) {
>
> I think the name of that property should make clear it's only changing
> the interrupt output driver configuration. What about
> "microchip,irq-active-high"?
Can we infer the setting from IRQ flags by chance?
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clk: use uninitialized_var instead setting 'flags' to 0 directly.
Setting 'flags' to zero will be certainly a misleading way to avoid
warning of 'flags' may be used uninitialized. uninitialized_var is
a correct way because the warning is a false possitive.
Signed-off-by: Xiubo Li
---
drivers/clk/clk-gate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 4a58c55..51fd87f 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -45,7 +45,7 @@ static void clk_gate_endisable(struct clk_hw *hw, int enable)
{
struct clk_gate *gate = to_clk_gate(hw);
int set = gate->flags & CLK_GATE_SET_TO_DISABLE ? 1 : 0;
- unsigned long flags = 0;
+ unsigned long uninitialized_var(flags);
u32 reg;
set ^= enable;
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
pull request: bluetooth-next 2014-09-22
Hi John, Here are some more patches for 3.18. They include various fixes to the btusb HCI driver, a fix for LE SMP, as well as adding Jukka to the MAINTAINERS file for generic 6LoWPAN (as requested by Alexander Aring). I've held on to this pull request a bit since we were waiting for a SCO related fix to get sorted out first. However, since the merge window is getting closer I decided not to wait for it. If we do get the fix sorted out there'll probably be a second small pull request later this week. Let me know if there are any issues pulling. Thanks. Johan --- The following changes since commit 9a783a139c32a905825ee0aa9597f485ea461f76: Bluetooth: Fix re-setting RPA as expired when deferring update (2014-09-12 18:34:25 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream for you to fetch changes up to 5eb596f55cacc2389554a8d7572d90d5e9d4269d: Bluetooth: Fix setting correct security level when initiating SMP (2014-09-18 17:39:37 +0200) Johan Hedberg (2): Bluetooth: btusb: Use GFP_KERNEL in btusb_send_frame() Bluetooth: Fix setting correct security level when initiating SMP Jukka Rissanen (1): MAINTAINERS: add maintainer for generic 6LoWPAN Marcel Holtmann (7): Bluetooth: btusb: Separate TX URB allocation and submission Bluetooth: Add BUILD_BUG_ON check for SKB control buffer size Bluetooth: Provide HCI command opcode information to driver Bluetooth: btusb: Fix old coding style issues Bluetooth: btusb: Split fragement receiption into separate functions Bluetooth: btusb: Implement driver internal packet reassembly Bluetooth: Remove exported hci_recv_fragment function MAINTAINERS | 1 + drivers/bluetooth/btusb.c | 511 +- include/net/bluetooth/bluetooth.h | 1 + include/net/bluetooth/hci_core.h | 1 - net/bluetooth/af_bluetooth.c | 3 + net/bluetooth/hci_core.c | 21 +- net/bluetooth/smp.c | 5 +- 7 files changed, 385 insertions(+), 158 deletions(-) pgpFV70uOsJ0a.pgp Description: PGP signature
[PATCH v5 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.
We also defer the probe for our host in case we end up getting
EPROBE_DEFER error when getting PHYs.
Signed-off-by: Vivek Gautam
Acked-by: Jingoo Han
Acked-by: Alan Stern
---
Changes since v4:
- returning 'ret' instead of PTR_ERR(phy), since ret is nothing but that only.
Changes since v3:
- Addressed review comments by Alan:
-- Skipped renaming 'phy_number' variable,
-- resorted to just adding minimal change required for phy assignment.
-- updated patch description to mention EPROBE_DEFER support.
drivers/usb/host/ehci-exynos.c | 74 +++-
1 file changed, 20 insertions(+), 54 deletions(-)
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 2eed9a4..7189f2e 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -21,11 +21,8 @@
#include
#include
#include
-#include
-#include
#include
#include
-#include
#include "ehci.h"
@@ -47,9 +44,7 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
struct exynos_ehci_hcd {
struct clk *clk;
- struct usb_phy *phy;
- struct usb_otg *otg;
- struct phy *phy_g[PHY_NUMBER];
+ struct phy *phy[PHY_NUMBER];
};
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)->priv)
@@ -60,8 +55,9 @@ static int exynos_ehci_get_phy(struct device *dev,
struct device_node *child;
struct phy *phy;
int phy_number;
- int ret = 0;
+ int ret;
+ /* Get PHYs for the controller */
for_each_available_child_of_node(dev->of_node, child) {
ret = of_property_read_u32(child, "reg", _number);
if (ret) {
@@ -77,31 +73,21 @@ static int exynos_ehci_get_phy(struct device *dev,
}
phy = devm_of_phy_get(dev, child, NULL);
+ exynos_ehci->phy[phy_number] = phy;
of_node_put(child);
- if (IS_ERR(phy))
- /* Lets fallback to older USB-PHYs */
- goto usb_phy_old;
- exynos_ehci->phy_g[phy_number] = phy;
- /* Make the older PHYs unavailable */
- exynos_ehci->phy = ERR_PTR(-ENXIO);
- }
-
- return 0;
-
-usb_phy_old:
- exynos_ehci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- if (IS_ERR(exynos_ehci->phy)) {
- ret = PTR_ERR(exynos_ehci->phy);
- if (ret != -ENXIO && ret != -ENODEV) {
- dev_err(dev, "no usb2 phy configured\n");
- return ret;
+ if (IS_ERR(phy)) {
+ ret = PTR_ERR(phy);
+ if (ret == -EPROBE_DEFER) {
+ return ret;
+ } else if (ret != -ENOSYS && ret != -ENODEV) {
+ dev_err(dev,
+ "Error retrieving usb2 phy: %d\n", ret);
+ return ret;
+ }
}
- dev_dbg(dev, "Failed to get usb2 phy\n");
- } else {
- exynos_ehci->otg = exynos_ehci->phy->otg;
}
- return ret;
+ return 0;
}
static int exynos_ehci_phy_enable(struct device *dev)
@@ -111,16 +97,13 @@ static int exynos_ehci_phy_enable(struct device *dev)
int i;
int ret = 0;
- if (!IS_ERR(exynos_ehci->phy))
- return usb_phy_init(exynos_ehci->phy);
-
for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
- if (!IS_ERR(exynos_ehci->phy_g[i]))
- ret = phy_power_on(exynos_ehci->phy_g[i]);
+ if (!IS_ERR(exynos_ehci->phy[i]))
+ ret = phy_power_on(exynos_ehci->phy[i]);
if (ret)
for (i--; i >= 0; i--)
- if (!IS_ERR(exynos_ehci->phy_g[i]))
- phy_power_off(exynos_ehci->phy_g[i]);
+ if (!IS_ERR(exynos_ehci->phy[i]))
+ phy_power_off(exynos_ehci->phy[i]);
return ret;
}
@@ -131,14 +114,9 @@ static void exynos_ehci_phy_disable(struct device *dev)
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
int i;
- if (!IS_ERR(exynos_ehci->phy)) {
- usb_phy_shutdown(exynos_ehci->phy);
- return;
- }
-
for (i = 0; i < PHY_NUMBER; i++)
- if (!IS_ERR(exynos_ehci->phy_g[i]))
- phy_power_off(exynos_ehci->phy_g[i]);
+ if (!IS_ERR(exynos_ehci->phy[i]))
+ phy_power_off(exynos_ehci->phy[i]);
}
static void exynos_setup_vbus_gpio(struct device *dev)
@@ -231,9 +209,6 @@
[PATCH v5 2/2] usb: host: ohci-exynos: Remove unnecessary usb-phy support
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.
We also defer the probe for our host in case we end up getting
EPROBE_DEFER error when getting PHYs.
Signed-off-by: Vivek Gautam
Acked-by: Jingoo Han
Acked-by: Alan Stern
---
Changes since v4:
- returning 'ret' instead of PTR_ERR(phy), since ret is nothing but that only.
Changes since v3:
- Addressed review comments by Alan:
-- Skipped renaming 'phy_number' variable,
-- resorted to just adding minimal change required for phy assignment.
-- updated patch description to mention EPROBE_DEFER support.
drivers/usb/host/ohci-exynos.c | 81 ++--
1 file changed, 20 insertions(+), 61 deletions(-)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 7c48e3f..d28b658 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -19,11 +19,8 @@
#include
#include
#include
-#include
-#include
#include
#include
-#include
#include "ohci.h"
@@ -38,9 +35,7 @@ static struct hc_driver __read_mostly exynos_ohci_hc_driver;
struct exynos_ohci_hcd {
struct clk *clk;
- struct usb_phy *phy;
- struct usb_otg *otg;
- struct phy *phy_g[PHY_NUMBER];
+ struct phy *phy[PHY_NUMBER];
};
static int exynos_ohci_get_phy(struct device *dev,
@@ -49,15 +44,9 @@ static int exynos_ohci_get_phy(struct device *dev,
struct device_node *child;
struct phy *phy;
int phy_number;
- int ret = 0;
+ int ret;
- /*
-* Getting generic phy:
-* We are keeping both types of phys as a part of transiting OHCI
-* to generic phy framework, so as to maintain backward compatibilty
-* with old DTB too.
-* We fallback to older USB-PHYs when we fail to get generic PHYs.
-*/
+ /* Get PHYs for the controller */
for_each_available_child_of_node(dev->of_node, child) {
ret = of_property_read_u32(child, "reg", _number);
if (ret) {
@@ -73,31 +62,21 @@ static int exynos_ohci_get_phy(struct device *dev,
}
phy = devm_of_phy_get(dev, child, NULL);
+ exynos_ohci->phy[phy_number] = phy;
of_node_put(child);
- if (IS_ERR(phy))
- /* Lets fallback to older USB-PHYs */
- goto usb_phy_old;
- exynos_ohci->phy_g[phy_number] = phy;
- /* Make the older PHYs unavailable */
- exynos_ohci->phy = ERR_PTR(-ENXIO);
- }
-
- return 0;
-
-usb_phy_old:
- exynos_ohci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- if (IS_ERR(exynos_ohci->phy)) {
- ret = PTR_ERR(exynos_ohci->phy);
- if (ret != -ENXIO && ret != -ENODEV) {
- dev_err(dev, "no usb2 phy configured\n");
- return ret;
+ if (IS_ERR(phy)) {
+ ret = PTR_ERR(phy);
+ if (ret == -EPROBE_DEFER) {
+ return ret;
+ } else if (ret != -ENOSYS && ret != -ENODEV) {
+ dev_err(dev,
+ "Error retrieving usb2 phy: %d\n", ret);
+ return ret;
+ }
}
- dev_dbg(dev, "Failed to get usb2 phy\n");
- } else {
- exynos_ohci->otg = exynos_ohci->phy->otg;
}
- return ret;
+ return 0;
}
static int exynos_ohci_phy_enable(struct device *dev)
@@ -107,16 +86,13 @@ static int exynos_ohci_phy_enable(struct device *dev)
int i;
int ret = 0;
- if (!IS_ERR(exynos_ohci->phy))
- return usb_phy_init(exynos_ohci->phy);
-
for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
- if (!IS_ERR(exynos_ohci->phy_g[i]))
- ret = phy_power_on(exynos_ohci->phy_g[i]);
+ if (!IS_ERR(exynos_ohci->phy[i]))
+ ret = phy_power_on(exynos_ohci->phy[i]);
if (ret)
for (i--; i >= 0; i--)
- if (!IS_ERR(exynos_ohci->phy_g[i]))
- phy_power_off(exynos_ohci->phy_g[i]);
+ if (!IS_ERR(exynos_ohci->phy[i]))
+ phy_power_off(exynos_ohci->phy[i]);
return ret;
}
@@ -127,14 +103,9 @@ static void exynos_ohci_phy_disable(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
int i;
- if (!IS_ERR(exynos_ohci->phy)) {
- usb_phy_shutdown(exynos_ohci->phy);
- return;
- }
-
for (i = 0; i < PHY_NUMBER; i++)
- if
[PATCH v2 1/3][RESEND] sched: fix confusing PFA_NO_NEW_PRIVS constant
From: Tetsuo Handa
Commit 1d4457f99928 ("sched: move no_new_privs into new atomic flags")
defined PFA_NO_NEW_PRIVS as hexadecimal value, but it is confusing
because it is used as bit number. Redefine it as decimal bit number.
Note this changes the bit position of PFA_NOW_NEW_PRIVS from 1 to 0.
Signed-off-by: Tetsuo Handa
Acked-by: Kees Cook
[ lizf: slightly modified subject and changelog ]
Signed-off-by: Zefan Li
---
Oops, forgot the "From" line...
---
include/linux/sched.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5c2c885..4557765 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1957,7 +1957,7 @@ static inline void memalloc_noio_restore(unsigned int
flags)
}
/* Per-process atomic flags. */
-#define PFA_NO_NEW_PRIVS 0x0001/* May not gain new privileges. */
+#define PFA_NO_NEW_PRIVS 0 /* May not gain new privileges. */
static inline bool task_no_new_privs(struct task_struct *p)
{
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/3] gpio: sch: Consolidate similar algorithms
Replied inline. :)
> -Original Message-
> From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> Sent: 18 September, 2014 7:17 PM
> To: Chang, Rebecca Swee Fun
> Cc: Linus Walleij; linux-g...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/3] gpio: sch: Consolidate similar algorithms
>
> On Wed, Sep 17, 2014 at 04:49:03PM +0800, Chang Rebecca Swee Fun wrote:
> > Consolidating similar algorithms into common functions to make GPIO
> > SCH simpler and manageable.
> >
> > Signed-off-by: Chang Rebecca Swee Fun
> >
> > ---
> > drivers/gpio/gpio-sch.c | 95
> > ++
> -
> > 1 file changed, 53 insertions(+), 42 deletions(-)
> >
> > diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c index
> > 99720c8..2189c22 100644
> > --- a/drivers/gpio/gpio-sch.c
> > +++ b/drivers/gpio/gpio-sch.c
> > @@ -43,6 +43,8 @@ struct sch_gpio {
> >
> > #define to_sch_gpio(c) container_of(c, struct sch_gpio, chip)
> >
> > +static void sch_gpio_set(struct gpio_chip *gc, unsigned gpio_num, int
> > +val);
> > +
>
> Is it possible to move the sch_gpio_set() function here instead of forward
> declaring it?
Yes, it is possible. There is a reason I submitted the code in this structure.
By putting the sch_gpio_set() function below will makes the diff patch looks
neat and easy for review.
If it doesn't make sense to make the patch for easy reviewing, I can change by
moving the function above.
>
> > static unsigned sch_gpio_offset(struct sch_gpio *sch, unsigned gpio,
> > unsigned reg)
> > {
> > @@ -63,94 +65,89 @@ static unsigned sch_gpio_bit(struct sch_gpio *sch,
> unsigned gpio)
> > return gpio % 8;
> > }
> >
> > -static void sch_gpio_enable(struct sch_gpio *sch, unsigned gpio)
> > +static void sch_gpio_enable(struct sch_gpio *sch, unsigned gpio,
> > +unsigned reg)
>
> I don't see much value in doing this.
>
> To me sch_gpio_enable(sch, gpio) is more intuitive than sch_gpio_enable(sch,
> gpio, GEN). Why do I need to pass register to enable function in the first
> place?
> It should know better how to enable the GPIO, right?
>
> Same goes for others.
The register values are required when it comes to IRQ handling. By passing in
the registers values, we can make full use of the algorithms without
introducing extra/similar algorithms to compute other register offset values.
For example, we have other offset values to handle such as:-
GTPE0x0C
GTNE0x10
GGPE0x14
GSMI0x18
GTS 0x1C
CGNMIEN 0x40
RGNMIEN 0x44
Regards
Rebecca
>
> > {
> > unsigned short offset, bit;
> > u8 enable;
> >
> > spin_lock(>lock);
> >
> > - offset = sch_gpio_offset(sch, gpio, GEN);
> > + offset = sch_gpio_offset(sch, gpio, reg);
> > bit = sch_gpio_bit(sch, gpio);
> >
> > enable = inb(sch->iobase + offset);
> > - if (!(enable & (1 << bit)))
> > - outb(enable | (1 << bit), sch->iobase + offset);
> > + if (!(enable & BIT(bit)))
> > + outb(enable | BIT(bit), sch->iobase + offset);
> >
> > spin_unlock(>lock);
> > }
> >
> > -static int sch_gpio_direction_in(struct gpio_chip *gc, unsigned
> > gpio_num)
> > +static void sch_gpio_disable(struct sch_gpio *sch, unsigned gpio,
> > +unsigned reg)
> > {
> > - struct sch_gpio *sch = to_sch_gpio(gc);
> > - u8 curr_dirs;
> > unsigned short offset, bit;
> > + u8 disable;
> >
> > spin_lock(>lock);
> >
> > - offset = sch_gpio_offset(sch, gpio_num, GIO);
> > - bit = sch_gpio_bit(sch, gpio_num);
> > -
> > - curr_dirs = inb(sch->iobase + offset);
> > + offset = sch_gpio_offset(sch, gpio, reg);
> > + bit = sch_gpio_bit(sch, gpio);
> >
> > - if (!(curr_dirs & (1 << bit)))
> > - outb(curr_dirs | (1 << bit), sch->iobase + offset);
> > + disable = inb(sch->iobase + offset);
> > + if (disable & BIT(bit))
> > + outb(disable & ~BIT(bit), sch->iobase + offset);
> >
> > spin_unlock(>lock);
> > - return 0;
> > }
> >
> > -static int sch_gpio_get(struct gpio_chip *gc, unsigned gpio_num)
> > +static int sch_gpio_reg_get(struct gpio_chip *gc, unsigned gpio,
> > +unsigned reg)
> > {
> > struct sch_gpio *sch = to_sch_gpio(gc);
> > - int res;
> > unsigned short offset, bit;
> > + u8 curr_dirs;
> >
> > - offset = sch_gpio_offset(sch, gpio_num, GLV);
> > - bit = sch_gpio_bit(sch, gpio_num);
> > + offset = sch_gpio_offset(sch, gpio, reg);
> > + bit = sch_gpio_bit(sch, gpio);
> >
> > - res = !!(inb(sch->iobase + offset) & (1 << bit));
> > + curr_dirs = !!(inb(sch->iobase + offset) & BIT(bit));
> >
> > - return res;
> > + return curr_dirs;
> > }
> >
> > -static void sch_gpio_set(struct gpio_chip *gc, unsigned gpio_num, int
> > val)
> > +static void sch_gpio_reg_set(struct gpio_chip *gc, unsigned gpio, unsigned
> reg,
> > +int val)
> > {
> > struct sch_gpio *sch = to_sch_gpio(gc);
> > - u8 curr_vals;
> > unsigned short offset,
Re: [PATCH v4 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support
On Thu, Sep 18, 2014 at 8:20 PM, Alan Stern wrote:
> On Thu, 18 Sep 2014, Vivek Gautam wrote:
>
>> Now that we have completely moved from older USB-PHY drivers
>> to newer GENERIC-PHY drivers for PHYs available with USB controllers
>> on Exynos series of SoCs, we can remove the support for the same
>> in our host drivers too.
>>
>> We also defer the probe for our host in case we end up getting
>> EPROBE_DEFER error when getting PHYs.
>
> Better now. But I didn't notice this the first time:
>
>> + if (IS_ERR(phy)) {
>> + ret = PTR_ERR(phy);
>> + if (ret == -EPROBE_DEFER) {
>> + return ret;
>> + } else if (ret != -ENOSYS && ret != -ENODEV) {
>> + dev_err(dev,
>> + "Error retrieving usb2 phy: %d\n",
>> ret);
>> + return PTR_ERR(phy);
>
> It doesn't make any real difference, but wouldn't you prefer to say
> "return ret" here?
sure, will update this.
>
> With or without that change, for both these two patches:
>
> Acked-by: Alan Stern
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the kvm-arm tree
On 09/22/2014 07:07 AM, Eric Auger wrote:
> Dear all,
>
> Thanks Stephen for reporting the problem. Indeed removing irq.h header
> file is no more possible since commit
> c77dcacb397519b6ade8f08201a4a90a7f4f751e, "KVM: Move more code under
> CONFIG_HAVE_KVM_IRQFD" which moves among other things
> kvm_register_irq_ack_notifier and kvm_unregister_irq_ack_notifier in
> eventfd.c.
Hi,
kvm_register_irq_ack_notifier and kvm_unregister_irq_ack_notifier were
already included in Paul's patch,
commit e4d57e1ee1ab59f0cef0272800ac6c52e0ec814a, KVM: Move irq notifier
implementation into eventfd.c and just moved in above patch.
So I completely missed this ioapic function.
You can remove my commit. No commit does depend on it yet.
Thanks
Eric
>
> including virt/kvm/ioapic.h might fix the problem but I am OoO next week
> and cannot investigate further right now.
>
> Please can you remove that commit. Sorry for the inconvenience.
>
> Best Regards
>
> Eric
>
>
> On 09/22/2014 06:06 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the kvm-arm tree, today's linux-next build (x86_64
>> allmodconfig)
>> failed like this:
>>
>> arch/x86/kvm/../../../virt/kvm/eventfd.c: In function
>> 'kvm_register_irq_ack_notifier':
>> arch/x86/kvm/../../../virt/kvm/eventfd.c:493:2: error: implicit declaration
>> of function 'kvm_vcpu_request_scan_ioapic'
>> [-Werror=implicit-function-declaration]
>> kvm_vcpu_request_scan_ioapic(kvm);
>> ^
>>
>> Probably caused by commit 0ba09511ddc3 ("KVM: EVENTFD: remove inclusion
>> of irq.h").
>>
>> I have used the kvm-arm tree from next-20140919 for today.
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: ARC: ARC_BOARD_ANGEL4 and ARC_BOARD_ML509
On Friday 12 September 2014 02:30 PM, Paul Bolle wrote:
> Hi Vineet,
>
> On Mon, 2014-06-09 at 09:05 +, Vineet Gupta wrote:
>> On Wednesday 04 June 2014 03:04 PM, Paul Bolle wrote:
>>> Linux-next included commit c00bfd974fb0 ("ARC: [arcfpga] Get rid of
>>> legacy BVCI latency unit support") in next-20140604. It removes the
>>> Kconfig symbol ARC_HAS_BVCI_LAT_UNIT. And that symbol's entry is the
>>> only place were the symbols ARC_BOARD_ANGEL4 and ARC_BOARD_ML509 are
>>> currently used. So it follows that the entries for ARC_BOARD_ANGEL4 and
>>> ARC_BOARD_ML509 could be removed too.
>> Thx for noticing this.
>>
>> I'm planning to use these symbols to set up default builtin DT blobs from
>> Kconfig
>> itself (rather than current defconfigs). If that doesn't workout - sure I
>> will
>> remove the symbols.
> No news here as of v3.17-rc4 and next-20140912. Are you still planning
> to use these symbols or should I submit the trivial patch to drop them?
Please send over patch - I'll queue it up for 3.18
Thx,
-Vineet
>
> Thanks,
>
>
> Paul Bolle
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf tools: Fix build-id matching on vmlinux
* Namhyung Kim wrote:
> There's a problem on finding correct kernel symbols when perf report
> runs on a different kernel. Although a part of the problem was solved
> by the prior commit 0a7e6d1b6844 ("perf tools: Check recorded kernel
> version when finding vmlinux"), there's a remaining problem still.
>
> When perf records samples, it synthesizes the kernel map using
> machine__mmap_name() and ref_reloc_sym like "[kernel.kallsyms]_text".
> You can easily see it using 'perf report -D' command.
>
> After finishing record, it goes through the recorded events to find
> maps/dsos actually used. And then record build-id info of them.
>
> During this process, it needs to load symbols in a dso and it'd call
> dso__load_vmlinux() since the default value of the symbol_conf.try_
> vmlinux_path is true. However it changes dso->long_name to a real
> path of the vmlinux file (e.g. /lib/modules/3.16.0-rc2+/build/vmlinux)
> if one is running on a custom kernel.
>
> It resulted in that perf report reads the build-id of the vmlinux, but
> cannot use it since it only knows about the [kernel.kallsyms] map. It
> then falls back to possible vmlinux paths by using the recorded kernel
> version (in case of a recent version) or a running kernel silently.
>
> Even with the recent tools, this still has a possibility of breaking
> the result. As the build directory is a symbolic link, if one built a
> new kernel in the same directory with different source/config, the old
> link to vmlinux will point the new file. So it's absolutely needed to
> use build-id when finding a kernel image.
>
> In this patch, it's now changed to try to search a kernel dso using
> "vmlinux" shortname (which always has a build-id) and, if not found,
> search "[kernel.kallsyms]".
>
> Before:
>
> $ perf report
> # Children Self Command Shared Object Symbol
> # ... .
> ...
> #
> 72.15% 0.00% swapper [kernel.kallsyms] [k] set_curr_task_rt
> 72.15% 0.00% swapper [kernel.kallsyms] [k] native_calibrate_tsc
> 72.15% 0.00% swapper [kernel.kallsyms] [k]
> tsc_refine_calibration_work
> 71.87%71.87% swapper [kernel.kallsyms] [k] module_finalize
>...
>
> After (for the same perf.data):
>
> 72.15% 0.00% swapper vmlinux [k] cpu_startup_entry
> 72.15% 0.00% swapper vmlinux [k] arch_cpu_idle
> 72.15% 0.00% swapper vmlinux [k] default_idle
> 71.87%71.87% swapper vmlinux [k] native_safe_halt
>...
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Namhyung Kim
> ---
> tools/perf/util/machine.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> index b2ec38bf211e..14880b81e98c 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -1062,8 +1062,22 @@ static int machine__process_kernel_mmap_event(struct
> machine *machine,
>* Should be there already, from the build-id table in
>* the header.
>*/
> - struct dso *kernel = __dsos__findnew(>kernel_dsos,
> - kmmap_prefix);
> + struct dso *kernel = NULL;
> + struct dso *dso;
> +
> + list_for_each_entry(dso, >kernel_dsos, node) {
> + const char *suffix;
> +
> + suffix = dso->long_name + strlen(dso->long_name) - 3;
> + if (strcmp(suffix, ".ko")) {
> + kernel = dso;
> + break;
> + }
Is strlen(dso->long_name) guaranteed to be >= 3? If not then you
should probably check for it, otherwise we might strcmp into
invalid memory.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the kvm-arm tree
Dear all,
Thanks Stephen for reporting the problem. Indeed removing irq.h header
file is no more possible since commit
c77dcacb397519b6ade8f08201a4a90a7f4f751e, "KVM: Move more code under
CONFIG_HAVE_KVM_IRQFD" which moves among other things
kvm_register_irq_ack_notifier and kvm_unregister_irq_ack_notifier in
eventfd.c.
including virt/kvm/ioapic.h might fix the problem but I am OoO next week
and cannot investigate further right now.
Please can you remove that commit. Sorry for the inconvenience.
Best Regards
Eric
On 09/22/2014 06:06 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the kvm-arm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> arch/x86/kvm/../../../virt/kvm/eventfd.c: In function
> 'kvm_register_irq_ack_notifier':
> arch/x86/kvm/../../../virt/kvm/eventfd.c:493:2: error: implicit declaration
> of function 'kvm_vcpu_request_scan_ioapic'
> [-Werror=implicit-function-declaration]
> kvm_vcpu_request_scan_ioapic(kvm);
> ^
>
> Probably caused by commit 0ba09511ddc3 ("KVM: EVENTFD: remove inclusion
> of irq.h").
>
> I have used the kvm-arm tree from next-20140919 for today.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/15] powerpc/powerpc: Add new PCIe functions for allocating cxl interrupts
> >+struct device_node *pnv_pci_to_phb_node(struct pci_dev *dev)
> >+{
> >+struct device_node *np;
> >+struct property *prop = NULL;
> >+
> >+np = of_node_get(pci_device_to_OF_node(dev));
> >+
> >+/* Scan up the tree looking for the PHB node */
> >+while (np) {
> >+if ((prop = of_find_property(np, "ibm,opal-phbid", NULL)))
> >+break;
> >+np = of_get_next_parent(np);
> >+}
> >+
> >+if (!prop) {
> >+of_node_put(np);
> >+return NULL;
> >+}
> >+
> >+return np;
> >+}
> >+EXPORT_SYMBOL(pnv_pci_to_phb_node);
>
> Nitpick: I'm not sure it's better way. "struct pci_controller::dn" should
> always have valid "ibm,opal-phbid", so I guess the code could be like this
> way:
>
> struct pci_controller *hose = pci_bus_to_host(dev->bus);
>
> return hose->dn;
Nice.. that makes it much simpler. I'll update.
> >+
> >+#ifdef CONFIG_CXL_BASE
> >+int pnv_phb_to_cxl(struct pci_dev *dev)
> >+{
> >+struct device_node *np;
> >+struct pnv_ioda_pe *pe;
> >+const u64 *prop64;
> >+u64 phb_id;
> >+int rc;
> >+
> >+dev_info(>dev, "switch PHB to CXL\n");
> >+
> >+if (!(np = pnv_pci_to_phb_node(dev)))
> >+return -ENODEV;
> >+
> >+prop64 = of_get_property(np, "ibm,opal-phbid", NULL);
> >+
> >+phb_id = be64_to_cpup(prop64);
> >+dev_info(>dev, "PHB-ID : 0x%016llx\n", phb_id);
> >+
>
> The PHB ID would have been there: struct pnv_phb::opal_id. So
> I guess we needn't grab it from device-tree again :)
Nice, I'll update.
> >+if (!(pe = pnv_ioda_get_pe(dev))) {
> >+rc = -ENODEV;
> >+goto out;
> >+}
> >+dev_info(>dev, " pe : %i\n", pe->pe_number);
>
> Perhaps you can reuse pe_info() here.
Yep, will do.
> >+#ifdef CONFIG_CXL_BASE
> >+int pnv_cxl_ioda_msi_setup(struct pci_dev *dev, unsigned int hwirq,
> >+ unsigned int virq)
> >+{
> >+struct pci_controller *hose = pci_bus_to_host(dev->bus);
> >+struct pnv_phb *phb = hose->private_data;
> >+unsigned int xive_num = hwirq - phb->msi_base;
> >+struct pnv_ioda_pe *pe;
> >+int rc;
> >+
> >+if (!(pe = pnv_ioda_get_pe(dev)))
> >+return -ENODEV;
> >+
> >+/* Assign XIVE to PE */
> >+rc = opal_pci_set_xive_pe(phb->opal_id, pe->pe_number, xive_num);
> >+if (rc) {
> >+pr_warn("%s: OPAL error %d setting msi_base 0x%x hwirq 0x%x
> >XIVE 0x%x PE\n",
> >+pci_name(dev), rc, phb->msi_base, hwirq, xive_num);
> >+return -EIO;
> >+}
>
> It seems current firmware doesn't support the OPAL API for PHB3.
The current public version of skiboot seems to be doing something here
in hw/phb3.c in phb3_set_ive_pe():
https://github.com/open-power/skiboot/blob/c34c4ef8c660e3e439365c8f5c06143ff00bc6bc/hw/phb3.c#L1096
I think we still need this.
Thanks again!
Mikey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the staging tree with Linus' tree
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in
drivers/iio/accel/bma180.c between commit 0668a4e4d297 ("iio: accel:
bma180: Fix indio_dev->trig assignment") from Linus' tree and commit
16ed8692fa48 ("iio:bma180: Enable use of device without IRQ") from the
staging tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/iio/accel/bma180.c
index 19100fddd2ed,6ef19641457c..
--- a/drivers/iio/accel/bma180.c
+++ b/drivers/iio/accel/bma180.c
@@@ -553,29 -729,31 +729,31 @@@ static int bma180_probe(struct i2c_clie
indio_dev->modes = INDIO_DIRECT_MODE;
indio_dev->info = _info;
- trig = iio_trigger_alloc("%s-dev%d", indio_dev->name, indio_dev->id);
- if (!trig) {
- ret = -ENOMEM;
- goto err_chip_disable;
- }
+ if (client->irq > 0) {
+ data->trig = iio_trigger_alloc("%s-dev%d", indio_dev->name,
+ indio_dev->id);
+ if (!data->trig) {
+ ret = -ENOMEM;
+ goto err_chip_disable;
+ }
- ret = devm_request_irq(>dev, client->irq,
- iio_trigger_generic_data_rdy_poll,
- IRQF_TRIGGER_RISING, BMA180_IRQ_NAME, trig);
- if (ret) {
- dev_err(>dev, "unable to request IRQ\n");
- goto err_trigger_free;
- }
+ ret = devm_request_irq(>dev, client->irq,
+ iio_trigger_generic_data_rdy_poll, IRQF_TRIGGER_RISING,
+ "bma180_event", data->trig);
+ if (ret) {
+ dev_err(>dev, "unable to request IRQ\n");
+ goto err_trigger_free;
+ }
- trig->dev.parent = >dev;
- trig->ops = _trigger_ops;
- iio_trigger_set_drvdata(trig, indio_dev);
- data->trig = trig;
- indio_dev->trig = iio_trigger_get(trig);
+ data->trig->dev.parent = >dev;
+ data->trig->ops = _trigger_ops;
+ iio_trigger_set_drvdata(data->trig, indio_dev);
- indio_dev->trig = data->trig;
++ indio_dev->trig = iio_trigger_get(data->trig);
- ret = iio_trigger_register(trig);
- if (ret)
- goto err_trigger_free;
+ ret = iio_trigger_register(data->trig);
+ if (ret)
+ goto err_trigger_free;
+ }
ret = iio_triggered_buffer_setup(indio_dev, NULL,
bma180_trigger_handler, NULL);
signature.asc
Description: PGP signature
RE: [PATCH] clk: samsung: exynos5260: fix typo in clock name
Hi Tomasz, Will you please take this patch and following three Exynos3250 clock fixes in your tree. 1: clk: samsung: exynos3250: fix width field of mout_mmc0/1 https://lkml.org/lkml/2014/9/5/265 2: clk: samsung: exynos3250: fix width and shift of div_spi0_isp clock https://lkml.org/lkml/2014/9/9/364 3: clk: samsung: exynos3250: fix mout_cam_blk parent list https://lkml.org/lkml/2014/9/6/41 Thanks, Pankaj Dubey > > Please add my sign-off as > > Signed-off-by: Pankaj Dubey > > > > > Missed your sign-off? You can reply with it inline and I will add it > > when applying this weekend. > > > > P.S. Please keep me on CC when sending patches for Samsung clock drivers. > > > > Best regards, > > Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] ARM: dts: vf610-colibri: Add backlight support
On Friday 19 September 2014 09:33 PM, Stefan Agner wrote:
> Am 2014-09-19 15:38, schrieb Bhuvanchandra DV:
>> Signed-off-by: Bhuvanchandra DV
>> ---
>> arch/arm/boot/dts/vf610-colibri-eval-v3.dts |6 ++
>> arch/arm/boot/dts/vf610-colibri.dtsi|6 ++
>> 2 files changed, 12 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/vf610-colibri-eval-v3.dts
>> b/arch/arm/boot/dts/vf610-colibri-eval-v3.dts
>> index 00f63d9..711cf82 100644
>> --- a/arch/arm/boot/dts/vf610-colibri-eval-v3.dts
>> +++ b/arch/arm/boot/dts/vf610-colibri-eval-v3.dts
>> @@ -19,6 +19,12 @@
>> };
>> };
>>
>> + {
>> +brightness-levels = <0 4 8 16 32 64 128 255>;
>> +default-brightness-level = <6>;
>> +status = "okay";
>> +};
>> +
>> {
>> pinctrl-names = "default";
>> pinctrl-0 = <_esdhc1>;
>> diff --git a/arch/arm/boot/dts/vf610-colibri.dtsi
>> b/arch/arm/boot/dts/vf610-colibri.dtsi
>> index 560cd69..20b1c15 100644
>> --- a/arch/arm/boot/dts/vf610-colibri.dtsi
>> +++ b/arch/arm/boot/dts/vf610-colibri.dtsi
>> @@ -13,6 +13,12 @@
>> model = "Toradex Colibri VF61 COM";
>> compatible = "toradex,vf610-colibri_vf61", "fsl,vf610";
>>
>> +bl: backlight {
>> +compitable = "pwm-backlight";
>> +pwms = < 0 500 0>;
>> +status = "disabled";
>> +};
>> +
> Typo, "compitable" is not a valid property...
>
> When this is fixed,
> Acked-By: Stefan Agner
Thanks for pointing it out. Will update accordingly.
>> clocks {
>> enet_ext {
>> compatible = "fixed-clock";
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] regulator: st-pwm: get voltage and duty table from dts
On 09/22/2014 12:18 PM, Doug Anderson wrote: Chris, On Sun, Sep 21, 2014 at 7:52 PM, Chris Zhong wrote: Get voltage & duty table from device tree might be better, other platforms can also use this driver without any modify. Signed-off-by: Chris Zhong Reviewed-by: Doug Anderson No need to re-spin, but please remember that all tags should be bunched together (no blank lines). In other words, YES: Signed-off-by: Chris Zhong Reviewed-by: Doug Anderson NO: Signed-off-by: Chris Zhong Reviewed-by: Doug Anderson Thanks. It seems the patman add the blank line, I will manually modify it next 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 1/3] sched: fix confusing PFA_NO_NEW_PRIVS constant
On 2014/9/22 12:02, Tejun Heo wrote:
> On Mon, Sep 22, 2014 at 11:50:46AM +0800, Zefan Li wrote:
>> From: Tetsuo Handa
>>
>> Commit 1d4457f99928 ("sched: move no_new_privs into new atomic flags")
>> defined PFA_NO_NEW_PRIVS as hexadecimal value, but it is confusing
>> because it is used as bit number. Redefine it as decimal bit number.
>
> It's also changing the bit position, which is fine but should be
> mentioned in the description.
>
I've resent the patch with changelog updated.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] sched: fix confusing PFA_NO_NEW_PRIVS constant
On Mon, Sep 22, 2014 at 12:43:32PM +0800, Zefan Li wrote:
> Commit 1d4457f99928 ("sched: move no_new_privs into new atomic flags")
> defined PFA_NO_NEW_PRIVS as hexadecimal value, but it is confusing
> because it is used as bit number. Redefine it as decimal bit number.
>
> Note this changes the bit position of PFA_NOW_NEW_PRIVS from 1 to 0.
>
> Signed-off-by: Tetsuo Handa
> Acked-by: Kees Cook
> [ lizf: slightly modified subject and changelog ]
> Signed-off-by: Zefan Li
All the patches look good to me. I can't say I'm a big fan of
function defining macros but I don't have prettier alternatives
either. Once Peter/Ingo acks the patches, I'll route them through
cgroup/for-3.17-fixes.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5] mfd: syscon: Decouple syscon interface from platform devices
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure where is can be probed and such non-DT based drivers can use
syscon_regmap_lookup_by_pdev API and get access to regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completly remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann
Suggested-by: Tomasz Figa
Tested-by: Vivek Gautam
Tested-by: Javier Martinez Canillas
Signed-off-by: Pankaj Dubey
---
Patch v4 and related discussions can be found here [1].
Changes since v4:
- Addressed Tomasz Figa's comments for v4.
- Added error handing in of_syscon_register function.
- Using devm_regmap_init_mmio instead of regmap_init_mmio.
Changes since v3:
- Addressed Arnd's comment for v2.
- Updated of_syscon_register for adding dev pointer in regmap_init_mmio.
- For early users created dummy platform device.
Changes since v2:
- Added back platform device support from syscon, with one change that
syscon will not be probed for DT based platform.
- Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
users of syscon will not be broken.
- Removed unwanted change in syscon.h.
- Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
Arnd Bergmann.
- Added Tested-by of Vivek Gautam for testing on Exynos platform.
Changes since v1:
- Removed of_syscon_unregister function.
- Modified of_syscon_register function and it will be used by syscon.c
to create syscon objects whenever required.
- Removed platform device support from syscon.
- Removed syscon_regmap_lookup_by_pdevname API support.
- As there are significant changes w.r.t patchset v1, I am taking over
author for this patchset from Tomasz Figa.
[1]: https://lkml.org/lkml/2014/9/19/267
drivers/mfd/syscon.c | 107 +++---
1 file changed, 85 insertions(+), 22 deletions(-)
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index ca15878..0b17f50 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -22,31 +23,105 @@
#include
#include
#include
+#include
static struct platform_driver syscon_driver;
+static DEFINE_SPINLOCK(syscon_list_slock);
+static LIST_HEAD(syscon_list);
+
struct syscon {
+ struct device_node *np;
struct regmap *regmap;
+ struct list_head list;
+};
+
+static struct regmap_config syscon_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
};
-static int syscon_match_node(struct device *dev, void *data)
+static struct syscon *of_syscon_register(struct device_node *np)
{
- struct device_node *dn = data;
+ struct platform_device *pdev = NULL;
+ struct syscon *syscon;
+ struct regmap *regmap;
+ void __iomem *base;
+ int ret;
+
+ if (!of_device_is_compatible(np, "syscon"))
+ return ERR_PTR(-EINVAL);
+
+ syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
+ if (!syscon)
+ return ERR_PTR(-ENOMEM);
+
+ base = of_iomap(np, 0);
+ if (!base) {
+ ret = -ENOMEM;
+ goto err_map;
+ }
+
+ /* if device is already populated and available then use it */
+ pdev = of_find_device_by_node(np);
+ if (!pdev) {
+ /* for early users create dummy syscon device and use it */
+ pdev = platform_device_alloc("dummy-syscon", -1);
+ if (!pdev) {
+ ret = -ENOMEM;
+ goto err_pdev;
+ }
+ pdev->dev.of_node = of_node_get(np);
+ }
+
+ regmap = devm_regmap_init_mmio(>dev, base, _regmap_config);
+ if (IS_ERR(regmap)) {
+ dev_err(>dev, "regmap init failed\n");
+ ret =
Re: [PATCH] Fix nasty 32-bit overflow bug in buffer i/o code.
On Mon, 22 Sep 2014, Anton Altaparmakov wrote:
> Any code that uses __getblk() and thus bread(), breadahead(), sb_bread(),
> sb_breadahead(), sb_getblk(), and calls it using a 64-bit block on a
> 32-bit arch (where "long" is 32-bit) causes an inifinite loop in
> __getblk_slow() with an infinite stream of errors logged to dmesg like
> this:
>
> __find_get_block_slow() failed. block=6740375944, b_blocknr=2445408648
> b_state=0x0020, b_size=512
> device sda1 blocksize: 512
>
> Note how in hex block is 0x191C1F988 and b_blocknr is 0x91C1F988 i.e. the
> top 32-bits are missing (in this case the 0x1 at the top).
>
> This is because grow_dev_page() was broken in commit 676ce6d5ca30: "block:
> replace __getblk_slow misfix by grow_dev_page fix" by Hugh Dickins so that
> it now has a 32-bit overflow due to shifting the block value to the right
> so it fits in 32-bits and storing the result in pgoff_t variable which is
> 32-bit and then passing the pgoff_t variable left-shifted as the block
> number which causes the top bits to get lost as the pgoff_t is not type
> cast to sector_t / 64-bit before the shift.
>
> This patch fixes this issue by type casting "index" to sector_t before
> doing the left shift.
>
> Note this is not a theoretical bug but has been seen in the field on a
> 4TiB hard drive with logical sector size 512 bytes.
>
> This patch has been verified to fix the infinite loop problem on 3.17-rc5
> kernel using a 4TB disk image mounted using "-o loop". Without this patch
> doing a "find /nt" where /nt is an NTFS volume causes the inifinite loop
> 100% reproducibly whilst with the patch it works fine as expected.
>
> Signed-off-by: Anton Altaparmakov
> Cc: sta...@vger.kernel.org # 3.6 3.8 3.10 3.12 3.14 3.16
Acked-by: Hugh Dickins
Yes indeed, that's bad, and entirely my fault (though it took me a while
to see how the "block = index << sizebits" which was there before was okay,
but my passing "index << sizebits" as arg to function very much not okay).
Thank you, Anton.
But I see my commit was marked for stable 3.0 3.2 3.4 3.5: so your fix
is needed in 3.2 and 3.4 longterm also (the others now beyond life).
Hugh
> ---
>
> Linus, can you please apply this? Alternatively, Andrew, can you please
> pick this up and send it to Linus?
>
> It would be good it it can be applied for 3.17 as well as to all stable
> kernels >= 3.6 as they are all broken!
>
> Thanks a lot in advance!
>
> Best regards,
>
> Anton
> --
> Anton Altaparmakov (replace at with @)
> Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
> Linux NTFS maintainer, http://www.linux-ntfs.org/
>
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 8f05111..3588a80 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -1022,7 +1022,8 @@ grow_dev_page(struct block_device *bdev, sector_t block,
> bh = page_buffers(page);
> if (bh->b_size == size) {
> end_block = init_page_buffers(page, bdev,
> - index << sizebits, size);
> + (sector_t)index << sizebits,
> + size);
> goto done;
> }
> if (!try_to_free_buffers(page))
> @@ -1043,7 +1044,8 @@ grow_dev_page(struct block_device *bdev, sector_t block,
>*/
> spin_lock(>i_mapping->private_lock);
> link_dev_buffers(page, bh);
> - end_block = init_page_buffers(page, bdev, index << sizebits, size);
> + end_block = init_page_buffers(page, bdev, (sector_t)index << sizebits,
> + size);
> spin_unlock(>i_mapping->private_lock);
> done:
> ret = (block < end_block) ? 1 : -ENXIO;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] sched: fix confusing PFA_NO_NEW_PRIVS constant
Commit 1d4457f99928 ("sched: move no_new_privs into new atomic flags")
defined PFA_NO_NEW_PRIVS as hexadecimal value, but it is confusing
because it is used as bit number. Redefine it as decimal bit number.
Note this changes the bit position of PFA_NOW_NEW_PRIVS from 1 to 0.
Signed-off-by: Tetsuo Handa
Acked-by: Kees Cook
[ lizf: slightly modified subject and changelog ]
Signed-off-by: Zefan Li
---
The other two patches don't need to be updated, so no need to resend them.
---
include/linux/sched.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5c2c885..4557765 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1957,7 +1957,7 @@ static inline void memalloc_noio_restore(unsigned int
flags)
}
/* Per-process atomic flags. */
-#define PFA_NO_NEW_PRIVS 0x0001/* May not gain new privileges. */
+#define PFA_NO_NEW_PRIVS 0 /* May not gain new privileges. */
static inline bool task_no_new_privs(struct task_struct *p)
{
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] ARM: dts: vf610-colibri: Add PWM support
On Friday 19 September 2014 09:30 PM, Stefan Agner wrote:
> Am 2014-09-19 15:38, schrieb Bhuvanchandra DV:
>> The Colibri standard defines four pins as PWM outputs, two of them (PWM
>> A and C) are routed to FTM instance 0 and the other two (PWM B and D)
>> are routed to FTM instance 1. Hence enable both FTM instances for the
>> Colibri module and mux the four pins accordingly.
>>
>> Signed-off-by: Bhuvanchandra DV
>> ---
>> arch/arm/boot/dts/vf610-colibri-eval-v3.dts |8 +++
>> arch/arm/boot/dts/vf610-colibri.dtsi| 31
>> +++
>> 2 files changed, 35 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/vf610-colibri-eval-v3.dts
>> b/arch/arm/boot/dts/vf610-colibri-eval-v3.dts
>> index 7fb3066..00f63d9 100644
>> --- a/arch/arm/boot/dts/vf610-colibri-eval-v3.dts
>> +++ b/arch/arm/boot/dts/vf610-colibri-eval-v3.dts
>> @@ -33,6 +33,14 @@
>> status = "okay";
>> };
>>
>> + {
>> +status = "okay";
>> +};
>> +
>> + {
>> +status = "okay";
>> +};
>> +
>> {
>> status = "okay";
>> };
>> diff --git a/arch/arm/boot/dts/vf610-colibri.dtsi
>> b/arch/arm/boot/dts/vf610-colibri.dtsi
>> index 0cd8343..560cd69 100644
>> --- a/arch/arm/boot/dts/vf610-colibri.dtsi
>> +++ b/arch/arm/boot/dts/vf610-colibri.dtsi
>> @@ -13,10 +13,6 @@
>> model = "Toradex Colibri VF61 COM";
>> compatible = "toradex,vf610-colibri_vf61", "fsl,vf610";
>>
>> -memory {
>> -reg = <0x8000 0x1000>;
>> -};
>> -
>> clocks {
>> enet_ext {
>> compatible = "fixed-clock";
>> @@ -25,6 +21,9 @@
>> };
>> };
>>
>> +memory {
>> +reg = <0x8000 0x1000>;
>> +};
> Memory is a bit an exception here: In almost all device tree this is the
> first node after model/compatible. Also, it's generally not allowed to
> make changes outside of the topic (PWM in this case)... Hence I would
> drop this change.
>
> The rest
> Acked-By: Stefan Agner
OK. Will drop the change.
>> };
>>
>> {
>> @@ -44,6 +43,16 @@
>> arm,tag-latency = <3 2 3>;
>> };
>>
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_pwm0>;
>> +};
>> +
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_pwm1>;
>> +};
>> +
>> {
>> pinctrl-names = "default";
>> pinctrl-0 = <_uart0>;
>> @@ -97,6 +106,20 @@
>> >;
>> };
>>
>> +pinctrl_pwm0: pwm0grp {
>> +fsl,pins = <
>> +VF610_PAD_PTB0__FTM0_CH00x1182
>> +VF610_PAD_PTB1__FTM0_CH10x1182
>> +>;
>> +};
>> +
>> +pinctrl_pwm1: pwm1grp {
>> +fsl,pins = <
>> +VF610_PAD_PTB8__FTM1_CH00x1182
>> +VF610_PAD_PTB9__FTM1_CH10x1182
>> +>;
>> +};
>> +
>> pinctrl_uart0: uart0grp {
>> fsl,pins = <
>> VF610_PAD_PTB10__UART0_TX 0x21a2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/15] powerpc/powernv: Split out set MSI IRQ chip code
> >+static void set_msi_irq_chip(struct pnv_phb *phb, unsigned int virq)
> >+{
> >+struct irq_data *idata;
> >+struct irq_chip *ichip;
> >+
> >+/*
> >+ * Change the IRQ chip for the MSI interrupts on PHB3.
> >+ * The corresponding IRQ chip should be populated for
> >+ * the first time.
> >+ */
> >+if (phb->type == PNV_PHB_IODA2) {
> >+if (!phb->ioda.irq_chip_init) {
> >+idata = irq_get_irq_data(virq);
> >+ichip = irq_data_get_irq_chip(idata);
> >+phb->ioda.irq_chip_init = 1;
> >+phb->ioda.irq_chip = *ichip;
> >+phb->ioda.irq_chip.irq_eoi = pnv_ioda2_msi_eoi;
> >+}
> >+
> >+irq_set_chip(virq, >ioda.irq_chip);
> >+}
> >+}
> >+
>
> Nitpick: to check PHB type and bail early could avoid nested code :)
>
> if (phb->type != PNV_PHB_IODA2)
> return;
OK, will do in repost.
Thanks,
Mikey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE]: SCST 3.0 released
No, because it's too new, but you can always get it from the git. Or you can use stable Emulex driver for 16Gb connectivity. It's not in the bundle only because of the Emulex policy. Thanks, Vlad On 9/19/2014 23:59, scst.n...@gmail.com wrote: Does 16Gb qla2x00t included? 发自我的小米手机 Vladislav Bolkhovitin 于 2014-9-20 下午2:39写道： Hi All, I'm glad to announce that SCST 3.0 has just been released. This release includes SCST core, target drivers iSCSI-SCST for iSCSI, including iSER support (thanks to Mellanox!), qla2x00t for QLogic Fibre Channel adapters, ib_srpt for InfiniBand SRP, fcst for FCoE and scst_local for local loopback-like access as well as SCST management utility scstadmin. Also separately you can download from Emulex development portal stable and fully functional target driver for the current generation of Emulex Fibre Channel adapters. SCST is alternative SCSI target stack for Linux. SCST allows creation of sophisticated storage devices, which provide advanced functionality, like replication, thin provisioning, deduplication, high availability, automatic backup, etc. Majority of recently developed SAN appliances, especially higher end ones, are SCST based. It might well be that your favorite storage appliance running SCST in the firmware. More info about SCST and its modules you can find on: http://scst.sourceforge.net Thanks to all who made it happen! Vlad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] spi: qup: Fix incorrect block transfers
This patch fixes a number of errors with the QUP block transfer mode. Errors
manifested themselves as input underruns, output overruns, and timed out
transactions.
The block mode does not require the priming that occurs in FIFO mode. At the
moment that the QUP is placed into the RUN state, the QUP may immediately raise
an interrupt if the request is a write. Therefore, there is no need to prime
the pump.
In addition, the block transfers require that whole blocks of data are
read/written at a time. The last block of data that completes a transaction may
contain less than a full blocks worth of data.
Each block of data results in an input/output service interrupt accompanied with
a input/output block flag set. Additional block reads/writes require clearing
of the service flag. It is ok to check for additional blocks of data in the
ISR, but you have to ack every block you transfer. Imbalanced acks result in
early return from complete transactions with pending interrupts that still have
to be ack'd. The next transaction can be affected by these interrupts.
Signed-off-by: Andy Gross
---
drivers/spi/spi-qup.c | 194 +++--
1 file changed, 141 insertions(+), 53 deletions(-)
diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
index 9f83d29..9c4c745 100644
--- a/drivers/spi/spi-qup.c
+++ b/drivers/spi/spi-qup.c
@@ -80,6 +80,8 @@
#define QUP_IO_M_MODE_BAM 3
/* QUP_OPERATIONAL fields */
+#define QUP_OP_IN_BLOCK_READ_REQ BIT(13)
+#define QUP_OP_OUT_BLOCK_WRITE_REQ BIT(12)
#define QUP_OP_MAX_INPUT_DONE_FLAG BIT(11)
#define QUP_OP_MAX_OUTPUT_DONE_FLAGBIT(10)
#define QUP_OP_IN_SERVICE_FLAG BIT(9)
@@ -143,6 +145,7 @@ struct spi_qup {
int tx_bytes;
int rx_bytes;
int qup_v1;
+ int mode;
};
@@ -198,30 +201,16 @@ static int spi_qup_set_state(struct spi_qup *controller,
u32 state)
return 0;
}
-
-static void spi_qup_fifo_read(struct spi_qup *controller,
- struct spi_transfer *xfer)
+static void qup_fill_read_buffer(struct spi_qup *controller,
+ struct spi_transfer *xfer, u32 data)
{
u8 *rx_buf = xfer->rx_buf;
- u32 word, state;
- int idx, shift, w_size;
-
- w_size = controller->w_size;
-
- while (controller->rx_bytes < xfer->len) {
-
- state = readl_relaxed(controller->base + QUP_OPERATIONAL);
- if (0 == (state & QUP_OP_IN_FIFO_NOT_EMPTY))
- break;
+ int idx, shift;
+ int read_len = min_t(int, xfer->len - controller->rx_bytes,
+ controller->w_size);
- word = readl_relaxed(controller->base + QUP_INPUT_FIFO);
-
- if (!rx_buf) {
- controller->rx_bytes += w_size;
- continue;
- }
-
- for (idx = 0; idx < w_size; idx++, controller->rx_bytes++) {
+ if (rx_buf)
+ for (idx = 0; idx < read_len; idx++) {
/*
* The data format depends on bytes per SPI word:
* 4 bytes: 0x12345678
@@ -229,40 +218,129 @@ static void spi_qup_fifo_read(struct spi_qup *controller,
* 1 byte : 0x0012
*/
shift = BITS_PER_BYTE;
- shift *= (w_size - idx - 1);
- rx_buf[controller->rx_bytes] = word >> shift;
+ shift *= (controller->w_size - idx - 1);
+ rx_buf[controller->rx_bytes + idx] = data >> shift;
}
- }
+
+ controller->rx_bytes += read_len;
}
-static void spi_qup_fifo_write(struct spi_qup *controller,
- struct spi_transfer *xfer)
+static void qup_prepare_write_data(struct spi_qup *controller,
+ struct spi_transfer *xfer, u32 *data)
{
const u8 *tx_buf = xfer->tx_buf;
- u32 word, state, data;
- int idx, w_size;
+ u32 val;
+ int idx;
+ int write_len = min_t(int, xfer->len - controller->tx_bytes,
+ controller->w_size);
- w_size = controller->w_size;
+ *data = 0;
- while (controller->tx_bytes < xfer->len) {
+ if (tx_buf)
+ for (idx = 0; idx < write_len; idx++) {
+ val = tx_buf[controller->tx_bytes + idx];
+ *data |= val << (BITS_PER_BYTE * (3 - idx));
+ }
- state = readl_relaxed(controller->base + QUP_OPERATIONAL);
- if (state & QUP_OP_OUT_FIFO_FULL)
- break;
+ controller->tx_bytes += write_len;
+}
- word = 0;
- for (idx = 0; idx < w_size; idx++, controller->tx_bytes++) {
+static void
Re: [PATCH v4 1/2] regulator: st-pwm: get voltage and duty table from dts
Chris, On Sun, Sep 21, 2014 at 7:52 PM, Chris Zhong wrote: > Get voltage & duty table from device tree might be better, other platforms > can also use this > driver without any modify. > > Signed-off-by: Chris Zhong > > Reviewed-by: Doug Anderson No need to re-spin, but please remember that all tags should be bunched together (no blank lines). In other words, YES: > Signed-off-by: Chris Zhong > Reviewed-by: Doug Anderson NO: > Signed-off-by: Chris Zhong > > Reviewed-by: Doug Anderson -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v4] mfd: syscon: Decouple syscon interface from platform devices
Hi Tomasz,
On Friday, September 19, 2014 Tomasz Figa wrote,
> Hi Pankaj,
>
> Please see my comments inline.
>
> On 19.09.2014 15:06, Pankaj Dubey wrote:
> > Currently a syscon entity can be only registered directly through a
> > platform device that binds to a dedicated syscon driver. However in
> > certain use cases it is desirable to make a device used with another
> > driver a syscon interface provider.
>
> [snip]
>
> > -static int syscon_match_node(struct device *dev, void *data)
> > +static struct syscon *of_syscon_register(struct device_node *np)
> > {
> > - struct device_node *dn = data;
> > + struct platform_device *pdev = NULL;
> > + struct syscon *syscon;
> > + struct regmap *regmap;
> > + void __iomem *base;
> > +
> > +
>
> nit: Stray blank line.
>
OK. Will remove this.
> > + if (!of_device_is_compatible(np, "syscon"))
> > + return ERR_PTR(-EINVAL);
>
> I don't think this check is needed at all. I'd say that drivers should be
free to register a
> syscon provider for any node.
I think this check is correct, as only nodes having "syscon" as secondary
compatibility should be
used to create a syscon provider. And that's why we have "syscon" as
secondary compatibility in
device nodes which can be a syscon provider.
>
> > +
> > + syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
> > + if (!syscon)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + base = of_iomap(np, 0);
> > + if (!base)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + if (!of_device_is_available(np) ||
>
> Wouldn't it be enough to simply call of_find_device_by_node(np) and if it
fails then
> instead create a dummy device?
>
OK, this could be also one of approach, I will change accordingly.
> > + of_node_test_and_set_flag(np, OF_POPULATED)) {
> > + /* if device is already populated and avaiable then use it
*/
> > + pdev = of_find_device_by_node(np);
> > + if (!(>dev))
>
> This is just plain wrong, because this condition will always evaluate to
true (see the
> definition of struct platform_device). Shouldn't you rather just check the
pdev
> pointer?
OK, will update this.
>
> > + return ERR_PTR(-ENODEV);
> > +
> > + } else {
> > + /* for early users create dummy syscon device and use it */
> > + pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
> > + if (!pdev)
> > + return ERR_PTR(-ENOMEM);
>
> Any clean-up on error path?
OK, will add error path. Also will use platform_device_alloc as suggested.
>
> > +
> > + pdev->name = "dummy-syscon";
> > + pdev->id = -1;
>
> Wouldn't you get an ID collision if more than one syscon is registered
early? Maybe
> the naming scheme from of_device_alloc() could be adopted partially?
I think this should not be an issue, passing id as -1 should take care of
this.
As you know Exynos has two syscon providers "pmu" and "sysreg" I have
written a test
code to check this scenario and tested it during early stage and I am
successfully able to get
PMU and SYSREG handle.
>
> > + device_initialize(>dev);
>
> I wonder if you couldn't simply reuse platform_device_alloc() for all of
this, except
> the line below, which would still have to be handled separately.
>
> > + pdev->dev.of_node = np;
> > + }
> > +
> > + regmap = regmap_init_mmio(>dev, base, _regmap_config);
> > + if (IS_ERR(regmap)) {
> > + pr_err("regmap init failed\n");
>
> If you have a dev here then you should be able to use dev_err() already.
OK.
>
> > + return ERR_CAST(regmap);
> > + }
[snip]
> > +
> > + if (!syscon)
> > + syscon = of_syscon_register(np);
> > +
> > + if (!IS_ERR(syscon))
> > + return syscon->regmap;
> > +
> > + return ERR_CAST(syscon);
>
> nit: Usually error checking is done the opposite way, i.e.
OK, will change accordingly.
Thanks,
Pankaj Dubey
>
> if (IS_ERR(syscon))
> return ERR_CAST(syscon);
>
> return syscon->regmap;
>
> Best regards,
> Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the kvm-arm tree
Hi all,
After merging the kvm-arm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
arch/x86/kvm/../../../virt/kvm/eventfd.c: In function
'kvm_register_irq_ack_notifier':
arch/x86/kvm/../../../virt/kvm/eventfd.c:493:2: error: implicit declaration of
function 'kvm_vcpu_request_scan_ioapic' [-Werror=implicit-function-declaration]
kvm_vcpu_request_scan_ioapic(kvm);
^
Probably caused by commit 0ba09511ddc3 ("KVM: EVENTFD: remove inclusion
of irq.h").
I have used the kvm-arm tree from next-20140919 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH] Revert "percpu: free percpu allocation info for uniprocessor system"
On Sun, Sep 21, 2014 at 03:04:53PM -0700, Guenter Roeck wrote:
> This reverts commit 3189eddbcafc ("percpu: free percpu allocation info for
> uniprocessor system").
>
> The commit causes a hang with a crisv32 image. This may be an architecture
> problem, but at least for now the revert is necessary to be able to boot a
> crisv32 image.
>
> Fixes: 3189eddbcafc ("percpu: free percpu allocation info for uniprocessor
> system")
> Cc: Tejun Heo
> Cc: Honggang Li
> Signed-off-by: Guenter Roeck
Applied to percpu/for-3.18.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] sched: fix confusing PFA_NO_NEW_PRIVS constant
On Mon, Sep 22, 2014 at 11:50:46AM +0800, Zefan Li wrote:
> From: Tetsuo Handa
>
> Commit 1d4457f99928 ("sched: move no_new_privs into new atomic flags")
> defined PFA_NO_NEW_PRIVS as hexadecimal value, but it is confusing
> because it is used as bit number. Redefine it as decimal bit number.
It's also changing the bit position, which is fine but should be
mentioned in the description.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] workqueue fixes for v3.17-rc6
Hello, Linus.
create_singlethread_workqueue() is the old interface which is kept
around for backward compatibility - each should be reviewed to
determine whether singlethread usage was to save worker threads or for
ordering guarantee and whether it's depended upon by memory reclaim
path.
While adding NUMA support for unbound workqueues during v3.10, I
forgot to update it breaking the singlethread and ordering properties
on NUMA setups. The breakage was unfortunately rather subtle and went
without being reported until now.
The only missing piece is __WQ_ORDERED flag which makes the unbounded
workqueue use a single backend queue across different NUMA nodes.
It's fixed by making create_singlethread_workqueue() wrap
alloc_ordered_workqueue() so that possible future updates are
inherited automatically.
Thanks.
The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:
Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-3.17-fixes
for you to fetch changes up to e09c2c295468476a239d13324ce9042ec4de05eb:
workqueue: apply __WQ_ORDERED to create_singlethread_workqueue() (2014-09-13
05:13:08 +0900)
Tejun Heo (1):
workqueue: apply __WQ_ORDERED to create_singlethread_workqueue()
include/linux/workqueue.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index a0cc2e9..b996e6cd 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -419,7 +419,7 @@ __alloc_workqueue_key(const char *fmt, unsigned int flags,
int max_active,
alloc_workqueue("%s", WQ_FREEZABLE | WQ_UNBOUND | WQ_MEM_RECLAIM, \
1, (name))
#define create_singlethread_workqueue(name)\
- alloc_workqueue("%s", WQ_UNBOUND | WQ_MEM_RECLAIM, 1, (name))
+ alloc_ordered_workqueue("%s", WQ_MEM_RECLAIM, name)
extern void destroy_workqueue(struct workqueue_struct *wq);
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] openrisc: Support both old (or32) and new (or1k) toolchain
On 09/21/2014 07:53 PM, Stefan Kristiansson wrote:
On Thu, Sep 18, 2014 at 09:56:38PM -0700, Guenter Roeck wrote:
ping ... comments / feedback anyone ?
Guenter
FWIW, I've tested this and it works fine.
Hi Stefan,
Great, thanks a lot for testing. Any idea if Jonas is available to send it
upstream,
or should I try to send it to Linus directly ?
Thanks,
Guenter
Stefan
On 09/08/2014 02:00 PM, Guenter Roeck wrote:
The output file format for openrisc has changed from "elf32-or32"
to "elf32-or1k" when using the or1k instead of the older or32 toochain.
Select the correct output format automatically to be able to compile
the kernel with both toolchain variants.
Cc: Stefan Kristiansson
Signed-off-by: Guenter Roeck
---
Candidate for -stable ?
arch/openrisc/kernel/vmlinux.lds.S | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/openrisc/kernel/vmlinux.lds.S
b/arch/openrisc/kernel/vmlinux.lds.S
index 2d69a85..1c5d21a 100644
--- a/arch/openrisc/kernel/vmlinux.lds.S
+++ b/arch/openrisc/kernel/vmlinux.lds.S
@@ -30,7 +30,13 @@
#include
#include
-OUTPUT_FORMAT("elf32-or32", "elf32-or32", "elf32-or32")
+#ifdef __OR1K__
+#define __OUTPUT_FORMAT"elf32-or1k"
+#else
+#define __OUTPUT_FORMAT"elf32-or32"
+#endif
+
+OUTPUT_FORMAT(__OUTPUT_FORMAT, __OUTPUT_FORMAT, __OUTPUT_FORMAT)
jiffies = jiffies_64 + 4;
SECTIONS
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] sched: add a macro to define bitops for task atomic flags
This will simplify code when we add new flags.
Signed-off-by: Zefan Li
---
include/linux/sched.h | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 4557765..04a2ae2 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1959,15 +1959,17 @@ static inline void memalloc_noio_restore(unsigned int
flags)
/* Per-process atomic flags. */
#define PFA_NO_NEW_PRIVS 0 /* May not gain new privileges. */
-static inline bool task_no_new_privs(struct task_struct *p)
-{
- return test_bit(PFA_NO_NEW_PRIVS, >atomic_flags);
-}
-
-static inline void task_set_no_new_privs(struct task_struct *p)
-{
- set_bit(PFA_NO_NEW_PRIVS, >atomic_flags);
-}
+#define TASK_PFA_BITOPS(name, func)\
+static inline bool task_##func(struct task_struct *p) \
+{ return test_bit(PFA_##name, >atomic_flags); } \
+ \
+static inline void task_set_##func(struct task_struct *p) \
+{ set_bit(PFA_##name, >atomic_flags); } \
+ \
+static inline void task_clear_##func(struct task_struct *p)\
+{ clear_bit(PFA_##name, >atomic_flags); }
+
+TASK_PFA_BITOPS(NO_NEW_PRIVS, no_new_privs)
/*
* task->jobctl flags
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] cpuset: PF_SPREAD_PAGE and PF_SPREAD_SLAB should be atomic flags
When we change cpuset.memory_spread_{page,slab}, cpuset will flip
PF_SPREAD_{PAGE,SLAB} bit of tsk->flags for each task in that cpuset.
This should be done using atomic bitops, but currently we don't,
which is broken.
Tetsuo reported a hard-to-reproduce kernel crash on RHEL6, which happend
when one thread tried to clear PF_USED_MATH while at the same time another
thread tried to flip PF_SPREAD_PAGE/PF_SPREAD_SLAB. They both operate on
the same task.
Here's the full report:
https://lkml.org/lkml/2014/9/19/230
To fix this, we make PF_SPREAD_PAGE and PF_SPARED_SLAB atomic flags.
Fixes: 950592f7b991 ("cpusets: update tasks' page/slab spread flags in time")
Cc: # 2.6.31+
Reported-by: Tetsuo Handa
Signed-off-by: Zefan Li
---
include/linux/cpuset.h | 4 ++--
include/linux/sched.h | 6 --
kernel/cpuset.c| 9 +
3 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h
index 0d4e067..2f073db 100644
--- a/include/linux/cpuset.h
+++ b/include/linux/cpuset.h
@@ -94,12 +94,12 @@ extern int cpuset_slab_spread_node(void);
static inline int cpuset_do_page_mem_spread(void)
{
- return current->flags & PF_SPREAD_PAGE;
+ return task_spread_page(current);
}
static inline int cpuset_do_slab_mem_spread(void)
{
- return current->flags & PF_SPREAD_SLAB;
+ return task_spread_slab(current);
}
extern int current_cpuset_is_being_rebound(void);
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 04a2ae2..ee634d1 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1903,8 +1903,6 @@ extern void thread_group_cputime_adjusted(struct
task_struct *p, cputime_t *ut,
#define PF_KTHREAD 0x0020 /* I am a kernel thread */
#define PF_RANDOMIZE 0x0040 /* randomize virtual address space */
#define PF_SWAPWRITE 0x0080 /* Allowed to write to swap */
-#define PF_SPREAD_PAGE 0x0100 /* Spread page cache over cpuset */
-#define PF_SPREAD_SLAB 0x0200 /* Spread some slab caches over cpuset
*/
#define PF_NO_SETAFFINITY 0x0400 /* Userland is not allowed to meddle
with cpus_allowed */
#define PF_MCE_EARLY0x0800 /* Early kill for mce process policy */
#define PF_MUTEX_TESTER0x2000 /* Thread belongs to the rt
mutex tester */
@@ -1958,6 +1956,8 @@ static inline void memalloc_noio_restore(unsigned int
flags)
/* Per-process atomic flags. */
#define PFA_NO_NEW_PRIVS 0 /* May not gain new privileges. */
+#define PFA_SPREAD_PAGE 1 /* Spread page cache over cpuset */
+#define PFA_SPREAD_SLAB 2 /* Spread some slab caches over cpuset */
#define TASK_PFA_BITOPS(name, func)\
static inline bool task_##func(struct task_struct *p) \
@@ -1970,6 +1970,8 @@ static inline void task_clear_##func(struct task_struct
*p) \
{ clear_bit(PFA_##name, >atomic_flags); }
TASK_PFA_BITOPS(NO_NEW_PRIVS, no_new_privs)
+TASK_PFA_BITOPS(SPREAD_PAGE, spread_page)
+TASK_PFA_BITOPS(SPREAD_SLAB, spread_slab)
/*
* task->jobctl flags
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index a37f4ed..1f107c7 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -365,13 +365,14 @@ static void cpuset_update_task_spread_flag(struct cpuset
*cs,
struct task_struct *tsk)
{
if (is_spread_page(cs))
- tsk->flags |= PF_SPREAD_PAGE;
+ task_set_spread_page(tsk);
else
- tsk->flags &= ~PF_SPREAD_PAGE;
+ task_clear_spread_page(tsk);
+
if (is_spread_slab(cs))
- tsk->flags |= PF_SPREAD_SLAB;
+ task_set_spread_slab(tsk);
else
- tsk->flags &= ~PF_SPREAD_SLAB;
+ task_clear_spread_slab(tsk);
}
/*
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] sched: fix confusing PFA_NO_NEW_PRIVS constant
From: Tetsuo Handa
Commit 1d4457f99928 ("sched: move no_new_privs into new atomic flags")
defined PFA_NO_NEW_PRIVS as hexadecimal value, but it is confusing
because it is used as bit number. Redefine it as decimal bit number.
Signed-off-by: Tetsuo Handa
Acked-by: Kees Cook
Signed-off-by: Zefan Li
---
include/linux/sched.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5c2c885..4557765 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1957,7 +1957,7 @@ static inline void memalloc_noio_restore(unsigned int
flags)
}
/* Per-process atomic flags. */
-#define PFA_NO_NEW_PRIVS 0x0001/* May not gain new privileges. */
+#define PFA_NO_NEW_PRIVS 0 /* May not gain new privileges. */
static inline bool task_no_new_privs(struct task_struct *p)
{
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scripts: checkpatch.pl: Fix existing typedef false positive warning
On Sun, 2014-09-21 at 22:08 -0500, Greg Donald wrote:
> On Sun, Sep 21, 2014 at 9:31 PM, Joe Perches wrote:
> > On Sun, 2014-09-21 at 20:32 -0500, Greg Donald wrote:
> >> Fixing an "open brace '{' following struct go on the same line" error
> >> causes a
> >> false positive warning "do not add new typedefs". Fix existing typedef
> >> false
> >> positive warning.
> >
> > This doesn't work.
> > The matching deleted line can be any number of lines above.
>
> But this fixes the most common case:
>
> -typedef struct ksock_proto
> -{
> +typedef struct ksock_proto {
Meh. I think people are smart enough to work
out that this is not a new typedef.
> If you're wanting to check more than just $rawlines[$linenr - 3], how
> far above does it make sense to go? From what I'm seeing the '{' is
> usually on the next line.
It's not the most common case working, it's the
generic case working.
It's in a large block being changed, it doesn't work.
If it's checking a file, there are no "-" lines.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] workqueue: fix a workqueue kernel panic issue.
On Sun, Sep 21, 2014 at 08:30:32PM -0700, Yifan Zhang wrote:
> Hi Tejun,
>
> What's do you think of this patch ? Any concern ?
Hmmm? Haven't I already responded to this patch?
> -Original Message-
> From: Yifan Zhang [mailto:zhan...@marvell.com]
> Sent: 2014年9月17日 16:18
> To: Tejun Heo; Jing Xiang; linux-kernel@vger.kernel.org
> Cc: Yifan Zhang
> Subject: [PATCH] workqueue: fix a workqueue kernel panic issue.
>
> if created workqueue in multi-thread unsynchronized,
Can you please elaborate?
> get_work_pwq() may return NULL, which cause kernel panic. Judge
> get_work_pwq() return value before use
> pwq->wq->flags.
>
> Signed-off-by: Yifan Zhang
> ---
> kernel/workqueue.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 5dbe22a..d3ac87f
> 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -1947,9 +1947,19 @@ __acquires(>lock) {
> struct pool_workqueue *pwq = get_work_pwq(work);
> struct worker_pool *pool = worker->pool;
> - bool cpu_intensive = pwq->wq->flags & WQ_CPU_INTENSIVE;
> + bool cpu_intensive;
> int work_color;
> struct worker *collision;
> +
> + if (pwq == NULL) {
> + pr_err("BUG: invalid struct work_struct.data %lu\n",
> + atomic_long_read(>data));
> + dump_stack();
> + return;
I have difficult time seeing how the above piece of code would be
acceptable but maybe the situation you're trying to explain is weird
enough to justify it.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
itrace: An interrupts tracing tool
Many functions depends on interrupts in Linux system, when the interrupts occur an error, it may cause fatal problem. Then, we should record their trace when interrupts in and out. The recorded information could help us analyze interrupts errors. Itrace is such an interrupts trace tool we have developed, it provides config interface and trace information through "procfs". Do you think it has the value to upstream? Thanks Zhiping Du -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tip tree with the nfs tree
Hi all,
Today's linux-next merge of the tip tree got conflicts in
fs/nfs/blocklayout/blocklayoutdev.c and
fs/nfs/blocklayout/blocklayoutdm.c between commit 871760ce97a9
("pnfs/blocklayout: move all rpc_pipefs related code into a single
file") from the nfs tree and commit f139caf2e897 ("sched, cleanup,
treewide: Remove set_current_state(TASK_RUNNING) after schedule()")
from the tip tree.
I fixed it up (the former move the code in these two files into
fs/nfs/blocklayout/rpc_pipefs.c, so I deleted the 2 files and applied
the following merge fix patch) and can carry the fix as necessary (no
action is required).
From: Stephen Rothwell
Date: Mon, 22 Sep 2014 13:29:19 +1000
Subject: [PATCH] pnfs: merge fixup for sched cleanup of
set_current_state(TASK_RUNNING)
Signed-off-by: Stephen Rothwell
---
fs/nfs/blocklayout/rpc_pipefs.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/nfs/blocklayout/rpc_pipefs.c b/fs/nfs/blocklayout/rpc_pipefs.c
index 8d04bda2bd2e..e966c023b1b7 100644
--- a/fs/nfs/blocklayout/rpc_pipefs.c
+++ b/fs/nfs/blocklayout/rpc_pipefs.c
@@ -92,7 +92,6 @@ bl_resolve_deviceid(struct nfs_server *server, struct
pnfs_block_volume *b,
set_current_state(TASK_UNINTERRUPTIBLE);
schedule();
- __set_current_state(TASK_RUNNING);
remove_wait_queue(>bl_wq, );
if (reply->status != BL_DEVICE_REQUEST_PROC) {
--
2.1.0
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
RE: [PATCH] workqueue: fix a workqueue kernel panic issue.
Hi Tejun,
What's do you think of this patch ? Any concern ?
BR,
Yifan
-Original Message-
From: Yifan Zhang [mailto:zhan...@marvell.com]
Sent: 2014年9月17日 16:18
To: Tejun Heo; Jing Xiang; linux-kernel@vger.kernel.org
Cc: Yifan Zhang
Subject: [PATCH] workqueue: fix a workqueue kernel panic issue.
if created workqueue in multi-thread unsynchronized,
get_work_pwq() may return NULL, which cause kernel panic. Judge get_work_pwq()
return value before use
pwq->wq->flags.
Signed-off-by: Yifan Zhang
---
kernel/workqueue.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 5dbe22a..d3ac87f
100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1947,9 +1947,19 @@ __acquires(>lock) {
struct pool_workqueue *pwq = get_work_pwq(work);
struct worker_pool *pool = worker->pool;
- bool cpu_intensive = pwq->wq->flags & WQ_CPU_INTENSIVE;
+ bool cpu_intensive;
int work_color;
struct worker *collision;
+
+ if (pwq == NULL) {
+ pr_err("BUG: invalid struct work_struct.data %lu\n",
+ atomic_long_read(>data));
+ dump_stack();
+ return;
+ }
+
+ cpu_intensive = pwq->wq->flags & WQ_CPU_INTENSIVE;
+
#ifdef CONFIG_LOCKDEP
/*
* It is permissible to free the struct work_struct from
--
1.7.9.5
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i
Re: [PATCH RFC 2/2] vhost: support urgent descriptors
On 09/20/2014 06:00 PM, Paolo Bonzini wrote:
> Il 19/09/2014 09:10, Jason Wang ha scritto:
- if (!vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX)) {
+ if (vq->urgent || !vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX)) {
>> So the urgent descriptor only work when event index was not enabled?
>> This seems suboptimal, we may still want to benefit from event index
>> even if urgent descriptor is used. Looks like we need return true here
>> when vq->urgent is true?
> Its ||, not &&.
>
> Without event index, all descriptors are treated as urgent.
>
> Paolo
>
The problem is if vq->urgent is true, the patch checks
VRING_AVAIL_F_NO_INTERRUPT bit. This bit were set unconditionally in
virtqueue_enable_cb() regardless of event index feature and cleared
unconditionally in virtqueue_disable_cb(). So virtqueue_enable_cb() was
used to not only publish a new event index but also enable the urgent
descriptor. And virtqueue_disable_cb() disabled all interrupts including
the urgent descriptor. Guest won't get urgent interrupts by just adding
virtqueue_add_outbuf_urgent() since what it needs is to enable and
disable interrupt for !urgent descriptor.
Btw, not sure "urgent" is a suitable name, since interrupt is often slow
in kvm guest. And in fact virtio-net will probably use "urgent"
descriptor for those packets (e.g stream packets who can be delayed a
little bit to batch more bytes from userspace) who was not urgent
compared to other packets.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] driver/drx39xyj: fix some compiling warnings
When compiling kernel, in module drx39xyj, there are some warnings
showing some variables may be used uninitialized, though they have
been initialized in fact.
drivers/media/dvb-frontends/drx39xyj/drxj.c: In function
‘drxj_dap_atomic_read_reg32.isra.17’:
drivers/media/dvb-frontends/drx39xyj/drxj.c:2190:7: warning:
‘*((void *)+3)’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
word = (u32) buf[3];
^
drivers/media/dvb-frontends/drx39xyj/drxj.c:2192:10: warning:
‘*((void *)+2)’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
word |= (u32) buf[2];
^
drivers/media/dvb-frontends/drx39xyj/drxj.c:2194:10: warning:
‘*((void *)+1)’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
word |= (u32) buf[1];
^
drivers/media/dvb-frontends/drx39xyj/drxj.c:2196:10: warning:
‘buf’ may be used uninitialized in this function [-Wmaybe-uninitialized]
word |= (u32) buf[0];
^
drivers/media/dvb-frontends/drx39xyj/drxj.c: In function
‘drx39xxj_read_status’:
drivers/media/dvb-frontends/drx39xyj/drxj.c:10671:11: warning:
‘strength’ may be used uninitialized in this function [-Wmaybe-uninitialized]
u16 mer, strength;
^
drivers/media/dvb-frontends/drx39xyj/drxj.c: In function
‘drxj_dap_scu_atomic_read_reg16’:
drivers/media/dvb-frontends/drx39xyj/drxj.c:4208:9: warning:
‘*((void *)+1)’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
word = (u16) (buf[0] + (buf[1] << 8));
^
drivers/media/dvb-frontends/drx39xyj/drxj.c:4208:9: warning:
‘buf’ may be used uninitialized in this function [-Wmaybe-uninitialized]
Signed-off-by: Li, Zhen-Hua
---
drivers/media/dvb-frontends/drx39xyj/drxj.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/drx39xyj/drxj.c
b/drivers/media/dvb-frontends/drx39xyj/drxj.c
index 7ca7a21..afb14c70 100644
--- a/drivers/media/dvb-frontends/drx39xyj/drxj.c
+++ b/drivers/media/dvb-frontends/drx39xyj/drxj.c
@@ -2181,6 +2181,7 @@ int drxj_dap_atomic_read_reg32(struct i2c_device_addr
*dev_addr,
if (!data)
return -EINVAL;
+ memset(buf, 0, sizeof(*data));
rc = drxj_dap_atomic_read_write_block(dev_addr, addr,
sizeof(*data), buf, true);
@@ -4200,6 +4201,7 @@ int drxj_dap_scu_atomic_read_reg16(struct i2c_device_addr
*dev_addr,
if (!data)
return -EINVAL;
+ memset(buf, 0, 2);
rc = drxj_dap_scu_atomic_read_write_block(dev_addr, addr, 2, buf, true);
if (rc < 0)
return rc;
@@ -10667,7 +10669,7 @@ ctrl_sig_quality(struct drx_demod_instance *demod,
enum drx_standard standard = ext_attr->standard;
int rc;
u32 ber, cnt, err, pkt;
- u16 mer, strength;
+ u16 mer, strength = 0;
rc = get_sig_strength(demod, );
if (rc < 0) {
--
2.0.0-rc0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] scripts: checkpatch.pl: Fix existing typedef false positive warning
On Sun, Sep 21, 2014 at 9:31 PM, Joe Perches wrote:
> On Sun, 2014-09-21 at 20:32 -0500, Greg Donald wrote:
>> Fixing an "open brace '{' following struct go on the same line" error causes
>> a
>> false positive warning "do not add new typedefs". Fix existing typedef false
>> positive warning.
>
> This doesn't work.
> The matching deleted line can be any number of lines above.
But this fixes the most common case:
-typedef struct ksock_proto
-{
+typedef struct ksock_proto {
If you're wanting to check more than just $rawlines[$linenr - 3], how
far above does it make sense to go? From what I'm seeing the '{' is
usually on the next line.
--
Greg Donald
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Payment
Dear Recipient, You have been awarded the sum of 8,000,000.00 (Eight Million Pounds sterling) with reference number 77100146 by office of the ministry of finance UK.Send us your personal details to deliver your funds. Gloria Pete -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: FIX ME in oxu210p-hcd.c
Damm, didn't configure my kill-file correctly, and this snuck in, so might as well respond... On Sun, Sep 21, 2014 at 10:36:18PM -0400, nick wrote: > On 14-09-21 10:24 PM, gre...@linuxfoundation.org wrote: > >> Sorry Greg, > >> I don't want to get banned again. I was trying to help out and learn, I > >> was apologizing not > >> for wasting time as much as for making sure I wasn't wasting maintainer > >> time again. I also > >> am coming to the conclusion that my terrible patches were a waste of time > >> and I am trying > >> to get back into helping out. > > > > You were asked to finish the Eudyptula challenge before bothering any > > other kernel developers with questions / patches. Until that happens, > > you are in my killfile, now with yet-another-email-address. > > > Greg K-H, > I really don't want you to get any more upset with me then you already are. > The reason I gave up on the > challenge was it was mostly driver based and I wanted to learn more in other > areas. If you would like to > discuss with me your concerns about my work on this list and how I can aid > more please let me known. You stopped so early in the challenge, you really have no idea what it is "mostly" about, so don't make rash statements like that. Again, unless you finish it, you will be ignored by me, and probably by everyone else as well. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: Add delay between CMD6 and CMD13 for Sandisk eMMC cards
Hi,
On 09/22/2014 02:48 AM, Pavel Machek wrote:
> On Mon 2014-09-15 19:44:28, Jaehoon Chung wrote:
>> On 09/15/2014 07:08 PM, Jean-Michel Hautbois wrote:
>>> Hi Jaehoon,
>>>
On 09/09/2014 09:26 PM, Jean-Michel Hautbois wrote:
> Tested on a i.MX6 board, with Sandisk SDIN5D1-2G.
> Without this patch, I/O errors occur.
> This eMMC seems to have a different Manufacturer ID as it reads 0x45
> and not 0x2 as specified in datasheet.
I think this patch don't merge into mainline.
This is not solution for problem.
you mentioned the below comment, this is workaround.
>>>
>>> Yes
>>>
>
> Signed-off-by: Jean-Michel Hautbois
> ---
> drivers/mmc/core/mmc_ops.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
> index f51b5ba..91babaa 100644
> --- a/drivers/mmc/core/mmc_ops.c
> +++ b/drivers/mmc/core/mmc_ops.c
> @@ -458,6 +458,15 @@ int __mmc_switch(struct mmc_card *card, u8 set, u8
> index, u8 value,
> if (!use_busy_signal)
> return 0;
>
> + /* WORKAROUND: for Sandisk eMMC cards, it might need certain delay
> + * before sending CMD13 after CMD6
> + * On SDIN5D1-2G MANFID is 0x45 and not 0x2 as specified in
> datasheet
> + */
> + if (card->cid.manfid == CID_MANFID_SANDISK ||
> + card->cid.manfid == 0x45) {
> + msleep(1);
> + }
If it's a general problem of Sandisk SDIN5D1-2G,
I think you need to verify this problem. And can you use the MMC_FIXUP()
and QUIRK?
>>>
>>> Well, this is difficult to verify, I know that on all my SDIN5D1-2G I
>>> have this MANFID different from what is defined by CID_MANFID_SANDISK.
>>> How should I use MMC_FIXUP ? Like this ?
>>
>> I think you need to explain why delay is need.
>> i didn't have same card, but it might be your host controller or other
>> problem.
>
> Datasheet says it is needed, so we need to do the delay.
>
> Adding pointer to the datasheet (page, chapter) to the comment might be good
> idea.
It's good. Then i think good that it will add the delay with the MMC_FIXUP and
QUIRK.
Best Regards,
Jaehoon Chung
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] openrisc: Support both old (or32) and new (or1k) toolchain
On Thu, Sep 18, 2014 at 09:56:38PM -0700, Guenter Roeck wrote:
> ping ... comments / feedback anyone ?
>
> Guenter
>
FWIW, I've tested this and it works fine.
Stefan
> On 09/08/2014 02:00 PM, Guenter Roeck wrote:
> >The output file format for openrisc has changed from "elf32-or32"
> >to "elf32-or1k" when using the or1k instead of the older or32 toochain.
> >Select the correct output format automatically to be able to compile
> >the kernel with both toolchain variants.
> >
> >Cc: Stefan Kristiansson
> >Signed-off-by: Guenter Roeck
> >---
> >Candidate for -stable ?
> >
> > arch/openrisc/kernel/vmlinux.lds.S | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> >diff --git a/arch/openrisc/kernel/vmlinux.lds.S
> >b/arch/openrisc/kernel/vmlinux.lds.S
> >index 2d69a85..1c5d21a 100644
> >--- a/arch/openrisc/kernel/vmlinux.lds.S
> >+++ b/arch/openrisc/kernel/vmlinux.lds.S
> >@@ -30,7 +30,13 @@
> > #include
> > #include
> >
> >-OUTPUT_FORMAT("elf32-or32", "elf32-or32", "elf32-or32")
> >+#ifdef __OR1K__
> >+#define __OUTPUT_FORMAT "elf32-or1k"
> >+#else
> >+#define __OUTPUT_FORMAT "elf32-or32"
> >+#endif
> >+
> >+OUTPUT_FORMAT(__OUTPUT_FORMAT, __OUTPUT_FORMAT, __OUTPUT_FORMAT)
> > jiffies = jiffies_64 + 4;
> >
> > SECTIONS
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 2/2] dt-bindings: add devicetree bindings for st-pwm regulator
Document the st-pwm regulator
Signed-off-by: Chris Zhong
Adviced by Doug Anderson
- remove regulator-always-on and regulator-boot-on from the Example
Reviewed-by: Doug Anderson
---
Changes in v4: None
Changes in v3:
Adviced by Doug Anderson
- update the Example
Changes in v2:
Adviced by Lee Jones
- rename the documentation
Adviced by Doug Anderson
- update the example
Adviced by Mark Rutland
- remove pwm-reg-period
.../bindings/regulator/pwm-regulator.txt | 27
1 file changed, 27 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/pwm-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
new file mode 100644
index 000..c6756a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
@@ -0,0 +1,27 @@
+pwm regulator bindings
+
+Required properties:
+- compatible: Should be "pwm-regulator"
+- pwms: OF device-tree PWM specification (see PWM binding pwm.txt)
+- voltage-table: voltage and duty table, include 2 merbers in each set of
+ brackets, first one is voltage(unit: uv), the next is duty(unit: percent)
+
+Any property defined as part of the core regulator binding defined in
+regulator.txt can also be used.
+
+Example:
+ pwm_regulator {
+ compatible = "pwm-regulator;
+ pwms = < 0 8448 0>;
+
+ voltage-table = <1114000 0>,
+ <1095000 10>,
+ <1076000 20>,
+ <1056000 30>,
+ <1036000 40>,
+ <1016000 50>;
+
+ regulator-min-microvolt = <1016000>;
+ regulator-max-microvolt = <1114000>;
+ regulator-name = "vdd_logic";
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/2] regulator: get voltage & duty table from dts for st-pwm
get voltage & duty table from device tree might be better, other platforms can also use this driver without any modify. Tested on a rk3288 sdk board as logic voltage regulator. Changes in v4: Adviced by Doug Anderson - improve kconfig - add const for desc structure Changes in v3: Adviced by Doug Anderson - Make Kconfig & Makefile alphabetical - remove pwm_reg_period from pwm_regulator_data - modify the calculation in pwm_regulator_set_voltage_sel - add length validity check Adviced by Doug Anderson - update the Example Changes in v2: Adviced by Lee Jones - rename the file - remove all the prefix st_ - add depend on PWM in Kconfig Adviced by Lee Jones - rename the documentation Adviced by Doug Anderson - update the example Adviced by Mark Rutland - remove pwm-reg-period Chris Zhong (2): regulator: st-pwm: get voltage and duty table from dts dt-bindings: add devicetree bindings for st-pwm regulator .../bindings/regulator/pwm-regulator.txt | 27 +++ drivers/regulator/Kconfig | 13 +- drivers/regulator/Makefile |2 +- drivers/regulator/pwm-regulator.c | 197 drivers/regulator/st-pwm.c | 190 --- 5 files changed, 232 insertions(+), 197 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/pwm-regulator.txt create mode 100644 drivers/regulator/pwm-regulator.c delete mode 100644 drivers/regulator/st-pwm.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/2] regulator: st-pwm: get voltage and duty table from dts
Get voltage & duty table from device tree might be better, other platforms can
also use this
driver without any modify.
Signed-off-by: Chris Zhong
Reviewed-by: Doug Anderson
---
Changes in v4:
Adviced by Doug Anderson
- improve kconfig
- add const for desc structure
Changes in v3:
Adviced by Doug Anderson
- Make Kconfig & Makefile alphabetical
- remove pwm_reg_period from pwm_regulator_data
- modify the calculation in pwm_regulator_set_voltage_sel
- add length validity check
Changes in v2:
Adviced by Lee Jones
- rename the file
- remove all the prefix st_
- add depend on PWM in Kconfig
drivers/regulator/Kconfig | 13 +--
drivers/regulator/Makefile|2 +-
drivers/regulator/pwm-regulator.c | 197 +
drivers/regulator/st-pwm.c| 190 ---
4 files changed, 205 insertions(+), 197 deletions(-)
create mode 100644 drivers/regulator/pwm-regulator.c
delete mode 100644 drivers/regulator/st-pwm.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index fb32bab..b927cab 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -449,6 +449,13 @@ config REGULATOR_PFUZE100
Say y here to support the regulators found on the Freescale
PFUZE100/PFUZE200 PMIC.
+config REGULATOR_PWM
+ tristate "PWM voltage regulator"
+ depends on PWM
+ help
+ This driver supports PWM controlled voltage regulators. PWM
+ duty cycle can increase or decrease the voltage.
+
config REGULATOR_RC5T583
tristate "RICOH RC5T583 Power regulators"
depends on MFD_RC5T583
@@ -493,12 +500,6 @@ config REGULATOR_S5M8767
via I2C bus. S5M8767A have 9 Bucks and 28 LDOs output and
supports DVS mode with 8bits of output voltage control.
-config REGULATOR_ST_PWM
- tristate "STMicroelectronics PWM voltage regulator"
- depends on ARCH_STI
- help
-This driver supports ST's PWM controlled voltage regulators.
-
config REGULATOR_TI_ABB
tristate "TI Adaptive Body Bias on-chip LDO"
depends on ARCH_OMAP
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 236fdbb..f3cf5a5 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
obj-$(CONFIG_REGULATOR_MC13XXX_CORE) += mc13xxx-regulator-core.o
obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
+obj-$(CONFIG_REGULATOR_PWM) += pwm-regulator.o
obj-$(CONFIG_REGULATOR_TPS51632) += tps51632-regulator.o
obj-$(CONFIG_REGULATOR_PBIAS) += pbias-regulator.o
obj-$(CONFIG_REGULATOR_PCAP) += pcap-regulator.o
@@ -66,7 +67,6 @@ obj-$(CONFIG_REGULATOR_RK808) += rk808-regulator.o
obj-$(CONFIG_REGULATOR_S2MPA01) += s2mpa01.o
obj-$(CONFIG_REGULATOR_S2MPS11) += s2mps11.o
obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
-obj-$(CONFIG_REGULATOR_ST_PWM) += st-pwm.o
obj-$(CONFIG_REGULATOR_STW481X_VMMC) += stw481x-vmmc.o
obj-$(CONFIG_REGULATOR_TI_ABB) += ti-abb-regulator.o
obj-$(CONFIG_REGULATOR_TPS6105X) += tps6105x-regulator.o
diff --git a/drivers/regulator/pwm-regulator.c
b/drivers/regulator/pwm-regulator.c
new file mode 100644
index 000..d3f55ea
--- /dev/null
+++ b/drivers/regulator/pwm-regulator.c
@@ -0,0 +1,197 @@
+/*
+ * Regulator driver for PWM Regulators
+ *
+ * Copyright (C) 2014 - STMicroelectronics Inc.
+ *
+ * Author: Lee Jones
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct pwm_regulator_data {
+ struct regulator_desc desc;
+ struct pwm_voltages *duty_cycle_table;
+ struct pwm_device *pwm;
+ bool enabled;
+ int state;
+};
+
+struct pwm_voltages {
+ unsigned int uV;
+ unsigned int dutycycle;
+};
+
+static int pwm_regulator_get_voltage_sel(struct regulator_dev *dev)
+{
+ struct pwm_regulator_data *drvdata = rdev_get_drvdata(dev);
+
+ return drvdata->state;
+}
+
+static int pwm_regulator_set_voltage_sel(struct regulator_dev *dev,
+unsigned selector)
+{
+ struct pwm_regulator_data *drvdata = rdev_get_drvdata(dev);
+ unsigned int pwm_reg_period;
+ int dutycycle;
+ int ret;
+
+ pwm_reg_period = pwm_get_period(drvdata->pwm);
+
+ dutycycle = (pwm_reg_period *
+ drvdata->duty_cycle_table[selector].dutycycle) / 100;
+
+ ret = pwm_config(drvdata->pwm, dutycycle, pwm_reg_period);
+ if (ret) {
+ dev_err(>dev, "Failed to configure PWM\n");
+ return ret;
+ }
+
+ drvdata->state = selector;
+
+ if (!drvdata->enabled) {
+ ret =
[PATCH v3] perf tools: Fix build-id matching on vmlinux
There's a problem on finding correct kernel symbols when perf report
runs on a different kernel. Although a part of the problem was solved
by the prior commit 0a7e6d1b6844 ("perf tools: Check recorded kernel
version when finding vmlinux"), there's a remaining problem still.
When perf records samples, it synthesizes the kernel map using
machine__mmap_name() and ref_reloc_sym like "[kernel.kallsyms]_text".
You can easily see it using 'perf report -D' command.
After finishing record, it goes through the recorded events to find
maps/dsos actually used. And then record build-id info of them.
During this process, it needs to load symbols in a dso and it'd call
dso__load_vmlinux() since the default value of the symbol_conf.try_
vmlinux_path is true. However it changes dso->long_name to a real
path of the vmlinux file (e.g. /lib/modules/3.16.0-rc2+/build/vmlinux)
if one is running on a custom kernel.
It resulted in that perf report reads the build-id of the vmlinux, but
cannot use it since it only knows about the [kernel.kallsyms] map. It
then falls back to possible vmlinux paths by using the recorded kernel
version (in case of a recent version) or a running kernel silently.
Even with the recent tools, this still has a possibility of breaking
the result. As the build directory is a symbolic link, if one built a
new kernel in the same directory with different source/config, the old
link to vmlinux will point the new file. So it's absolutely needed to
use build-id when finding a kernel image.
In this patch, it's now changed to try to search a kernel dso using
"vmlinux" shortname (which always has a build-id) and, if not found,
search "[kernel.kallsyms]".
Before:
$ perf report
# Children Self Command Shared Object Symbol
# ... .
...
#
72.15% 0.00% swapper [kernel.kallsyms] [k] set_curr_task_rt
72.15% 0.00% swapper [kernel.kallsyms] [k] native_calibrate_tsc
72.15% 0.00% swapper [kernel.kallsyms] [k]
tsc_refine_calibration_work
71.87%71.87% swapper [kernel.kallsyms] [k] module_finalize
...
After (for the same perf.data):
72.15% 0.00% swapper vmlinux [k] cpu_startup_entry
72.15% 0.00% swapper vmlinux [k] arch_cpu_idle
72.15% 0.00% swapper vmlinux [k] default_idle
71.87%71.87% swapper vmlinux [k] native_safe_halt
...
Cc: sta...@vger.kernel.org
Signed-off-by: Namhyung Kim
---
tools/perf/util/machine.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index b2ec38bf211e..14880b81e98c 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1062,8 +1062,22 @@ static int machine__process_kernel_mmap_event(struct
machine *machine,
* Should be there already, from the build-id table in
* the header.
*/
- struct dso *kernel = __dsos__findnew(>kernel_dsos,
-kmmap_prefix);
+ struct dso *kernel = NULL;
+ struct dso *dso;
+
+ list_for_each_entry(dso, >kernel_dsos, node) {
+ const char *suffix;
+
+ suffix = dso->long_name + strlen(dso->long_name) - 3;
+ if (strcmp(suffix, ".ko")) {
+ kernel = dso;
+ break;
+ }
+ }
+
+ if (kernel == NULL)
+ kernel = __dsos__findnew(>kernel_dsos,
+kmmap_prefix);
if (kernel == NULL)
goto out_problem;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [f2fs-dev] [PATCH 07/10] f2fs: use meta_inode cache to improve roll-forward speed
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Monday, September 15, 2014 6:14 AM
> To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Cc: Jaegeuk Kim
> Subject: [f2fs-dev] [PATCH 07/10] f2fs: use meta_inode cache to improve
> roll-forward speed
>
> Previously, all the dnode pages should be read during the roll-forward
> recovery.
> Even worsely, whole the chain was traversed twice.
> This patch removes that redundant and costly read operations by using page
> cache
> of meta_inode and readahead function as well.
>
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/checkpoint.c | 11 --
> fs/f2fs/f2fs.h | 5 +++--
> fs/f2fs/recovery.c | 59
> +---
> fs/f2fs/segment.h| 5 +++--
> 4 files changed, 43 insertions(+), 37 deletions(-)
>
> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> index 7262d99..d1ed889 100644
> --- a/fs/f2fs/checkpoint.c
> +++ b/fs/f2fs/checkpoint.c
> @@ -82,6 +82,8 @@ static inline int get_max_meta_blks(struct f2fs_sb_info
> *sbi, int type)
> case META_SSA:
> case META_CP:
> return 0;
> + case META_POR:
> + return SM_I(sbi)->main_blkaddr + sbi->user_block_count;
Here we will skip virtual over-provision segments, so better to use
TOTAL_BLKS(sbi).
> default:
> BUG();
> }
> @@ -90,11 +92,11 @@ static inline int get_max_meta_blks(struct f2fs_sb_info
> *sbi, int type)
> /*
> * Readahead CP/NAT/SIT/SSA pages
> */
> -int ra_meta_pages(struct f2fs_sb_info *sbi, int start, int nrpages, int type)
> +int ra_meta_pages(struct f2fs_sb_info *sbi, block_t start, int nrpages, int
> type)
> {
> block_t prev_blk_addr = 0;
> struct page *page;
> - int blkno = start;
> + block_t blkno = start;
> int max_blks = get_max_meta_blks(sbi, type);
>
> struct f2fs_io_info fio = {
> @@ -128,6 +130,11 @@ int ra_meta_pages(struct f2fs_sb_info *sbi, int start,
> int nrpages, int
> type)
> /* get ssa/cp block addr */
> blk_addr = blkno;
> break;
> + case META_POR:
> + if (unlikely(blkno >= max_blks))
> + goto out;
> + blk_addr = blkno;
> + break;
The real modification in patch which is merged to dev of f2fs is as following:
- /* get ssa/cp block addr */
+ case META_POR:
+ if (blkno >= max_blks || blkno < min_blks)
+ goto out;
IMHO, it's better to verify boundary separately for META_{SSA,CP,POR} with
unlikely.
How do you think?
> default:
> BUG();
> }
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 4f84d2a..48d7d46 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -103,7 +103,8 @@ enum {
> META_CP,
> META_NAT,
> META_SIT,
> - META_SSA
> + META_SSA,
> + META_POR,
> };
>
> /* for the list of ino */
> @@ -1291,7 +1292,7 @@ void destroy_segment_manager_caches(void);
> */
> struct page *grab_meta_page(struct f2fs_sb_info *, pgoff_t);
> struct page *get_meta_page(struct f2fs_sb_info *, pgoff_t);
> -int ra_meta_pages(struct f2fs_sb_info *, int, int, int);
> +int ra_meta_pages(struct f2fs_sb_info *, block_t, int, int);
> long sync_meta_pages(struct f2fs_sb_info *, enum page_type, long);
> void add_dirty_inode(struct f2fs_sb_info *, nid_t, int type);
> void remove_dirty_inode(struct f2fs_sb_info *, nid_t, int type);
> diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
> index 3736728..6f7fbfa 100644
> --- a/fs/f2fs/recovery.c
> +++ b/fs/f2fs/recovery.c
> @@ -173,7 +173,7 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi,
> struct list_head
> *head)
> {
> unsigned long long cp_ver = cur_cp_version(F2FS_CKPT(sbi));
> struct curseg_info *curseg;
> - struct page *page;
> + struct page *page = NULL;
> block_t blkaddr;
> int err = 0;
>
> @@ -181,20 +181,19 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi,
> struct list_head
> *head)
> curseg = CURSEG_I(sbi, CURSEG_WARM_NODE);
> blkaddr = NEXT_FREE_BLKADDR(sbi, curseg);
>
> - /* read node page */
> - page = alloc_page(GFP_F2FS_ZERO);
> - if (!page)
> - return -ENOMEM;
> - lock_page(page);
> -
> while (1) {
> struct fsync_inode_entry *entry;
>
> - err = f2fs_submit_page_bio(sbi, page, blkaddr, READ_SYNC);
> - if (err)
> - return err;
> + if (blkaddr < SM_I(sbi)->main_blkaddr ||
> + blkaddr > TOTAL_BLKS(sbi))
blkaddr >= TOTAL_BLKS(sbi) ?
> + break;
>
> - lock_page(page);
> + page = get_meta_page(sbi, blkaddr);
> + if (IS_ERR(page))
> +
Re: FIX ME in oxu210p-hcd.c
On 14-09-21 10:24 PM, gre...@linuxfoundation.org wrote: > On Sun, Sep 21, 2014 at 10:17:38PM -0400, nick wrote: >> >> >> On 14-09-21 10:11 PM, gre...@linuxfoundation.org wrote: >>> On Sun, Sep 21, 2014 at 10:03:28PM -0400, nick wrote: On 14-09-21 07:53 PM, Peter Chen wrote: > > >> Subject: Re: FIX ME in oxu210p-hcd.c >> >> >> I found a unfixed FIX ME in the file stated in my above message. I am >> wondering what to set hcd->self.comtroller->dma_mask to as it's now been >> defined to NULL and clearly even as a newbie this seem incorrect. >> Regards Nick > > Usually, it is set at its controller driver or pass through through > device tree or > platform data. > > Peter > Sorry Peter, I apologize for asking for more help here but I will paste the function below and with my changes. Please let me known if I am wrong and how to fix it as I new here. Sorry for Wasting Your Time, >>> >>> Then please do not. Just because your other email addresses were banned >>> from lkml, don't keep popping up and bothering people, it's rude, and >>> will cause this address to be banned as well. >>> >> Sorry Greg, >> I don't want to get banned again. I was trying to help out and learn, I was >> apologizing not >> for wasting time as much as for making sure I wasn't wasting maintainer time >> again. I also >> am coming to the conclusion that my terrible patches were a waste of time >> and I am trying >> to get back into helping out. > > You were asked to finish the Eudyptula challenge before bothering any > other kernel developers with questions / patches. Until that happens, > you are in my killfile, now with yet-another-email-address. > > greg k-h > Greg K-H, I really don't want you to get any more upset with me then you already are. The reason I gave up on the challenge was it was mostly driver based and I wanted to learn more in other areas. If you would like to discuss with me your concerns about my work on this list and how I can aid more please let me known. Sorry , Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: FIX ME in oxu210p-hcd.c
On 14-09-21 10:11 PM, Peter Chen wrote:
>
>
Subject: Re: FIX ME in oxu210p-hcd.c
I found a unfixed FIX ME in the file stated in my above message. I am
wondering what to set hcd->self.comtroller->dma_mask to as it's now
been defined to NULL and clearly even as a newbie this seem incorrect.
Regards Nick
>>>
>>> Usually, it is set at its controller driver or pass through through
>>> device tree or platform data.
>>>
>>> Peter
>>>
>> Sorry Peter,
>> I apologize for asking for more help here but I will paste the function
>> below and
>> with my changes.
>> Please let me known if I am wrong and how to fix it as I new here.
>> Sorry for Wasting Your Time,
>
> You are welcome
>
>> Nick
>> static int oxu_reset(struct usb_hcd *hcd) {
>> struct oxu_hcd *oxu = hcd_to_oxu(hcd);
>> int ret;
>>
>> spin_lock_init(>mem_lock);
>> INIT_LIST_HEAD(>urb_list);
>> oxu->urb_len = 0;
>>
>> -/* FIMXE */
>> +hcd->self.controller->dma_mask = hcd->regs;
>>
>
> It is the dma mask, not the register.
>
> Try below patch to see if it works for you:
>
> diff --git a/drivers/usb/host/oxu210hp-hcd.c b/drivers/usb/host/oxu210hp-hcd.c
> index da5fb0e..5549851 100644
> --- a/drivers/usb/host/oxu210hp-hcd.c
> +++ b/drivers/usb/host/oxu210hp-hcd.c
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -3841,6 +3842,12 @@ static int oxu_drv_probe(struct platform_device *pdev)
> goto error;
> }
>
> + ret = dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(32));
> + if (ret) {
> + dev_err(>dev, "set dma mask error\n");
> + goto error;
> + }
> +
> /* Allocate a driver data struct to hold useful info for both
> * SPH & OTG devices
> */
>
> Peter
>
>
>> if (oxu->is_otg) {
>> oxu->caps = hcd->regs + OXU_OTG_CAP_OFFSET;
>> oxu->regs = hcd->regs + OXU_OTG_CAP_OFFSET + \
>> HC_LENGTH(readl(>caps->hc_capbase));
>>
>> oxu->mem = hcd->regs + OXU_SPH_MEM;
>> } else {
>> oxu->caps = hcd->regs + OXU_SPH_CAP_OFFSET;
>> oxu->regs = hcd->regs + OXU_SPH_CAP_OFFSET + \
>> HC_LENGTH(readl(>caps->hc_capbase));
>>
>> oxu->mem = hcd->regs + OXU_OTG_MEM;
>> }
>>
>> oxu->hcs_params = readl(>caps->hcs_params);
>> oxu->sbrn = 0x20;
>>
>> ret = oxu_hcd_init(hcd);
>> if (ret)
>> return ret;
>>
>> return 0;
>> }
Unfortunately I can't get it to apply with git apply and get the following
message,
Checking patch drivers/usb/host/oxu210hp-hcd.c...
error: while searching for:
goto error;
}
/* Allocate a driver data struct to hold useful info for both
* SPH & OTG devices
*/
error: patch failed: drivers/usb/host/oxu210hp-hcd.c:3841
error: drivers/usb/host/oxu210hp-hcd.c: patch does not apply
I will paste the version of my patch file for your troubles.
Regards Nick
diff --git a/drivers/usb/host/oxu210hp-hcd.c b/drivers/usb/host/oxu210hp-hcd.c
index da5fb0e..5549851 100644
--- a/drivers/usb/host/oxu210hp-hcd.c
+++ b/drivers/usb/host/oxu210hp-hcd.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
@@ -3841,6 +3842,12 @@ static int oxu_drv_probe(struct platform_device *pdev)
goto error;
}
+ ret = dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(32));
+ if (ret) {
+ dev_err(>dev, "set dma mask error\n");
+ goto error;
+ }
+
/* Allocate a driver data struct to hold useful info for both
* SPH & OTG devices
*/
Re: [PATCH] scripts: checkpatch.pl: Fix existing typedef false positive warning
On Sun, 2014-09-21 at 20:32 -0500, Greg Donald wrote:
> Fixing an "open brace '{' following struct go on the same line" error causes a
> false positive warning "do not add new typedefs". Fix existing typedef false
> positive warning.
This doesn't work.
The matching deleted line can be any number of lines above.
> Signed-off-by: Greg Donald
> ---
> scripts/checkpatch.pl | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 4d08b39..eafe5e7 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3081,14 +3081,24 @@ sub process {
> }
>
> # check for new typedefs, only function parameters and sparse annotations
> -# make sense.
> +# and existing typedefs make sense.
> if ($line =~ /\btypedef\s/ &&
> $line !~ /\btypedef\s+$Type\s*\(\s*\*?$Ident\s*\)\s*\(/ &&
> $line !~ /\btypedef\s+$Type\s+$Ident\s*\(/ &&
> $line !~ /\b$typeTypedefs\b/ &&
> $line !~ /\b__bitwise(?:__|)\b/) {
> - WARN("NEW_TYPEDEFS",
> - "do not add new typedefs\n" . $herecurr);
> + # check if $line is diff-like
> + if (substr($rawlines[$linenr - 3], 0, 1) eq '-') {
> + my $oldline3 = substr($rawlines[$linenr - 3],
> 1);
> + # check if typedef already existed
> + if ($line !~ /$oldline3/) {
> + WARN("NEW_TYPEDEFS",
> + "do not add new typedefs\n" .
> $herecurr);
> + }
> + } else {
> + WARN("NEW_TYPEDEFS",
> + "do not add new typedefs\n" . $herecurr);
> + }
> }
>
> # * goes on variable not on type
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: FIX ME in oxu210p-hcd.c
On Sun, Sep 21, 2014 at 10:17:38PM -0400, nick wrote: > > > On 14-09-21 10:11 PM, gre...@linuxfoundation.org wrote: > > On Sun, Sep 21, 2014 at 10:03:28PM -0400, nick wrote: > >> > >> > >> On 14-09-21 07:53 PM, Peter Chen wrote: > >>> > >>> > Subject: Re: FIX ME in oxu210p-hcd.c > > > I found a unfixed FIX ME in the file stated in my above message. I am > wondering what to set hcd->self.comtroller->dma_mask to as it's now been > defined to NULL and clearly even as a newbie this seem incorrect. > Regards Nick > >>> > >>> Usually, it is set at its controller driver or pass through through > >>> device tree or > >>> platform data. > >>> > >>> Peter > >>> > >> Sorry Peter, > >> I apologize for asking for more help here but I will paste the function > >> below and with my changes. > >> Please let me known if I am wrong and how to fix it as I new here. > >> Sorry for Wasting Your Time, > > > > Then please do not. Just because your other email addresses were banned > > from lkml, don't keep popping up and bothering people, it's rude, and > > will cause this address to be banned as well. > > > Sorry Greg, > I don't want to get banned again. I was trying to help out and learn, I was > apologizing not > for wasting time as much as for making sure I wasn't wasting maintainer time > again. I also > am coming to the conclusion that my terrible patches were a waste of time and > I am trying > to get back into helping out. You were asked to finish the Eudyptula challenge before bothering any other kernel developers with questions / patches. Until that happens, you are in my killfile, now with yet-another-email-address. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FIX ME in oxu210p-hcd.c
On 14-09-21 10:11 PM, gre...@linuxfoundation.org wrote: > On Sun, Sep 21, 2014 at 10:03:28PM -0400, nick wrote: >> >> >> On 14-09-21 07:53 PM, Peter Chen wrote: >>> >>> Subject: Re: FIX ME in oxu210p-hcd.c I found a unfixed FIX ME in the file stated in my above message. I am wondering what to set hcd->self.comtroller->dma_mask to as it's now been defined to NULL and clearly even as a newbie this seem incorrect. Regards Nick >>> >>> Usually, it is set at its controller driver or pass through through device >>> tree or >>> platform data. >>> >>> Peter >>> >> Sorry Peter, >> I apologize for asking for more help here but I will paste the function >> below and with my changes. >> Please let me known if I am wrong and how to fix it as I new here. >> Sorry for Wasting Your Time, > > Then please do not. Just because your other email addresses were banned > from lkml, don't keep popping up and bothering people, it's rude, and > will cause this address to be banned as well. > Sorry Greg, I don't want to get banned again. I was trying to help out and learn, I was apologizing not for wasting time as much as for making sure I wasn't wasting maintainer time again. I also am coming to the conclusion that my terrible patches were a waste of time and I am trying to get back into helping out. Cheers, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Racy manipulation of task_struct->flags in cgroups code causes hard to reproduce kernel panics
>> On Sat, Sep 20, 2014 at 01:55:54PM +0800, Zefan Li wrote:
Then, what made current->flags to unexpectedly preserve PF_USED_MATH flag?
The user is running cgrulesengd process in order to utilize cpuset cgroup.
Thus, cpuset_update_task_spread_flag() is called when cgrulesengd process
writes someone's pid to /cgroup/cpuset/$group/tasks interface.
cpuset_update_task_spread_flag() is updating other thread's
"struct task_struct"->flags without exclusion control or atomic
operations!
-- linux-2.6.32-358.23.2.el6/kernel/cpuset.c --
300:/*
301: * update task's spread flag if cpuset's page/slab spread flag is set
302: *
303: * Called with callback_mutex/cgroup_mutex held
304: */
305:static void cpuset_update_task_spread_flag(struct cpuset *cs,
306:struct task_struct *tsk)
307:{
308:if (is_spread_page(cs))
309:tsk->flags |= PF_SPREAD_PAGE;
310:else
311:tsk->flags &= ~PF_SPREAD_PAGE;
312:if (is_spread_slab(cs))
313:tsk->flags |= PF_SPREAD_SLAB;
314:else
315:tsk->flags &= ~PF_SPREAD_SLAB;
316:}
>>>
>>> We should make the updating of this flag atomic.
>>
>> Ugh, why do we even implement that in cpuset. This should be handled
>> by MPOL_INTERLEAVE. It feels like people have been using cpuset as
>> the dumpsite that people used w/o thinking much. Going forward, let's
>> please confine cpuset to collective cpu and memory affinity
>> configuration. It really shouldn't be implementing novel features for
>> scheduler or mm.
>>
>> Anyways, yeah, the patch looks correct to me. Can you please send a
>> version w/ proper description and sob?
>>
>
> This race condition exists since commit 950592f7b991 ("cpusets: update
> tasks' page/slab spread flags in time") (i.e. Linux 2.6.31 and later)
> but "struct task_struct"->atomic_flags was added in Linux 3.17.
>
> If use of ->atomic_flags for cpuset is acceptable, how should we fix
> older kernels? Backport ->atomic_flags?
>
Yeah, we'll just add tsk->atomic_flags to struct task_struct when
backporting this patch for stable trees.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] f2fs: fix roll-forward missing scenarios
On Sat, 2014-09-20 at 20:36 -0700, Jaegeuk Kim wrote:
> On Sun, Sep 21, 2014 at 07:22:32AM +0800, Huang Ying wrote:
> > On Sat, 2014-09-20 at 09:23 -0700, Jaegeuk Kim wrote:
> > > On Thu, Sep 18, 2014 at 09:04:11PM +0800, huang ying wrote:
> > > > On Thu, Sep 18, 2014 at 1:51 PM, Jaegeuk Kim wrote:
> > > >
> > > > > We can summarize the roll forward recovery scenarios as follows.
> > > > >
> > > > > [Term] F: fsync_mark, D: dentry_mark
> > > > >
> > > > > 1. inode(x) | CP | inode(x) | dnode(F)
> > > > > -> Update the latest inode(x).
> > > > >
> > > > > 2. inode(x) | CP | inode(F) | dnode(F)
> > > > > -> No problem.
> > > > >
> > > > > 3. inode(x) | CP | dnode(F) | inode(x)
> > > > > -> Recover to the latest dnode(F), and drop the last inode(x)
> > > > >
> > > > > 4. inode(x) | CP | dnode(F) | inode(F)
> > > > > -> No problem.
> > > > >
> > > > > 5. CP | inode(x) | dnode(F)
> > > > > -> The inode(DF) was missing. Should drop this dnode(F).
> > > > >
> > > > > 6. CP | inode(DF) | dnode(F)
> > > > > -> No problem.
> > > > >
> > > > > 7. CP | dnode(F) | inode(DF)
> > > > > -> If f2fs_iget fails, then goto next to find inode(DF).
> > > > >
> > > > > 8. CP | dnode(F) | inode(x)
> > > > > -> If f2fs_iget fails, then goto next to find inode(DF).
> > > > >But it will fail due to no inode(DF).
> > > > >
> > > > > So, this patch adds some missing points such as #1, #5, #7, and #8.
> > > > >
> > > > > Signed-off-by: Huang Ying
> > > > > Signed-off-by: Jaegeuk Kim
> > > > > ---
> > > > > fs/f2fs/recovery.c | 71
> > > > > +-
> > > > > 1 file changed, 60 insertions(+), 11 deletions(-)
> > > > >
> > > > > diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
> > > > > index 36d4f73..a4eb978 100644
> > > > > --- a/fs/f2fs/recovery.c
> > > > > +++ b/fs/f2fs/recovery.c
> > > > > @@ -14,6 +14,37 @@
> > > > > #include "node.h"
> > > > > #include "segment.h"
> > > > >
> > > > > +/*
> > > > > + * Roll forward recovery scenarios.
> > > > > + *
> > > > > + * [Term] F: fsync_mark, D: dentry_mark
> > > > > + *
> > > > > + * 1. inode(x) | CP | inode(x) | dnode(F)
> > > > > + * -> Update the latest inode(x).
> > > > > + *
> > > > > + * 2. inode(x) | CP | inode(F) | dnode(F)
> > > > > + * -> No problem.
> > > > > + *
> > > > > + * 3. inode(x) | CP | dnode(F) | inode(x)
> > > > > + * -> Recover to the latest dnode(F), and drop the last inode(x)
> > > > > + *
> > > > > + * 4. inode(x) | CP | dnode(F) | inode(F)
> > > > > + * -> No problem.
> > > > > + *
> > > > > + * 5. CP | inode(x) | dnode(F)
> > > > > + * -> The inode(DF) was missing. Should drop this dnode(F).
> > > > > + *
> > > > > + * 6. CP | inode(DF) | dnode(F)
> > > > > + * -> No problem.
> > > > > + *
> > > > > + * 7. CP | dnode(F) | inode(DF)
> > > > > + * -> If f2fs_iget fails, then goto next to find inode(DF).
> > > > > + *
> > > > > + * 8. CP | dnode(F) | inode(x)
> > > > > + * -> If f2fs_iget fails, then goto next to find inode(DF).
> > > > > + *But it will fail due to no inode(DF).
> > > > > + */
> > > > > +
> > > > > static struct kmem_cache *fsync_entry_slab;
> > > > >
> > > > > bool space_for_roll_forward(struct f2fs_sb_info *sbi)
> > > > > @@ -110,27 +141,32 @@ out:
> > > > > return err;
> > > > > }
> > > > >
> > > > > -static int recover_inode(struct inode *inode, struct page *node_page)
> > > > > +static void __recover_inode(struct inode *inode, struct page *page)
> > > > > {
> > > > > - struct f2fs_inode *raw_inode = F2FS_INODE(node_page);
> > > > > + struct f2fs_inode *raw = F2FS_INODE(page);
> > > > > +
> > > > > + inode->i_mode = le16_to_cpu(raw->i_mode);
> > > > > + i_size_write(inode, le64_to_cpu(raw->i_size));
> > > > > + inode->i_atime.tv_sec = le64_to_cpu(raw->i_mtime);
> > > > > + inode->i_ctime.tv_sec = le64_to_cpu(raw->i_ctime);
> > > > > + inode->i_mtime.tv_sec = le64_to_cpu(raw->i_mtime);
> > > > > + inode->i_atime.tv_nsec = le32_to_cpu(raw->i_mtime_nsec);
> > > > > + inode->i_ctime.tv_nsec = le32_to_cpu(raw->i_ctime_nsec);
> > > > > + inode->i_mtime.tv_nsec = le32_to_cpu(raw->i_mtime_nsec);
> > > > > +}
> > > > >
> > > > > +static int recover_inode(struct inode *inode, struct page *node_page)
> > > > > +{
> > > > > if (!IS_INODE(node_page))
> > > > > return 0;
> > > > >
> > > > > - inode->i_mode = le16_to_cpu(raw_inode->i_mode);
> > > > > - i_size_write(inode, le64_to_cpu(raw_inode->i_size));
> > > > > - inode->i_atime.tv_sec = le64_to_cpu(raw_inode->i_mtime);
> > > > > - inode->i_ctime.tv_sec = le64_to_cpu(raw_inode->i_ctime);
> > > > > - inode->i_mtime.tv_sec = le64_to_cpu(raw_inode->i_mtime);
> > > > > - inode->i_atime.tv_nsec = le32_to_cpu(raw_inode->i_mtime_nsec);
> > > > > - inode->i_ctime.tv_nsec = le32_to_cpu(raw_inode->i_ctime_nsec);
> > > > > - inode->i_mtime.tv_nsec = le32_to_cpu(raw_inode->i_mtime_nsec);
> > > > > +
Re: FIX ME in oxu210p-hcd.c
On Sun, Sep 21, 2014 at 10:03:28PM -0400, nick wrote: > > > On 14-09-21 07:53 PM, Peter Chen wrote: > > > > > >> Subject: Re: FIX ME in oxu210p-hcd.c > >> > >> > >> I found a unfixed FIX ME in the file stated in my above message. I am > >> wondering what to set hcd->self.comtroller->dma_mask to as it's now been > >> defined to NULL and clearly even as a newbie this seem incorrect. > >> Regards Nick > > > > Usually, it is set at its controller driver or pass through through device > > tree or > > platform data. > > > > Peter > > > Sorry Peter, > I apologize for asking for more help here but I will paste the function below > and with my changes. > Please let me known if I am wrong and how to fix it as I new here. > Sorry for Wasting Your Time, Then please do not. Just because your other email addresses were banned from lkml, don't keep popping up and bothering people, it's rude, and will cause this address to be banned as well. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: FIX ME in oxu210p-hcd.c
> >> Subject: Re: FIX ME in oxu210p-hcd.c
> >>
> >>
> >> I found a unfixed FIX ME in the file stated in my above message. I am
> >> wondering what to set hcd->self.comtroller->dma_mask to as it's now
> >> been defined to NULL and clearly even as a newbie this seem incorrect.
> >> Regards Nick
> >
> > Usually, it is set at its controller driver or pass through through
> > device tree or platform data.
> >
> > Peter
> >
> Sorry Peter,
> I apologize for asking for more help here but I will paste the function below
> and
> with my changes.
> Please let me known if I am wrong and how to fix it as I new here.
> Sorry for Wasting Your Time,
You are welcome
> Nick
> static int oxu_reset(struct usb_hcd *hcd) {
> struct oxu_hcd *oxu = hcd_to_oxu(hcd);
> int ret;
>
> spin_lock_init(>mem_lock);
> INIT_LIST_HEAD(>urb_list);
> oxu->urb_len = 0;
>
> - /* FIMXE */
> + hcd->self.controller->dma_mask = hcd->regs;
>
It is the dma mask, not the register.
Try below patch to see if it works for you:
diff --git a/drivers/usb/host/oxu210hp-hcd.c b/drivers/usb/host/oxu210hp-hcd.c
index da5fb0e..5549851 100644
--- a/drivers/usb/host/oxu210hp-hcd.c
+++ b/drivers/usb/host/oxu210hp-hcd.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
@@ -3841,6 +3842,12 @@ static int oxu_drv_probe(struct platform_device *pdev)
goto error;
}
+ ret = dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(32));
+ if (ret) {
+ dev_err(>dev, "set dma mask error\n");
+ goto error;
+ }
+
/* Allocate a driver data struct to hold useful info for both
* SPH & OTG devices
*/
Peter
> if (oxu->is_otg) {
> oxu->caps = hcd->regs + OXU_OTG_CAP_OFFSET;
> oxu->regs = hcd->regs + OXU_OTG_CAP_OFFSET + \
> HC_LENGTH(readl(>caps->hc_capbase));
>
> oxu->mem = hcd->regs + OXU_SPH_MEM;
> } else {
> oxu->caps = hcd->regs + OXU_SPH_CAP_OFFSET;
> oxu->regs = hcd->regs + OXU_SPH_CAP_OFFSET + \
> HC_LENGTH(readl(>caps->hc_capbase));
>
> oxu->mem = hcd->regs + OXU_OTG_MEM;
> }
>
> oxu->hcs_params = readl(>caps->hcs_params);
> oxu->sbrn = 0x20;
>
> ret = oxu_hcd_init(hcd);
> if (ret)
> return ret;
>
> return 0;
> }
Re: FIX ME in oxu210p-hcd.c
On 14-09-21 07:53 PM, Peter Chen wrote:
>
>
>> Subject: Re: FIX ME in oxu210p-hcd.c
>>
>>
>> I found a unfixed FIX ME in the file stated in my above message. I am
>> wondering what to set hcd->self.comtroller->dma_mask to as it's now been
>> defined to NULL and clearly even as a newbie this seem incorrect.
>> Regards Nick
>
> Usually, it is set at its controller driver or pass through through device
> tree or
> platform data.
>
> Peter
>
Sorry Peter,
I apologize for asking for more help here but I will paste the function below
and with my changes.
Please let me known if I am wrong and how to fix it as I new here.
Sorry for Wasting Your Time,
Nick
static int oxu_reset(struct usb_hcd *hcd)
{
struct oxu_hcd *oxu = hcd_to_oxu(hcd);
int ret;
spin_lock_init(>mem_lock);
INIT_LIST_HEAD(>urb_list);
oxu->urb_len = 0;
- /* FIMXE */
+ hcd->self.controller->dma_mask = hcd->regs;
if (oxu->is_otg) {
oxu->caps = hcd->regs + OXU_OTG_CAP_OFFSET;
oxu->regs = hcd->regs + OXU_OTG_CAP_OFFSET + \
HC_LENGTH(readl(>caps->hc_capbase));
oxu->mem = hcd->regs + OXU_SPH_MEM;
} else {
oxu->caps = hcd->regs + OXU_SPH_CAP_OFFSET;
oxu->regs = hcd->regs + OXU_SPH_CAP_OFFSET + \
HC_LENGTH(readl(>caps->hc_capbase));
oxu->mem = hcd->regs + OXU_OTG_MEM;
}
oxu->hcs_params = readl(>caps->hcs_params);
oxu->sbrn = 0x20;
ret = oxu_hcd_init(hcd);
if (ret)
return ret;
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/can/flexcan.c between commit fc05b884a31d ("can: flexcan:
correctly initialize mailboxes") from the net tree and commit
cdce844865be ("can: flexcan: add vf610 support for FlexCAN") from the
net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/can/flexcan.c
index 6586309329e6,2700865efcad..
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@@ -824,8 -859,7 +883,8 @@@ static int flexcan_chip_start(struct ne
struct flexcan_priv *priv = netdev_priv(dev);
struct flexcan_regs __iomem *regs = priv->base;
int err;
- u32 reg_mcr, reg_ctrl;
+ u32 reg_mcr, reg_ctrl, reg_crl2, reg_mecr;
+ int i;
/* enable module */
err = flexcan_chip_enable(priv);
signature.asc
Description: PGP signature
RE: [PATCH] ARM: ls1021a: add gating clocks to IP blocks.
Hi,
> Subject: Re: [PATCH] ARM: ls1021a: add gating clocks to IP blocks.
>
> On Fri, Sep 19, 2014 at 11:37:27AM +0100, Xiubo Li wrote:
> > A given application may not use all the peripherals on the device.
> > In this case, it may be desirable to disable unused peripherals.
> > DCFG provides a mechanism for gating clocks to IP blocks that are
> > not used when running an application.
> >
> > Signed-off-by: Xiubo Li
> > ---
> > arch/arm/mach-imx/Makefile| 2 +
> > arch/arm/mach-imx/clk-ls1021a.c | 124
> ++
> > arch/arm/mach-imx/clk.h | 21 +
> > include/dt-bindings/clock/ls1021a-clock.h | 54 +
> > 4 files changed, 201 insertions(+)
> > create mode 100644 arch/arm/mach-imx/clk-ls1021a.c
> > create mode 100644 include/dt-bindings/clock/ls1021a-clock.h
>
> This looks to be missing an addition to Documentation/devicetree. Please
> put together a document.
>
Okay, I will do it.
Thanks,
BRs
Xiubo
> Mark.
>
> >
> > diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> > index 6e4fcd8..f6a1544 100644
> > --- a/arch/arm/mach-imx/Makefile
> > +++ b/arch/arm/mach-imx/Makefile
> > @@ -110,4 +110,6 @@ obj-$(CONFIG_SOC_IMX53) += mach-imx53.o
> >
> > obj-$(CONFIG_SOC_VF610) += clk-vf610.o mach-vf610.o
> >
> > +obj-$(CONFIG_SOC_LS1021A) += clk-ls1021a.o
> > +
> > obj-y += devices/
> > diff --git a/arch/arm/mach-imx/clk-ls1021a.c b/arch/arm/mach-imx/clk-
> ls1021a.c
> > new file mode 100644
> > index 000..680b616
> > --- /dev/null
> > +++ b/arch/arm/mach-imx/clk-ls1021a.c
> > @@ -0,0 +1,124 @@
> > +/*
> > + * Copyright 2014 Freescale Semiconductor, Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "clk.h"
> > +
> > +static struct clk *clk[LS1021A_CLK_END];
> > +static struct clk_onecell_data clk_data;
> > +
> > +static void __init ls1021a_clocks_init(struct device_node *np)
> > +{
> > + void __iomem *dcfg_base;
> > +
> > +#define DCFG_CCSR_DEVDISR1 (dcfg_base + 0x70)
> > +#define DCFG_CCSR_DEVDISR2 (dcfg_base + 0x74)
> > +#define DCFG_CCSR_DEVDISR3 (dcfg_base + 0x78)
> > +#define DCFG_CCSR_DEVDISR4 (dcfg_base + 0x7c)
> > +#define DCFG_CCSR_DEVDISR5 (dcfg_base + 0x80)
> > +
> > + dcfg_base = of_iomap(np, 0);
> > +
> > + BUG_ON(!dcfg_base);
> > +
> > + clk[LS1021A_CLK_PBL_EN] = ls1021a_clk_gate("pbl_en", "dummy",
> > + DCFG_CCSR_DEVDISR1, 0,
> > true);
> > + clk[LS1021A_CLK_ESDHC_EN] = ls1021a_clk_gate("esdhc_en", "dummy",
> > + DCFG_CCSR_DEVDISR1, 2,
> > true);
> > + clk[LS1021A_CLK_DMA1_EN] = ls1021a_clk_gate("dma1_en", "dummy",
> > + DCFG_CCSR_DEVDISR1, 8,
> > true);
> > + clk[LS1021A_CLK_DMA2_EN] = ls1021a_clk_gate("dma2_en", "dummy",
> > + DCFG_CCSR_DEVDISR1, 9,
> > true);
> > + clk[LS1021A_CLK_USB3_PHY_EN] = ls1021a_clk_gate("usb3_phy_en",
> "dummy",
> > + DCFG_CCSR_DEVDISR1, 12,
> true);
> > + clk[LS1021A_CLK_USB2_EN] = ls1021a_clk_gate("usb2_en", "dummy",
> > + DCFG_CCSR_DEVDISR1, 13,
> true);
> > + clk[LS1021A_CLK_SATA_EN] = ls1021a_clk_gate("sata_en", "dummy",
> > + DCFG_CCSR_DEVDISR1, 16,
> true);
> > + clk[LS1021A_CLK_USB3_EN] = ls1021a_clk_gate("usb3_en", "dummy",
> > + DCFG_CCSR_DEVDISR1, 17,
> true);
> > + clk[LS1021A_CLK_SEC_EN] = ls1021a_clk_gate("sec_en", "dummy",
> > + DCFG_CCSR_DEVDISR1, 22,
> true);
> > + clk[LS1021A_CLK_2D_ACE_EN] = ls1021a_clk_gate("2d_ace_en", "dummy",
> > + DCFG_CCSR_DEVDISR1, 30,
> true);
> > + clk[LS1021A_CLK_QE_EN] = ls1021a_clk_gate("qe_en", "dummy",
> > + DCFG_CCSR_DEVDISR1, 31,
> true);
> > +
> > + clk[LS1021A_CLK_ETSEC1_EN] = ls1021a_clk_gate("etsec1_en", "dummy",
> > + DCFG_CCSR_DEVDISR2, 0,
> > true);
> > + clk[LS1021A_CLK_ETSEC2_EN] = ls1021a_clk_gate("etsec2_en", "dummy",
> > + DCFG_CCSR_DEVDISR2, 1,
> > true);
> > + clk[LS1021A_CLK_ETSEC3_EN] = ls1021a_clk_gate("etsec3_en", "dummy",
> > + DCFG_CCSR_DEVDISR2, 2,
> > true);
> > +
> > +
[PATCH] scripts: checkpatch.pl: Fix existing typedef false positive warning
Fixing an "open brace '{' following struct go on the same line" error causes a
false positive warning "do not add new typedefs". Fix existing typedef false
positive warning.
Signed-off-by: Greg Donald
---
scripts/checkpatch.pl | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 4d08b39..eafe5e7 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3081,14 +3081,24 @@ sub process {
}
# check for new typedefs, only function parameters and sparse annotations
-# make sense.
+# and existing typedefs make sense.
if ($line =~ /\btypedef\s/ &&
$line !~ /\btypedef\s+$Type\s*\(\s*\*?$Ident\s*\)\s*\(/ &&
$line !~ /\btypedef\s+$Type\s+$Ident\s*\(/ &&
$line !~ /\b$typeTypedefs\b/ &&
$line !~ /\b__bitwise(?:__|)\b/) {
- WARN("NEW_TYPEDEFS",
-"do not add new typedefs\n" . $herecurr);
+ # check if $line is diff-like
+ if (substr($rawlines[$linenr - 3], 0, 1) eq '-') {
+ my $oldline3 = substr($rawlines[$linenr - 3],
1);
+ # check if typedef already existed
+ if ($line !~ /$oldline3/) {
+ WARN("NEW_TYPEDEFS",
+"do not add new typedefs\n" .
$herecurr);
+ }
+ } else {
+ WARN("NEW_TYPEDEFS",
+"do not add new typedefs\n" . $herecurr);
+ }
}
# * goes on variable not on type
--
1.9.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 3/3 v2] GPIO: gpio-dwapb: Suspend & Resume PM enabling
>
> > +/* Store GPIO context across system-wide suspend/resume transitions
> > +*/ static struct dwapb_context {
> > + u32 data[DWAPB_MAX_PORTS];
> > + u32 dir[DWAPB_MAX_PORTS];
> > + u32 ext[DWAPB_MAX_PORTS];
> > + u32 int_en;
> > + u32 int_mask;
> > + u32 int_type;
> > + u32 int_pol;
> > + u32 int_deb;
> > +} dwapb_context;
>
> NAK, this should STILL be part of the device state container. Not a local
> variable.
>
> I've said this before. Please fix this, thanks.
>
Linus, please review Version 5 that I sent on Sep.17th. I have fixed it in the
v5.
Re: [PATCH v3 1/5] drm/rockchip: Add basic drm driver
On 2014年09月20日 08:03, Rob Clark wrote:
On Fri, Sep 19, 2014 at 1:47 AM, Mark yao wrote:
diff --git a/include/uapi/drm/rockchip_drm.h b/include/uapi/drm/rockchip_drm.h
new file mode 100644
index 000..8f8e60e
--- /dev/null
+++ b/include/uapi/drm/rockchip_drm.h
@@ -0,0 +1,97 @@
+/*
+ *
+ * Copyright (c) Fuzhou Rockchip Electronics Co.Ltd
+ * Authors:
+ * Mark Yao
+ *
+ * base on exynos_drm.h
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#ifndef _UAPI_ROCKCHIP_DRM_H
+#define _UAPI_ROCKCHIP_DRM_H
+
+#include
+
+/**
+ * User-desired buffer creation information structure.
+ *
+ * @size: user-desired memory allocation size.
+ * @flags: user request for setting memory type or cache attributes.
+ * @handle: returned a handle to created gem object.
+ * - this handle will be set by gem module of kernel side.
+ */
+struct drm_rockchip_gem_create {
+ uint64_t size;
+ uint32_t flags;
+ uint32_t handle;
+};
+
+/**
+ * A structure for getting buffer offset.
+ *
+ * @handle: a pointer to gem object created.
+ * @pad: just padding to be 64-bit aligned.
+ * @offset: relatived offset value of the memory region allocated.
+ * - this value should be set by user.
+ */
+struct drm_rockchip_gem_map_off {
+ uint32_t handle;
+ uint32_t pad;
+ uint64_t offset;
+};
+
+/**
+ * A structure for mapping buffer.
+ *
+ * @handle: a handle to gem object created.
+ * @pad: just padding to be 64-bit aligned.
+ * @size: memory size to be mapped.
+ * @mapped: having user virtual address mmaped.
+ * - this variable would be filled by rockchip gem module
+ * of kernel side with user virtual address which is allocated
+ * by do_mmap().
+ */
+struct drm_rockchip_gem_mmap {
+ uint32_t handle;
+ uint32_t pad;
+ uint64_t size;
+ uint64_t mapped;
+};
Could we do without the mmap ioctl? It has been a source of problems
in other drivers, and the ioctl to get mmap offset, plus normal mmap()
on drm device file should be sufficient
BR,
-R
OK, I will try to move the special mmap ioctl and use drm generic mmap
interface.
+/**
+ * A structure to gem information.
+ *
+ * @handle: a handle to gem object created.
+ * @flags: flag value including memory type and cache attribute and
+ * this value would be set by driver.
+ * @size: size to memory region allocated by gem and this size would
+ * be set by driver.
+ */
+struct drm_rockchip_gem_info {
+ uint32_t handle;
+ uint32_t flags;
+ uint64_t size;
+};
+
+#define DRM_ROCKCHIP_GEM_CREATE0x00
+#define DRM_ROCKCHIP_GEM_MAP_OFFSET0x01
+#define DRM_ROCKCHIP_GEM_MMAP 0x02
+#define DRM_ROCKCHIP_GEM_GET 0x04
+
+#define DRM_IOCTL_ROCKCHIP_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + \
+ DRM_ROCKCHIP_GEM_CREATE, struct drm_rockchip_gem_create)
+
+#define DRM_IOCTL_ROCKCHIP_GEM_MAP_OFFSET DRM_IOWR(DRM_COMMAND_BASE + \
+ DRM_ROCKCHIP_GEM_MAP_OFFSET, struct drm_rockchip_gem_map_off)
+
+#define DRM_IOCTL_ROCKCHIP_GEM_MMAPDRM_IOWR(DRM_COMMAND_BASE + \
+ DRM_ROCKCHIP_GEM_MMAP, struct drm_rockchip_gem_mmap)
+
+#define DRM_IOCTL_ROCKCHIP_GEM_GET DRM_IOWR(DRM_COMMAND_BASE + \
+ DRM_ROCKCHIP_GEM_GET, struct drm_rockchip_gem_info)
+#endif /* _UAPI_ROCKCHIP_DRM_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/5] drm/rockchip: Add basic drm driver
On 2014年09月19日 21:04, David Herrmann wrote:
Hi
On Fri, Sep 19, 2014 at 7:47 AM, Mark yao wrote:
[snip]
+static int rockchip_drm_bind(struct device *dev)
+{
+ return drm_platform_init(_drm_driver, to_platform_device(dev));
Please avoid drm_platform_*() usage. We're about to drop all the
drm_bus midlayers. See the tegra driver how to do it, but basically
just this:
OK, I will do it.
struct drm_device *ddev;
ddev = drm_dev_alloc(_drm_driver, _platform_device(dev)->dev);
if (!ddev)
return -ENOMEM;
r = drm_dev_set_unique(ddev, dev_name(>dev));
if (r < 0) {
drm_dev_unref(ddev);
return r;
}
r = drm_dev_register(ddev);
if (r < 0) {
drm_dev_unref(ddev);
return r;
}
+}
+
+static void rockchip_drm_unbind(struct device *dev)
+{
+ drm_put_dev(dev_get_drvdata(dev));
Please use:
struct drm_device *ddev = dev_get_drvdata(dev);
drm_dev_unregister(ddev);
drm_dev_unref(ddev);
Thanks
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 0/4] APM X-Gene PCIe host controller
Hi Tanmay, On Sat, Sep 20, 2014 at 1:15 AM, Tanmay Inamdar wrote: > Hi Ming Lei, > > On Thu, Sep 18, 2014 at 8:08 PM, Ming Lei wrote: >> Hi Tanmay, >> >> On Wed, Sep 17, 2014 at 6:33 AM, Tanmay Inamdar wrote: >>> This patch adds support for AppliedMicro X-Gene PCIe host controller. The >>> driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint >>> cards. >>> >>> X-Gene PCIe controller driver has depedency on the pcie arm64 arch support. >>> Liviu Dudau from ARM has sent a patch set for pcie arm64 arch support and >>> support for creating generic pcie bridge from device tree. Liviu's patches >>> are available here >>> https://lkml.org/lkml/2014/9/8/333 >>> >>> If someone wishes to test PCIe on X-Gene with this patch set, above >>> mentioned >>> patches from Liviu must be applied before the patches in this patch set. >>> Also >>> please use latest xgene u-boot firmware. >>> >>> changes since V8: >>> 1. Add 'dma-coherent' attribute in device node. >> >> >> I just tested your V9 patches plus Liviu's V10 PCI/ARM64 patches >> against 3.17-rc5 on Mustang, and the following failure is triggered: >> >> [1.190131] bnx2x: Broadcom NetXtreme II 5771x/578xx 10/20-Gigabit >> Ethernet Driver bnx2x 1.78.19-0 (2014/02/10) >> [1.200249] tg3.c:v3.137 (May 11, 2014) >> [1.204087] [ cut here ] >> [1.208682] WARNING: CPU: 1 PID: 1 at drivers/pci/pci.c:131 >> pci_ioremap_bar+0x70/0x78() >> [1.216646] Modules linked in: >> [1.219696] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc5+ #1 >> [1.226018] Call trace: >> [1.228453] [] dump_backtrace+0x0/0x16c >> [1.233826] [] show_stack+0x10/0x1c >> [1.238851] [] dump_stack+0x74/0x94 >> [1.243878] [] warn_slowpath_common+0x88/0xb0 >> [1.249767] [] warn_slowpath_null+0x14/0x20 >> [1.255485] [] pci_ioremap_bar+0x6c/0x78 >> [1.260942] [] tg3_init_one+0x148/0x16f4 >> [1.266401] [] pci_device_probe+0x78/0xd4 >> [1.271946] [] driver_probe_device+0x94/0x390 >> [1.277834] [] __driver_attach+0x98/0xa0 >> [1.283293] [] bus_for_each_dev+0x54/0x98 >> [1.288835] [] driver_attach+0x1c/0x28 >> [1.294121] [] bus_add_driver+0x164/0x240 >> [1.299663] [] driver_register+0x64/0x130 >> [1.305207] [] __pci_register_driver+0x3c/0x48 >> [1.311181] [] tg3_driver_init+0x1c/0x28 >> [1.316640] [] do_one_initcall+0xc4/0x1b4 >> [1.322186] [] kernel_init_freeable+0x1b8/0x25c >> [1.328246] [] kernel_init+0xc/0xd4 >> [1.333278] ---[ end trace f4dca5ab5b436080 ]--- >> [1.337871] tg3 :01:00.0: Cannot map device registers, aborting >> [1.344122] tg3: probe of :01:00.0 failed with error -12 >> >> > > Thanks for trying out the patches. Which firmware version are you > using? We may have release new firmware version for PCI to work if not > released yet. U-Boot 2013.04-mustang_sw_1.13.28-beta (Aug 25 2014 - 14:16:10) I will check if there is newer fw available. > Also can you please send out the entire boot log? Please see below link: http://pastebin.com/fLqaDn6t Thanks, -- Ming Lei > > Thanks, > Tanmay > >> >> Thanks, >> >>> >>> changes since V7: >>> 1. Fix outbound region mapping for IO region. Thanks Liviu for the catch. >>> >>> changes since V6: >>> 1. Port driver to changed interface as per Liviu's v10 series. >>> >>> changes since V5: >>> 1. Port driver to changed interface of 'of_create_pci_host_bridge' >>> 2. Fix the prefetch bit setting >>> 3. Removed bunch of register programming which is already done by firmware >>> >>> changes since V4: >>> 1. fix section mismatch warnings >>> 2. fix the patch description >>> 3. fix indentation >>> 4. update read/write cfg functions by passing both addr and offset. >>> 5. use 'time_before' for timeout. >>> 6. remove unnecessary 'IS_ERR_OR_NULL'. Keep 'IS_ERR' for 'clk_get' >>> 7. remove BUG_ON for pci_ioremap_io. >>> >>> changes since V3: >>> 1. remove 'struct hw_pci' and supporting ops in hw_pci >>> 2. add code to create the host bridge from dts >>> 3. add code to scan the the host bridge >>> 4. modify outbound windows setup function to get resource information from >>>'bridge->windows' >>> 5. add compatible string in pcie dts node with current X-Gene SOC name. >>> >>> changes since V2: >>> 1. redefined each PCI port in different PCI domain correctly. >>> 2. removed setup_lane and setup_link functions from driver. >>> 3. removed scan_bus wrapper and set_primary_bus hack. >>> 4. added pci_ioremap_io for io resources. >>> >>> changes since V1: >>> 1. added PCI domain support >>> 2. reading cpu and pci addresses from device tree to configure regions. >>> 3. got rid of unnecessary wrappers for readl and writel. >>> 4. got rid of endpoint configuration code. >>> 5. added 'dma-ranges' property support to read inbound region configuration. >>> 6. renamed host driver file to 'pci-xgene.c' from 'pcie-xgene.c' >>> 7. dropped 'clock-names' property from bindings >>> 8. added comments whereever
Re: [PATCH v3 0/7] mtd: denali: A collection of trivial coding style fixes
Hi Brian, On Fri, 19 Sep 2014 10:00:20 -0700 Brian Norris wrote: > On Tue, Sep 16, 2014 at 08:04:18PM +0900, Masahiro Yamada wrote: > > > > > > Masahiro Yamada (7): > > mtd: denali: fix the format of comment blocks > > mtd: denali: remove unnecessary variable initializations > > mtd: denali: remove unnecessary casts > > mtd: denali: change the type of iterators to int > > I already merged these 4. > > > mtd: denali: remove a set-but-unused variable > > This one was merged but you changed it (and falsely kept the > 'Reviewed-by' tag). So I split it out into its own patch and dropped the > 'Reviewed-by'. > > > mtd: denali: remove unnecessary parentheses > > mtd: denali: fix indents and other trivial things > > Applied a modified version of the last three, to l2-mtd.git. Feel free > to check my work, but git tells me that the end result is identical. Everything looks good. Many thanks!! Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 1/2] iio: vadc: Qualcomm SPMI PMIC voltage ADC driver
Hello Jonathan and Stanimir, > >> See Documentation/ABI/sysfs-bus-iio > >> Millivolts I think... We copied hwmon where possible. > > > > I'm a bit confused about these units. I searched references of > > iio_read_channel_processed() and found a few. > > > > The iio_hwmon expecting milivolts. On the other side lp8788-charger.c > > registers a get_property method in charger-manager.c, which expects > > microvolts in get_batt_uV(). > It's definitely meant to be millivolts (lifted from hwmon a while back). > See Documentation/ABI/testing/sysfs-bus-iio > > Looks like we have a bug in lp8788-charger - it might be matched with one in > lp8788-adc, but then there will be a bug there... > > Cc'd Milo Kim. 'lp8788-charger' registers not charger-manager but power-supply subsystem. 'lp8788-adc' is the IIO driver. 'lp8788-charger' is the IIO consumer of lp8788-adc. (How to communicate between lp8788-adc and lp8788-charger) 1. Application requests vbatt(battery voltage) by accessing /sys/class/power/ 2. lp8788-charger asks lp8788-adc to get converted vbatt value 3. lp8788-adc get the battery ADC from the device. It returns calculated micro voltage to lp8788-charger. 4. lp8788-charger reports this uV value to the application 5. Application uses uV or converts to mV or V unit. It's up to the app. Please note that battery app accesses not /sys/bus/iio but /sys/class/power/. Best regards, Milo
Re: x86, microcode: BUG: microcode update that changes x86_capability
On Sun, Sep 21, 2014 at 05:51:12PM -0700, H. Peter Anvin wrote: > He said *outside* of the early update mechanism. True. Sorry yes I misread it. Yes, that's the way to go. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Fix nasty 32-bit overflow bug in buffer i/o code.
Any code that uses __getblk() and thus bread(), breadahead(), sb_bread(),
sb_breadahead(), sb_getblk(), and calls it using a 64-bit block on a
32-bit arch (where "long" is 32-bit) causes an inifinite loop in
__getblk_slow() with an infinite stream of errors logged to dmesg like
this:
__find_get_block_slow() failed. block=6740375944, b_blocknr=2445408648
b_state=0x0020, b_size=512
device sda1 blocksize: 512
Note how in hex block is 0x191C1F988 and b_blocknr is 0x91C1F988 i.e. the
top 32-bits are missing (in this case the 0x1 at the top).
This is because grow_dev_page() was broken in commit 676ce6d5ca30: "block:
replace __getblk_slow misfix by grow_dev_page fix" by Hugh Dickins so that
it now has a 32-bit overflow due to shifting the block value to the right
so it fits in 32-bits and storing the result in pgoff_t variable which is
32-bit and then passing the pgoff_t variable left-shifted as the block
number which causes the top bits to get lost as the pgoff_t is not type
cast to sector_t / 64-bit before the shift.
This patch fixes this issue by type casting "index" to sector_t before
doing the left shift.
Note this is not a theoretical bug but has been seen in the field on a
4TiB hard drive with logical sector size 512 bytes.
This patch has been verified to fix the infinite loop problem on 3.17-rc5
kernel using a 4TB disk image mounted using "-o loop". Without this patch
doing a "find /nt" where /nt is an NTFS volume causes the inifinite loop
100% reproducibly whilst with the patch it works fine as expected.
Signed-off-by: Anton Altaparmakov
Cc: sta...@vger.kernel.org # 3.6 3.8 3.10 3.12 3.14 3.16
---
Linus, can you please apply this? Alternatively, Andrew, can you please
pick this up and send it to Linus?
It would be good it it can be applied for 3.17 as well as to all stable
kernels >= 3.6 as they are all broken!
Thanks a lot in advance!
Best regards,
Anton
--
Anton Altaparmakov (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
diff --git a/fs/buffer.c b/fs/buffer.c
index 8f05111..3588a80 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1022,7 +1022,8 @@ grow_dev_page(struct block_device *bdev, sector_t block,
bh = page_buffers(page);
if (bh->b_size == size) {
end_block = init_page_buffers(page, bdev,
- index << sizebits, size);
+ (sector_t)index << sizebits,
+ size);
goto done;
}
if (!try_to_free_buffers(page))
@@ -1043,7 +1044,8 @@ grow_dev_page(struct block_device *bdev, sector_t block,
*/
spin_lock(>i_mapping->private_lock);
link_dev_buffers(page, bh);
- end_block = init_page_buffers(page, bdev, index << sizebits, size);
+ end_block = init_page_buffers(page, bdev, (sector_t)index << sizebits,
+ size);
spin_unlock(>i_mapping->private_lock);
done:
ret = (block < end_block) ? 1 : -ENXIO;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: x86, microcode: BUG: microcode update that changes x86_capability
He said *outside* of the early update mechanism. On September 21, 2014 5:37:24 PM PDT, Andi Kleen wrote: >Henrique de Moraes Holschuh writes: > > >> And yes, this means we will kill support for microcode updates >> outside of the initramfs/early-initramfs, at least in Debian, >> and likely in Ubuntu. > >You got it totally backwards. initramfs updating should handle this >microcode update just fine, as it happens before the kernel >scans the cpuids. Just don't update it later. > >Nothing else is needed. > >-Andi -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86, microcode: BUG: microcode update that changes x86_capability
Henrique de Moraes Holschuh writes: > And yes, this means we will kill support for microcode updates > outside of the initramfs/early-initramfs, at least in Debian, > and likely in Ubuntu. You got it totally backwards. initramfs updating should handle this microcode update just fine, as it happens before the kernel scans the cpuids. Just don't update it later. Nothing else is needed. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: + mm-slab_common-commonize-slab-merge-logic.patch added to -mm tree
On Fri, Sep 19, 2014 at 03:37:45PM -0700, a...@linux-foundation.org wrote:
>
> The patch titled
> Subject: mm/slab_common: commonize slab merge logic
> has been added to the -mm tree. Its filename is
> mm-slab_common-commonize-slab-merge-logic.patch
>
> This patch should soon appear at
>
> http://ozlabs.org/~akpm/mmots/broken-out/mm-slab_common-commonize-slab-merge-logic.patch
> and later at
>
> http://ozlabs.org/~akpm/mmotm/broken-out/mm-slab_common-commonize-slab-merge-logic.patch
>
> Before you just go and hit "reply", please:
>a) Consider who else should be cc'ed
>b) Prefer to cc a suitable mailing list as well
>c) Ideally: find the original patch on the mailing list and do a
> reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> The -mm tree is included into linux-next and is updated
> there every 3-4 working days
>
> --
> From: Joonsoo Kim
> Subject: mm/slab_common: commonize slab merge logic
>
> Slab merge is good feature to reduce fragmentation. Now, it is only
> applied to SLUB, but, it would be good to apply it to SLAB. This patch is
> preparation step to apply slab merge to SLAB by commonizing slab merge
> logic.
>
> Signed-off-by: Joonsoo Kim
> Cc: Randy Dunlap
> Cc: Christoph Lameter
> Cc: Pekka Enberg
> Cc: David Rientjes
> Signed-off-by: Andrew Morton
> ---
>
> Documentation/kernel-parameters.txt | 14 ++--
> mm/slab.h | 15
> mm/slab_common.c| 91 ++
> mm/slub.c | 91 --
> 4 files changed, 117 insertions(+), 94 deletions(-)
>
> diff -puN
> Documentation/kernel-parameters.txt~mm-slab_common-commonize-slab-merge-logic
> Documentation/kernel-parameters.txt
> ---
> a/Documentation/kernel-parameters.txt~mm-slab_common-commonize-slab-merge-logic
> +++ a/Documentation/kernel-parameters.txt
> @@ -3140,6 +3140,13 @@ bytes respectively. Such letter suffixes
>
> slram= [HW,MTD]
>
> + slab_nomerge[MM]
> + Disable merging of slabs with similar size. May be
> + necessary if there is some reason to distinguish
> + allocs to different slabs. Debug options disable
> + merging on their own.
> + For more information see Documentation/vm/slub.txt.
> +
> slab_max_order= [MM, SLAB]
> Determines the maximum allowed order for slabs.
> A high setting may cause OOMs due to memory
> @@ -3175,11 +3182,8 @@ bytes respectively. Such letter suffixes
> For more information see Documentation/vm/slub.txt.
>
> slub_nomerge[MM, SLUB]
> - Disable merging of slabs with similar size. May be
> - necessary if there is some reason to distinguish
> - allocs to different slabs. Debug options disable
> - merging on their own.
> - For more information see Documentation/vm/slub.txt.
> + Same with slab_nomerge. This is supported for legacy.
> + See slab_nomerge for more information.
>
> smart2= [HW]
> Format: [,[,...,]]
> diff -puN mm/slab.h~mm-slab_common-commonize-slab-merge-logic mm/slab.h
> --- a/mm/slab.h~mm-slab_common-commonize-slab-merge-logic
> +++ a/mm/slab.h
> @@ -88,15 +88,30 @@ extern void create_boot_cache(struct kme
> size_t size, unsigned long flags);
>
> struct mem_cgroup;
> +
> +int slab_unmergeable(struct kmem_cache *s);
> +struct kmem_cache *find_mergeable(size_t size, size_t align,
> + unsigned long flags, const char *name, void (*ctor)(void *));
> #ifdef CONFIG_SLUB
> struct kmem_cache *
> __kmem_cache_alias(const char *name, size_t size, size_t align,
> unsigned long flags, void (*ctor)(void *));
> +
> +unsigned long kmem_cache_flags(unsigned long object_size,
> + unsigned long flags, const char *name,
> + void (*ctor)(void *));
> #else
> static inline struct kmem_cache *
> __kmem_cache_alias(const char *name, size_t size, size_t align,
> unsigned long flags, void (*ctor)(void *))
> { return NULL; }
> +
> +static inline unsigned long kmem_cache_flags(unsigned long object_size,
> + unsigned long flags, const char *name,
> + void (*ctor)(void *))
> +{
> + return flags;
> +}
> #endif
>
>
> diff -puN mm/slab_common.c~mm-slab_common-commonize-slab-merge-logic
> mm/slab_common.c
> --- a/mm/slab_common.c~mm-slab_common-commonize-slab-merge-logic
> +++ a/mm/slab_common.c
> @@ -31,6 +31,34 @@ DEFINE_MUTEX(slab_mutex);
> struct kmem_cache *kmem_cache;
>
> /*
> + * Set of flags that will prevent slab merging
>
Re: [PATCH 1/3] cap1106: Add support for various cap11xx devices
On Sun, Sep 21, 2014 at 2:58 AM, Daniel Mack wrote:
> Hi,
>
> On 09/21/2014 05:01 AM, Matt Ranostay wrote:
>> Several other variants of the cap11xx device exists with a varying
>> number of capacitance detection channels. Add support for creating
>> the channels dynamically.
>
> Thanks for the patches!
>
>>
>> Signed-off-by: Matt Ranostay
>> ---
>> drivers/input/keyboard/cap1106.c | 54
>> +++-
>
> Please also add a patch to rename the file to cap11xx.c, and make sure
> to export the patch with 'git format-patch -M' to detect the rename.
>
>> diff --git a/drivers/input/keyboard/cap1106.c
>> b/drivers/input/keyboard/cap1106.c
>> index d70b65a..b9c43b5 100644
>> --- a/drivers/input/keyboard/cap1106.c
>> +++ b/drivers/input/keyboard/cap1106.c
>> @@ -55,8 +55,6 @@
>> #define CAP1106_REG_MANUFACTURER_ID 0xfe
>> #define CAP1106_REG_REVISION 0xff
>>
>> -#define CAP1106_NUM_CHN 6
>> -#define CAP1106_PRODUCT_ID 0x55
>> #define CAP1106_MANUFACTURER_ID 0x5d
>>
>> struct cap1106_priv {
>> @@ -64,7 +62,8 @@ struct cap1106_priv {
>> struct input_dev *idev;
>>
>> /* config */
>> - unsigned short keycodes[CAP1106_NUM_CHN];
>> + u32 *keycodes;
>
> unsigned short *, please. See below.
>
>> @@ -189,27 +188,23 @@ static int cap1106_i2c_probe(struct i2c_client
>> *i2c_client,
>> struct cap1106_priv *priv;
>> struct device_node *node;
>> int i, error, irq, gain = 0;
>> - unsigned int val, rev;
>> - u32 gain32, keycodes[CAP1106_NUM_CHN];
>> + unsigned int val, prod, rev;
>> + u32 gain32;
>>
>> priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>> if (!priv)
>> return -ENOMEM;
>>
>> + priv->num_channels = (unsigned long) id->driver_data;
>
> priv->num_channels is unsigned int.
>
> Also, a BUG_ON(!priv->num_channels) wouldn't harm.
>
>> + priv->keycodes = devm_kzalloc(dev,
>> + sizeof(u32) * priv->num_channels, GFP_KERNEL);
>
> Use devm_kcalloc() to allocate an array.
>
>> @@ -235,17 +234,12 @@ static int cap1106_i2c_probe(struct i2c_client
>> *i2c_client,
>> dev_err(dev, "Invalid sensor-gain value %d\n", gain32);
>> }
>>
>> - BUILD_BUG_ON(ARRAY_SIZE(keycodes) != ARRAY_SIZE(priv->keycodes));
>> -
>> /* Provide some useful defaults */
>> - for (i = 0; i < ARRAY_SIZE(keycodes); i++)
>> - keycodes[i] = KEY_A + i;
>> + for (i = 0; i < priv->num_channels; i++)
>> + priv->keycodes[i] = KEY_A + i;
>>
>> of_property_read_u32_array(node, "linux,keycodes",
>> -keycodes, ARRAY_SIZE(keycodes));
>> -
>> - for (i = 0; i < ARRAY_SIZE(keycodes); i++)
>> - priv->keycodes[i] = keycodes[i];
>> + priv->keycodes, priv->num_channels);
>
> Hmm, no. Internally, you have to store the keycodes as unsigned short,
> otherwise EVIOC{G|S}KEYCODE from usespace doesn't work.
>
> of_property_read_u16_array() should work here for unsigned short, I
> guess. Otherwise, you'd have to open-code the routine.
>
Problem with u16 is you'll to mark it */bits/ 16* in the device tree
entry.. I doubt that is acceptable
>> @@ -313,12 +307,16 @@ static int cap1106_i2c_probe(struct i2c_client
>> *i2c_client,
>>
>> static const struct of_device_id cap1106_dt_ids[] = {
>> { .compatible = "microchip,cap1106", },
>> + { .compatible = "microchip,cap1126", },
>> + { .compatible = "microchip,cap1188", },
>
> Hmm, how can that work unless you set .data to the number of channels
> here? Did you test that with a DT-enabled board?
>
>
> Thanks,
> Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/3] gpio: sch: Add support for Intel Quark X1000 SoC
> -Original Message- > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com] > Sent: 18 September, 2014 7:23 PM > To: Chang, Rebecca Swee Fun > Cc: Linus Walleij; linux-g...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 2/3] gpio: sch: Add support for Intel Quark X1000 SoC > > On Wed, Sep 17, 2014 at 04:49:04PM +0800, Chang Rebecca Swee Fun wrote: > > Intel Quark X1000 provides a total of 16 GPIOs. The GPIOs are split > > between the legacy I/O bridge and the GPIO controller. > > > > GPIO-SCH is the GPIO pins on legacy bridge for Intel Quark SoC. > > Intel Quark X1000 has 2 GPIOs powered by the core power well and 6 > > from the suspend power well. > > > > This piece of work is derived from Dan O'Donovan's initial work for > > Quark > > X1000 enabling. > > > > Signed-off-by: Chang Rebecca Swee Fun > > > > One question, see below. But in general looks good, so > > Reviewed-by: Mika Westerberg > > > --- > > drivers/gpio/Kconfig| 11 +-- > > drivers/gpio/gpio-sch.c |6 ++ > > 2 files changed, 15 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index > > 690904a..64683a9 100644 > > --- a/drivers/gpio/Kconfig > > +++ b/drivers/gpio/Kconfig > > @@ -356,25 +356,32 @@ config GPIO_VR41XX > > Say yes here to support the NEC VR4100 series General-purpose I/O > > Uint > > > > config GPIO_SCH > > - tristate "Intel SCH/TunnelCreek/Centerton GPIO" > > + tristate "Intel SCH/TunnelCreek/Centerton/Quark X1000 GPIO" > > depends on PCI && X86 > > select MFD_CORE > > select LPC_SCH > > help > > Say yes here to support GPIO interface on Intel Poulsbo SCH, > > - Intel Tunnel Creek processor or Intel Centerton processor. > > + Intel Tunnel Creek processor, Intel Centerton processor or > > + Intel Quark X1000 SoC. > > + > > The Intel SCH contains a total of 14 GPIO pins. Ten GPIOs are > > powered by the core power rail and are turned off during sleep > > modes (S3 and higher). The remaining four GPIOs are powered by > > the Intel SCH suspend power supply. These GPIOs remain > > active during S3. The suspend powered GPIOs can be used to wake the > > system from the Suspend-to-RAM state. > > + > > The Intel Tunnel Creek processor has 5 GPIOs powered by the > > core power rail and 9 from suspend power supply. > > + > > The Intel Centerton processor has a total of 30 GPIO pins. > > Twenty-one are powered by the core power rail and 9 from the > > suspend power supply. > > > > + The Intel Quark X1000 SoC has 2 GPIOs powered by the core > > + power well and 6 from the suspend power well. > > + > > config GPIO_ICH > > tristate "Intel ICH GPIO" > > depends on PCI && X86 > > diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c index > > 2189c22..38d6e74 100644 > > --- a/drivers/gpio/gpio-sch.c > > +++ b/drivers/gpio/gpio-sch.c > > @@ -241,6 +241,12 @@ static int sch_gpio_probe(struct platform_device > *pdev) > > sch->chip.ngpio = 30; > > break; > > > > + case PCI_DEVICE_ID_INTEL_QUARK_X1000_ILB: > > Is this PCI ID provided by some other patch series? Yes, this PCI ID has been submitted to upstream through MFD subsystem tree. Rebecca -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v14 net-next 00/11] eBPF syscall, verifier, testsuite
Hi All, v13 -> v14: - small change to 1st patch to ease 'new userspace with old kernel' problem (done similar to perf_copy_attr()) (suggested by Daniel) - the rest unchanged v12 -> v13: - replaced 'foo __user *' pointers with __aligned_u64 (suggested by David) - added __attribute__((aligned(8)) to 'union bpf_attr' to keep constant alignment between patches - updated manpage and syscall wrappers due to __aligned_u64 - rebased, retested on x64 with 32-bit and 64-bit userspace and on i386, build tested on arm32,sparc64 v11 -> v12: - dropped patch 11 and copied few macros to libbpf.h (suggested by Daniel) - replaced 'enum bpf_prog_type' with u32 to be safe in compat (.. Andy) - implemented and tested compat support (not part of this set) (.. Daniel) - changed 'void *log_buf' to 'char *' (.. Daniel) - combined struct bpf_work_struct and bpf_prog_info (.. Daniel) - added better return value explanation to manpage (.. Andy) - added log_buf/log_size explanation to manpage (.. Andy & Daniel) - added a lot more info about prog_type and map_type to manpage (.. Andy) - rebased, tweaked test_stubs Patches 1-4 establish BPF syscall shell for maps and programs. Patches 5-10 add verifier step by step Patch 11 adds test stubs for 'unspec' program type and verifier testsuite from user space Note that patches 1,3,4,7 add commands and attributes to the syscall while being backwards compatible from each other, which should demonstrate how other commands can be added in the future. After this set the programs can be loaded for testing only. They cannot be attached to any events. Though manpage talks about tracing and sockets, it will be a subject of future patches. Please take a look at manpage: BPF(2) Linux Programmer's ManualBPF(2) NAME bpf - perform a command on eBPF map or program SYNOPSIS #include int bpf(int cmd, union bpf_attr *attr, unsigned int size); DESCRIPTION bpf() syscall is a multiplexor for a range of different operations on eBPF which can be characterized as "universal in-kernel virtual machine". eBPF is similar to original Berkeley Packet Filter (or "classic BPF") used to filter network packets. Both statically analyze the programs before loading them into the kernel to ensure that programs cannot harm the running system. eBPF extends classic BPF in multiple ways including ability to call in- kernel helper functions and access shared data structures like eBPF maps. The programs can be written in a restricted C that is compiled into eBPF bytecode and executed on the eBPF virtual machine or JITed into native instruction set. eBPF Design/Architecture eBPF maps is a generic storage of different types. User process can create multiple maps (with key/value being opaque bytes of data) and access them via file descriptor. In parallel eBPF programs can access maps from inside the kernel. It's up to user process and eBPF program to decide what they store inside maps. eBPF programs are similar to kernel modules. They are loaded by the user process and automatically unloaded when process exits. Each eBPF program is a safe run-to-completion set of instructions. eBPF verifier statically determines that the program terminates and is safe to execute. During verification the program takes a hold of maps that it intends to use, so selected maps cannot be removed until the program is unloaded. The program can be attached to different events. These events can be packets, tracepoint events and other types in the future. A new event triggers execution of the program which may store information about the event in the maps. Beyond storing data the programs may call into in-kernel helper functions which may, for example, dump stack, do trace_printk or other forms of live kernel debugging. The same program can be attached to multiple events. Different programs can access the same map: tracepoint tracepoint tracepointsk_buffsk_buff event A event B event C on eth0on eth1 | | || | | | || | --> tracing <-- tracing socket socket prog_1 prog_2 prog_3 prog_4 | | || |--- -| |---| map_3 map_1 map_2 Syscall Arguments bpf() syscall operation is determined by cmd which can be one of the following: BPF_MAP_CREATE Create a map with given type and attributes and return map FD BPF_MAP_LOOKUP_ELEM Lookup element by
[PATCH v14 net-next 02/11] bpf: enable bpf syscall on x64 and i386
done as separate commit to ease conflict resolution Signed-off-by: Alexei Starovoitov --- arch/x86/syscalls/syscall_32.tbl |1 + arch/x86/syscalls/syscall_64.tbl |1 + include/linux/syscalls.h |3 ++- include/uapi/asm-generic/unistd.h |4 +++- kernel/sys_ni.c |3 +++ 5 files changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl index 028b78168d85..9fe1b5d002f0 100644 --- a/arch/x86/syscalls/syscall_32.tbl +++ b/arch/x86/syscalls/syscall_32.tbl @@ -363,3 +363,4 @@ 354i386seccomp sys_seccomp 355i386getrandom sys_getrandom 356i386memfd_createsys_memfd_create +357i386bpf sys_bpf diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl index 35dd922727b9..281150b539a2 100644 --- a/arch/x86/syscalls/syscall_64.tbl +++ b/arch/x86/syscalls/syscall_64.tbl @@ -327,6 +327,7 @@ 318common getrandom sys_getrandom 319common memfd_createsys_memfd_create 320common kexec_file_load sys_kexec_file_load +321common bpf sys_bpf # # x32-specific system call numbers start at 512 to avoid cache impact diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h index 0f86d85a9ce4..bda9b81357cc 100644 --- a/include/linux/syscalls.h +++ b/include/linux/syscalls.h @@ -65,6 +65,7 @@ struct old_linux_dirent; struct perf_event_attr; struct file_handle; struct sigaltstack; +union bpf_attr; #include #include @@ -875,5 +876,5 @@ asmlinkage long sys_seccomp(unsigned int op, unsigned int flags, const char __user *uargs); asmlinkage long sys_getrandom(char __user *buf, size_t count, unsigned int flags); - +asmlinkage long sys_bpf(int cmd, union bpf_attr *attr, unsigned int size); #endif diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h index 11d11bc5c78f..22749c134117 100644 --- a/include/uapi/asm-generic/unistd.h +++ b/include/uapi/asm-generic/unistd.h @@ -705,9 +705,11 @@ __SYSCALL(__NR_seccomp, sys_seccomp) __SYSCALL(__NR_getrandom, sys_getrandom) #define __NR_memfd_create 279 __SYSCALL(__NR_memfd_create, sys_memfd_create) +#define __NR_bpf 280 +__SYSCALL(__NR_bpf, sys_bpf) #undef __NR_syscalls -#define __NR_syscalls 280 +#define __NR_syscalls 281 /* * All syscalls below here should go away really, diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c index 391d4ddb6f4b..b4b5083f5f5e 100644 --- a/kernel/sys_ni.c +++ b/kernel/sys_ni.c @@ -218,3 +218,6 @@ cond_syscall(sys_kcmp); /* operate on Secure Computing state */ cond_syscall(sys_seccomp); + +/* access BPF programs and maps */ +cond_syscall(sys_bpf); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v14 net-next 04/11] bpf: expand BPF syscall with program load/unload
eBPF programs are similar to kernel modules. They are loaded by the user
process and automatically unloaded when process exits. Each eBPF program is
a safe run-to-completion set of instructions. eBPF verifier statically
determines that the program terminates and is safe to execute.
The following syscall wrapper can be used to load the program:
int bpf_prog_load(enum bpf_prog_type prog_type,
const struct bpf_insn *insns, int insn_cnt,
const char *license)
{
union bpf_attr attr = {
.prog_type = prog_type,
.insns = ptr_to_u64(insns),
.insn_cnt = insn_cnt,
.license = ptr_to_u64(license),
};
return bpf(BPF_PROG_LOAD, , sizeof(attr));
}
where 'insns' is an array of eBPF instructions and 'license' is a string
that must be GPL compatible to call helper functions marked gpl_only
Upon succesful load the syscall returns prog_fd.
Use close(prog_fd) to unload the program.
User space tests and examples follow in the later patches
Signed-off-by: Alexei Starovoitov
---
include/linux/bpf.h | 38 +++
include/linux/filter.h |8 +--
include/uapi/linux/bpf.h | 26
kernel/bpf/core.c| 29
kernel/bpf/syscall.c | 165 ++
5 files changed, 246 insertions(+), 20 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 2887f3f9da59..92979182be81 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -46,4 +46,42 @@ void bpf_register_map_type(struct bpf_map_type_list *tl);
void bpf_map_put(struct bpf_map *map);
struct bpf_map *bpf_map_get(struct fd f);
+/* eBPF function prototype used by verifier to allow BPF_CALLs from eBPF
programs
+ * to in-kernel helper functions and for adjusting imm32 field in BPF_CALL
+ * instructions after verifying
+ */
+struct bpf_func_proto {
+ u64 (*func)(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5);
+ bool gpl_only;
+};
+
+struct bpf_verifier_ops {
+ /* return eBPF function prototype for verification */
+ const struct bpf_func_proto *(*get_func_proto)(enum bpf_func_id
func_id);
+};
+
+struct bpf_prog_type_list {
+ struct list_head list_node;
+ struct bpf_verifier_ops *ops;
+ enum bpf_prog_type type;
+};
+
+void bpf_register_prog_type(struct bpf_prog_type_list *tl);
+
+struct bpf_prog;
+
+struct bpf_prog_aux {
+ atomic_t refcnt;
+ bool is_gpl_compatible;
+ enum bpf_prog_type prog_type;
+ struct bpf_verifier_ops *ops;
+ struct bpf_map **used_maps;
+ u32 used_map_cnt;
+ struct bpf_prog *prog;
+ struct work_struct work;
+};
+
+void bpf_prog_put(struct bpf_prog *prog);
+struct bpf_prog *bpf_prog_get(u32 ufd);
+
#endif /* _LINUX_BPF_H */
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 1a0bc6d134d7..4ffc0958d85e 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -21,6 +21,7 @@
struct sk_buff;
struct sock;
struct seccomp_data;
+struct bpf_prog_aux;
/* ArgX, context and stack frame pointer register positions. Note,
* Arg1, Arg2, Arg3, etc are used as argument mappings of function
@@ -300,17 +301,12 @@ struct bpf_binary_header {
u8 image[];
};
-struct bpf_work_struct {
- struct bpf_prog *prog;
- struct work_struct work;
-};
-
struct bpf_prog {
u16 pages; /* Number of allocated pages */
booljited; /* Is our filter JIT'ed? */
u32 len;/* Number of filter blocks */
struct sock_fprog_kern *orig_prog; /* Original BPF program */
- struct bpf_work_struct *work; /* Deferred free work struct */
+ struct bpf_prog_aux *aux; /* Auxiliary fields */
unsigned int(*bpf_func)(const struct sk_buff *skb,
const struct bpf_insn *filter);
/* Instructions for interpreter */
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 395cabd2ca0a..424f442016e7 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -99,12 +99,23 @@ enum bpf_cmd {
* returns zero and stores next key or negative error
*/
BPF_MAP_GET_NEXT_KEY,
+
+ /* verify and load eBPF program
+* prog_fd = bpf(BPF_PROG_LOAD, union bpf_attr *attr, u32 size)
+* Using attr->prog_type, attr->insns, attr->license
+* returns fd or negative error
+*/
+ BPF_PROG_LOAD,
};
enum bpf_map_type {
BPF_MAP_TYPE_UNSPEC,
};
+enum bpf_prog_type {
+ BPF_PROG_TYPE_UNSPEC,
+};
+
union bpf_attr {
struct { /* anonymous struct used by BPF_MAP_CREATE command */
__u32 map_type; /* one of enum bpf_map_type */
@@ -121,6 +132,21 @@ union bpf_attr {
__aligned_u64 next_key;
};
};
+
+ struct { /* anonymous
[PATCH v14 net-next 05/11] bpf: handle pseudo BPF_CALL insn
in native eBPF programs userspace is using pseudo BPF_CALL instructions
which encode one of 'enum bpf_func_id' inside insn->imm field.
Verifier checks that program using correct function arguments to given func_id.
If all checks passed, kernel needs to fixup BPF_CALL->imm fields by
replacing func_id with in-kernel function pointer.
eBPF interpreter just calls the function.
In-kernel eBPF users continue to use generic BPF_CALL.
Signed-off-by: Alexei Starovoitov
---
kernel/bpf/syscall.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 0afb4eaa1887..b513659d120f 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -357,6 +357,40 @@ void bpf_register_prog_type(struct bpf_prog_type_list *tl)
list_add(>list_node, _prog_types);
}
+/* fixup insn->imm field of bpf_call instructions:
+ * if (insn->imm == BPF_FUNC_map_lookup_elem)
+ * insn->imm = bpf_map_lookup_elem - __bpf_call_base;
+ * else if (insn->imm == BPF_FUNC_map_update_elem)
+ * insn->imm = bpf_map_update_elem - __bpf_call_base;
+ * else ...
+ *
+ * this function is called after eBPF program passed verification
+ */
+static void fixup_bpf_calls(struct bpf_prog *prog)
+{
+ const struct bpf_func_proto *fn;
+ int i;
+
+ for (i = 0; i < prog->len; i++) {
+ struct bpf_insn *insn = >insnsi[i];
+
+ if (insn->code == (BPF_JMP | BPF_CALL)) {
+ /* we reach here when program has bpf_call instructions
+* and it passed bpf_check(), means that
+* ops->get_func_proto must have been supplied, check it
+*/
+ BUG_ON(!prog->aux->ops->get_func_proto);
+
+ fn = prog->aux->ops->get_func_proto(insn->imm);
+ /* all functions that have prototype and verifier
allowed
+* programs to call them, must be real in-kernel
functions
+*/
+ BUG_ON(!fn->func);
+ insn->imm = fn->func - __bpf_call_base;
+ }
+ }
+}
+
/* drop refcnt on maps used by eBPF program and free auxilary data */
static void free_used_maps(struct bpf_prog_aux *aux)
{
@@ -478,6 +512,9 @@ static int bpf_prog_load(union bpf_attr *attr)
if (err < 0)
goto free_used_maps;
+ /* fixup BPF_CALL->imm field */
+ fixup_bpf_calls(prog);
+
/* eBPF program is ready to be JITed */
bpf_prog_select_runtime(prog);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v14 net-next 09/11] bpf: verifier (add branch/goto checks)
check that control flow graph of eBPF program is a directed acyclic graph
check_cfg() does:
- detect loops
- detect unreachable instructions
- check that program terminates with BPF_EXIT insn
- check that all branches are within program boundary
Signed-off-by: Alexei Starovoitov
---
kernel/bpf/verifier.c | 183 +
1 file changed, 183 insertions(+)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 7227543e474b..effab7d1c7e8 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -313,6 +313,185 @@ static struct bpf_map *ld_imm64_to_map_ptr(struct
bpf_insn *insn)
return (struct bpf_map *) (unsigned long) imm64;
}
+/* non-recursive DFS pseudo code
+ * 1 procedure DFS-iterative(G,v):
+ * 2 label v as discovered
+ * 3 let S be a stack
+ * 4 S.push(v)
+ * 5 while S is not empty
+ * 6t <- S.pop()
+ * 7if t is what we're looking for:
+ * 8return t
+ * 9for all edges e in G.adjacentEdges(t) do
+ * 10 if edge e is already labelled
+ * 11 continue with the next edge
+ * 12 w <- G.adjacentVertex(t,e)
+ * 13 if vertex w is not discovered and not explored
+ * 14 label e as tree-edge
+ * 15 label w as discovered
+ * 16 S.push(w)
+ * 17 continue at 5
+ * 18 else if vertex w is discovered
+ * 19 label e as back-edge
+ * 20 else
+ * 21 // vertex w is explored
+ * 22 label e as forward- or cross-edge
+ * 23 label t as explored
+ * 24 S.pop()
+ *
+ * convention:
+ * 0x10 - discovered
+ * 0x11 - discovered and fall-through edge labelled
+ * 0x12 - discovered and fall-through and branch edges labelled
+ * 0x20 - explored
+ */
+
+enum {
+ DISCOVERED = 0x10,
+ EXPLORED = 0x20,
+ FALLTHROUGH = 1,
+ BRANCH = 2,
+};
+
+#define PUSH_INT(I) \
+ do { \
+ if (cur_stack >= insn_cnt) { \
+ ret = -E2BIG; \
+ goto free_st; \
+ } \
+ stack[cur_stack++] = I; \
+ } while (0)
+
+#define PEEK_INT() \
+ ({ \
+ int _ret; \
+ if (cur_stack == 0) \
+ _ret = -1; \
+ else \
+ _ret = stack[cur_stack - 1]; \
+ _ret; \
+})
+
+#define POP_INT() \
+ ({ \
+ int _ret; \
+ if (cur_stack == 0) \
+ _ret = -1; \
+ else \
+ _ret = stack[--cur_stack]; \
+ _ret; \
+})
+
+#define PUSH_INSN(T, W, E) \
+ do { \
+ int w = W; \
+ if (E == FALLTHROUGH && st[T] >= (DISCOVERED | FALLTHROUGH)) \
+ break; \
+ if (E == BRANCH && st[T] >= (DISCOVERED | BRANCH)) \
+ break; \
+ if (w < 0 || w >= insn_cnt) { \
+ verbose("jump out of range from insn %d to %d\n", T,
w); \
+ ret = -EINVAL; \
+ goto free_st; \
+ } \
+ if (st[w] == 0) { \
+ /* tree-edge */ \
+ st[T] = DISCOVERED | E; \
+ st[w] = DISCOVERED; \
+ PUSH_INT(w); \
+ goto peek_stack; \
+ } else if ((st[w] & 0xF0) == DISCOVERED) { \
+ verbose("back-edge from insn %d to %d\n", T, w); \
+ ret = -EINVAL; \
+ goto free_st; \
+ } else if (st[w] == EXPLORED) { \
+ /* forward- or cross-edge */ \
+ st[T] = DISCOVERED | E; \
+ } else { \
+ verbose("insn state internal bug\n"); \
+ ret = -EFAULT; \
+ goto free_st; \
+ } \
+ } while (0)
+
+/* non-recursive depth-first-search to detect loops in BPF program
+ * loop == back-edge in directed graph
+ */
+static int check_cfg(struct verifier_env *env)
+{
+ struct bpf_insn *insns = env->prog->insnsi;
+ int insn_cnt = env->prog->len;
+ int cur_stack = 0;
+ int *stack;
+ int ret = 0;
+ int *st;
+ int i, t;
+
+ st = kzalloc(sizeof(int) * insn_cnt, GFP_KERNEL);
+ if (!st)
+ return -ENOMEM;
+
+ stack = kzalloc(sizeof(int) * insn_cnt, GFP_KERNEL);
+ if (!stack) {
+ kfree(st);
+ return -ENOMEM;
+ }
+
+ st[0] = DISCOVERED; /* mark 1st insn as discovered */
+ PUSH_INT(0);
+
+peek_stack:
+ while ((t = PEEK_INT()) != -1) {
+ if (BPF_CLASS(insns[t].code) == BPF_JMP) {
+
[PATCH v14 net-next 08/11] bpf: handle pseudo BPF_LD_IMM64 insn
eBPF programs passed from userspace are using pseudo BPF_LD_IMM64 instructions
to refer to process-local map_fd. Scan the program for such instructions and
if FDs are valid, convert them to 'struct bpf_map' pointers which will be used
by verifier to check access to maps in bpf_map_lookup/update() calls.
If program passes verifier, convert pseudo BPF_LD_IMM64 into generic by dropping
BPF_PSEUDO_MAP_FD flag.
Note that eBPF interpreter is generic and knows nothing about pseudo insns.
Signed-off-by: Alexei Starovoitov
---
include/linux/filter.h |6 ++
kernel/bpf/verifier.c | 147
2 files changed, 153 insertions(+)
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 4ffc0958d85e..ca95abd2bed1 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -145,6 +145,12 @@ struct bpf_prog_aux;
.off = 0, \
.imm = ((__u64) (IMM)) >> 32 })
+#define BPF_PSEUDO_MAP_FD 1
+
+/* pseudo BPF_LD_IMM64 insn used to refer to process-local map_fd */
+#define BPF_LD_MAP_FD(DST, MAP_FD) \
+ BPF_LD_IMM64_RAW(DST, BPF_PSEUDO_MAP_FD, MAP_FD)
+
/* Short form of mov based on type, BPF_X: dst_reg = src_reg, BPF_K: dst_reg =
imm32 */
#define BPF_MOV64_RAW(TYPE, DST, SRC, IMM) \
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 871edc1f2e1f..7227543e474b 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -125,10 +125,15 @@
* are set to NOT_INIT to indicate that they are no longer readable.
*/
+#define MAX_USED_MAPS 64 /* max number of maps accessed by one eBPF program */
+
/* single container for all structs
* one verifier_env per bpf_check() call
*/
struct verifier_env {
+ struct bpf_prog *prog; /* eBPF program being verified */
+ struct bpf_map *used_maps[MAX_USED_MAPS]; /* array of map's used by
eBPF program */
+ u32 used_map_cnt; /* number of used maps */
};
/* verbose verifier prints what it's seeing
@@ -300,6 +305,115 @@ static void print_bpf_insn(struct bpf_insn *insn)
}
}
+/* return the map pointer stored inside BPF_LD_IMM64 instruction */
+static struct bpf_map *ld_imm64_to_map_ptr(struct bpf_insn *insn)
+{
+ u64 imm64 = ((u64) (u32) insn[0].imm) | ((u64) (u32) insn[1].imm) << 32;
+
+ return (struct bpf_map *) (unsigned long) imm64;
+}
+
+/* look for pseudo eBPF instructions that access map FDs and
+ * replace them with actual map pointers
+ */
+static int replace_map_fd_with_map_ptr(struct verifier_env *env)
+{
+ struct bpf_insn *insn = env->prog->insnsi;
+ int insn_cnt = env->prog->len;
+ int i, j;
+
+ for (i = 0; i < insn_cnt; i++, insn++) {
+ if (insn[0].code == (BPF_LD | BPF_IMM | BPF_DW)) {
+ struct bpf_map *map;
+ struct fd f;
+
+ if (i == insn_cnt - 1 || insn[1].code != 0 ||
+ insn[1].dst_reg != 0 || insn[1].src_reg != 0 ||
+ insn[1].off != 0) {
+ verbose("invalid bpf_ld_imm64 insn\n");
+ return -EINVAL;
+ }
+
+ if (insn->src_reg == 0)
+ /* valid generic load 64-bit imm */
+ goto next_insn;
+
+ if (insn->src_reg != BPF_PSEUDO_MAP_FD) {
+ verbose("unrecognized bpf_ld_imm64 insn\n");
+ return -EINVAL;
+ }
+
+ f = fdget(insn->imm);
+
+ map = bpf_map_get(f);
+ if (IS_ERR(map)) {
+ verbose("fd %d is not pointing to valid
bpf_map\n",
+ insn->imm);
+ fdput(f);
+ return PTR_ERR(map);
+ }
+
+ /* store map pointer inside BPF_LD_IMM64 instruction */
+ insn[0].imm = (u32) (unsigned long) map;
+ insn[1].imm = ((u64) (unsigned long) map) >> 32;
+
+ /* check whether we recorded this map already */
+ for (j = 0; j < env->used_map_cnt; j++)
+ if (env->used_maps[j] == map) {
+ fdput(f);
+ goto next_insn;
+ }
+
+ if (env->used_map_cnt >= MAX_USED_MAPS) {
+ fdput(f);
+ return -E2BIG;
+ }
+
+ /* remember this map */
+ env->used_maps[env->used_map_cnt++] = map;
+
+ /* hold the
[PATCH v14 net-next 10/11] bpf: verifier (add verifier core)
This patch adds verifier core which simulates execution of every insn and
records the state of registers and program stack. Every branch instruction seen
during simulation is pushed into state stack. When verifier reaches BPF_EXIT,
it pops the state from the stack and continues until it reaches BPF_EXIT again.
For program:
1: bpf_mov r1, xxx
2: if (r1 == 0) goto 5
3: bpf_mov r0, 1
4: goto 6
5: bpf_mov r0, 2
6: bpf_exit
The verifier will walk insns: 1, 2, 3, 4, 6
then it will pop the state recorded at insn#2 and will continue: 5, 6
This way it walks all possible paths through the program and checks all
possible values of registers. While doing so, it checks for:
- invalid instructions
- uninitialized register access
- uninitialized stack access
- misaligned stack access
- out of range stack access
- invalid calling convention
- instruction encoding is not using reserved fields
Kernel subsystem configures the verifier with two callbacks:
- bool (*is_valid_access)(int off, int size, enum bpf_access_type type);
that provides information to the verifer which fields of 'ctx'
are accessible (remember 'ctx' is the first argument to eBPF program)
- const struct bpf_func_proto *(*get_func_proto)(enum bpf_func_id func_id);
returns argument constraints of kernel helper functions that eBPF program
may call, so that verifier can checks that R1-R5 types match the prototype
More details in Documentation/networking/filter.txt and in kernel/bpf/verifier.c
Signed-off-by: Alexei Starovoitov
---
include/linux/bpf.h | 47 +++
kernel/bpf/verifier.c | 1003 -
2 files changed, 1049 insertions(+), 1 deletion(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 9dfeb36f8971..3cf91754a957 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -46,6 +46,31 @@ void bpf_register_map_type(struct bpf_map_type_list *tl);
void bpf_map_put(struct bpf_map *map);
struct bpf_map *bpf_map_get(struct fd f);
+/* function argument constraints */
+enum bpf_arg_type {
+ ARG_ANYTHING = 0, /* any argument is ok */
+
+ /* the following constraints used to prototype
+* bpf_map_lookup/update/delete_elem() functions
+*/
+ ARG_CONST_MAP_PTR, /* const argument used as pointer to bpf_map */
+ ARG_PTR_TO_MAP_KEY, /* pointer to stack used as map key */
+ ARG_PTR_TO_MAP_VALUE, /* pointer to stack used as map value */
+
+ /* the following constraints used to prototype bpf_memcmp() and other
+* functions that access data on eBPF program stack
+*/
+ ARG_PTR_TO_STACK, /* any pointer to eBPF program stack */
+ ARG_CONST_STACK_SIZE, /* number of bytes accessed from stack */
+};
+
+/* type of values returned from helper functions */
+enum bpf_return_type {
+ RET_INTEGER,/* function returns integer */
+ RET_VOID, /* function doesn't return anything */
+ RET_PTR_TO_MAP_VALUE_OR_NULL, /* returns a pointer to map elem value
or NULL */
+};
+
/* eBPF function prototype used by verifier to allow BPF_CALLs from eBPF
programs
* to in-kernel helper functions and for adjusting imm32 field in BPF_CALL
* instructions after verifying
@@ -53,11 +78,33 @@ struct bpf_map *bpf_map_get(struct fd f);
struct bpf_func_proto {
u64 (*func)(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5);
bool gpl_only;
+ enum bpf_return_type ret_type;
+ enum bpf_arg_type arg1_type;
+ enum bpf_arg_type arg2_type;
+ enum bpf_arg_type arg3_type;
+ enum bpf_arg_type arg4_type;
+ enum bpf_arg_type arg5_type;
+};
+
+/* bpf_context is intentionally undefined structure. Pointer to bpf_context is
+ * the first argument to eBPF programs.
+ * For socket filters: 'struct bpf_context *' == 'struct sk_buff *'
+ */
+struct bpf_context;
+
+enum bpf_access_type {
+ BPF_READ = 1,
+ BPF_WRITE = 2
};
struct bpf_verifier_ops {
/* return eBPF function prototype for verification */
const struct bpf_func_proto *(*get_func_proto)(enum bpf_func_id
func_id);
+
+ /* return true if 'size' wide access at offset 'off' within bpf_context
+* with 'type' (read or write) is allowed
+*/
+ bool (*is_valid_access)(int off, int size, enum bpf_access_type type);
};
struct bpf_prog_type_list {
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index effab7d1c7e8..663d02c6e23c 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -125,6 +125,72 @@
* are set to NOT_INIT to indicate that they are no longer readable.
*/
+#define _(OP) ({ int ret = (OP); if (ret < 0) return ret; })
+
+/* types of values stored in eBPF registers */
+enum bpf_reg_type {
+ NOT_INIT = 0,/* nothing was written into register */
+ UNKNOWN_VALUE, /* reg doesn't contain a valid pointer */
+ PTR_TO_CTX, /* reg points to bpf_context */
[PATCH v14 net-next 11/11] bpf: mini eBPF library, test stubs and verifier testsuite
1.
the library includes a trivial set of BPF syscall wrappers:
int bpf_create_map(int key_size, int value_size, int max_entries);
int bpf_update_elem(int fd, void *key, void *value);
int bpf_lookup_elem(int fd, void *key, void *value);
int bpf_delete_elem(int fd, void *key);
int bpf_get_next_key(int fd, void *key, void *next_key);
int bpf_prog_load(enum bpf_prog_type prog_type,
const struct sock_filter_int *insns, int insn_len,
const char *license);
bpf_prog_load() stores verifier log into global bpf_log_buf[] array
and BPF_*() macros to build instructions
2.
test stubs configure eBPF infra with 'unspec' map and program types.
These are fake types used by user space testsuite only.
3.
verifier tests valid and invalid programs and expects predefined
error log messages from kernel.
40 tests so far.
$ sudo ./test_verifier
#0 add+sub+mul OK
#1 unreachable OK
#2 unreachable2 OK
#3 out of range jump OK
#4 out of range jump2 OK
#5 test1 ld_imm64 OK
...
Signed-off-by: Alexei Starovoitov
---
kernel/bpf/Makefile |4 +
kernel/bpf/test_stub.c | 116 +
lib/Kconfig.debug |3 +-
samples/bpf/Makefile| 12 +
samples/bpf/libbpf.c| 94
samples/bpf/libbpf.h| 172 ++
samples/bpf/test_verifier.c | 548 +++
7 files changed, 948 insertions(+), 1 deletion(-)
create mode 100644 kernel/bpf/test_stub.c
create mode 100644 samples/bpf/Makefile
create mode 100644 samples/bpf/libbpf.c
create mode 100644 samples/bpf/libbpf.h
create mode 100644 samples/bpf/test_verifier.c
diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile
index 3c726b0995b7..45427239f375 100644
--- a/kernel/bpf/Makefile
+++ b/kernel/bpf/Makefile
@@ -1 +1,5 @@
obj-y := core.o syscall.o verifier.o
+
+ifdef CONFIG_TEST_BPF
+obj-y += test_stub.o
+endif
diff --git a/kernel/bpf/test_stub.c b/kernel/bpf/test_stub.c
new file mode 100644
index ..fcaddff4003e
--- /dev/null
+++ b/kernel/bpf/test_stub.c
@@ -0,0 +1,116 @@
+/* Copyright (c) 2011-2014 PLUMgrid, http://plumgrid.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+
+/* test stubs for BPF_MAP_TYPE_UNSPEC and for BPF_PROG_TYPE_UNSPEC
+ * to be used by user space verifier testsuite
+ */
+struct bpf_context {
+ u64 arg1;
+ u64 arg2;
+};
+
+static u64 test_func(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
+{
+ return 0;
+}
+
+static struct bpf_func_proto test_funcs[] = {
+ [BPF_FUNC_unspec] = {
+ .func = test_func,
+ .gpl_only = true,
+ .ret_type = RET_PTR_TO_MAP_VALUE_OR_NULL,
+ .arg1_type = ARG_CONST_MAP_PTR,
+ .arg2_type = ARG_PTR_TO_MAP_KEY,
+ },
+};
+
+static const struct bpf_func_proto *test_func_proto(enum bpf_func_id func_id)
+{
+ if (func_id < 0 || func_id >= ARRAY_SIZE(test_funcs))
+ return NULL;
+ return _funcs[func_id];
+}
+
+static const struct bpf_context_access {
+ int size;
+ enum bpf_access_type type;
+} test_ctx_access[] = {
+ [offsetof(struct bpf_context, arg1)] = {
+ FIELD_SIZEOF(struct bpf_context, arg1),
+ BPF_READ
+ },
+ [offsetof(struct bpf_context, arg2)] = {
+ FIELD_SIZEOF(struct bpf_context, arg2),
+ BPF_READ
+ },
+};
+
+static bool test_is_valid_access(int off, int size, enum bpf_access_type type)
+{
+ const struct bpf_context_access *access;
+
+ if (off < 0 || off >= ARRAY_SIZE(test_ctx_access))
+ return false;
+
+ access = _ctx_access[off];
+ if (access->size == size && (access->type & type))
+ return true;
+
+ return false;
+}
+
+static struct bpf_verifier_ops test_ops = {
+ .get_func_proto = test_func_proto,
+ .is_valid_access = test_is_valid_access,
+};
+
+static struct bpf_prog_type_list tl_prog = {
+ .ops = _ops,
+ .type = BPF_PROG_TYPE_UNSPEC,
+};
+
+static struct bpf_map *test_map_alloc(union bpf_attr *attr)
+{
+ struct bpf_map *map;
+
+ map = kzalloc(sizeof(*map), GFP_USER);
+ if (!map)
+ return ERR_PTR(-ENOMEM);
+
+ map->key_size = attr->key_size;
+ map->value_size = attr->value_size;
+ map->max_entries = attr->max_entries;
+ return map;
+}
+
+static void test_map_free(struct bpf_map *map)
+{
+ kfree(map);
+}
+
+static struct bpf_map_ops test_map_ops = {
+ .map_alloc = test_map_alloc,
+ .map_free = test_map_free,
+};
+
+static struct bpf_map_type_list tl_map = {
+ .ops = _map_ops,
+ .type = BPF_MAP_TYPE_UNSPEC,
+};
+
+static int __init register_test_ops(void)
+{
+ bpf_register_map_type(_map);
+
[PATCH v14 net-next 07/11] bpf: verifier (add ability to receive verification log)
add optional attributes for BPF_PROG_LOAD syscall:
union bpf_attr {
struct {
...
__u32 log_level; /* verbosity level of eBPF verifier */
__u32 log_size; /* size of user buffer */
__aligned_u64 log_buf; /* user supplied 'char *buffer' */
};
};
when log_level > 0 the verifier will return its verification log in the user
supplied buffer 'log_buf' which can be used by program author to analyze why
verifier rejected given program.
'Understanding eBPF verifier messages' section of
Documentation/networking/filter.txt
provides several examples of these messages, like the program:
BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
BPF_LD_MAP_FD(BPF_REG_1, 0),
BPF_CALL_FUNC(BPF_FUNC_map_lookup_elem),
BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 1),
BPF_ST_MEM(BPF_DW, BPF_REG_0, 4, 0),
BPF_EXIT_INSN(),
will be rejected with the following multi-line message in log_buf:
0: (7a) *(u64 *)(r10 -8) = 0
1: (bf) r2 = r10
2: (07) r2 += -8
3: (b7) r1 = 0
4: (85) call 1
5: (15) if r0 == 0x0 goto pc+1
R0=map_ptr R10=fp
6: (7a) *(u64 *)(r0 +4) = 0
misaligned access off 4 size 8
The format of the output can change at any time as verifier evolves.
Signed-off-by: Alexei Starovoitov
---
include/uapi/linux/bpf.h |3 +
kernel/bpf/syscall.c |2 +-
kernel/bpf/verifier.c| 235 ++
3 files changed, 239 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 424f442016e7..31b0ac208a52 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -138,6 +138,9 @@ union bpf_attr {
__u32 insn_cnt;
__aligned_u64 insns;
__aligned_u64 license;
+ __u32 log_level; /* verbosity level of verifier
*/
+ __u32 log_size; /* size of user buffer */
+ __aligned_u64 log_buf;/* user supplied buffer */
};
} __attribute__((aligned(8)));
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 74b3628c5fdb..ba61c8c16032 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -458,7 +458,7 @@ struct bpf_prog *bpf_prog_get(u32 ufd)
}
/* last field in 'union bpf_attr' used by this command */
-#defineBPF_PROG_LOAD_LAST_FIELD license
+#defineBPF_PROG_LOAD_LAST_FIELD log_buf
static int bpf_prog_load(union bpf_attr *attr)
{
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index d6f9c3d6b4d7..871edc1f2e1f 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -125,9 +125,244 @@
* are set to NOT_INIT to indicate that they are no longer readable.
*/
+/* single container for all structs
+ * one verifier_env per bpf_check() call
+ */
+struct verifier_env {
+};
+
+/* verbose verifier prints what it's seeing
+ * bpf_check() is called under lock, so no race to access these global vars
+ */
+static u32 log_level, log_size, log_len;
+static char *log_buf;
+
+static DEFINE_MUTEX(bpf_verifier_lock);
+
+/* log_level controls verbosity level of eBPF verifier.
+ * verbose() is used to dump the verification trace to the log, so the user
+ * can figure out what's wrong with the program
+ */
+static void verbose(const char *fmt, ...)
+{
+ va_list args;
+
+ if (log_level == 0 || log_len >= log_size - 1)
+ return;
+
+ va_start(args, fmt);
+ log_len += vscnprintf(log_buf + log_len, log_size - log_len, fmt, args);
+ va_end(args);
+}
+
+static const char *const bpf_class_string[] = {
+ [BPF_LD]= "ld",
+ [BPF_LDX] = "ldx",
+ [BPF_ST]= "st",
+ [BPF_STX] = "stx",
+ [BPF_ALU] = "alu",
+ [BPF_JMP] = "jmp",
+ [BPF_RET] = "BUG",
+ [BPF_ALU64] = "alu64",
+};
+
+static const char *const bpf_alu_string[] = {
+ [BPF_ADD >> 4] = "+=",
+ [BPF_SUB >> 4] = "-=",
+ [BPF_MUL >> 4] = "*=",
+ [BPF_DIV >> 4] = "/=",
+ [BPF_OR >> 4] = "|=",
+ [BPF_AND >> 4] = "&=",
+ [BPF_LSH >> 4] = "<<=",
+ [BPF_RSH >> 4] = ">>=",
+ [BPF_NEG >> 4] = "neg",
+ [BPF_MOD >> 4] = "%=",
+ [BPF_XOR >> 4] = "^=",
+ [BPF_MOV >> 4] = "=",
+ [BPF_ARSH >> 4] = "s>>=",
+ [BPF_END >> 4] = "endian",
+};
+
+static const char *const bpf_ldst_string[] = {
+ [BPF_W >> 3] = "u32",
+ [BPF_H >> 3] = "u16",
+ [BPF_B >> 3] = "u8",
+ [BPF_DW >> 3] = "u64",
+};
+
+static const char *const bpf_jmp_string[] = {
+ [BPF_JA >> 4] = "jmp",
+ [BPF_JEQ >> 4] = "==",
+ [BPF_JGT >> 4] = ">",
+ [BPF_JGE >> 4] = ">=",
+ [BPF_JSET >> 4] = "&",
+ [BPF_JNE >> 4] = "!=",
+ [BPF_JSGT >> 4] = "s>",
+ [BPF_JSGE >> 4] = "s>=",
+ [BPF_CALL >> 4] = "call",
+ [BPF_EXIT >> 4] = "exit",
+};
+
[PATCH v14 net-next 06/11] bpf: verifier (add docs)
this patch adds all of eBPF verfier documentation and empty bpf_check() The end goal for the verifier is to statically check safety of the program. Verifier will catch: - loops - out of range jumps - unreachable instructions - invalid instructions - uninitialized register access - uninitialized stack access - misaligned stack access - out of range stack access - invalid calling convention More details in Documentation/networking/filter.txt Signed-off-by: Alexei Starovoitov --- Documentation/networking/filter.txt | 224 +++ include/linux/bpf.h |2 + kernel/bpf/Makefile |2 +- kernel/bpf/syscall.c|2 +- kernel/bpf/verifier.c | 133 + 5 files changed, 361 insertions(+), 2 deletions(-) create mode 100644 kernel/bpf/verifier.c diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt index 1900d29518f1..f1c90967f748 100644 --- a/Documentation/networking/filter.txt +++ b/Documentation/networking/filter.txt @@ -1001,6 +1001,99 @@ instruction that loads 64-bit immediate value into a dst_reg. Classic BPF has similar instruction: BPF_LD | BPF_W | BPF_IMM which loads 32-bit immediate value into a register. +eBPF verifier +- +The safety of the eBPF program is determined in two steps. + +First step does DAG check to disallow loops and other CFG validation. +In particular it will detect programs that have unreachable instructions. +(though classic BPF checker allows them) + +Second step starts from the first insn and descends all possible paths. +It simulates execution of every insn and observes the state change of +registers and stack. + +At the start of the program the register R1 contains a pointer to context +and has type PTR_TO_CTX. +If verifier sees an insn that does R2=R1, then R2 has now type +PTR_TO_CTX as well and can be used on the right hand side of expression. +If R1=PTR_TO_CTX and insn is R2=R1+R1, then R2=UNKNOWN_VALUE, +since addition of two valid pointers makes invalid pointer. +(In 'secure' mode verifier will reject any type of pointer arithmetic to make +sure that kernel addresses don't leak to unprivileged users) + +If register was never written to, it's not readable: + bpf_mov R0 = R2 + bpf_exit +will be rejected, since R2 is unreadable at the start of the program. + +After kernel function call, R1-R5 are reset to unreadable and +R0 has a return type of the function. + +Since R6-R9 are callee saved, their state is preserved across the call. + bpf_mov R6 = 1 + bpf_call foo + bpf_mov R0 = R6 + bpf_exit +is a correct program. If there was R1 instead of R6, it would have +been rejected. + +load/store instructions are allowed only with registers of valid types, which +are PTR_TO_CTX, PTR_TO_MAP, FRAME_PTR. They are bounds and alignment checked. +For example: + bpf_mov R1 = 1 + bpf_mov R2 = 2 + bpf_xadd *(u32 *)(R1 + 3) += R2 + bpf_exit +will be rejected, since R1 doesn't have a valid pointer type at the time of +execution of instruction bpf_xadd. + +At the start R1 type is PTR_TO_CTX (a pointer to generic 'struct bpf_context') +A callback is used to customize verifier to restrict eBPF program access to only +certain fields within ctx structure with specified size and alignment. + +For example, the following insn: + bpf_ld R0 = *(u32 *)(R6 + 8) +intends to load a word from address R6 + 8 and store it into R0 +If R6=PTR_TO_CTX, via is_valid_access() callback the verifier will know +that offset 8 of size 4 bytes can be accessed for reading, otherwise +the verifier will reject the program. +If R6=FRAME_PTR, then access should be aligned and be within +stack bounds, which are [-MAX_BPF_STACK, 0). In this example offset is 8, +so it will fail verification, since it's out of bounds. + +The verifier will allow eBPF program to read data from stack only after +it wrote into it. +Classic BPF verifier does similar check with M[0-15] memory slots. +For example: + bpf_ld R0 = *(u32 *)(R10 - 4) + bpf_exit +is invalid program. +Though R10 is correct read-only register and has type FRAME_PTR +and R10 - 4 is within stack bounds, there were no stores into that location. + +Pointer register spill/fill is tracked as well, since four (R6-R9) +callee saved registers may not be enough for some programs. + +Allowed function calls are customized with bpf_verifier_ops->get_func_proto() +The eBPF verifier will check that registers match argument constraints. +After the call register R0 will be set to return type of the function. + +Function calls is a main mechanism to extend functionality of eBPF programs. +Socket filters may let programs to call one set of functions, whereas tracing +filters may allow completely different set. + +If a function made accessible to eBPF program, it needs to be thought through +from safety point of view. The verifier will guarantee that the function is +called with valid arguments. + +seccomp vs socket filters
[PATCH v14 net-next 03/11] bpf: add lookup/update/delete/iterate methods to BPF maps
'maps' is a generic storage of different types for sharing data between kernel
and userspace.
The maps are accessed from user space via BPF syscall, which has commands:
- create a map with given type and attributes
fd = bpf(BPF_MAP_CREATE, union bpf_attr *attr, u32 size)
returns fd or negative error
- lookup key in a given map referenced by fd
err = bpf(BPF_MAP_LOOKUP_ELEM, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key, attr->value
returns zero and stores found elem into value or negative error
- create or update key/value pair in a given map
err = bpf(BPF_MAP_UPDATE_ELEM, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key, attr->value
returns zero or negative error
- find and delete element by key in a given map
err = bpf(BPF_MAP_DELETE_ELEM, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key
- iterate map elements (based on input key return next_key)
err = bpf(BPF_MAP_GET_NEXT_KEY, union bpf_attr *attr, u32 size)
using attr->map_fd, attr->key, attr->next_key
- close(fd) deletes the map
Signed-off-by: Alexei Starovoitov
---
include/linux/bpf.h |8 ++
include/uapi/linux/bpf.h | 38
kernel/bpf/syscall.c | 235 ++
3 files changed, 281 insertions(+)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 48014a71f0fe..2887f3f9da59 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -9,6 +9,7 @@
#include
#include
+#include
struct bpf_map;
@@ -17,6 +18,12 @@ struct bpf_map_ops {
/* funcs callable from userspace (via syscall) */
struct bpf_map *(*map_alloc)(union bpf_attr *attr);
void (*map_free)(struct bpf_map *);
+ int (*map_get_next_key)(struct bpf_map *map, void *key, void *next_key);
+
+ /* funcs callable from userspace and from eBPF programs */
+ void *(*map_lookup_elem)(struct bpf_map *map, void *key);
+ int (*map_update_elem)(struct bpf_map *map, void *key, void *value);
+ int (*map_delete_elem)(struct bpf_map *map, void *key);
};
struct bpf_map {
@@ -37,5 +44,6 @@ struct bpf_map_type_list {
void bpf_register_map_type(struct bpf_map_type_list *tl);
void bpf_map_put(struct bpf_map *map);
+struct bpf_map *bpf_map_get(struct fd f);
#endif /* _LINUX_BPF_H */
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index f58a10f9670c..395cabd2ca0a 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -70,6 +70,35 @@ enum bpf_cmd {
* map is deleted when fd is closed
*/
BPF_MAP_CREATE,
+
+ /* lookup key in a given map
+* err = bpf(BPF_MAP_LOOKUP_ELEM, union bpf_attr *attr, u32 size)
+* Using attr->map_fd, attr->key, attr->value
+* returns zero and stores found elem into value
+* or negative error
+*/
+ BPF_MAP_LOOKUP_ELEM,
+
+ /* create or update key/value pair in a given map
+* err = bpf(BPF_MAP_UPDATE_ELEM, union bpf_attr *attr, u32 size)
+* Using attr->map_fd, attr->key, attr->value
+* returns zero or negative error
+*/
+ BPF_MAP_UPDATE_ELEM,
+
+ /* find and delete elem by key in a given map
+* err = bpf(BPF_MAP_DELETE_ELEM, union bpf_attr *attr, u32 size)
+* Using attr->map_fd, attr->key
+* returns zero or negative error
+*/
+ BPF_MAP_DELETE_ELEM,
+
+ /* lookup key in a given map and return next key
+* err = bpf(BPF_MAP_GET_NEXT_KEY, union bpf_attr *attr, u32 size)
+* Using attr->map_fd, attr->key, attr->next_key
+* returns zero and stores next key or negative error
+*/
+ BPF_MAP_GET_NEXT_KEY,
};
enum bpf_map_type {
@@ -83,6 +112,15 @@ union bpf_attr {
__u32 value_size; /* size of value in bytes */
__u32 max_entries;/* max number of entries in a map */
};
+
+ struct { /* anonymous struct used by BPF_MAP_*_ELEM commands */
+ __u32 map_fd;
+ __aligned_u64 key;
+ union {
+ __aligned_u64 value;
+ __aligned_u64 next_key;
+ };
+ };
} __attribute__((aligned(8)));
#endif /* _UAPI__LINUX_BPF_H__ */
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 428a0e23adc0..f94349ecaf61 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
static LIST_HEAD(bpf_map_types);
@@ -111,6 +112,228 @@ free_map:
return err;
}
+/* if error is returned, fd is released.
+ * On success caller should complete fd access with matching fdput()
+ */
+struct bpf_map *bpf_map_get(struct fd f)
+{
+ struct bpf_map *map;
+
+ if (!f.file)
+ return ERR_PTR(-EBADF);
+
+ if (f.file->f_op != _map_fops) {
+ fdput(f);
+ return ERR_PTR(-EINVAL);
+ }
+
+
[PATCH v14 net-next 01/11] bpf: introduce BPF syscall and maps
BPF syscall is a multiplexor for a range of different operations on eBPF.
This patch introduces syscall with single command to create a map.
Next patch adds commands to access maps.
'maps' is a generic storage of different types for sharing data between kernel
and userspace.
Userspace example:
/* this syscall wrapper creates a map with given type and attributes
* and returns map_fd on success.
* use close(map_fd) to delete the map
*/
int bpf_create_map(enum bpf_map_type map_type, int key_size,
int value_size, int max_entries)
{
union bpf_attr attr = {
.map_type = map_type,
.key_size = key_size,
.value_size = value_size,
.max_entries = max_entries
};
return bpf(BPF_MAP_CREATE, , sizeof(attr));
}
'union bpf_attr' is backwards compatible with future extensions.
More details in Documentation/networking/filter.txt and in manpage
Signed-off-by: Alexei Starovoitov
---
Documentation/networking/filter.txt | 39
include/linux/bpf.h | 41 +
include/uapi/linux/bpf.h| 23 +
kernel/bpf/Makefile |2 +-
kernel/bpf/syscall.c| 169 +++
5 files changed, 273 insertions(+), 1 deletion(-)
create mode 100644 include/linux/bpf.h
create mode 100644 kernel/bpf/syscall.c
diff --git a/Documentation/networking/filter.txt
b/Documentation/networking/filter.txt
index 81916ab5d96f..1900d29518f1 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -1001,6 +1001,45 @@ instruction that loads 64-bit immediate value into a
dst_reg.
Classic BPF has similar instruction: BPF_LD | BPF_W | BPF_IMM which loads
32-bit immediate value into a register.
+eBPF maps
+-
+'maps' is a generic storage of different types for sharing data between kernel
+and userspace.
+
+The maps are accessed from user space via BPF syscall, which has commands:
+- create a map with given type and attributes
+ map_fd = bpf(BPF_MAP_CREATE, union bpf_attr *attr, u32 size)
+ using attr->map_type, attr->key_size, attr->value_size, attr->max_entries
+ returns process-local file descriptor or negative error
+
+- lookup key in a given map
+ err = bpf(BPF_MAP_LOOKUP_ELEM, union bpf_attr *attr, u32 size)
+ using attr->map_fd, attr->key, attr->value
+ returns zero and stores found elem into value or negative error
+
+- create or update key/value pair in a given map
+ err = bpf(BPF_MAP_UPDATE_ELEM, union bpf_attr *attr, u32 size)
+ using attr->map_fd, attr->key, attr->value
+ returns zero or negative error
+
+- find and delete element by key in a given map
+ err = bpf(BPF_MAP_DELETE_ELEM, union bpf_attr *attr, u32 size)
+ using attr->map_fd, attr->key
+
+- to delete map: close(fd)
+ Exiting process will delete maps automatically
+
+userspace programs use this syscall to create/access maps that eBPF programs
+are concurrently updating.
+
+maps can have different types: hash, array, bloom filter, radix-tree, etc.
+
+The map is defined by:
+ . type
+ . max number of elements
+ . key size in bytes
+ . value size in bytes
+
Testing
---
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
new file mode 100644
index ..48014a71f0fe
--- /dev/null
+++ b/include/linux/bpf.h
@@ -0,0 +1,41 @@
+/* Copyright (c) 2011-2014 PLUMgrid, http://plumgrid.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#ifndef _LINUX_BPF_H
+#define _LINUX_BPF_H 1
+
+#include
+#include
+
+struct bpf_map;
+
+/* map is generic key/value storage optionally accesible by eBPF programs */
+struct bpf_map_ops {
+ /* funcs callable from userspace (via syscall) */
+ struct bpf_map *(*map_alloc)(union bpf_attr *attr);
+ void (*map_free)(struct bpf_map *);
+};
+
+struct bpf_map {
+ atomic_t refcnt;
+ enum bpf_map_type map_type;
+ u32 key_size;
+ u32 value_size;
+ u32 max_entries;
+ struct bpf_map_ops *ops;
+ struct work_struct work;
+};
+
+struct bpf_map_type_list {
+ struct list_head list_node;
+ struct bpf_map_ops *ops;
+ enum bpf_map_type type;
+};
+
+void bpf_register_map_type(struct bpf_map_type_list *tl);
+void bpf_map_put(struct bpf_map *map);
+
+#endif /* _LINUX_BPF_H */
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 479ed0b6be16..f58a10f9670c 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -62,4 +62,27 @@ struct bpf_insn {
__s32 imm;/* signed immediate constant */
};
+/* BPF syscall commands */
+enum bpf_cmd {
+ /* create a map with given type and attributes
+* fd = bpf(BPF_MAP_CREATE, union bpf_attr *, u32 size)
+* returns fd or negative error
+* map is deleted when fd is closed
+*/
+
[PATCH v1 2/5] mm: add full variable in swap_info_struct
Now, swap leans on !p->highest_bit to indicate a swap is full.
It works well for normal swap because every slot on swap device
is used up when the swap is full but in case of zram, swap sees
still many empty slot although backed device(ie, zram) is full
since zram's limit is over so that it could make trouble when
swap use highest_bit to select new slot via free_cluster.
This patch introduces full varaiable in swap_info_struct
to solve the problem.
Suggested-by: Dan Streetman
Signed-off-by: Minchan Kim
---
include/linux/swap.h | 1 +
mm/swapfile.c| 33 +++--
2 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index ea4f926e6b9b..a3c11c051495 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -224,6 +224,7 @@ struct swap_info_struct {
struct swap_cluster_info free_cluster_tail; /* free cluster list tail */
unsigned int lowest_bit;/* index of first free in swap_map */
unsigned int highest_bit; /* index of last free in swap_map */
+ boolfull; /* whether swap is full or not */
unsigned int pages; /* total of usable pages of swap */
unsigned int inuse_pages; /* number of those currently in use */
unsigned int cluster_next; /* likely index for next allocation */
diff --git a/mm/swapfile.c b/mm/swapfile.c
index c07f7f4912e9..209112cf8b83 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -558,7 +558,7 @@ checks:
}
if (!(si->flags & SWP_WRITEOK))
goto no_page;
- if (!si->highest_bit)
+ if (si->full)
goto no_page;
if (offset > si->highest_bit)
scan_base = offset = si->lowest_bit;
@@ -589,6 +589,7 @@ checks:
spin_lock(_avail_lock);
plist_del(>avail_list, _avail_head);
spin_unlock(_avail_lock);
+ si->full = true;
}
si->swap_map[offset] = usage;
inc_cluster_info_page(si, si->cluster_info, offset);
@@ -653,14 +654,14 @@ start_over:
plist_requeue(>avail_list, _avail_head);
spin_unlock(_avail_lock);
spin_lock(>lock);
- if (!si->highest_bit || !(si->flags & SWP_WRITEOK)) {
+ if (si->full || !(si->flags & SWP_WRITEOK)) {
spin_lock(_avail_lock);
if (plist_node_empty(>avail_list)) {
spin_unlock(>lock);
goto nextsi;
}
- WARN(!si->highest_bit,
-"swap_info %d in list but !highest_bit\n",
+ WARN(si->full,
+"swap_info %d in list but swap is full\n",
si->type);
WARN(!(si->flags & SWP_WRITEOK),
"swap_info %d in list but !SWP_WRITEOK\n",
@@ -796,21 +797,25 @@ static unsigned char swap_entry_free(struct
swap_info_struct *p,
/* free if no reference */
if (!usage) {
+ bool was_full;
+
dec_cluster_info_page(p, p->cluster_info, offset);
if (offset < p->lowest_bit)
p->lowest_bit = offset;
- if (offset > p->highest_bit) {
- bool was_full = !p->highest_bit;
+ if (offset > p->highest_bit)
p->highest_bit = offset;
- if (was_full && (p->flags & SWP_WRITEOK)) {
- spin_lock(_avail_lock);
- WARN_ON(!plist_node_empty(>avail_list));
- if (plist_node_empty(>avail_list))
- plist_add(>avail_list,
- _avail_head);
- spin_unlock(_avail_lock);
- }
+ was_full = p->full;
+
+ if (was_full && (p->flags & SWP_WRITEOK)) {
+ spin_lock(_avail_lock);
+ WARN_ON(!plist_node_empty(>avail_list));
+ if (plist_node_empty(>avail_list))
+ plist_add(>avail_list,
+ _avail_head);
+ spin_unlock(_avail_lock);
+ p->full = false;
}
+
atomic_long_inc(_swap_pages);
p->inuse_pages--;
frontswap_invalidate_page(p->type, offset);
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 5/5] zram: add fullness knob to control swap full
Some zram usecase could want lower fullness than default 80 to
avoid unnecessary swapout-and-fail-recover overhead.
A typical example is that mutliple swap with high piroirty
zram-swap and low priority HDD-swap so it could still enough
free swap space although one of swap devices is full(ie, zram).
It would be better to fail over to HDD-swap rather than failing
swap write to zram in this case.
This patch exports fullness to user so user can control it
via the knob.
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 10
drivers/block/zram/zram_drv.c | 38 +-
drivers/block/zram/zram_drv.h | 1 +
3 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index b13dc993291f..817738d14061 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -138,3 +138,13 @@ Description:
amount of memory ZRAM can use to store the compressed data. The
limit could be changed in run time and "0" means disable the
limit. No limit is the initial state. Unit: bytes
+
+What: /sys/block/zram/fullness
+Date: August 2014
+Contact: Minchan Kim
+Description:
+ The fullness file is read/write and specifies how easily
+ zram become full state so if you set it to lower value,
+ zram can reach full state easily compared to higher value.
+ Curretnly, initial value is 80% but it could be changed.
+ Unit: Percentage
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 649cad9d0b1c..ec3656f6891d 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -136,6 +136,37 @@ static ssize_t max_comp_streams_show(struct device *dev,
return scnprintf(buf, PAGE_SIZE, "%d\n", val);
}
+static ssize_t fullness_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int val;
+ struct zram *zram = dev_to_zram(dev);
+
+ down_read(>init_lock);
+ val = zram->fullness;
+ up_read(>init_lock);
+
+ return scnprintf(buf, PAGE_SIZE, "%d\n", val);
+}
+
+static ssize_t fullness_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t len)
+{
+ int err;
+ unsigned long val;
+ struct zram *zram = dev_to_zram(dev);
+
+ err = kstrtoul(buf, 10, );
+ if (err || val > 100)
+ return -EINVAL;
+
+ down_write(>init_lock);
+ zram->fullness = val;
+ up_write(>init_lock);
+
+ return len;
+}
+
static ssize_t mem_limit_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -733,6 +764,7 @@ static void zram_reset_device(struct zram *zram, bool
reset_capacity)
zram->limit_pages = 0;
atomic_set(>alloc_fail, 0);
+ zram->fullness = ZRAM_FULLNESS_PERCENT;
if (!init_done(zram)) {
up_write(>init_lock);
@@ -984,7 +1016,7 @@ static int zram_full(struct block_device *bdev, void *arg)
compr_pages = atomic64_read(>stats.compr_data_size)
>> PAGE_SHIFT;
if ((100 * compr_pages / total_pages)
- >= ZRAM_FULLNESS_PERCENT)
+ >= zram->fullness)
return 1;
}
@@ -1020,6 +1052,8 @@ static DEVICE_ATTR(orig_data_size, S_IRUGO,
orig_data_size_show, NULL);
static DEVICE_ATTR(mem_used_total, S_IRUGO, mem_used_total_show, NULL);
static DEVICE_ATTR(mem_limit, S_IRUGO | S_IWUSR, mem_limit_show,
mem_limit_store);
+static DEVICE_ATTR(fullness, S_IRUGO | S_IWUSR, fullness_show,
+ fullness_store);
static DEVICE_ATTR(mem_used_max, S_IRUGO | S_IWUSR, mem_used_max_show,
mem_used_max_store);
static DEVICE_ATTR(max_comp_streams, S_IRUGO | S_IWUSR,
@@ -1051,6 +1085,7 @@ static struct attribute *zram_disk_attrs[] = {
_attr_compr_data_size.attr,
_attr_mem_used_total.attr,
_attr_mem_limit.attr,
+ _attr_fullness.attr,
_attr_mem_used_max.attr,
_attr_max_comp_streams.attr,
_attr_comp_algorithm.attr,
@@ -1132,6 +1167,7 @@ static int create_device(struct zram *zram, int device_id)
strlcpy(zram->compressor, default_compressor, sizeof(zram->compressor));
zram->meta = NULL;
zram->max_comp_streams = 1;
+ zram->fullness = ZRAM_FULLNESS_PERCENT;
return 0;
out_free_disk:
diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
index fcf3176a9f15..6a9f383d0d78 100644
--- a/drivers/block/zram/zram_drv.h
+++ b/drivers/block/zram/zram_drv.h
@@ -119,6 +119,7 @@ struct zram {
*/
unsigned long limit_pages;
+ int
[PATCH v1 1/5] zram: generalize swap_slot_free_notify
Currently, swap_slot_free_notify is used for zram to free
duplicated copy page for memory efficiency when it knows
there is no reference to the swap slot.
This patch generalizes it to be able to use for other
swap hint to communicate with VM.
Signed-off-by: Minchan Kim
---
Documentation/filesystems/Locking | 4 ++--
drivers/block/zram/zram_drv.c | 18 --
include/linux/blkdev.h| 7 +--
mm/page_io.c | 6 +++---
mm/swapfile.c | 6 +++---
5 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/Documentation/filesystems/Locking
b/Documentation/filesystems/Locking
index 94d93b1f8b53..c262bfbeafa9 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -405,7 +405,7 @@ prototypes:
void (*unlock_native_capacity) (struct gendisk *);
int (*revalidate_disk) (struct gendisk *);
int (*getgeo)(struct block_device *, struct hd_geometry *);
- void (*swap_slot_free_notify) (struct block_device *, unsigned long);
+ int (*swap_hint) (struct block_device *, unsigned int, void *);
locking rules:
bd_mutex
@@ -418,7 +418,7 @@ media_changed: no
unlock_native_capacity:no
revalidate_disk: no
getgeo:no
-swap_slot_free_notify: no (see below)
+swap_hint: no (see below)
media_changed, unlock_native_capacity and revalidate_disk are called only from
check_disk_change().
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index d78b245bae06..22a37764c409 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -926,7 +926,8 @@ error:
bio_io_error(bio);
}
-static void zram_slot_free_notify(struct block_device *bdev,
+/* this callback is with swap_lock and sometimes page table lock held */
+static int zram_slot_free_notify(struct block_device *bdev,
unsigned long index)
{
struct zram *zram;
@@ -939,10 +940,23 @@ static void zram_slot_free_notify(struct block_device
*bdev,
zram_free_page(zram, index);
bit_spin_unlock(ZRAM_ACCESS, >table[index].value);
atomic64_inc(>stats.notify_free);
+
+ return 0;
+}
+
+static int zram_swap_hint(struct block_device *bdev,
+ unsigned int hint, void *arg)
+{
+ int ret = -EINVAL;
+
+ if (hint == SWAP_FREE)
+ ret = zram_slot_free_notify(bdev, (unsigned long)arg);
+
+ return ret;
}
static const struct block_device_operations zram_devops = {
- .swap_slot_free_notify = zram_slot_free_notify,
+ .swap_hint = zram_swap_hint,
.owner = THIS_MODULE
};
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index e267bf0db559..c7220409456c 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1609,6 +1609,10 @@ static inline bool blk_integrity_is_initialized(struct
gendisk *g)
#endif /* CONFIG_BLK_DEV_INTEGRITY */
+enum swap_blk_hint {
+ SWAP_FREE,
+};
+
struct block_device_operations {
int (*open) (struct block_device *, fmode_t);
void (*release) (struct gendisk *, fmode_t);
@@ -1624,8 +1628,7 @@ struct block_device_operations {
void (*unlock_native_capacity) (struct gendisk *);
int (*revalidate_disk) (struct gendisk *);
int (*getgeo)(struct block_device *, struct hd_geometry *);
- /* this callback is with swap_lock and sometimes page table lock held */
- void (*swap_slot_free_notify) (struct block_device *, unsigned long);
+ int (*swap_hint)(struct block_device *, unsigned int, void *);
struct module *owner;
};
diff --git a/mm/page_io.c b/mm/page_io.c
index 955db8b0d497..c6cc19655e97 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -114,7 +114,7 @@ void end_swap_bio_read(struct bio *bio, int err)
* we again wish to reclaim it.
*/
struct gendisk *disk = sis->bdev->bd_disk;
- if (disk->fops->swap_slot_free_notify) {
+ if (disk->fops->swap_hint) {
swp_entry_t entry;
unsigned long offset;
@@ -122,8 +122,8 @@ void end_swap_bio_read(struct bio *bio, int err)
offset = swp_offset(entry);
SetPageDirty(page);
- disk->fops->swap_slot_free_notify(sis->bdev,
- offset);
+ disk->fops->swap_hint(sis->bdev,
+ SWAP_FREE, (void *)offset);
}
}
}
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 8798b2e0ac59..c07f7f4912e9 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -816,9 +816,9 @@ static unsigned char
[PATCH v1 4/5] zram: add swap full hint
This patch implement SWAP_FULL handler in zram so that VM can
know whether zram is full or not and use it to stop anonymous
page reclaim.
How to judge fullness is below,
fullness = (100 * used space / total space)
It means the higher fullness is, the slower we reach zram full.
Now, default of fullness is 80 so that it biased more momory
consumption rather than early OOM kill.
Above logic works only when used space of zram hit over the limit
but zram also pretend to be full once 32 consecutive allocation
fail happens. It's safe guard to prevent system hang caused by
fragment uncertainty.
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 60 ---
drivers/block/zram/zram_drv.h | 1 +
2 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 22a37764c409..649cad9d0b1c 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -43,6 +43,20 @@ static const char *default_compressor = "lzo";
/* Module params (documentation at end) */
static unsigned int num_devices = 1;
+/*
+ * If (100 * used_pages / total_pages) >= ZRAM_FULLNESS_PERCENT),
+ * we regards it as zram-full. It means that the higher
+ * ZRAM_FULLNESS_PERCENT is, the slower we reach zram full.
+ */
+#define ZRAM_FULLNESS_PERCENT 80
+
+/*
+ * If zram fails to allocate memory consecutively up to this,
+ * we regard it as zram-full. It's safe guard to prevent too
+ * many swap write fail due to lack of fragmentation uncertainty.
+ */
+#define ALLOC_FAIL_MAX 32
+
#define ZRAM_ATTR_RO(name) \
static ssize_t zram_attr_##name##_show(struct device *d, \
struct device_attribute *attr, char *b) \
@@ -148,6 +162,7 @@ static ssize_t mem_limit_store(struct device *dev,
down_write(>init_lock);
zram->limit_pages = PAGE_ALIGN(limit) >> PAGE_SHIFT;
+ atomic_set(>alloc_fail, 0);
up_write(>init_lock);
return len;
@@ -410,6 +425,7 @@ static void zram_free_page(struct zram *zram, size_t index)
atomic64_sub(zram_get_obj_size(meta, index),
>stats.compr_data_size);
atomic64_dec(>stats.pages_stored);
+ atomic_set(>alloc_fail, 0);
meta->table[index].handle = 0;
zram_set_obj_size(meta, index, 0);
@@ -597,10 +613,15 @@ static int zram_bvec_write(struct zram *zram, struct
bio_vec *bvec, u32 index,
}
alloced_pages = zs_get_total_pages(meta->mem_pool);
- if (zram->limit_pages && alloced_pages > zram->limit_pages) {
- zs_free(meta->mem_pool, handle);
- ret = -ENOMEM;
- goto out;
+ if (zram->limit_pages) {
+ if (alloced_pages > zram->limit_pages) {
+ zs_free(meta->mem_pool, handle);
+ atomic_inc(>alloc_fail);
+ ret = -ENOMEM;
+ goto out;
+ } else {
+ atomic_set(>alloc_fail, 0);
+ }
}
update_used_max(zram, alloced_pages);
@@ -711,6 +732,7 @@ static void zram_reset_device(struct zram *zram, bool
reset_capacity)
down_write(>init_lock);
zram->limit_pages = 0;
+ atomic_set(>alloc_fail, 0);
if (!init_done(zram)) {
up_write(>init_lock);
@@ -944,6 +966,34 @@ static int zram_slot_free_notify(struct block_device *bdev,
return 0;
}
+static int zram_full(struct block_device *bdev, void *arg)
+{
+ struct zram *zram;
+ struct zram_meta *meta;
+ unsigned long total_pages, compr_pages;
+
+ zram = bdev->bd_disk->private_data;
+ if (!zram->limit_pages)
+ return 0;
+
+ meta = zram->meta;
+ total_pages = zs_get_total_pages(meta->mem_pool);
+
+ if (total_pages >= zram->limit_pages) {
+
+ compr_pages = atomic64_read(>stats.compr_data_size)
+ >> PAGE_SHIFT;
+ if ((100 * compr_pages / total_pages)
+ >= ZRAM_FULLNESS_PERCENT)
+ return 1;
+ }
+
+ if (atomic_read(>alloc_fail) > ALLOC_FAIL_MAX)
+ return 1;
+
+ return 0;
+}
+
static int zram_swap_hint(struct block_device *bdev,
unsigned int hint, void *arg)
{
@@ -951,6 +1001,8 @@ static int zram_swap_hint(struct block_device *bdev,
if (hint == SWAP_FREE)
ret = zram_slot_free_notify(bdev, (unsigned long)arg);
+ else if (hint == SWAP_FULL)
+ ret = zram_full(bdev, arg);
return ret;
}
diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
index c6ee271317f5..fcf3176a9f15 100644
--- a/drivers/block/zram/zram_drv.h
+++ b/drivers/block/zram/zram_drv.h
@@ -113,6 +113,7 @@ struct zram {
u64 disksize;
[PATCH v1 3/5] mm: VM can be aware of zram fullness
VM uses nr_swap_pages to throttle amount of swap when it reclaims
anonymous pages because the nr_swap_pages means freeable space
of swap disk.
However, it's a problem for zram because zram can limit memory
usage by knob(ie, mem_limit) so that swap out can fail although
VM can see lots of free space from zram disk but no more free
space in zram by the limit. If it happens, VM should notice it
and stop reclaimaing until zram can obtain more free space but
we don't have a way to communicate between VM and zram.
This patch adds new hint SWAP_FULL so that zram can say to VM
"I'm full" from now on. Then VM cannot reclaim annoymous page
any more. If VM notice swap is full, it can remove swap_info_struct
from swap_avail_head and substract remained freeable space from
nr_swap_pages so that VM can think swap is full until VM frees a
swap and increase nr_swap_pages again.
Signed-off-by: Minchan Kim
---
include/linux/blkdev.h | 1 +
mm/swapfile.c | 44 ++--
2 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index c7220409456c..39f074e0acd7 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1611,6 +1611,7 @@ static inline bool blk_integrity_is_initialized(struct
gendisk *g)
enum swap_blk_hint {
SWAP_FREE,
+ SWAP_FULL,
};
struct block_device_operations {
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 209112cf8b83..71e3df0431b6 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -493,6 +493,29 @@ static unsigned long scan_swap_map(struct swap_info_struct
*si,
int latency_ration = LATENCY_LIMIT;
/*
+* If zram is full, we don't need to scan and want to stop swap.
+* For it, we removes si from swap_avail_head and decreases
+* nr_swap_pages to prevent further anonymous reclaim so that
+* VM can restart swap out if zram has a free space.
+* Look at swap_entry_free.
+*/
+ if (si->flags & SWP_BLKDEV) {
+ struct gendisk *disk = si->bdev->bd_disk;
+
+ if (disk->fops->swap_hint && disk->fops->swap_hint(
+ si->bdev, SWAP_FULL, NULL)) {
+ spin_lock(_avail_lock);
+ WARN_ON(plist_node_empty(>avail_list));
+ plist_del(>avail_list, _avail_head);
+ spin_unlock(_avail_lock);
+ atomic_long_sub(si->pages - si->inuse_pages,
+ _swap_pages);
+ si->full = true;
+ return 0;
+ }
+ }
+
+ /*
* We try to cluster swap pages by allocating them sequentially
* in swap. Once we've allocated SWAPFILE_CLUSTER pages this
* way, however, we resort to first-free allocation, starting
@@ -798,6 +821,14 @@ static unsigned char swap_entry_free(struct
swap_info_struct *p,
/* free if no reference */
if (!usage) {
bool was_full;
+ struct gendisk *virt_swap = NULL;
+
+ /* Check virtual swap */
+ if (p->flags & SWP_BLKDEV) {
+ virt_swap = p->bdev->bd_disk;
+ if (!virt_swap->fops->swap_hint)
+ virt_swap = NULL;
+ }
dec_cluster_info_page(p, p->cluster_info, offset);
if (offset < p->lowest_bit)
@@ -814,17 +845,18 @@ static unsigned char swap_entry_free(struct
swap_info_struct *p,
_avail_head);
spin_unlock(_avail_lock);
p->full = false;
+ if (virt_swap)
+ atomic_long_add(p->pages -
+ p->inuse_pages,
+ _swap_pages);
}
atomic_long_inc(_swap_pages);
p->inuse_pages--;
frontswap_invalidate_page(p->type, offset);
- if (p->flags & SWP_BLKDEV) {
- struct gendisk *disk = p->bdev->bd_disk;
- if (disk->fops->swap_hint)
- disk->fops->swap_hint(p->bdev,
- SWAP_FREE, (void *)offset);
- }
+ if (virt_swap)
+ virt_swap->fops->swap_hint(p->bdev,
+ SWAP_FREE, (void *)offset);
}
return usage;
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 0/5] stop anon reclaim when zram is full
For zram-swap, there is size gap between virtual disksize and available physical memory size for zram so that VM can try to reclaim anonymous pages even though zram is full. It makes system alomost hang(ie, unresponsible) easily in my kernel build test(ie, 1G DRAM, CPU 12, 4G zram swap, 50M zram limit). VM should have killed someone. This patch adds new hint SWAP_FULL so VM can ask fullness to zram and if it founds zram is full, VM doesn't reclaim anonymous pages until zram-swap gets new free space. With this patch, I see OOM when zram-swap is full instead of hang with no response. Minchan Kim (5): zram: generalize swap_slot_free_notify mm: add full variable in swap_info_struct mm: VM can be aware of zram fullness zram: add swap full hint zram: add fullness knob to control swap full Documentation/ABI/testing/sysfs-block-zram | 10 +++ Documentation/filesystems/Locking | 4 +- drivers/block/zram/zram_drv.c | 114 +++-- drivers/block/zram/zram_drv.h | 2 + include/linux/blkdev.h | 8 +- include/linux/swap.h | 1 + mm/page_io.c | 6 +- mm/swapfile.c | 77 ++- 8 files changed, 189 insertions(+), 33 deletions(-) -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: FIX ME in oxu210p-hcd.c
> Subject: Re: FIX ME in oxu210p-hcd.c > > > I found a unfixed FIX ME in the file stated in my above message. I am > wondering what to set hcd->self.comtroller->dma_mask to as it's now been > defined to NULL and clearly even as a newbie this seem incorrect. > Regards Nick Usually, it is set at its controller driver or pass through through device tree or platform data. Peter
Re: [GIT PULL] KEYS: Changes for keyrings for security/next
James Morris wrote: > > Can you please pull these changes into security/next. They include the > > fixes > > tag I previously requested as there's a dependency between these changes and > > the fixes. > > > > I'm getting this warning after pulling your code: > > CC crypto/hash_info.o > crypto/asymmetric_keys/asymmetric_type.c: In function > asymmetric_key_hex_to_key_id: > crypto/asymmetric_keys/asymmetric_type.c:110: warning: ignoring return > value of hex2bin, declared with attribute warn_unused_result I've posted an additional patch that moves some of the prevalidation to after the memory allocation in asymmetric_key_hex_to_key_id() and added it onto the keys-next branch. Here's a revised pull request. --- Can you please pull these changes into security/next. They include the fixes tag I previously requested as there's a dependency between these changes and the fixes. So, there are the fixes to go upstream: (1) Reinstate the production of EPERM for key types beginning with '.' in requests from userspace. (2) Tidy up the cleanup of PKCS#7 message signed information blocks and fix a bug this made more obvious. There are some additional fixes which can go through security/next: (1) Insert some missing 'static' annotations. And then there are some improvements to X.509 and PKCS#7: Changes for next to improve the matching of asymmetric keys and to improve the handling of PKCS#7 certificates: (1) Provide a method to preparse the data supplied for matching a key. This permits they key type to extract out the bits it needs for matching once only. Further, the type of search (direct lookup or iterative) can be set and the function used to actually check the match can be set by preparse rather than being hard coded for the type. (2) Improves asymmetric keys identification. Keys derived from X.509 certs now get labelled with IDs derived from their issuer and certificate number (required to match PKCS#7) and from their SKID and subject (required to match X.509). IDs are now binary and match criterion preparsing is provided so that criteria can be turned into binary blobs to make matching faster. (3) Improves PKCS#7 message handling to permit PKCS#7 messages without X.509 cert lists to be matched to trusted keys, thereby allowing minimally sized PKCS#7 certs to be used. (4) Improves PKCS#7 message handling to better handle certificate chains that are broken due to unsupported crypto that can otherwise by used to intersect a trust keyring. (5) An alteration to to get rid of a warning due to the return value of hex2bin() not being checked. David --- The following changes since commit ac60ab4b4968b54fb5af20eac9dd78e36ad910c1: Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity into next (2014-09-12 22:40:22 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/keys-next-20140922 for you to fetch changes up to d1ac5540455c3a2a11e943e19e2dc044cebe147d: KEYS: Check hex2bin()'s return when generating an asymmetric key ID (2014-09-22 00:02:01 +0100) (from the branch description for keys-next local branch) Keyrings for linux-next Keyrings changes for next David Howells (19): KEYS: Fix missing statics PKCS#7: Add a missing static KEYS: Reinstate EPERM for a key type name beginning with a '.' PKCS#7: Provide a single place to do signed info block freeing PKCS#7: Fix the parser cleanup to drain parsed out X.509 certs Merge tag 'keys-fixes-20140916' into keys-next Merge tag 'keys-next-fixes-20140916' into keys-next Provide a binary to hex conversion function KEYS: Preparse match data KEYS: Remove key_type::def_lookup_type KEYS: Remove key_type::match in favour of overriding default by match_preparse KEYS: Make the key matching functions return bool KEYS: Update the keyrings documentation for match changes KEYS: Implement binary asymmetric key ID handling KEYS: Overhaul key identification when searching for asymmetric keys PKCS#7: Better handling of unsupported crypto PKCS#7: Handle PKCS#7 messages that contain no X.509 certs Merge tag 'keys-pkcs7-20140916' into keys-next KEYS: Check hex2bin()'s return when generating an asymmetric key ID Documentation/security/keys.txt | 65 +++-- crypto/asymmetric_keys/asymmetric_keys.h | 8 +- crypto/asymmetric_keys/asymmetric_type.c | 223 +- crypto/asymmetric_keys/pkcs7_key_type.c | 2 - crypto/asymmetric_keys/pkcs7_parser.c | 99 +++-- crypto/asymmetric_keys/pkcs7_parser.h | 6 +- crypto/asymmetric_keys/pkcs7_trust.c | 87
[PATCH] bridge: fix netfilter/NF_BR_LOCAL_OUT for own, locally generated queries
Ebtables on the OUTPUT chain (NF_BR_LOCAL_OUT) would not work as expected
for both locally generated IGMP and MLD queries. The IP header specific
filter options are off by 14 Bytes for netfilter (actual output on
interfaces is fine).
NF_HOOK() expects the skb->data to point to the IP header, not the
ethernet one (while dev_queue_xmit() does not). Luckily there is an
br_dev_queue_push_xmit() helper function already - let's just use that.
Introduced by eb1d16414339a6e113d89e2cca2556005d7ce919
("bridge: Add core IGMP snooping support")
Ebtables example:
$ ebtables -I OUTPUT -p IPv6 -o eth1 --logical-out br0 \
--log --log-level 6 --log-ip6 --log-prefix="~EBT: " -j DROP
before (broken):
~EBT: IN= OUT=eth1 MAC source = 02:04:64:a4:39:c2 \
MAC dest = 33:33:00:00:00:01 proto = 0x86dd IPv6 \
SRC=64a4:39c2:86dd:6000::0020:0001:fe80 IPv6 \
DST=:::0004:64ff:fea4:39c2:ff02, \
IPv6 priority=0x3, Next Header=2
after (working):
~EBT: IN= OUT=eth1 MAC source = 02:04:64:a4:39:c2 \
MAC dest = 33:33:00:00:00:01 proto = 0x86dd IPv6 \
SRC=fe80::::0004:64ff:fea4:39c2 IPv6 \
DST=ff02:::::::0001, \
IPv6 priority=0x0, Next Header=0
Signed-off-by: Linus Lüssing
---
net/bridge/br_multicast.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 7751c92..9d02e6c 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -813,10 +813,9 @@ static void __br_multicast_send_query(struct net_bridge
*br,
return;
if (port) {
- __skb_push(skb, sizeof(struct ethhdr));
skb->dev = port->dev;
NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_OUT, skb, NULL, skb->dev,
- dev_queue_xmit);
+ br_dev_queue_push_xmit);
} else {
br_multicast_select_own_querier(br, ip, skb);
netif_rx(skb);
--
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/
